Зачем использовать AppFabric, когда денормализованные данные SQL Server также работают?

Question

Я работаю над веб-сайтом электронной коммерции, предназначенным для представления большого количества SKU. Схема SQL Server, описывающая эти продукты, нормализована в той мере, в которой несколько лет назад стало неоправданно медленным получение необходимой информации для представления клиентам, поэтому мы изменили нашу инфраструктуру таким образом, чтобы мы несли затраты на загрузку данных для каждый продукт один раз и затем сохраняет эти данные в кэше AppFabric (ранее Velocity).

С течением времени сложность требований, предъявляемых к нашей инфраструктуре AppFabric, выросла (представьте себе), заставив нас потратить значительное количество времени на написание кода для обработки извлечения данных из нашего кеша, обновления данных, включая инкрементные обновления и т. Д.

У нас есть большая часть наших данных о продуктах, хранящихся в денормализованной форме в боковой базе данных, поэтому для экспериментов я написал консольное приложение для случайного выбора одного из наших ~ 150K SKU за один раз, а затем извлечение записи для этого продукта из нашей денормализованной таблицы.

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

Это заставляет меня думать, что нам может быть лучше, просто используя денормализованные данные в SQL Server для наших высоких требований к нагрузке/высокой производительности. Инструменты управления для данных на базе SQL Server намного лучше. Все разработчики нашей команды умеют использовать Management Studio, тогда как с AppFabric у нас есть один dev, который может использовать PowerShell для a) Дайте нам количество записей, хранящихся в кеше, и b) дамп кэша. Любые другие функции управления, которые мы должны создать сами.

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

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

Answer 1

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

В AppFabric Cache я могу настроить распределенный набор серверов для работы с одним логическим хранилищем - со встроенной балансировкой нагрузки. Таким образом, в отличие от Microsoft SQL Server, который не имеет возможности предоставлять кластерные экземпляры с целью балансировки нагрузки - если я читаю и пишу от 50 до 100 миллионов раз в день, кеш является более жизнеспособным решением для совместного использования этих ресурсов. Затем эти записи могут быть поставлены в очередь на долговечную модель настойчивости с течением времени, гарантируя, что нет реальных пиков в использовании, потому что они распространяются как по структуре кэширования, так и в прочном хранилище.

Answer 2

Использование AppFabric, а не выделенной базы данных, связанной с кэшем, содержащей денормализованную схему, также обеспечивает преимущества мелкозернистого управления политиками истечения срока действия, выселения и настройки региона кеша. Вам придется перевернуть это самостоятельно, если вы используете SqlServer. Я также согласен с комментариями @ mperrenoud03 о балансировке нагрузки и высокой скорости транзакций. Кроме того, если вы используете хороший инструмент ORM, например NHibernate, его можно настроить на использование Appfabric (или других распределенных кэш-платформ) в качестве кеша второго уровня. Мы используем это в нашем проекте и получаем хорошие результаты.