第5章 数据建模：结构即命运
第 5 章 · 数据建模：结构即命运
章节摘要：MongoDB 建模的核心抉择是内嵌还是引用，原则是"一起读的数据放一起、无界增长的数据拆出去"。本章从一次无界数组撑爆文档的事故讲建模原则、常见模式与模式校验（Schema Validation）。读完本章，你能在需求评审阶段就识别出危险的文档结构。
学习目标
- 能依据访问模式（而非实体关系图）决定内嵌或引用；
- 能说出无界数组、超深嵌套两类结构性风险；
- 能运用分桶、扩展引用、子集等常见建模模式；
- 能用 $jsonSchema 给集合加校验，挡住脏数据。
核心概念速览
金句：关系建模画的是数据长什么样，文档建模画的是数据怎么被用——用错了图纸，后面全是返工。
子章节导航
- 5.1 建模原则：无界数组事故，讲内嵌/引用的判断法与三大原则。复盘认真还原了 16MB 文档的"濒死过程"——撞顶前有十五分钟的延迟爬升期，监控 avgObjSize 本可提前发现。写竞争一节补上了比容量更早到来的约束：数组既是读热点又是写热点时，不撞顶也该拆。
- 5.2 文档结构与模式设计：评论流事故，讲分桶、扩展引用等模式与 Schema Validation。26 亿文档的事故拆解了存储、查询、运维三层同时爆发的机制，属性模式的收益与代价讲清了"什么时候赚什么时候亏"；校验部分给出先 warn 后 error 的上线节奏，避免一挂校验就拦截存量流量。
子章节之间的逻辑关系
5.1 给判断原则，5.2 给落地的模式库与校验手段——先立规矩，再发工具。原则回答"内嵌还是引用"这个二选一，模式回答二选一不够用时的中间态：分桶是"引用但聚拢"、扩展引用是"引用但冗余"、子集是"内嵌但限量"。每个模式都是在 5.1 两条原则的张力之间找平衡点，理解了原则，模式就不需要死记。
原则(5.1) ──► 模式与校验(5.2) │ │ 内嵌还是引用 分桶 · 扩展引用 · jsonSchema
本章的教训有一个共同形状：建模错误都不会立刻报错。16MB 撞顶在第 29 分钟才可见，26 亿文档在第两个月才告急——结构问题的账单总是迟到，但从不缺席。这也是为什么建模评审值得放在需求阶段：改一行代码是分钟级，改一个文档结构是周级。
本章知识点核对清单
离开本章前逐条自查：拿到一份需求时，能否先写出访问模式（谁读、读哪几条、多久读一次）再谈结构；能否对任意一个数组字段回答"上界是多少、敢不敢写进合同"；能否说清分桶、扩展引用、子集三种模式各自化解的是哪条原则的张力；能否写出一个含 required 字段与 bsonType 校验的 $jsonSchema，并说清 validationAction 从 warn 切到 error 的前置条件；能否解释为什么建模错误总是迟到爆发、以及用什么手段让它提前可见。任何一条答不顺，回对应小节把事故复盘重读一遍。
一份评审用的三行模板
把本章方法压进需求评审可直接使用的三行模板：第一行写访问模式，格式是"谁、按什么键、读多少条、频率"；第二行写数组字段的合同上界，写不出数字就标红待定；第三行写拆分决策，内嵌、引用或分桶三选一并给一句理由。三行填不满的需求不该进入表结构设计，这一条写进规范后，第 5 章两起事故的形态在纸面阶段就会被拦下大半。
前置知识与后续延伸
前置：第 2 章文档与数组。延伸：建模决定了分片键的可选空间（第 7 章），也决定了事务的使用频率（第 8 章）。