第 28 章：与关系型数据库对比

这是《MongoDB 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 MongoDB 和关系型数据库不是简单替代关系。核心差异在数据模型、事务边界、Schema 演进、扩展方式和查询生态。选型应从访问模式和团队能力出发，而不是“哪个更新”。

28.1 数据模型

关系模型：

users
orders
order_items
products

文档模型：

{
  _id: "o_10001",
  user_id: "u_1001",
  status: "PAID",
  total_amount: NumberDecimal("599.00"),
  items: [
    { sku_id: "sku_10001", quantity: 1 }
  ],
  shipping_address: { city: "Shanghai" }
}

28.2 事务能力

MongoDB：

1. 单文档操作天然原子；
2. 多文档事务支持 ACID；
3. 事务应短小；
4. 分片事务成本更高。

关系型数据库：

1. 多表事务成熟；
2. 隔离级别体系清晰；
3. 复杂约束和外键能力强；
4. 强事务场景通常更稳。

支付、账务、库存等复杂强一致模型，不应仅因为“文档方便”就忽略关系型数据库的成熟约束。

28.3 查询能力

MongoDB 管道表达能力强，但复杂分析通常应迁移到 ClickHouse、Snowflake 或其他分析系统。

28.4 Schema 演进

MongoDB 添加字段：

db.products.updateMany(
  {},
  { $set: { schema_version: 2 } }
)

关系型数据库：

ALTER TABLE products ADD COLUMN schema_version INT;

差异：

灵活 Schema 不代表不需要契约，只是把治理从表结构移到应用和 validator。

28.5 扩展方式

MongoDB：

1. 副本集提供高可用和读扩展；
2. 分片提供水平扩展；
3. 分片键决定路由和分布；
4. 原生分片运维体系成熟。

关系型数据库：

1. 主从或高可用集群；
2. 读写分离；
3. 按业务拆库拆表；
4. 分布式数据库或中间件；
5. 云托管能力差异大。

如果数据天然按租户、用户、设备分片，MongoDB 的文档边界和分片模型比较自然。

28.6 性能模型

MongoDB 优势场景：

1. 按主键取大 JSON 对象；
2. 字段结构变化快；
3. 聚合管道中小型实时统计；
4. 多地域或租户分片；
5. 前置事件或行为存储。

关系型优势场景：

1. 复杂多表事务；
2. 强外键和约束；
3. 复杂 SQL 报表；
4. 稳定关系模型；
5. 精细 SQL 优化器生态。

性能结论必须基于自己的索引、数据量、并发和磁盘压测。

28.7 选型建议

优先考虑 MongoDB：

1. 聚合读整个业务对象；
2. 字段结构变化频繁；
3. 多语言 JSON 契约；
4. 租户或设备数据可自然分片；
5. 需要原生 Change Stream；
6. 团队有文档建模经验。

优先考虑关系型数据库：

1. 强事务和多表约束；
2. 财务账务系统；
3. 复杂 SQL 和报表；
4. 关系稳定且一致性要求高；
5. 团队 SQL 运维成熟。

28.8 混合架构

常见组合：

orders        MySQL / PostgreSQL
product doc   MongoDB
search        Elasticsearch
analytics     ClickHouse
cache         Redis

数据流：

business DB -> CDC / Change Stream -> document store / search / analytics

混合架构必须统一：

1. 实体 ID；
2. 数据契约；
3. 对账任务；
4. 数据归属；
5. 生命周期。

本章小结

MongoDB 适合以文档为访问边界的灵活数据模型，关系型数据库适合强关系和强事务模型。两者可以通过 CDC 或 Change Stream 组合。选型的关键问题是：数据如何被读写、事务边界在哪里、未来如何扩展。

思考题

1. 哪类业务适合内嵌文档模型？
2. 为什么财务系统常选择关系型数据库？
3. MongoDB 的灵活 Schema 需要哪些治理？
4. 什么分片场景适合 MongoDB？
5. 混合架构中如何保证数据一致性？