产品特性与边界
MongoDB 的主要价值是让应用以完整文档作为读写和原子更新边界。BSON 支持嵌套文档、数组、日期、二进制、Decimal128 和 ObjectId 等类型，比文本 JSON 拥有更明确的数据库类型语义。
主要能力
| 能力 | 说明 |
|---|---|
| 文档模型 | 一条记录可以直接表达对象、子对象和集合 |
| 灵活结构 | 同一 Collection 的文档可以具有不同字段，可用验证规则约束 |
| 原子文档更新 | 单文档写入原子，可用更新操作符修改局部字段或数组 |
| 聚合管道 | 通过多个 Stage 完成过滤、变换、分组、关联和窗口计算 |
| 多种索引 | 支持复合、数组、TTL、地理、文本、Wildcard 和 Hashed 等索引 |
| 复制集 | 通过 Oplog 复制、选举和故障切换提供冗余 |
| 分片 | 把 Collection 按 Shard Key 分布到多个 Shard |
| Change Stream | 以受支持的接口订阅复制集或分片集群中的数据变化 |
BSON 不等于 JSON
javascript
{
_id: ObjectId("507f1f77bcf86cd799439011"),
username: "alice",
balance: Decimal128("100.00"),
createdAt: ISODate("2026-08-20T08:00:00Z"),
tags: ["user", "vip"],
profile: { city: "Hefei", level: 3 }
}ObjectId、Decimal128 和 Date 是 BSON 类型，不是普通 JSON 字符串。驱动序列化时如果把金额写成 Double、把日期写成字符串，同一个 Field 就可能出现多种类型，进而影响排序、比较、索引和聚合结果。
文档大小存在上限，超大二进制通常使用 GridFS 或外部对象存储，而不是无限嵌入一个 Document。
适合的场景
| 场景 | 适配原因 | 需要评估 |
|---|---|---|
| 内容与商品目录 | 不同类别字段差异大，常整体读取 | 属性检索索引数量和验证规则 |
| 聚合根数据 | 主对象与从属数据生命周期一致 | 文档增长、数组上限和并发热点 |
| 事件与设备数据 | 高写入、按时间和设备查询 | 时序集合、TTL、分片键和保留周期 |
| 用户画像与配置 | 嵌套结构、字段逐步演进 | 局部更新和历史版本兼容 |
| 地理位置服务 | GeoJSON 与 2dsphere 索引 | 坐标顺序、查询范围和精度 |
不应仅凭这些理由选择
| 常见理由 | 问题 |
|---|---|
| “不用设计表结构” | 结构仍存在于数据、代码、索引和验证规则中，只是约束更晚暴露 |
| “数据量大” | 单纯容量大不能决定模型，访问模式、分片键和运维能力更关键 |
| “MongoDB 一定更快” | 性能取决于文档布局、索引、工作集、写关注和查询形态 |
| “天然高可用” | 复制集还需要跨故障域部署、正确多数派、连接配置和切换演练 |
| “支持事务，所以能照搬关系模型” | 多文档事务可用，但跨文档协调会削弱文档模型的优势 |
如果数据高度规范化、依赖大量临时关联、强外键约束和复杂跨实体事务，关系型数据库通常更自然。MongoDB 的选择应来自聚合边界和访问模式，而不是来自“NoSQL”标签。