高伸缩性的场景

MongoDB 非常适合高伸缩性的场景，它是可扩展性的表结构。基于这点，可以将预期范围内，表结构可能会不断扩展的 MySQL 表结构，通过 MongoDB 来存储，这就可以保证表结构的扩展性。

日志系统的场景

日志系统数据量特别大，如果用 MongoDB 数据库存储这些数据，利用分片集群支持海量数据，同时使用聚集分析和 MapReduce 的能力，是个很好的选择。

分布式文件存储

MongoDB 还适合存储大尺寸的数据，之前介绍的 GridFS 存储方案，就是基于 MongoDB 的分布式文件存储系统。

三个场景点到了 Mongo 的强项，但选型还需要另一半：它不擅长什么、以及文档模型带来的设计约束。只讲适用场景的选型文会误导人在错误场景引入 Mongo。本文补全双向边界与数据建模要点。

为什么是这三个场景：文档模型的特性映射

  • Schema 灵活（BSON 动态字段）：表结构频繁演进的业务（商品属性、表单配置、SaaS 多租户自定义字段）——MySQL 加列要 DDL 锁表/在线变更流程，Mongo 直接写新字段
  • 水平分片内建：分片集群（shard + mongos + config server）按 shard key 自动均衡，日志/事件类海量写入横向扩展
  • 聚合管道（Aggregation Pipeline）：$match/$group/$lookup 在服务端做统计分析，日志报表、行为分析免导出
  • GridFS：大文件切 chunk 存储，元数据与内容一体管理（注意：对象存储 S3/OSS 通常是更专业的选择，GridFS 适合”文件与文档强关联”场景）

不擅长的场景（反向边界）

  • 多文档强一致事务：Mongo 4.0+ 支持多文档事务，但性能与成熟度不及关系库；核心交易（扣款-记账强一致）仍选 MySQL/PG
  • 复杂多表关联：$lookup 能力有限且性能差于关系库 join；高度关联的规范化数据是关系模型主场
  • 高频小更新+强约束：无外键/检查约束，数据完整性靠应用层保证，团队纪律不足时脏数据风险高
  • 深度分页与复杂排序：大 skip 性能差（用 range 查询代替 skip）

数据建模要点（与关系建模的根本差异）

  • 以查询驱动嵌入：把”一起读的数据”嵌进同一文档（订单+订单项），一次读取免 join；关系建模以规范化驱动，Mongo 以访问模式驱动
  • 嵌入 vs 引用抉择：嵌入数据是否无界增长（数组无限长的文档会爆 16MB 上限与更新代价）→ 无界部分改引用
  • shard key 是生死决策：选错（单调递增时间戳）写热点集中、改不了；选型原则=查询覆盖度高+基数足够+非单调
  • 文档 16MB 上限与单文档更新原子性（4.0 前仅单文档原子）是设计硬约束

与 MySQL/ES 的分工组合

典型组合：MySQL 存核心交易（强一致）、Mongo 存灵活结构业务数据（商品/内容/配置）、ES 存检索与日志分析。三者按”一致性要求、结构稳定性、检索需求”三轴分工，而非互相替代。

选型 checklist

  • 结构频繁演进 + 无需强事务 → Mongo 候选
  • 海量写入 + 水平扩展 + 聚合分析 → Mongo 候选（日志/事件/物联网 telemetry）
  • 大文件与文档强关联 → GridFS 候选（否则对象存储）
  • 核心交易/复杂关联/强约束 → 回关系库
  • 全文检索/复杂聚合看板 → 看 ES

MongoDB 的使用场景一句话：结构灵活、写多读模式固定、需要水平扩展的”半结构化”数据主场；记住它的反向边界（强事务、复杂关联、完整性约束），选型才不会从”合适”滑向”滥用”。