Хранение результата поиска для подкачки страниц и сортировки
Я реализовывал Поисковый сервер MS 2010 и до сих пор его действительно хорошее. Я делаю поисковые запросы через их веб-сервис, но из-за непоследовательных результатов, я думаю о кэшировании результата вместо этого.
Сайт является маленькой интранет (500 сотрудников), таким образом, это не должны быть никакие проблемы, но мне любопытно, что приближается, Вы взяли бы, если бы это был больший сайт.
Я погуглил немного, но действительно не приехал ни через что определенное. Так, несколько вопросов:
- Что другие подходы там? И почему они лучше?
- Какого количества это стоит для хранения представления данных 400-500 строк? Какие размеры выполнимы?
- Другие точки необходимо учесть.
Любой вход приветствуется :)
4 ответа
Чтобы добиться этого, вам нужно использовать множество методов.
Во-первых , вам нужен какой-то уровень сохраняемости. Если вы используете простой старый веб-сайт, то сеанс пользователя будет наиболее логичным для использования уровнем. Если вы используете веб-службы (то есть без сеанса) и просто звоните через клиента, тогда вам все равно нужен какой-то уровень приложения (своего рода общий сеанс) для ваших служб. Почему? Этот слой будет домом для кэша результатов вашей базы данных.
Во-вторых, вам нужен способ кэширования ваших результатов в любом используемом вами контейнере (сеансе или уровне приложения веб-сервисов). Вы можете сделать это двумя способами ... Если запрос - это то, что может сделать любой пользователь, тогда будет работать простой хэш запроса, и вы можете поделиться этим сохраненным результатом между другими пользователями. Вероятно, вам по-прежнему нужен какой-то GUID для результата, чтобы вы могли передать его в своем клиентском приложении, но поиск хэша из запросов к результатам будет полезен. Если эти запросы уникальны, вы можете просто использовать уникальный GUID для результата запроса и передать его клиентскому приложению. Это сделано для того, чтобы вы могли выполнять свои функции кэширования ...
Механизм кеширования может включать в себя какой-то буфер или очередь фиксированной длины ... чтобы старые результаты автоматически очищались / удалялись по мере добавления новых. Затем, если поступает запрос, который является промахом кеша, он будет выполняться в обычном режиме и добавлен в кеш.
В-третьих , вам может понадобиться какой-то способ страницы вашего объекта результата ...шаблон Iterator здесь хорошо работает, хотя, вероятно, может сработать что-то более простое ... например, fetch X количество результатов, начиная с точки Y . Однако шаблон Iterator был бы лучше, так как позже вы могли бы удалить свой механизм кеширования и страницы прямо из базы данных, если хотите.
В-четвертых , вам нужен какой-то механизм упреждающей выборки (как предлагали другие). Вы должны запустить поток, который будет выполнять полный поиск, а в основном потоке просто выполните быстрый поиск с верхним X количеством элементов. Надеюсь, к тому времени, когда пользователь попытается выполнить разбиение на страницы, второй поток будет завершен, и ваш полный результат будет теперь в кеше. Если результат не готов, вы можете просто добавить простую логику экрана загрузки.
Это должно помочь вам ... дайте мне знать, если вам нужны пояснения / подробности по какой-либо конкретной части.
Я оставлю вам еще несколько советов ...
Вы не хотите отправлять весь результат в клиентское приложение (если вы используете Ajax или что-то вроде приложения для iPhone). Почему? Потому что это огромная трата. Пользователь, скорее всего, не будет просматривать все результаты ... теперь вы просто отправили более 2 МБ полей результатов бесплатно.
Javascript - отличный язык, но помните, что это все еще язык сценариев на стороне клиента ... вы не хотите слишком сильно замедлять работу пользователя, отправляя огромные объемы данных для обработки клиентом Ajax. Просто отправьте предварительно выбранный результат вашему клиенту и результаты дополнительных страниц в качестве пользовательских страниц.
Абстракция абстракция абстракция ...вы хотите абстрагироваться от кеша, запросов, разбиения по страницам, предварительной выборки ... как можно больше. Почему? Допустим, вы хотите переключить базы данных или хотите перейти на страницу непосредственно из базы данных вместо использования объекта результата в кеше ... ну, если вы все сделаете правильно, это будет намного проще изменить позже. Кроме того, при использовании веб-служб многие другие приложения могут впоследствии использовать эту логику.
Теперь я, вероятно, предложил изощренное решение для того, что вам нужно :). Но если вы сможете добиться этого, используя все правильные методы, вы многому научитесь и получите очень хорошую базу на случай, если вы захотите расширить функциональность или повторно использовать этот код.
Дайте мне знать, если у вас есть вопросы.
Я должен признать, что я не очень хорошо знаком с MS Search Server, поэтому это может не относиться. У меня часто были ситуации, когда приложению приходилось искать в сотнях миллионов записей наборы результатов, которые нужно было отсортировать, разбить на страницы и выполнить поиск в SQL Server. Обычно я использую двухэтапный подход. Сначала я беру первые результаты «x», которые необходимо отобразить, и отправляю их в браузер для быстрого отображения. Во-вторых, в другом потоке я завершаю полный запрос и перемещаю результаты во временную таблицу, где они могут быть сохранены и получены быстрее. Любой заданный запрос может иметь тысячи или десятки тысяч результатов, но по сравнению с сотнями миллионов или даже миллиардами общих записей этим меньшим подмножеством можно очень легко управлять из временной таблицы. Это также снижает нагрузку на другие таблицы по мере выполнения запросов. Если пользователю нужна вторая страница записей, или нужно их отсортировать, или просто хочет подмножество исходного запроса, все это извлекается из временной таблицы.
Затем необходимо ввести логику для проверки устаревших временных таблиц и их удаления. Это достаточно просто, и я позволяю SQL Server обрабатывать эту функцию. Наконец, необходимо ввести логику при изменении исходного запроса (значительные изменения периметра), чтобы новый набор данных можно было извлечь и поместить в новую временную таблицу для дальнейшего запроса. Все это относительно просто.
Пользователи так привыкли к тому, что время возврата из таких мест, как Google, составляет долю секунды, и эта модель дает мне достаточно гибкости, чтобы действительно достичь этого без необходимости использования специального программного и аппаратного обеспечения, которое они используют.
Надеюсь, это немного поможет.
Ответ Тима - отличный способ справиться с ситуацией, если у вас есть возможность выполнить начальный запрос во втором потоке, а логика (разбиение на страницы / сортировка / фильтрация), применяемая к результатам, требует действий на сервере ..... в противном случае ....
Если вы можете использовать AJAX, набор результатов из 500 строк может быть вызван на страницу и выгружен или отсортирован на клиенте. Это может привести к некоторым действительно интересным функциям ... ознакомьтесь с решениями datagrid от jQueryUI и Dojo для вдохновения!
А для действительно интенсивных функций, таких как произвольные фильтры регулярных выражений и изменение порядка столбцов с помощью перетаскивания, вы можете полностью освободить сервер.
Одновременная загрузка данных в браузер также позволяет вам вызывать вспомогательные данные (предварительный просмотр страниц и т. Д.), Когда пользователь «запрашивает» их ....
Основная проблема заключается в ограничении данных, которые вы возвращаете для каждого результата, до что вы на самом деле будете использовать для сортировки и фильтрации.
Возможности безграничны :)
Похоже, что медленной частью поиска является полнотекстовый поиск, а не получение результатов. Как насчет кеширования идентификаторов результирующих записей ресурсов? Кроме того, поскольку может быть правдой, что поисковые запросы часто дублируются, сохраните хэш поискового запроса, запроса и соответствующих ресурсов. Затем вы можете получить следующую страницу результатов по идентификатору. Также работает с AJAX.
Поскольку это интрасеть, и вы можете управлять поисковыми ресурсами, вы даже можете предварительно вычислить соответствие нового или обновленного ресурса популярным запросам во время простоя.