Procedimientos recomendados para escalar el rendimiento aprovisionado

En este artículo se describen los procedimientos recomendados y las estrategias para escalar el rendimiento de la base de datos o contenedor (colección, tabla o grafo). Estos conceptos se aplican cuando se aumenta las unidades de solicitud manuales aprovisionadas por segundo (RU/s) o el valor máximo de RU/s de escalado automático de cualquier recurso para cualquiera de las API de Azure Cosmos DB.

Prerrequisitos

• Si no está familiarizado con la creación de particiones y el escalado en Azure Cosmos DB, consulte Creación de particiones y escalado horizontal en Azure Cosmos DB.
• Si planea escalar las RU/s debido a 429 excepciones, revise las instrucciones de Diagnóstico y solución de problemas de excepciones de "Tasa de solicitudes demasiado grande" (429). Antes de aumentar las RU/s, identifique la causa principal del problema y confirme si el aumento de las RU/s es la solución adecuada.

Información general sobre el escalado de las RU/s

Cuando envía una solicitud para aumentar las RU/s de su base de datos o contenedor, dependiendo de las RU/s solicitadas y el diseño actual de la partición física, la operación de escalado se completa de forma instantánea o asincrónica (normalmente entre 4 y 6 horas).

• Escalado vertical instantáneo:

  • Cuando las RU/s solicitadas pueden ser compatibles con el diseño de partición física actual, Azure Cosmos DB no necesita dividir ni agregar nuevas particiones.
  • Como resultado, la operación se completa inmediatamente y las RU/s están disponibles para su uso.

• Escalado vertical asincrónico:

  • Cuando las RU/s solicitadas son superiores a las que puede admitir el diseño de partición física, Azure Cosmos DB divide las particiones físicas existentes. Esto sucede hasta que el recurso tiene el número mínimo de particiones necesarias para admitir las RU/s solicitadas.
  • Como resultado, la operación puede tardar algún tiempo en completarse, normalmente de 4 a 6 horas. Cada partición física puede admitir un máximo de 10 000 RU/s (se aplica a todas las API) de rendimiento y 50 GB de almacenamiento (se aplica a todas las API, excepto Cassandra, que tiene 30 GB de almacenamiento).

  Nota:

  Si realiza una operación de región de escritura de cambios o agrega o quita una nueva región mientras una operación de escalado vertical asincrónica está en curso, la operación de escalado vertical del rendimiento se pausa. Se reanuda automáticamente cuando se completa la operación de conmutación por error o agregar o quitar región.

• Escalado hacia abajo instantáneo:

  • Para la operación de reducción vertical, Azure Cosmos DB no necesita dividir ni agregar nuevas particiones.
  • Como resultado, la operación se completa inmediatamente y las RU/s están disponibles para su uso.
  • El resultado clave de esta operación es que se reducen las RU por partición física.

Escalado vertical de las RU/s sin cambiar el diseño de la partición

Paso 1: Buscar el número actual de particiones físicas

Vaya a Información>Rendimiento>Normalized RU Consumption (%) By PartitionKeyRangeID [Consumo de RU normalizado (%) por PartitionKeyRangeID]. Cuente el número distinto de PartitionKeyRangeIds.

Cada PartitionKeyRangeId se asigna a una partición física y se asigna para contener datos para un intervalo de valores hash posibles.

Azure Cosmos DB distribuye los datos entre particiones lógicas y físicas en función de la clave de partición para habilitar el escalado horizontal. A medida que se escriben los datos, Azure Cosmos DB usa el hash del valor de la clave de partición para determinar en qué partición lógica y física se encuentran los datos.

Paso 2: Calcular el rendimiento máximo predeterminado

Las mayor cantidad de RU/s a la que se puede escalar sin provocar que Azure Cosmos DB divida las particiones es igual a Current number of physical partitions * 10,000 RU/s.

Puede obtener este valor del proveedor de recursos de Azure Cosmos DB. Realice una solicitud GET en los objetos de configuración de rendimiento base de datos o contenedor y recupere la propiedad instantMaximumThroughput. Este valor también está disponible en la página Escala y configuración de la base de datos o contenedor en el portal.

Ejemplo

Supongamos que tiene un contenedor existente con cinco particiones físicas y 30.000 RU/s de rendimiento aprovisionado de forma manual. Puede aumentar las RU/s de 5 * 10,000 RU/s = 50,000 RU/s forma instantánea. Del mismo modo, si hubo un contenedor con una escalabilidad automática máxima de las RU/s de 30 000 RU/s (escala entre 3000 y 30 000 RU/s), podríamos aumentar el número máximo de RU/s a 50 000 RU/s al instante (escala entre 5000 y 50 000 RU/s).

Cómo garantizar la distribución uniforme de datos durante el escalado asincrónico

Información previa

Al aumentar las RU/s más allá del número actual de physical partitions * 10,000 RU/s, Azure Cosmos DB divide las particiones existentes hasta el nuevo número de particiones = ROUNDUP(requested RU/s / 10,000 RU/s). Durante una división, las particiones primarias se dividen en dos particiones secundarias.

Por ejemplo, supongamos que tiene un contenedor con tres particiones físicas y 30 000 RU/s de rendimiento provisionado manualmente. Si aumenta el rendimiento a 45 000 RU/s, Azure Cosmos DB divide dos de las particiones físicas existentes para que, en total, haya ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 physical partitions.

Si tiene una carga de trabajo distribuida uniformemente con respecto al almacenamiento y volumen de solicitudes, normalmente se logra mediante la creación de particiones por campos de cardinalidad alta, como /id, se recomienda establecer RU/s de forma que todas las particiones se dividan uniformemente cuando realice un escalado.

Para ver por qué, veamos un ejemplo en el que tiene un contenedor existente con dos particiones físicas, 20 000 RU/s y 80 GB de datos.

Gracias a la elección de una buena clave de partición con una cardinalidad alta, los datos se distribuyen más o menos uniformemente en ambas particiones físicas. A cada partición física se le asigna aproximadamente el 50 % del espacio de claves, que se define como el intervalo total de valores hash posibles.

Además, Azure Cosmos DB distribuye las RU/s uniformemente entre todas las particiones físicas. Como resultado, cada partición física tiene 10 000 RU/s y el 50 % (40 GB) de los datos totales. En el diagrama siguiente se muestra nuestro estado actual.

Supongamos que quieres aumentar nuestras RU/s de 20 000 RU/s a 30 000 RU/s.

Si simplemente aumentas las RU/s a 30,000 RU/s, solo se divide una de las particiones. Después de la división, te quedas con:

• Una partición que contiene 50% de los datos (esta partición no se ha dividido).
• Dos particiones que contienen el 25% de los datos cada una (son particiones secundarias resultantes de la partición primaria que se ha dividido).

Dado que Azure Cosmos DB distribuye RU/s uniformemente entre todas las particiones físicas, cada partición física sigue recibiendo 10 000 RU/s. Sin embargo, ahora tiene un sesgo en el almacenamiento y en la distribución de solicitudes.

En el diagrama siguiente, las particiones 3 y 4 (las particiones secundarias de la partición 2) cada una tienen 10 000 RU/s para atender solicitudes de 20 GB de datos, mientras que la partición 1 tiene 10 000 RU/s para atender solicitudes por dos veces la cantidad de datos (40 GB).

Para mantener una distribución de almacenamiento uniforme, primero puede aumentar sus RU/s para asegurar que cada partición se divida. A continuación, puede reducir las RU/s hasta el estado deseado.

Por lo tanto, si empieza con dos particiones físicas, para garantizar que las particiones sean iguales después de la división, debe establecer RU/s de manera que termine con cuatro particiones físicas. Para lograrlo, establezca RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/s primero. Después de completar la división, reduzca las RU/s a 30 000 RU/s.

Como resultado, cada partición física obtiene 30,000 RU/s / 4 = 7500 RU/s para atender solicitudes de 20 GB de datos. En general, mantienes una distribución uniforme de almacenamiento y solicitudes entre las particiones.

Fórmula general

Paso 1: Aumentar las RU/s para garantizar que todas las particiones se dividen uniformemente

En general, si tiene un número inicial de particiones físicas Py desea establecer una RU/s deseadaS:

Aumente la RU/s hasta 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Esto proporciona las RU/s más cercanas al valor deseado que garantiza que todas las particiones se dividan uniformemente.

Paso 2: Reducir las RU/s a las RU/s deseadas

Por ejemplo, supongamos que tenemos cinco particiones físicas y 50 000 RU/s y queremos escalar a 150 000 RU/s. Primero deberíamos establecer: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200,000 RU/sy, a continuación, reducir a 150 000 RU/s.

Cuando escalamos verticalmente hasta 200 000 RU/s, las RU/s manuales más bajas que podemos establecer en el futuro son 2000 RU/s. El valor más bajo de RU/s máximas de escalabilidad automática que se puede establecer es de 20 000 RU/s (escala entre 2000 y 20 000 RU/s). Puesto que nuestras RU/s de destino son 150 000 RU/s, no nos vemos afectados por las RU/s mínimas.

Optimización de RU/s para la ingesta de datos de gran tamaño

Cuando se planea migrar o ingerir una gran cantidad de datos en Azure Cosmos DB, se recomienda establecer las RU/s del contenedor de forma que Azure Cosmos DB aprovisione previamente las particiones físicas necesarias para almacenar la cantidad total de datos que se planea ingerir por adelantado. De lo contrario, durante la ingesta, Azure Cosmos DB podría tener que dividir particiones, lo que agrega más tiempo a la ingesta de datos.

Podemos aprovechar el hecho de que, durante la creación del contenedor, Azure Cosmos DB usa la fórmula heurística de iniciar RU/s para calcular el número de particiones físicas con las que empezar.

Paso 1: Revisar la elección de la clave de partición

Siga los procedimientos recomendados para elegir una clave de partición y garantizar una distribución equilibrada del volumen de solicitudes y el almacenamiento después de la migración.

Paso 2: Calcular el número de particiones físicas que necesita

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Cada partición física puede contener un máximo de 50 GB de almacenamiento (30 GB para la API de Cassandra). El valor que debe elegir para los datos de destino por partición física en GB depende de cuán llenas desea que estén las particiones físicas y de cuánto espera que el almacenamiento crezca después de la migración.

Por ejemplo, si prevé que el almacenamiento seguirá creciendo, puede optar por establecer el valor en 30 GB. Suponiendo que eligió una buena clave de partición que distribuye uniformemente el almacenamiento, cada partición es ~60% completa (30 GB de 50 GB). A medida que se escriben los datos futuros, se pueden almacenar en el conjunto existente de particiones físicas, sin necesidad de que el servicio agregue inmediatamente más particiones físicas.

Por el contrario, si cree que el almacenamiento no aumentará significativamente después de la migración, podría optar por establecer el valor más alto, por ejemplo, 45 GB. Esto significa que cada partición es ~90% completa (45 GB de 50 GB). Esto minimiza el número de particiones físicas entre las que se reparten los datos, lo que significa que cada partición física puede obtener una fracción mayor del total de RU/s aprovisionadas.

Paso 3: Calcular el número de RU/s con las que empezar para todas las particiones

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition

Comencemos con un ejemplo con un número arbitrario de RU/s de destino por partición física.

• Initial throughput per physical partition = 10,000 RU/s per physical partition cuando se usan bases de datos de rendimiento compartido o escalado automático
• Initial throughput per physical partition = 6000 RU/s per physical partition cuando se usa el rendimiento manual

Ejemplo

Supongamos que tiene 1 TB (1000 GB) de datos para procesar y desea usar el rendimiento manual. Cada partición física de Azure Cosmos DB tiene una capacidad de 50 GB. Supongamos que pretende empaquetar particiones para que sean 80% completas (40 GB), dejando espacio para el crecimiento futuro.

Esto significa que para 1 TB de datos, necesita 1000 GB / 40 GB = 25 particiones físicas. Para asegurarse de obtener 25 particiones físicas, primero use el rendimiento manual y aprovisione 25 * 6000 RU/s = 150,000 RU/s. Después de crear el contenedor, para ayudar a la ingesta a ir más rápido, aumente las RU/s a 250 000 RU/s antes de que comience la ingesta (se produce al instante porque ya tiene 25 particiones físicas). Esto permite que cada partición obtenga un máximo de 10 000 RU/s.

Si usas el rendimiento de escalabilidad automática o una base de datos de rendimiento compartido, para obtener 25 particiones físicas, primero aprovisionarías 25 * 10,000 RU/s = 250,000 RU/s. Dado que ya está en las RU/s más altas que se pueden admitir con 25 particiones físicas, no aumentaría aún más nuestras RU/s aprovisionadas antes de la ingesta.

En teoría, con 250 000 RU/s y 1 TB de datos, si se asumen documentos de 1 kb y 10 RU necesarias para escritura, la ingesta puede completarse teóricamente en: 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours.

Este cálculo es una estimación suponiendo que el cliente que realiza la ingesta puede saturar completamente el rendimiento y distribuir las escrituras entre todas las particiones físicas. Como procedimiento recomendado, se recomienda realizar un orden aleatorio de los datos en el lado cliente. Esto garantiza que cada segundo, el cliente escribe en muchas particiones lógicas distintas (y, por tanto, físicas).

Una vez finalizada la migración, puede reducir las RU/s o habilitar la escalabilidad automática según sea necesario.

Pasos siguientes

• Cómo supervisar las RU/s normalizadas para un contenedor o una cuenta de Azure Cosmos DB
• Diagnóstico y solución de problemas de excepciones de "tasa de solicitud demasiado grande" (429)
• Creación de contenedores y bases de datos de Azure Cosmos DB con rendimiento de escalabilidad automática