100M+ records పై full-text search ను మీరు ఎలా నిర్మిస్తారు?

Question

IT Interview Practice · Accepted Answer

ఒక dedicated search engine వాడండి — **inverted index పై నిర్మించిన Elasticsearch/OpenSearch** — **CDC** ద్వారా మీ source DB నుండి fed చేయబడి, scale కోసం index ను shard చేయండి. మీ primary database (Postgres/MySQL) వందల millions of rows పై relevance-ranked text search చేయలేదు; ఒక `LIKE '%term%'` ప్రతి row ను scan చేస్తుంది. ఒక search engine సమస్యను invert చేస్తుంది.

```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 ను look up చేసి వాటిని intersect చేస్తుంది — O(matching docs), O(all docs) కాదు. ఇదే 100M+ documents పై sub-100ms search ను సాధ్యం చేస్తుంది. Text ముందుగా **analyzed** అవుతుంది: tokenize, lowercase, stem ("running" → "run"), stopwords drop — తద్వారా queries variants ను match చేస్తాయి.

## CDC ద్వారా Ingestion

Dual-write చేయవద్దు (app DB *మరియు* ES కి వ్రాస్తుంది) — ఒక failure వాటిని inconsistent గా వదిలేస్తుంది. బదులుగా, **Change Data Capture** తో మార్పులను 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 ను 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** ను పరిష్కరిస్తారా అని check చేస్తారు. మంచిది: "Elasticsearch వాడండి." గొప్పది: మీరు ingestion కి CDC/Debezium ను, ranking కి BM25 ను పేర్కొని, scale కి trade గా eventual consistency ను అంగీకరిస్తారు.

**సాధారణ ఉచ్చు:** Elasticsearch ను మీ source of truth గా భావించడం. ఇది ఒక derived index — మీ DB లా durable/transactional కాదు. అవసరమైనప్పుడు source నుండి దాన్ని rebuild చేయండి.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **Eventual consistency:** search CDC pipeline latency ద్వారా writes వెనుక వెనుకబడుతుంది (సాధారణంగా sub-second).
- **Reindex pain:** 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

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు