Dela via

Optimera ditt Azure Cosmos DB-program med hjälp av hastighetsbegränsning

  • Artikel

GÄLLER FÖR: NoSQL MongoDB Kassandra Gremlin Bord

Den här artikeln ger utvecklare en metod för att betygsätta begäranden till Azure Cosmos DB. Om du implementerar det här mönstret kan du minska felen och förbättra den övergripande prestandan för arbetsbelastningar som överskrider det etablerade dataflödet för måldatabasen eller containern.

Begäranden som överskrider ditt etablerade dataflöde i Azure Cosmos DB kan resultera i tillfälliga fel som TooManyRequests, Timeout och ServiceUnavailable. Vanligtvis försöker du igen när kapaciteten är tillgänglig och lyckas. Den här metoden kan dock resultera i ett stort antal begäranden efter felsökvägen i koden och resulterar vanligtvis i 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 skapar ett Azure Cosmos DB-konto med 20 000 RU/sekund.
  • Ditt program bearbetar ett inmatningsjobb som innehåller 10 000 poster, som var och en kostar 10 enheter för begäranden (RU:er). Den totala kapacitet som krävs för att slutföra det här jobbet är 100 000 RU.
  • Du skickar ett helt jobb till Azure Cosmos DB och förväntar 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 enheter för begäranden som behövs för jobbet (100 000) är större än det etablerade maxvärdet (20 000). Cirka 2 000 av posterna godkänns i databasen, men cirka 8 000 avvisas. Du skickar cirka 8 000 poster till Azure Cosmos DB vid återförsök, varav cirka 2 000 accepteras och så vidare. Du bör förvänta dig att det här mönstret skickar cirka 30 000 poster i stället för 10 000 poster.
  • Du väljer i stället att skicka dessa begäranden jämnt över fem sekunder, du bör förvänta dig inga fel och totalt snabbare dataflöde eftersom varje batch skulle ligga på eller under de etablerade 20 000.

Du kan sprida begäranden över en tidsperiod genom att införa en mekanism för hastighetsbegränsning i koden.

Ru:erna som etableras för en container delas jämnt över antalet fysiska partitioner. Om Azure Cosmos DB etablerade två fysiska partitioner i föregående exempel skulle var och en ha 10 K RU.

Mer information om enheter för programbegäran finns i Enheter för begäran i Azure Cosmos DB . Mer information om hur du beräknar antalet RU:er som förbrukas av din arbetsbelastning finns i Överväganden för begärandeenhet. Mer information om partitionering av Azure Cosmos DB finns i Partitionering och horisontell skalning i Azure Cosmos DB.

Metod

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

  1. Profilera ditt program så att du har data om skrivningar och läsbegäranden 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 i 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 på en sekund inte överskrider ditt etablerade dataflöde.
  8. Belastningstesta programmet och kontrollera att du inte överskrider det etablerade dataflödet.
  9. Testa RU-kostnaderna igen regelbundet 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:s standardindexeringsprincip för nyligen skapade containrar varje egenskap. Varje indexerad egenskap ökar RU-kostnaden för skrivningar.

Standardindexeringsprincipen kan minska svarstiden i läsintensiva system där frågefiltervillkor är väl fördelade över alla lagrade fält. Till exempel kan system där Azure Cosmos DB tillbringar större delen av sin tid med slutanvändarskapade ad hoc-sökningar vara till nytta.

Du kanske vill exkludera egenskaper som aldrig söks mot från att indexeras. Om du tar bort egenskaper från indexet kan du förbättra den övergripande systemprestandan (kostnad och tid) för system som är skrivintensiva och hämtningsmönster för poster är mer begränsade.

Innan du mäter några 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 om alla kostnadsberäkningar.

När det är möjligt kan testning av ett system under utveckling med en belastning som återspeglar vanliga frågor vid normala och högsta efterfrågan 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:

  • Tänk på alla faktorer som påverkar RU-användningen enligt beskrivningen i överväganden för begärandeenheten.
  • Alla läsningar och skrivningar i databasen eller containern delar samma etablerade dataflöde.
  • RU-förbrukning uppstår oavsett vilka 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 vad driftsystemet kommer att stöta på.
    • 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 med jämna mellanrum.
    • Indexändringar, storleken på index kan påverka kostnaden.
    • Det är bra att skapa ett repeterbart (kan 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 tenderar att vara lätt att förutsäga. Du infogar poster och dokumenterar kostnaden som Azure Cosmos DB 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 är tillräckligt nära i kostnad för att du kan 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 i genomsnitt beräkna dessa kostnader till 14 RU.

Läsbegäranden

Kostnaden för frågeåtgärder kan vara 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 de representativa frågorna för att fastställa kostnaden. Det finns olika former som den här processen kan ha:
    • 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 kan till exempel upptäcka att varje sats i frågan har en viss kostnad, eller att en indexerad egenskap kostar "x" medan en inte indexerade kostnader "y" osv.
  • Antalet resultat kan variera och om du inte har statistik kan du inte förutsäga RU-effekten från returnyttolasten.

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

Tillfällig felhantering

Ditt program behöver fortfarande tillfällig felhantering även om du implementerar en hastighetsbegränsningsmekanism av följande skäl:

  • Den faktiska kostnaden för en begäran kan skilja sig från den beräknade kostnaden.
  • Tillfälliga fel kan inträffa av andra orsaker än TooManyRequests.

En korrekt implementering av en hastighetsbegränsningsmekanism 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 övergripande systemdataflö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 påverka arbetsbelastningens tillgänglighet, svarstid, dataflöde eller prestanda.

Autoskalning av etablerat dataflöde passar bra för verksamhetskritiska arbetsbelastningar som har varierande eller oförutsägbara trafikmönster och kräver serviceavtal (SLA) med höga prestanda och skala.

Mer information om automatisk skalning finns i Skapa Azure Cosmos DB-containrar och databaser med autoskalningsdataflöde.

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 leda till att tjänsten misslyckas eller att aktiviteten överskrider tidsgränsen.

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 en cache i stället för att köra frågor mot Azure Cosmos DB varje gång. Att använda en cache kan förbättra prestandan 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 andra samlingar i förväg när du har lagrat data i Azure Cosmos DB när data inte är idealiskt formaterade för nödvändiga frågeåtgärder. Det här mönstret kan hjälpa till att stödja effektiv frågekörning och extrahering av data och förbättra programmets prestanda.

Mer information finns i Materialiserat vymönster.

Relaterat innehåll