Dela via

Distribuera dataflöde mellan partitioner (förhandsversion)

  • Artikel

GÄLLER FÖR: NoSQL MongoDB

Som standard distribuerar Azure Cosmos DB det etablerade dataflödet för en databas eller container lika över alla fysiska partitioner. Scenarier kan dock uppstå där vissa logiska (och därmed fysiska) partitioner behöver mer dataflöde än andra på grund av en skev arbetsbelastning eller val av partitionsnyckel. I dessa scenarier ger Azure Cosmos DB dig möjlighet att omdistribuera ditt etablerade dataflöde mellan fysiska partitioner. Genom att distribuera dataflöde mellan partitioner får du bättre prestanda utan att behöva konfigurera det övergripande dataflödet baserat på den hetaste partitionen.

Funktionen för omdistribuering av dataflöde gäller för databaser och containrar med etablerat dataflöde (manuell och autoskalning) och gäller inte för serverlösa containrar. Du kan ändra dataflödet per fysisk partition med hjälp av Azure Cosmos DB PowerShell- eller Azure CLI-kommandona.

När du ska använda den här funktionen

I allmänhet rekommenderas användning av den här funktionen för scenarier när båda följande är sanna:

  • Du ser konsekvent större än 1–5 % total frekvens på 429 svar
  • Du har en konsekvent, förutsägbar frekvent partition

Om du inte ser några 429-svar och svarstiden från slutpunkt till slutpunkt är acceptabel krävs det ingen åtgärd för att konfigurera om RU/s per partition. Om du har en arbetsbelastning som har konsekvent trafik med tillfälliga oförutsägbara toppar i alla partitioner rekommenderar vi att du använder autoskalning och burst-kapacitet (förhandsversion). Autoskalning och burst-kapacitet säkerställer att du kan uppfylla dina dataflödeskrav. Om du har en liten mängd RU/s per partition kan du också använda partitionssammanslagningen (förhandsversion) för att minska antalet partitioner och säkerställa fler RU/s per partition för samma totala etablerade dataflöde.

Exempelscenario

Anta att vi har en arbetsbelastning som håller reda på transaktioner som äger rum i butiker. Eftersom de flesta av våra frågor är av StoreIdpartitioneras vi efter StoreId. Men med tiden ser vi att vissa butiker har mer aktivitet än andra och kräver mer dataflöde för att hantera sina arbetsbelastningar. Vi ser hastighetsbegränsning (429) för begäranden mot dessa StoreId och vår totala frekvens på 429 svar är större än 1–5 %. Samtidigt är andra butiker mindre aktiva och kräver mindre dataflöde. Nu ska vi se hur vi kan omdistribuera vårt dataflöde för bättre prestanda.

Steg 1: Identifiera vilka fysiska partitioner som behöver mer dataflöde

Det finns två sätt att identifiera om det finns en frekvent partition.

Alternativ 1: Använda Azure Monitor-mått

Om du vill kontrollera om det finns en frekvent partition går du till Insights>Dataflöde>Normaliserad RU-förbrukning (%) av PartitionKeyRangeID. Filtrera till en specifik databas och container.

Varje PartitionKeyRangeId mappar till en fysisk partition. Leta efter ett PartitionKeyRangeId som konsekvent har en högre normaliserad RU-förbrukning än andra. Ett värde ligger till exempel konsekvent på 100 %, men andra ligger på 30 % eller mindre. Ett mönster som detta kan indikera en frekvent partition.

Skärmbild av diagrammet Normaliserad RU-förbrukning efter PartitionKeyRangeId med en frekvent partition.

Alternativ 2: Använd diagnostikloggar

Vi kan använda informationen från CDBPartitionKeyRUConsumption i diagnostikloggar för att få mer information om de logiska partitionsnycklarna (och motsvarande fysiska partitioner) som förbrukar mest RU/s på en andra nivås kornighet. Observera att exempelfrågorna endast använder 24 timmar för illustrativa syften – vi rekommenderar att du använder minst sju dagars historik för att förstå mönstret.

Hitta den fysiska partition (PartitionKeyRangeId) som förbrukar mest RU/s över tid

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

För en viss fysisk partition hittar du de 10 viktigaste logiska partitionsnycklarna som förbrukar flest RU/s under varje timme

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

Steg 2: Fastställa mål-RU/s för varje fysisk partition

Fastställa aktuella RU/s för varje fysisk partition

Först ska vi fastställa aktuella RU/s för varje fysisk partition. Du kan använda Azure Monitor-måttet PhysicalPartitionThroughput och delas upp med dimensionen PhysicalPartitionId för att se hur många RU/s du har per fysisk partition.

Om du inte har ändrat dataflödet per partition tidigare kan du också använda formeln: Current RU/s per partition = Total RU/s / Number of physical partitions

Följ riktlinjerna i artikeln Metodtips för skalning av etablerat dataflöde (RU/s) för att fastställa antalet fysiska partitioner.

Du kan också använda PowerShell Get-AzCosmosDBSqlContainerPerPartitionThroughput och Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput kommandon för att läsa aktuella RU/s på varje fysisk partition.

Använd Install-Module för att installera Az.CosmosDB-modulen med förhandsversionsfunktioner aktiverade.

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

Get-AzCosmosDBSqlContainerPerPartitionThroughput Använd kommandot eller Get-AzCosmosDBSqlDatabasePerPartitionThroughput för att läsa aktuella RU/s på varje fysisk partition.


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

Fastställa RU/s för målpartition

Nu ska vi bestämma hur många RU/s vi vill ge till våra hetaste fysiska partitioner. Vi anropar den här inställningen för våra målpartitioner. De flesta RU/s som en fysisk partition kan innehålla är 10 000 RU/s.

Rätt metod beror på dina arbetsbelastningskrav. Allmänna metoder är:

  • Öka RU/s med en procentandel, mäta frekvensen för 429 svar och upprepa tills önskat dataflöde uppnås.
    • Om du inte är säker på rätt procentsats kan du börja med 10 % för att vara konservativ.
    • Om du redan vet att den här fysiska partitionen kräver det mesta av dataflödet för arbetsbelastningen kan du börja med att fördubbla RU/s eller öka den till högst 10 000 RU/s, beroende på vilket som är lägre.
  • Öka RU/s till Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Den här metoden försöker beräkna vad den "verkliga" RU/s-förbrukningen skulle ha varit om begärandena inte hade varit hastighetsbegränsade.

Fastställa RU/s för källpartition

Slutligen ska vi bestämma hur många RU/s vi vill behålla på våra andra fysiska partitioner. Det här valet avgör vilka partitioner som den fysiska målpartitionen tar dataflödet från.

I PowerShell-API:erna måste vi ange minst en källpartition för att omdistribuera RU/s från. Vi kan också ange ett anpassat minsta dataflöde som varje fysisk partition ska ha efter omfördelningen. Om det inte anges ser Azure Cosmos DB som standard till att varje fysisk partition har minst 100 RU/s efter omfördelningen. Vi rekommenderar att du uttryckligen anger det minsta dataflödet.

Rätt metod beror på dina arbetsbelastningskrav. Allmänna metoder är:

  • Ta RU/s lika från alla källpartitioner (fungerar bäst när det finns <= 10 partitioner)
    • Beräkna hur mycket vi behöver förskjuta varje fysisk källpartition med. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Tilldela minsta dataflöde för varje källpartition = Current RU/s of source partition - offset
  • Ta RU/s från de minst aktiva partitionerna
    • Använd Azure Monitor-mått och diagnostikloggar för att avgöra vilka fysiska partitioner som har minst trafik/begärandevolym
    • Beräkna hur mycket vi behöver förskjuta varje fysisk källpartition med. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Tilldela minsta dataflöde för varje källpartition = Current RU/s of source partition - offset

Steg 3: Ändra dataflödet programatiskt mellan partitioner

Du kan använda PowerShell-kommandot Update-AzCosmosDBSqlContainerPerPartitionThroughput för att omdistribuera dataflödet.

För att förstå exemplet nedan ska vi ta ett exempel där vi har en container som har totalt 6 000 RU/s (antingen 6 000 manuella RU/s eller autoskalning av 6 000 RU/s) och 3 fysiska partitioner. Baserat på vår analys vill vi ha en layout där:

  • Fysisk partition 0: 1 000 RU/s
  • Fysisk partition 1: 4 000 RU/s
  • Fysisk partition 2: 1 000 RU/s

Vi anger partitionerna 0 och 2 som våra källpartitioner och anger att efter omfördelningen ska de ha minst 1 000 RU/s. Partition 1 är ute målpartition, som vi anger ska ha 4 000 RU/s.

Update-AzCosmosDBSqlContainerPerPartitionThroughput Använd för containrar med dedikerade RU/s eller Update-AzCosmosDBSqlDatabasePerPartitionThroughput kommandot för databaser med delade RU/s för att omdistribuera dataflöde mellan fysiska partitioner. I databaser med delat dataflöde representeras ID:t för de fysiska partitionerna av en GUID-sträng.

$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

När du har slutfört omdistributionen kan du verifiera ändringen genom att visa måttet PhysicalPartitionThroughput i Azure Monitor. Dela upp med dimensionen PhysicalPartitionId för att se hur många RU/s du har per fysisk partition.

Om det behövs kan du även återställa RU/s per fysisk partition så att RU/s för din container är jämnt fördelade över alla fysiska partitioner.

Update-AzCosmosDBSqlContainerPerPartitionThroughput Använd kommandot för containrar med dedikerade RU/s eller Update-AzCosmosDBSqlDatabasePerPartitionThroughput kommandot för databaser med delade RU/s med parameter -EqualDistributionPolicy för att fördela RU/s jämnt över alla fysiska partitioner.


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

Steg 4: Verifiera och övervaka ru/s-förbrukningen

När du har slutfört omdistributionen kan du verifiera ändringen genom att visa måttet PhysicalPartitionThroughput i Azure Monitor. Dela upp med dimensionen PhysicalPartitionId för att se hur många RU/s du har per fysisk partition.

Vi rekommenderar att du övervakar din totala frekvens på 429 svar och RU/s-förbrukning. Mer information finns i Steg 1 för att verifiera att du har uppnått de prestanda du förväntar dig.

Efter ändringarna, förutsatt att den övergripande arbetsbelastningen inte har ändrats, ser du förmodligen att både mål- och käll-fysiska partitioner har högre normaliserad RU-förbrukning än tidigare. Högre normaliserad RU-förbrukning är förväntat beteende. I princip har du allokerat RU/s närmare vad varje partition faktiskt behöver förbruka, så högre normaliserad RU-förbrukning innebär att varje partition fullt ut använder sina allokerade RU/s. Du bör också förvänta dig att se en lägre total frekvens på 429 undantag, eftersom de frekventa partitionerna nu har fler RU/s för att hantera begäranden.

Begränsningar

Villkor för förhandsversion av berättigande

Om du vill använda förhandsversionen måste ditt Azure Cosmos DB-konto uppfylla följande kriterier:

  • Ditt Azure Cosmos DB-konto använder API för NoSQL eller API för MongoDB.
    • Om du använder API för MongoDB måste versionen vara >= 3.6.
  • Ditt Azure Cosmos DB-konto använder etablerat dataflöde (manuellt eller autoskalning). Distribution av dataflöde mellan partitioner gäller inte för serverlösa konton.

Du behöver inte registrera dig för att använda förhandsversionen. Om du vill använda funktionen använder du PowerShell- eller Azure CLI-kommandona för att omdistribuera dataflöde mellan dina resursers fysiska partitioner.

Nästa steg

Lär dig hur du använder etablerat dataflöde med följande artiklar: