Planificateur de requêtes v3

La version 3.0 de Planner est disponible dans tous les Régions AWS pays où la version 8.0 du moteur est disponible.

La version 3.0 de Planner 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, indiquant la version 3.0 du planificateur.

Sélectionnez Appliquer immédiatement (si vous sélectionnez Appliquer au redémarrage, la sélection sera inefficace jusqu'au prochain redémarrage du cluster).

Dans un cluster global, sélectionnez la même plannerVersion valeur (1.0 ou 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 principales et secondaires peut entraîner un comportement et des performances incohérents des requêtes.

La mise à jour vers la version 3.0 du planificateur pendant une fenêtre de maintenance planifiée ou pendant des périodes de trafic réduit sera la solution la moins perturbatrice, car les taux d'erreur peuvent 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 de Planner n'est pas prise en charge dans les clusters élastiques, qui reviendront à la version 1.0 de Planner.

Alors que Planner v1 permet d'utiliser « PlanHint » pour s'assurer 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 opèrent sur le même terrain, réduisant ainsi le traitement des données intermédiaires et améliorant 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 du scan distinct qui améliore considérablement les performances des opérations distinctes sur des index 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"
                        }
                }
        }
}

             

La distinct commande nécessite la version 3.0 du planificateur.

La aggregate commande nécessite la version 3.0 du planificateur et Amazon DocumentDB 8.0.2. Un filtre s'applique lorsque le pipeline lit la collection tout au long d'une $match étape principale.

Un filtre défini sur la collection étrangère d'un $graphLookup étage $lookup ou détermine l'index utilisé pour scanner cette collection étrangère. Cela nécessite également la version 3.0 du planificateur et Amazon DocumentDB 8.0.2.