Preguntas más frecuentes sobre el rendimiento aprovisionado por Escalabilidad automática en Azure Cosmos DB

SE APLICA A: NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB usa el rendimiento aprovisionado de escalabilidad automática para administrar y escalar automáticamente las unidades de solicitud por segundo (RU/s) de la base de datos o el contenedor en función del uso. Este artículo responde a las preguntas más frecuentes sobre la escalabilidad automática de Azure Cosmos DB.

¿Cuál es la diferencia entre escalabilidad automática y Autopilot en Azure Cosmos DB?

Escalabilidad automática o rendimiento aprovisionado de escalabilidad automática es el nombre actualizado de la característica de Azure Cosmos DB que anteriormente se llamaba Autopilot. En la versión actual de la escalabilidad automática, hemos agregado nuevas características, incluido el soporte mediante programación y la capacidad de establecer un número máximo de RU/s.

¿Qué ocurre con las bases de datos o los contenedores creados en el modelo del nivel de Autopilot anterior?

Los recursos que se han creado en el modelo del nivel anterior se admiten automáticamente en el nuevo modelo del número máximo de RU/s personalizadas de escalabilidad automática. El límite superior del nivel se convierte en las nuevas RU/s máximas, lo que da como resultado el mismo intervalo de escala.

Por ejemplo, si anteriormente ha seleccionado el nivel que escalaba entre 400 RU/s y 4000 RU/s, la base de datos o el contenedor ahora muestran un máximo de 4000 RU/s, que se escalan entre 400 RU/s y 4000 RU/s. Después, puede cambiar el número máximo de RU/s a un valor personalizado en función de su carga de trabajo.

¿Cuál es el punto de entrada de RU/s para la escalabilidad automática?

A partir de abril de 2022, puede establecer la escalabilidad automática con un número máximo de RU/s tan bajo como 1000 RU/s (escala entre 100 RU/s y 1000 RU/s). También puede establecer un intervalo de escala de 200 RU/s a 2000 RU/s o 300 RU/s a 3000 RU/s. Anteriormente, el punto de entrada era de 400 RU/s a 4000 RU/s.

Se recomienda esta configuración para las cargas de trabajo que tienen requisitos de bajo rendimiento, pero que todavía se pueden escalar al número máximo de RU/s.

¿Con qué rapidez se escala verticalmente la escalabilidad automática en función de los incrementos de tráfico?

Con la escalabilidad automática, el sistema escala verticalmente el valor T o reduce verticalmente el valor T de rendimiento (RU/s) dentro del rango de 0,1 × Tmax a Tmax en función del tráfico entrante. Dado que el escalado es automático e instantáneo, puede consumir hasta el valor de Tmax aprovisionado en cualquier momento, sin ningún retraso.

¿Cómo puedo determinar a qué número de RU/s está escalado actualmente el sistema?

Use las métricas de Azure Monitor para supervisar el número máximo de RU/s de escalabilidad automática aprovisionado y el rendimiento actual (RU/s) al que se escala el sistema.

¿Cuál es el precio de la escalabilidad automática?

Cada hora, se le facturará el mayor rendimiento T al que se escaló el sistema en esa hora. Si el recurso no ha tenido ninguna solicitud durante dicha hora o no se ha escalado más allá de 0,1 × Tmax, se le facturará por el mínimo de 0,1 × Tmax. Para más detalles, consulte la página de precios de Azure Cosmos DB.

¿Cómo se muestra la escalabilidad automática en la factura?

En las cuentas con una sola región de escritura, la tarifa de escalabilidad automática por cada 100 RU/s es 1,5 veces la tarifa del rendimiento aprovisionado estándar (manual). Su factura muestra el medidor de rendimiento aprovisionado estándar existente. La cantidad de este medidor se multiplica por 1,5. Por ejemplo, si el número más alto de RU/s al que se ha escalado el sistema en una hora fue de 6000 RU/s, se le facturarán 60 × 1,5 = 90 unidades del medidor durante esa hora.

En las cuentas que tienen varias regiones de escritura, la tarifa de escalabilidad automática por cada 100 RU/s es la misma que la tarifa del rendimiento aprovisionado estándar (manual) de varias regiones de escritura. La factura muestra el medidor de varias regiones de escritura existente. Dado que las tarifas son las mismas, si usa la escalabilidad automática, verá la misma cantidad que para el rendimiento estándar.

¿Funciona la escalabilidad automática con capacidad reservada?

Sí. Con capacidad reservada para cuentas con regiones de escritura únicas, el descuento por reserva de los recursos de escalabilidad automática se aplica al uso del medidor con una proporción de 1,5 veces la proporción de la región específica. Por ejemplo, si desea usar la capacidad reservada para cubrir 10 000 RU/s de escalado automático, debe planear la compra de 15 000 RU/s de capacidad reservada en general.

La capacidad reservada con varias regiones de escritura funciona del mismo modo para la escalabilidad automática y el rendimiento aprovisionado estándar (manual). Para más información, consulte Capacidad reservadas de Azure Cosmos DB.

¿La escalabilidad automática funciona con el nivel gratis de Azure Cosmos DB?

Sí. En el nivel gratis, puede usar el rendimiento de escalabilidad automática en un contenedor o una base de datos. Obtenga más información sobre cómo funciona la facturación del nivel gratis con la escalabilidad automática.

¿La escalabilidad automática se admite para todas las API?

Sí. La escalabilidad automática es compatible con todas las API: NoSQL, Gremlin, Table, Cassandra y MongoDB.

¿Se admite la escalabilidad automática para las cuentas con varias regiones de escritura?

Sí. El número máximo de RU/s está disponible en cada región que se agregue a la cuenta de Azure Cosmos DB.

¿Cómo habilito la escalabilidad automática para nuevos contenedores o bases de datos?

¿Se puede habilitar la escalabilidad automática en una base de datos o un contenedor existente?

Sí. También puede cambiar entre la escalabilidad automática y el rendimiento aprovisionado estándar (manual). Actualmente, para todas las API, puede usar Azure Portal, la CLI de Azure o PowerShell para realizar estas operaciones. De forma predeterminada, no puede usar los SDK de cliente de Azure Cosmos DB ni una plantilla de Azure Resource Manager para migrar entre el rendimiento aprovisionado manual y la escalabilidad automática. Sin embargo, puede usar los SDK de cliente o una plantilla de Azure Resource Manager para crear nuevos recursos de escalabilidad automática y cambiar el número máximo de RU/s en un recurso de escalabilidad automática existente.

¿Cómo funciona la migración entre la escalabilidad automática y el rendimiento aprovisionado estándar (manual)?

Conceptualmente, el cambio del tipo de rendimiento es un proceso de dos fases. En primer lugar, se envía una solicitud para cambiar la configuración de rendimiento para usar la escalabilidad automática o el rendimiento aprovisionado manual. En ambos casos, el sistema determina y establece automáticamente un valor de RU/s inicial, en función de la configuración de rendimiento actual y el almacenamiento. Durante este paso, no se acepta ningún valor de RU/s proporcionado por el usuario. Después, una vez completada la actualización, puede cambiar el número de RU/s para que se adapten a su carga de trabajo.

Migración del rendimiento aprovisionado estándar (manual) a la escalabilidad automática

En el caso de un contenedor, use la siguiente fórmula para calcular el número máximo de RU/s inicial de la escalabilidad automática:

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10) redondeado a los 1000 RU/s más cercanos.

El número máximo de RU/s inicial real de escalabilidad automática puede variar en función de la configuración de la cuenta.

Ejemplo #1: Tiene un contenedor con un rendimiento aprovisionado manual de 10 000 RU/s y 25 GB de almacenamiento. Al habilitar la escalabilidad automática, el número máximo de RU/s inicial para la escalabilidad automática es 10 000 RU/s, que se puede escalar entre 1000 RU/s y 10 000 RU/s.

Ejemplo #2: Tiene un contenedor con un rendimiento aprovisionado manual de 50 000 RU/s y 25 000 GB de almacenamiento. Al habilitar la escalabilidad automática, el número máximo de RU/s inicial para la escalabilidad automática es 250 000 RU/s, que se puede escalar entre 25 000 RU/s y 250 000 RU/s.

Migración de la escalabilidad automática al rendimiento aprovisionado estándar (manual)

El rendimiento aprovisionado manual inicial es igual al número máximo de RU/s actual de la escalabilidad automática.

Ejemplo: Tiene una base de datos o un contenedor de escalabilidad automática que tiene un número máximo de 20 000 RU/s (escala entre 2000 RU/s y 20 000 RU/s). Al actualizar para usar el rendimiento aprovisionado manual, el rendimiento inicial es de 20 000 RU/s.

¿Puedo usar la CLI de Azure, PowerShell o Azure Resource Manager para administrar bases de datos o contenedores que usan escalabilidad automática?

Sí. Para habilitar la escalabilidad automática en una base de datos o un contenedor existentes mediante programación, puede usar la CLI de Azure o PowerShell.

Para crear una base de datos o un contenedor que use escalabilidad automática, puede usar la CLI de Azure, PowerShell o una plantilla de Azure Resource Manager.

¿Se admite la escalabilidad automática en las bases de datos de rendimiento compartido?

Sí. Para habilitar la escalabilidad automática para una base de datos de rendimiento compartido, al crear la base de datos, seleccione escalabilidad automática y la opción Aprovisionar rendimiento.

¿Cuántos contenedores se permiten por base de datos de rendimiento compartido cuando está habilitada la escalabilidad automática?

Azure Cosmos DB requiere un máximo de 25 contenedores en una base de datos de rendimiento compartido. El máximo se aplica a las bases de datos que tienen escalabilidad automática o rendimiento estándar (manual).

¿Cómo afecta la escalabilidad automática al nivel de coherencia de la base de datos?

La escalabilidad automática no tiene ningún efecto en el nivel de coherencia de una base de datos.

Para más información, consulte Niveles de coherencia.

¿Cuál es el límite de almacenamiento asociado a cada opción de máximo de RU/s?

El límite de almacenamiento en GB para cada máximo de RU/s es el número máximo de RU/s de la base de datos o contenedor dividido entre 10. Por ejemplo, si el número máximo de RU/s es 20 000 RU/s, el recurso puede admitir 2000 GB de almacenamiento.

Para ver las opciones de almacenamiento y el número máximo de RU/s disponibles, consulte Aprovisionamiento de límites de escalabilidad automática y rendimiento.

¿Qué ocurre si se supera el límite de almacenamiento asociado al rendimiento máximo?

Si se supera el límite de almacenamiento asociado al rendimiento máximo de la base de datos o el contenedor, Azure Cosmos DB aumentará automáticamente el rendimiento máximo hasta el siguiente número de RU/s que pueda admitir ese nivel de almacenamiento.

En un escenario de ejemplo, si comienza con un máximo de 50 000 RU/s (escala entre 5000 y 50 000 RU/s), puede almacenar hasta 5000 GB de datos. Si el tamaño de almacenamiento aumenta a 5001 GB, el almacenamiento ahora es de 6000 GB y el nuevo número máximo de RU/s es de 60 000 RU/s (escala entre 6 000 RU/s y 60 000 RU/s).

¿Puedo cambiar el número máximo de RU/s en una base de datos o contenedor?

Sí. Para obtener más información, consulte Cómo aprovisionar el rendimiento de escalabilidad automática.

Cuando se cambia el número máximo de RU/s, según el valor solicitado, la operación asincrónica puede tardar de 4 a 6 horas en finalizar. Más información.

¿Cómo puedo aumentar el número máximo de RU/s?

Cuando se envía una solicitud para aumentar el número máximo de RU/s Tmax, en función del número máximo de RU/s seleccionado, el servicio aprovisiona más recursos para admitir el número máximo de RU/s más alto. Mientras esto se lleva a cabo, la carga de trabajo y las operaciones existentes no se ven afectadas. El sistema sigue escalando la base de datos o el contenedor entre el valor anterior de 0,1 × Tmax y Tmax, hasta que esté listo el nuevo intervalo de escalado de 0,1 × Tmax_new a Tmax_new.

¿Cómo puedo reducir el número máximo de RU/s?

Al reducir el número máximo de RU/s, el valor mínimo que se puede establecer es MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10), redondeado a los 1000 RU/s más cercanos.

Ejemplo #1: Tiene un contenedor de escalabilidad automática que tiene un número máximo de 20 000 RU/s (escala entre 2000 RU/s y 20 000 RU/s) y 1500 GB de almacenamiento. El valor mínimo más bajo en el que puede establecer el número máximo de RU/s es MAX(1,000, 20,000 / 10, 1,500 × 10) = 15 000 RU/s (escala entre 1500 RU/s y 15 000 RU/s).

Ejemplo #2: Tiene un contenedor de escalabilidad automática que tiene un número máximo de RU/s de 100 000 RU/s y 100 GB de almacenamiento. Ahora, escale el número máximo de RU/s hasta 150 000 RU/s (escala entre 15 000 RU/s y 150 000 RU/s). El valor mínimo más bajo en el que ahora puede establecer el número máximo de RU/s es MAX(1,000, 150,000 / 10, 100 × 10) = 15 000 RU/s (escala entre 1500 RU/s y 15 000 RU/s).

En el caso de una base de datos de rendimiento compartido, al reducir el número máximo de RU/s, el valor mínimo que se puede establecer es MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000)), redondeado a los 1000 RU/s más cercanos.

Estas fórmulas y ejemplos se aplican al valor mínimo del número máximo de RU/s de escalabilidad automática que puede establecer. Son independientes del rango 0,1 × Tmax a Tmax al que el sistema se escala automáticamente. Independientemente del número máximo de RU/s, el sistema siempre escala entre 0,1 × Tmax y Tmax.

¿Cómo funciona TTL con la escalabilidad automática?

Las operaciones de período de vida (TTL) no afectan al escalado de RU/s en escalabilidad automática. Las RU consumidas debido a TTL no forman parte de las RU/s facturadas del contenedor con escalabilidad automática.

Por ejemplo, para un contenedor de escalabilidad automática con 400 RU/s a 4000 RU/s:

  • Hora 1: T=0: el contenedor no tiene uso (sin solicitudes de TTL ni de la carga de trabajo). Las RU/s facturables son 400 RU/s.
  • Hora 1: T=1: TTL está habilitado.
  • Hora 1: T=2: el contenedor comienza a obtener solicitudes. Las solicitudes consumen 1000 RU en 1 segundo. Se usan 200 RU de TTL. Las RU/s facturables siguen siendo 1000 RU/s. Independientemente del momento en que se produzcan las eliminaciones de TTL, no afectan la lógica de la escalabilidad automática.

¿Cómo se asigna el número máximo de RU/s a las particiones físicas?

Al seleccionar por primera vez el número máximo de RU/s, Azure Cosmos DB aprovisiona dividiendo el número máximo de RU/s por 10 000 RU/s para obtener el número de particiones físicas necesarias. Cada partición física puede admitir hasta 10 000 RU/s y un almacenamiento de 50 GB. A medida que aumenta el tamaño del almacenamiento, Azure Cosmos DB divide automáticamente las particiones para agregar más particiones físicas con el fin de controlar el aumento del almacenamiento. Si el almacenamiento supera el límite asociado, Azure Cosmos DB aumenta el número máximo de RU/s.

El número máximo de RU/s de la base de datos o el contenedor se dividen uniformemente entre todas las particiones físicas. El rendimiento total al que se puede escalar cualquier partición física única es el número máximo de RU/s de la base de datos o contenedor dividido por el número de particiones físicas.

¿Qué ocurre si las solicitudes entrantes superan el máximo de RU/s de la base de datos o el contenedor?

Si el total de RU/s consumidas supera el número máximo de RU/s del contenedor o la base de datos, las solicitudes que superen el número máximo de RU/s se limitarán y devolverán un código de estado 429. Las solicitudes que dan lugar a más del 100 % de uso normalizado se limitan. La utilización normalizada se define como el máximo del uso de las RU/s en todas las particiones físicas.

Por ejemplo, el rendimiento máximo son 20 000 RU/s y tiene dos particiones físicas, P_1 y P_2. Cada partición es capaz de escalar a 10 000 RU/s. En un segundo determinado, si P_1 ha usado 6000 RU y P_2 ha usado 8000 RU, la utilización normalizada es MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) = 0,8.

Nota

Los SDK de cliente de Azure Cosmos DB y las herramientas de importación de datos (Azure Data Factory, la biblioteca Bulk Executor) vuelven a intentarlo automáticamente después de que se devuelva un error de código 429, por lo que los errores de código 429 ocasionales no son problemáticos. Un gran número sostenido de errores de código 429 puede indicar que necesita aumentar el número máximo de RU/s o revisar la estrategia de partición para que incluya una partición de nivel de acceso frecuente.

¿Se pueden producir errores de limitación o limitación de frecuencia cuando la escalabilidad automática está habilitada?

Sí. Los errores de código 429 se pueden ver en dos escenarios.

En primer lugar, cuando el total de las RU/s consumidas supera el número máximo de RU/s del contenedor o la base de datos, el servicio limita las solicitudes en consecuencia.

En segundo lugar, si un valor de clave de partición lógica que tiene una cantidad de solicitudes desproporcionada en comparación con otros valores de la clave de partición (como en una partición de nivel de acceso frecuente), puede que la partición física subyacente supere el presupuesto de las RU/s. Como procedimiento recomendado, para evitar las particiones frecuentes, elija una buena clave de partición que dé lugar a una distribución uniforme tanto del almacenamiento como del rendimiento.

Por ejemplo, si selecciona la opción de rendimiento máximo de 20 000 RU/s y tiene 200 GB de almacenamiento, si tiene cuatro particiones físicas, cada partición física se puede escalar automáticamente hasta 5000 RU/s. Si una partición activa está en una clave de partición lógica específica, verá errores de código 429 cuando la partición física subyacente en la que reside supere los 5000 RU/s o el uso normalizado del 100 %.

Ver errores de código 429 cuando se usa la escalabilidad automática no indica necesariamente un problema con la base de datos o el contenedor. Por lo general, para una carga de trabajo de producción, si entre el 1 % y el 5 % de las solicitudes tienen errores de código 429 y la latencia de un extremo a otro es aceptable, los errores son un signo correcto de que las RU/s se están utilizando por completo. No se requiere ninguna acción.

Aprenda cómo interpretar y depurar errores de limitación de frecuencia de código 429.

¿El consumo normalizado de RU/s puede ser del 100 % si la escalabilidad automática no se escala al número máximo de RU/s?

Sí. Para obtener más información, consulte Supervisión de RU/s normalizadas.