Стратегия кеширования InstantSearch - PullRequest
1 голос
/ 21 апреля 2020

Я хотел бы реализовать быстрый, плавный поиск. Количество найденных предметов не так много: ~ 100 макс. Каждый элемент содержит количество данных, которое будет содержать событие facebook. Все они будут отображаться при начальной загрузке (возможно, бесконечный свиток). Данные не будут часто меняться. Не более 100 одновременно работающих пользователей.

Какова наилучшая стратегия кэширования результатов поиска при указанных выше условиях?

Какая стратегия наиболее масштабируема?

Stack

  • Внешний интерфейс: Nuxt (VueJS) + InstantSearch (без Algolia!)
  • Бэкэнд: Spring boot
  • Dockerized

Возможные решения

  1. Дополнительная служба кэширования на бэкэнде (например, reddis, memcached) + сделать UI go для разрыва на каждой поисковой операции. В основном это будет спамить серверную часть при каждом нажатии клавиши
  2. Загружать все элементы в локальное хранилище (например, Vuex ) и искать там напрямую. Это увеличит объем памяти приложения и может привести к беспорядочной сверхурочной работе.
  3. Комбинация из двух?

1 Ответ

2 голосов
/ 21 апреля 2020

Уровень кеша определенно не повредит. Количество пользователей не должно быть проблемой. Даже самый маленький экземпляр ec2 на aws может справиться с этим легко.

Вы можете попытаться добавить небольшую задержку в текстовое поле, чтобы не каждое нажатие клавиши запускало поиск, но, возможно, давало задержку ~ 50 мс? Попробуй посмотреть, каково это при наборе текста на панели поиска.

Для 100 элементов Vuex тоже может работать довольно быстро, если вы не загружаете stati c активы, например изображения, непосредственно в Vuex. ~ 100 элементов в JSON данных - это не много, но они также не масштабируются, если в вашем приложении неожиданно появилось 10000 элементов.

Лучший на мой взгляд сценарий:

  • Redis кеш, потому что многие запросы будут очень похожи или даже идентичны. Вам просто нужно найти точку отсчета в том, как долго действует кеш
  • Балансировка нагрузки вашего бэкэнда и внешнего интерфейса, т. Е. Создание большего количества экземпляров вашего docker -изображения по требованию для обработки потенциальных пиков в запросах, если ЦП -usage превышает определенный порог
  • Если ваш бэкэнд выполняет больше, чем просто поиск, перенесите этот поиск на выделенный экземпляр, чтобы он не мешал «обычным запросам»
  • Очень важно: Создавайте индексы в своей базе данных для более быстрых результатов поиска, избегайте полного сканирования везде, где сможете!
  • Возможно, подумайте о том, чтобы отключиться от сервера, если в вашем приложении нет traffi c 24/7

Редактировать: - иметь api, кеш и базу данных рядом друг с другом, чтобы связь между экземплярами не проходила далеко.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...