📚 课程目录第1章互联网业务数据特征与MongoDB定位

1. 互联网业务数据特征与MongoDB定位

互联网业务的数据系统，和传统企业级系统有一个根本差异：数据形态与访问模式在持续变化。一个电商商品中心，早期可能只有“商品名、价格、库存”三个字段；半年后要加 SKU 规格、促销标签、多语言描述、图文详情、评价聚合；一年后又要支持直播挂车、跨境税率、区域限购。如果每次加字段都要走一次 DDL 变更、停机窗口和上下游同步，业务迭代速度会被数据库结构拖住。理解 MongoDB 的定位，本质上就是理解它为什么适合这类“结构会变、量会涨、并发会冲”的场景，以及它在哪些地方并不合适。

一、互联网业务的四个核心数据特征

高并发：典型场景如秒杀、抢券、直播弹幕、IoT 心跳上报。特征是短时间内大量请求集中打到同一批数据上，读写比可能达到 100:1 甚至更高，且对 P99 延迟敏感。这类负载要求数据库具备水平扩展能力和高效的写入路径，而不是依赖单机垂直扩容。

海量数据：用户行为日志、订单流水、消息记录、设备上报，单表/单集合动辄数十亿条。数据量增长往往不是线性的，而是随业务活动出现尖峰。此时“单机放不下、单表查不动”是常态，分片与冷热分层成为必需。

灵活 Schema：同一业务实体在不同渠道、不同版本、不同租户下字段差异很大。例如商品在自营渠道有“自营仓编码”，在第三方渠道有“供应商结算价”，在跨境场景有“HS 编码”。用固定列表达会产生大量 NULL 或稀疏字段，用 EAV 模型又会把查询复杂度推给应用层。

读写模式多样：既有按主键点查（用户详情、订单详情），也有范围扫描（时间区间流水），还有聚合统计（GMV、留存、漏斗）。同一份数据要同时服务在线交易和离线分析，对存储引擎的索引能力和聚合能力提出复合要求。

二、MongoDB 文档模型为什么契合这些特征

MongoDB 以 BSON 文档为基本存储单元，文档内可以嵌套子文档和数组。这一模型直接对应了“一个业务实体一次读全”的访问习惯。以订单为例，订单主信息、商品明细、收货地址、支付记录可以放在同一个文档中：

{
  _id: ObjectId("..."),
  orderNo: "SO202405180001",
  userId: 88213,
  status: "PAID",
  items: [
    { skuId: "A1001", name: "无线耳机", price: 299.00, qty: 1 },
    { skuId: "B2007", name: "保护壳",   price:  39.00, qty: 2 }
  ],
  address: { province: "浙江", city: "杭州", detail: "..." },
  payInfo: { channel: "WECHAT", paidAt: ISODate("2024-05-18T10:12:03Z") },
  tags: ["618", "plus会员"]
}

这样一次 find({orderNo: "SO202405180001"}) 就能拿到订单全貌，避免了多表 JOIN。对于高并发点查，这是最直接的性能收益。同时，文档模型天然支持字段增减：新增 invoiceInfo 子文档不需要全量迁移，旧文档读取时该字段为 undefined，应用层按需兼容即可。

在扩展性上，MongoDB 通过副本集提供高可用与读扩展，通过分片集群提供水平写扩展。分片键选择得当（如 {userId: "hashed"} 或 {orderNo: 1}），可以把写入压力分散到多个 shard，支撑海量数据与高并发写入。

三、适用场景与边界

MongoDB 适合：内容管理、商品目录、用户画像、订单快照、日志与事件、IoT 设备状态、实时推荐特征存储等“实体聚合明显、读多写多、结构易变”的场景。

但它并非万能。以下情况需要谨慎或选择其他方案：强事务跨多实体（如银行转账涉及多账户强一致扣减），虽然 MongoDB 支持多文档事务，但高并发下事务开销和冲突不可忽视；复杂多表关联分析，如数据仓库中的星型模型查询，关系型或列式存储更合适；超高频计数器，如单条微博点赞数每秒数万次更新，需要结合 Redis 等缓存层或使用 $inc 配合分片；严格 Schema 约束，如金融账务要求字段类型和必填项强校验，需借助 JSON Schema 校验器或应用层保障。

判断口诀：“一个聚合一次读、结构常变、量级要扩”优先 MongoDB；“多实体强事务、复杂关联、强 Schema”优先关系型或其他专用存储。

四、从访问模式反推模型设计

MongoDB 建模的核心不是“先画 ER 图”，而是“先问怎么查”。同一份数据，如果主要按用户查订单，可以把订单嵌入用户文档；如果订单量巨大且需要独立分片，则应把订单作为独立集合，用 userId 做关联字段。嵌入与引用的取舍，取决于读写比例、文档大小上限（16MB）和更新频率。

下图展示了互联网业务特征如何驱动 MongoDB 的定位选择，以及建模时的关键判断路径：

回到实践，判断一个业务是否适合 MongoDB，可以按以下顺序自检：第一，核心实体是否以“聚合根”形式被整体读写？第二，字段是否会在半年内频繁增减？第三，数据量或并发是否已接近单机关系型数据库的瓶颈？第四，是否存在跨实体的强事务需求？前三个为“是”、第四个为“否”时，MongoDB 通常是合理选择。反之，则应优先考虑关系型数据库、数据仓库或缓存层组合。

需要强调的是，MongoDB 的“灵活”不等于“随意”。生产环境中仍应通过 JSON Schema 校验器约束关键字段类型与必填项，通过索引设计保障查询性能，通过分片键规划避免热点。灵活 Schema 的价值在于让结构演进不必停机，而不是让数据质量失去控制。把这两点区分清楚，才能在互联网业务中真正发挥文档模型的优势。