MongoDB 文档模型设计：从关系型思维到文档型思维的转变

原创于 2026-07-20 14:04:51 发布 · 458 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

MongoDB

前言

前两篇我们把环境搭好、把基础语法过了一遍。到这里，“会用” MongoDB 已经不成问题——但会用和用好之间，隔着一整套设计思维的鸿沟。

这篇是整个专栏的第一个转折点。很多从 MySQL 转过来的开发者，装完 MongoDB 干的第一件事，就是把原来的表结构一张一张"翻译"成集合：用户表变 users 集合、订单表变 orders 集合、订单明细表变 order_items 集合，然后照旧用 ID 去关联。能跑，但这基本等于开着跑车挂一档——你花钱买了文档模型的表达力，却还在用关系型的思路使用它。

文档模型最核心的能力，是让一份"业务上原本就该在一起"的数据，在物理上也真的存在一起。理解这一点，比记住任何 API 都重要。这篇我们就把这套思维掰开讲透：关系型和文档型的根本差异在哪、内嵌与引用到底怎么选、有哪些反直觉的坑。

一、关系型思维的"惯性"从哪来

关系型数据库的设计，核心目标是消除冗余。范式（Normalization）那套理论，本质就一句话：同一份数据只存一次，其他地方用外键引用它。

举个例子，一个博客系统，关系型会这么设计：

users 表：      id, name, email
posts 表：      id, user_id, title, content
comments 表：   id, post_id, user_id, content
tags 表：       id, name
post_tags 表：  post_id, tag_id   （多对多中间表）

要查一篇文章的完整信息（作者、内容、评论、标签），你得 JOIN 四五张表。这在关系型世界里天经地义——存储时拆散、查询时拼回，用 JOIN 的代价换取数据的零冗余和强一致。

这套思维的惯性极强，强到大多数人换了数据库都改不过来。但问题是：MongoDB 没有真正意义上高效的 JOIN。 它的 $lookup 能用，但性能和使用场景都有明显限制。如果你还按范式拆表，等于把关系型最贵的操作（JOIN），搬到了一个不擅长它的数据库上。

二、文档型思维：先问"数据怎么被读"

文档模型的设计起点完全不同。关系型问"这份数据的本质结构是什么"，文档型问的是——“这份数据会被怎么读取和使用”。

这是最关键的思维转变：从"以数据为中心"转向"以查询为中心"（Query-Driven Design）。

还是博客那个例子。一篇文章连同它的标签、作者名，通常是一起被读出来展示的。那么在文档模型里，它就应该长成一个文档：

{
  "_id": ObjectId("..."),
  "title": "MongoDB 文档模型设计",
  "content": "...",
  "author": {
    "id": ObjectId("..."),
    "name": "Tree"
  },
  "tags": ["mongodb", "database", "设计"],
  "createdAt": ISODate("2026-07-17T10:00:00Z")
}

原来要 JOIN 三张表（posts、users、tags、post_tags）才能拼出来的东西，现在一次查询、一个文档全拿到。没有 JOIN，没有拼接，读取路径短到极致。

这就是文档模型的核心价值主张：用存储时的适度冗余，换取读取时的极致简单。 它和关系型的取舍方向正好相反。

在这里插入图片描述

三、核心抉择：内嵌（Embedding）还是引用（Referencing）

这是文档模型设计里绕不开、也最容易做错的决策。所谓建模，很大程度上就是在为每一对相关联的数据回答：把它嵌进来，还是用 ID 引用它？

3.1 内嵌：把关联数据直接塞进文档

内嵌就是把关联的数据作为子文档或数组，直接放进父文档里。上面文章带 author、tags 的例子就是内嵌。

优点：

一次读取拿到所有数据，没有 JOIN，读性能极好
数据在物理上聚在一起，符合"一起被读"的访问模式
单文档更新是原子的，天然保证这部分数据的一致性

代价：

冗余：author.name 存在每篇文章里，作者改名要更新多处
文档会变大，有 16MB 上限（后面细说）

3.2 引用：只存对方的 ID

引用就是关系型的老路子——只存关联对象的 _id，用的时候再查一次（或 $lookup）。

// posts 文档只存 author_id
{
  "_id": ObjectId("..."),
  "title": "MongoDB 文档模型设计",
  "author_id": ObjectId("user_123")
}

优点：

无冗余，作者信息只存一份，改名只改一处
父文档保持精简

代价：

读取要多次查询或 $lookup，性能不如内嵌
失去了单次读取的简单性

3.3 决策的黄金准则

到底选哪个？记住这几条经验法则，能覆盖绝大多数场景：

判断维度	倾向内嵌	倾向引用
关系类型	一对一、一对少量	一对海量、多对多
读写比例	读多写少	写多、频繁独立更新
访问模式	总是一起读取	经常独立访问子数据
数据体量	子数据小而有界	子数据大或无限增长
一致性要求	能接受冗余	必须单一数据源

一句话总结这套准则："一起读、量可控、改得少"就内嵌；"独立用、会疯长、常更新"就引用。

在这里插入图片描述

3.4 第三条路：引用 + 冗余关键字段（混合模式）

实际生产里，用得最多的其实既不是纯内嵌、也不是纯引用，而是二者的折中——引用 + 冗余几个关键字段。这是从"二选一的教条"迈向"工程现实"的关键一跃，很多人卡在这里。

看一个最典型的场景：订单列表页。列表要展示每个订单的用户名，但订单和用户显然是引用关系（用户是独立大实体）。如果纯用引用：

// 订单只存 user_id
{ "_id": ObjectId("..."), "user_id": ObjectId("user_123"), "total": 8597 }

那么渲染一个 20 条的订单列表，就要先查 20 个订单，再拿着 20 个 user_id 回头查一遍 users 集合拿名字——经典的 N+1 查询问题。

混合模式的做法是：在订单里保留 user_id 引用的同时，冗余一个 user_name：

{
  "_id": ObjectId("..."),
  "user_id": ObjectId("user_123"),   // 保留引用：需要完整用户信息时用它
  "user_name": "张三",                // 冗余：列表展示直接用，免去 join
  "total": NumberDecimal("8597")
}

这样列表页一次查询就够了，需要用户完整信息时再靠 user_id 去查。用一个字段的冗余，换掉了一次额外查询。

在这里插入图片描述

当然，冗余是有代价的：用户改名时，你需要考虑历史订单里的 user_name 要不要跟着变。而这恰恰要回到业务语义去判断——

关键判断：冗余字段是"快照"还是"缓存"？

如果它代表历史事实（如"下单时这个用户叫什么"），那就该冻结，用户改名不影响它，反而是正确的。
如果它只是为了加速展示的副本（如商品列表里冗余的分类名），那用户/源数据变更时，就需要同步更新所有冗余处（可用后台任务批量刷）。

想清楚这个问题，你才算真正理解了文档建模里"冗余"的分量——它不是偷懒，而是一个需要主动管理的工程决策。

四、三种关系怎么建模

把上面的准则套到实际的一对一、一对多、多对多关系上。

4.1 一对一 / 一对少量：优先内嵌

用户和地址、用户和个人资料，这种一对一或一对少量，几乎无脑内嵌：

{
  "_id": ObjectId("..."),
  "name": "Tree",
  "profile": {
    "avatar": "http://...",
    "bio": "后端开发"
  },
  "addresses": [
    { "type": "home", "city": "Beijing" },
    { "type": "work", "city": "Shanghai" }
  ]
}

一个人有几个地址？撑死几个。这种"有界的少量"数据，内嵌是最优解。

4.2 一对多（多的一方无限增长）：用引用

典型的坑：博客文章和它的评论。新手很容易把评论直接内嵌成数组：

// ❌ 危险设计：评论无限增长
{
  "_id": ObjectId("..."),
  "title": "...",
  "comments": [ /* 一篇爆款文章可能有几万条评论 */ ]
}

这就踩中了后面要讲的无界数组大坑。评论数量没有上限，文档会一直膨胀，直到撞上 16MB 限制。这种情况应该反过来——评论单独成集合，用 post_id 引用文章：

// ✅ comments 集合，引用 post
{ "_id": ObjectId("..."), "post_id": ObjectId("..."), "content": "..." }

4.3 多对多：混合策略

学生和课程、文章和标签这种多对多，通常用引用，或者根据读取方向做适度冗余。比如文章内嵌少量标签名（读文章时直接展示），标签集合再单独维护（管理标签时用）。

这里引出一个重要观念：文档模型允许、甚至鼓励为了不同的读取场景做适度冗余。 这在关系型里是要被打的，在文档型里是正常操作。

五、几个反直觉的设计陷阱

这一节是重点，都是生产环境里真实会崩的坑。

5.1 无界数组（Unbounded Array）

前面提过的评论就是典型。任何"可能无限增长"的数组，都不该内嵌。 原因有三：

16MB 文档上限：MongoDB 单个文档硬上限 16MB，无界数组迟早撞墙。
性能悬崖：文档变大后，每次更新都要重写整个文档，$push 一条评论却要搬动几 MB 数据。
索引低效：超大数组的多键索引会急剧膨胀。

判断标准很简单：这个数组的元素数量有没有一个明确的上限？ 有（如一个用户的几个地址）→ 可内嵌；没有（如评论、日志、点赞记录）→ 必须引用。

在这里插入图片描述

把"性能悬崖"量化一下，你会更有体感。假设一条评论文档约 200 字节：

16MB / 200B ≈ 8 万条评论就撑爆一个文档——热门文章分分钟超。
更要命的是撞墙之前就已经很慢了：MongoDB 更新文档时，一旦文档变大超过了预留空间，就要把整个文档挪到新位置重写。当文档涨到 2MB，你每 $push 一条 200 字节的评论，底层可能要搬动 2MB 数据。写入成本随文档大小线性上升，这就是"悬崖"——不是某一刻突然崩，而是越用越慢，直到不可用。

怎么实际测量文档大小？ 别靠猜，MongoDB 给了工具：

// 查单个文档的 BSON 字节大小
Object.bsonsize(db.posts.findOne({ _id: ObjectId("...") }))

// 查整个集合的统计：文档数、平均文档大小、总大小
db.posts.stats()
// 重点看 avgObjSize（平均文档大小）、count（文档数）

// 找出集合里最大的那批文档（按某个数组长度排序，揪出异常大文档）
db.posts.aggregate([
  { $project: { size: { $bsonSize: "$$ROOT" }, title: 1 } },
  { $sort: { size: -1 } },
  { $limit: 5 }
])

上线前用 $bsonSize 排一遍最大文档，是个性价比极高的习惯——能在文档撑爆之前就发现"某个大 V 的文章评论数组已经 5MB 了"这类隐患。

5.2 无界数组的解法之一：桶模式（Bucket Pattern）

引用能解决无界数组，但对某些场景（尤其是时序数据：物联网传感器、日志、股价、点赞流水）还有更精细的方案——桶模式，这是 MongoDB 官方推崇的设计模式。

纯引用会走向另一个极端：一个传感器每秒一条读数，一天就是 8.6 万条独立文档，一个月几百万条。文档数量爆炸同样会带来问题：索引变大、每条文档都有 _id 等固定开销、查询要扫海量小文档。

桶模式的思路是折中：不是一条数据一个文档（太碎），也不是全塞进一个文档（无界），而是按某个维度（通常是时间）把一批数据"装进一个桶"。比如"一个传感器一小时的读数"打包成一个文档：

{
  "_id": ObjectId("..."),
  "sensor_id": "sensor_01",
  "start": ISODate("2026-07-17T10:00:00Z"),   // 这个桶的时间窗口
  "count": 60,                                 // 桶里有多少条
  "measurements": [                            // 一小时内的读数，有界（最多 60 条）
    { "t": ISODate("...10:00:00Z"), "temp": 25.1 },
    { "t": ISODate("...10:01:00Z"), "temp": 25.3 }
    // ...
  ]
}

在这里插入图片描述

这样既避免了单文档无界膨胀（每个桶大小可控），又大幅减少了文档总数（60 条变 1 条），索引和查询都更高效。

MongoDB 5.0 之后还专门推出了时间序列集合（Time Series Collections），在底层自动帮你做类似的分桶和压缩，时序场景可以直接用它，不用手动实现桶模式。这块我们放到后面专门的篇章展开。

5.3 过度内嵌导致的"大文档"

即使没到无界的程度，过深、过大的内嵌也会拖慢性能。因为 MongoDB 读写的最小单位是整个文档——你只想读文章标题，它也得把内嵌的几百条评论一起从磁盘捞出来。

记住这条铁律：MongoDB 没有"只读文档的一部分字段就只加载那部分"这回事，读一个文档就是读它的全部。 内嵌越多，每次读取的固定成本越高。

5.4 为了"范式"而拆分

从关系型过来的人常犯的反向错误：明明是"一起读、量又小"的数据，非要拆成两个集合再 $lookup。这是把关系型的洁癖带了过来。文档模型里，适度冗余不是错误，而是设计手段。

5.5 忽略数据的"生命周期"

一份数据是频繁修改还是写完基本不动，直接影响内嵌还是引用。订单里的下单时收货地址应该内嵌快照（哪怕用户地址后来改了，历史订单也该保留当时的地址），而用户当前的默认地址则适合能改的引用。同一份"地址"，因生命周期不同，建模方式完全不同。

六、一个完整的建模案例：电商订单

把上面所有原则串起来，看一个订单该怎么设计。先列访问模式（这是文档建模的第一步，永远先问怎么读）：

查订单详情：要一次拿到商品清单、收货信息、金额
商品信息（名称、单价）在下单时快照固定，之后商品改价不影响历史订单
用户可能有海量历史订单

综合判断后的设计：

{
  "_id": ObjectId("..."),
  "user_id": ObjectId("user_123"),        // 引用：用户是独立的大实体
  "status": "paid",
  "shipping": {                            // 内嵌快照：下单时的收货信息
    "name": "张三",
    "phone": "138****0000",
    "address": "北京市朝阳区..."
  },
  "items": [                               // 内嵌：商品明细快照，数量有界
    { "product_id": ObjectId("..."), "name": "iPhone 15", "price": NumberDecimal("5999"), "qty": 1 },
    { "product_id": ObjectId("..."), "name": "AirPods",   "price": NumberDecimal("1299"), "qty": 2 }
  ],
  "total": NumberDecimal("8597"),
  "createdAt": ISODate("2026-07-17T10:00:00Z")
}

在这里插入图片描述

拆解每个决策：

user_id 用引用：用户是独立的大实体，有自己海量的其他数据，不可能内嵌。
shipping 内嵌快照：下单时的收货信息，属于这个订单的历史事实，必须冻结，不能因用户改地址而变。
items 内嵌：一个订单的商品数量是有界的（几十件顶天了），且总是和订单一起读；同时 name、price 存的是下单时的快照，商品后续改价不影响它。
product_id 保留引用：万一要跳转到商品详情页，还能通过它查到当前商品。

一个文档，把引用、内嵌、快照三种手段全用上了——这就是文档建模的思维方式：没有教条，只有针对访问模式的权衡。

七、灵活的边界：别让 Schema-less 变成"无法无天"

文档模型的 Schema-less（无固定结构）是把双刃剑。前面一直在讲它带来的灵活，但如果一个团队十几个人往同一个集合里写数据，灵活很快会变成灾难：

有人把年龄写成数字 18，有人写成字符串 "18"
有人字段叫 phone，有人叫 phoneNumber，还有人拼错成 phon
本该必填的 user_id，某段旧代码干脆没写

这些脏数据一旦落库，后面的查询、聚合、索引全会被坑到，排查起来还极其痛苦。所以生产环境里有一条重要认知：Schema-less 不等于不要 Schema，只是把 Schema 的约束权交到了你手里。

MongoDB 提供了 JSON Schema 校验（Schema Validation） 来兜底。你可以在创建集合时定义一套规则，写入不符合规则的文档会被拒绝：

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "email", "age"],        // 必填字段
      properties: {
        name: {
          bsonType: "string",
          description: "name 必须是字符串且必填"
        },
        email: {
          bsonType: "string",
          pattern: "^.+@.+$"                      // 简单邮箱格式校验
        },
        age: {
          bsonType: "int",
          minimum: 0,
          maximum: 150                            // 年龄范围约束
        }
      }
    }
  },
  validationLevel: "strict",      // strict：所有插入和更新都校验
  validationAction: "error"        // error：不符合就拒绝；warn：只记警告不拒绝
})

这样一来，往 users 写一条 age 是字符串、或者缺了 email 的文档，会直接被拒绝，脏数据从入口就被挡住。

怎么把握这个度？ 不必一上来就给所有集合套最严格的校验——那会牺牲文档模型宝贵的灵活性。实践中的平衡点通常是：核心业务集合（订单、用户、支付）用 validation 守住关键字段和类型，日志、埋点这类容忍度高的集合保持宽松。 灵活和约束不是二选一，而是按集合的重要性分级管理。

这一节的意义，正好呼应本专栏"敢上生产"的调性——设计文档模型时，既要享受 Schema-less 的灵活，也要在该收口的地方主动加上约束。

八、总结

从关系型到文档型，思维转变就这几条，但每一条都需要刻意练习去扭转惯性：

从"以数据为中心"到"以查询为中心"：先问数据怎么被读，再决定怎么存。
JOIN 不是理所当然的：MongoDB 里应尽量靠合理的文档结构避免 JOIN，而不是照搬范式。
内嵌 vs 引用，还有混合模式：一句话——"一起读、量可控、改得少"就内嵌；"独立用、会疯长、常更新"就引用；列表展示等场景则用"引用 + 冗余关键字段"的折中。
适度冗余是设计手段，不是错误：这是和关系型最大的观念差异，但要想清楚冗余字段是"快照"还是"缓存"。
警惕无界数组和大文档：16MB 上限和"整文档读写"是两条必须记住的物理约束；时序场景用桶模式或时间序列集合化解。
Schema-less 不等于不要 Schema：核心集合用 JSON Schema 校验守住关键字段，把脏数据挡在门外。

把这套思维内化了，你设计出来的 MongoDB 结构才会又快又稳，而不是一个披着集合外衣的关系型数据库。

下一篇我们进入索引——文档模型设计得再好，没有合适的索引，查询照样慢。我们会讲透 MongoDB 的索引类型和那条决定复合索引成败的 ESR 法则。

标签

#mongodb #数据库