Kaip sukurti pilno teksto paiešką per 100 mln.+ įrašų?

Question

IT Interview Practice · Accepted Answer

Naudokite specializuotą paieškos variklį — **Elasticsearch/OpenSearch, pastatytą ant inverted index** — maitinamą iš jūsų šaltinio DB per **CDC**, ir skaidykite indeksą mastui. Jūsų pirminė duomenų bazė (Postgres/MySQL) negali atlikti aktualumu ranguotos teksto paieškos per šimtus milijonų eilučių; `LIKE '%term%'` skenuoja kiekvieną eilutę. Paieškos variklis apverčia 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
```

## Inverted index — kodėl jis greitas

Normalus indeksas susieja eilutę → reikšmės. **Inverted index** susieja *terminą → dokumentų, kuriuose jis yra, sąrašą*. Paieška „database scaling" ieško dviejų trumpų posting sąrašų ir juos sukerta — O(atitinkantys dokumentai), ne O(visi dokumentai). Tai daro mažiau nei 100ms paiešką per 100 mln.+ dokumentų įmanomą. Tekstas pirma **analizuojamas**: tokenizuojamas, mažinamos raidės, stemminamas („running" → „run"), stopwords atmetami — tad užklausos atitinka variantus.

## Priėmimas per CDC

Nerašykite dukart (app rašo DB *ir* ES) — gedimas palieka juos nesuderintus. Vietoj to srautu perduokite pokyčius su **Change Data Capture**: **Debezium** seka DB write-ahead žurnalą, publikuoja eilučių pokyčius į **Kafka**, o indexer juos pritaiko Elasticsearch. Tai išlaiko paiešką **eventually consistent** su šaltiniu ir išgyvena ES gedimą (įvykiai pakartojami iš Kafka).

## Sharding ir aktualumas

Indeksas suskaidytas į **shard** (kiekvienas — savarankiškas Lucene indeksas), paskleistas per mazgus; **replikos** prideda skaitymo throughput ir HA. Užklausa scatter į visus shard, kiekvienas grąžina savo top-k, o koordinatorius sujungia. Aktualumas pagal nutylėjimą naudoja **BM25** — term frequency × inverse document frequency — derinamą su boosts, sinonimais ir laukų svoriais.

## Interviu perspektyva

Interviuotojai tikrina, ar (1) griebiatės tinkamo įrankio vietoj `LIKE`, (2) žinote, *kaip* inverted index veikia, ir (3) sprendžiate **sinchronizacijos problemą** be dual-writes. Gerai: „naudokite Elasticsearch." Puikiai: įvardijate CDC/Debezium priėmimui, BM25 rangavimui ir priimate eventual consistency kaip masto kompromisą.

**Dažni spąstai:** laikyti Elasticsearch savo tiesos šaltiniu. Tai išvestinis indeksas — ne patvarus/transakcinis kaip jūsų DB. Perkurkite jį iš šaltinio kai reikia.

## Kompromisai ir gedimų būdai

- **Eventual consistency:** paieška atsilieka nuo įrašymų CDC konvejerio latency (dažniausiai mažiau nei sekundė).
- **Reindex skausmas:** mapping/analyzer pakeitimai reikalauja pilno reindex — naudokite aliases zero-downtime keitimams.
- **Gili puslapiavimas:** puslapis 10 000 yra brangus (scatter-gather) — naudokite `search_after`, ne `from/size`.
- **Karštas shard / skew:** netolygus dokumentų paskirstymas; parinkite gerą routing raktą ir pakankamai shard iš anksto (jie fiksuoti kuriant).
- **Aktualumo derinimas yra nuolatinis:** BM25 nutylėjimai retai atitinka verslo tikslą — tikėkitės iteracijos.

Inverted index — kodėl jis greitas

Priėmimas per CDC

Sharding ir aktualumas

Interviu perspektyva

Kompromisai ir gedimų būdai

Susiję klausimai