आप 10 करोड़+ records पर full-text search कैसे बनाते हैं?

Question

IT Interview Practice · Accepted Answer

एक समर्पित search engine इस्तेमाल करें — **Elasticsearch/OpenSearch जो एक inverted index पर बना है** — जो आपके source DB से **CDC** के ज़रिए feed होता है, और scale के लिए index को shard करें। आपका primary database (Postgres/MySQL) सैकड़ों करोड़ rows पर relevance-ranked text search नहीं कर सकता; एक `LIKE '%term%'` हर row scan करता है। एक search engine समस्या को उलट देता है।

```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 की सूची* map करता है। "database scaling" खोजने से दो छोटी posting lists lookup होती हैं और intersect होती हैं — O(matching docs), O(all docs) नहीं। यही 10 करोड़+ documents पर 100ms से कम search संभव बनाता है। Text को पहले **analyze** किया जाता है: tokenized, lowercased, stemmed ("running" → "run"), stopwords गिराए जाते हैं — ताकि 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** में बांटा जाता है (हर एक एक self-contained Lucene index), nodes में फैलाया जाता है; **replicas** read throughput और HA जोड़ती हैं। एक query सभी shards में scatter होती है, हर एक अपना top-k लौटाता है, और coordinator merge करता है। Relevance default रूप से **BM25** इस्तेमाल करती है — term frequency × inverse document frequency — boosts, synonyms, और field weights के साथ tunable।

## इंटरव्यू का नज़रिया

Interviewers परखते हैं कि क्या आप (1) `LIKE` के बजाय सही उपकरण की ओर बढ़ते हैं, (2) जानते हैं inverted index *कैसे* काम करता है, और (3) dual-writes के बिना **sync समस्या** हल करते हैं। अच्छा: "Elasticsearch इस्तेमाल करें।" बढ़िया: आप ingestion के लिए CDC/Debezium, ranking के लिए BM25 नाम लेते हैं, और scale के trade के रूप में eventual consistency स्वीकार करते हैं।

**आम जाल:** Elasticsearch को अपना source of truth मानना। यह एक derived index है — आपके DB जैसा durable/transactional नहीं। ज़रूरत पड़ने पर इसे source से फिर से बनाएं।

## ट्रेड-ऑफ़ और failure modes

- **Eventual consistency:** search, writes से CDC pipeline latency जितना पीछे रहता है (आमतौर पर sub-second)।
- **Reindex दर्द:** 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 चुनें (वे creation पर fixed हैं)।
- **Relevance tuning जारी रहती है:** BM25 defaults शायद ही business intent से match करते हैं — iteration की अपेक्षा करें।

Inverted index — यह तेज़ क्यों है

CDC के ज़रिए ingestion

Sharding और relevance

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न