Hvordan bygger du full-text search over 100M+ poster?

Question

IT Interview Practice · Accepted Answer

Bruk en dedikert søkemotor — **Elasticsearch/OpenSearch bygd på en inverted index** — matet fra kilde-DB-en din via **CDC**, og shard indeksen for skala. Din primære database (Postgres/MySQL) kan ikke gjøre relevans-rangert tekstsøk over hundrevis av millioner rader; en `LIKE '%term%'` skanner hver rad. En søkemotor inverterer problemet.

```text
Kilde-DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)  (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                    ├─ Shard 1
Spørring ─▶ Coordinator ─▶ scatter til shards ─▶ gather ─┴─ Shard N ── rangert på BM25
```

## Inverted index — hvorfor det er raskt

En normal indeks mapper rad → verdier. En **inverted index** mapper *term → liste over dokumenter som inneholder den*. Å søke "database scaling" slår opp to korte posting-lister og skjærer dem — O(matchende dokumenter), ikke O(alle dokumenter). Dette er det som gjør under-100ms søk over 100M+ dokumenter mulig. Tekst blir **analysert** først: tokenisert, lowercase-et, stemmet ("running" → "run"), stoppord droppet — slik at spørringer matcher varianter.

## Ingestion via CDC

Ikke dual-write (app skriver DB *og* ES) — en feil etterlater dem inkonsistente. I stedet, stream endringer med **Change Data Capture**: **Debezium** tailer DB-ens write-ahead log, publiserer rad-endringer til **Kafka**, og en indexer applikerer dem til Elasticsearch. Dette holder søk **eventually consistent** med kilden og overlever ES-nedetid (events replayes fra Kafka).

## Sharding og relevans

Indeksen deles i **shards** (hver en selvstendig Lucene-indeks), spredt over noder; **replicas** legger til lese-throughput og HA. En spørring scatter-er til alle shards, hver returnerer sin top-k, og coordinatoren merger. Relevans bruker **BM25** som standard — term frequency × inverse document frequency — justerbar med boosts, synonymer og feltvekter.

## Intervjuperspektiv

Intervjuere sjekker om du (1) griper til riktig verktøy i stedet for `LIKE`, (2) vet *hvordan* inverted index fungerer, og (3) løser **sync-problemet** uten dual-writes. Bra: "bruk Elasticsearch." Utmerket: du navngir CDC/Debezium for ingestion, BM25 for rangering, og aksepterer eventual consistency som avveiningen for skala.

**Vanlig felle:** å behandle Elasticsearch som sannhetskilden din. Det er en avledet indeks — ikke varig/transaksjonell som DB-en din. Gjenoppbygg den fra kilden ved behov.

## Avveininger og feilmoduser

- **Eventual consistency:** søk henger etter writes med CDC-pipeline-latency (vanligvis under sekundet).
- **Reindex-smerte:** mapping/analyzer-endringer trenger en full reindex — bruk aliaser for zero-downtime bytter.
- **Deep pagination:** side 10 000 er dyr (scatter-gather) — bruk `search_after`, ikke `from/size`.
- **Hot shard / skjevhet:** ujevn dokumentdistribusjon; velg en god routing-nøkkel og nok shards på forhånd (de er faste ved opprettelse).
- **Relevanstuning er kontinuerlig:** BM25-standarder matcher sjelden forretningsintensjon — forvent iterasjon.

Inverted index — hvorfor det er raskt

Ingestion via CDC

Sharding og relevans

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål