તમે 100M+ records પર full-text search કેવી રીતે બનાવશો?

Question

IT Interview Practice · Accepted Answer

એક dedicated search engine વાપરો — **inverted index પર બનેલું Elasticsearch/OpenSearch** — તમારા source DB થી **CDC** દ્વારા feed થયેલું, અને scale માટે index ને shard કરો. તમારી primary database (Postgres/MySQL) સેંકડો લાખો rows પર relevance-ranked text search કરી શકતી નથી; એક `LIKE '%term%'` દરેક row scan કરે છે. search engine problem ને invert કરે છે.

```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 — તે શા માટે ઝડપી છે

સામાન્ય index row → values map કરે છે. એક **inverted index** *term → તેને ધરાવતા documents ની list* map કરે છે. "database scaling" search કરવાથી બે ટૂંકી posting lists lookup થાય અને intersect થાય — O(matching docs), O(all docs) નહીં. આ જ 100M+ documents પર sub-100ms search શક્ય બનાવે છે. Text પહેલા **analyzed** થાય છે: tokenized, lowercased, stemmed ("running" → "run"), stopwords dropped — જેથી queries variants ને match કરે.

## CDC દ્વારા Ingestion

dual-write ન કરો (app DB *અને* ES લખે) — એક failure તેમને inconsistent છોડે છે. તેને બદલે, **Change Data Capture** સાથે changes stream કરો: **Debezium** DB ના write-ahead log ને tail કરે છે, row changes ને **Kafka** પર publish કરે છે, અને એક indexer તેમને Elasticsearch પર apply કરે છે. આ search ને source સાથે **eventually consistent** રાખે છે અને ES downtime થી બચે છે (events Kafka થી replay થાય).

## Sharding & relevance

index **shards** માં split થાય છે (દરેક self-contained Lucene index), nodes પર ફેલાયેલા; **replicas** read throughput અને HA ઉમેરે છે. query બધા shards પર scatter થાય, દરેક તેનું top-k return કરે, અને coordinator merge કરે. Relevance default રૂપે **BM25** વાપરે છે — term frequency × inverse document frequency — boosts, synonyms, અને field weights સાથે tunable.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર્સ તપાસે છે કે તમે (1) `LIKE` ને બદલે યોગ્ય tool તરફ પહોંચો છો, (2) inverted index *કેવી રીતે* કામ કરે છે તે જાણો છો, અને (3) dual-writes વગર **sync problem** ઉકેલો છો. Good: "Elasticsearch વાપરો." Great: તમે ingestion માટે CDC/Debezium, ranking માટે BM25 નું નામ આપો છો, અને scale ના trade તરીકે eventual consistency સ્વીકારો છો.

**સામાન્ય trap:** Elasticsearch ને તમારી source of truth ગણવી. તે derived index છે — તમારા DB જેવું durable/transactional નથી. જરૂર પડે ત્યારે source માંથી rebuild કરો.

## Trade-offs અને failure modes

- **Eventual consistency:** search CDC pipeline latency (સામાન્ય રીતે sub-second) જેટલી writes થી lag કરે છે.
- **Reindex pain:** mapping/analyzer changes ને full reindex જોઈએ — zero-downtime swaps માટે aliases વાપરો.
- **Deep pagination:** page 10,000 મોંઘું છે (scatter-gather) — `from/size` નહીં, `search_after` વાપરો.
- **Hot shard / skew:** અસમાન doc distribution; સારો routing key અને પૂરતા shards up front પસંદ કરો (તે creation પર fixed છે).
- **Relevance tuning ongoing છે:** BM25 defaults ભાગ્યે જ business intent ને match કરે છે — iteration ની અપેક્ષા રાખો.

Inverted index — તે શા માટે ઝડપી છે

CDC દ્વારા Ingestion

Sharding & relevance

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો