Wie baust du eine Volltextsuche über 100 Mio.+ Datensätze?

Question

IT Interview Practice · Accepted Answer

Nutze eine dedizierte Suchmaschine - **Elasticsearch/OpenSearch, aufgebaut auf einem Inverted Index** - gespeist aus deiner Quell-DB über **CDC**, und sharde den Index für Skalierung. Deine primäre Datenbank (Postgres/MySQL) kann keine relevanz-gerankte Textsuche über hunderte Millionen Rows leisten; ein `LIKE '%term%'` scannt jede Row. Eine Suchmaschine kehrt das Problem um.

```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 - warum er schnell ist

Ein normaler Index mappt Row → Werte. Ein **Inverted Index** mappt *Term → Liste der Dokumente, die ihn enthalten*. Die Suche nach "database scaling" schlägt zwei kurze Posting-Listen nach und schneidet sie - O(passende Docs), nicht O(alle Docs). Das macht Sub-100ms-Suche über 100M+ Dokumente möglich. Text wird zuvor **analysiert**: tokenisiert, kleingeschrieben, gestemmt ("running" → "run"), Stoppwörter verworfen - damit Queries Varianten matchen.

## Ingestion über CDC

Kein Dual-Write (App schreibt DB *und* ES) - ein Fehler lässt sie inkonsistent zurück. Streame stattdessen Änderungen mit **Change Data Capture**: **Debezium** liest das Write-Ahead-Log der DB, publiziert Row-Änderungen an **Kafka**, und ein Indexer wendet sie auf Elasticsearch an. Das hält die Suche **eventually consistent** mit der Quelle und übersteht ES-Ausfälle (Events werden aus Kafka neu abgespielt).

## Sharding & Relevanz

Der Index wird in **Shards** (jeder ein eigenständiger Lucene-Index) über Nodes verteilt; **Replicas** ergänzen Read-Throughput und HA. Eine Query fächert an alle Shards aus, jeder liefert seine Top-k, und der Coordinator merged. Relevanz nutzt standardmäßig **BM25** - Term Frequency × Inverse Document Frequency - abstimmbar mit Boosts, Synonymen und Feldgewichten.

## Interview-Perspektive

Interviewer prüfen, ob du (1) zum richtigen Werkzeug statt zu `LIKE` greifst, (2) weißt, *wie* der Inverted Index funktioniert, und (3) das **Sync-Problem** ohne Dual-Writes löst. Gut: "Elasticsearch verwenden." Hervorragend: Du benennst CDC/Debezium für Ingestion, BM25 fürs Ranking und akzeptierst Eventual Consistency als Trade für Skalierung.

**Häufige Falle:** Elasticsearch als deine Source of Truth zu behandeln. Es ist ein abgeleiteter Index - nicht langlebig/transaktional wie deine DB. Baue ihn bei Bedarf aus der Quelle neu auf.

## Trade-offs & Fehlermodi

- **Eventual Consistency:** Suche hinkt Writes um die CDC-Pipeline-Latency hinterher (meist sub-Sekunde).
- **Reindex-Schmerz:** Mapping-/Analyzer-Änderungen brauchen einen vollständigen Reindex - nutze Aliase für Zero-Downtime-Swaps.
- **Deep Pagination:** Seite 10.000 ist teuer (Scatter-Gather) - nutze `search_after`, nicht `from/size`.
- **Hot Shard / Skew:** ungleichmäßige Dokumentverteilung; wähle einen guten Routing Key und genug Shards im Voraus (sie sind bei Erstellung fest).
- **Relevanz-Tuning ist fortlaufend:** BM25-Defaults treffen selten die Business-Intention - erwarte Iteration.

Inverted Index - warum er schnell ist

Ingestion über CDC

Sharding & Relevanz

Interview-Perspektive

Trade-offs & Fehlermodi

Ähnliche Fragen