NoSQL 与文档数据库建模

很多从 MySQL/PostgreSQL 转到 MongoDB 的开发者,第一反应是"这不就是存 JSON 吗,有什么难的"。等真正开始建模,就会发现查询慢、字段散乱、聚合写不动——根本原因是还在用关系建模的脑子套文档库。

文档数据库的建模哲学和关系库几乎是反过来的。关系库追求范式化(消除冗余、保证一致性),文档库追求"聚合在一起、一次读出来"。这篇文章讲清楚 MongoDB 文档建模的核心思路,以及那些实战中真正会踩的坑。

一、文档数据库与关系库的思维差异

关系库的基本单位是"行",一行就是一个平坦的记录。要表达"用户有多个地址",得拆两张表:users 和 addresses,通过 user_id 关联。这是把现实世界的复杂对象拍平成二维表。

文档库的基本单位是"文档"(BSON/JSON),一棵树。一个用户文档可以天然这样长:

// users 集合
{
  _id: ObjectId("..."),
  name: "张三",
  emails: ["[email protected]", "[email protected]"],
  addresses: [
    { type: "home", city: "北京", zip: "100000" },
    { type: "work", city: "上海", zip: "200000" }
  ],
  createdAt: ISODate("...")
}

地址直接嵌在用户里,一次查询就能拿到所有信息。这种"聚合根"的概念,来自领域驱动设计(DDD)——一个文档通常对应一个聚合根,是读写的一致性边界。

关键差异可以总结为:

记住一句话:关系库的 JOIN 是在查询时发生的,文档库的"JOIN"是在建模时就决定好的——要么嵌进去(没有 JOIN),要么引用(手动查询)。这个决策一旦做错,后面改起来非常痛。

二、核心原则:按查询设计 schema

文档建模最反直觉也最重要的一条原则:先想怎么读,再决定怎么存。

关系建模是"按实体设计 schema",先把实体和关系画成 ER 图,第三范式拉满,查询性能交给索引和 JOIN 优化器。这套思路在文档库里行不通——文档库没有强大的 JOIN,查询模式决定了数据该怎么组织。

举个真实场景:博客系统的文章页。前端要展示一篇文章,包括标题、正文、作者名、作者头像、标签列表、前 10 条评论。如果你按关系建模思路做,会拆成 articles / users / tags / comments 四个集合,然后页面渲染时来个四连 $lookup。结果就是慢、复杂、还没法用索引优化。

按查询设计 schema 的做法是:这个页面要的所有东西,尽量塞到一个文档里(或者一次查询能搞定)。

// articles 集合,为"文章详情页"这个查询优化
{
  _id: ObjectId("..."),
  title: "MongoDB 建模指南",
  body: "...",
  author: {                    // 冗余作者信息(反范式化)
    _id: ObjectId("..."),
    name: "张三",
    avatar: "/u/zhangsan.png"
  },
  tags: ["nosql", "mongodb", "backend"],
  comments: [                  // 评论小量且强从属,直接嵌
    { user: "李四", text: "学到了", at: ISODate("...") }
  ],
  createdAt: ISODate("..."),
  updatedAt: ISODate("...")
}

一个 findOne({_id}) 就能渲染整个页面。这就是文档库的威力——你为读路径设计存储。

换个场景:如果同一个系统要做"后台分析报表,按标签聚合文章数、按作者统计 PV",那这套 schema 就不一定最优,可能需要单独维护一份统计集合。文档库经常会出现"为不同查询准备不同形状的集合"的情况,这不是浪费,是为读性能付费。

三、嵌套 vs 引用:这是一道选择题

什么时候该把数据嵌进父文档,什么时候该独立成集合用引用?这是文档建模的核心选择题。判断标准其实不复杂:

嵌套(Embedding)适合的场景:

• 一对少(1-to-few),数量有上限
• 强从属关系,子文档没有独立的生命周期
• 总是和父文档一起读

典型案例:文章 + 评论(小量)。一篇博客下面的评论通常就几十条,且永远和文章一起显示,嵌进去最自然:

// 嵌套:评论是文章的一部分
{
  _id: articleId,
  title: "...",
  comments: [
    { _id: ObjectId("..."), user: "李四", text: "...", at: ISODate("...") }
    // 几十条没问题
  ]
}

引用(Referencing)适合的场景:

• 一对多中的"多"数量大或无上限
• 多对多关系
• 子文档有独立的生命周期,会被单独查询/更新

典型案例:用户 + 订单。一个用户可能下几千个订单,每个订单还要独立查询、统计、分页展示。如果把订单嵌进用户文档,用户文档会膨胀到几十 MB,每次更新都重写整块——这是反模式。正确做法是独立集合 + 引用:

// users
{ _id: userId, name: "张三", ... }

// orders —— 独立集合,引用用户
{ _id: orderId, userId: userId, amount: 99, items: [...], at: ISODate("...") }

// 查某用户的订单(分页)
db.orders.find({ userId }).sort({ at: -1 }).limit(20)

一个简单的判断口诀:"会不会无限增长"和"要不要单独查"。两者只要有一个是 yes,就果断拆出去用引用。

四、反范式化:用空间换读性能

关系建模视冗余为洪水猛兽(更新异常),文档建模却把适度的冗余当作常规武器。这就是反范式化(denormalization)。

最常见的例子:文章里冗余存作者名。关系库里你只会存 author_id,显示时 JOIN users 表拿名字。文档库里你直接在文章文档里存一份 author.name,读文章页时一次查询就够,省掉了 $lookup。

// 反范式化:把"读时需要"的作者信息冗余进文章
{
  _id: articleId,
  title: "...",
  authorId: ObjectId("..."),
  authorName: "张三",      // 冗余字段
  authorAvatar: "/u/zhangsan.png"  // 冗余字段
}

代价是什么?作者改名时,要同步更新他名下所有文章的 authorName。这就是反范式化的本质交换:用写的复杂性换读的速度。在"读多写少"的场景下(作者改名一年也发生不了几次,但文章被读几万次),这笔交易非常划算。

实战中有几种常见的反范式化手段:

1. 冗余字段:如上例,把高频读取但低频更新的关联字段冗余存一份。
2. 快照:订单里存一份下单时刻的商品信息(价格、标题),即使商品后来改价改标题,历史订单永远显示下单时的情况。这种冗余甚至是正确性必需的。
3. 物化视图:为高频查询维护一份预聚合的集合,比如每小时的统计结果单独存。

反范式化不是越多越好。每次冗余都在给自己增加"更新时要同步多处"的债。原则是:只冗余那些读频率远高于写频率的字段。

五、文档大小与无限增长数组:反模式警告

MongoDB 单文档有 16MB 的硬上限。这个限制不是性能建议,是物理约束——超过直接报错写不进去。所以任何"无限往一个文档里塞东西"的设计都是反模式。

最常见的反模式是无限增长的数组。新手很容易写出这样的设计:

// 反模式:把所有评论嵌进文章
{
  _id: articleId,
  comments: [
    // 几万条评论......
  ]
}

热门文章评论轻松上万条,文档很快就超 16MB 崩掉。就算没超上限,每次加一条评论都要重写整个文档(虽然 MongoDB 有 $push 优化位置),性能也会急剧下降。

正确的做法是评论数量大时就拆成独立集合,用引用:

// comments 独立集合
{ _id: commentId, articleId: articleId, user: "...", text: "...", at: ISODate(...) }

// 查文章的评论,带分页
db.comments.find({ articleId }).sort({ at: -1 }).skip(20).limit(20)

判断标准很简单:如果一个数组理论上有可能无限增长,就一定不要嵌。哪怕今天只有 10 条,业务上去了就是几万条,到时候迁移很痛。

另一个相关反模式是把"关系库的多对多中间表"硬套成嵌套数组——比如用户文档里嵌一个 friendIds: [...] 几千个 ObjectId 的数组。虽然不会爆 16MB,但每次查朋友关系都要把整个数组读进来,索引效率也差。这种用专门的关联集合(类似关系库的中间表)更合适。

六、事务与一致性:能做但别滥用

MongoDB 从 4.0 开始支持多文档事务,4.x 版本进一步增强了分布式事务。很多人听到"MongoDB 支持事务了"就放心地像用 MySQL 一样到处开事务。这是误解。

MongoDB 的单文档原子性是天然的——对一个文档的任何更新(哪怕修改了多个嵌套字段)都是原子的,不需要显式事务。所以如果你的数据建模做得到位(把强一致性的数据聚合在一个文档里),你根本不需要事务。

跨文档/跨集合事务的问题在于:

• 性能代价高:比单文档更新慢一个数量级以上,涉及协调开销。
• 锁竞争:长事务会拖慢整个系统。
• 限制多:事务有大小和时长上限,不适合重负载场景。

所以正确的设计思路是:把一致性边界尽量收敛到单文档内。需要强一致性的关联数据,在建模时就聚合进同一个文档,靠单文档原子性保证一致,而不是靠跨文档事务去补。

真要用跨文档事务的场景是那些无法避免的跨聚合操作:比如转账(扣一个账户、加另一个账户)、订单与库存的联动。这种操作没有天然的聚合根,才显式开事务。日常 CRUD 大可不必。

// 必须用事务的典型场景:转账
const session = db.getMongo().startSession()
session.startTransaction()
try {
  db.accounts.updateOne({ _id: fromId }, { $inc: { balance: -100 } }, { session })
  db.accounts.updateOne({ _id: toId },   { $inc: { balance:  100 } }, { session })
  session.commitTransaction()
} catch (e) {
  session.abortTransaction()
}

七、何时用文档库,何时用关系库

文档库不是银弹,关系库也不是遗物。选型的核心是看业务特征。

适合文档库(MongoDB)的场景:

• Schema 灵活多变:字段不固定、频繁加新字段。比如内容管理、商品 SKU(不同品类属性完全不同)、日志、配置。
• 读多写少 + 文档天然聚合:博客、CMS、商品详情页——一次查询要拿一坨关联数据的场景。
• 水平扩展需求大:MongoDB 的分片机制对水平扩展友好。
• 快速迭代的产品:schema 不用提前定死,适合 MVP 阶段。

适合关系库(MySQL/PostgreSQL)的场景:

• 强一致性要求高:金融、交易、库存——这种场景关系库的事务和约束是更稳的选择。
• 复杂关联查询多:报表、BI、多表 JOIN 是常态的业务。关系优化器几十年的积累,$lookup 比不了。
• 数据天然是"多对多 + 规范化":比如 ERP、教务系统,实体关系网复杂且没有明显的聚合根。
• 写密集 + 多表事务:需要严格的隔离级别和行锁语义。

一个现实经验:很多系统是混合的。用户、订单、账务跑在 PostgreSQL,保证强一致;内容、评论、动态 Feed 跑在 MongoDB,享受聚合的读性能。不用非此即彼。

八、别把文档库当关系库用

最后说一个最常见、也最致命的坑:带着关系建模的脑子用文档库。

典型症状是:建了一堆集合,每个集合都是扁平的几行字段,然后用 _id 互相引用,查询时疯狂 $lookup,还抱怨"MongoDB 怎么 JOIN 这么难用"。这不是 MongoDB 的问题,是你用错了。

把每个集合都拆成第三范式,本质上是把文档库当成了一个"没有外键约束、JOIN 很弱的关系库"。这种用法会同时失去两边的好处:既没有关系库的强一致性和优化器,也没有文档库的聚合读性能。

正确的姿势是:承认文档库是另一套思维。它假设你的数据可以按聚合根组织、读路径相对固定、schema 会演化、冗余可以接受。如果你的业务根本不是这种形状(比如天然就是复杂多对多关系网、强一致性重于一切),那也许根本不该选文档库——选了就要按它的规则玩。

一个简单的自检:你最近写的 MongoDB 查询,有几个用了 $lookup? 如果绝大多数查询都在 $lookup 拼数据,说明你的建模有问题——要么数据该嵌的没嵌,要么这个业务根本该用关系库。

小结

• 按查询设计 schema:先想清楚最频繁的读路径长什么样,再决定文档怎么组织,而不是按实体范式先存好再说。
• 嵌套 vs 引用看增长性:一对少且强从属就嵌,可能无限增长或有独立查询需求就引用。
• 反范式化是常规武器:适度冗余换读性能,但只冗余"读多写少"的字段,并接受更新要同步多处的代价。
• 守住单文档一致性边界:能用单文档原子性解决就别开跨文档事务;数据建模到位,MongoDB 事务的需求会很少。
• 别硬套关系范式:把文档库当关系库用是最常见的坑,数据形状不匹配就果断换关系库。

关系库消除冗余,文档库拥抱聚合——建模的第一性问题永远是"这份数据,读的时候长什么样"。