آپ 10 کروڑ+ records پر full-text search کیسے بناتے ہیں؟

Question

IT Interview Practice · Accepted Answer

ایک وقف شدہ search engine استعمال کریں — **Elasticsearch/OpenSearch جو ایک inverted index پر بنا ہے** — جو **CDC** کے ذریعے آپ کے source DB سے 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 دیکھتا ہے اور انہیں intersect کرتا ہے — O(matching docs)، O(all docs) نہیں۔ یہی چیز 10 کروڑ+ documents پر 100ms سے کم search ممکن بناتی ہے۔ Text پہلے **analyze** ہوتا ہے: tokenize، lowercase، stem ("running" → "run")، stopwords گرا دیے جاتے ہیں — تاکہ queries variants سے میل کھائیں۔

## CDC کے ذریعے ingestion

dual-write نہ کریں (app DB *اور* ES دونوں لکھے) — ایک ناکامی انہیں غیر مطابق چھوڑ دیتی ہے۔ اس کے بجائے، تبدیلیوں کو **Change Data Capture** سے stream کریں: **Debezium** DB کے write-ahead log کی پیروی کرتا ہے، row تبدیلیاں **Kafka** پر publish کرتا ہے، اور ایک indexer انہیں Elasticsearch پر لاگو کرتا ہے۔ یہ search کو source کے ساتھ **eventually consistent** رکھتا ہے اور ES downtime سے بچتا ہے (events Kafka سے replay ہوتے ہیں)۔

## Sharding اور relevance

index **shards** میں تقسیم ہوتا ہے (ہر ایک ایک self-contained Lucene index)، nodes میں پھیلا ہوا؛ **replicas** read throughput اور HA بڑھاتے ہیں۔ ایک query تمام shards میں پھیلتی ہے، ہر ایک اپنے top-k واپس کرتا ہے، اور coordinator merge کرتا ہے۔ Relevance بطورِ default **BM25** استعمال کرتی ہے — term frequency × inverse document frequency — boosts، synonyms، اور field weights سے tunable۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والے جانچتے ہیں کہ آپ (1) `LIKE` کے بجائے صحیح اوزار کی طرف بڑھتے ہیں، (2) جانتے ہیں کہ inverted index *کیسے* کام کرتا ہے، اور (3) dual-writes کے بغیر **sync problem** حل کرتے ہیں۔ اچھا: "Elasticsearch استعمال کرو۔" عمدہ: آپ ingestion کے لیے CDC/Debezium، ranking کے لیے BM25 کا نام لیتے ہیں، اور eventual consistency کو scale کے trade کے طور پر قبول کرتے ہیں۔

**عام جال:** Elasticsearch کو اپنا source of truth سمجھنا۔ یہ ایک derived index ہے — آپ کے DB کی طرح durable/transactional نہیں۔ ضرورت پر اسے source سے دوبارہ بنائیں۔

## توازن اور ناکامی کے طریقے

- **Eventual consistency:** search CDC pipeline latency سے writes کے پیچھے رہتا ہے (عموماً sub-second)۔
- **Reindex تکلیف:** mapping/analyzer تبدیلیوں کو ایک full reindex چاہیے — zero-downtime swaps کے لیے aliases استعمال کریں۔
- **Deep pagination:** page 10,000 مہنگا ہے (scatter-gather) — `from/size` نہیں بلکہ `search_after` استعمال کریں۔
- **Hot shard / skew:** غیر یکساں doc تقسیم؛ ایک اچھا routing key اور شروع میں کافی shards چنیں (وہ تخلیق پر مقرر ہو جاتے ہیں)۔
- **Relevance tuning جاری رہتی ہے:** BM25 defaults شاذ ہی business intent سے میل کھاتے ہیں — iteration کی توقع رکھیں۔

Inverted index — یہ تیز کیوں ہے

CDC کے ذریعے ingestion

Sharding اور relevance

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات