Saltar al contenido principal

 Subscribe

Los índices compuestos se incorporaron a Azure Cosmos DB en Microsoft Build 2019. Con la última actualización del servicio, los tipos de consulta adicionales pueden aprovechar los índices compuestos. En esta entrada exploraremos los índices compuestos y destacaremos los casos de uso más comunes.

Tipos de índice en Azure Cosmos DB

Actualmente, Azure Cosmos DB tiene los siguientes tipos de índice que se utilizan para los siguientes tipos de consultas:

Índices por rango:

  • Consultas de igualdad
  • Consultas por rango
  • Consultas de tipo ORDER BY para ordenar por una sola propiedad
  • Consultas de tipo JOIN

Índices espaciales:

  • Funciones geoespaciales

Índices compuestos:

  • Consultas de tipo ORDER BY para ordenar por varias propiedades
  • Consultas con un filtro y una cláusula ORDER BY
  • Consultas para filtrar por dos o más propiedades

Casos de uso de los índices compuestos

De forma predeterminada, Azure Cosmos DB crea un índice por rango para cada propiedad. Para muchas cargas de trabajo, estos índices son suficientes y no es necesario realizar más optimizaciones. Además de los índices por rango predeterminados, se pueden agregar índices compuestos. Los índices compuestos tienen una ruta de acceso y un orden (ASC o DESC) definidos para cada propiedad dentro del índice compuesto.

Consultas de tipo ORDER BY para ordenar por varias propiedades

Si una consulta tiene una cláusula ORDER BY con dos o más propiedades, se requiere un índice compuesto. Por ejemplo, la consulta siguiente requiere que se defina un índice compuesto para age (antigüedad) y name (nombre) (age ASC, name ASC):

SELECT * FROM c ORDER BY c.age ASC, c.name ASC

Esta consulta ordenará todos los resultados en orden ascendente por el valor de la propiedad age. Si dos documentos tienen el mismo valor de age, la consulta los ordenará por name.

Consultas con un filtro y una cláusula ORDER BY

Si una consulta tiene un filtro y una cláusula ORDER BY para distintas propiedades, un índice compuesto mejorará el rendimiento. Por ejemplo, la consulta siguiente requerirá menos unidades de solicitud (RU) si se define un índice compuesto para name y age, y se actualiza la consulta para incluir el valor de name en la cláusula ORDER BY:

Consulta original que utiliza un índice por rango:

SELECT * FROM c WHERE c.name = “Tim” ORDER BY c.age ASC

Consulta revisada que utiliza un índice compuesto para name y age:

SELECT * FROM c WHERE c.name = “Tim” ORDER BY c.name ASC, c.age ASC

Aunque un índice compuesto mejora considerablemente el rendimiento de las consultas, todavía puede ejecutar la consulta original correctamente sin un índice compuesto. Al ejecutar la consulta revisada con un índice compuesto, se ordenarán los documentos por la propiedad age. Dado que todos los documentos que coinciden con el filtro tienen el mismo valor de name, la consulta los devolverá en orden ascendente por el valor de la propiedad age.

Consultas con un filtro para varias propiedades

Si una consulta tiene un filtro para dos o más propiedades, se puede mejorar el rendimiento agregando un índice compuesto.

Considere la siguiente consulta:

SELECT * FROM c WHERE c.name = “Tim” and c.age > 18

En ausencia de un índice compuesto para (name ASC y age ASC), usaremos un índice por rango para esta consulta. Podemos mejorar la eficacia de esta consulta creando un índice compuesto para la propiedades name y age.

Las consultas con varios filtros de igualdad y un máximo de un filtro por rango (como >, <, <=, >=, !=) utilizarán el índice compuesto. En algunos casos, si una consulta no puede utilizar totalmente un índice compuesto, usará una combinación de los índices compuestos y los índices por rango definidos. Para obtener más información, consulte la documentación de la directiva de indexación.

Ventajas de rendimiento de los índices compuestos

Podemos ejecutar algunas consultas de ejemplo para mostrar las ventajas de rendimiento de los índices compuestos. Usaremos un conjunto de datos de nutrición que se utiliza en los laboratorios de Azure Cosmos DB.

En este ejemplo, optimizaremos una consulta que tiene un filtro y una cláusula ORDER BY. Comenzaremos con la directiva de indexación predeterminada, que indexa todas las propiedades con un índice por rango. Al ejecutar la siguiente consulta como se indica en la imagen siguiente en Azure Portal, observamos las métricas de la consulta:

Métricas de la consulta:

Consulta que utiliza un índice por rango y consume 21,8 RU.

Esta consulta, con la directiva de indexación predeterminada, necesitó 21,8 RU.

Al agregar un índice compuesto para foodGroup y _ts, y actualizar el texto de la consulta para incluir foodGroup en la cláusula ORDER BY, se redujo considerablemente el cargo de RU de la consulta.

Métricas de la consulta:

Consulta que utiliza un índice compuesto y consume 4,07 RU.

Después de agregar un índice compuesto, el cargo de RU de la consulta disminuyó de 21,8 RU a solo 4,07 RU. Esta optimización de la consulta será especialmente impactante a medida que aumente el tamaño total de los datos. Las ventajas de un índice compuesto son significativas cuando las propiedades de la cláusula ORDER BY tienen una cardinalidad alta.

Creación de índices compuestos

Puede obtener más información sobre la creación de índices compuestos en esta documentación. Actualizar la directiva de indexación directamente desde Azure Portal es fácil. Al crear un índice compuesto para los datos que ya están en Azure Cosmos DB, la actualización del índice utilizará el resto de RU de las operaciones normales. Una vez definida la nueva directiva de indexación, Azure Cosmos DB indexará automáticamente las propiedades con un índice compuesto a medida que se escriban.

Vea si los índices compuestos mejorarán el uso de RU para sus cargas de trabajo actuales en Azure Cosmos DB.

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation