Bästa metoder för skalning av provisionerat genomflöde

GÄLLER FÖR: NoSQL MongoDB Kassandra Gremlin Bord

I den här artikeln beskrivs metodtips och strategier för att skala dataflödet för din databas eller container (samling, tabell eller graf). Begreppen gäller när du antingen ökar de tilldelade manuella begärandeenheterna per sekund (RU/s) eller den maximala RU/s för autoskalning av alla resurser för någon av Azure Cosmos DB-API:erna.

Förutsättningar

• Om du är nybörjare på partitionering och skalning i Azure Cosmos DB kan du läsa Partitionering och horisontell skalning i Azure Cosmos DB.
• Om du planerar att skala upp dina RU/s på grund av 429-undantag, se över vägledningen i Diagnos och felsökning av "Begärandefrekvensen är för stor" (429)-undantag. Innan du ökar RU/s identifierar du rotorsaken till problemet och om det är rätt lösning att öka RU/s.

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 ändringsskrivningsregionå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ödet. Den återupptas automatiskt när övergången eller åtgärden att lägga till eller ta bort en 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.

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 du har en befintlig container med fem fysiska partitioner och 30 000 RU/s manuellt tillhandahållen prestanda. Du kan öka RU/s till 5 * 10,000 RU/s = 50,000 RU/s omedelbart. 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).

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 physical partitions * 10,000 RU/sdelar 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 du har en container med tre fysiska partitioner och 30 000 RU/s med manuellt tilldelad kapacitet. Om du ökar 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 physical partitions.

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

För att se varför ska vi ta ett exempel där du har en befintlig container med två 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.

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

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

• En partition som innehåller 50% av data (den här partitionen delades inte).
• Två partitioner som innehåller 25% av datan vardera (dessa är de resulterande underpartitionerna 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 du dock en skev lagringsfördelning och förfrågningsfördelning.

I följande diagram har partitioner 3 och 4 (underordnade partitioner av partition 2) vardera 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 om dubbelt så mycket data (40 GB).

För att upprätthålla en jämn lagringsdistribution kan du först skala upp dina RU/s för att säkerställa att varje partition delas. Sedan kan du sänka RU/s till önskat tillstånd igen.

Om du börjar med två fysiska partitioner måste du därför ange RU/s så att du får fyra fysiska partitioner för att garantera att partitionerna är jämnt fördelade efter delning. För att uppnå detta, ställ först in RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/s. När delningen är klar sänker du sedan RU/s till 30 000 RU/s.

Därför får 30,000 RU/s / 4 = 7500 RU/s varje fysisk partition hantera begäranden om 20 GB data. Sammantaget underhåller du jämn lagring och begärandedistribution mellan partitioner.

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.

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 bör välja för Måldata per fysisk partition i 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 är 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 är ~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 physical partition när du använder databaser för autoskalning eller delat dataflöde
• Initial throughput per physical partition = 6000 RU/s per physical partition när du använder manuell genomströmning

Exempel

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

Det innebär att du behöver 1000 GB / 40 GB = 25 fysiska partitioner för 1 TB data. För att säkerställa att du får 25 fysiska partitioner, med hjälp av manuell genomströmning, etablerar du först 25 * 6000 RU/s = 150,000 RU/s. När containern har skapats ökar du RU/s till 250 000 RU/s innan inmatningen börjar (sker direkt eftersom du redan har 25 fysiska partitioner) för att hjälpa inmatningen att gå snabbare. På så sätt kan varje partition få maximalt 10 000 RU/s.

Om du använder autoskalningsbar kapacitet eller en databas för delad kapacitet, för att hämta 25 fysiska partitioner, ska du först etablera 25 * 10,000 RU/s = 250,000 RU/s. Eftersom du redan har högst RU/s som kan stödjas med 25 fysiska partitioner skulle du 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, kan inmatningen teoretiskt sett slutföras i: 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours.

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 du sänka RU/s eller aktivera autoskalning efter behov.

Nästa steg

• Övervaka normaliserade RU/s för en Azure Cosmos DB-container eller ett konto
• Diagnostisera och felsöka "Begärandefrekvensen är för stor" (429) undantag
• Skapa Azure Cosmos DB-containrar och databaser med autoskalningsdataflöde