Planificador de consultas v3

La versión 3.0 de Planner está disponible en todas las regiones en las que está disponible la versión 8.0 del motor.

La versión 3.0 de Planner es el planificador de consultas predeterminado cuando se selecciona la versión 8.0 del motor.

Siga los pasos en Modificación de parámetros de clúster de Amazon DocumentDB para modificar el grupo de parámetros del clúster.

Para el parámetro denominado 'PlannerVersion', cambie el valor a 3.0 para indicar la versión 3.0 del planificador.

Seleccione Aplicar inmediatamente (si selecciona Aplicar al reiniciar, la selección no será válida hasta el siguiente reinicio del clúster).

En un clúster global, seleccione el mismo plannerVersion valor (1.0, 2.0 o 3.0) en los grupos de parámetros del clúster para ambas regiones. Tenga en cuenta que seleccionar diferentes versiones del planificador en las regiones principales y secundarias puede provocar que el comportamiento y el rendimiento de las consultas no sea constante.

La actualización a la versión 3.0 del planificador durante un período de mantenimiento programado o durante períodos de tráfico reducido será lo menos molesto, ya que las tasas de error pueden aumentar si se cambia la versión del planificador cuando las cargas de trabajo se están ejecutando activamente.

La versión 3.0 de Planner no es compatible con los clústeres elásticos, que recurrirán a la versión 1.0 de Planner.

Si bien Planner v1 permite el uso de «PlanHint» para garantizar que el optimizador de consultas seleccione un plan de consultas específico, Planner v3 no permite el uso de «PlanHint» y se basa en optimizaciones internas para elegir el mejor plan para la consulta en cuestión.

Cuando es posible, el planificador sitúa las etapas de $match en una fase más temprana del proceso, lo que reduce el número de documentos procesados en las etapas posteriores.

//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 } }
])

El planificador combina automáticamente las etapas $lookup y $unwind cuando funcionan en el mismo campo, lo que reduce el procesamiento intermedio de datos y mejora el rendimiento.

                 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 versión 3.0 de Planner presenta una nueva estrategia de ejecución de Distinct Scan que mejora significativamente el rendimiento de distintas operaciones con índices de cardinalidad bajos.

                 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"
                        }
                }
        }
}