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

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

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

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

Ответ 1

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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