100M+ 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-ஐ 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-ஐ lookup செய்து அவற்றை intersect செய்கிறது — O(matching docs), O(all docs) அல்ல. 100M+ documents மீது sub-100ms search-ஐ சாத்தியமாக்குவது இது தான். Text முதலில் **analyzed** ஆகிறது: tokenized, lowercased, stemmed ("running" → "run"), stopwords drop செய்யப்படுகின்றன — எனவே queries variants-ஐப் பொருத்துகின்றன.

## CDC மூலம் Ingestion

dual-write செய்யாதீர்கள் (app DB-க்கு *மற்றும்* ES-க்கு எழுதுகிறது) — ஒரு தோல்வி அவற்றை inconsistent-ஆக விட்டுவிடுகிறது. மாறாக, **Change Data Capture** மூலம் changes-ஐ 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 திருப்புகிறது, மேலும் 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 CDC pipeline latency-ஆல் writes-ஐ பின்தொடர்கிறது (வழக்கமாக sub-second).
- **Reindex pain:** mapping/analyzer changes-க்கு ஒரு முழு 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-இல் நிலையானவை).
- **Relevance tuning தொடர்ச்சியானது:** BM25 defaults அரிதாகவே business intent-ஐப் பொருத்துகின்றன — iteration எதிர்பாருங்கள்.

Inverted index — ஏன் வேகமானது

CDC மூலம் Ingestion

Sharding & relevance

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வி முறைகளும்

தொடர்புடைய கேள்விகள்