时间戳

首页 > 解决方案 > MongoDB - 使用 $elemMatch 在数组中搜索，使用索引比不使用更慢

arrays - MongoDB - 使用 $elemMatch 在数组中搜索，使用索引比不使用更慢

问题描述

我有一个包含 500k 文档的集合，其结构如下：

{
    "_id" : ObjectId("5f2d30b0c7cc16c0da84a57d"),
    "RecipientId" : "6a28d20f-4741-4c14-a055-2eb2593dcf13",
    
    ...
    
    "Actions" : [ 
        {
            "CampaignId" : "7fa216da-db22-44a9-9ea3-c987c4152ba1",
            "ActionDatetime" : ISODate("1998-01-13T00:00:00.000Z"),
            "ActionDescription" : "OPEN"
        }, 
        ...
    ]
}

我需要计算“Actions”数组中的子文档满足特定条件的顶级文档，为此我创建了以下多键索引（仅以“ActionDatetime”字段为例）：

db.getCollection("recipients").createIndex( { "Actions.ActionDatetime": 1 } )

问题是当我使用 $elemMatch 编写查询时，操作比我根本不使用 Multikey 索引时要慢得多：

db.getCollection("recipients").count({
  "Actions":
    { $elemMatch:{ ActionDatetime: {$gt: new Date("1950-08-04")} }}}
)

此查询的统计信息：

{
    "executionSuccess" : true,
    "nReturned" : 0,
    "executionTimeMillis" : 13093,
    "totalKeysExamined" : 8706602,
    "totalDocsExamined" : 500000,
    "executionStages" : {
        "stage" : "COUNT",
        "nReturned" : 0,
        "executionTimeMillisEstimate" : 1050,
        "works" : 8706603,
        "advanced" : 0,
        "needTime" : 8706602,
        "needYield" : 0,
        "saveState" : 68020,
        "restoreState" : 68020,
        "isEOF" : 1,
        "nCounted" : 500000,
        "nSkipped" : 0,
        "inputStage" : {
            "stage" : "FETCH",
            "filter" : {
                "Actions" : {
                    "$elemMatch" : {
                        "ActionDatetime" : {
                            "$gt" : ISODate("1950-08-04T00:00:00.000Z")
                        }
                    }
                }
            },
            "nReturned" : 500000,
            "executionTimeMillisEstimate" : 1040,
            "works" : 8706603,
            "advanced" : 500000,
            "needTime" : 8206602,
            "needYield" : 0,
            "saveState" : 68020,
            "restoreState" : 68020,
            "isEOF" : 1,
            "docsExamined" : 500000,
            "alreadyHasObj" : 0,
            "inputStage" : {
                "stage" : "IXSCAN",
                "nReturned" : 500000,
                "executionTimeMillisEstimate" : 266,
                "works" : 8706603,
                "advanced" : 500000,
                "needTime" : 8206602,
                "needYield" : 0,
                "saveState" : 68020,
                "restoreState" : 68020,
                "isEOF" : 1,
                "keyPattern" : {
                    "Actions.ActionDatetime" : 1.0
                },
                "indexName" : "Actions.ActionDatetime_1",
                "isMultiKey" : true,
                "multiKeyPaths" : {
                    "Actions.ActionDatetime" : [ 
                        "Actions"
                    ]
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "Actions.ActionDatetime" : [ 
                        "(new Date(-612576000000), new Date(9223372036854775807)]"
                    ]
                },
                "keysExamined" : 8706602,
                "seeks" : 1,
                "dupsTested" : 8706602,
                "dupsDropped" : 8206602
            }
        }
    }
}

此查询执行需要 14 秒，而如果我删除索引，则 COLLSCAN 需要 1 秒。

我知道不使用 $elemMatch 并直接按“Actions.ActionDatetime”过滤会获得更好的性能，但实际上我需要按数组内的多个字段进行过滤，因此 $elemMatch 成为强制性的.

我怀疑是 FETCH 阶段正在扼杀性能，但我注意到当我直接使用“Actions.ActionDatetime”时，MongoDB 能够使用 COUNT_SCAN 而不是 fetch，但性能仍然比碰撞扫描（4 秒）。

我想知道是否有更好的索引策略来索引数组内具有高基数的子文档，或者我目前的方法是否遗漏了一些东西。随着数量的增长，索引这些信息将是必要的，我不想依赖 COLLSCAN。

标签： arraysmongodbperformanceindexingmongodb-indexes

解决方案

这里的问题是双重的：

  • 每个文档都与您的查询匹配
    考虑将索引类比为图书馆中的目录。如果你想找一本书，在目录中查找它可以让你直接走到拿着它的书架上，这比从第一个书架开始搜索书籍要快得多（当然除非它确实在那第一个架子）。然而，如果你想把图书馆里的所有书都拿走，直接把它们从书架上拿下来要比检查每本书的目录然后去拿要快得多。
    虽然这个类比远非完美，但它确实表明，当考虑大量文档时，可以预期集合扫描比索引查找更有效。

  • 多键索引对每个文档有多个条目
    当 mongod 在数组上构建索引时，它会在索引中为每个离散元素创建一个单独的条目。当您从数组元素中匹配一个值时，索引可以让您快速找到匹配的文档，但由于单个文档预计在索引中有多个条目，因此之后需要进行重复数据删除。

上述情况进一步加剧$elemMatch。由于索引包含单独索引字段的值，因此无法确定不同字段的值是否出现在索引的同一数组元素中，因此它必须加载每个文档以进行检查。

本质上，当将 elemMatch 与索引和匹配每个文档的查询一起使用时，mongod 节点将检查索引以识别匹配值，对该列表进行重复数据删除，然后加载每个文档（可能按照索引中遇到的顺序）以查看是否有单个数组值满足 elemMatch。

与 mongod 必须按照在磁盘上遇到的顺序加载每个文档并检查单个数组元素匹配是否满足 elemMatch 的非索引集合扫描执行相比，很明显，如果一个大的索引查询将执行更差文档匹配查询的百分比。

推荐阅读