Что верно про использование поисковой системы в архитектуре backend-сервиса?
- Как правильно встроить поиск в бэкенд?
Поисковый индекс — производная модель чтения с согласованностью в конечном счёте: источник истины — база, индекс наполняется событиями или CDC.
- Query — с оценкой релевантности; filter — без оценки, кэшируется и быстрее
- Переиндексация — в новый индекс с переключением алиаса
- Документ денормализован под поиск
А ещё Задержка индексации ~1 с — интерфейс не должен ждать мгновенного появления
Подробно
Держать поисковую систему источником истины опасно: у неё нет транзакций и ограничений целостности, а при сбое или смене схемы индекс переиндексируют — что возможно, только если данные лежат где-то ещё. Поэтому стандартная схема такая: основная база хранит данные, а индекс наполняется событиями или через захват изменений. Разделение контекстов даёт практический выигрыш: условия, отвечающие на вопрос «да или нет» (диапазон дат, статус, категория), помещают в filter, где не считается оценка и результат кэшируется, а собственно текстовый поиск оставляют в query. И обязательно закладывайте задержку появления документа в поиске в пользовательский сценарий.
Что хотят услышать
- Роль модели чтения и итоговая согласованность.
- Разница query и filter.
- Переиндексация без простоя.
Частые ошибки
- Делать поисковый индекс единственным местом хранения данных.
- Класть все условия в query context и терять кэширование фильтров.
Проверьте себя
Несколько верных вариантов. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Источник истины — основная база, а поисковый индекс можно перестроить
- ✓Filter context не считает релевантность и кэшируется, query context — считает
- ✓Изменения видны поиску не сразу — согласованность в конечном счёте
- ✗Поисковый движок даёт такие же транзакционные гарантии, как реляционная СУБД, включая откат
Что спросят дальше
- Как обычно наполняют поисковый индекс из основной базы?
- Что делать, если пользователю нужно сразу увидеть только что созданный документ?
Разбор темы
- Полнотекстовый поиск (Elasticsearch)
Почему LIKE не поиск, инвертированный индекс, анализаторы, релевантность BM25, query vs filter context и поиск как read model.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.