Come costruisci una ricerca full-text su 100M+ di record?

Question

IT Interview Practice · Accepted Answer

Usa un motore di ricerca dedicato — **Elasticsearch/OpenSearch costruito su un inverted index** — alimentato dal tuo DB sorgente via **CDC**, e fai sharding dell'index per la scala. Il tuo database primario (Postgres/MySQL) non può fare ricerca testuale ordinata per rilevanza su centinaia di milioni di righe; un `LIKE '%term%'` fa lo scan di ogni riga. Un motore di ricerca inverte il 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
```

## Inverted index — perché è veloce

Un index normale mappa riga → valori. Un **inverted index** mappa *termine → lista di documenti che lo contengono*. Cercare "database scaling" consulta due brevi posting list e le interseca — O(documenti corrispondenti), non O(tutti i documenti). È questo a rendere possibile una ricerca sotto i 100ms su 100M+ di documenti. Il testo viene prima **analizzato**: tokenizzato, portato in minuscolo, stemmizzato ("running" → "run"), le stopword scartate — così le query corrispondono alle varianti.

## Ingestione via CDC

Non fare dual-write (l'app scrive sul DB *e* su ES) — un fallimento li lascia inconsistenti. Invece, fai streaming dei cambiamenti con **Change Data Capture**: **Debezium** segue il write-ahead log del DB, pubblica i cambiamenti di riga su **Kafka**, e un indexer li applica a Elasticsearch. Questo mantiene la ricerca **eventualmente consistente** con la sorgente e sopravvive ai downtime di ES (gli eventi vengono ripetuti da Kafka).

## Sharding e rilevanza

L'index è suddiviso in **shard** (ognuno un index Lucene autonomo), distribuiti su più nodi; le **replica** aggiungono throughput di lettura e HA. Una query fa scatter su tutti gli shard, ciascuno restituisce i suoi top-k, e il coordinator li unisce. La rilevanza usa **BM25** di default — frequenza del termine × inverse document frequency — regolabile con boost, sinonimi e pesi dei campi.

## Prospettiva del colloquio

Gli intervistatori verificano se (1) ricorri allo strumento giusto invece di `LIKE`, (2) sai *come* funziona l'inverted index, e (3) risolvi il **problema di sincronizzazione** senza dual-write. Buono: "usa Elasticsearch." Eccellente: nomini CDC/Debezium per l'ingestione, BM25 per il ranking, e accetti la consistenza eventuale come compromesso per la scala.

**Trappola comune:** trattare Elasticsearch come tua fonte di verità. È un index derivato — non durevole/transazionale come il tuo DB. Ricostruiscilo dalla sorgente quando serve.

## Compromessi e modalità di guasto

- **Consistenza eventuale:** la ricerca è indietro rispetto alle scritture della latenza della pipeline CDC (di solito sotto il secondo).
- **Dolore di reindex:** i cambi di mapping/analyzer richiedono un reindex completo — usa gli alias per swap senza downtime.
- **Deep pagination:** la pagina 10.000 è costosa (scatter-gather) — usa `search_after`, non `from/size`.
- **Shard caldo / skew:** distribuzione non uniforme dei documenti; scegli una buona routing key e abbastanza shard fin dall'inizio (sono fissati alla creazione).
- **Il tuning della rilevanza è continuo:** i default di BM25 raramente coincidono con l'intento di business — aspettati iterazione.

Inverted index — perché è veloce

Ingestione via CDC

Sharding e rilevanza

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate