Doorvoer opnieuw distribueren tussen partities (preview)

  • Artikel

VAN TOEPASSING OP: Nosql MongoDB

Standaard distribueert Azure Cosmos DB de ingerichte doorvoer van een database of container gelijkmatig over alle fysieke partities. Scenario's kunnen zich echter voordoen als gevolg van een scheeftrekken in de werkbelasting of de keuze van de partitiesleutel, bepaalde logische (en dus fysieke) partities meer doorvoer nodig hebben dan andere partities. Voor deze scenario's biedt Azure Cosmos DB u de mogelijkheid om uw ingerichte doorvoer opnieuw te distribueren over fysieke partities. Het opnieuw distribueren van doorvoer tussen partities helpt u betere prestaties te bereiken zonder dat u uw totale doorvoer hoeft te configureren op basis van de heetste partitie.

De functie voor het opnieuw distribueren van doorvoer is van toepassing op databases en containers met behulp van ingerichte doorvoer (handmatig en automatisch schalen) en is niet van toepassing op serverloze containers. U kunt de doorvoer per fysieke partitie wijzigen met behulp van de Azure Cosmos DB PowerShell- of Azure CLI-opdrachten.

Wanneer u deze functie gebruikt

Over het algemeen wordt het gebruik van deze functie aanbevolen voor scenario's waarin beide waar zijn:

  • U ziet consistent meer dan 1-5% totale snelheid van 429 antwoorden
  • U hebt een consistente, voorspelbare dynamische partitie

Als u geen 429-foutmeldingen ziet en de volledige latentie acceptabel is, is er geen actie nodig om RU/s per partitie opnieuw te configureren. Als u een workload hebt waarop consistent verkeer plaatsvindt met af en toe onvoorspelbare pieken in al uw partities, is het verstandig om automatische schaalaanpassing en burst-capaciteit (preview) te gebruiken. Automatische schaalaanpassing en burst-capaciteit zorgen ervoor dat u aan uw doorvoervereisten kunt voldoen. Als u een kleine hoeveelheid RU/s per partitie hebt, kunt u ook de samenvoeging van partities (preview) gebruiken om het aantal partities te verminderen en ervoor te zorgen dat er meer RU/s per partitie zijn voor dezelfde totale ingerichte doorvoer.

Voorbeeldscenario

Stel dat we een workload hebben die transacties bijhoudt die plaatsvinden in winkels. Omdat de meeste van onze query's door StoreIdzijn, partitioneren we op StoreId. Na verloop van tijd zien we echter dat sommige winkels meer activiteit hebben dan andere winkels en dat er meer doorvoer nodig is om hun workloads te verwerken. We zien snelheidsbeperking (429) voor aanvragen voor die StoreIds en onze totale snelheid van 429 antwoorden is groter dan 1-5%. Ondertussen zijn andere winkels minder actief en vereisen ze minder doorvoer. Laten we eens kijken hoe we onze doorvoer opnieuw kunnen distribueren voor betere prestaties.

Stap 1: bepalen welke fysieke partities meer doorvoer nodig hebben

Er zijn twee manieren om te bepalen of er een dynamische partitie is.

Optie 1: Metrische gegevens van Azure Monitor gebruiken

Als u wilt controleren of er een dynamische partitie is, gaat u naar Genormaliseerd RU-verbruik voor inzichten>>(%) op PartitionKeyRangeID. Filteren op een specifieke database en container.

Elke PartitionKeyRangeId wordt toegewezen aan één fysieke partitie. Zoek naar één PartitionKeyRangeId die consistent een hoger genormaliseerd RU-verbruik heeft dan andere. Eén waarde is bijvoorbeeld consistent op 100%, maar andere waarden zijn 30% of minder. Een patroon zoals dit kan duiden op een dynamische partitie.

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

Optie 2: Diagnostische logboeken gebruiken

We kunnen de informatie van CDBPartitionKeyRUConsumption in diagnostische logboeken gebruiken voor meer informatie over de logische partitiesleutels (en bijbehorende fysieke partities) die de meeste RU/s op een tweede niveau granulariteit gebruiken. Houd er rekening mee dat de voorbeeldquery's slechts 24 uur voor illustratieve doeleinden gebruiken. Het is raadzaam om ten minste zeven dagen geschiedenis te gebruiken om het patroon te begrijpen.

Zoek de fysieke partitie (PartitionKeyRangeId) die de meeste RU/s in de loop van de tijd verbruikt

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

Voor een bepaalde fysieke partitie zoekt u de tien belangrijkste logische partitiesleutels die de meeste RU/s per uur gebruiken

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

Stap 2: de doel-RU/s voor elke fysieke partitie bepalen

Huidige RU/s voor elke fysieke partitie bepalen

Laten we eerst de huidige RU/s voor elke fysieke partitie bepalen. U kunt de metrische gegevens physicalPartitionThroughput van Azure Monitor gebruiken en splitsen door de dimensie PhysicalPartitionId om te zien hoeveel RU/s u per fysieke partitie hebt.

Als u de doorvoer per partitie nog niet eerder hebt gewijzigd, kunt u de formule ook gebruiken: Current RU/s per partition = Total RU/s / Number of physical partitions

Volg de richtlijnen in het artikel Aanbevolen procedures voor het schalen van ingerichte doorvoer (RU/s) om het aantal fysieke partities te bepalen.

U kunt ook de PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput en Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput opdrachten gebruiken om de huidige RU/s op elke fysieke partitie te lezen.

Gebruik Install-Module deze optie om de Az.CosmosDB-module te installeren waarvoor functies voor voorlopige versies zijn ingeschakeld.

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

Gebruik de Get-AzCosmosDBSqlContainerPerPartitionThroughput of Get-AzCosmosDBSqlDatabasePerPartitionThroughput opdracht om de huidige RU/s op elke fysieke partitie te lezen.


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

RU/s bepalen voor doelpartitie

Vervolgens gaan we bepalen hoeveel RU/s we aan onze heetste fysieke partitie(s) willen geven. We noemen deze set onze doelpartitie(s). De meeste RU/s elke fysieke partitie kan 10.000 RU/s bevatten.

De juiste benadering is afhankelijk van uw workloadvereisten. Algemene benaderingen zijn onder andere:

  • Verhoog de RU/s met een percentage, meet de snelheid van 429 antwoorden en herhaal deze totdat de gewenste doorvoer wordt bereikt.
    • Als u het juiste percentage niet zeker weet, kunt u beginnen met 10% om conservatief te zijn.
    • Als u al weet dat voor deze fysieke partitie de meeste doorvoer van de workload is vereist, kunt u beginnen door de RU/s te verdubbelen of te verhogen tot het maximum van 10.000 RU/s, afhankelijk van wat lager is.
  • De RU/s verhogen naar Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Met deze benadering wordt geprobeerd te schatten wat het werkelijke RU/s-verbruik zou zijn geweest als de aanvragen niet beperkt waren geweest.

RU/s bepalen voor bronpartitie

Ten slotte gaan we bepalen hoeveel RU/s we willen behouden op onze andere fysieke partities. Deze selectie bepaalt de partities waaruit de fysieke doelpartitie doorvoer neemt.

In de PowerShell-API's moeten we ten minste één bronpartitie opgeven om RU/s opnieuw te distribueren. We kunnen ook een aangepaste minimale doorvoer opgeven die elke fysieke partitie moet hebben na de herdistributie. Als dit niet is opgegeven, zorgt Azure Cosmos DB er standaard voor dat elke fysieke partitie ten minste 100 RU/s heeft na de herdistributie. Het wordt aanbevolen om expliciet de minimale doorvoer op te geven.

De juiste benadering is afhankelijk van uw workloadvereisten. Algemene benaderingen zijn onder andere:

  • Ru/s even gebruiken van alle bronpartities (werkt het beste als er = 10 partities zijn <)
    • Bereken de hoeveelheid die we nodig hebben om elke fysieke bronpartitie te compenseren. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • De minimale doorvoer toewijzen voor elke bronpartitie = Current RU/s of source partition - offset
  • RU/s nemen van de minst actieve partitie(s)
    • Metrische gegevens en diagnostische logboeken van Azure Monitor gebruiken om te bepalen welke fysieke partities het minste verkeer/aanvraagvolume hebben
    • Bereken de hoeveelheid die we nodig hebben om elke fysieke bronpartitie te compenseren. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • De minimale doorvoer toewijzen voor elke bronpartitie = Current RU/s of source partition - offset

Stap 3: De doorvoer via een programma wijzigen tussen partities

U kunt de PowerShell-opdracht Update-AzCosmosDBSqlContainerPerPartitionThroughput gebruiken om doorvoer opnieuw te distribueren.

Als u het onderstaande voorbeeld wilt begrijpen, gaan we een voorbeeld nemen van een container met 6000 RU/s totaal (ofwel 6000 handmatige RU/s of automatische schaalaanpassing van 6000 RU/s) en 3 fysieke partities. Op basis van onze analyse willen we een indeling waarin:

  • Fysieke partitie 0: 1000 RU/s
  • Fysieke partitie 1: 4000 RU/s
  • Fysieke partitie 2: 1000 RU/s

We geven partities 0 en 2 op als onze bronpartities en geven aan dat ze na de herdistributie minimaal RU/s van 1000 RU/s moeten hebben. Partitie 1 is buiten de doelpartitie, die we opgeven moet 4000 RU/s hebben.

Gebruik voor Update-AzCosmosDBSqlContainerPerPartitionThroughput containers met toegewezen RU/s of de Update-AzCosmosDBSqlDatabasePerPartitionThroughput opdracht voor databases met gedeelde RU/s om doorvoer over fysieke partities opnieuw te distribueren. In gedeelde doorvoerdatabases worden de id's van de fysieke partities vertegenwoordigd door een GUID-tekenreeks.

$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

Nadat u de herdistributie hebt voltooid, kunt u de wijziging controleren door de metrische gegevens PhysicalPartitionThroughput in Azure Monitor weer te geven. Splits op de dimensie PhysicalPartitionId om te zien hoeveel RU/s u per fysieke partitie hebt.

Indien nodig kunt u de RU/s per fysieke partitie ook opnieuw instellen, zodat de RU/s van uw container gelijkmatig worden verdeeld over alle fysieke partities.

Gebruik de Update-AzCosmosDBSqlContainerPerPartitionThroughput opdracht voor containers met toegewezen RU/s of de Update-AzCosmosDBSqlDatabasePerPartitionThroughput opdracht voor databases met gedeelde RU/s met parameter -EqualDistributionPolicy om RU/s gelijkmatig over alle fysieke partities te distribueren.


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

Stap 4: Uw RU/s-verbruik controleren en bewaken

Nadat u de herdistributie hebt voltooid, kunt u de wijziging controleren door de metrische gegevens PhysicalPartitionThroughput in Azure Monitor weer te geven. Splits op de dimensie PhysicalPartitionId om te zien hoeveel RU/s u per fysieke partitie hebt.

Het is raadzaam om uw totale snelheid van 429 reacties en RU/s-verbruik te controleren. Raadpleeg stap 1 voor meer informatie om te controleren of u de verwachte prestaties hebt bereikt.

Nadat de wijzigingen zijn doorgevoerd, ervan uitgaande dat de algehele workload niet is gewijzigd, zult u waarschijnlijk zien dat zowel de fysieke doel- als de bronpartitie een hoger genormaliseerd RU-verbruik hebben dan eerder. Een hoger genormaliseerd RU-verbruik wordt verwacht. In wezen hebt u RU/s dichter bij wat elke partitie daadwerkelijk moet gebruiken, dus hoger genormaliseerd RU-verbruik betekent dat elke partitie volledig gebruikmaakt van de toegewezen RU/s. U zou ook een lagere algemene snelheid van 429 uitzonderingen moeten zien, omdat de dynamische partities nu meer RU/s hebben voor het verwerken van aanvragen.

Beperkingen

Criteria voor geschiktheid voor preview

Als u de preview wilt gebruiken, moet uw Azure Cosmos DB-account voldoen aan alle volgende criteria:

  • Uw Azure Cosmos DB-account maakt gebruik van API voor NoSQL of API voor MongoDB.
    • Als u API voor MongoDB gebruikt, moet de versie = 3.6 zijn >.
  • Uw Cosmos-account maakt gebruik van de ingerichte doorvoer (handmatige of automatische schaalaanpassing). De distributie van doorvoer tussen partities is niet van toepassing op serverloze accounts.

U hoeft zich niet te registreren om de preview te gebruiken. Als u de functie wilt gebruiken, gebruikt u de PowerShell- of Azure CLI-opdrachten om de doorvoer over de fysieke partities van uw resources opnieuw te distribueren.

Volgende stappen

Meer informatie over het gebruik van ingerichte doorvoer met de volgende artikelen: