Dela via

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

  • Artikel

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

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 inspektera 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ärde-sö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 antingen de starka eller begränsade inaktuella konsekvensnivåerna 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 Kostnad för läsning med en punkt
1 kB 1 RU
100 kB 10 RU:er

Eftersom punktläsningar (nyckel-/värdesökningar på objekt-ID och partitionsnyckel) ä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 läspunkt (i stället för en fråga) när det är möjligt.

Kommentar

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 Azure Cosmos DB-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 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 begärande används.

I vissa fall kan du se en sekvens med 200 och 429 svar och enheter för variabelbegäran i en växlingsbar körning av frågor, vilket beror på att frågorna körs så snabbt som möjligt baserat på tillgängliga RU:er. Du kan se en frågekörningsbrytning i flera sidor/tur och retur-resor mellan server och klient. Till exempel kan 10 000 objekt returneras som flera sidor, var och en debiteras baserat på beräkningen 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 kostnadsoptimera frågor

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

  • Samlokalisera flera entitetstyper

    Försök att samplacera flera entitetstyper inom 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 atomiska transaktioner över flera poster via lagrade procedurer/utlösare begränsas till en partitionsnyckel i en enda container. Om du samlokaliserar entiteter i samma container kan du minska antalet nätverksresor för att lösa relationer mellan poster. Så det ökar prestandan från slutpunkt till slutpunkt, möjliggör atomiska transaktioner över flera poster för en större datamängd och därmed sänker kostnaderna. Om det är svårt att hitta flera entitetstyper i ett enda 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ät 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 när det gäller enheter för begäranden 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 svarstid. 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 begä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 efterföljande begäranden begränsas. Mer information finns i artikeln om enheter för begäranden och kalkylatorn för begärandeenheten.

Skriva data

RU-kostnaden för att skriva ett objekt beror på:

  • Objektstorleken.
  • 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 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 för 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: