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

Что такое хороший дизайн для кэширования результатов дорогого поиска в системе 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/браузера

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

ОТВЕТЫ

Ответ 1

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

Литература:

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Это довольно полно.

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

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

Ответ 5

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

Ответ 6

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

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