Si ndërtoni full-text search mbi 100M+ regjistra?

Question

IT Interview Practice · Accepted Answer

Përdorni një search engine të dedikuar — **Elasticsearch/OpenSearch të ndërtuar mbi një inverted index** — të ushqyer nga source DB juaj përmes **CDC**, dhe shard-oni index-in për shkallë. Baza juaj primare (Postgres/MySQL) nuk mund të bëjë kërkim teksti me renditje sipas relevancës mbi qindra miliona rreshta; një `LIKE '%term%'` skanon çdo rresht. Një search engine e përmbys problemin.

```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 — pse është i shpejtë

Një index normal harton rresht → vlera. Një **inverted index** harton *term → listë dokumentesh që e përmbajnë*. Kërkimi i "database scaling" shikon dy posting lists të shkurtra dhe i pret — O(dokumente që përputhen), jo O(të gjithë dokumentet). Kjo është ajo që e bën të mundur kërkimin nën-100ms mbi 100M+ dokumente. Teksti **analizohet** së pari: tokenizohet, kthehet në gërma të vogla, stemohet ("running" → "run"), stopwords hiqen — që query-t të përputhen me variantet.

## Ingestion përmes CDC

Mos bëni dual-write (aplikacioni shkruan DB *dhe* ES) — një dështim i lë ata inkonsistentë. Në vend të kësaj, bëni stream të ndryshimeve me **Change Data Capture**: **Debezium** ndjek write-ahead log-un e DB-së, publikon ndryshimet e rreshtave te **Kafka**, dhe një indexer i aplikon ato te Elasticsearch. Kjo e mban search-in **eventually consistent** me burimin dhe mbijeton ndërprerjet e ES (event-et bëjnë replay nga Kafka).

## Sharding & relevancë

Index-i ndahet në **shards** (secili një Lucene index i pavarur), i shpërndarë nëpër node; **replicas** shtojnë read throughput dhe HA. Një query bën scatter te të gjithë shards, secili kthen top-k-në e vet, dhe koordinatori i bashkon. Relevanca përdor **BM25** si default — frekuenca e termit × frekuenca e kundërt e dokumentit — e rregullueshme me boosts, sinonime dhe pesha fushash.

## Këndvështrimi i intervistës

Intervistuesit kontrollojnë nëse ju (1) kapeni pas veglës së duhur në vend të `LIKE`, (2) dini *si* funksionon inverted index-i, dhe (3) zgjidhni **problemin e sync** pa dual-writes. Mirë: "përdor Elasticsearch." E shkëlqyer: emërtoni CDC/Debezium për ingestion, BM25 për renditje, dhe pranoni eventual consistency si kompromis për shkallën.

**Kurthi i zakonshëm:** trajtimi i Elasticsearch si burimi juaj i së vërtetës. Është një index i derivuar — jo i qëndrueshëm/transaksional si DB juaj. Rindërtojeni nga burimi kur duhet.

## Kompromiset & mënyrat e dështimit

- **Eventual consistency:** search-i vonon shkrimet me latency-n e pipeline-it CDC (zakonisht nën-sekondë).
- **Dhimbja e reindex:** ndryshimet e mapping/analyzer kërkojnë një reindex të plotë — përdorni aliases për swap zero-downtime.
- **Deep pagination:** faqja 10,000 është e shtrenjtë (scatter-gather) — përdorni `search_after`, jo `from/size`.
- **Hot shard / skew:** shpërndarje e pabarabartë dokumentesh; zgjidhni një routing key të mirë dhe shards të mjaftueshëm që në fillim (janë fikse në krijim).
- **Rregullimi i relevancës është i vazhdueshëm:** default-et e BM25 rrallë përputhen me qëllimin e biznesit — prisni iteracion.

Inverted index — pse është i shpejtë

Ingestion përmes CDC

Sharding & relevancë

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme