Redistribuer le débit entre les partitions
S’APPLIQUE À : 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 constatez systématiquement une utilisation normalisée de 100 % sur quelques partitions d’une collection.
- Vous constatez systématiquement une latence supérieure à l’acceptation.
Si vous ne constatez pas une consommation de RU de 100 % et que votre latence de bout en bout est acceptable, aucune action de reconfiguration des RU/s par partition n’est requise.
Si votre charge de travail a un trafic constant avec des pics occasionnels imprévisibles sur toutes vos partitions, nous vous recommandons d’utiliser la mise à l’échelle automatique et la capacité de rafale. 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 pour réduire le nombre de partitions et garantir un plus grand nombre de RU/s par partition pour le même débit approvisionné 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 constatons une consommation de RU normalisée de 100 % pour les requêtes sur ces StoreId. 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.
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, 1m), 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-AzCosmosDBMongoDBCollectionPerPartitionThroughput
pour lire les RU/s actuelles sur chaque partition physique.
// 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
Déterminer les RU/s pour la partition cible
Ensuite, nous allons décider du nombre de RU/s que nous voulons donner aux 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 les RU/s de 10 % et répétez 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.
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
- Calculez la quantité dont nous avons besoin pour compenser chaque partition physique source.
- 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-AzCosmosDBMongoDBCollectionPerPartitionThroughput
pour les collections avec des RU/s dédiées ou la commande Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput
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
// 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
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-AzCosmosDBMongoDBCollectionPerPartitionThroughput
pour les collections avec des RU/s dédiées ou la commande Update-AzCosmosDBMongoDBDatabasePerPartitionThroughput
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.
// 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
É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.
Nous vous recommandons de monitorer votre consommation de RU normalisée par partition. 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 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 :
- En savoir plus sur le débit approvisionné.
- En savoir plus sur les unités de requête.
- Besoin de surveiller les partitions actives ? Consultez unités de demande de surveillance.
- Vous souhaitez découvrir les meilleures pratiques ? Consultez Meilleures pratiques pour la mise à l’échelle du débit approvisionné.
- En savoir plus sur les erreurs de limitation de débit