Skapa Azure Cosmos DB-containrar och databaser med autoskalningsdataflöde
GÄLLER FÖR: 
NoSQL MongoDB Kassandra Gremlin Bord
I Azure Cosmos DB kan du konfigurera antingen standarddataflöde (manuell) eller autoskalning för dina databaser och containrar. Med autoskalning av etablerat dataflöde i Azure Cosmos DB kan du skala dataflödet (RU/s) för databasen eller containern automatiskt och omedelbart.
Autoskalning av etablerat dataflöde passar bra för verksamhetskritiska arbetsbelastningar som har varierande eller oförutsägbara trafikmönster och kräver serviceavtal med höga prestanda och skala. Autoskalning skalar som standard arbetsbelastningar baserat på den mest aktiva regionen och partitionen. För icke-uniforma arbetsbelastningar som har olika arbetsbelastningsmönster mellan regioner och partitioner kan den här skalningen orsaka onödiga uppskalningar. Dynamisk skalning eller dynamisk autoskalning är en förbättring av autoskalning som etableras i hela skalan som hjälper till att skala sådana icke-uniforma arbetsbelastningar oberoende av användning, per region och partitionsnivå. Med dynamisk skalning kan du spara kostnader om du ofta upplever frekventa partitioner och/eller har flera regioner.
Fördelar med autoskalning
Azure Cosmos DB-databaser och containrar som har konfigurerats med autoskalningsetablerad dataflöde har följande fördelar:
Enkelt: Autoskalning tar bort komplexiteten i att hantera RU/s med anpassade skript eller manuellt skala kapacitet.
Skalbar: Databaser och containrar skalar automatiskt det etablerade dataflödet efter behov. Klientanslutningar, program eller Azure Cosmos DB-serviceavtal störs inte.
Kostnadseffektiv: Autoskalning hjälper dig att optimera din RU/s-användning och kostnadsanvändning genom att skala ned när den inte används. Du betalar bara för de resurser som dina arbetsbelastningar behöver per timme. Om du anger max RU/s (Tmax) för automatisk skalning och använder hela Tmax för 66 % av timmarna eller mindre kan du spara med autoskalning av alla timmar under en månad. Förutom dynamisk skalning är det mer kostnadseffektivt att lägga till en sekundär region för hög tillgänglighet eftersom varje region och partition skalar oberoende av den faktiska användningen. Mer information finns i artikeln om hur du väljer mellan standard (manuell) och autoskalning av etablerat dataflöde .
Hög tillgänglighet: Databaser och containrar som använder autoskalning använder samma globalt distribuerade, feltoleranta Azure Cosmos DB-serverdel med hög tillgänglighet för att säkerställa datahållbarhet och hög tillgänglighet.
Användningsfall för autoskalning
Användningsfallen för autoskalning är:
Varierande eller oförutsägbara arbetsbelastningar: När dina arbetsbelastningar har varierande eller oförutsägbara toppar i användningen hjälper autoskalning till genom att automatiskt skala upp och ned baserat på användning. Exempel är detaljhandelswebbplatser som har olika trafikmönster beroende på säsongsvariation; IOT-arbetsbelastningar som har toppar vid olika tidpunkter under dagen. verksamhetsprogram som ser den högsta användningen några gånger per månad eller år med mera. Med autoskalning behöver du inte längre etablera manuellt för toppkapacitet eller genomsnittlig kapacitet.
Nya program: Om du utvecklar ett nytt program och inte är säker på vilket dataflöde (RU/s) du behöver, gör autoskalning det enkelt att komma igång. Du kan börja med startpunkten för autoskalning på 100–1 000 RU/s, övervaka din användning och fastställa rätt RU/s över tid.
Program som används sällan: Om du har ett program, som endast används några timmar flera gånger per dag, vecka eller månad, till exempel ett program med låg volym/webb-/bloggwebbplats. Autoskalning justerar kapaciteten för att hantera den högsta användningen och skalas ned när den är över.
Utvecklings- och testarbetsbelastningar: Om du eller ditt team använder Azure Cosmos DB-databaser och containrar under arbetstid, men inte behöver dem på nätter eller helger, sparar autoskalning kostnaderna genom att skala ned till ett minimum när de inte används.
Schemalagda produktionsarbetsbelastningar/frågor: Om du har en serie schemalagda begäranden, åtgärder eller frågor som du vill köra under inaktiva perioder kan du enkelt göra det med autoskalning. När du behöver köra arbetsbelastningen skalas dataflödet automatiskt till det värde som behövs och skalas ned efteråt.
Att skapa en anpassad lösning på dessa problem kräver inte bara mycket tid, utan även komplexitet i programmets konfiguration eller kod. Autoskalning aktiverar ovanstående scenarier och tar bort behovet av anpassad eller manuell skalning av kapaciteten.
Användningsfall för dynamisk skalning
Användningsfallen för dynamisk skalning är:
- Databasarbetsbelastningar som har en mycket trafikerad primär region och en sekundär passiv region för haveriberedskap.
- Med dynamisk skalning är det mer kostnadseffektivt att uppnå hög tillgänglighet med flera regioner. Den sekundära regionen skalas separat och skalas automatiskt ned när den är inaktiv. Den sekundära regionen skalas också automatiskt upp när den blir aktiv och vid hantering av skrivreplikeringstrafik från den primära regionen.
- Databasarbetsbelastningar i flera regioner.
- Dessa arbetsbelastningar observerar ofta ojämn fördelning av begäranden mellan regioner på grund av naturlig trafiktillväxt och dalar under dagen. En databas kan till exempel vara aktiv under kontorstid i globalt distribuerade tidszoner.
Så här fungerar autoskalning av etablerat dataflöde
När du konfigurerar containrar och databaser med autoskalning anger du det maximala dataflöde Tmax som krävs. Azure Cosmos DB skalar dataflödet T , till exempel 0.1*Tmax <= T <= Tmax. Om du till exempel anger maximalt dataflöde till 20 000 RU/s skalas dataflödet mellan 2 000 och 20 000 RU/s. Eftersom skalning är automatisk och omedelbar kan du när som helst använda upp till den etablerade Tmax utan fördröjning.
Varje timme debiteras du för det högsta dataflödet T som systemet skalas till inom en timme. När dynamisk skalning är aktiverat baseras skalning på RU/s-användningen vid varje fysisk partition och region. Eftersom varje partition och region skalas separat kan detta leda till kostnadsbesparingar för icke-enhetliga arbetsbelastningar, eftersom onödiga uppskalningar undviks.
Startpunkten för maximalt dataflöde Tmax för autoskalning börjar vid 1 000 RU/s, vilket skalar mellan 100 och 1 000 RU/s. Du kan ange Tmax i steg om 1 000 RU/s och ändra värdet när som helst.
Om vi till exempel har en samling med 1 000 RU/s och 2 partitioner kan varje partition gå upp till 500 RU/s. För en timmes aktivitet skulle användningen se ut så här:
| Region | Partition | Genomflöde | Utnyttjande | Kommentar |
|---|---|---|---|---|
| Skriva | P1 | <= 500 RU/s | 100 % | 500 RU/s bestående av 50 RU/s som används för skrivåtgärder och 450 RU/s för läsåtgärder. |
| Skriva | P2 | <= 200 RU/s | 40 % | 200 RU/s som består av alla läsåtgärder. |
| Lästa | P1 | <= 150 RU/s | 30 % | 150 RU/s som består av 50 RU/s som används för skrivningar som replikeras från skrivregionen. 100 RU/s används för läsåtgärder i den här regionen. |
| Lästa | P2 | <= 50 RU/s | 10 % |
Utan dynamisk skalning skalas alla partitioner jämnt baserat på den hetaste partitionen. I det här exemplet, eftersom den hetaste partitionen hade 100 % användning, skalas alla partitioner i både skriv- och läsregionerna till 1 000 RU/s, vilket gör att den totala RU/s skalas till 2 000 RU/s.
Med dynamisk skalning, eftersom varje partition och regions dataflöde skalas oberoende av varandra, skulle den totala RU/s skalas till 900 RU/s, vilket bättre återspeglar det faktiska trafikmönstret och sänker kostnaderna.
Aktivera autoskalning för befintliga resurser
Använd Azure Portal, CLI eller PowerShell för att aktivera autoskalning på en befintlig databas eller container. Du kan växla mellan autoskalning och standard (manuellt) etablerat dataflöde när som helst. Mer information finns i den här dokumentationen för mer information.
Dataflödes- och lagringsgränser för autoskalning
För valfritt värde kan Tmaxdatabasen eller containern lagra totalt 0.1 * Tmax GB. När den här mängden lagringsutrymme har uppnåtts ökas maximalt antal RU/s automatiskt baserat på det nya lagringsvärdet, utan att det påverkar programmet.
Om du till exempel börjar med maximalt RU/s på 50 000 RU/s (skalar mellan 5 000 och 50 000 RU/s) kan du lagra upp till 5 000 GB data. Om du överskrider 5 000 GB , till exempel om lagringen nu är 6 000 GB, blir den nya maximala RU/s 60 000 RU/s (skalar mellan 6 000 och 60 000 RU/s).
När du använder dataflöde på databasnivå med autoskalning kan du låta de första 25 containrarna dela ett maximalt RU/s för autoskalning på 1 000 (skalar mellan 100 och 1 000 RU/s) så länge du inte överskrider 100 GB lagringsutrymme. Mer information finns i den här dokumentationen.
Aktivera dynamisk skalning
Dynamisk skalning är aktiverat som standard för alla Azure Cosmos DB-konton som skapats efter den 25 september 2024. Kunder som vill aktivera den här funktionen för sina äldre konton kan göra det programmatiskt via Azure PowerShell/CLI/Rest API eller från funktionsfönstret i Azure Portal enligt följande:
Gå till ditt Azure Cosmos DB-konto i Azure Portal.
Gå till sidan Funktioner .
Leta upp och aktivera funktionen Dynamisk skalning (per region och autoskalning per partition).
Viktigt!
Funktionen är aktiverad på kontonivå, så alla containrar med automatisk skalning och databaser för delat dataflöde i kontot kommer automatiskt att ha den här funktionen tillämpad. Aktivering av den här funktionen påverkar inte resurser i kontot som använder manuellt dataflöde. Manuella resurser måste ändras till autoskalning för att dra nytta av dynamisk skalning. Aktivering av den här funktionen har noll avbrottstid eller prestandapåverkan. Den här funktionen gäller inte för serverlösa konton.
Övervaka mått
Du kan använda följande mått för att övervaka autoskalning och dynamisk skalning:
| Måttnamn | Definition | Måttanvändning |
|---|---|---|
| Etablerat dataflöde | Visar den aggregerade högsta RU/s som skalats till under timmen och representerar det totala antalet RU/s som skalats till för timmen. | Du kan använda måttet Provisioned Throughput för att se ru/s som du debiteras för varje timme. Med autoskalning debiteras du baserat på den mest aktiva partitionen för varje timme och samma tillämpas på alla partitioner och regioner. Med dynamisk autoskalning debiteras du för den aggregerade högsta RU/s som skalas till i varje timme på varje partitions- och regionnivå. |
| Normaliserad RU-förbrukning | Det här måttet representerar förhållandet mellan förbrukade RU/s och etablerade RU/s på varje partitions- och regionnivå. | Använd det här måttet för att avgöra om det maximala dataflödet för autoskalning är under eller överetablerade. Om måttvärdet är konsekvent 100 % och programmet ser hastighetsbegränsning (429 felkod) kan du behöva fler RU/s. Om det här måttvärdet däremot är lågt och det inte finns någon hastighetsbegränsning kan det finnas utrymme för att optimera och skala ned RU/s. Lär dig hur du tolkar och felsöker fel med hastighetsbegränsning på 429. Måttet Normalized RU Consumption återspeglar ru/s som förbrukas i den sekundära regionen på grund av skrivreplikeringstrafik från den primära, utöver all lästrafik på den sekundära. |
| Autoskalad RU | Visar dynamiskt skalat etablerat dataflöde på varje partitions- och regionnivå endast för konton med dynamisk autoskalning. | Använd det här måttet för att se hur partitioner i varje region skalas oberoende baserat på deras användning. Använd Azure Monitor-mått - Autoscaled RU för att analysera hur den nya autoskalningen tillämpas mellan partitioner och regioner. Filtrera efter önskat databaskonto och din container och filtrera eller dela sedan efter måttet Fysiskt PartitionID. Det här måttet visar alla partitioner i olika regioner. |
Jämförelse – containrar som konfigurerats med manuellt dataflöde jämfört med autoskalning
Mer information finns i den här dokumentationen om hur du väljer mellan standarddataflöde (manuell) och autoskalning.
| Containrar med standarddataflöde (manuellt) | Containrar med autoskalningsdataflöde | |
|---|---|---|
| Etablerat dataflöde (RU/s) | Manuellt etablerad. | Skalas automatiskt och omedelbart baserat på arbetsbelastningens användningsmönster. |
| Hastighetsbegränsning för begäranden/åtgärder (429) | Kan inträffa om förbrukningen överskrider etablerad kapacitet. | Inträffar inte om du använder RU/s inom det autoskalningsdataflödesintervall som har konfigurerats. |
| Kapacitetsplanering | Du måste göra kapacitetsplanering och ange exakt det dataflöde du behöver. | Systemet tar automatiskt hand om kapacitetsplanering och kapacitetshantering. |
| Prissättning | Du betalar för manuellt etablerade RU/s per timme med standardpriset (manuella) RU/s per timme. | Du betalar per timme för de högsta RU/s som systemet skalas upp till inom en timme. För konton med en enda skrivningsregion betalar du för de RU/s som används per timme, med hjälp av autoskalning av RU/s per timme. För konton med flera skrivregioner debiteras ingen extra kostnad för autoskalning. Du betalar för det dataflöde som används per timme med samma ru/s för skrivningar i flera regioner per timme. |
| Passar bäst för arbetsbelastningstyper | Förutsägbara och stabila arbetsbelastningar | Oförutsägbara och variabla arbetsbelastningar |
Migrera standardetablerat dataflöde till autoskalning
Användare som vill migrera ett stort antal resurser från standardetablerat dataflöde till autoskalning kan använda ett Azure CLI-skript för att migrera varje dataflödesresurs i en Azure-prenumeration till autoskalning. Mer information finns i Konvertera till autoskalning.
Nästa steg
- Läs vanliga frågor och svar om autoskalning.
- Lär dig hur du väljer mellan manuellt dataflöde och autoskalningsdataflöde.
- Lär dig hur du etablerar autoskalningsdataflöde i en Azure Cosmos DB-databas eller container.
- Läs mer om partitionering i Azure Cosmos DB.
- Försöker du planera kapacitet för en migrering till Azure Cosmos DB? Du kan använda information om ditt befintliga databaskluster för kapacitetsplanering.
- Om allt du vet är antalet virtuella kärnor och servrar i ditt befintliga databaskluster läser du om att uppskatta enheter för begäranden med virtuella kärnor eller virtuella kärnor
- Om du känner till vanliga begärandefrekvenser för din aktuella databasarbetsbelastning kan du läsa om att uppskatta enheter för begäranden med azure Cosmos DB-kapacitetshanteraren