Cum construiești căutare full-text peste 100M+ de înregistrări?

Question

IT Interview Practice · Accepted Answer

Folosește un motor de căutare dedicat — **Elasticsearch/OpenSearch construit pe un index inversat** — alimentat din DB-ul sursă prin **CDC**, și fă sharding pe index pentru scară. Baza ta de date primară (Postgres/MySQL) nu poate face căutare de text ordonată după relevanță peste sute de milioane de rânduri; un `LIKE '%term%'` scanează fiecare rând. Un motor de căutare inversează problema.

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

## Index inversat — de ce este rapid

Un index normal mapează rând → valori. Un **index inversat** mapează *termen → lista documentelor care îl conțin*. Căutarea "database scaling" caută două posting list-uri scurte și le intersectează — O(documente care se potrivesc), nu O(toate documentele). Asta face posibilă căutarea sub-100ms peste 100M+ de documente. Textul este mai întâi **analizat**: tokenizat, transformat în litere mici, redus la rădăcină ("running" → "run"), stopwords eliminate — astfel încât interogările să se potrivească cu variantele.

## Ingestie prin CDC

Nu face dual-write (aplicația scrie în DB *și* în ES) — un eșec le lasă inconsistente. În schimb, transmite modificările prin **Change Data Capture**: **Debezium** urmărește write-ahead log-ul DB-ului, publică modificările de rânduri în **Kafka**, iar un indexer le aplică în Elasticsearch. Asta menține căutarea **eventual consistentă** cu sursa și supraviețuiește căderilor ES (evenimentele fac replay din Kafka).

## Sharding și relevanță

Indexul este împărțit în **shard-uri** (fiecare un index Lucene de sine stătător), distribuite pe noduri; **replicile** adaugă throughput de citire și HA. O interogare se distribuie (scatters) pe toate shard-urile, fiecare returnează top-k-ul său, iar coordonatorul face merge. Relevanța folosește implicit **BM25** — frecvența termenului × frecvența inversă în documente — reglabilă cu boost-uri, sinonime și ponderi de câmp.

## Perspectiva de interviu

Intervievatorii verifică dacă (1) apelezi la unealta potrivită în loc de `LIKE`, (2) știi *cum* funcționează indexul inversat și (3) rezolvi **problema de sincronizare** fără dual-writes. Bine: "folosește Elasticsearch." Excelent: numești CDC/Debezium pentru ingestie, BM25 pentru ranking și accepți consistența eventuală ca fiind compromisul pentru scară.

**Capcană obișnuită:** a trata Elasticsearch ca sursa ta de adevăr. Este un index derivat — nu durabil/tranzacțional precum DB-ul tău. Reconstruiește-l din sursă când e nevoie.

## Compromisuri și moduri de eșec

- **Consistență eventuală:** căutarea este în urma scrierilor cu latența pipeline-ului CDC (de obicei sub-secundă).
- **Durerea reindexării:** modificările de mapping/analyzer necesită un reindex complet — folosește alias-uri pentru swap-uri zero-downtime.
- **Paginare adâncă:** pagina 10.000 este costisitoare (scatter-gather) — folosește `search_after`, nu `from/size`.
- **Shard fierbinte / dezechilibru:** distribuție inegală a documentelor; alege o cheie de routing bună și suficiente shard-uri din start (sunt fixe la creare).
- **Reglarea relevanței este continuă:** valorile implicite BM25 rareori se potrivesc cu intenția de business — așteaptă-te la iterații.

Index inversat — de ce este rapid

Ingestie prin CDC

Sharding și relevanță

Perspectiva de interviu

Compromisuri și moduri de eșec

Întrebări conexe