Begär enheter i Azure Azure Azures DB

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

Azure Azure Azures DB har stöd för många API:er, till exempel SQL, MongoDB,Andra, Gremlin och Table. Varje API har en egen uppsättning databasåtgärder. Dessa åtgärder går från enkla läsningar och skrivningar till komplexa frågor. Varje databasåtgärd använder systemresurser beroende på åtgärdens komplexitet.

Kostnaden för alla databasåtgärder normaliseras av Azure Azure AzureS DB och uttrycks av Begär enheter (eller beenheter, kort). Begär enhet är en prestandavaluta som sammandrager systemresurser som PROCESSOR, IOPS och minne som krävs för att utföra databasåtgärder som stöds av Azure Azures DB.

Kostnaden för att göra en punktläsning (d.v.s. hämta ett objekt med dess ID och partitionsnyckelvärde) för ett 1 KB-objekt är 1 Begär enhet (eller 1 RU). Alla andra databasåtgärder tilldelas på samma sätt en kostnad med hjälp av RUs. Oavsett vilket API du använder för att interagera med Azure Azures-behållaren mäts kostnader alltid med beenheter. Oavsett om databasåtgärden är en skrivning, punktläsning eller fråga mäts alltid kostnader i RUs.

Följande bild visar den avancerade idén med foU:er:

Databasåtgärder använder begär enheter

För att hantera och planera kapaciteten ser Azure Azure Azures DB till att antalet RUs för en viss databasåtgärd över en viss datauppsättning är deterministiskt. Du kan undersöka svarsrubriken för att spåra antalet RUs som används av en databasåtgärd. När du förstår de faktorer som påverkar RU-avgifter och programmets dataflödeskrav kan du köra programmet kostnadseffektivt.

Vilken typ av Azure Azure Azure-konto du använder avgör hur använda RUs debiteras. Det finns tre lägen där du kan skapa ett konto:

  1. Etablerat dataflödesläge:I det här läget etablerar du antalet RUs för programmet i steg om 100 RUs per sekund. Om du vill skala det etablerade dataflödet för programmet kan du öka eller minska antalet RUs när som helst i steg eller decrements på 100 RUs. Du kan göra dina ändringar programmässigt eller med hjälp av Azure Portal. Du debiteras per timme för beloppet för be slutanvändaranvändare per sekund som du har etablerat. Mer information finns i artikeln Om etablerat dataflöde.

    Du kan tillhandahålla dataflöde med två distinkta granulariteter:

  2. Serverlöst läge:I det här läget behöver du inte etablera något dataflöde när du skapar resurser i ditt Azure Azures-konto. I slutet av faktureringsperioden debiteras du för mängden Begär enheter som har förbrukats av databasåtgärderna. Mer information finns i artikeln Om serverlös dataflöde.

  3. Läget förautomatisk skalning: I det här läget kan du automatiskt och direkt skala dataflödet (RU/s) för databasen eller behållaren baserat på dess användning, utan att påverka tillgängligheten, svarstiden, dataflödet eller prestandan för arbetsbelastningen. Det här läget passar bra för verksamhetskritiska arbetsbelastningar som har variabel eller oförutsägbara trafikmönster och kräver hög prestanda och skala. Mer information finns i artikeln om dataflöde för automatisk skalning.

Att begära enhetsöverväganden

Även om du uppskattar hur många foU-åtgärder som används efter arbetsbelastningen bör du tänka på följande faktorer:

  • Objektstorlek:När storleken på ett objekt ökar, ökas även antalet RUs som används för att läsa eller skriva objektet.

  • Objektindexering:Varje objekt indexeras automatiskt som standard. Färre RUs används om du väljer att inte indexera vissa av dina objekt i en behållare.

  • Antal objektegenskaper:Om standardindexeringen gäller för alla egenskaper ökas antalet objekt som används för att skriva objekt när antalet objektegenskaper ökar.

  • Indexerade egenskaper:En indexprincip för varje behållare avgör vilka egenskaper som indexeras som standard. För att minska förbrukningen i ru för skrivåtgärder begränsar du antalet indexerade egenskaper.

  • Datakonsekvens:Den starka och bundna inaktuella konsekvensnivån tar upp ungefär två gånger fler RUs medan du utför läsåtgärder jämfört med andra nivåer av naturligt konsekvens.

  • Typ av läsning:Poängläsningar kostar betydligt färre RUs än frågor.

  • Frågemönster:En frågas komplexitet påverkar hur många foU:er som används för en åtgärd. Exempel på faktorer som påverkar kostnaden för frågeåtgärder:

    • Antalet frågeresultat
    • Antalet predikat
    • Predikatens natur
    • Antalet användardefinierade funktioner
    • Storleken på källdata
    • Storleken på resultatuppsättningen
    • Projektioner

    Samma fråga för samma data kommer alltid att kostar samma antal berätt stora kostnader för upprepade körningar.

  • Skriptanvändning:Precis som med frågor använder lagrade procedurer och utlösare RUs beroende på komplexiteten hos åtgärderna som utförs. När du utvecklar programmet kontrollerar du rubriken för begäran om debitering för att bättre förstå hur mycket RU-kapacitet varje åtgärd tar upp.

Begär enheter och flera regioner

Om du etablerar "R" RUs på en Container (eller databas) ser Hanss DB till att R-R-RUs är tillgängliga i varje region som är kopplad till ditt Tackkonto. Du kan inte selektivt tilldela RUs till ett visst område. RUs provisioned on a Container (or database) are provisioned in all the regions associated with your Fån snäckor konto.

Om vi utgår från att en Sådd-behållare är konfigurerad med RUS och det finns N-regioner kopplade till Resurskonto, är det totala antalet företag som är tillgängliga globalt i behållaren = R x N.

Ditt val av konsekvensmodell påverkar också dataflödet. Du kan få ungefär 2x läsflöde för en mer naturligt konsekvent nivå (till exempel session,konsekvent prefix och eventuell konsekvens) jämfört med starkare konsekvensnivåer (t.ex. bunden inaktuellhet eller stark konsekvens).

Nästa steg