Kako zgradite polnobesedno iskanje (full-text search) čez 100M+ zapisov?

Question

IT Interview Practice · Accepted Answer

Uporabite namenski iskalni pogon — **Elasticsearch/OpenSearch, zgrajen na obrnjenem indeksu (inverted index)** — napajan iz vaše izvorne DB prek **CDC**, in shardajte indeks za obseg. Vaša primarna podatkovna baza (Postgres/MySQL) ne zmore relevančno rangiranega besedilnega iskanja čez sto milijonov vrstic; `LIKE '%term%'` skenira vsako vrstico. Iskalni pogon obrne problem.

```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
```

## Obrnjeni indeks — zakaj je hiter

Normalen indeks preslika vrstica → vrednosti. **Obrnjeni indeks** preslika *izraz (term) → seznam dokumentov, ki ga vsebujejo*. Iskanje "database scaling" poišče dva kratka seznama zadetkov (posting lists) in ju preseka — O(ujemajoči se dokumenti), ne O(vsi dokumenti). To omogoča pod-100 ms iskanje čez 100M+ dokumentov. Besedilo se najprej **analizira**: tokenizira, spremeni v male črke, korenizira (stemming: "running" → "run"), odstrani stopwords — tako da poizvedbe ujamejo variante.

## Zajem prek CDC

Ne dvojno zapisujte (aplikacija piše v DB *in* ES) — odpoved pusti nekonsistentnost. Namesto tega pretakajte spremembe s **Change Data Capture**: **Debezium** sledi write-ahead dnevniku DB, objavlja spremembe vrstic v **Kafko**, indekser pa jih uveljavi v Elasticsearch. To ohranja iskanje **eventualno konsistentno** z virom in preživi izpad ES (dogodki se ponovno predvajajo iz Kafke).

## Sharding in relevanca

Indeks je razdeljen v **sharde** (vsak samostojen Lucene indeks), razporejene čez vozlišča; **replike** dodajajo bralni throughput in HA. Poizvedba se razprši (scatter) na vse sharde, vsak vrne svojih top-k, koordinator pa združi. Relevanca privzeto uporablja **BM25** — pogostost izraza × obrnjena pogostost dokumentov (inverse document frequency) — nastavljivo z boosti, sinonimi in utežmi polj.

## Pogled s stališča razgovora

Izpraševalci preverjajo, ali (1) posežete po pravem orodju namesto `LIKE`, (2) veste, *kako* obrnjeni indeks deluje, in (3) rešite **problem sinhronizacije** brez dvojnih zapisov. Dobro: "uporabi Elasticsearch." Odlično: poimenujete CDC/Debezium za zajem, BM25 za rangiranje in sprejmete eventualno konsistentnost kot kompromis za obseg.

**Pogosta past:** obravnavanje Elasticsearcha kot vira resnice. Je izpeljani indeks — ne trajen/transakcijski kot vaša DB. Po potrebi ga ponovno zgradite iz vira.

## Kompromisi in načini odpovedi

- **Eventualna konsistentnost:** iskanje zaostaja za zapisi za latenco CDC cevovoda (običajno pod-sekundno).
- **Bolečina ponovnega indeksiranja:** spremembe mapping/analyzer potrebujejo popolno ponovno indeksiranje — uporabite aliase za zamenjavo brez izpada (zero-downtime).
- **Globoko paginiranje (deep pagination):** stran 10.000 je draga (scatter-gather) — uporabite `search_after`, ne `from/size`.
- **Vroč shard / neenakomernost:** neenakomerna porazdelitev dokumentov; izberite dober routing key in dovolj shardov vnaprej (fiksni so ob ustvaritvi).
- **Uravnavanje relevance je nenehno:** BM25 privzetki redko ustrezajo poslovnemu namenu — pričakujte iteracijo.

Obrnjeni indeks — zakaj je hiter

Zajem prek CDC

Sharding in relevanca

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja