Започвайки с MongoDB версия 3.0, просто променяйки реда от
collection.aggregate(...).explain()
до
collection.explain().aggregate(...)
ще ви даде желаните резултати (документация тук).
За по-стари версии>=2.6 ще трябва да използвате explain
опция за операции по конвейер за агрегация
explain:true
db.collection.aggregate([
{ $project : { "Tags._id" : 1 }},
{ $unwind : "$Tags" },
{ $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
{ $group: {
_id : "$_id",
count: { $sum:1 }
}},
{$sort: {"count":-1}}
],
{
explain:true
}
)
Важно съображение при Aggregation Framework е, че индексът може да се използва само за извличане на първоначалните данни за конвейер (напр. използване на $match
, $sort
, $geonear
в началото на конвейер), както и последващи $lookup
и $graphLookup
етапи. След като данните бъдат извлечени в тръбопровода за агрегиране за обработка (напр. преминаване през етапи като $project
, $unwind
и $group
) по-нататъшната манипулация ще бъде в паметта (евентуално с помощта на временни файлове, ако allowDiskUse
опцията е зададена).
Оптимизиране на тръбопроводи
Като цяло можете да оптимизирате тръбопроводите за агрегиране чрез:
- Стартиране на конвейер с
$match
етап за ограничаване на обработката до съответните документи. - Осигуряване на първоначалното
$match
/$sort
етапите се поддържат от ефективен индекс. - Филтриране на данните по-рано с помощта на
$match
,$limit
и$skip
. - Минимизиране на ненужните етапи и манипулиране на документи (може би преразглеждане на вашата схема, ако се изисква сложна гимнастика за агрегиране).
- Възползване на по-новите оператори за агрегиране, ако сте надстроили своя MongoDB сървър. Например, MongoDB 3.4 добави много нови етапи на агрегиране и изрази, включително поддръжка за работа с масиви, низове и аспекти.
Има също така редица оптимизации на конвейера за агрегиране, които се случват автоматично в зависимост от версията на сървъра на MongoDB. Например, съседните етапи могат да бъдат обединени и/или пренаредени, за да се подобри изпълнението, без да се засягат изходните резултати.
Ограничения
Както при MongoDB 3.4, Aggregation Framework explain
опция предоставя информация за това как се обработва конвейер, но не поддържа същото ниво на детайлност като executionStats
режим за find()
запитване. Ако сте фокусирани върху оптимизирането на изпълнението на първоначалната заявка, вероятно ще намерите за полезно да прегледате еквивалентния find().explain()
заявка с executionStats
или allPlansExecution
многословие.
Има няколко подходящи заявки за функции за гледане/гласуване в програмата за проследяване на проблеми на MongoDB по отношение на по-подробни статистически данни за изпълнение, които да помогнат за оптимизиране/профилиране на тръбопроводи за агрегиране:
- SERVER-19758:Добавете режимите за обяснение на „executionStats“ и „allPlansExecution“ към обяснението на агрегирането
- SERVER-21784:Проследявайте статистически данни за изпълнението за всеки етап на тръбопровода за агрегиране и излагайте чрез обяснение.
- SERVER-22622:Подобрете обяснението на $lookup, за да посочите план за заявка в колекцията „от“