У меня есть защищенный кластер 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 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 минут + иногда и обычно около 6 минут для результирующего набора из 1,5 миллиона документов [т.е. соответствующий app_id имеет около 1,5 миллиона документов].
Вот вывод команды объясненияв запросе показано отклонено плана с использованием «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)
Спасибо!:)
------------ РЕДАКТИРОВАТЬ --------------
Полный результатОбъяснение немного длинное, поэтому я вставил его сюда , оно объясняет выбор indexPlanner индекса (Index2).
Также и о shard_key, он полностью отличается от того, что запрашивается здесьВот почему я определяю отдельный конкретный индекс только для этого запроса.(ключ шарда является составным индексом для (app_id, android_id, some_other_field_not_in_query).