Optimera kostnaden för begäran i Azure Cosmos DB
GÄLLER FÖR: Nosql Mongodb Cassandra Gremlin Tabell
Den här artikeln beskriver hur läs- och skrivbegäranden översätts till enheter för begäranden och hur du optimerar kostnaden för dessa begäranden. Läsåtgärder omfattar punktläsningar och frågor. Skrivåtgärder inkluderar infoga, ersätta, ta bort och upsert av objekt.
Azure Cosmos DB erbjuder en omfattande uppsättning databasåtgärder som körs på objekten i en container. Den kostnad som hör till var och en av dessa operationer varierar baserat på vilken CPU, vilka IO-resurser och hur mycket minne som krävs för att slutföra operationen. I stället för att tänka på och hantera maskinvaruresurser kan du tänka på en enhet för begäran (RU) som ett enda mått för de resurser som krävs för att utföra olika databasåtgärder för att hantera en begäran.
Mäta RU-avgiften för en begäran
Det är viktigt att mäta RU-avgiften för dina begäranden för att förstå deras faktiska kostnad och även utvärdera effektiviteten i dina optimeringar. Du kan hämta den här kostnaden med hjälp av Azure Portal eller genom att granska svaret som skickas tillbaka från Azure Cosmos DB via någon av SDK:erna. Mer information om hur du uppnår detta finns i Hitta enhetsavgiften för begäran i Azure Cosmos DB .
Läsa data: punktläsningar och frågor
Läsåtgärder i Azure Cosmos DB sorteras vanligtvis från snabbaste/mest effektiva till långsammare/mindre effektiva när det gäller RU-förbrukning enligt följande:
- Punktläsningar (nyckel-/värdesökning på ett enda objekt-ID och partitionsnyckel).
- Fråga med en filtersats i en enda partitionsnyckel.
- Fråga utan en likhets- eller intervallfiltersats på någon egenskap.
- Fråga utan filter.
Konsekvensnivåns roll
När du använder konsekvensnivåernaför stark eller begränsad föråldring fördubblas RU-kostnaden för alla läsåtgärder (punktläsning eller fråga).
Punktläsningar
Den enda faktor som påverkar RU-avgiften för en punktläsning (förutom den konsekvensnivå som används) är storleken på objektet som hämtats. I följande tabell visas RU-kostnaden för punktläsningar för objekt som är 1 KB och 100 kB stora.
Objektstorlek | Kostnaden för en punkt läs |
---|---|
1 kB | 1 RU |
100 kB | 10 RU:er |
Eftersom punktläsningar (nyckel-/värdesökningar på objekt-ID:t och partitionsnyckeln) är den mest effektiva typen av läsning bör du se till att objekt-ID:t har ett meningsfullt värde så att du kan hämta objekten med en punktläsning (i stället för en fråga) när det är möjligt.
Anteckning
I API:et för NoSQL kan punktläsningar endast göras med hjälp av REST-API:et eller SDK:erna. Frågor som filtrerar på ett objekts ID och partitionsnyckel anses inte vara en punktläsning. Om du vill se ett exempel med .NET SDK kan du läsa ett objekt i Azure Cosmos DB för NoSQL.
Frågor
Enheter för begäranden för frågor är beroende av ett antal faktorer. Till exempel antalet Inlästa/returnerade Azure Cosmos DB-objekt, antalet sökningar mot indexet, frågekompileringstiden osv. Detaljer. Azure Cosmos DB garanterar att samma fråga när den körs på samma data alltid använder samma antal enheter för begäranden även vid upprepade körningar. Frågeprofilen med hjälp av frågekörningsmått ger dig en bra uppfattning om hur enheter för programbegäran används.
I vissa fall kan du se en sekvens med 200 och 429 svar och enheter för variabla begäranden i en sidbaserad körning av frågor, vilket beror på att frågor körs så snabbt som möjligt baserat på tillgängliga RU:er. Du kan se en frågekörningsbrytning i flera sidor/turer mellan server och klient. Till exempel kan 10 000 objekt returneras som flera sidor, var och en debiteras baserat på den beräkning som utförts för den sidan. När du summerar över dessa sidor bör du få samma antal RU:er som du skulle få för hela frågan.
Mått för felsökning av frågor
Prestanda och dataflöde som används av frågor (inklusive användardefinierade funktioner) beror främst på funktionstexten. Det enklaste sättet att ta reda på hur mycket tid frågekörningen spenderas i UDF och antalet förbrukade RU:er är genom att aktivera frågemåtten. Om du använder .NET SDK, här är exempel på frågemått som returneras av SDK:
Retrieved Document Count : 1
Retrieved Document Size : 9,963 bytes
Output Document Count : 1
Output Document Size : 10,012 bytes
Index Utilization : 100.00 %
Total Query Execution Time : 0.48 milliseconds
Query Preparation Times
Query Compilation Time : 0.07 milliseconds
Logical Plan Build Time : 0.03 milliseconds
Physical Plan Build Time : 0.05 milliseconds
Query Optimization Time : 0.00 milliseconds
Index Lookup Time : 0.06 milliseconds
Document Load Time : 0.03 milliseconds
Runtime Execution Times
Query Engine Execution Time : 0.03 milliseconds
System Function Execution Time : 0.00 milliseconds
User-defined Function Execution Time : 0.00 milliseconds
Document Write Time : 0.00 milliseconds
Client Side Metrics
Retry Count : 1
Request Charge : 3.19 RUs
Metodtips för att kostnadsoptimerar frågor
Tänk på följande metodtips när du optimerar frågor mot kostnad:
Samplacera flera entitetstyper
Försök att samplacera flera entitetstyper inom ett enskilt eller mindre antal containrar. Den här metoden ger fördelar inte bara ur ett prisperspektiv, utan även för frågekörning och transaktioner. Frågor är begränsade till en enda container. och atomära transaktioner över flera poster via lagrade procedurer/utlösare begränsas till en partitionsnyckel i en enda container. Genom att samplacera entiteter i samma container kan du minska antalet nätverksresor för att lösa relationer mellan poster. Det ökar därför prestandan från slutpunkt till slutpunkt, aktiverar atomära transaktioner över flera poster för en större datauppsättning och sänker därmed kostnaderna. Om det är svårt att samplacera flera entitetstyper inom ett enskilt eller mindre antal containrar för ditt scenario, vanligtvis på grund av att du migrerar ett befintligt program och du inte vill göra några kodändringar – bör du överväga att etablera dataflöde på databasnivå.
Mäta och justera för lägre användning av enheter för begäranden/sekund
Komplexiteten i en fråga påverkar hur många enheter för programbegäran som förbrukas för en åtgärd. Antalet predikat, predikatens natur, antalet UDF:er och storleken på källdatauppsättningen. Alla dessa faktorer påverkar kostnaden för frågeåtgärder.
Azure Cosmos DB ger förutsägbara prestanda när det gäller dataflöde och svarstid med hjälp av en etablerad dataflödesmodell. Det etablerade dataflödet representeras i fråga om enheter för programbegäran per sekund eller RU/s. En enhet för begäran (RU) är en logisk abstraktion över beräkningsresurser som processor, minne, I/O osv. som krävs för att utföra en begäran. Det etablerade dataflödet (RU:er) är reserverat och dedikerat till din container eller databas för att ge förutsägbart dataflöde och svarstider. Med etablerat dataflöde kan Azure Cosmos DB tillhandahålla förutsägbara och konsekventa prestanda, garanterad låg svarstid och hög tillgänglighet i valfri skala. Enheter för programbegäran representerar den normaliserade valuta som förenklar resonemanget om hur många resurser ett program behöver.
Begärandeavgiften som returneras i begärandehuvudet anger kostnaden för en viss fråga. Om en fråga till exempel returnerar 1 000 1 KB-objekt är kostnaden för åtgärden 1 000. Därför respekterar servern bara två sådana begäranden inom en sekund innan de begränsar efterföljande begäranden. Mer information finns i artikeln om enheter för programbegäran och kalkylatorn för begärandeenheten.
Skriva data
RU-kostnaden för att skriva ett objekt beror på:
- Objektets storlek.
- Antalet egenskaper som omfattas av indexeringsprincipen och som måste indexeras.
Att infoga ett objekt på 1 kB utan indexering kostar cirka ~5,5 RU:er. Att ersätta en artikel kostar två gånger den avgift som krävs för att infoga samma objekt.
Optimera skrivningar
Det bästa sättet att optimera RU-kostnaden för skrivåtgärder är att ge dina objekt rättigheter och antalet egenskaper som indexeras.
- Lagring av mycket stora objekt i Azure Cosmos DB resulterar i höga RU-avgifter och kan betraktas som ett antimönster. Lagra i synnerhet inte binärt innehåll eller stora textsegment som du inte behöver fråga efter. Bästa praxis är att placera den här typen av data i Azure Blob Storage och lagra en referens (eller länk) till bloben i det objekt som du skriver till Azure Cosmos DB.
- Att optimera indexeringsprincipen för att endast indexera de egenskaper som dina frågor filtrerar på kan göra stor skillnad för de RU:er som förbrukas av dina skrivåtgärder. När du skapar en ny container indexerar standardindexeringsprincipen varje egenskap som finns i dina objekt. Även om detta är en bra standard för utvecklingsaktiviteter rekommenderar vi starkt att du utvärderar om och anpassar indexeringsprincipen när du går till produktion eller när din arbetsbelastning börjar ta emot betydande trafik.
När du utför massinmatning av data rekommenderar vi också att du använder azure Cosmos DB-massexekutorbiblioteket eftersom det är utformat för att optimera RU-förbrukningen av sådana åtgärder. Du kan också använda Azure Data Factory som bygger på samma bibliotek.
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:
- Läs mer om att optimera för utveckling och testning
- Läs mer om att förstå din Azure Cosmos DB-faktura
- Läs mer om att optimera dataflödeskostnaden
- Läs mer om att optimera lagringskostnaden
- Läs mer om att optimera kostnaden för Azure Cosmos DB-konton i flera regioner
- Läs mer om reserverad kapacitet i Azure Cosmos DB
- Försöker du göra kapacitetsplanering 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 hjälp av virtuella kärnor eller virtuella processorer
- 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-kapacitetsplanering