如何优化海量数据场景下基于MongoDB+Koa.js的应用性能？

现有MongoDB+NodeJS的技术栈本身可以适配当前及未来100倍规模的业务场景，当前性能不达预期的核心原因是单副本集架构无法承载海量数据的高并发读写、聚合、检索需求，而非基础组件选型错误。

• 单副本集资源上限瓶颈：当前1亿条数据仅靠单副本集的垂直扩容已经触及天花板，CPU、内存、磁盘IO的负载上限无法支撑大跨度数据范围的聚合、检索操作，未来增长到100亿条数据的场景完全无法适配
• 预聚合逻辑存在缺陷：
  • 入库阶段同步执行MongoDB aggregate预计算会阻塞主入库流程，拖慢写入性能
  • 预聚合逻辑未覆盖数据更新、删除场景，要么预聚合结果一致性无法保障，要么全量重算带来额外的性能开销
  • 多维度聚合场景下无法覆盖所有查询维度，仍存在大量未命中预聚合结果的实时计算请求
• 检索场景适配不足：100+属性的多维度组合检索很容易出现索引覆盖不足的情况，即便走索引扫描，MongoDB对跨多索引的联合查询、模糊查询的性能天生弱于专门的检索引擎

现有技术栈迭代优化（无需更换核心组件，投入成本低） #

• 搭建MongoDB分片集群替代现有单副本集：
  • 分片键优先选择高频查询的过滤字段组成复合键，比如高频查询按时间+业务ID过滤，就对应设置分片键，尽可能避免跨分片查询
  • 做冷热数据分离，最近3个月的高频访问热数据存在高性能节点分片，超过时间阈值的冷数据归档到低配置节点分片，冷数据分片可以降低副本数节约资源
  • 配置读偏好策略，非强一致要求的读请求、聚合请求全部路由到从节点执行，分摊主节点的写入压力
• 优化预聚合逻辑：
  • 用MongoDB Change Stream异步消费数据变更事件，把预聚合计算从入库同步流程剥离，不阻塞主写入链路
  • 预聚合结果做分层存储，按时间粒度（分钟级、小时级、天级）、业务维度分别存储，查询时优先匹配最接近的预计算结果，降低实时计算量
• 检索场景精细化优化：
  • 为高频检索的多属性组合创建专门的复合覆盖索引，避免查询回表
  • 对固定条件的高频查询结果做持久化缓存，缓存失效时间和对应数据的更新频率绑定

技术栈升级方案（性能提升幅度更大，适配未来100倍数据增长） #

• 检索场景补充Elasticsearch：把所有需要多维度组合检索、模糊检索的字段同步到ES，检索请求优先走ES，仅需要返回完整文档时再回查MongoDB，数据同步用MongoDB Change Stream做增量同步，延迟可控制在秒级
• 聚合场景补充ClickHouse：把需要做大数据量多维度聚合的原始数据同步到ClickHouse，列式存储引擎针对100+属性的聚合查询性能比MongoDB高10~100倍，完全适配百亿级数据的亚秒级聚合需求
• 入库流程引入Kafka做削峰：每日多次批量入库的请求先写入Kafka，异步消费执行数据校验后再写入底层存储，避免高峰写入请求直接打垮数据库

• 开启MongoDB慢查询日志，定期分析慢查询记录，针对性调整索引、分片策略
• 对NodeJS服务做接口粒度的性能埋点，明确区分数据库耗时、服务逻辑耗时，避免误判瓶颈点
• 配置自动冷数据归档策略，超过访问周期的历史数据自动转储到低成本对象存储，需要查询时走离线计算链路，不占用在线存储资源

内容的提问来源于stack exchange，提问作者Temp O'rary