Optimera kostnaden för etablerat dataflöde i Azure Cosmos DB

GÄLLER FÖR: SQL API Cassandra API Gremlin API Table API Azure Cosmos DB API for MongoDB

Genom att erbjuda en etablerad dataflödesmodell erbjuder Azure Cosmos DB förutsägbara prestanda i valfri skala. Om du reserverar eller etablerar dataflöde i förväg eliminerar du den "brusande granneffekten" på prestandan. Du anger exakt hur mycket dataflöde du behöver och Azure Cosmos DB garanterar det konfigurerade dataflödet, som backas upp av serviceavtalet.

Du kan börja med ett minsta dataflöde på 400 RU/sek och skala upp till tiotals miljoner begäranden per sekund eller ännu mer. Varje begäran som du utfärdar mot din Azure Cosmos-container eller databas, till exempel en läsbegäran, skrivbegäran, frågebegäran, lagrade procedurer, har en motsvarande kostnad som dras av från ditt etablerade dataflöde. Om du etablerar 400 RU/s och utfärdar en fråga som kostar 40 RU:er kan du utfärda 10 sådana frågor per sekund. Alla begäranden utöver detta blir hastighetsbegränsade och du bör försöka begäran igen. Om du använder klientdrivrutiner stöder de logiken för automatiska återförsök.

Du kan etablera dataflöden för databaser och containrar, och de olika strategierna kan ge besparingar beroende på scenariot.

Optimera genom att etablera dataflöde på olika nivåer

  • Om du etablerar dataflöde i en databas kan alla containrar, till exempel samlingar/tabeller/grafer i databasen dela dataflödet baserat på belastningen. Dataflödet som är reserverat på databasnivå delas ojämnt, beroende på arbetsbelastningen på en specifik uppsättning containrar.

  • Om du etablerar dataflöde för en container garanteras dataflödet för containern, som backas upp av serviceavtalet. Valet av en logisk partitionsnyckel är avgörande för jämn belastningsfördelning över alla logiska partitioner i en container. Mer information finns i artiklar om partitionering och horisontell skalning .

Följande är några riktlinjer för att besluta om en etablerad dataflödesstrategi:

Överväg att etablera dataflöde i en Azure Cosmos-databas (som innehåller en uppsättning containrar) om:

  1. Du har några dussin Azure Cosmos-containrar och vill dela dataflöde över vissa eller alla av dem.

  2. Du migrerar från en databas med en enda klientorganisation som är utformad för att köras på virtuella IaaS-värddatorer eller lokalt, till exempel NoSQL eller relationsdatabaser till Azure Cosmos DB. Och om du har många samlingar/tabeller/grafer och inte vill göra några ändringar i datamodellen. Observera att du kan behöva kompromettera vissa av fördelarna med Azure Cosmos DB om du inte uppdaterar din datamodell när du migrerar från en lokal databas. Vi rekommenderar att du alltid omvärderar din datamodell så att den får ut mesta möjliga av prestanda och även optimerar för kostnader.

  3. Du vill absorbera oplanerade toppar i arbetsbelastningar på grund av pooldataflöde på databasnivå som utsätts för en oväntad topp i arbetsbelastningen.

  4. I stället för att ange specifikt dataflöde för enskilda containrar är du noga med att hämta det aggregerade dataflödet i en uppsättning containrar i databasen.

Överväg att etablera dataflöde för en enskild container om:

  1. Du har några Azure Cosmos-containrar. Eftersom Azure Cosmos DB är schemaoberoende kan en container innehålla objekt som har heterogena scheman och inte kräver att kunderna skapar flera containertyper, en för varje entitet. Det är alltid ett alternativ att överväga om gruppering av separata till exempel 10–20 containrar i en enda container är meningsfullt. Med minst 400 RU:er för containrar kan poolning av alla 10–20 containrar i en vara mer kostnadseffektiv.

  2. Du vill styra dataflödet för en specifik container och få garanterat dataflöde för en viss container som backas upp av serviceavtalet.

Överväg en hybrid av ovanstående två strategier:

  1. Som tidigare nämnts kan du med Azure Cosmos DB blanda och matcha ovanstående två strategier, så att du nu kan ha vissa containrar i Azure Cosmos-databasen, som kan dela dataflödet som etablerats på databasen samt vissa containrar i samma databas, som kan ha dedikerade mängder etablerat dataflöde.

  2. Du kan använda ovanstående strategier för att komma med en hybridkonfiguration, där du har både databasnivå etablerat dataflöde med vissa containrar som har dedikerat dataflöde.

Som du ser i följande tabell kan du, beroende på valet av API, etablera dataflöde med olika kornigheter.

API Konfigurera för delat dataflöde Konfigurera för dedikerat dataflöde
API för SQL Databas Container
API för Azure Cosmos DB för MongoDB Databas Samling
Cassandra-API Nyckelområde Tabell
Gremlin-API Databaskonto Graph
Tabell-API Databaskonto Tabell

Genom att etablera dataflöde på olika nivåer kan du optimera dina kostnader baserat på arbetsbelastningens egenskaper. Som tidigare nämnts kan du programmatiskt och när som helst öka eller minska ditt etablerade dataflöde för antingen enskilda containrar eller kollektivt över en uppsättning containrar. Genom att skala dataflödet elastiskt när arbetsbelastningen ändras betalar du bara för det dataflöde som du har konfigurerat. Om din container eller en uppsättning containrar distribueras över flera regioner kommer dataflödet som du konfigurerar för containern eller en uppsättning containrar garanterat att göras tillgängligt i alla regioner.

Optimera genom att hastighetsbegränsa dina förfrågningar

För arbetsbelastningar som inte är känsliga för svarstid kan du etablera mindre dataflöde och låta programmet hantera hastighetsbegränsning när det faktiska dataflödet överskrider det etablerade dataflödet. Servern avslutar begäran i förebyggande syfte med RequestRateTooLarge (HTTP-statuskod 429) och returnerar x-ms-retry-after-ms rubriken som anger hur lång tid, i millisekunder, som användaren måste vänta innan begäran görs på nytt.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Återförsökslogik i SDK:er

De interna SDK:erna (.NET/.NET Core, Java, Node.js och Python) fångar implicit det här svaret, respekterar det serverspecifika återförsökshuvudet och försöker igen. Såvida inte ditt konto används samtidigt av flera klienter kommer nästa återförsök att lyckas.

Om du har fler än en klient som kumulativt fungerar konsekvent över begärandefrekvensen kanske standardantalet för återförsök, som för närvarande är inställt på 9, inte räcker. I sådana fall genererar klienten en RequestRateTooLargeException med statuskod 429 till programmet. Standardantalet för återförsök kan ändras genom att ange RetryOptions på ConnectionPolicy-instansen. Som standard RequestRateTooLargeException returneras med statuskod 429 efter en kumulativ väntetid på 30 sekunder om begäran fortsätter att fungera över begärandefrekvensen. Detta inträffar även om det aktuella antalet återförsök är mindre än det maximala antalet återförsök, oavsett om det är standardvärdet 9 eller ett användardefinierat värde.

MaxRetryAttemptsOnThrottledRequests är inställt på 3, så i det här fallet, om en begärandeåtgärd begränsas genom att överskrida det reserverade dataflödet för containern, försöker begärandeåtgärden tre gånger innan undantaget skickas till programmet. MaxRetryWaitTimeInSeconds är inställt på 60, så i det här fallet om den kumulativa väntetiden för återförsök i sekunder sedan den första begäran överskrider 60 sekunder genereras undantaget.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Partitioneringsstrategi och kostnader för etablerat dataflöde

En bra partitioneringsstrategi är viktig för att optimera kostnaderna i Azure Cosmos DB. Se till att det inte finns någon snedställning av partitioner som exponeras via lagringsmått. Se till att det inte finns någon snedställning av dataflödet för en partition, som exponeras med dataflödesmått. Kontrollera att det inte finns någon skevhet mot vissa partitionsnycklar. Dominerande nycklar i lagringen exponeras via mått, men nyckeln är beroende av ditt programåtkomstmönster. Det är bäst att tänka på rätt logisk partitionsnyckel. En bra partitionsnyckel förväntas ha följande egenskaper:

  • Välj en partitionsnyckel som sprider arbetsbelastningen jämnt över alla partitioner och jämnt över tid. Med andra ord bör du inte ha några nycklar till med majoriteten av data och vissa nycklar med mindre eller inga data.

  • Välj en partitionsnyckel som gör att åtkomstmönster kan fördelas jämnt över logiska partitioner. Arbetsbelastningen är någorlunda jämn över alla nycklar. Med andra ord bör majoriteten av arbetsbelastningen inte fokusera på några specifika nycklar.

  • Välj en partitionsnyckel som har ett stort antal värden.

Den grundläggande idén är att sprida data och aktiviteten i containern över uppsättningen logiska partitioner, så att resurser för datalagring och dataflöde kan distribueras över de logiska partitionerna. Kandidater för partitionsnycklar kan innehålla de egenskaper som ofta visas som ett filter i dina frågor. Frågor kan dirigeras effektivt genom att du tar med partitionsnyckeln i filterpredikatet. Med en sådan partitioneringsstrategi blir det mycket enklare att optimera etablerat dataflöde.

Utforma mindre objekt för högre dataflöde

Kostnaden för begäran eller bearbetningskostnaden för en viss åtgärd korreleras direkt till objektets storlek. Åtgärder på stora objekt kostar mer än åtgärder på mindre objekt.

Dataåtkomstmönster

Det är alltid bra att logiskt separera dina data i logiska kategorier baserat på hur ofta du kommer åt data. Genom att kategorisera den som frekventa, medelstora eller kalla data kan du finjustera den förbrukade lagringen och det dataflöde som krävs. Beroende på åtkomstfrekvensen kan du placera data i separata containrar (till exempel tabeller, grafer och samlingar) och finjustera det etablerade dataflödet för dem så att de passar behoven för det datasegmentet.

Om du använder Azure Cosmos DB och vet att du inte kommer att söka efter vissa datavärden eller sällan kommer åt dem bör du lagra de komprimerade värdena för dessa attribut. Med den här metoden sparar du lagringsutrymme, indexutrymme och etablerat dataflöde och ger lägre kostnader.

Optimera genom att ändra indexeringsprincipen

Som standard indexerar Azure Cosmos DB automatiskt varje egenskap för varje post. Detta är avsett att underlätta utvecklingen och säkerställa utmärkta prestanda för många olika typer av ad hoc-frågor. Om du har stora poster med tusentals egenskaper kanske det inte är användbart att betala dataflödeskostnaden för indexering av varje egenskap, särskilt om du bara frågar mot 10 eller 20 av dessa egenskaper. När du kommer närmare att få grepp om din specifika arbetsbelastning är vår vägledning att justera indexpolicyn. Fullständig information om Azure Cosmos DB-indexeringsprincipen finns här.

Övervakning av etablerat och förbrukat dataflöde

Du kan övervaka det totala antalet etablerade RU:er, antalet frekvensbegränsade begäranden samt antalet RU:er som du har förbrukat i Azure Portal. Följande bild visar ett exempel på användningsstatistik:

Övervaka enheter för programbegäran i Azure Portal

Du kan också ange aviseringar för att kontrollera om antalet hastighetsbegränsade begäranden överskrider ett visst tröskelvärde. Mer information finns i artikeln Övervaka Azure Cosmos DB . Dessa aviseringar kan skicka ett e-postmeddelande till kontoadministratörerna eller anropa en anpassad HTTP Webhook eller en Azure-funktion för att automatiskt öka etablerat dataflöde.

Skala ditt dataflöde elastiskt och på begäran

Eftersom du debiteras för det etablerade dataflödet kan du undvika avgifterna för det oanvända dataflödet genom att matcha det etablerade dataflödet efter dina behov. Du kan skala upp eller ned ditt etablerade dataflöde när som helst efter behov. Om dina dataflödesbehov är mycket förutsägbara kan du använda Azure Functions och använda en timerutlösare för att öka eller minska dataflödet enligt ett schema.

  • Övervakning av förbrukningen av dina RU:er och förhållandet mellan frekvensbegränsade begäranden kan visa att du inte behöver behålla etableringen under konstant hela dagen eller veckan. Du kan få mindre trafik på natten eller under helgen. Genom att använda antingen Azure Portal eller Azure Cosmos DB-interna SDK:er eller REST API kan du skala ditt etablerade dataflöde när som helst. Azure Cosmos DB:s REST-API tillhandahåller slutpunkter för att programmatiskt uppdatera prestandanivån för dina containrar, vilket gör det enkelt att justera dataflödet från koden beroende på tid på dagen eller veckodagen. Åtgärden utförs utan driftstopp och börjar vanligtvis gälla på mindre än en minut.

  • Ett av de områden du bör skala dataflödet är när du matar in data i Azure Cosmos DB, till exempel under datamigrering. När du har slutfört migreringen kan du skala ned etablerat dataflöde för att hantera lösningens stabila tillstånd.

  • Kom ihåg att faktureringen är detaljerad på en timme, så du sparar inga pengar om du ändrar ditt etablerade dataflöde oftare än en timme i taget.

Fastställa vilket dataflöde som behövs för en ny arbetsbelastning

Om du vill fastställa det etablerade dataflödet för en ny arbetsbelastning kan du använda följande steg:

  1. Utför en inledande, grov utvärdering med hjälp av kapacitetsplaneraren och justera dina uppskattningar med hjälp av Azure Cosmos DB Explorer i Azure Portal.

  2. Vi rekommenderar att du skapar containrar med högre dataflöde än förväntat och sedan skalar ned efter behov.

  3. Vi rekommenderar att du använder en av de interna Azure Cosmos DB SDK:erna för att dra nytta av automatiska återförsök när begäranden får hastighetsbegränsad. Om du arbetar på en plattform som inte stöds och använder Cosmos DB:s REST-API implementerar du en egen återförsöksprincip med huvudet x-ms-retry-after-ms .

  4. Kontrollera att programkoden har stöd för ärendet när alla återförsök misslyckas.

  5. Du kan konfigurera aviseringar från Azure Portal för att få meddelanden om hastighetsbegränsning. Du kan börja med konservativa gränser som 10 frekvensbegränsade begäranden under de senaste 15 minuterna och växla till mer ivriga regler när du har listat ut din faktiska förbrukning. Tillfälliga hastighetsgränser är bra, de visar att du spelar med de gränser du har angett och det är precis vad du vill göra.

  6. Använd övervakning för att förstå ditt trafikmönster, så att du kan överväga behovet av att dynamiskt justera dataflödesetablering under dagen eller en vecka.

  7. Övervaka förhållandet mellan etablerat och förbrukat dataflöde regelbundet för att se till att du inte har etablerat fler än det antal containrar och databaser som krävs. Att ha lite över etablerat dataflöde är en bra säkerhetskontroll.

Metodtips för att optimera etablerat dataflöde

Följande steg hjälper dig att göra dina lösningar mycket skalbara och kostnadseffektiva när du använder Azure Cosmos DB.

  1. Om du har betydligt över etablerat dataflöde mellan containrar och databaser bör du granska RU:er som etablerats jämfört med förbrukade RU:er och finjustera arbetsbelastningarna.

  2. En metod för att beräkna mängden reserverat dataflöde som krävs av ditt program är att registrera ru-avgiften för begärandeenheten som är associerad med körning av typiska åtgärder mot en representativ Azure Cosmos-container eller databas som används av ditt program och sedan beräkna antalet åtgärder som du förväntar dig att utföra varje sekund. Se till att mäta och inkludera vanliga frågor och deras användning också. Information om hur du beräknar RU-kostnader för frågor programmatiskt eller med hjälp av portalen finns i Optimera kostnaden för frågor.

  3. Ett annat sätt att få åtgärder och deras kostnader i RU:er är genom att aktivera Azure Monitor-loggar, vilket ger dig en uppdelning av åtgärden/varaktigheten och begärandeavgiften. Azure Cosmos DB tillhandahåller en begärandeavgift för varje åtgärd, så att varje åtgärdsavgift kan lagras tillbaka från svaret och sedan användas för analys.

  4. Du kan skala upp och ned etablerat dataflöde elastiskt när du behöver hantera dina arbetsbelastningsbehov.

  5. Du kan lägga till och ta bort regioner som är associerade med ditt Azure Cosmos-konto när du behöver och kontrollera kostnaderna.

  6. Kontrollera att du har en jämn fördelning av data och arbetsbelastningar mellan logiska partitioner i dina containrar. Om du har en ojämn partitionsdistribution kan det leda till högre dataflöde än det värde som behövs. Om du upptäcker att du har en skev distribution rekommenderar vi att du omdistribuerar arbetsbelastningen jämnt över partitionerna eller partitionerar om data.

  7. Om du har många containrar och dessa containrar inte kräver serviceavtal kan du använda det databasbaserade erbjudandet för de fall där serviceavtalen för dataflöde per container inte gäller. Du bör identifiera vilka av de Azure Cosmos-containrar som du vill migrera till dataflödeserbjudandet på databasnivå och sedan migrera dem med hjälp av en ändringsflödesbaserad lösning.

  8. Överväg att använda den kostnadsfria Cosmos DB-nivån (kostnadsfri i ett år), Prova Cosmos DB (upp till tre regioner) eller nedladdningsbar Cosmos DB-emulator för utvecklings-/testscenarier. Genom att använda dessa alternativ för test-dev kan du avsevärt sänka dina kostnader.

  9. Du kan ytterligare utföra arbetsbelastningsspecifika kostnadsoptimeringar – till exempel öka batchstorleken, belastningsutjämningsläsningar i flera regioner och deduplicera data, om tillämpligt.

  10. Med reserverad Azure Cosmos DB-kapacitet kan du få betydande rabatter på upp till 65 % i tre år. Azure Cosmos DB reserved capacity model (Reserverad kapacitetsmodell för Azure Cosmos DB) är ett förskottsåtagande för enheter för begäranden som behövs över tid. Rabatterna är nivåindelade så att ju fler enheter för begäran du använder under en längre period, desto mer blir rabatten. Dessa rabatter tillämpas omedelbart. Alla RU:er som används ovanför dina etablerade värden debiteras baserat på kostnaden för icke-reserverad kapacitet. Mer information finns i Reserverad kapacitet för Cosmos DB). Överväg att köpa reserverad kapacitet för att ytterligare sänka dina etablerade dataflödeskostnader.

Nästa steg

Härnäst kan du fortsätta att lära dig mer om kostnadsoptimering i Azure Cosmos DB med följande artiklar: