Optimera begär kostnad i Azure Azure AzureS DB

GÄLLER FÖR: SQL API Api Gremlin API Table API Azure Azure DB API för MongoDB

I den här artikeln beskrivs hur läs- och skrivförfrågningar omvandlas till Begär enheter och hur du optimerar kostnaden för dessa begäranden. Läsåtgärder inkluderar läsning av poäng och frågor. Skrivåtgärderna omfattar infoga, ersätta, ta bort och upsert av objekt.

Azure Azure Azures DB erbjuder en omfattande uppsättning databasåtgärder som fungerar för objekten i en behållare. Kostnaden som är kopplad till var och en av dessa åtgärder varierar beroende på processor, IO och minne som krävs för att slutföra åtgärden. I stället för att tänka på och hantera maskinvaruresurser kan du tänka på en begäranhet (RU) som en enda åtgärd för resurser som krävs för att utföra olika databasåtgärder för att utföra en begäran.

Mäta RU-debitering för en begäran

Det är viktigt att mäta ru-debiteringen 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 via Azure-portalen eller genom att granska svaret som skickas tillbaka från Azure Azure Azures DB via en av SDKs. Mer information om hur du uppnår det finns i Hitta debitering för begärandeenhet i Azure Setts DB.

Läsdata: punktläsningar och frågor

Läsåtgärder i Azure Azures DB är normalt ordnade från snabbast/mest effektiva till långsammare/mindre effektiva när det gäller RU-förbrukning enligt följande:

  • Point reads (key/value lookup on a single item ID and partition key).
  • Fråga med en filtersats med en 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 antingen de starka eller bundna inaktuella konsekvensnivåerna dubblerats kostnaden för all läsåtgärd (punktläsning eller fråga).

Poäng läses upp

Den enda faktor som påverkar ru-debitering för punktläsning (förutom den konsekvensnivå som används) är storleken på det hämtade objektet. I följande tabell visas kostnaden för punktläsningar för artiklar som är 1 kB och 100 kB stora.

Objektstorlek Kostnaden för en poängläsning
1 kB 1 RU
100 kB 10 RUs

Eftersom poängläsningar (nyckel-/värdeuppslag på objekt-ID:t) är den effektivaste typen av läsning bör du se till att objekt-ID:t har ett meningsfullt värde så att du kan hämta dina objekt med punktuppläsning (i stället för en fråga) när det är möjligt.

Frågor

Begär enheter för frågor är beroende av ett antal faktorer. Exempelvis antalet Azure Azure-objekt som lästs in/returnerats, antalet uppslag mot indexet, tiden för frågekompilering osv. Azure Azure Azures DB garanterar att samma fråga vid körning av samma data alltid kommer att använda samma antal begärsenheter även om körningar upprepas. Frågeprofilen som använder mått för frågekörning ger dig en bra uppfattning om hur frågeenheterna spenderas.

I vissa fall kan du se en sekvens av 200 och 429 svar och variabla begärande enheter i en sidförd körning av frågor, det vill säga att frågor körs så snabbt som möjligt baserat på tillgängliga berätt7d. Du kan se en körning av frågan i flera sidor/round trips mellan server och klient. Till exempel kan 10 000 objekt returneras som flera sidor, var och en debiterad utifrån beräkning som utförts för den sidan. När du summerar över de här sidorna bör du få samma antal foU:er som för hela frågan.

Mätvärden för felsökning av frågor

Prestanda och dataflöde som används av frågor (inklusive användardefinierade funktioner) beror oftast på funktionens brödtext. Det enklaste sättet att ta reda på hur mycket tid frågekörningen läggs på UDF och hur många användaraktiveringar som används är genom att aktivera frågemåtten. Om du använder .NET SDK finns det 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  

Rekommendationer för kostnadsoptimeringsfrågor

Tänk på följande metodtips när du optimerar frågor för kostnad:

  • Placera flera entitetstyper i samlokalisering

    Försök att placera flera entitetstyper i ett enda eller ett mindre antal behållare. Den här metoden ger inte bara fördelar ur ett prissättningsperspektiv, utan även för frågekörning och transaktioner. Frågor är begränsade till en enda behållare. och atomtransaktioner över flera poster via lagrade procedurer/utlösare är begränsade till en partitionsnyckel i en enda behållare. Att placera enheter i samma behållare kan minska antalet nätverksrundturer för att lösa relationer mellan poster. Det ökar end-to-end-prestanda, möjliggör atomiska transaktioner över flera poster för en större datauppsättning, vilket ger lägre kostnader. Om det är svårt att placera flera entitetstyper i ett enda eller ett mindre antal behållare för ditt scenario, vanligtvis på grund av att 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ån.

  • Mät och finjustera för lägre förfrågningsenheter/sekundanvändning

    Komplexiteten i en fråga påverkar hur många begärsenheter (RUs) som används för en åtgärd. Antalet predikat, typ av predikat, antal får inte använda filstorlekar och storleken på källdatauppsättningen. Alla dessa faktorer påverkar kostnaderna för frågeåtgärder.

Azure Azure Azures DB ger förutsägbar prestanda när det gäller dataflöde och svarstid genom att använda en modell för etableringsflöde. Dataflödet som tillhandahålls representeras av Begär enheter per sekund eller RU/s. En begärenhet (RU) är en logisk abstraktion över att beräkna resurser som processor, minne, IO osv. som krävs för att utföra en begäran. Det etablerade dataflödet är reserverat för behållaren eller databasen för att tillhandahålla förutsägbart dataflöde och svarstid. Med etablerat dataflöde kan Azure Azure Dbs DB tillhandahålla förutsägbara och konsekventa prestanda, garanterad låg latens och hög tillgänglighet i alla skalor. Begär enheter representerar den normaliserade valutan som förenklar skälen till hur många resurser ett program behöver.

Begärandedekostnaden som returneras i rubriken för begäran anger kostnaden för en viss fråga. Om en fråga till exempel returnerar 1 000 1 KB-objekt är åtgärdens kostnad 1 000. Servern följer därför bara två sådana begäranden inom en sekund innan efterföljande begäranden begränsas i takt med att de begränsas. Mer information finns i artikeln om begäranhetsenheter och kalkylatorn för begäranhet.

Skriva data

Hur mycket RU kostar att skriva ett objekt beror på:

  • Objektets storlek.
  • Antalet egenskaper som omfattas av indexeringsprincipen och som måste indexeras.

Infoga en 1 kB-post utan att indexera kostnader runt ~5,5 RUs. Att ersätta en artikel kostar två gånger den avgift som krävs för att infoga samma artikel.

Optimerar skriver

Det bästa sättet att optimera ru-kostnaden för skrivåtgärder är att rättighetsisera dina objekt och antalet egenskaper som indexeras.

  • Lagring av mycket stora objekt i Azure Azure AzureS DB resulterar i höga RU-avgifter och kan ses som ett skyddmönster. Lagra i synnerhet inte binärt innehåll eller stora delar av texten som du inte behöver fråga efter. En bra metod är att placera den här typen av data i Azure Blob Storage och lagra en referens (eller länk) till bloben i objektet du skriver till Azure Azure Azures DB.
  • En optimering av indexeringsprincipen för att bara indexera de egenskaper som frågefiltret på kan göra stor skillnad för de RUs som används av skrivåtgärderna. När du skapar en ny behållare indexeras varje egenskap i objekten i standardindexeringsprincipen. Det här är en bra standardinställning för utvecklingsverksamhet, men vi rekommenderar starkt att utvärdera och anpassa indexeringsprincipen när du går i produktion eller när arbetsbelastningen börjar få betydande trafik.

När du utför mass pågestering av data rekommenderar vi också att du använder Azure Azure Azure Db-massredigeringsbiblioteket, eftersom det är utformat för att optimera förbrukningen i ru för sådana åtgärder. Du kan också använda Azure Data Factory som bygger på samma bibliotek.

Nästa steg

Nu kan du gå vidare och lära dig mer om kostnadsoptimering i Azure Azure Azures DB med följande artiklar: