Какой опыт работы с базами данных, включая Elasticsearch?

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

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

Как отвечать

Разделите роли. Основная база (чаще всего PostgreSQL через SQLAlchemy или Django ORM) хранит источник истины с транзакциями и ограничениями. Elasticsearch держит производную копию для полнотекстового поиска, фильтров и агрегаций, и её можно пересобрать из основной базы.

Дальше конкретика:

• маппинг: text анализируется и ищется по словам, keyword хранится как есть для фильтров, сортировок и агрегаций. Часто поле держат в обоих видах через multi-fields. Динамический маппинг на проде лучше ограничивать, иначе тип угадывается по первому документу;
• изменение маппинга: тип существующего поля не меняется. Создают новый индекс, переносят данные через _reindex и переключают алиас, поэтому приложение всегда работает через алиас;
• запросы: условия, не влияющие на релевантность, кладите в filter внутри bool: они не считают score и кэшируются;
• загрузка: из Python через helpers.bulk пачками, на время массовой заливки увеличивают refresh_interval. По умолчанию он равен секунде, поэтому документ появляется в поиске не мгновенно;
• пагинация: from и size упираются в index.max_result_window (10 000 по умолчанию), для глубокого обхода нужен search_after с point in time.

Синхронизацию опишите честно: двойная запись из кода, очередь задач или CDC из основной базы. Скажите, как вы переживали рассинхрон и как пересобирали индекс без простоя.

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

Используют Elasticsearch как основное хранилище. Транзакций нет, запись видна не сразу, а при смене маппинга данные всё равно придётся откуда-то переливать.

Ищут полнотекстово по полю keyword или пытаются сортировать по text и удивляются результату.

Делают двойную запись без повторов и сверки: одна из записей падает, и поиск месяцами показывает удалённые товары.