3

我有一个托管 250+ 百万个文档的 MongoDB Sharded Cluster。

文件结构如下：

{
    "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 s）：

{
    '$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)

谢谢！:)

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

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

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

4

2 回答 2

4

涵盖的查询需要适当的投影 - 请确保您要求仅返回索引中的字段。具体到分片集合，索引还应该包含分片键：https ://docs.mongodb.com/manual/core/query-optimization/#restrictions-on-sharded-collection 。

explain您可以使用allPlansExecution参数获取更多详细信息。它将向您展示规划器如何运行样本以及 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 个文档（高级）中选择得分较高的计划，这通常可以很好地了解它将如何用于整个查询。如果您对此表示怀疑，请尝试提示其他索引并检查它是否更快。

更新

shard key 是 (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 倍。

于 2019-03-08T10:16:31.363 回答
2

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

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

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

分配的分数和规划器的当前评估也可以在 Mongodb 中访问，以下命令帮助我找出分数以及它们如何随着时间的推移而进步。

var queryShape = db.installation.getPlanCache().listQueryShapes()[IDX]
db.installation.getPlanCache().getPlansByQuery(queryShape)
于 2019-03-10T13:40:08.860 回答