Optimización del rendimiento de consultas con Azure Cosmos DB

SE APLICA A: NoSQL

Azure Cosmos DB proporciona una API para NoSQL para consultar datos, sin necesidad de índices de esquema o secundarios. En este artículo se proporciona la siguiente información para los desarrolladores:

• Detalles de alto nivel sobre cómo funciona la ejecución de consultas SQL de Azure Cosmos DB
• Sugerencias y procedimientos recomendados para el rendimiento de consultas
• Ejemplos de cómo usar métricas de ejecución de consultas SQL para depurar el rendimiento de las consultas

Acerca de la ejecución de consultas SQL

En Azure Cosmos DB, los datos se almacenan en contenedores, que pueden crecer hasta cualquier tamaño de almacenamiento o rendimiento de las solicitudes. Azure Cosmos DB escala los datos de forma fluida entre particiones físicas en segundo plano para controlar el crecimiento de los datos o los aumentos del rendimiento aprovisionado. Puede emitir consultas SQL a cualquier contenedor mediante la API de REST o uno de los SDK de SQL compatibles.

Una breve introducción a la creación de particiones: se define una clave de partición como "ciudad", que determina la forma en que los datos se dividen entre particiones físicas. Los datos que pertenecen a una única clave de partición (por ejemplo, "city" == "Seattle") se almacenan en una partición física y una única partición física puede almacenar datos de varias claves de partición. Cuando una partición física alcanza su límite de almacenamiento, el servicio la divide sin ningún problema en dos nuevas particiones. Los datos se distribuyen de manera uniforme entre las nuevas particiones, y todos los datos de una sola clave de partición se mantienen agrupados. Como las particiones son transitorias, las API usan una abstracción de un intervalo de claves de partición, que indica los intervalos de valores hash de clave de partición.

Cuando se emite una consulta a Azure Cosmos DB, el SDK realiza estos pasos lógicos:

• Analiza la consulta SQL para determinar el plan de ejecución de consultas.
• Si la consulta incluye un filtro con la clave de partición, como SELECT * FROM c WHERE c.city = "Seattle", se enruta a una única partición. Si la consulta no tiene un filtro en la clave de partición, se ejecuta en todas las particiones y los resultados de cada una se combinan en el lado cliente.
• La consulta se ejecuta dentro de cada partición en serie o en paralelo, en función de la configuración del cliente. En cada partición, la consulta podría realizar uno o varios viajes en función de la complejidad de la consulta, el tamaño de página configurado y el rendimiento aprovisionado de la colección. Cada ejecución devuelve el número de unidades de solicitud que se consumen en la ejecución de la consulta y estadísticas de ejecución de consultas.
• El SDK realiza un resumen de los resultados de la consulta entre particiones. Por ejemplo, si la consulta implica una cláusula ORDER BY entre particiones, los resultados de particiones individuales se ordenan mediante combinación para devolver resultados en orden clasificado globalmente. Si la consulta es una agregación como COUNT, los recuentos de particiones individuales se suman para generar el recuento total.

Los SDK ofrecen diversas opciones para la ejecución de consultas. Por ejemplo, en .NET estas opciones están disponibles en la clase QueryRequestOptions. En la tabla siguiente se describen estas opciones y cómo pueden afectar al tiempo de ejecución de la consulta.

Por ejemplo, esta es una consulta en un contenedor con particiones creadas por /city mediante el SDK de .NET:

QueryDefinition query = new QueryDefinition("SELECT * FROM c WHERE c.city = 'Seattle'");
QueryRequestOptions options = new QueryRequestOptions()
{
    MaxItemCount = -1,
    MaxBufferedItemCount = -1,
    MaxConcurrency = -1,
    PopulateIndexMetrics = true
};
FeedIterator<dynamic> feedIterator = container.GetItemQueryIterator<dynamic>(query);

FeedResponse<dynamic> feedResponse = await feedIterator.ReadNextAsync();

Cada de ejecución de una consulta se corresponde a una API de REST POST con encabezados establecidos para las opciones de solicitud de consulta y la consulta SQL en el cuerpo. Para más información sobre los encabezados de solicitud y las opciones de la API de REST, consulte Querying resources using the REST API (Consulta de recursos mediante la API de REST).

Procedimientos recomendados para el rendimiento de consultas

Los siguientes factores suelen tener el mayor efecto en el rendimiento de las consultas de Azure Cosmos DB. Se profundizará más en cada uno de estos factores en este artículo.

Rendimiento aprovisionado

En Azure Cosmos DB, se crean contenedores de datos, cada uno con un rendimiento reservado expresado en unidades de solicitud (RU) por segundo. Una lectura de un documento de 1 KB es 1 RU, y cada operación (incluidas las consultas) se normaliza a un número fijo de RU según su complejidad. Por ejemplo, si tiene 1000 RU/s aprovisionadas para el contenedor y tiene una consulta como SELECT * FROM c WHERE c.city = 'Seattle' que consume 5 RU, puede ejecutar (1000 RU/s)/(5 RU/consulta) = 200 de estas consultas por segundo.

Si envía más de 200 consultas por segundo (u otras operaciones que saturan todas las RU aprovisionadas), el servicio empieza a limitar la velocidad de las solicitudes entrantes. Los SDK controlan automáticamente esta limitación de velocidad mediante la realización de un retroceso/reintento; por tanto, es posible que advierta una latencia más alta para estas consultas. El aumento del rendimiento aprovisionado al valor necesario mejora la latencia de las consultas y el rendimiento.

Para más información sobre las unidades de solicitud, consulte Unidades de solicitud.

Creación de particiones y claves de partición

Con Azure Cosmos DB, los siguientes escenarios para leer datos se ordenan de los normalmente más rápidos o eficaces a los más lentos o menos eficaces.

• GET en una sola clave de partición e identificador de elemento, también conocido como lectura de punto
• Consulta con una cláusula de filtro en una única clave de partición
• Consulta con una cláusula de filtro de igualdad o intervalo en cualquier propiedad
• Sin filtros de consulta

Las consultas que necesitan ejecutarse en todas las particiones tienen una mayor latencia y pueden consumir un mayor número de RU. Puesto que cada partición tiene indexación automática en todas las propiedades, la consulta se puede atender eficazmente desde el índice en este caso. Puede acelerar las consultas que abarcan particiones mediante las opciones de paralelismo.

Para aprender más sobre la creación de particiones y las claves de particiones, consulte Creación de particiones en Azure Cosmos DB.

SDK y opciones de consulta

Vea Sugerencias de rendimiento de consultas y Pruebas de rendimiento para saber cómo obtener el mejor rendimiento del lado cliente de Azure Cosmos DB al usar nuestros SDK.

Latencia de red

Vea Distribución global de Azure Cosmos DB para saber cómo configurar la distribución global y conectarse a la región más cercana. La latencia de red tiene un efecto significativo en el rendimiento de consultas cuando es necesario realizar varios recorridos de ida y vuelta, o recuperar un gran conjunto de resultados de la consulta.

Puede usar métricas de ejecución de consultas para recuperar el tiempo de ejecución del servidor de consultas, lo que le permite diferenciar entre el tiempo invertido en la ejecución de la consulta y el tiempo empleado en el tránsito de la red.

Directiva de indexación

Vea Configuración de la directiva de indexación para obtener rutas de indexación, clases y modos, y cómo afectan a la ejecución de consultas. De manera predeterminada, Azure Cosmos DB aplica indexación automática a todos los datos y usa índices de intervalo para cadenas y números, lo que es eficaz para las consultas de igualdad. Para escenarios de inserción de alto rendimiento, considere la posibilidad de excluir rutas de acceso a fin de reducir el costo de RU para cada operación de inserción.

Puede usar las métricas de índice a fin de identificar qué índices se usan para cada consulta y si faltan índices que mejorarían el rendimiento de las consultas.

Métricas de ejecución de consultas

Se devuelven métricas detalladas para cada ejecución de consulta en el diagnóstico para la solicitud. Estas métricas describen dónde se invierte el tiempo durante la ejecución de las consultas y habilitan la solución de problemas avanzada.

Más información sobre cómo obtener las métricas de consulta.

Los SDK de cliente pueden realizar internamente varias solicitudes de consulta para atender la consulta dentro de cada partición. El cliente realiza más de una llamada por partición si los resultados totales superan la opción de solicitud de número máximo de elementos, si la consulta supera el rendimiento aprovisionado de la partición, si la carga de consultas alcanza el tamaño máximo por página o si la consulta alcanza el límite de tiempo de espera asignado al sistema. Cada ejecución de consultas parcial devuelve métricas de consulta para esa página.

Estos son algunos ejemplos de consultas y cómo interpretar algunas de las métricas devueltas en la ejecución de consultas:

Pasos siguientes

• Para conocer los operadores de consulta y palabras clave SQL admitidos, consulte Consultas SQL.
• Para aprender más sobre las unidades de solicitud, consulte Unidades de solicitud.
• Para aprender más sobre la directiva de indexación, consulte Directiva de indexación