Dela via

Metodtips för skalning av etablerat dataflöde (RU/s)

  • Artikel

GÄLLER FÖR: Nosql Mongodb Cassandra Gremlin Tabell

I den här artikeln beskrivs metodtips och strategier för att skala dataflödet (RU/s) för databasen eller containern (samling, tabell eller diagram). Begreppen gäller när du ökar antingen etablerade manuella RU/s eller autoskalning av maximalt ANTAL RU/s för alla resurser för någon av Azure Cosmos DB-API:erna.

Förutsättningar

Bakgrund vid skalning av RU/s

När du skickar en begäran om att öka RU/s för databasen eller containern, beroende på din begärda RU/s och din aktuella fysiska partitionslayout, slutförs uppskalningsåtgärden antingen omedelbart eller asynkront (vanligtvis 4–6 timmar).

  • Omedelbar uppskalning
    • När dina begärda RU/s kan stödjas av den aktuella fysiska partitionslayouten behöver Azure Cosmos DB inte dela upp eller lägga till nya partitioner.
    • Därför slutförs åtgärden omedelbart och RU/s är tillgängliga för användning.
  • Asynkron uppskalning
    • När begärda RU/s är högre än vad som kan stödjas av den fysiska partitionslayouten delar Azure Cosmos DB upp befintliga fysiska partitioner. Detta inträffar tills resursen har det minsta antal partitioner som krävs för att stödja begärda RU/s.
    • Därför kan åtgärden ta en del tid att slutföra, vanligtvis 4–6 timmar. Varje fysisk partition har stöd för högst 10 000 RU/s (gäller för alla API:er) dataflöde och 50 GB lagring (gäller för alla API:er, förutom Cassandra, som har 30 GB lagring).

Kommentar

Om du utför en manuell regionredundansåtgärd eller lägger till/tar bort en ny region medan en asynkron uppskalningsåtgärd pågår, pausas uppskalningsåtgärden för dataflöde. Den återupptas automatiskt när redundansväxlingen eller åtgärden för att lägga till/ta bort region har slutförts.

  • Omedelbar nedskalning
    • För nedskalningsåtgärd behöver Azure Cosmos DB inte dela upp eller lägga till nya partitioner.
    • Därför slutförs åtgärden omedelbart och RU/s är tillgängliga för användning.
    • Det viktigaste resultatet av den här åtgärden är att RU:er per fysisk partition minskas.

Skala upp RU/s utan att ändra partitionslayouten

Steg 1: Hitta det aktuella antalet fysiska partitioner.

Gå till Insights>Dataflöde>Normaliserad RU-förbrukning (%) efter PartitionKeyRangeID. Räkna det distinkta antalet PartitionKeyRangeIds.

Räkna det distinkta antalet PartitionKeyRangeIds i diagrammet Normaliserad RU-förbrukning (%) efter PartitionKeyRangeID

Kommentar

Diagrammet visar endast högst 50 PartitionKeyRangeIds. Om resursen har fler än 50 kan du använda REST-API:et för Azure Cosmos DB för att räkna det totala antalet partitioner.

Varje PartitionKeyRangeId mappar till en fysisk partition och tilldelas att lagra data för en mängd möjliga hash-värden.

Azure Cosmos DB distribuerar dina data över logiska och fysiska partitioner baserat på partitionsnyckeln för att aktivera horisontell skalning. När data skrivs använder Azure Cosmos DB hash-värdet för partitionsnyckeln för att avgöra vilken logisk och fysisk partition datan finns på.

Steg 2: Beräkna standardvärdet för maximalt dataflöde

Den högsta RU/s som du kan skala till utan att utlösa Azure Cosmos DB för att dela partitioner är lika med Current number of physical partitions * 10,000 RU/s. Du kan hämta det här värdet från Azure Cosmos DB-resursprovidern. Utför en GET-begäran på databaseneller containerns dataflödesinställningsobjekt och hämta egenskapeninstantMaximumThroughput. Det här värdet är också tillgängligt på sidan Skala och Inställningar i databasen eller containern i portalen.

Exempel

Anta att vi har en befintlig container med fem fysiska partitioner och 30 000 RU/s manuellt etablerat dataflöde. Vi kan öka RU/s till 5 * 10 000 RU/s = 50 000 RU/s direkt. På samma sätt om vi hade en container med max RU/s för autoskalning på 30 000 RU/s (skalar mellan 3 000 och 30 000 RU/s), skulle vi kunna öka vår maximala RU/s till 50 000 RU/s direkt (skalar mellan 5 000 och 50 000 RU/s).

Dricks

Om du skalar upp RU/s för att svara på för stora undantag (429:er) rekommenderar vi att du först ökar RU/s till de högsta RU/s som stöds av din aktuella fysiska partitionslayout och utvärderar om de nya RU/s är tillräckliga innan du ökar ytterligare.

Så här säkerställer du jämn datadistribution under asynkron skalning

Bakgrund

När du ökar RU/s utöver det aktuella antalet fysiska partitioner * 10 000 RU/s, delar Azure Cosmos DB upp befintliga partitioner tills det nya antalet partitioner = ROUNDUP(requested RU/s / 10,000 RU/s). Under en delning delas överordnade partitioner upp i två underordnade partitioner.

Anta till exempel att vi har en container med tre fysiska partitioner och 30 000 RU/s med manuellt etablerat dataflöde. Om vi ökade dataflödet till 45 000 RU/s delar Azure Cosmos DB upp två av de befintliga fysiska partitionerna så att det totalt finns ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 fysiska partitioner.

Kommentar

Program kan alltid mata in och köra frågor mot data under en delning. Azure Cosmos DB-klient-SDK:er och -tjänsten hanterar automatiskt det här scenariot och ser till att begäranden dirigeras till rätt fysisk partition, så ingen ytterligare användaråtgärd krävs.

Om du har en arbetsbelastning som är mycket jämnt fördelad med avseende på lagrings- och begärandevolym – vanligtvis genom partitionering av fält med hög kardinalitet som /id – rekommenderas du när du skalar upp, konfigurera RU/s så att alla partitioner delas jämnt.

För att se varför ska vi ta ett exempel där vi har en befintlig container med 2 fysiska partitioner, 20 000 RU/s och 80 GB data.

Tack vare att du väljer en bra partitionsnyckel med hög kardinalitet är data ungefär jämnt fördelade i båda fysiska partitionerna. Varje fysisk partition tilldelas ungefär 50 % av nyckelområdet, vilket definieras som det totala intervallet för möjliga hashvärden.

Dessutom distribuerar Azure Cosmos DB RU/s jämnt över alla fysiska partitioner. Därför har varje fysisk partition 10 000 RU/s och 50 % (40 GB) av de totala data. Följande diagram visar vårt aktuella tillstånd.

Två PartitionKeyRangeIds, var och en med 10 000 RU/s, 40 GB och 50 % av det totala nyckelområdet

Anta nu att vi vill öka våra RU/s från 20 000 RU/s till 30 000 RU/s.

Om vi bara ökade RU/s till 30 000 RU/s delas bara en av partitionerna. Efter delningen har vi:

  • En partition som innehåller 50 % av data (den här partitionen delades inte)
  • Två partitioner som innehåller 25 % av alla data (det här är de resulterande underordnade partitionerna från den överordnade partitionen som delades)

Eftersom Azure Cosmos DB distribuerar RU/s jämnt över alla fysiska partitioner får varje fysisk partition fortfarande 10 000 RU/s. Nu har vi dock en skev lagrings- och begärandedistribution.

I följande diagram ser vi att partitioner 3 och 4 (underordnade partitioner av partition 2) var och en har 10 000 RU/s för att hantera begäranden om 20 GB data, medan partition 1 har 10 000 RU/s för att hantera begäranden för dubbelt så mycket data (40 GB).

Efter delningen finns det 3 PartitionKeyRangeIds, var och en med 10 000 RU/s. Ett av PartitionKeyRangeIds har dock 50 % av det totala nyckelområdet (40 GB), medan två av PartitionKeyRangeIds har 25 % av det totala nyckelområdet (20 GB)

För att upprätthålla en jämn lagringsdistribution kan vi först skala upp våra RU/s för att säkerställa varje partitionsdelning. Sedan kan vi sänka våra RU/s tillbaka till önskat tillstånd.

Så om vi börjar med två fysiska partitioner, för att garantera att partitionerna till och med delas upp, måste vi ange RU/s så att vi får fyra fysiska partitioner. För att uppnå detta anger vi först RU/s = 4 * 10 000 RU/s per partition = 40 000 RU/s. När delningen är klar kan vi sedan sänka våra RU/s till 30 000 RU/s.

Därför ser vi i följande diagram att varje fysisk partition får 30 000 RU/s /4 = 7 500 RU/s för att hantera begäranden om 20 GB data. Sammantaget underhåller vi jämn lagring och distribution av begäranden mellan partitioner.

När delningen har slutförts och RU/s har sänkts från 40 000 RU/s till 30 000 RU/s finns det 4 PartitionKeyRangeIds, var och en med 7 500 RU/s och 25 % av det totala nyckelområdet (20 GB)

Allmän formel

Steg 1: Öka ru/s för att garantera att alla partitioner delas jämnt

Om du i allmänhet har ett startantal fysiska partitioner Poch vill ange en önskad RU/s S:

Öka ru/s till: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Detta ger närmaste RU/s till önskat värde som säkerställer att alla partitioner delas jämnt.

Kommentar

När du ökar RU/s för en databas eller container kan detta påverka de minsta RU/s som du kan sänka till i framtiden. Normalt är den minsta RU/s lika med MAX(400 RU/s, Aktuell lagring i GB * 1 RU/s, Högsta RU/s som någonsin etablerats/100). Om den högsta RU/s som du någonsin har skalat till är 100 000 RU/s är den lägsta RU/s som du kan ange i framtiden 1 000 RU/s. Läs mer om minsta RU/s.

Steg 2: Sänk RU/s till önskad RU/s

Anta till exempel att vi har fem fysiska partitioner, 50 000 RU/s och vill skala till 150 000 RU/s. Vi bör först ange: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200 000 RU/s och sedan lägre till 150 000 RU/s.

När vi har skalat upp till 200 000 RU/s är den lägsta manuella RU/s som vi nu kan ställa in i framtiden 2 000 RU/s. Den lägsta autoskalnings max-RU/s som vi kan ange är 20 000 RU/s (skalar mellan 2 000 och 20 000 RU/s). Eftersom våra mål-RU/s är 150 000 RU/s påverkas vi inte av minsta RU/s.

Så här optimerar du RU/s för stor datainmatning

När du planerar att migrera eller mata in en stor mängd data till Azure Cosmos DB rekommenderar vi att du ställer in RU/s för containern så att Azure Cosmos DB etablerar de fysiska partitioner som behövs för att lagra den totala mängden data som du planerar att mata in i förväg. I annat fall kan Azure Cosmos DB under inmatningen behöva dela partitioner, vilket ger mer tid till datainmatningen.

Vi kan dra nytta av det faktum att Azure Cosmos DB under containerskapandet använder den heuristiska formeln för att starta RU/s för att beräkna antalet fysiska partitioner som ska börja med.

Steg 1: Granska valet av partitionsnyckel

Följ metodtipsen för att välja en partitionsnyckel för att säkerställa att du har en jämn distribution av begärandevolym och lagring efter migreringen.

Steg 2: Beräkna antalet fysiska partitioner som du behöver

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Varje fysisk partition kan innehålla högst 50 GB lagringsutrymme (30 GB för API för Cassandra). Vilket värde du ska välja för Target data per physical partition in GB beror på hur fullständigt packade du vill att de fysiska partitionerna ska vara och hur mycket du förväntar dig att lagringen ska växa efter migreringen.

Om du till exempel räknar med att lagringen fortsätter att växa kan du välja att ange värdet till 30 GB. Förutsatt att du har valt en bra partitionsnyckel som distribuerar lagringsutrymmet jämnt blir varje partition ~60 % full (30 GB av 50 GB). När framtida data skrivs kan de lagras på den befintliga uppsättningen fysiska partitioner, utan att tjänsten omedelbart behöver lägga till fler fysiska partitioner.

Om du däremot tror att lagringen inte ökar avsevärt efter migreringen kan du välja att ange värdet högre, till exempel 45 GB. Det innebär att varje partition blir ~90 % full (45 GB av 50 GB). Detta minimerar antalet fysiska partitioner som dina data är spridda över, vilket innebär att varje fysisk partition kan få en större del av den totala etablerade RU/s.

Steg 3: Beräkna antalet RU/s som ska börja med för alla partitioner

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition.

Vi börjar med ett exempel med ett godtyckligt antal mål-RU/s per fysisk partition.

  • Initial throughput per physical partition = 10 000 RU/s per fysisk partition vid autoskalning eller delade dataflödesdatabaser
  • Initial throughput per physical partition = 6 000 RU/s per fysisk partition när du använder manuellt dataflöde

Exempel

Anta att vi har 1 TB (1 000 GB) data som vi planerar att mata in och att vi vill använda manuellt dataflöde. Varje fysisk partition i Azure Cosmos DB har en kapacitet på 50 GB. Vi antar att vi strävar efter att paketpartitionerna ska vara 80 % fulla (40 GB), vilket ger oss utrymme för framtida tillväxt.

Det innebär att för 1 TB data behöver vi 1 000 GB/40 GB = 25 fysiska partitioner. För att säkerställa att vi får 25 fysiska partitioner etablerar vi först 25 * 6 000 RU/s = 150 000 RU/s om vi använder manuellt dataflöde. När containern har skapats ökar vi RU/s till 250 000 RU/s innan inmatningen börjar (sker direkt eftersom vi redan har 25 fysiska partitioner) när containern har skapats. På så sätt kan varje partition få maximalt 10 000 RU/s.

Om vi använder autoskalningsdataflöde eller en databas för delat dataflöde etablerar vi först 25 * 10 000 RU/s = 250 000 RU/s för att få 250 000 RU/s. Eftersom vi redan har högst RU/s som kan stödjas med 25 fysiska partitioner skulle vi inte ytterligare öka våra etablerade RU/s före inmatningen.

I teorin, med 250 000 RU/s och 1 TB data, om vi antar 1 kb dokument och 10 RU:er som krävs för skrivning, inmatningen kan teoretiskt sett slutföras i: 1 000 GB * (1 000 000 kb / 1 GB) * (1 dokument / 1 kb) * (10 RU / dokument) * (1 sekund / 250 000 RU) * (1 timme / 3600 sekunder) = 11,1 timmar.

Den här beräkningen är en uppskattning förutsatt att klienten som utför inmatningen helt kan mätta dataflödet och distribuera skrivningar över alla fysiska partitioner. Vi rekommenderar att du "blandar" dina data på klientsidan. Detta säkerställer att klienten varje sekund skriver till många distinkta logiska (och därmed fysiska) partitioner.

När migreringen är över kan vi sänka RU/s eller aktivera autoskalning efter behov.

Nästa steg