Hvordan bygger du fuldtekstsøgning over 100M+ records?

Question

IT Interview Practice · Accepted Answer

Brug en dedikeret search engine — **Elasticsearch/OpenSearch bygget på et inverted index** — fodret fra din source-DB via **CDC**, og shard index'et for skala. Din primære database (Postgres/MySQL) kan ikke lave relevans-rangeret tekstsøgning over hundreder af millioner rows; et `LIKE '%term%'` scanner hver row. En search engine vender problemet om.

```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 — hvorfor det er hurtigt

Et normalt index mapper row → værdier. Et **inverted index** mapper *term → liste af dokumenter der indeholder det*. At søge "database scaling" slår to korte posting lists op og skærer dem — O(matchende docs), ikke O(alle docs). Dette er, hvad der gør sub-100ms søgning over 100M+ dokumenter mulig. Tekst **analyseres** først: tokeniseret, small-cased, stemmet ("running" → "run"), stopwords droppet — så forespørgsler matcher varianter.

## Ingestion via CDC

Dual-write ikke (app skriver DB *og* ES) — en fejl efterlader dem inkonsistente. I stedet, stream ændringer med **Change Data Capture**: **Debezium** haler DB'ens write-ahead log, publicerer row-ændringer til **Kafka**, og en indexer anvender dem på Elasticsearch. Dette holder søgning **eventually consistent** med kilden og overlever ES-nedetid (events replayer fra Kafka).

## Sharding & relevans

Index'et er splittet i **shards** (hver et selvstændigt Lucene-index), spredt over noder; **replicas** tilføjer read-throughput og HA. En forespørgsel scatterer til alle shards, hver returnerer sin top-k, og coordinatoren merger. Relevans bruger **BM25** som standard — term frequency × inverse document frequency — indstillelig med boosts, synonymer og feltvægte.

## Interview-perspektiv

Interviewere tjekker, om du (1) griber efter det rette værktøj i stedet for `LIKE`, (2) ved *hvordan* det inverted index virker, og (3) løser **sync-problemet** uden dual-writes. Godt: "brug Elasticsearch." Fremragende: du navngiver CDC/Debezium til ingestion, BM25 til ranking, og accepterer eventual consistency som trade-off'et for skala.

**Almindelig fælde:** at behandle Elasticsearch som din kilde til sandhed. Det er et afledt index — ikke holdbart/transaktionelt som din DB. Genopbyg det fra kilden efter behov.

## Trade-offs & fejlmåder

- **Eventual consistency:** søgning sakker bag writes med CDC-pipelinens latency (som regel sub-sekund).
- **Reindex-smerte:** mapping/analyzer-ændringer kræver en fuld reindex — brug aliases til zero-downtime swaps.
- **Dyb paginering:** side 10.000 er dyr (scatter-gather) — brug `search_after`, ikke `from/size`.
- **Hot shard / skew:** ujævn doc-fordeling; vælg en god routing key og nok shards på forhånd (de er faste ved oprettelse).
- **Relevance tuning er løbende:** BM25-defaults matcher sjældent forretningsintention — forvent iteration.

Inverted index — hvorfor det er hurtigt

Ingestion via CDC

Sharding & relevans

Interview-perspektiv

Trade-offs & fejlmåder

Relaterede spørgsmål