ਤੁਸੀਂ 10 ਕਰੋੜ+ 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 ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ।

```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 ਵੇਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ intersect ਕਰਦਾ ਹੈ — O(matching docs), ਨਾ ਕਿ O(all docs)। ਇਹੀ 100M+ documents ਉੱਤੇ sub-100ms search ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। Text ਪਹਿਲਾਂ **analyze** ਹੁੰਦਾ ਹੈ: tokenize, lowercase, stem ("running" → "run"), stopwords drop — ਤਾਂ ਜੋ queries variants ਨਾਲ match ਕਰਨ।

## CDC ਰਾਹੀਂ Ingestion

dual-write ਨਾ ਕਰੋ (app DB *ਅਤੇ* ES ਲਿਖਦਾ ਹੈ) — ਇੱਕ failure ਉਹਨਾਂ ਨੂੰ inconsistent ਛੱਡ ਦਿੰਦੀ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, changes ਨੂੰ **Change Data Capture** ਨਾਲ stream ਕਰੋ: **Debezium** DB ਦੇ write-ahead log ਦੀ ਪੂਛ ਫੜਦਾ ਹੈ, 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 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** ਹੱਲ ਕਰਦੇ ਹੋ। ਵਧੀਆ: "Elasticsearch ਵਰਤੋ।" ਸ਼ਾਨਦਾਰ: ਤੁਸੀਂ ingestion ਲਈ CDC/Debezium, ranking ਲਈ BM25 ਦਾ ਨਾਂ ਲੈਂਦੇ ਹੋ, ਅਤੇ scale ਦੇ trade ਵਜੋਂ eventual consistency ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ।

**ਆਮ ਫੰਦਾ:** Elasticsearch ਨੂੰ ਆਪਣਾ source of truth ਮੰਨਣਾ। ਇਹ ਇੱਕ derived index ਹੈ — ਤੁਹਾਡੀ DB ਵਾਂਗ durable/transactional ਨਹੀਂ। ਲੋੜ ਪੈਣ ਉੱਤੇ ਇਸਨੂੰ source ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਓ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **Eventual consistency:** search writes ਤੋਂ CDC pipeline latency (ਆਮ ਤੌਰ ਉੱਤੇ sub-second) ਜਿੰਨਾ ਪਿੱਛੇ ਰਹਿੰਦਾ ਹੈ।
- **Reindex pain:** mapping/analyzer changes ਨੂੰ ਇੱਕ full reindex ਦੀ ਲੋੜ ਹੈ — zero-downtime swaps ਲਈ aliases ਵਰਤੋ।
- **Deep pagination:** page 10,000 ਮਹਿੰਗਾ ਹੈ (scatter-gather) — `search_after` ਵਰਤੋ, `from/size` ਨਹੀਂ।
- **Hot shard / skew:** ਅਸਮਾਨ doc distribution; ਇੱਕ ਵਧੀਆ routing key ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਕਾਫ਼ੀ shards ਚੁਣੋ (ਉਹ creation ਉੱਤੇ fixed ਹੁੰਦੇ ਹਨ)।
- **Relevance tuning ਲਗਾਤਾਰ ਹੈ:** BM25 defaults ਘੱਟ ਹੀ business intent ਨਾਲ match ਕਰਦੇ ਹਨ — iteration ਦੀ ਉਮੀਦ ਰੱਖੋ।

Inverted index — ਇਹ ਤੇਜ਼ ਕਿਉਂ ਹੈ

CDC ਰਾਹੀਂ Ingestion

Sharding ਅਤੇ relevance

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ