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
}

因此，基本上，有些文档的字段为未安装，有些则没有。

以下是对集合的查询（这是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分钟以上的时间，通常大约需要6分钟才能处理150万份文档[例如匹配的app_id大约有150万个文档]。

以下是查询中的explain输出，其中显示了使用“ 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其他索引并检查它是否更快。

更新

分片键是（app_id，android_id，some_other_field_not_in_query

金田解释。 app_id是分片密钥和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倍。

Answer 2

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

MongoDB的查询计划者分数现在似乎已被重新调整，并且现在反映出与所有查找谓词匹配的Index的较高值。

因此，基本上，我需要花费几个小时的时间来弄清楚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最佳索引|查询计划者行为

2 个答案: