Partager via


Redistribuer le débit entre les partitions (préversion)

S’APPLIQUE À : NoSQL MongoDB

Par défaut, Azure Cosmos DB distribue le débit approvisionné d’une base de données ou d’un conteneur de manière égale sur toutes les partitions physiques. Toutefois, les scénarios peuvent survenir lorsque, en raison d’une asymétrie dans la charge de travail ou du choix de la clé de partition, certaines partitions logiques (et donc physiques) nécessitent plus de débit que d’autres. Pour ces scénarios, Azure Cosmos DB vous donne la possibilité de redistribuer votre débit provisionné sur des partitions physiques. La redistribution du débit entre les partitions vous permet d’obtenir de meilleures performances sans avoir à configurer votre débit global en fonction de la partition la plus chaude.

La fonctionnalité de redistribution du débit s’applique aux bases de données et aux conteneurs à l’aide du débit configuré (mise à l’échelle manuelle et automatique) et ne s’applique pas aux conteneurs serverless. Vous pouvez modifier le débit par partition physique à l’aide des commandes Azure Cosmos DB PowerShell ou Azure CLI.

Quand utiliser cette fonctionnalité

En général, l’utilisation de cette fonctionnalité est recommandée pour les scénarios où les deux conditions suivantes sont vraies :

  • Vous voyez constamment un taux global supérieur à 1 à 5 % de réponses 429
  • Vous avez une partition à chaud cohérente et prévisible

Si vous ne voyez pas de réponses 429 et que votre latence de bout en bout est acceptable, aucune action de reconfiguration des RU/s par partition n’est requise. Si vous disposez d’une charge de travail qui a un trafic cohérent avec des pics imprévisibles occasionnels sur toutes vos partitions, il est recommandé d’utiliser la mise à l’échelle automatique et la fonctionnalité de rafale (préversion). La capacité de mise à l’échelle automatique et de rafale vous permet de répondre à vos besoins en matière de débit. Si vous avez une petite quantité de RU/s par partition, vous pouvez également utiliser la fusion de partitions (préversion) pour réduire le nombre de partitions et garantir un plus grand nombre de RU/s par partition pour le même débit provisionné total.

Exemple de scénario

Supposons que nous ayons une charge de travail qui assure le suivi des transactions qui ont lieu dans les magasins de détail. Étant donné que la plupart de nos requêtes sont basées sur StoreId, nous partitionnons sur la base de StoreId. Toutefois, au fil du temps, nous constatons que certains magasins ont plus d’activité que d’autres et nécessitent plus de débit pour traiter leurs charges de travail. Nous voyons une limitation du débit (429) pour les demandes sur ces StoreIds, et notre taux global de réponses 429 est supérieur à 1 à 5 %. Pendant ce temps, les autres magasins sont moins actifs et nécessitent moins de débit. Voyons comment redistribuer notre débit pour de meilleures performances.

Étape 1 : Identifier les partitions physiques qui ont besoin de plus de débit

Il existe deux façons d’identifier s’il existe une partition à chaud.

Option 1 : Utiliser les métriques Azure Monitor

Pour vérifier s’il existe une partition active, accédez à Insights>Débit>Consommation RU normalisée (%) par PartitionKeyRangeID. Filtrez sur une base de données et un conteneur spécifiques.

Chaque PartitionKeyRangeId correspond à une partition physique. Recherchez un PartitionKeyRangeId qui a une consommation de RU normalisée plus élevée que d’autres. Par exemple, une valeur est constamment à 100 %, mais d’autres sont à 30 % au maximum. Un modèle tel que celui-ci peut indiquer une partition à chaud.

Screenshot of Normalized RU Consumption by PartitionKeyRangeId chart with a hot partition.

Option 2 : Utiliser les journaux de diagnostic

Nous pouvons utiliser les informations de CDBPartitionKeyRUConsumption dans les journaux de diagnostic pour obtenir plus d’informations sur les clés de partition logique (et les partitions physiques correspondantes) qui consomment le plus de RU/s à un deuxième niveau de granularité. Notez que les exemples de requêtes utilisent 24 heures à des fins d’illustration uniquement - il est recommandé d’utiliser au moins sept jours d’historique pour comprendre le modèle.

Recherchez la partition physique (PartitionKeyRangeId) qui consomme le plus de RU/s au fil du temps

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

Pour une partition physique donnée, recherchez les 10 principales clés de partition logique qui consomment le plus de RU/s sur chaque heure

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

Étape 2 : Déterminer les RU/s cibles pour chaque partition physique

Déterminer les RU/s actuelles pour chaque partition physique

Tout d’abord, nous allons déterminer les RU/s actuelles pour chaque partition physique. Vous pouvez utiliser la métrique Azure Monitor PhysicalPartitionThroughput et la fractionner par dimension PhysicalPartitionId pour voir le nombre de RU/s dont vous disposez par partition physique.

Sinon, si vous n’avez pas modifié votre débit par partition, vous pouvez utiliser la formule : Current RU/s per partition = Total RU/s / Number of physical partitions

Suivez les instructions de l’article Meilleures pratiques pour la mise à l’échelle du débit approvisionné (unités de requête par seconde) pour déterminer le nombre de partitions physiques.

Vous pouvez aussi utiliser les commandes PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput et Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput pour lire les RU/s actuelles sur chaque partition physique.

Utilisez Install-Module pour installer le module Az.CosmosDB avec les fonctionnalités de préversion activées.

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

Utilisez la commande Get-AzCosmosDBSqlContainerPerPartitionThroughput ou Get-AzCosmosDBSqlDatabasePerPartitionThroughput pour lire les RU/s actuelles sur chaque partition physique.


// 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

Déterminer les RU/s pour la partition cible

Ensuite, nous allons décider du nombre de RU/s que nous voulons donner à notre ou nos partitions physiques les plus chaudes. Nous allons appeler cette définition de notre ou nos partitions cibles. Le maximum de RU/s que peut contenir une partition physique est 10 000.

La bonne approche dépend des exigences de votre charge de travail. Les approches générales comprennent ce qui suit :

  • Augmentez le nombre de RU/s en spécifiant un pourcentage, mesurez le taux de réponses 429 et répéter l’opération jusqu’à ce que le débit souhaité soit atteint.
    • Si vous n’êtes pas sûr du bon pourcentage, vous pouvez commencer par 10 % pour être prudent.
    • Si vous savez déjà que cette partition physique requiert la plus grande partie du débit de la charge de travail, vous pouvez commencer par doubler la valeur de RU/s ou l’augmenter jusqu’au maximum de 10 000 RU/s, le chiffre le plus bas étant retenu.
  • Augmentation de la valeur de RU/s sur Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Cette approche tente d’estimer la consommation de RU/s « réelle » si le débit des requêtes n’avait pas été limité.

Déterminer les RU/s pour la partition source

Enfin, nous allons décider du nombre de RU/s que nous voulons conserver sur nos autres partitions physiques. Cette sélection détermine les partitions dont la partition physique cible prend le débit.

Dans les API PowerShell, nous devons spécifier au moins une partition source à partir de laquelle redistribuer des RU/s. Nous pouvons aussi spécifier un débit minimal personnalisé que chaque partition physique doit avoir après la redistribution. Si elle n’est pas spécifiée par défaut, Azure Cosmos DB garantit que chaque partition physique a au moins 100 RU/s après la redistribution. Il est recommandé de spécifier explicitement le débit minimal.

La bonne approche dépend des exigences de votre charge de travail. Les approches générales comprennent ce qui suit :

  • Extraction équitable des RU/s à partir de toutes les partitions sources (fonctionne mieux avec un maximum de 10 partitions)
    • Calculez la quantité dont nous avons besoin pour compenser chaque partition physique source. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Affecter le débit minimal pour chaque partition source = Current RU/s of source partition - offset
  • Extraction des RU/s à partir des partitions les moins actives
    • Utiliser les métriques et les journaux de diagnostic Azure Monitor pour déterminer quelles partitions physiques possèdent le moins de trafic/volume de requêtes
    • Calculez la quantité dont nous avons besoin pour compenser chaque partition physique source. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Affecter le débit minimal pour chaque partition source = Current RU/s of source partition - offset

Étape 3 : Modifier programmatiquement le débit entre les partitions

Vous pouvez utiliser la commande PowerShell Update-AzCosmosDBSqlContainerPerPartitionThroughput pour redistribuer le débit.

Pour comprendre l’exemple ci-dessous, prenons un exemple dans lequel nous avons un conteneur qui a un total de 6 000 RU/s (de mise à l’échelle manuelle ou de mise à l’échelle automatique) et 3 partitions physiques. En fonction de notre analyse, nous voulons un layout dans lequel :

  • Partition physique 0 : 1 000 RU/s
  • Partition physique 1 : 4 000 RU/s
  • Partition physique 2 : 1 000 RU/s

Nous spécifions les partitions 0 et 2 comme partitions sources, et nous spécifions qu’après la redistribution, elles doivent avoir au moins 1 000 RU/s. La partition 1 est notre partition cible, dont nous avons indiqué qu’elle devait avoir 4 000 RU/s.

Utilisez Update-AzCosmosDBSqlContainerPerPartitionThroughput pour les conteneurs avec des RU/s dédiées ou la commande Update-AzCosmosDBSqlDatabasePerPartitionThroughput pour les bases de données avec des RU/s partagées afin de redistribuer le débit entre les partitions physiques. Dans les bases de données de débit partagé, les ID des partitions physiques sont représentés par une chaîne 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

Une fois la redistribution terminée, vous pouvez vérifier la modification en affichant la métrique PhysicalPartitionThroughput dans Azure Monitor. Fractionné par la dimension PhysicalPartitionId pour afficher le nombre de RU/s dont vous disposez par partition physique.

Si nécessaire, vous pouvez aussi réinitialiser les RU/s par partition physique, afin que les RU/s de votre conteneur soient réparties uniformément entre toutes les partitions physiques.

Utilisez la commande Update-AzCosmosDBSqlContainerPerPartitionThroughput pour les conteneurs avec des RU/s dédiées ou la commande Update-AzCosmosDBSqlDatabasePerPartitionThroughput pour les bases de données avec des RU/s partagées avec le paramètre -EqualDistributionPolicy afin de distribuer uniformément des RU/s sur toutes les partitions physiques.


// 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

Étape 4 : Vérifier et surveiller votre consommation de RU/s

Une fois la redistribution terminée, vous pouvez vérifier la modification en affichant la métrique PhysicalPartitionThroughput dans Azure Monitor. Fractionné par la dimension PhysicalPartitionId pour afficher le nombre de RU/s dont vous disposez par partition physique.

Il est recommandé de surveiller votre taux global de réponses 429 et de consommation de RU/s. Pour plus d’informations, passez en revue l’étape 1 pour vérifier que vous avez atteint les performances attendues.

Après les modifications, en supposant que votre charge de travail globale n’a pas changé, vous verrez probablement que les partitions physiques cible et source ont une consommation de RU normalisée plus élevée que précédemment. Une consommation de RU normalisée plus élevée est attendue. Essentiellement, vous avez alloué des RU/s plus proches de ce que chaque partition a réellement besoin de consommer, donc une consommation normalisée de RU plus élevée signifie que chaque partition utilise pleinement les RU/s qui lui sont alloués. Vous devez également vous attendre à voir un taux global inférieur d’exceptions 429, car les partitions à chaud disposent maintenant de plus de RU/s pour traiter les requêtes.

Limites

Critères d’éligibilité à la préversion

Pour utiliser la préversion, votre compte Azure Cosmos DB doit répondre à tous les critères suivants :

  • Votre compte Azure Cosmos DB utilise l’API pour NoSQL ou l’API pour MongoDB.
    • Si vous utilisez l’API pour MongoDB, la version doit être >= 3.6.
  • Votre compte Azure Cosmos DB utilise un débit approvisionné (manuel ou avec mise à l’échelle automatique). La distribution du débit entre les partitions ne s’applique pas aux comptes serverless.

Vous n’avez pas besoin de vous inscrire pour utiliser la préversion. Pour utiliser la fonctionnalité, utilisez les commandes PowerShell ou Azure CLI afin de redistribuer le débit sur les partitions physiques de vos ressources.

Étapes suivantes

Découvrez comment utiliser le débit approvisionné avec les articles suivants :