Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
SE APLICA A: 
NoSQL
En este artículo se explica cómo consultar datos (como una colección, grafo o tabla) dentro de un contenedor de 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 siguiente consulta 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 predeterminado en Azure Cosmos DB.
Optimización de consultas entre particiones con índices secundarios globales
Los índices secundarios globales (versión preliminar) proporcionan un enfoque alternativo para evitar consultas entre particiones sin cambiar la clave de partición del contenedor. Un índice secundario global crea un contenedor independiente sincronizado automáticamente con una clave de partición diferente optimizada para patrones de consulta específicos.
Por ejemplo, si su contenedor está particionado por DeviceId pero consulta frecuentemente por Location, podría crear un índice secundario global particionado por Location. La consulta que antes era una consulta entre particiones ahora puede ejecutarse como una consulta dentro de la misma partición en el índice secundario global:
SELECT * FROM c WHERE c.Location = 'Seattle'
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 elMaxConcurrencyse establece en 0, hay una sola conexión de red a las particiones del contenedor.MaxBufferedItemCount: intercambia la latencia de consulta 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 paralelas.
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 de unidades de solicitud (RUs) 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 es un conductor de entrega que tiene que entregar paquetes a 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 cobrará por un mínimo de aproximadamente 2,5 RU cada vez que compruebe el índice de una partición física para obtener resultados aunque no haya elementos en la partición física que coincidan con el filtro de la consulta. Por lo tanto, si solo tiene una (o solo algunas) particiones físicas, las consultas entre particiones no consumen mucho más RU que las consultas en particiones.
El número de particiones físicas está asociado al número de RU aprovisionadas. Cada partición física permite hasta 10 000 RU 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:
- Tiene previsto tener más de 30 000 RU aprovisionadas
- Planea almacenar más de 100 GB de datos
Considere la posibilidad de usar índices secundarios globales (versión preliminar) para evitar consultas entre particiones. Los índices secundarios globales permiten crear contenedores adicionales con distintas claves de partición, sincronizadas automáticamente con el contenedor de origen. Este enfoque puede eliminar las consultas entre particiones para patrones de consulta específicos sin necesidad de cambios en la lógica de la aplicación o la clave de partición existentes.