คุณจะสร้าง full-text search บน record 100M+ รายการอย่างไร?

Question

IT Interview Practice · Accepted Answer

ใช้ search engine เฉพาะทาง — **Elasticsearch/OpenSearch ที่สร้างบน inverted index** — ป้อนข้อมูลจาก source DB ผ่าน **CDC** และ shard index เพื่อ scale primary database ของคุณ (Postgres/MySQL) ไม่สามารถทำ relevance-ranked text search บนหลายร้อยล้าน row ได้ `LIKE '%term%'` สแกนทุก row 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 **inverted index** แมป *term → รายการ document ที่มีมัน* การ search "database scaling" ทำการ lookup posting list สั้น ๆ สองอันแล้ว intersect — O(document ที่ตรง) ไม่ใช่ O(document ทั้งหมด) นี่คือสิ่งที่ทำให้ search แบบ sub-100ms บน 100M+ document เป็นไปได้ text ถูก **analyze** ก่อน: tokenize, lowercase, stem ("running" → "run"), drop stopword — เพื่อให้ query match รูปแบบต่าง ๆ

## Ingestion ผ่าน CDC

อย่า dual-write (app เขียน DB *และ* ES) — การล้มเหลวทำให้ทั้งสองไม่สอดคล้อง แทนที่จะเป็นแบบนั้น ให้ stream การเปลี่ยนแปลงด้วย **Change Data Capture**: **Debezium** ตาม write-ahead log ของ DB, publish การเปลี่ยนแปลง row ไปยัง **Kafka** และ indexer นำไปใช้กับ Elasticsearch สิ่งนี้ทำให้ search **eventually consistent** กับ source และรอดจากการล่มของ ES (event replay จาก Kafka)

## Sharding & relevance

index ถูกแยกเป็น **shard** (แต่ละอันคือ Lucene index ที่สมบูรณ์ในตัว) กระจายข้าม node **replica** เพิ่ม read throughput และ HA query จะ scatter ไปทุก shard แต่ละ shard คืน top-k ของมัน และ coordinator merge relevance ใช้ **BM25** โดยค่าเริ่มต้น — term frequency × inverse document frequency — ปรับได้ด้วย boost, synonym และ field weight

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์ตรวจว่าคุณ (1) ไขว่คว้าหาเครื่องมือที่ถูกต้องแทน `LIKE` หรือไม่ (2) รู้ *ว่า* inverted index ทำงานอย่างไร และ (3) แก้ **ปัญหา sync** โดยไม่ dual-write ดี: "ใช้ Elasticsearch" เยี่ยม: คุณระบุ CDC/Debezium สำหรับ ingestion, BM25 สำหรับ ranking และยอมรับ eventual consistency เป็นข้อแลกเปลี่ยนสำหรับ scale

**กับดักที่พบบ่อย:** ปฏิบัติต่อ Elasticsearch เป็น source of truth มันคือ derived index — ไม่ durable/transactional เหมือน DB ของคุณ สร้างใหม่จาก source เมื่อจำเป็น

## ข้อแลกเปลี่ยน & โหมด failure

- **Eventual consistency:** search ล่าช้ากว่าการเขียนตาม latency ของ CDC pipeline (มักต่ำกว่าวินาที)
- **ความเจ็บปวดของ reindex:** การเปลี่ยน mapping/analyzer ต้อง reindex ทั้งหมด — ใช้ alias เพื่อ swap แบบ zero-downtime
- **Deep pagination:** หน้า 10,000 แพง (scatter-gather) — ใช้ `search_after` ไม่ใช่ `from/size`
- **Hot shard / skew:** การกระจาย doc ไม่สม่ำเสมอ เลือก routing key ที่ดีและ shard ให้พอตั้งแต่ต้น (มันตายตัวตอนสร้าง)
- **การปรับ relevance เป็นงานต่อเนื่อง:** ค่าเริ่มต้น BM25 ไม่ค่อยตรงกับเจตนาทางธุรกิจ — คาดว่าจะต้องปรับซ้ำ

Inverted index — ทำไมถึงเร็ว

Ingestion ผ่าน CDC

Sharding & relevance

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & โหมด failure

คำถามที่เกี่ยวข้อง