S13-A04 · 聚合搜索设计与文档库（MongoDB）

适用读者：要做"跨多个数据源的统一搜索"、或在选文档库的人。
前置：S13-A02。
覆盖旧文：437（通用型聚合搜索设计，277 点）+ S12 移交的 5 张 MongoDB 卡（2616/1844/494/1571/1580，duplicate_ref）。
覆盖扩展：E-S13-013（聚合设计）、E-S13-014（MongoDB 边界）。
上一篇：S13-A03 · 向量库选型：ES vs 专用向量库
下一篇：S13-X01 · 八股速查。

1. 一句话结论

聚合搜索的本质是"统一查询协议 + 多源适配 + 统一排序"；它不要求把所有数据搬进一个库，而是要求"对外像一张表"。

客户端 → 统一查询 DSL
            ├─ 适配器 A（ES）   → 相关度排序
            ├─ 适配器 B（MySQL）→ 精确过滤
            └─ 适配器 C（向量库）→ 语义召回
                    ↓
                合并 + 重排 + 权限过滤

2. 聚合设计的五个组件（E-S13-013）

组件	职责
统一查询协议	分页/过滤/排序/关键词的公共表达
适配器	把统一协议翻译成各源的原生查询
合并层	去重、打分归一、分页对齐
权限过滤	在合并前过滤（安全边界）
降级	某源超时 → 返回部分结果并标注

两条铁律：

铁律	原因
权限过滤必须在召回阶段	合并后再过滤会泄露结果数/顺序
分页要"源内多取、合并后截断"	各源分页语义不同

3. MongoDB 的适用边界（E-S13-014、S12 移交卡）

适合	不适合
文档型数据（结构不固定）	强事务/多表关联
快速迭代的 schema	复杂聚合统计（性能）
内容/聊天记录/日志型数据	需要严格 ACID 的账务

"MongoDB vs MySQL vs ES"：

需求	选
事务与关系	MySQL
灵活文档 + 中等查询	MongoDB
全文检索/聚合分析	ES

判据："我的数据结构会频繁变吗？" 会 → MongoDB；固定且要事务 → MySQL。

3.1 与缓存的关系（S12 移交卡 A-1571/A-1580）

"MongoDB 与 Ehcache/Redis 的选型" 本质是"存储 vs 缓存"：MongoDB 是数据源，Redis 是缓存层——两者不是竞品。

4. 聚合搜索的验收指标

指标	说明
召回率	相关结果是否被找到
延迟 P99	多源中最慢的那个决定整体
部分失败率	降级比例
权限正确性	越权返回数必须为 0

5. 五个误区

误区	真相
"聚合搜索要先把数据都搬到一个库"	适配器模式即可
"先合并再过滤权限"	会泄露信息
"MongoDB 能替代 MySQL"	事务与关联弱
"MongoDB 和 Redis 是竞品"	存储 vs 缓存
"多源聚合延迟取平均"	取最慢的（木桶效应）

6. 自检（架构师版）

聚合搜索的五个组件？
两条铁律是什么？
MongoDB 的三个适用场景与三个禁区？
多源聚合延迟为什么取最慢？
权限过滤为什么必须在召回阶段？

7. 下一篇

S13-X01 · 搜索八股速查

最后一篇是附录索引，随后进入 S14。

本篇属于系列《S13 · 搜索与文档存储》。旧文来源：A-437 + S12 移交的 MongoDB 5 卡；扩展点 E-S13-013/014。