Bagaimana anda membina full-text search ke atas 100J+ rekod?

Question

IT Interview Practice · Accepted Answer

Guna enjin carian khusus — **Elasticsearch/OpenSearch dibina di atas inverted index** — disuap dari DB sumber anda melalui **CDC**, dan shard index untuk skala. Database utama anda (Postgres/MySQL) tidak boleh melakukan carian teks berperingkat relevan ke atas beratus juta baris; sebuah `LIKE '%term%'` mengimbas setiap baris. Sebuah enjin carian membalikkan masalah itu.

```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 — mengapa ia pantas

Sebuah index biasa memetakan baris → nilai. Sebuah **inverted index** memetakan *term → senarai dokumen yang mengandunginya*. Mencari "database scaling" mencari dua posting list pendek dan memotong silangnya (intersect) — O(dokumen sepadan), bukan O(semua dokumen). Inilah yang menjadikan carian sub-100ms ke atas 100J+ dokumen mungkin. Teks di-**analyze** dahulu: di-tokenize, dijadikan huruf kecil, di-stem ("running" → "run"), stopword digugurkan — supaya query sepadan dengan varian.

## Ingestion melalui CDC

Jangan dual-write (app menulis DB *dan* ES) — satu kegagalan meninggalkannya tidak konsisten. Sebaliknya, alirkan perubahan dengan **Change Data Capture**: **Debezium** mengekori write-ahead log DB, menerbitkan perubahan baris ke **Kafka**, dan seorang indexer mengaplikasikannya ke Elasticsearch. Ini mengekalkan carian **eventually consistent** dengan sumber dan bertahan gangguan ES (peristiwa di-replay dari Kafka).

## Sharding & relevan

Index dipecahkan menjadi **shard** (setiap satu index Lucene yang berdikari), tersebar merentas node; **replica** menambah throughput bacaan dan HA. Satu query scatter ke semua shard, setiap satu memulangkan top-k-nya, dan coordinator bercantum. Relevan menggunakan **BM25** secara lalai — kekerapan term × inverse document frequency — boleh ditala dengan boost, sinonim, dan berat medan.

## Perspektif temu duga

Penemu duga menyemak sama ada anda (1) menggapai alat yang betul dan bukannya `LIKE`, (2) tahu *bagaimana* inverted index berfungsi, dan (3) menyelesaikan **masalah sync** tanpa dual-write. Baik: "guna Elasticsearch." Hebat: anda menyebut CDC/Debezium untuk ingestion, BM25 untuk penyusunan, dan menerima eventual consistency sebagai pertukaran untuk skala.

**Perangkap biasa:** melayan Elasticsearch sebagai sumber kebenaran anda. Ia index terbitan — tidak durable/transactional seperti DB anda. Bina semula ia dari sumber apabila perlu.

## Pertukaran & mod kegagalan

- **Eventual consistency:** carian ketinggalan penulisan sebanyak latency pipeline CDC (biasanya sub-saat).
- **Kesakitan reindex:** perubahan mapping/analyzer memerlukan reindex penuh — guna alias untuk pertukaran tanpa masa henti.
- **Pagination dalam:** halaman 10,000 adalah mahal (scatter-gather) — guna `search_after`, bukan `from/size`.
- **Shard panas / kepincangan:** taburan dokumen tidak sekata; pilih routing key yang baik dan cukup shard di hadapan (ia tetap pada penciptaan).
- **Penalaan relevan berterusan:** lalai BM25 jarang sepadan dengan hasrat perniagaan — jangkakan iterasi.

Inverted index — mengapa ia pantas

Ingestion melalui CDC

Sharding & relevan

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan