Enheter för programbegäran i Azure Cosmos DB

  • Artikel
  • 5 minuter för att läsa

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

Azure Cosmos DB har stöd för många API:er, till exempel SQL, MongoDB, Cassandra, Gremlin och Table. Varje API har en egen uppsättning databasåtgärder. De här åtgärderna sträcker sig från enkla punktläsningar och skrivningar till komplexa frågor. Varje databasåtgärd förbrukar systemresurser baserat på åtgärdens komplexitet.

Kostnaden för alla databasåtgärder normaliseras av Azure Cosmos DB och uttrycks i form av enheter för programbegäran (Request Units, RU:er). Enhet för programbegäran är en prestandavaluta som abstraherar systemresurser som CPU, IOPS och minne som krävs för att utföra de databasåtgärder som stöds av Azure Cosmos DB.

Kostnaden för att göra en punktläsning (dvs. hämtning av ett enskilt objekt efter dess ID och partitionsnyckelvärde) för ett objekt på 1 kB är 1 enhet för programbegäran (eller 1 RU). Alla andra databasåtgärder tillskrivs på samma sätt en kostnad i form av RU:er. Oavsett vilket API du använder för att interagera med din Azure Cosmos-behållare mäts kostnaderna alltid med RU:er. Oavsett om databasåtgärden är en skrivning, punktläsning eller fråga mäts kostnaderna alltid i RU:er.

Följande bild illustrerar den övergripande tanken med RU:er:

Databasåtgärder förbrukar enheter för begäran

För att hantera och planera kapacitet ser Azure Cosmos DB till att antalet RU:er för en given databasåtgärd som avser en given datamängd är deterministisk. Du kan undersöka svarshuvudet för att ta reda på antalet RU:er som förbrukas av en valfri 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 Cosmos-konto du använder avgör hur förbrukade RU:er 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 RU:er för ditt program per sekund i steg om 100 RU:er per sekund. Om du vill skala det etablerade dataflödet för ditt program kan du öka eller minska antalet RU:er när som helst i steg om 100 RU:er. Du kan göra ändringarna med hjälp av programmering eller via Azure-portalen. Du debiteras per timme för det antal RU:er per sekund som du har etablerat. Mer information finns i artikeln Etablerat dataflöde.

    Du kan etablera dataflöde för två specifika 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 Cosmos-konto. I slutet av faktureringsperioden debiteras du för det antal enheter för förfrågningsbegäran som har förbrukats av databasåtgärderna. Mer information finns i artikeln Om serverlöst dataflöde.

  3. Autoskalningsläge: I det här läget kan du automatiskt och omedelbart skala dataflödet (RU/s) för databasen eller containern baserat på dess användning, utan att påverka arbetsbelastningens tillgänglighet, svarstid, dataflöde eller prestanda. Det här läget passar bra för verksamhetskritiska arbetsbelastningar som har varierande eller oförutsägbara trafikmönster och kräver serviceavtal med hög prestanda och skalning. Mer information finns i artikeln autoskala dataflöde.

Överväganden för enhet för programbegäran

När du beräknar antalet RU:er som förbrukas av din arbetsbelastning bör du tänka på följande faktorer:

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

  • Objektindexering: Som standard indexeras alla objekt automatiskt. Färre enheter för programbegäran används om du väljer att inte indexera vissa av objekten i en container.

  • Antal objektegenskaper: Om standardindexering används för alla egenskaper ökar det antal enheter för programbegäran som används för att skriva ett objekt allt eftersom antalet objektegenskaper ökar.

  • Indexerade egenskaper: En indexeringsprincip för varje container avgör vilka egenskaper som indexeras som standard. Om du vill minska förbrukningen av enheter för programbegäran för skrivåtgärder bör du begränsa antalet indexerade egenskaper.

  • Datakonsekvens: Konsekvensnivåerna för stark och avgränsad föråldhet förbrukar ungefär två gånger fler RU:er vid läsåtgärder jämfört med andra mindre konsekventa konsekvensnivåer.

  • Typ av läsningar: Punktläsningar kostar betydligt färre RU:er än frågor.

  • Frågemönster: Komplexiteten i en fråga påverkar hur många enheter för programbegäran som förbrukas för en åtgärd. Faktorer som påverkar kostnaden för frågeåtgärder omfattar:

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

    Samma fråga för samma data kostar alltid samma antal RU:er vid upprepade körningar.

  • Skriptanvändning: Precis som med frågor förbrukar lagrade procedurer och utlösare RU:er baserat på komplexiteten i de åtgärder som utförs. När du utvecklar ditt program kan du läsa rubriken för begärandekostnad för att få mer information om hur mycket RU-kapacitet varje åtgärd förbrukar.

Enheter för programbegäran och flera regioner

Om du etablerar R-RU:er på en Cosmos-container (eller databas) Cosmos DB att R-RU:er är tillgängliga i varje region som är associerad med ditt Cosmos-konto. Du kan inte selektivt tilldela RU:er till en viss region. RU:erna som etablerats på en Cosmos-container (eller databas) etableras i alla regioner som är associerade med ditt Cosmos-konto.

Förutsatt att en Cosmos-container har konfigurerats med R-RU:er och det finns N-regioner som är associerade med Cosmos-kontot, är det totala antalet RU:er som är tillgängliga globalt i containern = R x N.

Ditt val av konsekvensmodell påverkar också dataflödet. Du kan få ett dataflöde på ungefär 2 gånger för de mer avslappnade konsekvensnivåerna (t.ex. session, konsekvent prefix och slutlig konsekvens) jämfört med starkare konsekvensnivåer (t.ex. avgränsad föråldrhet eller stark konsekvens).

Nästa steg