Оптимизация RavenDb при повторном поиске и странице - PullRequest
0 голосов
/ 29 октября 2011

Учитывая структуру документа, которая имеет, скажем, 15 свойств и 3 свойства IEnumerable, где каждое такое свойство может иметь до 20 значений.

когда у меня есть 50 000 таких документов в вороне, учитывая, что пользователь может построить критерий, указав значения для 7 или около того свойств.

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

Теперь скажите, что я нахожу 7000 результатов, соответствующих некоторым критериям, созданным пользователем, если я решу извлечь все 7000 идентификаторов, соответствующих критериям (постоянно пропускаю, чтобы получить все, что я представляю), а затем хеширую критерии и использую их как ключ для хранения 7000 значений в memcached, затем при повторном поиске тех же критериев я могу просто извлечь идентификаторы из кэша, получить 10 идентификаторов для страницы, на которой находится пользователь, и загрузить результаты по идентификатору из raven. Кроме того, когда они появляются, я могу не выполнять тот же поиск снова с помощью команды «Пропустить и взять», а просто перейти в кеш и получить идентификаторы для следующей страницы, чтобы перейти в raven для загрузки.

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

Дает ли этот подход мне какие-либо дивиденды за то, что я все время выполняю поиск, пропускаю данные при необходимости на странице и позволяю raven использовать магию повторного использования динамических индексов при повторном использовании поиска?

Примечание : Я использую API LINQ.

1 Ответ

4 голосов
/ 29 октября 2011

Вы говорите о создании собственного индекса.Неважно, используете ли вы memcached или какую-либо другую технологию для хранения вашего индекса, это будет просто -> индекс.

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

Чтобы быть понятным - да, я действительно думаю, что вы должныиспользуйте стандартный интерфейс LINQ и позвольте RavenDB создавать динамические индексы.Если они используются действительно так часто, RavenDB очень скоро будет рекламировать их как постоянные индексы.

...