Кэширование локального экземпляра SQL на веб-сервере

Question

Я запускаю очень высокий трафик (10 миллионов показов в день)/высокодоходный веб-сайт, созданный с помощью .net. Основные метаданные хранятся на сервере SQL. У моей команды и у меня есть уникальная стратегия кэширования, которая включает в себя запросы к базе данных для новых метаданных через регулярные промежутки времени с сервера среднего уровня, сериализации данных в файлы и отправки их на веб-узлы. Веб-приложение использует данные в этих файлах (некоторые из них являются фактически сериализованными объектами), чтобы создавать объекты и кэшировать их в памяти для использования в запросах реального времени.

Преимущество этой модели заключается в том, что она:

1. Позволяет веб-узлы кэшировать все данные в памяти и не несут никакого IO накладных запросов к базе данных.
2. Если база данных когда-либо опускается либо неожиданно, либо для окон технического обслуживания, веб-серверы будут продолжать работать и получать доход. Вы даже можете запустить веб-сервер без необходимости извлекать свои исходные данные из БД, потому что все необходимые ему данные находятся в файлах на своих собственных дисках.
3. Позволяет быть полностью горизонтально масштабируемым. Если пропускная способность страдает, мы можем просто добавить веб-сервер.

Недостатки в том, что эти уровни кэширования и persistense добавляют сложность кода, который запрашивает базу данных, упаковывает данные и распаковывает их на веб-сервере. В любой момент, когда наша модель домена требует добавления объектов, нужно больше закодировать эту «сантехнику». Эта архитектура существует уже четыре года, и есть, вероятно, лучшие способы решения этой проблемы.

Одна из стратегий, которую я рассматривал, заключается в использовании репликации для репликации нашей основной базы данных SQL Server в локальные экземпляры базы данных, установленные на каждом веб-сервере. Приложение веб-сервера будет использовать обычные методы sql/ORM для создания объектов. Здесь мы все равно можем поддерживать отладку основной базы данных, и нам не нужно будет кодировать специализированный код кеширования и вместо этого использовать nHibernate для обработки персистентности.

Это похоже на более элегантное решение и хотелось бы видеть, что думают другие, или если у кого-либо есть альтернативы, чтобы предложить.

Answer 1

Считаете ли вы, что memcached? Так как:

1. в памяти
2. может работать локально
3. полностью масштабируемым горизонтально
4. предотвращает необходимость повторного кэша на каждом веб-сервере

Это может соответствовать требованиям. Проверьте Google for lots of details и истории использования.

Answer 2

Считаете ли вы использование кэширования SqlDependency?

Вы также можете записать данные на локальный диск на веб-уровне, если вас беспокоит начальное время запуска или отключения БД. Но, по крайней мере, с SqlDependency, вам не нужно будет опроса DB искать изменения. Это также можно сделать относительно прозрачным.

По моему опыту, добавление экземпляра БД на веб-серверах, как правило, не слишком хорошо работает с точки зрения масштабируемости или производительности.

Если вас беспокоит производительность и масштабируемость, вы можете рассмотреть возможность разделения вашего уровня данных. Специфика зависит от вашего приложения, но в качестве примера вы можете перемещать данные только для чтения на пару серверов SQL Express, заполненных репликацией.

В случае, если это поможет, я подробно расскажу об этом предмете в своей книге (Ultra-Fast ASP.NET).

Answer 3

Просто некоторые дополнение к тому, что RickNZ предложенный выше .. Поскольку основные данные, которые вы кэшировать в настоящее время не изменится, так часто и, вероятно, в течение некоторого окна обслуживания, вот что вы должны сделать в первую очередь на стороне базы данных:

Создайте репликацию SNAPSHOT для основных таблиц, которые вы хотите кэшировать. Добавление новых объектов будет одинаково легко. На всех веб-серверах установите SQL Express и подписаться на эту публикацию. Поскольку это не часто изменяющиеся данные, вы можете быть уверены, что проблема с использованием ресурсов сервера не связана с отключением сети для основных данных.

Все ваше кэширование, которое было доступно через предыдущий механизм, по-прежнему доступно, минус всякая головная боль, возникающая при добавлении новых объектов.

Далее вы можете использовать механизмы .NET, как было предложено выше. Вы не столкнетесь с отказом кластерного кластера, если ваш веб-сервер не опустится. В .NET есть много возможностей, которые .NET pro может указать после этого этапа.

Answer 4

Я думаю, вы слишком задумываетесь об этом. У SQL Server уже есть механизмы, доступные вам для обработки таких вещей.

Во-первых, внедрите кластер SQL Server для защиты основной базы данных. Вы можете переходить от узла к узлу в кластере, не теряя данные, а время простоя - это секунды, макс.

Во-вторых, реализовать зеркальное отображение базы данных для защиты от сбоя кластера. В зависимости от того, используете ли вы синхронное или асинхронное зеркалирование, ваш зеркальный сервер будет либо обновляться в реальном времени, либо через несколько минут. Если вы сделаете это в режиме реального времени, вы можете автоматически перейти на зеркало внутри своего приложения - SQL Server 2005 & выше поддержка встраивания имени зеркального сервера в строку подключения, поэтому вам даже не нужно поднимать палец. Приложение просто подключается к любому серверу в прямом эфире.

Между этими двумя вещами вы защищены от практически любого основного сбоя базы данных, не имеющего силового сбоя в сети или отказа сети, и нет никакой сложности в репликации. Это относится к проблеме с высокой доступностью и позволяет ответить на вопрос о масштабировании отдельно.

Мой любимый отправной точкой для масштабирования с использованием трех отдельных строк подключения в приложении, и выбрать правильный исходя из потребностей вашего запроса:

• в реальном времени - Очки непосредственно на один главный сервер. Все записи переходят к этой строке соединения, и здесь доступны только самые критически важные чтения.
• Near-Realtime - указывает на сбалансированный баланс ресурсов только для чтения SQL-серверов, которые обновляются обновлением путем репликации или доставки журналов. В вашем оригинальном дизайне они жили на веб-серверах, но это опасная практика и кошмар для обслуживания. SQL Server требует много памяти (не говоря уже о деньгах для лицензирования), и вы не хотите привязываться к добавлению сервера базы данных для каждого отдельного веб-сервера.
• Отложенная отчетность. В вашей среде прямо сейчас она будет указывать на один и тот же балансировочный пул подписчиков, но по дороге вы можете использовать технологию, например, доставку журналов, чтобы иметь пул серверов за 8-24 часа. Это очень хорошо, но данные далеко позади. Это отлично подходит для отчетов, поиска, долгосрочной истории и других потребностей, не связанных с реальным временем.

Если вы создаете приложение для использования этих трех строк соединения с самого начала, масштабирование намного проще и не требует какой-либо сложности кодирования - просто выберите правильную строку соединения.

Answer 5

Мне кажется, что Windows Server AppFabric - именно то, что вы ищете. (AKA «Velocity»). Из introductory documentation:

Windows Server AppFabric обеспечивает распределенной в памяти приложения платформы кэш для разработки масштабируемых, доступных и высокопроизводительных приложений. AppFabric плавает память на нескольких компьютерах , чтобы предоставить единый унифицированный вид кеша . Применения могут хранить любой сериализуемый объект CLR без , беспокоясь о том, где находится объект . Масштабируемость может быть достигнута , просто добавив больше компьютеров на . Кэш также позволяет хранить копии данных, хранящихся в кластере , тем самым защищая данные от сбоев. Он работает как услуга , доступ к которой осуществляется через сеть. В дополнении Windows Server AppFabric обеспечивает бесшовную интеграцию с ASP.NET, который позволяет ASP.NET-сеансу объекты, которые будут храниться в распределенном кеше , без необходимости писать в базы данных. Это увеличивает производительность и масштабируемость приложений ASP.NET.