AWS DocumentDB聚合功能失效：本地MongoDB正常线上异常

可能原因1：缺少关键索引导致全表扫描超时 #

DocumentDB对聚合查询的索引依赖度高于MongoDB，你的聚合第一个阶段是$match过滤parameters.article_id，如果该字段未创建索引，数据量较大时会触发全表扫描，直接导致请求超时。

解决办法：
在DocumentDB中为parameters.article_id创建单字段索引：

// 通过代码或Mongo Shell执行
await dbo.collection('articles_collection').createIndex({"parameters.article_id": 1})

可能原因2：聚合语法的兼容细节差异 #

尽管DocumentDB兼容MongoDB，但部分聚合语法的细节处理存在差异。你在$group中使用嵌套对象作为_id，可能触发了DocumentDB的兼容问题。

解决办法：
简化$group的_id结构，直接使用字段值而非嵌套对象：

const aggregateCursor = dbo.collection('articles_collection').aggregate([
    {
        $match: {
            'parameters.article_id': 141189,
        },
    },
    {
        $group: {
            _id: '$parameters.user_id', // 改为直接引用字段
            totalVisits: {
                $sum: 1,
            },
        },
    },
    { $limit: 5 },
])

可能原因3：连接配置的readPreference影响 #

你的连接URL设置了readPreference=secondaryPreferred，聚合操作在从节点执行时可能遇到资源瓶颈或锁冲突，而简单的find请求能正常处理。

解决办法：
临时修改连接URL的readPreference为primary，测试聚合是否正常：

const dbUrl = 'mongodb://<username>:<password>@<clustername>.cluster-csa8xeixiy9f.us-east-1.docdb.amazonaws.com:27017/?ssl=true&replicaSet=rs0&readPreference=primary&retryWrites=false'

如果恢复正常，再结合业务场景调整readPreference，或检查从节点的资源状态。

可能原因4：聚合内存不足未启用磁盘临时存储 #

当聚合操作需要处理大量数据时，默认内存限制可能不够，DocumentDB不会自动使用磁盘存储临时数据，导致进程卡住。

解决办法：
在聚合时添加allowDiskUse: true参数，允许使用磁盘存储临时结果：

const aggregateCursor = dbo.collection('articles_collection').aggregate([
    { $match: { 'parameters.article_id': 141189 } },
    { $group: { _id: '$parameters.user_id', totalVisits: { $sum: 1 } } },
    { $limit: 5 }
], { allowDiskUse: true }) // 添加该参数

可能原因5：DocumentDB实例资源不足 #

如果你的DocumentDB实例规格过小（如t2.micro这类低配实例），聚合操作的CPU、内存占用会超出实例承载能力，导致无响应。

解决办法：
登录AWS控制台查看DocumentDB实例的CPU、内存使用率，若持续高负载，升级实例规格（如改为t2.small或更高配置）。

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