setQuerySettings (comando de base de datos)

Query Settings and filtros de índices

A partir de MongoDB 8.0, los filtros de índice están en desuso. En su lugar, utiliza la configuración de query.

Los ajustes de query tienen más funcionalidades que los filtros de índices. Los filtros de índice no son persistentes y es difícil crear filtros de índice para todos los nodos del clúster.

Configurar los ajustes de query pasando una query

En la siguiente sintaxis, usted proporciona:

• Los mismos campos que un comando find, distinct o aggregate. Consulta las secciones de sintaxis en las páginas de esos comandos para ver los campos que puedes incluir en setQuerySettings.

• Un campo $db para especificar la base de datos para los ajustes de la query.

• Un documento settings con indexHints y otros campos.

db.adminCommand( {
   setQuerySettings: {
      <fields>,  // Provide fields for
                 // find, distinct, or aggregate command
      $db: <string>  // Provide a database name
   },
   // Provide a settings document with indexHints and other fields
   settings: {
      indexHints: [ {
         ns: { db: <string>, coll: <string> },
         allowedIndexes: <array>
      }, ... ],
      queryFramework: <string>,
      reject: <boolean>,
      comment: <BSON type>,
      queryKnobs: <document>,
      maxTimeMS: <non-negative integer>
   }
} )

Establecer la configuración del query pasando un hash de forma del query

Puede proporcionar una cadena hash de forma del query existente en setQuerySettings y un documento actualizado settings con indexHints y otros campos:

db.adminCommand( {
   setQuerySettings: <string>,  // Provide an existing query shape hash string
   // Provide a settings document with indexHints and other fields
   settings: {
      indexHints: [ {
         ns: { db: <string>, coll: <string> },
         allowedIndexes: <array>
      }, ... ],
      queryFramework: <string>,
      reject: <boolean>,
      comment: <BSON type>,
      queryKnobs: <document>,
      maxTimeMS: <non-negative integer>
   }
} )

Un hash de forma del query es un string que identifica de manera única la forma del query. Un ejemplo de forma del query hash es "F42757F1AEB68B4C5A6DE6182B29B01947C829C926BCC01226BDA4DDE799766C".

En las versiones compatibles actuales, se espera que la misma estructura de consulta genere el mismo hash en todos los nodos y tipos de implementación. Para saber cómo se comporta el hash en todos los nodos, tipos de implementación y clústeres, consulte Estabilidad del hash de la estructura de consulta.

Para obtener la string hash de la forma del query, haz cualquiera de estos:

• Utilice una etapa $querySettings en un pipeline de agregación y examine el campo queryShapeHash.

• Examina la salida del perfilador de base de datos.

• Ver los registros de consultas lentas.

Si configuras los parámetros de query utilizando una string encriptada, el campo representativeQuery no está presente inicialmente en el resultado de la etapa de agregación $querySettings.

A partir de MongoDB 8.3, si el FCV es 8.3 o posterior, MongoDB rellena el campo representativeQuery con la configuración de consulta que usted defina mediante un hash de forma de consulta. Cuando MongoDB ejecuta una consulta que coincide con la forma de consulta, programa el relleno. Este proceso no requiere ninguna acción por su parte.

El rellenado se ejecuta de forma asincrónica con el máximo esfuerzo para limitar el impacto en el rendimiento de tus queries. No se garantiza que una configuración de query se rellene la primera vez que se ejecuta una query coincidente. Si un rellenado no se completa, MongoDB lo intenta de nuevo la próxima vez que se ejecuta una query coincidente.

Para albergar las additional representative queries, MongoDB 8.3 también aumenta la capacidad de almacenamiento para representative queries en configuraciones de query más allá del límite original de 16 MB del documento BSON.

Perillas de consulta

A partir de MongoDB 9.0, puede usar la configuración queryKnobs para anular los parámetros internos del servidor para una única forma de consulta en lugar de para toda la instancia. Configure el campo queryKnobs para consultas específicas para mitigar el impacto de una forma regresiva sin cambiar el comportamiento de otras cargas de trabajo en la misma implementación.

Por ejemplo, puede anular el parámetro del servidor notablescan para una única forma de consulta en lugar de para toda la instancia estableciendo queryKnobs en { noTableScan: true }.

Cada perilla mantiene el tipo, los límites y el valor predeterminado de su parámetro de servidor subyacente, y setQuerySettings ejecuta la misma validación que setParameter. setQuerySettings rechaza los siguientes valores:

• perillas desconocidas

• Controles que no están marcados como configurables a través de la configuración de consulta.

• Tipos BSON incorrectos

• Cadenas de enumeración no válidas

• Valores fuera de rango

• Mandos cuyo requisito mínimo de FCV supera el FCV del grupo

El valor efectivo de un mando sigue esta precedencia, de mayor a menor:

1. Valor por forma establecido con queryKnobs

2. Valor establecido para toda la instancia con setParameter

3. Valor predeterminado compilado

Los parámetros de consulta forman parte de la configuración de consulta hash, por lo que también forman parte de la clave de caché del plan. Si se modifica el valor de un parámetro, MongoDB genera una nueva clave de caché del plan, de modo que el planificador crea un plan nuevo en lugar de reutilizar un plan almacenado en caché obsoleto.

A diferencia de setParameter, que se aplica por proceso y puede diferir entre nodos, MongoDB aplica los mismos valores de queryKnobs en todo el clúster para la forma de consulta coincidente.