MongoDB聚合管道性能测试疑问：是否应改用PostgreSQL/MySQL？

我们针对某业务场景对MongoDB开展了性能测试，具体情况如下：

• 测试集合：包含100,000条记录，字段有_id、userId、offerId、createdAt；每个唯一offerId对应20,000条文档，已为offerId字段创建索引。
• MongoDB实例配置：AWS云实例，2核CPU、16GB内存。
• 测试目标：执行包含以下阶段的聚合管道：
  1. 按offerId（值为"QRSTWVTZ"）过滤数据；
  2. 对结果分组，基于userId相关特定条件计算计数；
  3. 进一步过滤仅保留符合特定计数条件的记录；
  4. 用新数据替换根文档；
  5. 合并结果。

测试观察到的现象：

• 当offerId对应20,000条记录时，在约90请求/秒（RPS）的负载下，聚合管道平均响应时间为200-300毫秒，尽管已为offerId和userId创建索引且被管道使用。
• 当offerId仅对应1,000条记录时，响应时间显著提升至20-30毫秒。
• 即使执行简单的find({ offerId: "123" })查询，对应20,000条文档的offerId响应时间约为40-50毫秒，而对应1-2千条文档的offerId响应时间更短，尽管offerId已建索引。

现提出疑问：在此类场景下，是否应考虑改用PostgreSQL/MySQL等SQL数据库以获得更优性能？

核心瓶颈解析 #

你的测试结果本质是数据量级带来的计算/IO开销差异，并非MongoDB本身不适合这类场景：

1. 针对20k条数据的聚合，即便索引已经过滤出目标数据，后续的分组、计数、二次过滤等操作均为CPU密集型——2核CPU在90RPS的负载下极易出现资源饱和，这是响应时间拉长的核心原因。
2. 简单find查询的性能差异，源于返回20k条文档需要更多的网络IO和内存序列化开销，而1k条数据的IO压力几乎可以忽略。

是否需要切换到SQL数据库？ #

不一定，建议先尝试优化MongoDB现有配置与管道，再做决策：

• 资源扩容：将实例升级到4核CPU，聚合的分组计算性能会明显提升——当前16GB内存足够缓存大部分数据，CPU才是核心瓶颈。
• 聚合管道优化：
  • 用explain("executionStats")确认$match阶段是否真的命中offerId索引，避免索引失效。
  • 尝试预聚合：定期通过后台任务将每个offerId的userId计数结果存储到单独集合，查询时直接读取预计算数据，彻底规避实时聚合的开销。
  • 简化$replaceRoot和$merge阶段的操作，减少不必要的文档序列化成本。
• SQL数据库的预期与成本：
  SQL数据库在这类分组计数场景下，确实可能有更优的查询优化（比如PostgreSQL的哈希分组、索引扫描+分组的协同优化），但切换成本不可忽视：
  • 需要重构表结构，迁移历史数据；
  • 业务代码需重写数据访问逻辑，适配SQL语法；
  • 若后续有非结构化数据存储需求，SQL数据库的灵活性远不如MongoDB。

决策路径 #

1. 先执行MongoDB优化：升级CPU实例+优化聚合管道，验证性能是否能达到预期（比如将聚合响应时间降至50-100ms）。
2. 若优化后仍无法满足需求，再搭建SQL数据库测试环境，用相同数据集和负载做对比测试，确认性能提升是否能覆盖切换成本。

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