Miten rakennat kokotekstihaun (full-text search) yli 100M tietueeseen?

Question

IT Interview Practice · Accepted Answer

Käytä erillistä hakumoottoria — **Elasticsearch/OpenSearch, joka rakentuu käänteisindeksin (inverted index) päälle** — syötettynä lähde-DB:stäsi **CDC:n** kautta, ja shardaa indeksi skaalaa varten. Primary-tietokantasi (Postgres/MySQL) ei pysty relevanssijärjestettyyn tekstihakuun satojen miljoonien rivien yli; `LIKE '%term%'` skannaa jokaisen rivin. Hakumoottori kääntää ongelman.

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

## Käänteisindeksi — miksi se on nopea

Normaali indeksi kartoittaa rivi → arvot. **Käänteisindeksi** kartoittaa *termi → lista dokumenteista, jotka sisältävät sen*. Haku "database scaling" hakee kaksi lyhyttä posting-listaa ja leikkaa ne — O(vastaavat dokumentit), ei O(kaikki dokumentit). Tämä tekee alle 100 ms:n haun yli 100M dokumentin yli mahdolliseksi. Teksti **analysoidaan** ensin: tokenisoidaan, muutetaan pieniksi kirjaimiksi, stemmataan ("running" → "run"), stopwordit pudotetaan — jotta kyselyt osuvat varianttteihin.

## Sisäänotto CDC:n kautta

Älä dual-writea (sovellus kirjoittaa DB:hen *ja* ES:ään) — epäonnistuminen jättää ne epäkonsistenteiksi. Sen sijaan striimaa muutokset **Change Data Capturella**: **Debezium** seuraa DB:n write-ahead-lokia, julkaisee rivimuutokset **Kafkaan**, ja indeksoija soveltaa ne Elasticsearchiin. Tämä pitää haun **eventually consistentina** lähteen kanssa ja selviää ES-häiriöistä (tapahtumat toistuvat Kafkasta).

## Sharding & relevanssi

Indeksi jaetaan **shardeihin** (kukin itsenäinen Lucene-indeksi), levitettynä nodejen yli; **replikat** lisäävät luku-throughputia ja HA:ta. Kysely leviää kaikkiin shardeihin, kukin palauttaa top-k:nsa, ja koordinaattori yhdistää. Relevanssi käyttää oletuksena **BM25:tä** — termin frekvenssi × käänteinen dokumenttifrekvenssi — säädettävissä boosteilla, synonyymeillä ja kenttäpainoilla.

## Haastattelunäkökulma

Haastattelijat tarkistavat, (1) tartutko oikeaan työkaluun `LIKE`:n sijaan, (2) tiedätkö *miten* käänteisindeksi toimii ja (3) ratkaisetko **synkronointiongelman** ilman dual-writeja. Hyvä: "käytä Elasticsearchia." Loistava: nimeät CDC:n/Debeziumin sisäänottoon, BM25:n järjestykseen ja hyväksyt eventual consistencyn kompromissina mittakaavalle.

**Yleinen ansa:** Elasticsearchin kohteleminen totuuden lähteenä. Se on johdettu indeksi — ei kestävä/transaktionaalinen kuten DB:si. Rakenna se uudelleen lähteestä tarvittaessa.

## Kompromissit ja virhetilanteet

- **Eventual consistency:** haku laahaa kirjoituksia CDC-pipelinen latenssin verran (yleensä alle sekunnin).
- **Reindeksoinnin tuska:** mapping-/analyzer-muutokset tarvitsevat täyden reindeksoinnin — käytä aliaksia zero-downtime-vaihtoihin.
- **Syvä sivutus:** sivu 10 000 on kallis (scatter-gather) — käytä `search_after`, ei `from/size`.
- **Kuuma shard / vinouma:** epätasainen dokumenttijakauma; valitse hyvä routing-avain ja tarpeeksi shardeja etukäteen (ne ovat kiinteitä luontihetkellä).
- **Relevanssin säätö on jatkuvaa:** BM25-oletukset osuvat harvoin liiketoiminta-aikeeseen — odota iterointia.

Käänteisindeksi — miksi se on nopea

Sisäänotto CDC:n kautta

Sharding & relevanssi

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset