Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Planificar filtros de caché

Un filtro de caché del plan, también denominado filtro de índices, restringe el conjunto de índices que el planificador de consultas puede considerar para una forma de consulta específica. Cuando una consulta coincide con una forma que tiene un filtro, el planificador elige un plan solo entre los índices mencionados en ese filtro en lugar de evaluar todos los índices de la colección.

Una forma de consulta es la combinación del predicado de la consulta, la especificación de clasificación y el espacio de nombres de la colección, con los valores del predicado normalizados. Dos consultas que solo difieren en sus valores comparten una forma, por lo que un solo filtro las cubre todas. En la salida deplanCacheListFilters, los valores normalizados se muestran como"@".

Un filtro de caché del plan le permite fijar el plan para evitar elegir un índice más lento debido a la distribución de los datos o a los cambios en el índice. Los filtros tienen las siguientes propiedades:

Comandos admitidos

Los filtros de caché del plan requieren la versión 2.0 o posterior de Planner. El comando al que se puede aplicar un filtro depende de la versión del planificador y de la versión secundaria de Amazon DocumentDB, como se muestra en la tabla siguiente.

Para el aggregate comando, la forma se toma desde la parte frontal de la canalización: la línea inicial $match proporciona el filtro e $sort inmediatamente después proporciona la clasificación. $skipy $limit no afectan a la forma, ni tampoco a las etapas que se encuentran más allá de ese punto.

Amazon DocumentDB optimiza la canalización antes de planificarla, y un filtro de caché del plan se compara con la canalización optimizada. Por lo tanto, el filtro y la clasificación que ve el planificador pueden diferir de las etapas que escribió. Por ejemplo, dos $match etapas adyacentes en la parte delantera de una canalización se combinan en un solo $and predicado:

db.orders.aggregate([
  { $match: { status: "SHIPPED" } },
  { $match: { region: "us-east-1" } },
  { $group: { _id: "$customerId", total: { $sum: "$amount" } } }
])

El planificador ve uno $match activado{$and: [{status: ...}, {region: ...}]}, por lo que el filtro debe configurarse en ese predicado combinado.

db.runCommand({planCacheSetFilter: "orders",
query: { $and: [ { status: "SHIPPED" }, { region: "us-east-1" } ] },
indexes: [ "status_1_region_1" ]})

Un filtro establecido en la colección extranjera de una $lookup o varias $graphLookup etapas controla el índice utilizado para escanear esa colección extranjera.

Formas de consulta compatibles

A partir de Amazon DocumentDB 5.0.2 y 8.0.2, los siguientes operadores pueden aparecer en forma de consulta con un filtro de caché de planes:

La configuración de un filtro produce un error y se produce el código de error 303 para una forma de consulta que utilice $jsonSchema o$sampleRate. $expr También se produce un error en las siguientes formas. Una consulta que utilice cualquiera de ellas se planifica sin ningún filtro:

Configurar, enumerar y borrar filtros

Para configurar un filtro de caché del plan, utilice el planCacheSetFilter comando. Los sort campos query y juntos especifican la forma de la consulta y indexes muestran los nombres de índice que el planificador puede tener en cuenta para esa forma.

db.runCommand({
planCacheSetFilter: <collection>,
query: <query>,
sort: <sort>, // optional
indexes: [ <index1>, <index2>, ...],
comment: <any> // optional
})

Por ejemplo, el siguiente comando restringe el planificador al a_1 índice de la forma {a: {$eq: "@"}, b: {$eq: "@"}} sin ningún tipo de clasificación:

db.runCommand({planCacheSetFilter: "foo",
query: { a: 1, b: 1 },
sort: {},
indexes: [ "a_1" ]})

Al establecer un filtro para una forma que ya tiene uno, se reemplaza el filtro existente. Tras ejecutar los dos comandos siguientes, el filtro de la forma {a: {$eq: "@"}, b: {$eq: "@"}} es["b_1"]:

db.runCommand({planCacheSetFilter: "foo",
query: { a: 1, b: 1 },
sort: {},
indexes: [ "a_1" ]})

db.runCommand({planCacheSetFilter: "foo",
query: { a: 6, b: 10 },
sort: {},
indexes: [ "b_1" ]})

Para mostrar todos los filtros de una colección, utilice el planCacheListFilters comando:

db.runCommand({planCacheListFilters: <collection>})

El resultado muestra cada forma almacenada con sus valores normalizados y su lista de índices permitidos:

{
"filters" : [
{
"query" : { "a" : { "$eq" : "@" } },
"sort" : { },
"indexes" : [ "a_1" ]
},
{
"query" : { "a" : { "$gt" : "@" } },
"sort" : { "a" : 1 },
"indexes" : [ "a_1_b_1" ]
}
],
"ok" : 1
}

El operador se conserva y solo se reemplaza el valor por. "@" Una igualdad implícita, tal como, {a: 1} aparece en su forma explícita{"a": {"$eq": "@"}}, y los elementos de una $in matriz se reemplazan como un todo, como{"a": {"$in": "@"}}. Un conjunto de filtros sin clasificación aparece junto con un sort documento vacío.

Para eliminar los filtros, utilice el planCacheClearFilters comando.

db.runCommand({
planCacheClearFilters: <collection>,
query: <query pattern>, // optional
sort: <sort specification>, // optional
comment: <any> // optional
})

Para borrar todos los filtros de la colección, omite ambos query ysort:

db.runCommand({planCacheClearFilters: "foo"})

Suministra ambos query y sort borra solo el filtro que tiene ese tipo exacto. Los valores introducidos query se normalizan, por lo que cualquier valor representativo funciona. Para borrar solo el filtro que se estableció sin ordenar, pase un sort documento vacío:

db.runCommand({planCacheClearFilters: "foo", query: {a: 1}, sort: {a: 1}})

db.runCommand({planCacheClearFilters: "foo", query: {a: 1}, sort: {}})

Comprobar que se ha aplicado un filtro

El explain resultado incluye dos campos que indican el estado del filtro de caché del plan:

A partir de Amazon DocumentDB 5.0.2 y 8.0.2, estos campos se incluyen en todos los comandos que admiten los filtros de caché de planificación y en los resultados del generador de perfiles de esos comandos. En versiones secundarias anteriores, solo se indicaban para el comando. find Para obtener más información sobre la lectura y la explicación del resultado, consulteAnálisis del plan de consultas.

Un filtro puede coincidir con la forma de una consulta sin aplicarlo. Si ninguno de los índices de la lista del filtro sirve para la consulta, el planificador vuelve a planificar sin el filtro y elige un índice según el costo. En ese caso indexFilterSet es true y es. indexFilterApplied false Esto ocurre cuando los índices con nombre no cubren los campos de la consulta, cuando los índices con nombre no existen o cuando una $regex forma no puede generar límites de índice, como un patrón desanclado o que no distingue mayúsculas de minúsculas.

Ejemplos

En los siguientes ejemplos se utiliza una orders colección, y una customers colección, para el ejemplo, con estos índices: $lookup

db.orders.createIndex({ status: 1 })                         // status_1
db.orders.createIndex({ status: 1, orderDate: 1 })           // status_1_orderDate_1
db.orders.createIndex({ customerId: 1 })                     // customerId_1
db.customers.createIndex({ customerId: 1 })                  // customerId_1

Ejemplo: anclar una consulta de búsqueda a un índice compuesto

Imagínese una consulta que filtra status y ordena segúnorderDate:

db.orders.find({ status: "SHIPPED" }).sort({ orderDate: 1 })

El índice compuesto status_1_orderDate_1 satisface tanto el predicado como la clasificación, por lo que no es necesaria una clasificación por separado. Si el planificador lo eligestatus_1, la consulta tiene que ordenar sus resultados, lo que añade una SORT etapa y se encarece a medida que aumenta el número de pedidos coincidentes. Para restringir el planificador al índice compuesto de esta forma:

db.runCommand({planCacheSetFilter: "orders",
query: { status: "SHIPPED" },
sort: { orderDate: 1 },
indexes: [ "status_1_orderDate_1" ]})

Como los valores se normalizan sin tener en cuenta la forma, este filtro también cubre { status: "PENDING" }{ status: "CANCELLED" }, y todos los demás valores de status la misma clasificación. No cubre el mismo predicado con un orden diferente o sin ningún tipo de clasificación, que son formas independientes. Confirme que el filtro se ha aplicado conexplain:

db.orders.find({ status: "SHIPPED" }).sort({ orderDate: 1 }).explain()

Los informes de salida indexFilterSet: true yindexFilterApplied: true, y los nombres de las IXSCAN etapasstatus_1_orderDate_1.

Ejemplo: fijar una actualización a un índice selectivo

Una actualización tiene que localizar los documentos que se van a modificar antes de poder escribirlos, y esa búsqueda utiliza un índice del mismo modo que lo hace una lectura. Cuando más de un índice puede servir de base a un predicado, el índice que elija el planificador determina cuántos documentos examina la actualización.

db.orders.updateMany(
  { customerId: 4815, status: "PENDING" },
  { $set: { status: "CANCELLED" } }
)

Ambos customerId_1 y status_1 pueden servir para este predicado. Para anclar la actualización acustomerId_1:

db.runCommand({planCacheSetFilter: "orders",
query: { customerId: 4815, status: "PENDING" },
indexes: [ "customerId_1" ]})

Los filtros de los comandos de escritura requieren Amazon DocumentDB 5.0.2 u 8.0.2 y la versión 2.0 o posterior del planificador. Compruébelo con una explain de las actualizaciones:

db.runCommand({explain: {update: "orders",
updates: [{ q: { customerId: 4815, status: "PENDING" },
             u: { $set: { status: "CANCELLED" } },
             multi: true }]}})

El plan ganador es UPDATE superar una IXSCAN etapacustomerId_1. Se aplica el mismo filtro a delete los findAndModify comandos que utilizan esta forma de consulta, ya que la forma no incluye el tipo de escritura.

Ejemplo: anclar una canalización agregada y una colección externa de $lookup

En el caso de una agregación, la forma se toma de la $match fase inicial e $sort inmediatamente después de ella. Las etapas posteriores, como $group o$project, no forman parte de la figura.

db.orders.aggregate([
  { $match: { status: "SHIPPED" } },
  { $group: { _id: "$customerId", total: { $sum: "$amount" } } }
])

Un filtro establecido en el $match predicado controla el índice que se utiliza para leer: orders

db.runCommand({planCacheSetFilter: "orders",
query: { status: "SHIPPED" },
indexes: [ "status_1" ]})

Los filtros también se aplican a la colección a la que se une una $graphLookup etapa $lookup o. El filtro se establece en la colección externa, no en la colección con la que se ejecuta la canalización. En la siguiente canalización, orders está la colección externa y customers es la colección externa:

db.orders.aggregate([
  { $lookup: { from: "customers",
               localField: "customerId",
               foreignField: "customerId",
               as: "customer" } }
])

Los sondeos se unen customers una vez por documento externo, por lo que el índice elegido allí se aplica repetidamente y su coste se multiplica por todo el proceso. Para fijar ese escaneo a un índice específico, active el filtro customers para la forma de igualdad de la clave de unión:

db.runCommand({planCacheSetFilter: "customers",
query: { customerId: 1 },
indexes: [ "customerId_1" ]})

Dado que los valores se normalizan fuera de la forma, el valor 1 anterior es un marcador de posición y cualquier valor produce el mismo filtro. Cuando se aplica un filtro de recopilación extranjera, aparecen el nivel superior y los indexFilterApplied campos, indexFilterSet y el índice en true el que se basa el filtro seleccionado aparece en la parte externa del plan ganador. Los filtros activados aggregate requieren Amazon DocumentDB 8.0.2 y Planner versión 3.0.

Comportamiento con sugerencias y cambios en el índice