如何优化AWS DocumentDB性能？实例配置与查询瓶颈排查咨询

耗时原因排查 #

• 实例资源瓶颈概率高：4GB内存+2vCPU的配置，应对几十万条跨集合关联查询肯定吃力。DocumentDB依赖内存缓存索引和数据，内存不够会触发磁盘IO，速度直接掉档；2vCPU处理跨集合join这类计算密集型操作时，很容易出现CPU饱和，导致查询排队。你可以去CloudWatch看这几个指标：CPUUtilization、FreeableMemory、ReadIOPS，如果CPU长期超70%、内存剩不到10%、ReadIOPS突然暴涨，那就是资源不够的问题。
• 传输瓶颈基本可以排除：你的下载耗时才2秒，说明EC2和DocumentDB之间的网络带宽完全够，那28秒的等待时间全是DocumentDB在处理查询的时间，和传输没关系。

优化方案建议 #

1. 先验证资源瓶颈

临时升级实例规格（比如换成8GB内存+4vCPU的型号），看看查询耗时有没有明显下降。如果有，就说明当前资源确实不够，长期可以根据业务峰值调整到合适的规格，或者加只读实例分流查询压力。另外开一下DocumentDB的性能洞察，看看具体查询的执行计划，有没有全表扫描、低效join这些问题。

2. 重构数据模型，减少跨集合关联

DocumentDB本质是文档数据库，天生不擅长关系型的跨集合join，这类查询本身就慢。建议这么改：

• 如果关联的两个集合数据更新不频繁，直接把关联数据嵌入主集合的文档里，比如把用户信息嵌进订单文档，彻底避免join；
• 如果数据更新频繁，就在主集合里存关联数据的常用字段，用异步任务定期同步更新，查询时不用再关联其他集合。

3. 把筛选逻辑下推到数据库，不要全量拉取

别一次性把几十万条数据拉到客户端再筛选，完全是浪费资源。让客户端把筛选条件传给API，API让DocumentDB只返回符合条件的结果——比如客户端要查某个时间范围的数据，直接在查询里加$match条件，这样数据库计算量少了，传输的数据也少了，耗时会大幅降低。

4. 给查询加合适的索引

针对查询里用到的过滤字段、关联字段建复合索引，比如把主集合的关联字段和常用筛选字段组合成索引，能避免全表扫描，查询速度会快很多。

5. 应用层辅助优化

• 实现分页查询：如果业务允许，把大查询拆成多个分页请求，比如每次返回1万条，客户端分批加载，单次请求耗时会降下来，用户体验也更好；
• 缓存常用结果：如果某些筛选条件的查询结果不怎么变，用Redis缓存起来，不用每次都查DocumentDB。

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