Сохранение результатов поиска для подкачки и сортировки

Question

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

Сайт представляет собой небольшую интрасеть (500 сотрудников), поэтому проблем не должно быть, но мне интересно, какой подход вы бы выбрали, если бы это был сайт большего размера

Я гуглил abit, но на самом деле не нашел ничего особенного. Итак, несколько вопросов:

• Какие есть еще подходы? И почему они лучше?
• Сколько стоит хранить данные в 400-500 строк? Какие размеры возможны?
• Другие моменты, которые вы должны принять во внимание.

Любые входные данные приветствуются:)

Answer 1

Вам нужно использовать много техник, чтобы успешно это осуществить.

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

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

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

В-третьих , вы захотите каким-то образом разместить страницу с вашим объектом результата ... Шаблон итератора работает хорошо, хотя, вероятно, может работать что-то более простое ... как fetch X количество результатов, начиная с точки Y . Тем не менее, шаблон Iterator был бы лучше, так как вы могли бы позже удалить свой механизм кэширования и, если пожелаете, страницу непосредственно из базы данных.

Четвертый , вам нужен какой-то механизм предварительной выборки (как предлагали другие). Вы должны запустить поток, который будет выполнять полный поиск, а в вашей основной теме просто выполнить быстрый поиск с количеством элементов X . Надеемся, что к тому времени, когда пользователь попытается выполнить пейджинг, второй поток будет завершен, и ваш полный результат теперь будет в кеше. Если результат не готов, вы можете просто включить некоторую простую логику экрана загрузки.

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

Я оставлю вам еще несколько советов ...

1. Вы не хотите отправлять весь результат клиентскому приложению (если вы используете Ajax или что-то вроде приложения для iPhone). Зачем? Ну, потому что это огромная трата. Скорее всего, пользователь не будет просматривать все результаты ... теперь вы просто бесплатно отправили более 2 МБ полей результатов.

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

3. Абстракция абстракция абстракция ... вы хотите абстрагировать кеш, запросы, разбиение на страницы, предварительную выборку ... как можно больше. Зачем? Хорошо, скажем, вы хотите переключать базы данных или вы хотите перелистывать страницы непосредственно из базы данных вместо того, чтобы использовать результирующий объект в кеше ... хорошо, если вы все сделаете правильно, это будет легче изменить позже. Кроме того, при использовании веб-сервисов многие другие приложения могут использовать эту логику позже.

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

Дайте мне знать, если у вас есть вопросы.

Answer 2

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

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

Answer 3

Ответ Тима - отличный способ справиться с ситуацией, если у вас есть возможность запустить начальный запрос во втором потоке, а логика (разбиение на страницы / сортировка / фильтрация), применяемая к результатам, требует действий на сервере ... .. иначе ....

Если вы можете использовать AJAX, набор результатов из 500 строк может быть вызван на страницу и разбит на страницы или отсортирован на клиенте. Это может привести к некоторым по-настоящему интересным функциям ... Ознакомьтесь с решениями для сетки данных от jQueryUI и Dojo для вдохновения!

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

Загрузка данных в браузер одновременно позволяет также вызывать вспомогательные данные (предварительный просмотр страниц и т. Д.), Когда пользователь «запрашивает» их ...

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

Возможности безграничны:)

Answer 4

Я должен признать, что я не очень хорошо знаком с MS Search Server, поэтому это может не применяться. У меня часто возникали ситуации, когда приложению приходилось искать в сотнях миллионов записей наборы результатов, которые нужно было отсортировать, разбить на страницы и выполнить дополнительный поиск в SQL Server. Обычно я делаю два шага. Сначала я беру первые «х» результаты, которые необходимо отобразить, и отправляю их в браузер для быстрого отображения. Во-вторых, в другом потоке я завершаю полный запрос и перемещаю результаты во временную таблицу, где они могут быть сохранены и получены быстрее. Любой данный запрос может иметь тысячи или десятки тысяч результатов, но по сравнению с сотнями миллионов или даже миллиардами полных записей этим меньшим подмножеством можно очень легко манипулировать из временной таблицы. Это также создает меньшую нагрузку на другие таблицы при выполнении запросов. Если пользователю нужна вторая страница записей, или он должен отсортировать их, или просто хочет подмножество исходного запроса, все это извлекается из временной таблицы.

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

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

Надеюсь, это немного поможет.