Jak postavíte full-text vyhledávání nad 100M+ záznamy?

Question

IT Interview Practice · Accepted Answer

Použijte dedikovaný vyhledávací engine — **Elasticsearch/OpenSearch postavený na invertovaném indexu** — plněný ze zdrojové DB přes **CDC** a index shardujte kvůli škálování. Vaše primární databáze (Postgres/MySQL) neumí relevance-ranked textové vyhledávání nad stovkami milionů řádků; `LIKE '%term%'` skenuje každý řádek. Vyhledávací engine problém invertuje.

```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
```

## Invertovaný index — proč je rychlý

Normální index mapuje řádek → hodnoty. **Invertovaný index** mapuje *term → seznam dokumentů, které ho obsahují*. Hledání „database scaling“ vyhledá dva krátké posting listy a protne je — O(odpovídající dokumenty), ne O(všechny dokumenty). To je to, co činí sub-100ms vyhledávání nad 100M+ dokumenty možným. Text se nejprve **analyzuje**: tokenizuje, převede na malá písmena, stemuje („running“ → „run“), stopwords se zahodí — takže dotazy odpovídají variantám.

## Ingestion přes CDC

Nepoužívejte dual-write (aplikace zapisuje do DB *a* ES) — selhání je nechá nekonzistentní. Místo toho streamujte změny přes **Change Data Capture**: **Debezium** čte write-ahead log databáze, publikuje změny řádků do **Kafky** a indexer je aplikuje do Elasticsearch. Tím udrží vyhledávání **eventually consistent** se zdrojem a přežije výpadek ES (události se přehrají z Kafky).

## Sharding & relevance

Index je rozdělen na **shardy** (každý samostatný Lucene index), rozprostřené napříč nodes; **repliky** přidávají read throughput a HA. Dotaz se rozvětví na všechny shardy, každý vrátí své top-k a koordinátor je slévá. Relevance ve výchozím stavu používá **BM25** — term frequency × inverse document frequency — laditelné boosty, synonymy a váhami polí.

## Pohled z pohovoru

Tazatelé ověřují, zda (1) sáhnete po správném nástroji místo `LIKE`, (2) víte, *jak* invertovaný index funguje, a (3) vyřešíte **problém synchronizace** bez dual-writes. Dobré: „použij Elasticsearch.“ Skvělé: pojmenujete CDC/Debezium pro ingestion, BM25 pro řazení a akceptujete eventual consistency jako kompromis za měřítko.

**Častá past:** brát Elasticsearch jako zdroj pravdy. Je to odvozený index — ne trvanlivý/transakční jako vaše DB. V případě potřeby ho ze zdroje přebudujte.

## Kompromisy a režimy selhání

- **Eventual consistency:** vyhledávání zaostává za zápisy o latenci CDC pipeline (obvykle sub-sekunda).
- **Bolest reindexace:** změny mappingu/analyzeru vyžadují plnou reindexaci — použijte aliasy pro zero-downtime swapy.
- **Hluboká stránkování:** stránka 10 000 je drahá (scatter-gather) — použijte `search_after`, ne `from/size`.
- **Hot shard / skew:** nerovnoměrné rozložení dokumentů; volte dobrý routing key a dost shardů dopředu (jsou pevné při vytvoření).
- **Ladění relevance je nekonečné:** výchozí BM25 zřídka odpovídá byznysovému záměru — počítejte s iterací.

Invertovaný index — proč je rychlý

Ingestion přes CDC

Sharding & relevance

Pohled z pohovoru

Kompromisy a režimy selhání

Související otázky