如何在 1 亿+ 条记录上构建全文搜索？

Question

IT Interview Practice · Accepted Answer

使用专用的搜索引擎——**基于倒排索引（inverted index）的 Elasticsearch/OpenSearch**——通过 **CDC** 从你的源 DB 供给数据，并对 index 分片以扩展规模。你的主数据库（Postgres/MySQL）无法在数亿行上做按相关性排序的文本搜索；`LIKE '%term%'` 会扫描每一行。搜索引擎把这个问题反转过来。

```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
```

## 倒排索引——为何它快

普通 index 把 行 → 值 做映射。**倒排索引**把 *词项（term） → 包含它的文档列表* 做映射。搜索"database scaling"会查两个短的倒排表（posting list）并对它们求交——O(匹配文档数)，而非 O(所有文档数)。这正是让 1 亿+ 文档上的亚 100 毫秒搜索成为可能的原因。文本会先被**分析（analyzed）**：分词、转小写、词干化（"running" → "run"）、丢弃停用词（stopwords）——使查询能匹配各种变体。

## 通过 CDC 摄取

不要双写（应用同时写 DB *和* ES）——一次失败就会让它们不一致。相反，用**变更数据捕获（Change Data Capture, CDC）**流式传输变更：**Debezium** 跟踪 DB 的 write-ahead log，把行变更发布到 **Kafka**，再由一个 indexer 把它们应用到 Elasticsearch。这让搜索与源保持**最终一致（eventually consistent）**，并能挺过 ES 停机（事件从 Kafka 重放）。

## 分片与相关性

index 被拆成 **shard**（每个都是自包含的 Lucene index），分布在各节点上；**replica** 增加读 throughput 和 HA。一次查询扇出到所有 shard，每个返回它的 top-k，再由 coordinator 合并。相关性默认使用 **BM25**——词频 × 逆文档频率——可通过 boost、同义词和字段权重来调优。

## 面试视角

面试官检查你是否 (1) 求助于正确的工具而非 `LIKE`，(2) 知道倒排索引*如何*工作，以及 (3) 在不双写的情况下解决**同步问题**。好："用 Elasticsearch。"出色：你为摄取指出 CDC/Debezium，为排序指出 BM25，并接受最终一致性作为换取规模的取舍。

**常见陷阱：**把 Elasticsearch 当作你的真实来源。它是一个派生的 index——不像你的 DB 那样持久/事务性。需要时从源重建它。

## 权衡与故障模式

- **最终一致性：**搜索比写入滞后一个 CDC 管道的 latency（通常亚秒级）。
- **重建索引之痛：**mapping/分析器（analyzer）变更需要全量重建 index——使用别名（alias）实现零停机切换。
- **深度分页：**第 10,000 页很昂贵（scatter-gather）——使用 `search_after`，而非 `from/size`。
- **热点 shard / 倾斜：**文档分布不均；预先选一个好的路由键和足够的 shard 数（它们在创建时就固定了）。
- **相关性调优是持续的：**BM25 默认值很少匹配业务意图——要预期迭代。

倒排索引——为何它快

通过 CDC 摄取

分片与相关性

面试视角

权衡与故障模式

相关问题