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 समस्या उलटे करते.

```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" search करणे दोन लहान posting lists शोधते आणि त्यांना intersect करते — O(matching docs), O(all docs) नव्हे. हेच 10 कोटी+ documents वर 100ms खाली search शक्य करते. Text आधी **analyzed** होते: tokenize, lowercase, stem ("running" → "run"), stopwords टाकले जातात — जेणेकरून queries variants शी जुळतात.

## CDC द्वारे Ingestion

dual-write करू नका (app DB *आणि* ES लिहिते) — एक अपयश त्यांना inconsistent सोडते. त्याऐवजी, **Change Data Capture** ने बदल stream करा: **Debezium** DB चा write-ahead log tail करते, row बदल **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` ऐवजी योग्य साधनाकडे वळता का, (2) inverted index *कसा* चालतो हे जाणता का, आणि (3) dual-writes शिवाय **sync problem** सोडवता का. चांगले: "Elasticsearch वापरा." उत्तम: तुम्ही ingestion साठी CDC/Debezium, ranking साठी BM25 नावाने सांगता, आणि scale ची तडजोड म्हणून eventual consistency स्वीकारता.

**सामान्य सापळा:** Elasticsearch ला तुमचे source of truth मानणे. ते एक derived index आहे — तुमच्या DB सारखे durable/transactional नाही. गरज पडेल तेव्हा source मधून ते पुन्हा बांधा.

## तडजोडी आणि अपयश

- **Eventual consistency:** search CDC pipeline latency ने writes च्या मागे राहते (सहसा sub-second).
- **Reindex pain:** mapping/analyzer बदलांना पूर्ण 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 शी जुळतात — iteration अपेक्षित.

Inverted index — ते जलद का

CDC द्वारे Ingestion

Sharding & relevance

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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