Optimera kostnaden för begäran i Azure Cosmos DB

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

Den här artikeln beskriver hur läs- och skrivbegäranden översätts till enheter för programbegäran 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 betrakta en enhet för programbegä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 av 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 en av SDK:erna. Detaljerade anvisningar om hur du uppnår detta finns i Hitta kostnaden för enhet för programbegä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ärde-sökning på ett enskilt objekt-ID och partitionsnyckel).
  • Fråga med en filtersats inom en enda partitionsnyckel.
  • Fråga utan en likhets- eller intervallfiltersats för 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ämtas. I följande tabell visas RU-kostnaden för punktläsningar för objekt som är 1 KB och 100 kB stora.

Objektstorlek Kostnad för läsning med en punkt
1 kB 1 RU
100 kB 10 RU:er

Eftersom punktläsningar (nyckel-/värdesökningar i objekt-ID:t) ä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.

Frågor

Enheter för programbegäran för frågor är beroende av ett antal faktorer. Till exempel antalet Azure Cosmos-objekt som lästs in/returnerats, antalet sökningar mot indexet, frågekompileringstiden osv. information. Azure Cosmos DB garanterar att samma fråga när den körs på samma data alltid använder samma antal enheter för programbegäran ä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 variabla enheter för programbegäran i en växlingsbar 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 får 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

Överväg följande metodtips när du optimerar frågor mot kostnader:

  • Samplacera flera entitetstyper

    Försök att samplacera flera entitetstyper i ett enda 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 är begränsade till en partitionsnyckel i en enda container. Genom att placera entiteter i samma container kan du minska antalet nätverksresor för att matcha relationer mellan poster. Därför ökar prestandan från slutpunkt till slutpunkt, aktiverar atomiska 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 i ett enda eller mindre antal containrar i ditt scenario, vanligtvis eftersom du migrerar ett befintligt program och inte vill göra några kodändringar – bör du överväga att etablera dataflöde på databasnivå.

  • Mät och justera för lägre användning av enheter för programbegäran/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ägbar prestanda när det gäller dataflöde och svarstid med hjälp av en etablerad dataflödesmodell. Det etablerade dataflödet representeras i termer av enheter för programbegäran per sekund eller RU/s. En enhet för programbegä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 tillhandahålla 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ärandeavgift 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 frekvensen begränsar efterföljande begäranden. Mer information finns i artikeln om enheter för programbegäran och kalkylatorn för enheter för programbegäran.

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 objektet 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 i de RU:er som förbrukas av skrivåtgärderna. 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-massexecutor-biblioteket 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 med att lära dig mer om kostnadsoptimering i Azure Cosmos DB med följande artiklar: