Xây full-text search trên 100M+ bản ghi như thế nào?

Question

IT Interview Practice · Accepted Answer

Dùng một search engine chuyên dụng — **Elasticsearch/OpenSearch xây trên inverted index** — được nạp từ source DB qua **CDC**, và shard index để scale. Database chính (Postgres/MySQL) của bạn không thể làm text search xếp hạng theo relevance trên hàng trăm triệu dòng; một `LIKE '%term%'` scan mọi dòng. Search engine đảo ngược bài toán.

```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 — vì sao nó nhanh

Một index thường map dòng → giá trị. Một **inverted index** map *term → danh sách document chứa nó*. Tìm "database scaling" tra cứu hai posting list ngắn và giao chúng — O(document khớp), không phải O(tất cả document). Đây là thứ làm search dưới 100ms trên 100M+ document khả thi. Text được **analyze** trước: tokenize, hạ chữ thường, stemming ("running" → "run"), bỏ stopword — để query khớp các biến thể.

## Ingestion qua CDC

Đừng dual-write (app ghi DB *và* ES) — một lỗi để lại chúng không nhất quán. Thay vào đó, stream thay đổi bằng **Change Data Capture**: **Debezium** đọc đuôi write-ahead log của DB, publish thay đổi dòng lên **Kafka**, và một indexer áp chúng vào Elasticsearch. Cách này giữ search **eventually consistent** với source và sống sót khi ES down (event replay từ Kafka).

## Sharding & relevance

Index được chia thành **shard** (mỗi cái là một Lucene index tự chứa), trải trên các node; **replica** thêm read throughput và HA. Một query scatter tới mọi shard, mỗi shard trả top-k của nó, và coordinator merge. Relevance mặc định dùng **BM25** — term frequency × inverse document frequency — tinh chỉnh được bằng boost, synonym, và trọng số field.

## Góc nhìn phỏng vấn

Người phỏng vấn kiểm tra bạn có (1) với tới đúng công cụ thay vì `LIKE`, (2) biết inverted index hoạt động *ra sao*, và (3) giải quyết **vấn đề đồng bộ** mà không dual-write. Khá: "dùng Elasticsearch." Xuất sắc: bạn gọi tên CDC/Debezium cho ingestion, BM25 cho ranking, và chấp nhận eventual consistency như cái giá đổi lấy scale.

**Bẫy thường gặp:** coi Elasticsearch là source of truth. Nó là index dẫn xuất — không bền/transactional như DB của bạn. Rebuild nó từ source khi cần.

## Đánh đổi & kịch bản hỏng

- **Eventual consistency:** search trễ so với write bằng độ trễ pipeline CDC (thường dưới một giây).
- **Đau khi reindex:** đổi mapping/analyzer cần reindex toàn bộ — dùng alias để swap zero-downtime.
- **Phân trang sâu:** trang 10.000 tốn kém (scatter-gather) — dùng `search_after`, không phải `from/size`.
- **Hot shard / skew:** phân bố document không đều; chọn routing key tốt và đủ shard từ đầu (chúng cố định lúc tạo).
- **Tinh chỉnh relevance là việc liên tục:** mặc định BM25 hiếm khi khớp ý đồ nghiệp vụ — chuẩn bị lặp đi lặp lại.

Inverted index — vì sao nó nhanh

Ingestion qua CDC

Sharding & relevance

Góc nhìn phỏng vấn

Đánh đổi & kịch bản hỏng

Câu hỏi liên quan