Redistribuir taxa de transferência entre partições (versão prévia)
APLICA-SE AO: NoSQL MongoDB
Por padrão, o Azure Cosmos DB distribui a taxa de transferência provisionada de um banco de dados ou contêiner igualmente em todas as partições físicas. No entanto, cenários podem surgir em que devido a uma distorção na carga de trabalho ou escolha da chave de partição, determinadas partições lógicas (e, portanto, físicas) precisam de mais taxa de transferência do que outras. Para esses cenários, o Azure Cosmos DB oferece a capacidade de redistribuir sua taxa de transferência provisionada entre partições físicas. Redistribuir a taxa de transferência entre partições ajuda você a obter um melhor desempenho sem precisar configurar sua taxa de transferência geral com base na partição mais quente.
O recurso de redistribuição de taxa de transferência se aplica a bancos de dados e contêineres usando a taxa de transferência provisionada (dimensionamento manual e automático) e não se aplica a contêineres sem servidor. Você pode alterar a taxa de transferência por partição física usando os comandos do PowerShell ou da CLI do Azure do Azure Cosmos DB.
Quando usar esse recurso
Em geral, o uso desse recurso é recomendado para cenários quando ambos são verdadeiros:
- Você está consistentemente vendo uma taxa geral de 1 a 5% de 429 respostas
- Você tem uma partição quente consistente e previsível
Se você não estiver vendo 429 respostas e sua latência de ponta a ponta for aceitável, nenhuma ação para reconfigurar RU/s por partição será necessária. Se você tiver uma carga de trabalho que tenha tráfego consistente com picos imprevisíveis ocasionais em todas as partições, será recomendável usar o dimensionamento automático e a capacidade de intermitência (versão prévia). O dimensionamento automático e a capacidade de intermitência garantirão que você possa atender aos seus requisitos de taxa de transferência. Se você tiver uma pequena quantidade de RU/s por partição, também poderá usar a mesclagem de partição (versão prévia) para reduzir o número de partições e garantir mais RU/s por partição para a mesma taxa de transferência provisionada total.
Cenário de exemplo
Suponha que tenhamos uma carga de trabalho que acompanha as transações que ocorrem em lojas de varejo. Já que a maioria das nossas consultas são por StoreId
, particionamos por StoreId
. No entanto, ao longo do tempo, vemos que algumas lojas têm mais atividade do que outras e exigem mais taxa de transferência para atender às respectivas cargas de trabalho. Estamos vendo a limitação de taxa (429) para solicitações em relação a essas StoreIds, e nossa taxa geral de 429 respostas é maior que 1 a 5%. Enquanto isso, outras lojas são menos ativas e exigem uma taxa de transferência menor. Vamos ver como podemos redistribuir nossa taxa de transferência para aprimorar o desempenho.
Etapa 1: identificar quais partições físicas precisam de mais taxa de transferência
Há duas maneiras de identificar se há uma partição quente.
Opção 1: usar métricas do Azure Monitor
Para verificar se há uma partição em chamas, navegue até Insights>Taxa de Transferência>Consumo de RU Normalizado (%) Por PartitionKeyRangeID. Filtre para um banco de dados e contêiner específicos.
Cada PartitionKeyRangeId é mapeada para uma partição física. Procure um PartitionKeyRangeId que tenha um consumo de RU normalizado consistentemente maior do que outros. Por exemplo, um valor está consistentemente em 100%, mas outros estão em 30% ou menos. Um padrão como esse pode indicar uma partição quente.
Opção 2: usar logs de diagnóstico
Podemos usar as informações de CDBPartitionKeyRUConsumption nos Logs de Diagnóstico para obter mais informações sobre as chaves de partição lógica (e partições físicas correspondentes) que estão consumindo mais RU/s em uma granularidade de segundo nível. Observe que as consultas de exemplo usam 24 horas somente para fins ilustrativos. É recomendável usar pelo menos sete dias de histórico para entender o padrão.
Localize a partição física (PartitionKeyRangeId) que está consumindo mais RU/s ao longo do tempo
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 uma determinada partição física, localize as dez principais chaves de partição lógica que estão consumindo mais RU/s a 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
Etapa 2: determinar as RU/s de destino para cada partição física
Etapa 2: determinar as RU/s atuais para cada partição física
Primeiro, vamos determinar as RU/s atuais para cada partição física. Você pode usar a métrica PhysicalPartitionThroughput do Azure Monitor e dividir pela dimensão PhysicalPartitionId para ver quantas RU/s você tem por partição física.
Como alternativa, se você não tiver alterado sua taxa de transferência por partição anteriormente, poderá usar a fórmula: Current RU/s per partition = Total RU/s / Number of physical partitions
Siga as diretrizes no artigo Práticas recomendadas para dimensionar a taxa de transferência provisionada (RU/s) para determinar o número de partições físicas.
Você também pode usar o PowerShell e os comandos Get-AzCosmosDBSqlContainerPerPartitionThroughput
eGet-AzCosmosDBMongoDBCollectionPerPartitionThroughput
para ler as RU/s atuais em cada partição física.
Use Install-Module
para instalar o módulo Az.CosmosDB com recursos de pré-lançamento ativados.
$parameters = @{
Name = "Az.CosmosDB"
AllowPrerelease = $true
Force = $true
}
Install-Module @parameters
Use o comando Get-AzCosmosDBSqlContainerPerPartitionThroughput
ou Get-AzCosmosDBSqlDatabasePerPartitionThroughput
para ler as RU/s atuais em cada partição 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
Determinar RU/s para a partição de destino
Em seguida, vamos decidir quantas RU/s queremos dar às nossas partições físicas mais quentes. Vamos chamar isso de definir nossas partições de destino. A maior parte das RU/s que qualquer partição física pode conter é de 10.000 RU/s.
A abordagem correta depende de seus requisitos de carga de trabalho. As abordagens gerais incluem:
- Aumentar as RU/s por um percentual, medir a taxa de 429 respostas e repetir até que a taxa de transferência desejada seja alcançada.
- Se você não tiver certeza do percentual correto, poderá começar com 10% para ser conservador.
- Se você já souber que essa partição física exige a maior parte da taxa de transferência da carga de trabalho, você pode começar dobrando as RU/s ou aumentando-as para o máximo de 10.000 RU/s, o que for menor.
- Aumentar do máximo de RU/s para
Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
- Essa abordagem tenta estimar qual seria o consumo "real" de RU/s se as solicitações não tivessem sido limitadas por taxa.
Determinar RU/s para partição de origem
Por fim, vamos decidir quantas RU/s queremos manter em nossas outras partições físicas. Essa seleção determinará as partições das quais a partição física de destino recebe a taxa de transferência.
Nas APIs do PowerShell do Azure, devemos especificar pelo menos uma partição de origem para redistribuir RU/s. Também podemos especificar uma taxa de transferência mínima personalizada que cada partição física deve ter após a redistribuição. Se ela não for especificada, por padrão, o Azure Cosmos DB garantirá que cada partição física tenha pelo menos 100 RU/s após a redistribuição. É recomendável especificar explicitamente a taxa de transferência mínima.
A abordagem correta depende de seus requisitos de carga de trabalho. As abordagens gerais incluem:
- Usar o mesmo valor de RU/s de todas as partições de origem (funciona melhor quando há <= 10 partições)
- Calcular a quantidade necessária pela qual compensar cada partição física de origem.
Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
- Atribuir a taxa de transferência mínima para cada partição de origem =
Current RU/s of source partition - offset
- Calcular a quantidade necessária pela qual compensar cada partição física de origem.
- Usar RU/s das partições menos ativas
- Usar as métricas do Azure Monitor e os Logs de Diagnóstico para determinar quais partições físicas têm o menor volume de tráfego/solicitação
- Calcular a quantidade necessária pela qual compensar cada partição física de origem.
Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
- Atribuir a taxa de transferência mínima para cada partição de origem =
Current RU/s of source partition - offset
Etapa 3: alterar programaticamente a taxa de transferência entre partições
Você pode usar o comando Update-AzCosmosDBSqlContainerPerPartitionThroughput
do PowerShell para redistribuir a taxa de transferência.
Para entender o exemplo abaixo, vejamos um exemplo em que temos um contêiner com 6.000 RU/s no total (6.000 RU/s manuais ou dimensionamento automático de 6.000 RU/s) e três partições físicas. Com base em nossa análise, queremos um layout em que:
- Partição física 0: 1.000 RU/s
- Partição física 1: 4.000 RU/s
- Partição física 2: 1.000 RU/s
Especificamos as partições 0 e 2 como partições de origem e especificamos que, após a redistribuição, elas devem ter um mínimo de 1.000 RU/s. A partição 1 está fora da partição de destino, que especificamos que deve ter 4.000 RU/s.
Use o Update-AzCosmosDBSqlContainerPerPartitionThroughput
para contêineres com RU/s dedicada ou o comando Update-AzCosmosDBSqlDatabasePerPartitionThroughput
para bancos de dados com RU/s compartilhada para redistribuir a taxa de transferência entre partições físicas. Em bancos de dados com taxa de transferência compartilhada, as IDs das partições físicas são representadas por uma cadeia de caracteres de 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
Depois de concluir a redistribuição, você pode verificar a alteração exibindo a métrica PhysicalPartitionThroughput no Azure Monitor. Divida-a pela dimensão PhysicalPartitionId para ver quantas RU/s você tem por partição física.
Se necessário, você também pode redefinir as RU/s por partição física para que as RU/s do contêiner sejam distribuídas uniformemente em todas as partições físicas.
Use o comando Update-AzCosmosDBSqlContainerPerPartitionThroughput
para contêineres com RU/s dedicada ou o comando Update-AzCosmosDBSqlDatabasePerPartitionThroughput
, para bancos de dados com RU/s compartilhada, com o parâmetro -EqualDistributionPolicy
, a fim de distribuir as RU/s uniformemente em todas as partições 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
Etapa 4: verificar e monitorar o consumo de RU/s
Depois de concluir a redistribuição, você pode verificar a alteração exibindo a métrica PhysicalPartitionThroughput no Azure Monitor. Divida-a pela dimensão PhysicalPartitionId para ver quantas RU/s você tem por partição física.
É recomendável monitorar sua taxa geral de 429 respostas e consumo de RU/s. Para obter mais informações, examine a Etapa 1 para validar se você alcançou o desempenho esperado.
Após as alterações, supondo que sua carga de trabalho geral não tenha sido alterada, você provavelmente verá que as partições físicas de destino e de origem têm um consumo de RU normalizado mais alto do que anteriormente. O consumo normalizado mais alto de RU é o comportamento esperado. Essencialmente, você alocou um número de RU/s mais próximo do que cada partição realmente precisa consumir, portanto, um consumo de RU normalizado mais alto significa que cada partição está utilizando totalmente as respectivas RU/s alocadas. Você também deve esperar ver uma taxa geral mais baixa de 429 exceções, já que as partições quentes agora têm mais RU/s para atender às solicitações.
Limitações
Critérios de qualificação de versão prévia
Para usar a versão prévia, sua conta do Azure Cosmos DB deve atender a todos os seguintes critérios:
- Sua conta do Azure Cosmos DB está usando a API para NoSQL ou a API para MongoDB.
- Se você estiver usando a API para MongoDB, a versão deverá ser >= 3.6.
- Sua conta do Azure Cosmos DB está usando a taxa de transferência provisionada (dimensionamento automático ou manual). A distribuição da taxa de transferência entre partições não se aplica a contas sem servidor.
Você não precisa se inscrever para usar a versão prévia. Para utilizar o recurso, use os comandos do PowerShell ou da CLI do Azure para redistribuir a taxa de transferência entre as partições físicas de seus recursos.
Próximas etapas
Saiba mais sobre como usar a taxa de transferência provisionada com os seguintes artigos:
- Saiba mais sobre a taxa de transferência provisionada.
- Saiba mais sobre unidades de solicitação.
- Você precisa monitorar partições quentes? Confira unidades de solicitação de monitoramento.
- Deseja aprender as práticas recomendadas? Confira Práticas recomendadas para escalar a taxa de transferência provisionada.