jasonOk
@jasonOk
Легче болтать, чем код писать

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

На сайте есть гибкий ajax поиск, можно слайдером настраивать цену, от какой до какой, искать по категориям, теги 20+, ещё несколько дополнительных параметров и, конечно, поиск по запросу.
Так назревает вопрос — как всё это дело оптимизировать? Сохранять каждый отдельный запрос в БД или кэшировать с помощью redis?
Параметров поиска много, пользователь поменяет всего один, и результат кардинально изменится. Дело даже не в том, что запросы сложные, нет, проблема заключается в частых обращениях к серверу.
Как решаются подобные проблемы в серьёзных проектах?
  • Вопрос задан
  • 1261 просмотр
Пригласить эксперта
Ответы на вопрос 3
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Как решаются подобные проблемы в серьёзных проектах?


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

Частично эту проблему можно решить HTTP кешированием. То есть все парамеры поиска ходят в queryString а значит по одному URI мы можем иметь нужную страницу/данные. Однако вармат такого кэша будет занимать много времени, а сложность инвалидации будет так высока, что нужно 10 раз подумать прежде чем решаться на такое.
Ответ написан
xmoonlight
@xmoonlight Куратор тега PHP
https://sitecoder.blogspot.com
Поиск делится на 2 вида: статический (поиск по чёткому совпадению) и динамический (поиск по нечёткому совпадению).
Выполняем в 2 этапа:
1. Сначала - выполняйте поиск по четкому совпадению, (int,boolean) =>
[список параметров: int,bool & etc.]=>ID:кэш1
2. Затем из этого списка - ищите по нечёткому (varchar). =>
varchar +ID:кэш1=>ID:кэш2
Теперь если текстовый поисковый запрос не менялся, а менялись только настройки - поиск выполняется через обратный реверсивный поиск и если такую комбинацию уже кто-то искал (она есть в кэше1), то результат будет практически моментально получен.

Можно сформировать клиентскую выборку (кэш-таблицу), исключив только что изменённый параметр из кэша1 (но сохранив строку поиска) и вынести результат выборки на клиент, чтобы в дальнейшем (если пользователь будет двигать "ползунок" цены, к примеру, не меняя поисковый запрос), искать уже локально на самом клиенте без запроса на сервер.
Ответ написан
@ComodoHacker
В серьезных проектах делают поиск in-memory. Sphinx, Elastic Search и т.п.
Ну и сервер ставят такой, для которого частые обращения не проблема.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
SaveTime Москва
от 160 000 ₽
Farpost Владивосток
от 100 000 до 160 000 ₽
Cloud4Y Ярославль
от 65 000 до 130 000 ₽
25 февр. 2020, в 13:06
2000 руб./за проект
25 февр. 2020, в 12:59
50000 руб./за проект
25 февр. 2020, в 12:51
2000 руб./за проект