2. MongoDB文档模型设计原则
MongoDB 的文档模型与传统关系模型最大的差异，在于它允许把“本来分散在多张表里的数据”直接组织进一个 BSON 文档。这个能力既是优势，也是风险：用得好，一次查询就能拿到完整业务对象；用得不好，文档会无限膨胀、更新冲突频发、索引失效。本节围绕三个核心问题展开：文档结构如何组织、嵌套与引用如何取舍、反范式化到什么程度才合适。
一、文档结构的三个基本约束
设计文档结构前，必须先记住 MongoDB 的三条硬约束，它们直接决定建模边界：
- 单文档 16MB 上限：这是 BSON 文档的硬限制。任何“可能无限增长”的数组都不应内嵌，例如订单的评论、商品的日志、用户的动态。
- 文档整体读写：MongoDB 以文档为原子读写单位。读取一个文档会带回其全部字段，写入也是整文档级别（WiredTiger 内部有字段级更新优化，但语义上仍是文档原子性）。因此文档不宜过宽。
- 索引作用于字段路径：索引建立在具体字段或数组元素上，嵌套层级越深，查询与索引维护成本越高，可读性也越差。
基于这三条约束，可以把文档结构归纳为三种典型形态：扁平结构（字段平铺，适合配置、字典类数据）、嵌套结构（子文档或数组内嵌，适合“整体读取、局部更新少”的数据）、引用结构（通过 _id 关联其他集合，适合“独立生命周期、频繁单独访问”的数据）。
二、嵌套与引用：判断依据不是“好看”，而是访问模式
嵌套与引用的选择，本质是回答两个问题：这份子数据是否总是随父文档一起被读取？它是否会独立增长或被独立查询？
以电商订单为例。订单中的“收货地址”通常在下单时快照一次，之后不再变化，且查询订单时几乎总要展示地址——这类数据适合内嵌为子文档。而订单中的“商品”如果只是下单时的快照（名称、单价、数量），也适合内嵌为数组；但如果商品需要被独立检索、库存需要实时更新，则应把商品主数据放在独立的 products 集合，订单中只保留 productId 与快照字段，形成引用 + 冗余快照的混合结构。
再看社交场景。用户的“最近 20 条动态”适合内嵌，因为读取用户主页时通常一并展示；但“全部历史动态”必须放在独立集合，否则数组会无限增长并触碰 16MB 上限。这里的关键判断是：数组是否有界。有界数组可内嵌，无界数组必须引用。
三、模式设计模式：把常见问题沉淀为可复用结构
MongoDB 社区总结了一批“模式设计模式”，它们不是语法，而是针对特定访问模式的文档组织套路。以下四种在企业平台中最常用：
| 模式 | 适用场景 | 结构要点 |
|---|---|---|
| 内嵌（Embedding） | 子数据随父读取、有界 | 子文档或数组直接放入父文档 |
| 引用（Referencing） | 子数据独立生命周期、需单独查询 | 保存对方 _id，必要时 $lookup 关联 |
| 扩展引用（Extended Reference） | 引用后仍需少量字段避免回表 | 引用 _id 的同时冗余高频字段 |
| 桶模式（Bucket） | 时序、日志、IoT 等海量小文档 | 按时间窗口把多条记录合并进一个文档的数组 |
以桶模式为例，若每秒产生一条设备温度记录，直接一条一文档会导致集合文档数爆炸。可以按“每小时一个桶”组织：
{
_id: ObjectId("..."),
deviceId: "D-1024",
bucketStart: ISODate("2025-03-01T10:00:00Z"),
count: 3600,
readings: [
{ t: ISODate("2025-03-01T10:00:00Z"), v: 23.5 },
{ t: ISODate("2025-03-01T10:00:01Z"), v: 23.6 }
// ... 最多 3600 条
]
}这样单文档大小可控（约几百 KB），查询某设备某小时数据只需一次读取，索引数量也大幅下降。桶模式的核心是用“时间窗口 + 数组”换取文档数量与索引开销的平衡。
四、反范式化的权衡：冗余换读取，代价是写一致性
范式化（Normalization）在关系模型中用于消除冗余、保证一致性；MongoDB 的反范式化（Denormalization）则主动引入冗余，以换取更少的关联查询和更快的读取。这是一笔明确的交易：读性能提升，写复杂度和一致性风险上升。
例如订单中冗余商品名称与单价：读取订单时无需再查 products，一次查询即可渲染订单详情；但商品改名或调价后，历史订单中的快照不应被修改（这恰恰是业务需要的“下单时价格”），因此这种冗余是安全的。反之，若把“商品当前库存”冗余进订单，就会导致库存变化后订单数据失真，必须通过更新所有相关文档来同步，代价极高。
因此反范式化的判断标准是：冗余字段是否“写少读多”且“允许快照语义”。满足则冗余，不满足则引用。对于必须保持一致性的冗余字段，需要设计同步机制，例如在商品更新时通过 updateMany 批量刷新，或使用变更流（Change Stream）异步补偿。
五、落地检查清单
把上述原则落到具体设计时，可以用下面这份检查清单逐项核对。它不是流程，而是设计评审时的判断依据：
- 数组是否有界？无界数组一律引用或分桶，禁止内嵌。
- 子数据是否总随父读取？是则内嵌，否则引用。
- 冗余字段是否允许快照语义？允许则冗余，不允许则引用并设计同步。
- 文档预估大小是否远小于 16MB？接近上限说明结构需要拆分。
- 高频查询字段是否在顶层或浅层？过深路径会影响索引效率与可读性。
- 更新是否会引发跨文档一致性？若会，明确同步方式与失败补偿。
文档模型设计没有唯一正确答案，只有与访问模式匹配的答案。嵌套与引用的取舍、反范式化的程度，都应回到“谁在读、怎么读、写多频繁、能否容忍短暂不一致”这四个问题上。把这些问题在建模阶段问清楚，后续的索引设计、分片键选择与查询优化才有稳定的基础。