Consulta de un contenedor de Azure Cosmos DB

SE APLICA A: NoSQL

En este artículo se explica cómo consultar un contenedor (colección, grafo, tabla) en Azure Cosmos DB. En concreto, se explica cómo funcionan las consultas en particiones y entre particiones en Azure Cosmos DB.

Consulta en la partición

Al consultar los datos de los contenedores, si la consulta tiene un filtro de clave de partición especificado, Azure Cosmos DB optimiza automáticamente la consulta. Enruta la consulta a las particiones físicas correspondientes a los valores de clave de partición especificados en el filtro.

Por ejemplo, considere la consulta siguiente con un filtro de igualdad en DeviceId. Si ejecutamos esta consulta en un contenedor con particiones en DeviceId, esta consulta se filtra en una sola partición física.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Como en el ejemplo anterior, esta consulta también filtra en una sola partición. Si se agrega el filtro en Location, esto no cambia la consulta siguiente:

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'

Esta es una consulta que tiene un filtro de intervalo en la clave de partición y no se limita a una única partición física. Para ser una consulta en particiones, la consulta debe tener un filtro de igualdad que incluya la clave de partición:

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Consulta entre particiones

La siguiente consulta no tiene un filtro en la clave de partición (DeviceId). Por tanto, necesita distribuirse a través de todas las particiones físicas para ejecutarse en el índice de cada partición:

SELECT * FROM c WHERE c.Location = 'Seattle`

Cada partición física tiene su propio índice. Por tanto, cuando se ejecuta una consulta entre particiones en un contenedor, se ejecuta eficazmente una consulta por partición física. De forma automática, Azure Cosmos DB agrega los resultados en distintas particiones físicas.

Los índices de distintas particiones físicas son independientes entre sí. No hay ningún índice global en Azure Cosmos DB.

Consulta entre particiones en paralelo

Los SDK 1.9.0 y posteriores de Azure Cosmos DB admiten opciones de ejecución de consultas en paralelo. Las consultas entre particiones en paralelo permiten realizar consultas de baja latencia entre particiones.

Puede administrar la ejecución de consultas en paralelo ajustando los parámetros siguientes:

• MaxConcurrency: establece el número máximo de conexiones de red simultáneas a las particiones del contenedor. Si establece esta propiedad en -1, el SDK administra el grado de paralelismo. Si MaxConcurrency se establece en 0, esto significa que hay una única conexión de red a las particiones del contenedor.

• MaxBufferedItemCount: equilibra la latencia de las consultas frente al uso de memoria del lado cliente. Si se omite esta opción o se establece en -1, el SDK administra el número de elementos almacenados en búfer durante la ejecución de consultas en paralelo.

Debido a la capacidad de Azure Cosmos DB de paralelizar las consultas entre particiones, la latencia de las consultas, por lo general, se escala correctamente, ya que el sistema agrega particiones físicas. Sin embargo, el cargo por RU aumenta significativamente a medida que aumenta el número total de particiones físicas.

Al ejecutar una consulta entre particiones, en esencia, se realiza una consulta independiente por cada partición física individual. Aunque las consultas entre particiones usan el índice si está disponible, estas no son tan eficientes como las consultas realizadas en una sola partición.

Ejemplo útil

Esta es una analogía para explicar mejor las consultas entre particiones:

Imagine que usted es un repartidor que debe entregar paquetes en diferentes complejos de apartamentos. Cada complejo de apartamentos tiene una lista con los números de apartamento de todos los residentes. Podemos comparar cada apartamento complejo con una partición física y cada lista con el índice de la partición física.

Se pueden comparar consultas en particiones y entre particiones mediante este ejemplo:

Consulta en una sola partición (ejemplo)

Si el controlador de entrega sabe el complejo de apartamento (partición física) correcto, puede dirigirse inmediatamente a la compilación correcta. Como repartidor, puede consultar la lista del complejo de apartamentos con los números de apartamento de los residentes (el índice) y ofrecer rápidamente los paquetes correspondientes. En este caso, el repartidor no pierde tiempo ni esfuerzo al conducir hasta un complejo de apartamentos para comprobar si hay destinatarios de paquetes que vivan allí.

Consulta entre particiones (distribución ramificada)

Si el repartidor no conoce cuál es el complejo de apartamentos (partición física), debe dirigirse a cada uno de los edificios de apartamentos y comprobar la lista con todos los números de apartamento de todos los residentes (el índice). Una vez que el repartidor llega a cada complejo de apartamentos, aún puede usar la lista de direcciones de cada residente. Sin embargo, debe comprobar todas las listas de complejos de apartamentos para verificar si los destinatarios de los paquetes viven ahí o no. Este ejemplo muestra cómo funcionan las consultas entre particiones. Aunque puede utilizar el índice (es decir, no necesita llamar a cada puerta), debe comprobar por separado el índice de cada partición física.

Consulta entre particiones (con ámbito solo en algunas particiones físicas)

Si el repartidor supiera que todos los destinatarios de los paquetes viven en un cierto número de complejos de apartamentos, no necesitaría transportarse a todos los complejos. Incluso cuando transportarse a unos cuantos complejos de apartamentos sigue requiriendo más trabajo que visitar un solo edificio, el repartidor puede ahorrar tiempo y esfuerzo de esta manera. Si una consulta tiene la clave de partición en su filtro con la palabra clave IN, solo comprueba los índices de los datos de la partición física pertinente.

Evitar las consultas entre particiones

Para la mayoría de contenedores, tener algunas consultas entre particiones es inevitable, lo que está bien. Casi todas las operaciones de consulta se admiten en las particiones, tanto para las claves lógicas de partición como para las particiones físicas. Azure Cosmos DB también tiene muchas optimizaciones en el motor de consulta y los SDK del cliente para paralelizar la ejecución de consultas en particiones físicas.

Para la mayoría de los escenarios con mucha lectura, se recomienda seleccionar la propiedad más común en los filtros de consulta. También debe asegurarse de que la clave de partición se adhiera a otras prácticas recomendadas para la selección de claves de partición.

Evitar las consultas entre particiones normalmente solo es importante con contenedores grandes. Se le cobra un mínimo de aproximadamente 2,5 RU cada vez que compruebe el índice de la partición física de los resultados, aunque no haya elementos en la partición física que coincidan con el filtro de la consulta. Por tanto, si solo tiene una (o pocas) particiones físicas, las consultas entre particiones no consumen más RU que las consultas en una sola partición.

El número de particiones físicas está ligado a la cantidad de RUs aprovisionadas. Cada partición física permite hasta 10 000 RUs aprovisionadas y puede almacenar hasta 50 GB de datos. Azure Cosmos DB administra de forma automática las particiones físicas. El número de particiones físicas en el contenedor depende del rendimiento aprovisionado y del almacenamiento consumido.

Debe intentar evitar las consultas entre particiones si la carga de trabajo cumple los criterios siguientes:

• Planea tener más de 30 000 RU aprovisionadas
• Planea almacenar más de 100 GB de datos

Pasos siguientes

Consulte los siguientes artículos para información sobre la creación de particiones en Azure Cosmos DB:

• Creación de particiones y escalado horizontal en Azure Cosmos DB
• Crear una clave de partición sintética en Azure Cosmos DB