Optimera ditt Azure Cosmos DB med hastighetsbegränsning

Den här artikeln ger utvecklare en metod för att frekvensbegränsa begäranden till Azure Cosmos DB. Implementering av det här mönstret kan minska fel och förbättra övergripande prestanda för arbetsbelastningar som överskrider det etablerade dataflödet för måldatabasen eller containern.

Begäranden som överskrider det etablerade dataflödet i Azure Cosmos DB kan resultera i tillfälliga fel som TooManyRequests, Timeoutoch ServiceUnavailable. Normalt gör du nya försök med dessa begäranden när kapaciteten är tillgänglig och lyckas. Den här metoden kan dock resultera i ett stort antal begäranden som följer felsökvägen i koden och resulterar vanligtvis i ett minskat dataflöde.

Optimala systemprestanda, mätt efter kostnad och tid, kan uppnås genom att matcha arbetsbelastningstrafiken på klientsidan med det etablerade dataflödet på serversidan.

Föreställ dig följande scenario:

  • Du etablerar Azure Cosmos DB med 20 K RU/sekund.
  • Programmet bearbetar ett inmatningsjobb som innehåller 10 000 poster, var och en kostar 10 RU. Den totala kapaciteten som krävs för att slutföra det här jobbet är 100 K RU.
  • Om du skickar hela jobbet till Azure Cosmos DB bör du förvänta dig ett stort antal tillfälliga fel och en stor buffert med begäranden som du måste försöka igen. Det här villkoret beror på att det totala antalet RU:er som behövs för jobbet (100 K) är mycket större än det etablerade maxantalet (20 K). ~2 K av posterna kommer att godkännas i databasen, men ~8 K kommer att avvisas. Du skickar ~8 K poster till Azure Cosmos DB vid återförsök, varav ~2 K godkänns och så vidare. Du kan förvänta dig att det här mönstret skulle skicka ~30 000 poster i stället för 10 000 poster.
  • Om du i stället skickar dessa begäranden jämnt över 5 sekunder bör du inte förvänta dig några fel och totalt snabbare dataflöde eftersom varje batch skulle vara vid eller under de etablerade 20 K.

Du kan sprida begäranden över en viss tidsperiod genom att införa en frekvensbegränsningsmekanism i koden.

RU:erna som etableras för en container delas jämnt över antalet fysiska partitioner. I exemplet ovan, om Azure Cosmos DB etablerade två fysiska partitioner, skulle var och en ha 10 K RU.

Mer information om enheter för begäran finns i Enheter för förfrågning i Azure Cosmos DB . Mer information om att uppskatta antalet ENHETER för programbegäran som förbrukas av din arbetsbelastning finns i Överväganden för enhet för programbegäran. Mer information om partitionering Azure Cosmos DB finns i Partitionering och horisontell skalning i Azure Cosmos DB.

Metodik

En metod för att implementera hastighetsbegränsning kan se ut så här:

  1. Profilera programmet så att du har data om skrivningar och läsförfrågningar som används.
  2. Definiera alla index.
  3. Fyll i samlingen med en rimlig mängd data (kan vara exempeldata). Om du förväntar dig att ditt program normalt har miljontals poster fyller du det med miljontals poster.
  4. Skriv dina representativa dokument och registrera RU-kostnaden.
  5. Kör dina representativa frågor och registrera RU-kostnaden.
  6. Implementera en funktion i ditt program för att fastställa kostnaden för en viss begäran baserat på dina resultat.
  7. Implementera en hastighetsbegränsningsmekanism i koden för att säkerställa att summan av alla åtgärder som skickas till Azure Cosmos DB en sekund inte överskrider det etablerade dataflödet.
  8. Belastningstesta programmet och kontrollera att du inte överskrider det etablerade dataflödet.
  9. Testa RU-kostnaderna regelbundet igen och uppdatera kostnadsfunktionen efter behov.

Indexering

Till skillnad från andra SQL- och NoSQL-databaser som du kanske är bekant med indexerar Azure Cosmos DB standardindexeringsprincip för nyligen skapade containrar varje egenskap. Varje indexerad egenskap ökar RU-kostnaden för skrivningar.

Standardprincipen för indexering kan ge kortare svarstider i lästunga system där frågefiltervillkor är väl fördelade över alla lagrade fält. Till exempel kan system där Azure Cosmos DB mest av sin tid betjänar slutanvändarens utformade ad hoc-sökningar.

Du kanske vill undanta egenskaper som aldrig genomsöks mot från att indexeras. Att ta bort egenskaper från indexet kan förbättra systemets övergripande prestanda (kostnad och tid) för system som är skrivtunga och mönster för posthämtning är mer begränsade.

Innan du mäter kostnader bör du avsiktligt konfigurera en lämplig indexprincip för dina användningsfall. Om du senare ändrar index måste du också köra alla kostnadsberäkningar igen.

När det är möjligt kan du genom att testa ett system som är under utveckling med en belastning som återspeglar vanliga frågor vid normala och högsta behovsförhållanden visa vilken indexeringsprincip som ska användas.

Mer information om index finns i Indexeringsprinciper i Azure Cosmos DB.

Mäta kostnader

Det finns några viktiga begrepp när du mäter kostnader:

  • Överväg alla faktorer som påverkar RU-användningen, enligt beskrivningen i överväganden för begärandeenhet.
  • Alla läsningar och skrivningar i databasen eller containern delar samma etablerade dataflöde.
  • RU-förbrukning uppstår oavsett vilken Azure Cosmos DB API:er som används.
  • Partitionsstrategin för en samling kan ha en betydande inverkan på kostnaden för ett system. Mer information finns i Partitionering och horisontell skalning i Azure Cosmos DB.
  • Använd representativa dokument och representativa frågor.
    • Det här är dokument och frågor som du tror ligger nära det operativa systemet.
    • Det bästa sättet att hämta dessa representativa dokument och frågor är att instrumentera användningen av ditt program. Det är alltid bättre att fatta ett datadrivet beslut.
  • Mät kostnader regelbundet.
    • Indexändringar, storleken på index kan påverka kostnaden.
    • Det kan vara bra att skapa ett upprepningsbart (kanske till och med automatiserat) test av representativa dokument och frågor.
    • Se till att dina representativa dokument och frågor fortfarande är representativa.

Metoden för att fastställa kostnaden för en begäran är olika för varje API:

Skrivbegäranden

Kostnaden för skrivåtgärder brukar vara enkel att förutsäga. Du infogar poster och dokumenterar kostnaden som Azure Cosmos rapporterade.

Om du har dokument av olika storlek och/eller dokument som använder olika index är det viktigt att mäta alla. Du kanske upptäcker att dina representativa dokument har en tillräckligt stor kostnad för att du ska kunna tilldela ett enda värde för alla skrivningar. Om du till exempel hittade kostnader på 13,14 RU, 16,01 RU och 12,63 RU kan du beräkna dessa kostnader till 14 RU.

Läsbegäranden

Kostnaden för frågeåtgärder kan vara mycket svårare att förutsäga av följande skäl:

  • Om systemet stöder användardefinierade frågor måste du mappa inkommande frågor till representativa frågor för att fastställa kostnaden. Det finns olika former av den här processen:
    • Det kan vara möjligt att matcha frågorna exakt. Om det inte finns någon direkt matchning kan du behöva hitta den representativa fråga som den är närmast.
    • Du kanske upptäcker att du kan beräkna en kostnad baserat på frågans egenskaper. Du kanske till exempel upptäcker att varje sats i frågan har en viss kostnad, eller att en indexerad egenskap kostar "x" medan en som inte indexeras kostar "y" osv.
  • Antalet resultat kan variera och om du inte har statistik kan du inte förutsäga RU-påverkan från returnyttolasten.

Det är troligt att du inte har en enda kostnad för frågeåtgärder, utan en funktion som utvärderar frågan och beräknar en kostnad. Om du använder Core-API:et kan du sedan utvärdera den faktiska kostnaden för åtgärden och fastställa hur exakt uppskattningen var (justering av den här uppskattningen kan till och med ske automatiskt i koden).

Tillfällig felhantering

Programmet behöver fortfarande hantering av tillfälliga fel även om du implementerar en mekanism för hastighetsbegränsning av följande skäl:

  • Den faktiska kostnaden för en begäran kan vara annorlunda än din projicerade kostnad.
  • Tillfälliga fel kan inträffa av andra orsaker än TooManyRequests.

Att implementera en mekanism för hastighetsbegränsning i ditt program minskar dock avsevärt antalet tillfälliga fel.

Den här artikeln beskriver samordning på klientsidan och batchbearbetning av arbetsbelastningar, men det finns andra tekniker som kan användas för att hantera det övergripande systemets dataflöde.

Automatisk skalning

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. Dataflödet skalas baserat på användningen, utan att arbetsbelastningens tillgänglighet, svarstid, dataflöde eller prestanda påverkas.

Automatiskt 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 skalning.

Mer information om automatisk skalning finns i Skapa Azure Cosmos-containrar och databaser med dataflöde för automatisk skalning.

Mönster för köbaserad belastningsutjämning

Du kan använda en kö som fungerar som en buffert mellan en klient och Azure Cosmos DB för att jämna ut tillfälliga tunga belastningar som kan orsaka att tjänsten misslyckas eller att aktiviteten uppnår sin time out.

Det här mönstret är praktiskt för program som använder tjänster där överbelastning kan förekomma. Det här mönstret är dock inte användbart om programmet förväntar sig ett svar från tjänsten med minimal svarstid.

Det här mönstret passar ofta bra för inmatningsåtgärder.

Mer information om det här mönstret finns i Mönster för köbaserad belastningsutjämning.

Mönstret Cache-Aside

Du kan överväga att läsa in data på begäran i ett cacheminne i stället för att fråga Azure Cosmos DB varje gång. Att använda en cache kan förbättra prestanda och även bidra till att upprätthålla konsekvens mellan data som lagras i cacheminnet och data i det underliggande datalagret.

Mer information finns i: Cache-Aside-mönster.

Mönster för materialiserad vy

Du kan fylla i vyer i förväg i andra samlingar när du har lagrat data i Azure Cosmos DB när data inte är idealiska för obligatoriska frågeåtgärder. Det här mönstret kan ge stöd för effektiva frågor och extrahering av data samt förbättra programmets prestanda.

Mer information finns i Mönster för materialiserad vy.

Nästa steg