Комплексное поисковое решение - PullRequest
1 голос
/ 07 декабря 2010

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

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

  1. Отправить форму поиска
  2. Внутренне я запускаю каждый фильтр и логику поэтапно (это может занять несколько секунд)
  3. После того, как я найду все подходящие записи (результат, который мне нужен), я создаю запись в своей таблице searches, генерирующую токен этого поиска (на основе параметров поиска), такой как 86f7e437faa5 , и сохраняю все соответствующие записи идентификаторы
  4. Перенаправить посетителя на страницу, похожую на mysite.com/search?token=86f7e437faa5

И на странице результатов мне нужно только выяснить, о каком поиске я говорю, и пролистать идентификаторы результатов (полученные из таблицы searches).

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

Я никогда не видел учебник или что-то подобное, но я думаю, что некоторые форумы, такие как BBForum или Invision, занимаются поиском, верно? После поиска я перенаправляюсь на что-то вроде search.php? Id = 1231 (я не вижу параметры поиска в URL или в аргументах POST).

Этот «токен» не будет длиться дольше 30 минут ~ 1 ч. Так что «статический поиск» только из соображений производительности.

Что вы думаете об этом? Это сработает? Есть соображения? :)

Ответы [ 4 ]

2 голосов
/ 07 декабря 2010

Ваша система может иметь специальный токен, такой как 86f7e437faa5, и запросы кеша поиска. Это очень полезный механизм для повышения эффективности и масштабируемости системы.

Но пользователь должен просмотреть все параметры в соответствии с принципами юзабилити.

Таким образом, создание хэша параметров на лету на стороне сервера будет хорошим решением. Система проверяет наличие сгенерированного хэша в таблице поиска и возвращает результат, если найден. Если хеш отсутствует, система выполняет запрос из базовых таблиц и сохраняет новый результат в таблице поиска.

1 голос
/ 07 декабря 2010

Мне кажется достаточно логичным.

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

Так что, как и в вашей ситуации, Sphinx может очень быстро дать вам ваш набор идентификаторов, поскольку вся тяжелая работа былапредварительно сделано.

0 голосов
/ 07 декабря 2010

Sphinx кажется хорошим решением, если у вас есть контроль над вашим сервером (например, в VPS).

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

0 голосов
/ 07 декабря 2010

TiuTalk,

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

Я бы предпочел основывать токен на сеансе пользователя. Что ты думаешь?

@ g0nc1n

...