MongoDB文档模型设计最佳实践

MongoDB是NoSQL数据库中最流行的文档数据库。它的灵活schema设计是优势也是陷阱——如果没有良好的文档模型设计，后期数据膨胀后重构成本极高。本文分享MongoDB文档模型设计的核心原则和常见模式。

数据层的稳定性，往往决定了一个系统的下限。「MongoDB文档模型设计最佳实践」所涉及的数据库选型与高可用架构，正是最容易「平时看不见、出事要人命」的部分：平时跑得平稳，一旦出问题就是数据丢失或业务停摆，因此值得投入系统性的精力去治理。

数据一起访问的放在一起：和关系型数据库的范式化设计相反，MongoDB推荐反范式化——将经常一起读取的数据嵌入到同一个文档中。这样可以一次查询获取所有数据，避免多次查询或$lookup（类似JOIN）。

16MB文档大小限制：单个MongoDB文档最大16MB。设计时要注意数组字段不能无限增长。如果一个用户可能有上万个订单，不要把订单全部嵌入用户文档。

考虑读写比例：读多写少的场景适合嵌入（减少查询），写多读少的场景适合引用（减少更新开销）。

一对一嵌入：用户和用户资料。将profile嵌入user文档中，一次查询获取完整信息。

一对多嵌入：文章和评论（少量评论）。将最近10条评论嵌入文章文档，更早的评论存在单独的集合中（子集模式）。

一对多引用：用户和订单。用户文档中存储订单ID数组，订单存在单独的集合中。适合数据量大、需要独立查询的场景。

树形结构：使用父引用（parent_id字段）或物化路径（path字段如"/electronics/phones/apple/"）表示层级关系。物化路径查询子树效率更高。

MongoDB支持单字段索引、复合索引、多键索引（数组字段）、文本索引、地理空间索引。TTL索引可以自动删除过期文档（如session、日志）。部分索引（Partial Index）只对满足条件的文档建索引，节省空间。

注意：MongoDB的单个集合建议不超过10-15个索引。索引过多会影响写入性能。

阿里云MongoDB提供副本集和分片集群两种部署方式。副本集适合中小规模，分片集群支持水平扩展。支持自动备份、数据审计、SSL加密等企业级功能。

数据库选型与高可用架构的三个基本盘

其一是可恢复性：备份的价值不在于「做了」，而在于「能恢复」，定期演练恢复流程比增加备份份数更重要。其二是可回滚性：任何结构或参数变更都应有回退路径，避免把生产当试验场。其三是可预估性：容量与增长趋势要有数据支撑，而不是等到告警才响应。

这三个基本盘稳固之后，再去做性能调优和架构升级，风险会小很多。

机制化的沉淀，能让数据库选型与高可用架构从「个人经验」变成「团队能力」。