Как построить полнотекстовый поиск по 100 млн+ записей?

Question

IT Interview Practice · Accepted Answer

Используйте выделенный поисковый движок — **Elasticsearch/OpenSearch на инвертированном индексе** — питаемый из вашей исходной БД через **CDC**, и шардируйте индекс для масштаба. Ваша основная база (Postgres/MySQL) не умеет ранжированный по релевантности текстовый поиск по сотням миллионов строк; `LIKE '%term%'` сканирует каждую строку. Поисковый движок инвертирует задачу.

```text
Source DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)   (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                     ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter to shards ─▶ gather ─┴─ Shard N ── ranked by BM25
```

## Инвертированный индекс — почему он быстр

Обычный индекс отображает строку → значения. **Инвертированный индекс** отображает *терм → список документов, его содержащих*. Поиск «database scaling» ищет два коротких posting-списка и пересекает их — O(совпавших документов), а не O(всех документов). Именно это делает возможным sub-100ms поиск по 100 млн+ документов. Текст сперва **анализируется**: токенизируется, приводится к нижнему регистру, стеммируется («running» → «run»), стоп-слова отбрасываются — так что запросы находят варианты.

## Приём через CDC

Не делайте dual-write (приложение пишет в БД *и* в ES) — сбой оставит их неконсистентными. Вместо этого стримьте изменения через **Change Data Capture**: **Debezium** читает write-ahead log БД, публикует изменения строк в **Kafka**, а indexer применяет их к Elasticsearch. Это держит поиск **eventually consistent** с источником и переживает простой ES (события переигрываются из Kafka).

## Шардинг и релевантность

Индекс разбит на **шарды** (каждый — самодостаточный Lucene-индекс), распределённые по узлам; **реплики** добавляют throughput чтения и HA. Запрос разлетается по всем шардам, каждый возвращает свой top-k, а координатор мержит. Релевантность по умолчанию использует **BM25** — частота терма × обратная частота документа — настраиваемую бустами, синонимами и весами полей.

## Взгляд с точки зрения интервью

Интервьюеры проверяют, (1) тянетесь ли вы к правильному инструменту вместо `LIKE`, (2) знаете ли, *как* работает инвертированный индекс, и (3) решаете ли **проблему синхронизации** без dual-write. Хорошо: «использовать Elasticsearch». Отлично: вы называете CDC/Debezium для приёма, BM25 для ранжирования и принимаете eventual consistency как компромисс ради масштаба.

**Частая ловушка:** относиться к Elasticsearch как к источнику истины. Это производный индекс — не durable/транзакционный, как ваша БД. Перестраивайте его из источника, когда нужно.

## Компромиссы и режимы отказа

- **Eventual consistency:** поиск отстаёт от записей на latency CDC-пайплайна (обычно доли секунды).
- **Боль ре-индексации:** изменения mapping/анализатора требуют полной ре-индексации — используйте алиасы для zero-downtime переключений.
- **Глубокая пагинация:** страница 10 000 дорога (scatter-gather) — используйте `search_after`, а не `from/size`.
- **Горячий шард / перекос:** неравномерное распределение документов; выбирайте хороший routing-ключ и достаточно шардов заранее (они фиксируются при создании).
- **Настройка релевантности бесконечна:** дефолты BM25 редко совпадают с бизнес-намерением — ожидайте итераций.

Инвертированный индекс — почему он быстр

Приём через CDC

Шардинг и релевантность

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы