Как реализуется кэширование поиска?

Question

[jasonOk]

На сайте есть гибкий ajax поиск, можно слайдером настраивать цену, от какой до какой, искать по категориям, теги 20+, ещё несколько дополнительных параметров и, конечно, поиск по запросу.
Так назревает вопрос — как всё это дело оптимизировать? Сохранять каждый отдельный запрос в БД или кэшировать с помощью redis?
Параметров поиска много, пользователь поменяет всего один, и результат кардинально изменится. Дело даже не в том, что запросы сложные, нет, проблема заключается в частых обращениях к серверу.
Как решаются подобные проблемы в серьёзных проектах?

Answer 1

[Сергей Протько]

Как решаются подобные проблемы в серьёзных проектах?

Никак. Оптимизируют сам поиск, используя денормализацию данных что бы максимально упростить поиск и сделать его как можно менее напряжным для сервера. Ну и что бы "сократить" количество запросов используют "приемы" вроде throttle/debounce на клиенте, что бы не на каждый кник мышкой слать запрос, а когда пользователь не проявлял активности, к примеру секунду.

Частично эту проблему можно решить HTTP кешированием. То есть все парамеры поиска ходят в queryString а значит по одному URI мы можем иметь нужную страницу/данные. Однако вармат такого кэша будет занимать много времени, а сложность инвалидации будет так высока, что нужно 10 раз подумать прежде чем решаться на такое.

Comments

[Philipp]

Немного дополню Сергея, т.к. его ответ правильный. Обычно используются NoSQL решения, вроде Solr, на котором реализуется фасеточный поиск. Вот самый простой пример такого https://lucidworks.com/blog/2009/09/02/faceted-sea...

Answer 2

[xmoonlight]

Поиск делится на 2 вида: статический (поиск по чёткому совпадению) и динамический (поиск по нечёткому совпадению).
Выполняем в 2 этапа:
1. Сначала - выполняйте поиск по четкому совпадению, (int,boolean) =>
[список параметров: int,bool & etc.]=>ID:кэш1
2. Затем из этого списка - ищите по нечёткому (varchar). =>
varchar +ID:кэш1=>ID:кэш2
Теперь если текстовый поисковый запрос не менялся, а менялись только настройки - поиск выполняется через обратный реверсивный поиск и если такую комбинацию уже кто-то искал (она есть в кэше1), то результат будет практически моментально получен.

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

Answer 3

[ComodoHacker]

В серьезных проектах делают поиск in-memory. Sphinx, Elastic Search и т.п.
Ну и сервер ставят такой, для которого частые обращения не проблема.