Используете ли Elasticsearch для поиска

Что проверяют

Был ли у вас реальный опыт с поисковым движком и понимаете ли вы, что Elasticsearch стоит рядом с основной базой, а не вместо неё. Следом спрашивают, как данные попадают в индекс и что делать с устаревшими результатами.

Как отвечать

Если использовали, расскажите по порядку на примере своего проекта:

• зачем: полнотекстовый поиск с морфологией и релевантностью, фасеты через агрегации, логи вместе с Kibana. Если данных немного, упомяните, что рассматривали полнотекстовый поиск PostgreSQL (tsvector и индекс GIN);
• маппинг: поле text проходит через анализатор и режется на токены, keyword хранится как есть для фильтров и сортировки. Для русского нужен анализатор russian или морфология через плагин;
• запросы: match для текста, term для точных значений, bool с must и filter. Фильтры не влияют на оценку и хорошо кешируются, релевантность по умолчанию считается по BM25;
• синхронизация: источник правды остаётся в основной базе. Данные доезжают через outbox и фоновый обработчик, через CDC вроде Debezium или периодической переиндексацией. Индекс обновляется примерно раз в секунду, поэтому свежая запись видна не сразу;
• переиндексация: новый индекс строится рядом, потом алиас переключается без простоя.

Про клиент для C#: NEST относится к линейке 7.x, для 8.x и новее используют Elastic.Clients.Elasticsearch. Если проект сидит на OpenSearch, клиент свой, OpenSearch.Client.

Если опыта нет, так и скажите и объясните, как подошли бы к задаче: где источник правды, как синхронизировать, какие поля текстовые.

Где спотыкаются

Используют Elasticsearch как основную базу. Транзакций между документами нет, и при сбое синхронизации восстановить данные неоткуда.

Ищут term по полю text и ничего не находят: в индексе лежат токены в нижнем регистре, а не исходная строка.

Делают глубокую пагинацию через from и size. По умолчанию дальше 10 000 документов не пустит index.max_result_window, для таких случаев есть search_after с point in time.