Архитектура кэширования результатов поиска в приложении ASP.NET

Question

Каков хороший дизайн для кэширования результатов дорогого поиска в системе ASP.NET?

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

Вот некоторые общие требования, связанные с проблемой:

• Каждый результат поиска может содержать от нуля до нескольких сотен записей результатов
• Каждый поиск обходится относительно дорого и требует много времени (5-15 секунд в базе данных)
• Результаты должны быть разбиты на страницы перед отображением на клиенте, чтобы избежать информационной перегрузки для пользователя
• Пользователи ожидают, что смогут сортировать, фильтровать и искать в результатах поиска
• Пользователи ожидают, что смогут быстро переключаться между страницами в результатах поиска
• Пользователи ожидают, что смогут выбрать несколько элементов (с помощью флажка) на любом количестве страниц
• Пользователи ожидают относительно высокой производительности после завершения поиска

Я вижу несколько возможных вариантов, где и как реализовать кэширование:

1. Кэшируйте на сервере (в сеансе или в кэше приложений), используйте постбэки или панели Ajax для упрощения разбиения на страницы, сортировки, фильтрации и поиска.

• PROS : Простота реализации, достойная поддержка инфраструктуры ASP.NET
• CONS : очень болтливый, много памяти на сервере, данные могут кэшироваться дольше, чем необходимо; запрещает методы балансировки нагрузки

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

• PROS : эффективное использование памяти сервера; возможность масштабирования с использованием балансировки нагрузки;
• CONS : ограниченная поддержка инфраструктуры .NET; потенциально хрупкий при изменении структуры данных; размещает дополнительную нагрузку на базу данных; значительно сложнее

3. Кэшируйте на клиенте (используя сериализацию JSON или XML), используйте клиентский Javascript для разбивки на страницы, сортировки, фильтрации и выбора результатов.

• PROS : взаимодействие с пользователем может приблизиться к уровню «богатого клиента»; большинство браузеров могут обрабатывать JSON / XML изначально - для манипулирования существуют приличные библиотеки (например, jQuery)
• CONS : загрузка начального запроса может занять много времени; значительный объем памяти на клиентских машинах; потребует ручной Javascript на каком-то уровне для реализации

4. Кэшируйте на клиенте, используя сжатое / закодированное представление данных - перезвоните на сервер для декодирования при переключении страниц, сортировке, фильтрации и поиске.

• PROS : минимизировано влияние памяти на сервер; позволяет государству жить столько, сколько нужно клиенту; немного улучшенное использование памяти на клиенте по сравнению с JSON / XML
• CONS : большие наборы данных, перемещающиеся назад и вперед между клиентом / сервером; более низкая производительность (из-за сетевого ввода-вывода) по сравнению с чистым кэшированием на стороне клиента с использованием JSON / XML; гораздо сложнее в реализации - ограниченная поддержка .NET / browser

5. Некоторые альтернативные схемы кэширования, которые я не рассматривал ...

Answer 1

Для # 1, вы рассматривали возможность использования сервера состояний (даже сервера SQL) или механизма общего кэша? Есть много из хорошо единиц до выберите из, и Скорость становится очень зрелой - вероятно, будет RTM скоро. Схема аннулирования кэша, основанная на том, создает ли пользователь новый поиск, просматривает ли любую другую страницу, кроме нумерации страниц, и, наконец, стандартный тайм-аут (20 минут) должен быть довольно успешным при уменьшении размера кэша до минимального размера.

Ссылки:

• SharedCache (FOSS)
• NCache ($ 995 / CPU)
• StateServer (~ 1200 $ / сервер)
• StateMirror («Корпоративные цены»)
• Скорость (бесплатно?)

Answer 2

Если вы можете подождать до марта 2010 года, .NET 4.0 поставляется с новым System.Caching.CacheProvider , который обещает множество реализаций (диск, память, SQL Server / Velocity, как уже упоминалось).

Хорошее слайд-шоу технологии здесь . Однако это немного «катит по-своему» или многое другое. Но, вероятно, будет много поставщиков с закрытым и открытым исходным кодом, написанных для модели Provider, когда будет выпущена платформа.

По шести пунктам, которые вы указали, возникает несколько вопросов

• Что содержится в результатах поиска? Просто строковые данные или масса метаданных, связанных с каждым результатом?
• Насколько большой набор вы ищете?

Сколько памяти вы бы использовали для хранения всего набора в ОЗУ? Или, по крайней мере, иметь кеш самых популярных 10-100 поисковых терминов. Еще одной идеей может быть умный поиск и поиск, связанный с кэшированием после первого поиска.

5-15 секунд для результата - это долгое время ожидания поиска, поэтому я предполагаю, что это что-то похожее на поиск expedia.com, где запрашиваются несколько источников и возвращается много информации.

Из моего ограниченного опыта, самая большая проблема с подходом кэширования только на стороне клиента - Internet Explorer 6 или 7 . Только сервер и HTML - это мое предпочтение со всем набором результатов в кеше для подкачки страниц, срок его действия истекает через некоторое разумное время. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.

Answer 3

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

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

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

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

Answer 4

Поскольку вы говорите, любые идеи приветствуются:

Мы довольно успешно используем кэширование библиотеки предприятия для кэширования наборов результатов из результата LINQ.

http://msdn.microsoft.com/en-us/library/cc467894.aspx

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

Это довольно полнофункциональный.

Моя рекомендация комбинация # 1 и # 3 :

1. Кэшировать результаты запроса на сервере.
2. Сделать результаты доступными как в виде полной страницы, так и в виде JSON.
3. Кэшировать каждую страницу, динамически полученную на клиенте, но отправлять запрос каждый раз, когда страница меняется.
4. Используйте ETAG для аннулирования кэша клиента.

Answer 5

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

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

Answer 6

Посмотрите на SharedCache - он делает 1/2 довольно простым и прекрасно работает в системе с балансировкой нагрузки. Бесплатный, с открытым исходным кодом, и мы используем его около года без проблем.