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

Question

我有一个托管超过 250 万个文档的 MongoDB 分片集群。

文档结构如下:

{
    "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
}

所以基本上有些文档有已卸载字段，有些则没有。

以下是对集合的查询(这是 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)}}]}
    ]
}

这是我在该集合中拥有的两个相关索引:

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

现在的问题是，MongoDb 查询规划器似乎永远不会出于同样的目的选择我在集合中的Index1!

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

这是查询的解释输出，显示使用“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'
}

以下是使用不相关、未覆盖、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 无法正确使用我的索引有什么想法吗？
• 是否因为某些文档中可能不存在已卸载？
• 关于复合日期时指数方向的一些解释查询也将不胜感激，也许原因是索引方向？ (1, -1, -1, 1)

谢谢! :)

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

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

还有关于 shard_key，它与此处查询的内容完全不同，这就是为什么我仅为该查询定义一个单独的特定索引。 (分片键是 (app_id, android_id, some_other_field_not_in_query) 上的复合索引。

Answer 1

涵盖的查询需要正确的投影 - 请确保您要求仅返回索引中的字段。特别是对于分片集合，索引还应该包含分片键: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 个文档(高级)中得分较高的计划，这通常可以很好地了解它将如何适用于整个查询。如果您对此有疑问，请尝试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，因为它在评估期间成功返回了 101 个文档。没有匹配前缀 created_1_latest_transaction_-1_uninstalled_-1_app_id_1 的速度至少慢 100 倍。