我有一个包含超过 2 亿个文档的集合，其中包含维度(我想过滤或分组的内容)和指标(我想求和或获取平均值的内容)。我目前遇到了一些性能问题，我希望获得一些关于如何优化/扩展 MongoDB 的建议或关于替代解决方案的建议。我正在使用 WiredTiger 运行最新的稳定版 MongoDB。这些文件基本上如下所示:

{
  "dimensions": {
    "account_id": ObjectId("590889944befcf34204dbef2"),
    "url": "https://test.com",
    "date": ISODate("2018-03-04T23:00:00.000+0000")
  },
  "metrics": {
    "cost": 155,
    "likes": 200
  }
}

我在这个集合上有三个索引，因为在这个集合上运行了各种聚合:

1. 帐号编号
2. 日期
3. account_id 和日期

以下聚合查询获取 3 个月的数据，汇总成本和喜欢并按周/年分组:

db.large_collection.aggregate(

    [
        {
            $match: { "dimensions.date": { $gte: new Date(1512082800000), $lte: new Date(1522447200000) } }
        },

        {
            $match: { "dimensions.account_id": { $in: [ "590889944befcf34204dbefc", "590889944befcf34204dbf1f", "590889944befcf34204dbf21" ] }}
        },

        {
            $group: { 
              cost: { $sum: "$metrics.cost" }, 
              likes: { $sum: "$metrics.likes" }, 
              _id: { 
                year: { $year: { date: "$dimensions.date", timezone: "Europe/Amsterdam" } }, 
                week: { $isoWeek: { date: "$dimensions.date", timezone: "Europe/Amsterdam" } } 
              } 
            }
        },

        { 
            $project: {
                cost: 1, 
                likes: 1 
            }
        }
    ],

    {
        cursor: {
            batchSize: 50
        },
        allowDiskUse: true
    }

);

此查询大约需要 25-30 秒才能完成，我希望将其减少到至少 5-10 秒。它目前是单个 MongoDB 节点，没有分片或任何东西。解释查询可以在这里找到:https://pastebin.com/raw/fNnPrZh0和 executionStats:https://pastebin.com/raw/WA7BNpgA如您所见，MongoDB 正在使用索引，但仍有 130 万个文档需要读取。我目前怀疑我遇到了一些 I/O 瓶颈。

有谁知道我可以如何改进这个聚合管道？分片会有帮助吗？ MonogDB 是合适的工具吗？

最佳答案

当且仅当如果每条记录中的预计算维度是一个选项，则以下内容可以提高性能。

如果这种类型的查询代表了对这个集合的查询的重要部分，那么包括额外的字段来加快这些查询可能是一个可行的替代方案。

这还没有进行基准测试。

此查询中成本较高的部分之一可能来自处理日期。

• 首先在 $group 阶段为每个匹配记录计算与特定时区关联的年份和等周。

• 然后，在较小程度上，在初始过滤期间，保留最近 3 个月的日期。

想法是在每条记录中存储年份和等周数，对于给定的示例，这将是 { "year": 2018, "week": 10 } 。这样，$group 阶段中的 _id 键就不需要任何计算(否则将代表 1M3 复杂的日期操作)。

以类似的方式，我们还可以在每个记录中存储关联的月份，对于给定的示例，这将是 { "month": "201803"} 。这样，在对确切时间戳应用更精确和成本更高的过滤之前，第一个匹配项可能在月 [2, 3, 4, 5] 上。这会将对 200M 记录的初始成本较高的 Date 过滤节省为简单的 Int 过滤。

让我们用这些新的预计算字段创建一个新集合(在真实场景中，这些字段将包含在记录的初始 insert 期间):

db.large_collection.aggregate([
  { $addFields: {
    "prec.year": { $year: { date: "$dimensions.date", timezone: "Europe/Amsterdam" } },
    "prec.week": { $isoWeek: { date: "$dimensions.date", timezone: "Europe/Amsterdam" } },
    "prec.month": { $dateToString: { format: "%Y%m", date: "$dimensions.date", timezone: "Europe/Amsterdam" } }
  }},
  { "$out": "large_collection_precomputed" }
])

将存储这些文档:

{
  "dimensions" : { "account_id" : ObjectId("590889944befcf34204dbef2"), "url" : "https://test.com", "date" : ISODate("2018-03-04T23:00:00Z") },
  "metrics" : { "cost" : 155, "likes" : 200 },
  "prec" : { "year" : 2018, "week" : 10, "month" : "201803" }
}

然后让我们查询:

db.large_collection_precomputed.aggregate([
  // Initial gross filtering of dates (months) (on 200M documents):
  { $match: { "prec.month": { $gte: "201802", $lte: "201805" } } },
  { $match: {
    "dimensions.account_id": { $in: [
      ObjectId("590889944befcf34204dbf1f"), ObjectId("590889944befcf34204dbef2")
    ]}
  }},
  // Exact filtering of dates (costlier, but only on ~1M5 documents).
  { $match: { "dimensions.date": { $gte: new Date(1512082800000), $lte: new Date(1522447200000) } } },
  { $group: {
    // The _id is now extremly fast to retrieve:
    _id: { year: "$prec.year", "week": "$prec.week" },
    cost: { $sum: "$metrics.cost" },
    likes: { $sum: "$metrics.likes" }
  }},
  ...
])

在这种情况下，我们将在 account_id 和 month 上使用索引。

注意:在这里，月份存储为 String ("201803")，因为我不确定如何将它们转换为 Int 在聚合查询中。但最好是在插入记录时将它们存储为 Int

作为副作用，这显然会使集合的存储磁盘/内存更重。

关于mongodb - 大量集合的聚合管道缓慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49409559/