Вопросы о кешировании на сайте с большим трафиком - PullRequest
2 голосов
/ 11 февраля 2010

Предположим, мы создаем сайт электронной коммерции, который позволяет потребителям искать товары, вводя ключевые слова. Скажем, есть не более 200 000 продуктов, и миллионы потребителей используют систему. Допустим, таблица продуктов обновляется довольно часто. Так как количество продуктов не так велико, и мы, вероятно, можем хранить всю таблицу продуктов в памяти и осуществлять поиск по ней, а не попадать в базу данных. Мы надеемся создать распределенные кэши, которые хранят одни и те же данные, но находятся на разных серверах (по причине высокой доступности и производительности), и нам нужно иметь возможность синхронизировать данные между этими кэшами и делать недействительными кэши при изменении таблицы продуктов.

Наше приложение построено с использованием ASP.NET MVC и NHibernate. Я пытаюсь понять, поможет ли кэширование уровня 2 NHibernate в моей ситуации. Я был бы очень признателен, если бы вы, ребята, смогли пролить свет на это.

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

Ответы [ 3 ]

2 голосов
/ 13 февраля 2010

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

Компонент NHibernate.Search зависит от Lucene.Net, и поиск по ключевым словам отделен от собственной базы данных. Для каждого сопоставленного класса создается отдельный индексный файл, и оптимизация может быть задана на уровне свойств с использованием атрибутов, что обеспечивает дополнительный уровень детализации. Кроме того, вы можете реализовать лучшее соответствие и предложения (отметьте Lucene в действии и / или Hibernate Search в действии). Как примечание, вам не нужно поддерживать индекс (если вы явно не запросите перестроение индекса); реализация управляет всем негласно, хотя вы можете манипулировать индексом, если хотите. Таким образом, добавление / удаление / обновление продукта автоматически обновит соответствующий индекс.

Для кэша второго уровня вы получаете мгновенное повышение производительности. В тестовой среде с набором данных приблизительно в 2 млн строк у меня было улучшение более чем на 20% даже при крайне низком количестве запросов. Повышение производительности постепенно увеличивается по мере увеличения количества запросов - приложение сначала обращается к кэшу 2-го уровня, а если оно не находит его, затем обращается к БД, чтобы извлечь необходимые строки и вставить их в кэш для будущих запросов. Опять же, вы можете управлять такими вещами, как длительность кеша и другие параметры конфигурации, а также явно очищать кеш (весь, часть или отдельные записи), если вы хотите это сделать. Обратите внимание, что состояние кэша управляется приложением во время сохранения / обновления / удаления.

Для масштабируемости * кэш 2-го уровня зависит от провайдера (т.е. memcached обладает высокой производительностью и масштабируемостью и поддерживает распределенные экземпляры). * для Lucene.Net/NHibernate.Search вам нужно будет установить определенное место, в котором будут размещаться индексы, и это место должно быть доступно для чтения / записи всеми экземплярами веб-приложения. Обратите внимание, что чувствительная ссылка - это ввод-вывод и конфликт файлов, поэтому настройка компьютера с файловой системой, работающей быстрее, чем легкая, предотвратит это (я говорю о вашем сценарии со многими тысячами поисковых запросов в секунду)

В качестве примечания я бы настоятельно рекомендовал NHibernate.Search, поскольку он чрезвычайно быстр, чем запросы LIKE, и его проще использовать, чем реализацию полнотекстового поиска SQL-Server внутри приложения (что я и сделал).

2 голосов
/ 11 февраля 2010

Поможет ли кэш второго уровня, зависит от того, как часто обновляется таблица вашего продукта в связи с попаданиями в кеш. Если вы добавляете 100 новых продуктов в час, но получаете 10 000 запросов в час, даже 10% успеха в кэше будет иметь большое значение. Если скорости поменялись местами, кэш второго уровня практически не будет иметь значения.

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

Также убедитесь, что ваша БД настроена правильно для сценария с интенсивным обновлением.

1 голос
/ 11 февраля 2010

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

TekPub сделал недавний эпизод по вашему точному сценарию поиска описаний продуктов. В этом эпизоде ​​сравниваются запросы NHibernate, полнотекстовая индексация SQL и Lucene w / NHibernate.Search.

...