10 करोड+ record माथि full-text search कसरी बनाउनुहुन्छ?

Question

IT Interview Practice · Accepted Answer

एउटा समर्पित search engine प्रयोग गर्नुहोस् — **inverted index मा बनेको Elasticsearch/OpenSearch** — जुन तपाईंको source DB बाट **CDC** मार्फत feed हुन्छ, र scale का लागि index shard गर्नुहोस्। तपाईंको primary database (Postgres/MySQL) ले करोडौं row माथि 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 → value map गर्छ। एउटा **inverted index** ले *term → त्यो समावेश गर्ने document हरूको list* map गर्छ। "database scaling" खोज्दा दुई छोटो posting list हेर्छ र intersect गर्छ — O(matching docs), O(all docs) होइन। यही ले 10 करोड+ document माथि sub-100ms search सम्भव बनाउँछ। Text पहिले **analyze** हुन्छ: tokenize, lowercase, stem ("running" → "run"), stopword drop — ताकि query ले variant मिलाओस्।

## CDC मार्फत ingestion

dual-write नगर्नुहोस् (app ले DB *र* ES दुवैमा लेख्छ) — एउटा failure ले तिनलाई असंगत बनाउँछ। बरु, **Change Data Capture** सँग change stream गर्नुहोस्: **Debezium** ले DB को write-ahead log tail गर्छ, row change लाई **Kafka** मा publish गर्छ, र एउटा indexer ले तिनलाई Elasticsearch मा apply गर्छ। यसले search लाई source सँग **eventually consistent** राख्छ र ES downtime बचाउँछ (event Kafka बाट replay हुन्छन्)।

## Sharding र relevance

index लाई **shard** (प्रत्येक एक स्वतन्त्र Lucene index) मा विभाजन गरिन्छ, node हरूमा फैलाइन्छ; **replica** ले read throughput र HA थप्छ। एउटा query सबै shard मा scatter हुन्छ, प्रत्येकले आफ्नो top-k फर्काउँछ, र coordinator ले merge गर्छ। Relevance ले default रूपमा **BM25** प्रयोग गर्छ — term frequency × inverse document frequency — boost, synonym, र field weight सँग tunable।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारहरूले तपाईंले (1) `LIKE` को सट्टा सही tool तिर पुग्नुहुन्छ कि, (2) inverted index *कसरी* काम गर्छ जान्नुहुन्छ कि, र (3) dual-write बिना **sync समस्या** हल गर्नुहुन्छ कि जाँच्छन्। राम्रो: "Elasticsearch प्रयोग गर।" उत्कृष्ट: तपाईं ingestion का लागि CDC/Debezium, ranking का लागि BM25 नाम दिनुहुन्छ, र scale को trade को रूपमा eventual consistency स्वीकार्नुहुन्छ।

**साधारण जाल:** Elasticsearch लाई सत्यको स्रोत मान्नु। यो एउटा derived index हो — तपाईंको DB जस्तो टिकाउ/transactional होइन। आवश्यक हुँदा source बाट पुनर्निर्माण गर्नुहोस्।

## ट्रेड-अफ र failure mode

- **Eventual consistency:** search write भन्दा CDC pipeline latency (प्रायः sub-second) पछि पर्छ।
- **Reindex पीडा:** mapping/analyzer परिवर्तनलाई full reindex चाहिन्छ — zero-downtime swap का लागि alias प्रयोग गर्नुहोस्।
- **Deep pagination:** page 10,000 महँगो छ (scatter-gather) — `from/size` होइन, `search_after` प्रयोग गर्नुहोस्।
- **Hot shard / skew:** असमान doc वितरण; राम्रो routing key र सुरुमै पर्याप्त shard छान्नुहोस् (creation मा fix हुन्छन्)।
- **Relevance tuning निरन्तर:** BM25 default ले व्यापार अभिप्राय विरलै मिलाउँछ — iteration अपेक्षा गर्नुहोस्।

Inverted index — किन छिटो

CDC मार्फत ingestion

Sharding र relevance

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू