Preguntas más frecuentes sobre la distribución del rendimiento entre particiones

  • Artículo

SE APLICA A: 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:

  • Observa constantemente una utilización normalizada del 100 % en algunas particiones de una colección.
  • Observa constantemente una latencia superior a la aceptada.

Si no ve un consumo del RU al 100 % y la latencia de un extremo a otro es aceptable, no se requiere realizar 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. 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 unidades de solicitud por partición, también puede usar la combinación de particiones para reducir el número de particiones y garantizar más RU 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 un consumo de RU normalizado del 100 % para las solicitudes en esos StoreIds. 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>Normalized RU Consumption (%) By PartitionKeyRangeID (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 elemento partitionKeyRangeId que tenga un mayor consumo de RU normalizado 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 de nivel de acceso frecuente.

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, 1m), 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.

Primero debe determinar la RU/s actual de 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 PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput y Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput comandos 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-AzCosmosDBMongoDBCollectionPerPartitionThroughput para leer las RU/s actuales en cada partición física.

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

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

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

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

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

A continuación, debemos decidir cuántas RU/s queremos dar a las particiones físicas más activas. Llame 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 en un 10 % y repetir hasta que se logre 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.

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

Por último, decida cuántas RU/s quiere mantener en las 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, es necesario especificar al menos una partición de origen para 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 por la que necesita desplazar 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 necesita desplazar 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, puede ver un ejemplo en el que tiene un contenedor con un total de 6000 RU/s (6000 RU/s manuales o de escalado automático) y 3 particiones físicas. En función del análisis, quiere 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

Se han especificado las particiones 0 y 2 como particiones de origen y, después de la redistribución, recuerde que deben tener un mínimo de 1000 RU/s. La partición 1 está fuera de la partición de destino (recuerde que especificó que debe tener 4000 RU/s).

Use el comando Update-AzCosmosDBMongoDBCollectionPerPartitionThroughput para colecciones con RU/s dedicadas o el Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput para las bases de datos con RU/s compartidas 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

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

// Database with shared RU/s
Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput `
    -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-AzCosmosDBMongoDBCollectionPerPartitionThroughput para colecciones con RU/s dedicados o el Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput para bases de datos con RU/s compartidos con parámetro -EqualDistributionPolicy para distribuir RU/s uniformemente en todas las particiones físicas.

// Collection with dedicated RU/s
Update-AzCosmosDBMongoDBCollectionPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-collection-name>" `
    -EqualDistributionPolicy

// Database with shared RU/s
Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput `
    -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 el consumo normalizado de RU por partición. 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. Recuerde que se espera obtener 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 debe 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 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: