১০ কোটি+ record-এর উপর full-text search কীভাবে বানাবেন?

Question

IT Interview Practice · Accepted Answer

একটি dedicated search engine ব্যবহার করুন — **inverted index-এর উপর নির্মিত Elasticsearch/OpenSearch** — যা **CDC**-এর মাধ্যমে আপনার source DB থেকে খাওয়ানো হয়, এবং 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-এর তালিকা* map করে। "database scaling" সার্চ করলে দুটি ছোট posting list lookup করে এবং সেগুলো intersect করে — O(matching docs), O(all docs) নয়। এটিই ১০ কোটি+ document-এর উপর sub-100ms search সম্ভব করে। Text প্রথমে **analyzed** হয়: tokenized, lowercased, stemmed ("running" → "run"), stopword বাদ — যাতে query variant-এর সঙ্গে মেলে।

## CDC-এর মাধ্যমে ingestion

Dual-write করবেন না (app DB *এবং* ES-এ লেখে) — একটি failure সেগুলোকে inconsistent রেখে দেয়। বরং, **Change Data Capture** দিয়ে পরিবর্তন stream করুন: **Debezium** DB-এর write-ahead log tail করে, row পরিবর্তন **Kafka**-তে publish করে, এবং একটি indexer সেগুলো Elasticsearch-এ প্রয়োগ করে। এটি search-কে source-এর সঙ্গে **eventually consistent** রাখে এবং ES downtime-এ টিকে থাকে (event Kafka থেকে replay হয়)।

## Sharding ও relevance

index **shard**-এ (প্রতিটি একটি স্বয়ংসম্পূর্ণ Lucene index) split হয়, node জুড়ে ছড়ানো; **replica** read throughput ও HA যোগ করে। একটি query সব shard-এ scatter হয়, প্রতিটি তার top-k রিটার্ন করে, এবং coordinator merge করে। Relevance ডিফল্টভাবে **BM25** ব্যবহার করে — term frequency × inverse document frequency — boost, synonym ও field weight দিয়ে tunable।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়াররা যাচাই করেন আপনি (১) `LIKE`-এর বদলে সঠিক টুলের দিকে হাত বাড়ান কিনা, (২) inverted index *কীভাবে* কাজ করে জানেন কিনা, এবং (৩) dual-write ছাড়া **sync সমস্যা** সমাধান করেন কিনা। ভালো: "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 দিয়ে write থেকে পিছিয়ে থাকে (সাধারণত sub-second)।
- **Reindex যন্ত্রণা:** mapping/analyzer পরিবর্তনে full reindex লাগে — zero-downtime swap-এর জন্য alias ব্যবহার করুন।
- **Deep pagination:** page ১০,০০০ ব্যয়বহুল (scatter-gather) — `from/size` নয়, `search_after` ব্যবহার করুন।
- **Hot shard / skew:** অসম doc distribution; একটি ভালো routing key ও যথেষ্ট shard আগেভাগে বাছুন (এগুলো creation-এ fixed)।
- **Relevance tuning চলমান:** BM25 ডিফল্ট খুব কমই business intent-এর সঙ্গে মেলে — iteration আশা করুন।

Inverted index — কেন এটি দ্রুত

CDC-এর মাধ্যমে ingestion

Sharding ও relevance

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতার ধরন

সম্পর্কিত প্রশ্ন