Optimización del costo de las solicitudes en Azure Cosmos DB

  • Artículo

SE APLICA A: NoSQL MongoDB Cassandra Gremlin Table

En este artículo se describe cómo se traducen las solicitudes de lectura y escritura en unidades de solicitud y cómo optimizar el costo de estas solicitudes. Las operaciones de lectura incluyen lecturas y consultas puntuales. Las operaciones de escritura incluyen la inserción, el reemplazo, la eliminación y la inserción de elementos.

Azure Cosmos DB ofrece un amplio conjunto de operaciones de base de datos que se realizan en los elementos de un contenedor. El costo asociado a cada una de estas operaciones variará en función de la CPU, la E/S y la memoria necesarias para completar la operación. En lugar de administrar y pensar sobre los recursos de hardware, puede pensar en una unidad de solicitud (RU) como una medida única para los recursos necesarios para realizar varias operaciones de la base de datos y dar servicio a una solicitud.

Medición del cargo de una unidad de solicitud

Es importante medir el cargo de RU de las solicitudes para comprender el costo real y evaluar también la eficacia de las optimizaciones. Puede obtener este costo con Azure Portal o por medio de la inspección de la respuesta enviada desde Azure Cosmos DB mediante uno de los SDK. Consulte Búsqueda del cargo de unidad de solicitud en Azure Cosmos DB para obtener instrucciones detalladas sobre cómo lograrlo.

Lectura de datos: lecturas y consultas puntuales

Las operaciones de lectura en Azure Cosmos DB se suelen ordenar de la más rápida o eficiente a la más lenta o menos eficiente en cuanto a consumo de RU, de la siguiente manera:

  • Lecturas puntuales (búsqueda de clave y valor en un único id. de elemento y clave de partición).
  • Consulta con una cláusula de filtro en una única clave de partición.
  • Consulta sin una cláusula de filtro de igualdad o intervalo en cualquier propiedad.
  • Consulta sin filtros.

Rol del nivel de coherencia

Cuando se usan los niveles de coherenciafuerte u obsolescencia limitada, se duplica el costo de RU de cualquier operación de lectura (lectura o consulta puntual).

Lecturas puntuales

El único factor que afecta al cargo de RU de una lectura puntual (además del nivel de coherencia usado) es el tamaño del elemento recuperado. En la tabla siguiente se muestra el costo en RU de lecturas puntuales para los elementos con un tamaño de 1 KB y de 100 KB.

Tamaño del elemento Costo de una lectura puntual
1 KB 1 RU
100 KB 10 RU

Dado que las lecturas puntuales (búsquedas de clave/valor en el id. de elemento y clave de partición) son el tipo de lectura más eficaz, debe asegurarse de que el id. de elemento tenga un valor significativo para que pueda capturar los elementos con una lectura puntual (en lugar de una consulta) cuando sea posible.

Nota:

En la API para NoSQL, las lecturas puntuales solo se pueden realizar mediante la API de REST o los SDK. Las consultas que filtran por id. de elemento y clave de partición no se consideran una lectura puntual. Para ver un ejemplo con el SDK de .NET, consulte Lectura de un elemento en Azure Cosmos DB for NoSQL.

Consultas

Las unidades de solicitud para las consultas dependen de distintos factores. Por ejemplo, detalles sobre el número de elementos de Azure Cosmos DB cargado y devueltos, el número de búsquedas en el índice, el tiempo de compilación de consulta, etcétera. Azure Cosmos DB garantiza que la misma consulta de los mismos datos consumirá siempre el mismo número de unidades de solicitud, aunque se repitan las ejecuciones. El perfil de la consulta con métricas de ejecución de consultas ofrece una buena idea de cómo se invierten las unidades de solicitud.

En algunos casos podría ver una secuencia de 200 y 429 respuestas y unidades de solicitud variables en la ejecución paginada de las consultas; esto se debe a que estas se ejecutan lo más rápido posible en función de las RU disponibles. Quizá vea una ejecución de consulta dividida en varias páginas o en recorrido de ida y vuelta entre el cliente y servidor. Por ejemplo, 10 000 elementos pueden devolverse como varias páginas y que cada una se cargue en función del cálculo realizado para esa página. Al sumar estas páginas debe obtener el mismo número de unidades de solicitud que obtendría para la consulta completa.

Métricas para la solución de problemas de consultas

El rendimiento y la capacidad de proceso consumida por las consultas (incluidas las funciones definidas por el usuario) dependen principalmente del cuerpo de la función. La manera más sencilla de averiguar cuánto tiempo se dedica a la ejecución de consultas en la función definida por el usuario y el número de unidades de solicitud consumidas es habilitar las métricas de consulta. Si usa el SDK de .NET, estas son las métricas de consulta de ejemplo que este devuelve:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Procedimientos recomendados para optimizar el costo de las consultas

Al optimizar el costo de las consultas, considere los siguientes procedimientos recomendados:

  • Colocación de varios tipos de entidad

    Intente colocar varios tipos de entidad dentro de un único contenedor o en el menor número de ellos posible. Este método produce beneficios no solo en lo relativo a los precios, sino también respecto a las transacciones y la ejecución de las consultas. Las consultas se limitan a un único contenedor y las transacciones atómicas con varios registros a través de procedimientos almacenados o desencadenadores, a una clave de partición de un único contenedor. Colocar las entidades en el mismo contenedor puede reducir el número de recorridos de ida y vuelta en la red para resolver las relaciones entre registros. Por lo tanto, aumenta el rendimiento de un extremo a otro, permite las transacciones atómicas con varios registros para un mayor conjunto de datos y, como resultado, reduce los costos. Si la colocación de varios tipos de entidad en un único contenedor o en un número reducido de estos resulta difícil en su caso, normalmente porque va a migrar una aplicación existente y no quiere realizar cambios de código, debe considerar el rendimiento del aprovisionamiento a nivel de la base de datos.

  • Medición y optimización del uso menor de unidades de solicitud por segundo

    La complejidad de una consulta afecta a la cantidad de unidades de solicitud (RU) consumidas para una operación. El número de predicados, la naturaleza de estos, el número de UDF y el tamaño del conjunto de datos de origen son factores que influyen en el costo de las operaciones de consulta.

Azure Cosmos DB proporciona un rendimiento predecible en cuanto a rendimiento y latencia con un modelo de rendimiento aprovisionado. El rendimiento aprovisionado se representa en términos de unidades de solicitud por segundo o RU/s. Una unidad de solicitud (RU) es una abstracción lógica a través de los recursos de proceso, como CPU, memoria, E/S, etc., que son necesarios para realizar una solicitud. El rendimiento aprovisionado (RU) se reserva y está dedicado a su contenedor o base de datos para ofrecer un rendimiento y latencia predecibles. El rendimiento aprovisionado permite a Azure Cosmos DB ofrecer un rendimiento coherente y predecible, baja latencia garantizada y alta disponibilidad a cualquier escala. Las unidades de solicitud representan la moneda normalizada que simplifica el razonamiento sobre cuántos recursos necesita una aplicación.

El cargo de la solicitud devuelto en el encabezado de solicitud indica el costo de una consulta determinada. Por ejemplo, si una consulta devuelve 1000 elementos de 1 KB, el costo de la operación es 1000. Por lo tanto, al cabo de un segundo, el servidor atenderá solo dos de estas solicitudes antes de limitar la velocidad de las solicitudes posteriores. Para más información, consulte el artículo sobre las unidades de solicitud y la calculadora de unidades de solicitud.

Escritura de datos

El costo de RU de escribir un elemento depende de:

  • El tamaño del elemento.
  • El número de propiedades que se incluyen en la directiva de indexación y que es necesario indexar.

La inserción de un elemento de 1 KB sin indexación cuesta en torno a 5,5 RU. El reemplazo un elemento cuesta el doble que la inserción del mismo elemento.

Optimización de escrituras

La mejor manera de optimizar el costo de RU de las operaciones de escritura es adoptar un tamaño adecuado para los elementos y el número de propiedades que se indexan.

  • Almacenar elementos muy grandes en Azure Cosmos DB da como resultado altos cargos de RU y se puede considerar un antipatrón. En concreto, no almacene contenido binario o fragmentos grandes de texto que no necesite consultar. Un procedimiento recomendado es poner este tipo de datos en Azure Blob Storage y almacenar una referencia (o vínculo) al blob en el elemento que se escribe en Azure Cosmos DB.
  • La optimización de la directiva de indexación para indizar solo las propiedades por las que se filtran las consultas puede suponer una gran diferencia en la RU consumida por las operaciones de escritura. Al crear un nuevo contenedor, la directiva de indexación predeterminada indexa cada una de las propiedades que se encuentran en los elementos. Aunque se trata de un buen valor predeterminado para las actividades de desarrollo, se recomienda volver a evaluar y personalizar la directiva de indexación cuando pase a producción o cuando la carga de trabajo empiece a recibir un tráfico significativo.

Al realizar la ingesta masiva de datos, también se recomienda usar la biblioteca BulkExecutor de Azure Cosmos DB, ya que está diseñada para optimizar el consumo de RU de tales operaciones. Opcionalmente, también puede usar Azure Data Factory, que se basa en esa misma biblioteca.

Pasos siguientes

A continuación, puede seguir obteniendo más información sobre la optimización de costos en Azure Cosmos DB con los siguientes artículos: