Каковы преимущества и недостатки распределенного кэша второго уровня по сравнению с настройкой базы данных?

Question

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

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

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

Answer 1

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

Answer 2

Оба. Вы должны иметь распределенный кеш, чтобы предотвратить ненужные вызовы в базу данных и настроенную базу данных, чтобы начальные вызовы быстро возвращались. Например, для масштабирования Facebook требовалось значительное количество кэширования, но я уверен, что это не принесло бы пользы, если бы начальные запросы заняли 10 минут. :)

Answer 3

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

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

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

Это особенно верно для случая, когда веб-узел 1 запрашивает набор данных A, а веб-узел 2 запрашивает набор данных A -> вы собираетесь выполнить один и тот же запрос дважды, тогда как при кэшировании второго уровня вы делаете это только один раз.

Итак, моя рекомендация:

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

Do оптимизирует работу вашей базы данных. Это означает как со стороны базы данных (индексы, представления, sp-функции, функции, возможно, кластер с узлами только для чтения и только для записи), так и со стороны приложения (оптимизируйте ваши запросы, профилирование при отложенной / активной загрузке, не извлекайте данные, которые вам нужны не нужно, объединяйте несколько запросов в односторонние циклы через Future, MutliQuery, MultiCriteria)

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

Если использование текстовых запросов является повседневной операцией, используйте полнотекстовые возможности базы данных или, что еще лучше, используйте независимый сервис, такой как Lucene.NET (который может быть интегрирован с NHibernate через NHibernate.Search)

Answer 4

Два слова: измерьте это.

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

Answer 5

Это очень сложная тема.В любом случае вам нужно мастерство.Либо очень опытный администратор баз данных, либо очень опытный администратор NHibernate / Cache.

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

Поскольку у вас уже есть NHibernate, хотя отойти от него, вернуться к SQL (может быть, с помощью LINQ?) может оказаться довольно дорогой задачей,это не стоит усилий.

Answer 6

Мы используем кэш 2-го уровня NHibernate в нашей многосерверной среде с использованием среды распределенного кэша Microsoft AppFabric ( NHibernate Velocity Provider ) с большим успехом.

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

Поэтому мой ответ в основном - перед использованием кеша 2-го уровня вы должны действительно проверить и выяснить, действительно ли он нужен.