Hur bygger du fulltextsökning över 100M+ poster?

Question

IT Interview Practice · Accepted Answer

Använd en dedikerad sökmotor — **Elasticsearch/OpenSearch byggd på ett inverted index** — matad från din käll-DB via **CDC**, och sharda indexet för skala. Din primära databas (Postgres/MySQL) kan inte göra relevansrankad textsökning över hundratals miljoner rader; en `LIKE '%term%'` scannar varje rad. En sökmotor inverterar problemet.

```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 — varför det är snabbt

Ett normalt index mappar rad → värden. Ett **inverted index** mappar *term → lista av dokument som innehåller den*. Att söka "database scaling" slår upp två korta posting lists och snittar dem — O(matchande dokument), inte O(alla dokument). Detta är vad som gör sub-100ms-sökning över 100M+ dokument möjlig. Text **analyseras** först: tokeniseras, gemener, stemmas ("running" → "run"), stopwords släpps — så att frågor matchar varianter.

## Ingestion via CDC

Dubbelskriv inte (appen skriver DB *och* ES) — ett fel lämnar dem inkonsistenta. Strömma istället ändringar med **Change Data Capture**: **Debezium** följer DB:ns write-ahead log, publicerar radändringar till **Kafka**, och en indexer applicerar dem på Elasticsearch. Detta håller sökningen **eventually consistent** med källan och överlever ES-avbrott (händelser replayas från Kafka).

## Sharding & relevans

Indexet delas i **shards** (var och en ett fristående Lucene-index), spritt över noder; **replicas** lägger till läs-throughput och HA. En fråga scattrar till alla shards, var och en returnerar sin top-k, och koordinatorn slår ihop. Relevans använder **BM25** som standard — term frequency × inverse document frequency — justerbar med boosts, synonymer och fältvikter.

## Intervjuperspektiv

Intervjuare kontrollerar om du (1) griper efter rätt verktyg istället för `LIKE`, (2) vet *hur* det inverted index fungerar, och (3) löser **synkroniseringsproblemet** utan dubbelskrivningar. Bra: "använd Elasticsearch." Utmärkt: du namnger CDC/Debezium för ingestion, BM25 för rankning, och accepterar eventual consistency som avvägningen för skala.

**Vanlig fälla:** att behandla Elasticsearch som din source of truth. Det är ett härlett index — inte hållbart/transaktionellt som din DB. Bygg om det från källan vid behov.

## Avvägningar & felmoder

- **Eventual consistency:** sökning ligger efter skrivningar med CDC-pipelinens latens (vanligtvis sub-sekund).
- **Reindex-smärta:** mapping/analyzer-ändringar behöver en full reindex — använd aliases för swaps utan nedtid.
- **Djup paginering:** sida 10 000 är dyr (scatter-gather) — använd `search_after`, inte `from/size`.
- **Het shard / skevhet:** ojämn dokumentfördelning; välj en bra routing key och tillräckligt med shards i förväg (de är fasta vid skapande).
- **Relevansjustering är pågående:** BM25-standarder matchar sällan affärsavsikt — förvänta iteration.

Inverted index — varför det är snabbt

Ingestion via CDC

Sharding & relevans

Intervjuperspektiv

Avvägningar & felmoder

Relaterade frågor