Mongodb Explain for Aggregation framework

Från och med MongoDB version 3.0, ändrar du helt enkelt beställningen från

collection.aggregate(...).explain()

till

collection.explain().aggregate(...)

ger dig de önskade resultaten (dokumentation här).

För äldre versioner>=2.6 måste du använda explain alternativ för aggregeringspipelineoperationer

`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
  }
)

Ett viktigt övervägande med Aggregation Framework är att ett index endast kan användas för att hämta initial data för en pipeline (t.ex. användning av $match , $sort , $geonear i början av en pipeline) samt efterföljande $lookup och $graphLookup etapper. När data har hämtats in i aggregeringspipelinen för bearbetning (t.ex. passerar genom stadier som $project , $unwind och $group ) ytterligare manipulation kommer att finnas i minnet (möjligen med hjälp av temporära filer om allowDiskUse alternativet är inställt).

Optimera pipelines

I allmänhet kan du optimera aggregeringspipelines genom att:

Starta en pipeline med en $match steg för att begränsa behandlingen till relevanta dokument.
Säkerställer den initiala $match / $sort stadier stöds av ett effektivt index.
Filtrera data tidigt med $match , $limit och $skip .
Minimerar onödiga stadier och dokumentmanipulation (kanske omprövar ditt schema om komplicerad sammanläggningsgymnastik krävs).
Att dra nytta av nyare aggregeringsoperatörer om du har uppgraderat din MongoDB-server. Till exempel lade MongoDB 3.4 till många nya aggregeringssteg och uttryck, inklusive stöd för att arbeta med arrayer, strängar och fasetter.

Det finns också ett antal Aggregation Pipeline-optimeringar som sker automatiskt beroende på din MongoDB-serverversion. Till exempel kan intilliggande steg sammanföras och/eller ordnas om för att förbättra exekveringen utan att påverka utdataresultaten.

Begränsningar

Som i MongoDB 3.4, explain aggregeringsramverket alternativet ger information om hur en pipeline bearbetas men stöder inte samma detaljnivå som executionStats läge för en find() fråga. Om du är fokuserad på att optimera den initiala frågekörningen kommer du förmodligen att tycka att det är fördelaktigt att granska motsvarande find().explain() fråga med executionStats eller allPlansExecution mångfald.

Det finns några relevanta funktionsförfrågningar att se/rösta upp i MongoDB-problemspåraren angående mer detaljerad exekveringsstatistik för att hjälpa till att optimera/profilera aggregeringspipelines:

SERVER-19758:Lägg till "executionStats" och "allPlansExecution" förklaringslägen till aggregeringsförklaring
SERVER-21784:Spåra exekveringsstatistik för varje aggregeringspipelinesteg och exponera via förklara
SERVER-22622:Förbättra $lookup explain för att indikera frågeplan på "från"-samlingen