Hogyan építesz full-text keresést 100M+ rekord felett?

Question

IT Interview Practice · Accepted Answer

Használj egy dedikált keresőmotort — **Elasticsearch/OpenSearch inverted indexre épülve** — a forrás DB-dből **CDC**-n keresztül táplálva, és shardeld az indexet a méretezéshez. Az elsődleges adatbázisod (Postgres/MySQL) nem tud relevancia-rangsorolt szöveges keresést végezni több százmillió sor felett; egy `LIKE '%term%'` minden sort szkennel. Egy keresőmotor megfordítja a problémát.

```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 — miért gyors

Egy normál index sor → értékek leképezés. Egy **inverted index** *term → az azt tartalmazó dokumentumok listája* leképezés. A "database scaling" keresése két rövid posting listát néz meg és metszi őket — O(illeszkedő dokumentumok), nem O(összes dokumentum). Ez teszi lehetővé a 100ms alatti keresést 100M+ dokumentum felett. A szöveget először **elemzik**: tokenizálják, kisbetűsítik, szótövezik ("running" → "run"), stopwordöket eldobják — így a lekérdezések illeszkednek a variánsokhoz.

## Beolvasás CDC-n keresztül

Ne dual-write-olj (az app írja a DB-t *és* az ES-t) — egy hiba inkonzisztensen hagyja őket. Ehelyett streameld a változásokat **Change Data Capture**-rel: a **Debezium** a DB write-ahead logját követi, sorváltozásokat publikál a **Kafkába**, és egy indexer alkalmazza őket az Elasticsearchre. Ez a keresést **eventual consistensen** tartja a forrással és túléli az ES kiesést (az események replayelnek a Kafkából).

## Shardelés és relevancia

Az index **shardokra** van felosztva (mindegyik egy önálló Lucene index), node-okon szétterítve; a **replikák** olvasási throughputot és HA-t adnak. Egy lekérdezés minden shardra szór, mindegyik visszaadja a top-k-ját, és a koordinátor merge-el. A relevancia alapból **BM25**-öt használ — term frequency × inverse document frequency — hangolható boostokkal, szinonimákkal és mezősúlyokkal.

## Interjú szemszög

Az interjúztatók azt vizsgálják, hogy (1) a megfelelő eszközért nyúlsz-e a `LIKE` helyett, (2) tudod-e *hogyan* működik az inverted index, és (3) megoldod-e a **szinkron problémát** dual-write nélkül. Jó: "használj Elasticsearchöt." Kiváló: megnevezed a CDC/Debeziumot a beolvasáshoz, a BM25-öt a rangsoroláshoz, és elfogadod az eventual consistency-t mint a méret kompromisszumát.

**Gyakori csapda:** az Elasticsearchöt igazságforrásként kezelni. Ez egy származtatott index — nem tartós/tranzakcionális, mint az adatbázisod. Építsd újra a forrásból, ha szükséges.

## Kompromisszumok és hibamódok

- **Eventual consistency:** a keresés lemarad az írásoktól a CDC pipeline latenciájával (általában szubszekundum).
- **Reindex fájdalom:** a mapping/analyzer változások teljes reindexet igényelnek — használj aliasokat a zero-downtime cserékhez.
- **Mély lapozás:** a 10 000. oldal drága (scatter-gather) — használj `search_after`-t, ne `from/size`-t.
- **Forró shard / ferdeség:** egyenetlen dokumentum-eloszlás; válassz jó routing kulcsot és elég shardot előre (ezek létrehozáskor rögzítettek).
- **A relevancia-hangolás folyamatos:** a BM25 alapok ritkán illeszkednek az üzleti szándékhoz — számíts iterációra.

Inverted index — miért gyors

Beolvasás CDC-n keresztül

Shardelés és relevancia

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések