MongoDB海量文档处理最佳实践：关联引用与内嵌存储方案选型

首先先纠正一个常见误区：方案一中不需要搭建三个独立数据库，同实例下分3个独立的集合（文档型数据库）/表（关系型数据库）就能实现关联引用，跨独立数据库反而会额外提升运维、事务处理的成本，完全没有必要。

两个方案没有绝对的优劣，核心匹配你的业务场景即可，以下是具体的优缺点分析和选型建议：

方案一：关联引用实现（多集合/表，通过ID关联） #

优点 #

• 无单文档容量瓶颈：哪怕单个组织下有上万用户、单个用户名下有上万份文档，也不会触达部分数据库的单文档大小上限（比如MongoDB单文档最大限制为16MB），长期扩容无压力
• 写入性能稳定：修改用户信息、新增/修改文档时仅需要操作对应实体的文档，不需要改写整个组织的根文档，不会触发全文档重写，并发写入冲突的概率极低
• 查询灵活性高：需要单独查询用户列表、统计全量文档数据、后续做跨组织文档共享等功能时，不需要拉取整个组织的全量数据，查询开销更低
• 适合大多数常规业务场景：不管是后台管理的分页查询、还是前端的分模块拉取数据，都能轻松适配

缺点 #

• 全量关联查询需要多轮请求：如果你每次查询组织都需要带出全量用户+对应所有文档，需要做多次查询或者额外写关联逻辑，性能不如内嵌结构，这种场景可以加一层缓存优化
• 需要自行维护关联数据一致性：比如删除用户时需要同步处理名下的文档，修改用户公共信息时如果有冗余存储的字段要同步更新

方案二：全内嵌数组结构 #

优点 #

• 全量查询路径最短：如果你的业务90%以上的场景都是查询某个组织下的全量用户+所有文档，一次查询就能拿到所有数据，不需要额外做关联
• 单文档内天然保证数据一致性：在支持单文档事务的数据库下，不需要额外处理跨实体的一致性问题
• 极小数据量级下性能表现更好：如果单组织下用户不超过100、单用户下文档不超过1000，读写开销比关联结构更低

缺点 #

• 容量上限极低：一旦用户、文档的量级上涨，很容易触达单文档大小上限，而且文档体积越大，读写开销越高
• 并发写入冲突概率高：多个用户同时修改自己名下的文档时，都需要操作同一个组织根文档，很容易出现写入冲突失败的问题
• 扩展性极差：后续要做单独查询用户、分页查文档、跨组织共享文档之类的功能，改造难度非常大
• 分页处理成本高：要对用户或者文档做分页查询时，需要先拉取整个数组再在内存中处理，数据量大了之后性能会直接崩盘

选型建议：绝大多数常规Web应用优先选方案一，只有当你100%确定业务数据量级长期极小、且所有查询都是全量拉取组织下所有数据的极端场景，才考虑方案二。

内容的提问来源于stack exchange，提问作者cordmana