Compartir a través de

Redistribución del rendimiento entre particiones (versión preliminar)

SE APLICA A: NoSQL MongoDB

De forma predeterminada, Azure Cosmos DB distribuye el rendimiento aprovisionado de una base de datos o contenedor por igual en todas las particiones físicas. Sin embargo, pueden surgir escenarios en los que, debido a un sesgo en la carga de trabajo o la elección de la clave de partición, ciertas particiones lógicas (y, por tanto, físicas) necesitan más rendimiento que otros. En estos escenarios, Azure Cosmos DB ofrece la capacidad de redistribuir el rendimiento aprovisionado entre particiones físicas. Redistribuir el rendimiento entre particiones le permite obtener un rendimiento mejor sin tener que configurar el rendimiento general en función de la partición más activa.

La característica para redistribuir el rendimiento se aplica a bases de datos y contenedores mediante el rendimiento aprovisionado (escalado manual y automático) y no se aplica a contenedores sin servidor. Puede cambiar el rendimiento por partición física con los comandos de PowerShell de Azure Cosmos DB o de la CLI de Azure.

Cuándo usar esta característica

En general, se recomienda el uso de esta característica en escenarios en los que se cumplen las dos condiciones siguientes:

  • Está viendo constantemente una tasa general superior al 1-5 % de 429 respuestas
  • Si tiene una partición activa coherente y predecible.

Si no ve 429 respuestas y la latencia de un extremo a otro es aceptable, no se requiere ninguna acción para volver a configurar las RU/s por partición. Si tiene una carga de trabajo que tiene tráfico coherente con picos impredecibles ocasionales en todas las particiones, se recomienda usar la escalabilidad automática y la capacidad de ráfaga (versión preliminar). La capacidad de escalabilidad automática y de ráfaga garantizará que pueda cumplir los requisitos de rendimiento. Si tiene una pequeña cantidad de RU/s por partición, también puede usar la combinación de particiones (versión preliminar) para reducir el número de particiones y garantizar más RU/s por partición para el mismo rendimiento aprovisionado total.

Escenario de ejemplo

Supongamos que tiene una carga de trabajo que realiza un seguimiento de las transacciones que tienen lugar en las tiendas minoristas. Dado que la mayoría de nuestras consultas se hacen mediante StoreId, particionamos según StoreId. Sin embargo, con el tiempo vemos que algunos almacenes tienen más actividad que otros y requieren más rendimiento para atender sus cargas de trabajo. Estamos viendo la limitación de velocidad (429) para las solicitudes en esos StoreIds, y nuestra tasa global de 429 respuestas es mayor que un 1-5 %. Mientras tanto, otros almacenes son menos activos y requieren menos rendimiento. Veamos cómo puede redistribuir el rendimiento para mejorarlo.

Paso 1: Identifique qué particiones físicas necesitan más rendimiento

Hay dos maneras de identificar si hay una partición activa.

Opción 1: Uso de métricas de Azure Monitor

Para comprobar si hay una partición de nivel de acceso frecuente, vaya a Insights>Rendimiento>Consumo de RU normalizado (%) por PartitionKeyRangeID. Filtre por una base de datos y un contenedor específicos.

Cada objeto PartitionKeyRangeId se asigna a una partición física. Busque un PartitionKeyRangeId que tenga constantemente un consumo de RU normalizado mayor que otros. Por ejemplo, un valor es coherente en un 100 %, pero otros tienen un 30 % o menos. Un patrón como este puede indicar una partición activa.

Captura de pantalla del gráfico del consumo de RU normalizado por PartitionKeyRangeId con una partición caliente.

Opción 2: Uso de registros de diagnóstico

Puede usar la información de CDBPartitionKeyRUConsumption en registros de diagnóstico para obtener más información sobre las claves de partición lógicas (y las particiones físicas correspondientes) que consumen la mayoría de las RU/s en una granularidad de segundo nivel. Tenga en cuenta que las consultas de ejemplo usan solo 24 horas para fines ilustrativos; se recomienda usar al menos siete días del historial para comprender el patrón.

Busque la partición física (PartitionKeyRangeId) que consume más RU/s a lo largo del tiempo.

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hr)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| summarize sum(RequestCharge) by bin(TimeGenerated, 1s), PartitionKeyRangeId
| render timechart

Para una partición física determinada, busque las 10 claves de partición lógica principales que consumen más RU/s en cada hora.

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hour)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| where PartitionKeyRangeId == 0 // Replace with PartitionKeyRangeId 
| summarize sum(RequestCharge) by bin(TimeGenerated, 1hour), PartitionKey
| order by sum_RequestCharge desc | take 10

Paso 2: Determine las RU/s de destino de cada partición física

Determine las RU/s de destino de cada partición física.

En primer lugar, vamos a determinar las RU/s actuales para cada partición física. Puede usar la métrica de Azure Monitor PhysicalPartitionThroughput y dividirla por la dimensión PhysicalPartitionId para ver cuántas RU/s tiene por partición física.

Como alternativa, si no ha cambiado el rendimiento por partición antes, puede usar la fórmula : Current RU/s per partition = Total RU/s / Number of physical partitions.

Siga las instrucciones del artículo Procedimientos recomendados para escalar el rendimiento aprovisionado (RU/s) para determinar el número de particiones físicas.

También puede usar los comandos de PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput y Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput para leer las RU/s actuales en cada partición física.

Use Install-Module para instalar el módulo Az.CosmosDB con las características de versión preliminar habilitadas.

$parameters = @{
    Name = "Az.CosmosDB"
    AllowPrerelease = $true
    Force = $true
}
Install-Module @parameters

Use el comando Get-AzCosmosDBSqlContainerPerPartitionThroughput o Get-AzCosmosDBSqlDatabasePerPartitionThroughput para leer las RU/s actuales en cada partición física.


// Container with dedicated RU/s
$somePartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -AllPartitions

// Database with shared RU/s
$somePartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -AllPartitions

Determinación de RU/s para la partición de destino

A continuación, decida cuántas RU/s quiere dar a las particiones físicas más activas. Vamos a llamar a este conjunto de particiones de destino. El máximo de RU/s que puede contener cualquier partición física es de 10 000 RU/s.

La opción más adecuada depende de los requisitos de la carga de trabajo. Los enfoques generales incluyen:

  • Aumentar las RU/s según un porcentaje, medir la tasa de 429 respuestas y repetir hasta que se alcanza el rendimiento deseado.
    • Si no está seguro del porcentaje correcto, puede empezar con el 10 % para tener mayor seguridad.
    • Si ya sabe que esta partición física requiere la mayor parte del rendimiento de la carga de trabajo, puede empezar por duplicar las RU/s o aumentarla al máximo de 10 000 RU/s, lo que sea menor.
  • Aumentar las RU/s a Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Este enfoque intenta calcular lo que habría sido el consumo de RU/s "real" si las solicitudes no hubieran sido limitadas según la velocidad.

Determinación de RU/s para la partición de origen

Por último, vamos a decidir cuántas RU/s queremos mantener en nuestras otras particiones físicas. Esta selección determinará las particiones de las que la partición física de destino toma el rendimiento.

En las API de PowerShell, debemos especificar al menos una partición de origen desde la cual redistribuir las RU/s. Tambien podemos especificar un rendimiento mínimo personalizado que cada partición física debe tener después de la redistribución. Si no se especifica, Azure Cosmos DB garantizará de forma predeterminada que cada partición física tenga al menos 100 RU/s después de la redistribución. Se recomienda especificar de forma explícita el rendimiento mínimo.

La opción más adecuada depende de los requisitos de la carga de trabajo. Los enfoques generales incluyen:

  • Tomar cantidades iguales de RU/s de todas las particiones de origen (funciona mejor cuando <= 10 particiones).
    • Calcule la cantidad que necesitamos para compensar cada partición física de origen. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Asignar el rendimiento mínimo para cada partición de origen = Current RU/s of source partition - offset.
  • Tomar RU/s de las particiones menos activas
    • Uso de métricas y registros de diagnóstico de Azure Monitor para determinar qué particiones físicas tienen el menor tráfico o volumen de solicitudes
    • Calcule la cantidad por la que necesitamos compensar cada partición física de origen. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Asignar el rendimiento mínimo para cada partición de origen = Current RU/s of source partition - offset.

Paso 3: Cambie mediante programación el rendimiento entre particiones

Puede usar el comando Update-AzCosmosDBSqlContainerPerPartitionThroughput de PowerShell para redistribuir el rendimiento.

Para comprender el ejemplo siguiente, tomemos un ejemplo en el que tenemos un contenedor que tiene un total de 6000 RU/s (6000 RU/s manuales o escalabilidad automática de 6000 RU/s) y 3 particiones físicas. Según nuestro análisis, queremos un diseño en el que:

  • Partición física 0: 1000 RU/s
  • Partición física 1: 4000 RU/s
  • Partición física 2: 1000 RU/s

Especificamos las particiones 0 y 2 como particiones de origen y especificamos que después de la redistribución, deben tener un mínimo de RU/s de 1000 RU/s. La partición 1 está fuera de la partición de destino, que se debe especificar debe tener 4000 RU/s.

Use el comando Update-AzCosmosDBSqlContainerPerPartitionThroughput para contenedores con RU/s dedicados o el Update-AzCosmosDBSqlDatabasePerPartitionThroughput para las bases de datos con RU/s compartidos para redistribuir el rendimiento entre particiones físicas. En las bases de datos de rendimiento compartido, los identificadores de las particiones físicas se representan mediante una cadena GUID.

$SourcePhysicalPartitionObjects =  @()
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "0" -Throughput 1000
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "2" -Throughput 1000

$TargetPhysicalPartitionObjects =  @()
$TargetPhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "1" -Throughput 4000

// Container with dedicated RU/s
Update-AzCosmosDBSqlContainerPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-container-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

// Database with shared RU/s
Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

Una vez completada la redistribución, puede comprobar el cambio si consulta la métrica PhysicalPartitionThroughput en Azure Monitor. Divida por la dimensión PhysicalPartitionId para ver cuántas RU/s tiene por partición física.

Si es necesario, también puede restablecer las RU/s por partición física para que las RU/s del contenedor se distribuyan uniformemente entre todas las particiones físicas.

Use el comando Update-AzCosmosDBSqlContainerPerPartitionThroughput para contenedores con RU/s dedicados o el Update-AzCosmosDBSqlDatabasePerPartitionThroughput para bases de datos con RU/s compartidos con parámetro -EqualDistributionPolicy para distribuir RU/s uniformemente entre todas las particiones físicas.


// Container with dedicated RU/s
$resetPartitionsDedicatedRUContainer = Update-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -EqualDistributionPolicy

// Database with dedicated RU/s
$resetPartitionsSharedThroughputDatabase = Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -EqualDistributionPolicy

Paso 4: Compruebe y supervise el consumo de RU/s

Una vez completada la redistribución, puede comprobar el cambio si consulta la métrica PhysicalPartitionThroughput en Azure Monitor. Divida por la dimensión PhysicalPartitionId para ver cuántas RU/s tiene por partición física.

Se recomienda supervisar la tasa general de 429 respuestas y el consumo de RU/s. Para obtener más información, revise el paso 1 para comprobar que ha logrado el rendimiento esperado.

Después de los cambios, suponiendo que la carga de trabajo general no haya cambiado, es probable que vea que tanto el destino como las particiones físicas de origen tienen un mayor consumo de RU normalizado que antes. Se espera un mayor consumo de RU normalizado. Básicamente, ha asignado más RU/s de lo que realmente necesita consumir cada partición, por lo que un mayor consumo normalizado de RU significa que cada partición está utilizando completamente sus RU/s asignadas. También debería esperar ver una tasa general inferior de 429 excepciones, ya que las particiones activas ahora tienen más RU/s para atender solicitudes.

Limitaciones

Criterios de elegibilidad para la versión preliminar

Para usar la versión preliminar, la cuenta de Azure Cosmos DB debe cumplir todos los criterios siguientes:

  • La cuenta de Azure Cosmos DB usa la API para NoSQL o para MongoDB.
    • Si usa la API para MongoDB, la versión debe ser >= 3.6.
  • La cuenta de Azure Cosmos DB usa el rendimiento aprovisionado (escalado manual o automático). La distribución del rendimiento entre particiones no se aplica a las cuentas sin servidor.

No es necesario registrarse para usar la versión preliminar. Para usar la característica, use los comandos de PowerShell o la CLI de Azure para redistribuir el rendimiento entre las particiones físicas de los recursos.

Pasos siguientes

Obtenga información sobre cómo usar el rendimiento aprovisionado con los artículos siguientes: