150个关联应用共用Mongo数据库的Schema设计及后端架构咨询

方案选型判断：不建议继续沿用单集合存储模式 #

现有单集合内嵌不同应用子文档的设计仅适合极少量耦合应用的场景，150个应用的规模下继续沿用会遇到不可解的瓶颈：

• 触达Mongo单文档16MB的硬上限：哪怕每个应用的子文档仅存100KB的结构化数据，150个应用的总数据量就会达到15MB，接近阈值，业务迭代过程中稍有字段扩容就会触发写入失败
• 索引与查询效率崩盘：单集合混存多应用异构数据，需要为不同应用的查询条件建立大量组合索引，索引膨胀会严重拖慢写入和查询性能，同时跨应用的写入冲突概率会随应用数量指数级上升
• 维护风险不可控：任意应用的schema变更、数据修复操作都需要操作整个集合，一旦出现误操作会影响全部150个应用的可用性，耦合度过高完全无法支撑后续并行迭代

多集合架构的性能问题解决方案 #

你担心的150个集合关联查询性能问题完全可以通过分层架构解决，不需要牺牲可维护性选择单集合方案：

数据库层优化 #

• 统一核心关联字段并建索引：所有应用的公共关联字段（如项目ID、全局流水ID、租户ID等）统一命名规则，全部建立单字段索引，Mongo的$lookup关联操作在关联字段有索引的前提下，关联上百个集合的性能不会出现量级下降
• 新增预聚合中间集合：根据报表的实时性要求，通过定时任务/Change Streams实时同步的方式，把150个集合需要用于统计的核心字段预聚合后写入专用的报表中间集合，常规报表查询直接访问中间集合，不需要每次全量关联150个业务集合
• 分片集群部署：数据量超过单节点承载力时，按公共关联字段（如项目ID）做集合分片，进一步降低单节点查询压力，提升关联查询效率

业务层优化 #

• 封装统一数据访问层（DAL）：所有应用的数据库读写请求全部走统一DAL封装，对上层业务屏蔽底层多集合的存储细节，同时在DAL层接入Redis缓存，把高频访问的关联查询结果缓存，降低数据库访问压力
• 报表分层处理：实时性要求高的业务报表走实时聚合+缓存的方案，非实时的T+1类统计报表直接同步到离线数仓后提供查询，完全不占用业务库的资源

落地步骤建议 #

1. 立即停止单集合的开发模式，从第11个应用开始采用单应用对应独立collection的设计
2. 低峰期迁移已开发完成的10个应用的数据到独立集合，通过DAL层做新旧存储的兼容，保证上层业务无感知
3. 提前搭建预聚合任务和缓存组件，不要等150个应用全部上线后再处理报表性能问题，避免后期重构成本翻倍

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