MongoDB 最优索引 |查询规划器行为

Question

我有一个 MongoDB 分片集群托管 250+ 百万个文档。

文档结构如下：

{
    "app_id": "whatever", 
    "created": ISODate("2018-05-06T12:13:45.000Z"),
    "latest_transaction": ISODate("2019-03-06T11:11:40.000Z"),
    "anotherField1": "Str", "anotherField2": "Str", ...otherfields
}
{
    "app_id": "whatever", 
    "created": ISODate("2018-04-06T12:13:45.000Z"),
    "latest_transaction": ISODate("2019-03-06T11:11:40.000Z"),
    "uninstalled": ISODate("2019-03-07T11:11:40.000Z"),
    "anotherField1": "Str", "anotherField2": "Str", ...otherfields
}

所以基本上有些文档有字段 uninstalled，有些则没有。

下面是collection上的查询（是pymongo的解释，对不起datetime.datetime）：

{
    '$and': [
        {'app_id': {'$eq': 'whatever'}},
        {'created': {'$lt': datetime.datetime(2019, 3, 7, 0, 0)}},
        {'latest_transaction': {'$gt': datetime.datetime(2019, 2, 5, 0, 0)}},
        {'$nor': [{'uninstalled': {'$lt': datetime.datetime(2019, 3, 7, 0, 0)}}]}
    ]
}

这是我在 collection 上的两个相关指数：

Index1: {"created": 1, "latest_transaction": -1, "uninstalled": -1, "app_id": 1}
Index2: {'app_id': 1, 'anotherField1': 1, 'anotherField2': 1}

现在的问题是，MongoDb 查询规划器似乎从未选择 Index1 我在 collection 为了这个完全相同的目的！

我最初的印象是查询将使用覆盖索引以及我构建索引的方式[因此，非常快]，但对我来说很奇怪，mongodb 使用 Index2 一切都太慢了，有时需要 10 分钟以上，对于 150 万个文档的结果集通常需要 6 分钟左右 [即匹配 app_id 有大约 150 万个文档。

这是查询解释的输出，显示 rejected plan using "Index1"

{
    'inputStage': {
        'inputStage': {
            'direction': 'forward',
            'indexBounds': {
                'app_id': ['["whatever", "whatever"]'],
                'created': ['(true, new Date(1551916800000))'],
                'latest_transaction': ['[new Date(9223372036854775807), new Date(1549324800000))'],
                'uninstalled': ['[MaxKey, new Date(1551916800000)]', '[true, MinKey]']
            },
            'indexName': 'created_1_latest_transaction_-1_uninstalled_-1_app_id_1',
            'indexVersion': 2,
            'isMultiKey': False,
            'isPartial': False,
            'isSparse': False,
            'isUnique': False,
            'keyPattern': {
                'app_id': 1.0,
                'created': 1.0,
                'latest_transaction': -1.0,
                'uninstalled': -1.0
            },
            'multiKeyPaths': {'app_id': [], 'created': [], 'latest_transaction': [], 'uninstalled': []},
            'stage': 'IXSCAN'},
        'stage': 'FETCH'},
    'stage': 'SHARDING_FILTER'
}

下面是winning计划使用不相关，未覆盖，Index2：

{'inputStage': {
    'inputStage': {'direction': 'forward',
                   'indexBounds': {
                       'app_id': ['["whatever", "whatever"]'],
                       'anotherField1': ['[MinKey, MaxKey]'],
                       'anotherField2': ['[MinKey, MaxKey]']},
                   'indexName': 'app_id_1_anotherField2_1_anotherField1_1',
                   'indexVersion': 2,
                   'isMultiKey': False,
                   'isPartial': False,
                   'isSparse': False,
                   'isUnique': False,
                   'keyPattern': {'app_id': 1, 'anotherField1': 1, 'anotherField2': 1},
                   'multiKeyPaths': {'app_id': [], 'anotherField1': [], 'anotherField2': []},
                   'stage': 'IXSCAN'},
    'stage': 'FETCH'},
    'stage': 'SHARDING_FILTER'
}

关于为什么 mongodb 不能正确使用我的索引有什么想法吗？
是否因为 uninstalled 可能不存在于某些文档中？
做复合日期时对指数方向的一些解释查询也将不胜感激，也许原因是指数方向？ (1, -1, -1, 1)

谢谢！ :)

------------ 编辑 --------------

解释的完整结果有点长，所以我粘贴了它here，它解释了 queryPlanner 对索引 (Index2) 的选择。

另外关于 shard_key，它与这里查询的内容完全不同，这就是为什么我只为这个查询定义一个单独的特定索引。（分片键是 (app_id、android_id、some_other_field_not_in_query) 上的复合索引。

Answer 1

涵盖的查询需要适当的投影 - 请确保您只询问 return 索引中的字段。特别是对于分片集合，索引还应该包含分片键：https://docs.mongodb.com/manual/core/query-optimization/#restrictions-on-sharded-collection.

您可以使用 allPlansExecution 参数从 explain 获取更多详细信息。它将向您展示规划器运行如何采样以及 index2 获胜的原因。

https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/plan_ranker.cpp#L191分数是这样计算的：

baseScore = 1
productivity = advanced / works // the main one 

tieBreak = very_small_number
   + noFetchBonus // 0 for not covered queries
   + noSortBonus // 0 for no sort
   + noIxisectBonus // 0 for index intersection

score = baseScore + productivity + tieBreakers

它会在前 100 个文档中选择得分较高的计划 returned（高级），这通常会很好地说明它将如何针对整个查询工作。如果您怀疑它，请尝试 hint 另一个索引并检查它是否更快。

更新

shard key is a compound index on (app_id, android_id, some_other_field_not_in_query

有点解释。 app_id 是 sharding key 和 Index2 中的公共前缀。这意味着使用这个索引 mongo 可以立即决定查询哪些分片。更改 Index1 中的字段顺序以匹配分片键前缀：

Index1: {"app_id": 1, "created": 1, "latest_transaction": -1, "uninstalled": -1}

说明中的基本数字：

   u'inputStage': {u'advanced': 0,
     u'indexName': u'created_1_latest_transaction_-1_uninstalled_-1_app_id_1',       


   u'inputStage': {u'advanced': 88,
     u'indexName': u'app_id_1_is_enabled_1_another_id_1',

   u'inputStage': {u'advanced': 12,
     u'indexName': u'app_id_1_uninstalled_1_is_enabled_1',

   u'inputStage': {u'advanced': 101,
     u'indexName': u'app_id_1_is_enabled_1_gaid_1',

获胜者是 app_id_1_is_enabled_1_gaid_1，因为它在评估期间设法 return 101 份文件。没有匹配前缀created_1_latest_transaction_-1_uninstalled_-1_app_id_1的至少慢100倍

Answer 2

在这里回答我自己的问题，

MongoDB 的查询规划器分数现在似乎已重新调整，它们现在反映了与所有查找谓词匹配的索引的更高值。

所以基本上，它需要几个小时的时间来弄清楚 Index1: {"created": 1, "latest_transaction": -1, "uninstalled": -1, "app_id": 1} 应该比其他指数有更高的分数，而我预计行为的变化是瞬间的。

分配的分数和规划器的当前评估也 can be accessed in Mongodb，遵循命令帮助我计算分数以及它们如何随时间推移。

var queryShape = db.installation.getPlanCache().listQueryShapes()[IDX]
db.installation.getPlanCache().getPlansByQuery(queryShape)

MongoDB 最优索引 |查询规划器行为

MongoDB optimal Index | Query planner behavior

indexing

performance

mongodb

pymongo

query-planner