Optimera kostnad för etablerat dataflöde i Azure Azure Azures DB

GÄLLER FÖR: SQL API Api Gremlin API Table API Azure Azure Db API för MongoDB

Genom att erbjuda en tillhandahållad dataflödesmodell tillhandahåller Azure Azure Azure Db förutsägbara prestanda i valfri skala. Att reservera eller etablera dataflöde i förväg eliminerar "bullrig intilliggande effekt" på prestandan. Du anger exakt hur mycket dataflöde du behöver och Azure Azure Azures DB garanterar det konfigurerade dataflödet, med stöd av SLA.

Du kan börja med ett minsta dataflöde på 400 RU/sek och skala upp till tio miljoner förfrågningar per sekund eller ännu mer. Varje begäran du utfärdar mot din Azure Azure Sås-behållare eller -databas, t.ex. en läsbegäran, en skrivbegäran, en frågeförfrågan, 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 RUs, kommer du att kunna utfärda 10 sådana frågor per sekund. Om det inte går att begära ytterligare en återbetalning kan du försöka igen. Om du använder klientdrivrutiner har de stöd för automatisk logik för försök igen.

Du kan tillhandahålla dataflöde för databaser eller behållare och varje strategi kan hjälpa dig att spara på kostnader beroende på scenariot.

Optimera genom att tillhandahålla dataflöde på olika nivåer

  • Om du etablerar dataflöde i en databas kan alla behållare, till exempel samlingar/tabeller/diagram i den databasen, dela dataflödet baserat på inläsningen. Dataflödet som är reserverat på databasnivån delas ojämnt, beroende på arbetsbelastningen för en viss uppsättning behållare.

  • Om du etablerar dataflöde för en behållare säkerställs dataflödet för behållaren, säkerhetskopierat av SLA. Valet av en logisk partitionsnyckel är avgörande för en jämn fördelning av belastningen över alla logiska partitioner i en behållare. Mer information finns i artiklarna om Partitioneringoch vågrät skalning.

Följande är några riktlinjer för att avgöra en strategi för etableringsflöde:

Överväg att etablera dataflöde på en Azure Azure Azure-databas (som innehåller en uppsättning behållare) om:

  1. Du har några dussintals Azure Azure-behållare och vill dela dataflöde mellan vissa eller alla.

  2. Du migrerar från en databas med en klientorganisation som är utformad för att köras på IaaS-värdbaserade virtuella maskiner eller lokalt, till exempel NoSQL eller relationsdatabaser till Azure Azure Azures DB. Och om du har många samlingar/tabeller/diagram och du inte vill göra några ändringar i datamodellen. Observera att du kanske måste kompromettera vissa av fördelarna som erbjuds av Azure Azure Azures DB om du inte uppdaterar din datamodell vid migrering från en lokal databas. Vi rekommenderar att du alltid sätter ihop din datamodell för att få ut mesta möjliga av prestandan och även för att optimera för kostnader.

  3. Du vill använda oplanerade belastningstoppar i arbetsbelastningar genom att skapa sammandelade dataflöden på databasnivå som oväntat ökar arbetsbelastningen.

  4. I stället för att ange specifikt dataflöde för enskilda behållare är det bra om du får det samlade dataflödet över en uppsättning behållare i databasen.

Överväg att etablera dataflöde för en enskild behållare om:

  1. Du har några Azure Azure Azure-behållare. Eftersom Azure Azure Azures DB är schema-agnostic kan en behållare innehålla objekt som har heterologiska scheman och inte kräver att kunderna skapar flera behållartyper, en för varje entitet. Det är alltid ett alternativ att överväga om det är vettigt att gruppera 10–20 behållare i en enda behållare. Med ett minimiantal på 400 behållare för behållare kan det bli kostnadseffektivt att samla alla 10–20 behållare i en behållare.

  2. Du vill kontrollera dataflödet för en viss behållare och få det garanterad dataflödet för en viss behållare genom SLA.

Överväg en hybrid av de två strategier som beskrivs ovan:

  1. Som vi nämnt tidigare kan du kombinera och matcha de båda strategierna i Azure Azure DB, så att du nu kan ha vissa behållare i Azure Azure Azure-databasen, som kan dela dataflödet som etablerats i databasen samt vissa behållare i samma databas, vilket kan ha dedikerade mängder etablerat dataflöde.

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

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

API För delat dataflöde konfigurerar du För dedikerat dataflöde konfigurerar du
SQL API Databas Behållare
Azure Azure Azure DB:s API för MongoDB Databas Samling
Andra API Tangentområ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å egenskaperna för din arbetsbelastning. Som vi nämnt tidigare kan du programmässigt och när som helst öka eller minska ditt etablerade dataflöde för antingen enskilda behållare eller gemensamt över en uppsättning behållare. Genom att flexibelt skala dataflödet när arbetsbelastningen ändras betalar du bara för det dataflöde som du har konfigurerat. Om behållaren eller en uppsättning behållare är fördelad över flera områden säkerställs det dataflöde som du konfigurerar i behållaren eller en uppsättning behållare i alla regioner.

Optimera med rate-limiting dina begäranden

För arbetsbelastningar som inte är känsliga för fördröjning kan du tillhandahålla mindre genomflöde och låta programmet hantera hastighetsbegränsningar när det faktiska dataflödet överskrider det etablerade dataflödet. Servern avslutar i förebyggande syfte begäran med RequestRateTooLarge (HTTP-statuskod 429) och returnerar rubriken som anger hur lång tid, i millisekunder, som användaren måste vänta innan han eller hon försöker x-ms-retry-after-ms igen.

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

Försök igen-logik i SDKs

Ursprungliga SDKs (.NET/.NET Core, Java, Node.js och Python) fångar implicit upp det här svaret, respekterar det server angivna försök efter huvudet och försöker sedan igen. Om ditt konto inte används samtidigt av flera klienter lyckas nästa försök.

Om du har fler än en klient som har samma kumulativa operativsystem än begäranderäntan, kanske standardantalet för åter försök, som för närvarande är inställt på 9, inte är tillräckligt. I sådana fall ger klienten RequestRateTooLargeException statuskoden 429 i programmet. Standardantalet för försök kan ändras genom att ange RetryOptions i ConnectionPolicy-instansen. Som standard returneras statuskoden 429 efter en kumulativ väntetid på 30 sekunder om begäran fortsätter fungera över RequestRateTooLargeException begärans ränta. Detta inträffar även när det aktuella antalet försök är mindre än det maximala antalet försök igen, a sig det är standardvärdet på 9 eller ett användardefinierat värde.

MaxRetryAttemptsOnThrottledRequests är inställt på 3, så om en åtgärd för begäran i det här fallet är ett pris begränsat genom att överskrida det reserverade dataflödet för behållaren så görs åtgärden igen tre gånger innan undantag från programmet fastställs. MaxRetryWaitTimeInSeconds är inställt på 60, så om det kumulativa försök att vänta i sekunder sedan den första begäran överskrider 60 sekunder är undantaget undantaget.

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

Kostnader för partitionsstrategi och etablering av dataflöde

En bra partitionsstrategi är viktigt för att optimera kostnader i Azure Azure AzureS DB. Se till att det inte finns några sneda partitioner, som exponeras genom lagringsmått. Se till att det inte finns någon sned fördelning för en partition som exponeras med genomflödesmått. Se till att det inte finns några snedare mot vissa partitionsnycklar. Dominanta nycklar i lagring exponeras genom mätvärden, men nyckeln kommer att vara 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 fördelar 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 alla data och vissa nycklar med färre eller inga data.

  • Välj en partitionsnyckel som gör att åtkomstmönster fördelas jämnt över logiska partitioner. Arbetsbelastningen gäller till och med i alla nycklar. Med andra ord ska inte majoriteten av arbetsbelastningen fokusera på några specifika nycklar.

  • Välj en partitionsnyckel som har en mängd olika värden.

Den grundläggande idén är att sprida data och aktivitet i behållaren över de logiska partitionerna, så att resurser för datalagring och dataflöde kan fördelas över de logiska partitionerna. Kandidater för partitionsnycklar kan innehålla egenskaper som ofta förekommer som ett filter i dina frågor. Frågor kan dirigeras effektivt genom att partitionsnyckeln tas med i filtrets predikat. Med en sådan partitionsstrategi blir det mycket enklare att optimera det etablerade dataflödet.

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

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

Dataåtkomstmönster

Det är alltid bra att logiskt dela upp dina data i logiska kategorier baserat på hur ofta du får åtkomst till data. Genom att kategorisera dem som snabbdata, medelhöga eller kalla data kan du finjustera hur mycket lagringsutrymme som används och vilket dataflöde som krävs. Beroende på hur ofta åtkomsten är kan du placera data i separata behållare (till exempel tabeller, diagram och samlingar) och finjustera det etablerade dataflödet efter dem så att de tillgodoser behoven i det datasegmentet.

Om du använder Azure Han/hon, och vet att du inte kommer att söka efter vissa datavärden eller sällan kommer att använda dem, bör du dessutom lagra de komprimerade värdena för de attributen. Med den här metoden sparar du lagringsutrymme, indexutrymme och etablerat dataflöde och ger lägre kostnader.

Optimera genom att ändra indexeringsprincip

Som standard indexeras varje egenskap för varje post automatiskt i Azure Azure DB. Detta är avsett för att underlätta utvecklingen och säkerställa utmärkt 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ödets kostnad för att indexera varje egenskap, särskilt om du bara frågar mot 10 eller 20 av dessa egenskaper. När du börjar hantera din specifika arbetsbelastning är vår vägledning att anpassa indexpolicyn. Fullständig information om Azure Azure Azures DB-indexeringspolicy finns här.

Övervaka etablerat och förbrukat dataflöde

Du kan övervaka det totala antalet företag som tillhandahålls, antal prisbegränsade begäranden och antalet RUs du har förbrukat i Azure-portalen. Följande bild visar ett exempel på användningsmått:

Monitor request units in the Azure portal

Du kan också ange aviseringar för att kontrollera om antalet begränsade förfrågningar överskrider ett visst tröskelvärde. Mer information finns i Artikeln Om hur du övervakar Azure Azures 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 det etablerade dataflödet.

Skala dataflödets elasticitet och på begäran

Eftersom du faktureras för dataflödet som etablerats kan du genom att matcha det etablerade dataflödet med dina behov undvika kostnader för oanvända dataflöde. Du kan skala ditt etablerade dataflöde uppåt eller nedåt när som helst efter behov. Om dina dataflödesbehov är mycket förutsägbara kan du använda Azure-funktioner och använda en timerutlösare för att öka eller minska dataflödet i ett schema.

  • Övervaka användningen av dina beständiga användnings- och förhållandet mellan ratebegränsade begäranden och visa att du inte behöver hålla konstant under hela dagen eller veckan. Eventuellt får du mindre trafik på natten eller under helgen. Genom att använda antingen Azure Portal eller Azure Azure Azure Dbs som ursprungliga SDKs eller REST API kan du skala ditt etablerade dataflöde när som helst. Azure Azure Azure Dbs REST API tillhandahåller slutpunkter för programmässigt uppdatering av behållares prestandanivå, vilket gör det enkelt att justera dataflödet från koden beroende på tid på dagen eller dagen i veckan. Åtgärden utförs utan avbrott och fungerar normalt på mindre än en minut.

  • Ett av områdena som du ska skala genomflöde är när du matar in data i Azure Azure Azures DB, till exempel under datamigrering. När du har slutfört migreringen kan du skala det etablerade dataflödet nedåt för att hantera lösningens stadiga tillstånd.

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

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

Så här fastställer du det etablerade dataflödet för en ny arbetsbelastning:

  1. Gör en första, ungefärlig utvärdering med hjälp av kapacitetsplaneringen och justera dina uppskattningar med hjälp av Azure Azure Azures DB Explorer i Azure-portalen.

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

  3. Vi rekommenderar att du använder någon av de inbyggda AZURE AzureS DB-SDKs för att dra nytta av automatiska uppdateringar när förfrågningar får en begränsad ränta. Om du arbetar på en plattform som inte stöds och använder Dbs REST API implementerar du din egen princip för åter försök med x-ms-retry-after-ms sidhuvudet.

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

  5. Du kan konfigurera aviseringar från Azure Portal för att få aviseringar om prisbegränsning. Du kan börja med den mest gällande begränsningarna, t.ex. 10 prisbegränsade förfrågningar under de senaste 15 minuterna, och byta till mer efterfrågade regler när du tar reda på din faktiska förbrukning. Tillfälliga prisbegränsningar är bra, de visar att du håller på att spela upp de gränser du har angett och det är exakt vad du vill göra.

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

  7. Övervaka ditt provisionerade och använda dataflödeskvot regelbundet för att kontrollera att du inte har etablerat fler än nödvändigt antal behållare och databaser. 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 Azure AzureS DB.

  1. Om du har avsevärt mer än etablerat dataflöde mellan behållare och databaser bör du granska använda och finjustera arbetsbelastningen genom att granska använda och finjustera arbetsbelastningen.

  2. En metod för att uppskatta mängden reserverat dataflöde som krävs av programmet är att registrera den begärande enhet RU-debitering som är kopplad till att köra vanliga åtgärder mot en representativ Azure Azure Azure-behållare eller databas som används av programmet och sedan uppskatta antalet åtgärder du räknar med att utföra varje sekund. Se till att mäta och inkludera vanliga frågor och deras användning också. Mer information om hur du uppskattar ru-kostnader för frågor programmässigt eller med hjälp av portalen finns i Optimera kostnaden för frågor.

  3. Ett annat sätt att få drift och deras kostnader i RUs är att aktivera Azure Monitor-loggar, vilket ger dig detaljerad information om operation/varaktighet och begärandedekostnaden. Azure Azure Azures DB begär en debitering för varje åtgärd, så varje åtgärdsavgift kan lagras tillbaka från svaret och sedan användas för analys.

  4. Du kan skala upp och ned det etablerade dataflödet via ett flexibelt sätt allt eftersom du behöver anpassa arbetsbelastningen.

  5. Du kan lägga till och ta bort regioner som är kopplade till ditt Azure Azure Azure-konto efter behov och kontrollera kostnader.

  6. Kontrollera att du har en jämn fördelning av data och arbetsbelastningar över logiska partitioner av behållare. Om du har en ojämn partitionsdistribution kan det leda till ett högre genomflöde än det värde som behövs. Om du ser att du har en sned fördelning rekommenderar vi att arbetsbelastningen fördelas jämnt mellan partitionerna eller partitionerna.

  7. Om du har många behållare och de här behållarna inte kräver SLA:er kan du använda det databasbaserade erbjudandet för de fall där dataflödet per behållare inte gäller. Du bör identifiera vilka Azure Azure-behållare som du vill migrera till erbjudandet om dataflöde på databasnivå och sedan migrera dem med hjälp av en feedbaserad lösning för ändringar.

  8. Överväg att använda "Grupps DB Free Tier" (kostnadsfritt i ett år), Prova På db (upp till tre regioner) eller nedladdningsbara Db emulatorer för utvecklings-/testscenarier. Genom att använda de här alternativen för testavvikelse kan du avsevärt sänka kostnaderna.

  9. Du kan fortsätta att utföra arbetsspecifika kostnadsoptimeringar – till exempel öka batchstorleken, belastningsutjämning i flera regioner och avkoda data, om tillämpligt.

  10. Med azure Azure Azures DB reserverad kapacitet kan du få betydande rabatter på upp till 65 % under tre år. Azure Azure Azures DB-reserverad kapacitetsmodell är ett initialt åtagande när det gäller förfrågningar om enheter som behövs över tid. Rabatterna är nivåerade så att ju fler begärsenheter du använder under en längre period, desto mer rabatt blir den. Rabatterna tillämpas omedelbart. Eventuella RUs som används ovanför dina provisionerade värden debiteras baserat på den icke-reserverade kapacitetskostnaden. Mer information finns i Db-reserveradkapacitet i Det här finns mer information. Överväg reserverad inköpskapacitet för att ytterligare sänka kostnaderna för etableringsflöde.

Nästa steg

Nu kan du gå vidare och lära dig mer om kostnadsoptimering i Azure Azure Azures DB med följande artiklar: