Vanliga frågor och svar om etablerat dataflöde med autoskalning i Azure Cosmos DB

Autoskalning eller autoskalning av etablerat dataflöde är det uppdaterade namnet på Azure Cosmos DB-funktionen som tidigare kallades autopilot. I den aktuella versionen av autoskalning har vi lagt till nya funktioner, inklusive programmatiskt stöd och möjligheten att ange anpassade maximala RU/s.

Resurser som skapades i den tidigare nivåmodellen stöds automatiskt i den nya autoskalningsmodellen för maximalt ANTAL RU/s. Den övre gränsen för nivån blir det nya maximala ANTALET RU/s, vilket resulterar i samma skalningsintervall.

Om du till exempel tidigare har valt den nivå som skalades mellan 400 RU/s och 4 000 RU/s, visar databasen eller containern nu maximalt RU/s på 4 000 RU/s, vilket skalar mellan 400 RU/s och 4 000 RU/s. Sedan kan du ändra maximalt antal RU/s till ett anpassat värde baserat på din arbetsbelastning.

Från och med april 2022 kan du ange autoskalning med maximalt RU/s så lågt som 1 000 RU/s (skalar mellan 100 RU/s och 1 000 RU/s). Du kan också ange ett skalningsintervall på 200 RU/s till 2 000 RU/s eller 300 RU/s till 3 000 RU/s. Tidigare var startpunkten 400 RU/s till 4 000 RU/s.

Vi rekommenderar den här konfigurationen för arbetsbelastningar med låga dataflödeskrav, men som fortfarande kan skalas till maximalt antal RU/s.

Med autoskalning skalar systemet dataflödet (RU/s) T upp eller T ned inom intervallet 0,1 × Tmax baserat Tmax på inkommande trafik. Eftersom skalningen är automatisk och omedelbar kan du när som helst använda upp till den etablerade Tmax utan fördröjning.

Använd Azure Monitor-mått för att övervaka både den etablerade autoskalningsgränsen för MAXIMAL RU/s och det aktuella dataflödet (RU/s) som systemet skalas till.

Varje timme debiteras du för det högsta dataflödet T som systemet skalas till inom den timmen. Om resursen inte hade några begäranden under timmen eller inte skalades längre än 0,1 × Tmaxdebiteras du för minst 0,1 × Tmax. Mer information finns på prissidan för Azure Cosmos DB.

I konton med en skrivregion är autoskalningsfrekvensen per 100 RU/s 1,5 gånger hastigheten för det etablerade standarddataflödet (manuell). Din faktura visar den befintliga standardetablerade dataflödesmätaren. Den här mätarens kvantitet multipliceras med 1,5. Om till exempel den högsta RU/s som systemet skalades till inom en timme var 6 000 RU/s debiteras du 60 × 1,5 = 90 enheter av mätaren för den timmen.

I konton som har regioner med flera skrivningar är autoskalningsfrekvensen per 100 RU/s samma som frekvensen för standarddataflöde (manuell) för flera skrivningsregioner. Din faktura visar den befintliga mätaren för flera skrivningsregioner. Eftersom priserna är desamma ser du samma kvantitet som för standarddataflöde om du använder autoskalning.

Ja. Med reserverad kapacitet för konton med enskrivningsregioner tillämpas reservationsrabatten för autoskalningsresurser på mätaranvändningen med ett förhållande på 1,5 gånger förhållandet mellan den specifika regionen. Om du till exempel vill använda reserverad kapacitet för att täcka 10 000 RU/s för autoskalning bör du planera att köpa totalt 15 000 RU/s reserverad kapacitet.

Reserverad kapacitet för flera skrivningsregioner fungerar på samma sätt för autoskalning och standardetablerad dataflöde (manuell). Mer information finns i Reserverad kapacitet för Azure Cosmos DB.

Ja. På den kostnadsfria nivån kan du använda autoskalningsdataflöde i en databas eller i en container. Läs mer om hur fakturering på den kostnadsfria nivån fungerar med autoskalning.

Ja. Autoskalning stöds för alla API:er: NoSQL, Gremlin, Table, Cassandra och MongoDB.

Ja. Maximalt antal RU/er är tillgängliga i varje region som läggs till i Azure Cosmos DB-kontot.

Läs om hur du aktiverar autoskalning.

Ja. Du kan också växla mellan autoskalning och standardetablerade dataflöden (manuell). För närvarande kan du använda Azure-portalen, Azure CLI eller PowerShell för att utföra dessa åtgärder för alla API:er. Du kan inte använda Azure Cosmos DB-klient-SDK:er eller en Azure Resource Manager-mall för att migrera mellan manuellt etablerat dataflöde och autoskalning. Du kan dock använda klient-SDK:er eller en Azure Resource Manager-mall för att skapa nya autoskalningsresurser och ändra maximalt antal RU/s för en befintlig autoskalningsresurs.

Konceptuellt är det en process i två steg att ändra dataflödestypen. Först skickar du en begäran om att ändra dataflödesinställningarna för att använda autoskalning eller manuellt etablerat dataflöde. I båda fallen fastställer och anger systemet automatiskt ett initialt RU/s-värde baserat på aktuella dataflödesinställningar och lagring. Under det här steget godkänns inget ru/s-värde från användaren. När uppdateringen är klar kan du sedan ändra RU/s för att hantera din arbetsbelastning.

Migrera från standardetablerat dataflöde (manuellt) till autoskalning

För en container använder du följande formel för att beräkna den ursprungliga autoskalningsgränsen för MAXIMAL RU/s:

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10) avrundat till närmaste 1 000 RU/s.

Det faktiska maximala antalet RU/s för automatisk skalning kan variera beroende på din kontokonfiguration.

Exempel nr 1: Du har en container som har ett manuellt etablerat dataflöde på 10 000 RU/s och 25 GB lagringsutrymme. När du aktiverar autoskalning är den ursprungliga maximala RU/s för autoskalning 10 000 RU/s, vilket kan skalas mellan 1 000 RU/s och 10 000 RU/s.

Exempel nr 2: Du har en container som har ett manuellt etablerat dataflöde på 50 000 RU/s och 25 000 GB lagringsutrymme. När du aktiverar autoskalning är den ursprungliga maximala RU/s för autoskalning 250 000 RU/s, vilket kan skalas mellan 25 000 RU/s och 250 000 RU/s.

Migrera från autoskalning till standard (manuellt) etablerat dataflöde

Det första manuella etablerade dataflödet är lika med det aktuella maximala ANTALET RU/s för automatisk skalning.

Exempel: Du har en databas eller container för autoskalning som har högst 20 000 RU/s (skalar mellan 2 000 RU/s och 20 000 RU/s). När du uppdaterar för att använda manuellt etablerat dataflöde är det första dataflödet 20 000 RU/s.

Om du behöver migrera ett stort antal dataflödesresurser bör du överväga att använda det här Azure CLI-skriptet – Konvertera till autoskalning.

Ja. Om du vill aktivera autoskalning via programmering i en befintlig databas eller container kan du använda Azure CLI eller PowerShell.

Om du vill skapa en ny databas eller container som använder autoskalning kan du använda Azure CLI, PowerShell eller en Azure Resource Manager-mall.

Ja. Om du vill aktivera autoskalning för en databas med delat dataflöde väljer du autoskalning och alternativet Etablera dataflöde när du skapar databasen.

Azure Cosmos DB tillämpar högst 25 containrar i en databas med delat dataflöde. Maxvärdet gäller för databaser som har antingen autoskalning eller standarddataflöde (manuell).

Autoskalning påverkar inte konsekvensnivån för en databas.

Mer information finns i Konsekvensnivåer.

Lagringsgränsen i GB för varje maximal RU/s är den maximala RU/s för databasen eller containern dividerat med 10. Om den maximala RU/s till exempel är 20 000 RU/s kan resursen ha stöd för 2 000 GB lagringsutrymme.

Tillgängliga alternativ för maximal RU/s och lagring finns i Etablera autoskalningsgränser för dataflöde.

Om den lagringsgräns som är associerad med det maximala dataflödet för databasen eller containern överskrids ökar Azure Cosmos DB automatiskt det maximala dataflödet till näst högsta RU/s som kan stödja den lagringsnivån.

Om du till exempel börjar med maximalt RU/s på 50 000 RU/s (skalar mellan 5 000 RU/s och 50 000 RU/s) kan du lagra upp till 5 000 GB data. Om lagringsstorleken ökar till 5 001 GB är lagringen nu 6 000 GB och den nya maximala RU/s är 60 000 RU/s (skalar mellan 6 000 RU/s och 60 000 RU/s).

Ja. Mer information finns i Etablera dataflöde för autoskalning.

När du ändrar maximalt antal RU/s kan det ta 4 till 6 timmar att slutföra den asynkrona åtgärden, beroende på det begärda värdet. Läs mer.

När du skickar en begäran om att öka maximalt antal RU/s Tmax, beroende på det maximala antalet RU/s som valts, etablerar tjänsten fler resurser för att stödja de högre maximala RU/s. Det här händer, men din befintliga arbetsbelastning och dina åtgärder påverkas inte. Systemet fortsätter att skala databasen eller containern mellan föregående 0.1-× Tmax och Tmax tills det nya skalningsintervallet 0,1 × Tmax_new är Tmax_new klart.

När du sänker det maximala ANTALET RU/s avrundas det minsta värde som du kan ange till MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10) till närmaste 1 000 RU/s.

Exempel #1: Du har en container för automatisk skalning som har högst 20 000 RU/s (skalar mellan 2 000 RU/s och 20 000 RU/s) och 1 500 GB lagringsutrymme. Det lägsta, lägsta värdet som du kan ange maximalt ANTAL RU/s till är MAX(1,000, 20,000 / 10, 1,500 × 10) = 15 000 RU/s (skalar mellan 1 500 RU/s och 15 000 RU/s).

Exempel 2: Du har en container för automatisk skalning som har högst 100 000 RU/s och 100 GB lagringsutrymme. Nu skalar du maximalt RU/s upp till 150 000 RU/s (skalar mellan 15 000 RU/s och 150 000 RU/s). Det lägsta, lägsta värdet som du nu kan ange maximalt ANTAL RU/s till är MAX(1,000, 150,000 / 10, 100 × 10) = 15 000 RU/s (skalar mellan 1 500 RU/s och 15 000 RU/s).

För en databas med delat dataflöde avrundas det minsta värde som du kan ange till MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000)) närmaste 1 000 RU/s när du sänker det maximala antalet RU/s.

Dessa formler och exempel gäller för den minsta autoskalning av maximala RU/s som du kan ange. De är separata från 0.1-× Tmax som Tmax systemet automatiskt skalar till. Oavsett maximal RU/s skalar systemet alltid mellan 0,1 × Tmax och Tmax.

Time to Live-åtgärder (TTL) påverkar inte skalningen av RU/s i autoskalning. Alla RU:er som förbrukas på grund av TTL ingår inte i fakturerade RU/s i autoskalningscontainern.

Till exempel för en autoskalningscontainer som har 400 RU/s till 4 000 RU/s:

• Timme 1: T=0: Containern har ingen användning (inga TTL- eller arbetsbelastningsbegäranden). Fakturerbara RU/s är 400 RU/s.
• Timme 1: T=1: TTL är aktiverat.
• Timme 1: T=2: Containern börjar hämta begäranden. Begäranden förbrukar 1 000 RU:er på 1 sekund. 200 RU:er för TTL används. Fakturerbara RU/s är fortfarande 1 000 RU/s. Oavsett när TTL-borttagningarna sker påverkar de inte logiken för automatisk skalning.

När du först väljer maximalt antal RU/s etablerar Azure Cosmos DB genom att dela upp maximalt ANTAL RU/s med 10 000 RU/s för att få det antal fysiska partitioner som krävs. Varje fysisk partition har stöd för upp till 10 000 RU/s och 50 GB lagringsutrymme. När lagringsstorleken ökar delar Azure Cosmos DB automatiskt partitioner för att lägga till fler fysiska partitioner för att hantera lagringsökningen. Om lagringen överskrider den associerade gränsen ökar Azure Cosmos DB maximalt antal RU/s.

Den maximala RU/s för databasen eller containern delas jämnt över alla fysiska partitioner. Det totala dataflöde som en enskild fysisk partition kan skala till är den maximala RU/s för databasen eller containern dividerat med antalet fysiska partitioner.

Om den totala förbrukade RU/s överskrider den maximala RU/s för databasen eller containern begränsas begäranden som överskrider maximalt antal RU/s och returnerar en kod 429-status. Begäranden som resulterar i mer än 100 procent normaliserad användning begränsas. Normaliserad användning definieras som maximal ru/s-användning för alla fysiska partitioner.

Ditt maximala dataflöde är till exempel 20 000 RU/s och du har två fysiska partitioner, P_1 och P_2. Varje partition kan skalas till 10 000 RU/s. Om P_1 har använt 6 000 RU:er och P_2 har använt 8 000 RU:er under en viss sekund är MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) den normaliserade användningen = 0,8.

Ja. Det går att se kod 429-fel i två scenarier.

Först, när den totala förbrukade RU/s överskrider den maximala RU/s för databasen eller containern, begränsar tjänsten begäranden i enlighet med detta.

För det andra, om ett värde för en logisk partitionsnyckel har ett oproportionerligt högre antal begäranden jämfört med andra partitionsnyckelvärden, som i en frekvent partition, kan den underliggande fysiska partitionen överskrida dess RU/s-budget. För att undvika partitioner med frekvent åtkomstnivå rekommenderar vi att du väljer en bra partitionsnyckel som resulterar i en jämn fördelning av både lagring och dataflöde.

Om du till exempel väljer alternativet 20 000 RU/s maximalt dataflöde och du har 200 GB lagringsutrymme kan varje fysisk partition skalas automatiskt upp till 5 000 RU/s om du har fyra fysiska partitioner. Om en frekvent partition finns på en specifik logisk partitionsnyckel visas kod 429-fel när den underliggande fysiska partitionen den finns i överskrider 5 000 RU/s eller 100 procent normaliserad användning.

Att se kod 429-fel när du använder autoskalning tyder inte nödvändigtvis på ett problem med databasen eller containern. Om mellan 1 och 5 procent av begäranden har kod 429-fel och svarstiden från slutpunkt till slutpunkt är acceptabel är felen vanligtvis ett fel som visar att RU/s används fullt ut. Ingen åtgärd krävs.

Lär dig hur du tolkar och felsöker fel med hastighetsbegränsning på 429.

Ja. Mer information finns i Övervaka normaliserade RU/s.

Nästa steg

• Lär dig hur du aktiverar autoskalning i en Azure Cosmos DB-databas eller container.
• Lär dig mer om fördelarna med etablerat dataflöde med hjälp av autoskalning.
• Läs mer om logiska och fysiska partitioner.