Planificateur de requêtes v3

La version 3.0 de Planner est disponible dans toutes les régions où la version 8.0 du moteur est disponible.

La version 3.0 du planificateur est le planificateur de requêtes par défaut lorsque la version 8.0 du moteur est sélectionnée.

Suivez les étapes décrites Modification des paramètres du cluster Amazon DocumentDB pour modifier le groupe de paramètres de votre cluster.

Pour le paramètre intitulé « PlannerVersion », remplacez la valeur par 3.0 pour indiquer la version 3.0 du planificateur.

Sélectionnez Appliquer immédiatement (sélectionner Appliquer au redémarrage rendra la sélection inefficace jusqu'au prochain redémarrage du cluster).

Dans un cluster global, sélectionnez la même plannerVersion valeur (1,0, 2,0 ou 3,0) dans les groupes de paramètres du cluster pour les deux régions. Notez que la sélection de différentes versions du planificateur dans les régions principale et secondaire peut entraîner un comportement et des performances de requête incohérents.

La mise à jour vers la version 3.0 du planificateur pendant une période de maintenance planifiée ou pendant des périodes de trafic réduit sera la moins perturbatrice, car le taux d'erreur peut augmenter si la version du planificateur est modifiée alors que les charges de travail sont en cours d'exécution active.

La version 3.0 du planificateur n'est pas prise en charge dans les clusters élastiques, qui reviendront à la version 1.0 du planificateur.

Alors que Planner v1 autorise l'utilisation de « PlanHint » pour garantir qu'un plan de requête spécifique est sélectionné par l'optimiseur de requêtes, Planner v3 n'autorise pas l'utilisation de « PlanHint » et s'appuie sur des optimisations internes pour choisir le meilleur plan pour la requête donnée.

Le planificateur déplace les étapes $match plus tôt dans le pipeline lorsque cela est possible, réduisant ainsi le nombre de documents traités par les étapes suivantes.

//Planner v1
db.orders.aggregate([
  { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } },
  { $match: { customerId: { $gt: 1000 } } }
])

// Planner v3 pulls up the match since customerId exists in original documents
// Optimized internally as:
db.orders.aggregate([
  { $match: { customerId: { $gt: 1000 } } },  // Pulled up before project
  { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } }
])

Le planificateur combine automatiquement les étapes $lookup et $unwind lorsqu'elles fonctionnent sur le même terrain, ce qui réduit le traitement intermédiaire des données et améliore les performances.

                 Example query:
//Planner v1
db.orders.aggregate([
  { $lookup: { from: "products", localField: "productId", foreignField: "_id", as: "productInfo" } },
  { $unwind: "$productInfo" },
  { $project: { orderDate: 1, "productInfo.name": 1, "productInfo.price": 1 } }
])

// Planner version 3.0 optimizes this internally by coalescing the $lookup and $unwind stages
             

La version 3.0 de Planner introduit une nouvelle stratégie d'exécution de Distinct Scan qui améliore considérablement les performances des opérations distinctes sur des indices de cardinalité faibles.

                 Example query:
//// If there is a low cardinality index on "category", you may see a query plan like below
db.explain().products.distinct("category")

"queryPlanner" : {
        "plannerVersion" : 3,
        "namespace" : "db.products",
        "winningPlan" : {
                "stage" : "AGGREGATE",
                "inputStage" : {
                        "stage" : "DISTINCT_SCAN",
                        "inputStage" : {
                                "stage" : "IXONLYSCAN",
                                "indexName" : "category_1",
                                "direction" : "forward"
                        }
                }
        }
}