Enheter för programbegäran i Azure Cosmos DB

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

Azure Cosmos DB stöder många API:er, till exempel SQL, MongoDB, Cassandra, Gremlin och Table. Varje API har en egen uppsättning databasåtgärder. Dessa åtgärder 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). Begärandeenheten är en prestandavaluta som abstraherar systemresurser som CPU, IOPS och minne som krävs för att utföra databasåtgärder som stöds av Azure Cosmos DB.

Kostnaden för att utföra en punktläsning (hämta ett enskilt objekt med dess ID och partitionsnyckelvärde) för ett 1 KB-objekt är 1 enhet för begä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 skriv-, punktläsnings- eller fråga mäts kostnaderna alltid i RU:er.

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

Databasåtgärder använder enheter för programbegä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 eller minskningar på 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 antalet enheter för programbegäran som har förbrukats av databasåtgärderna. Mer information finns i artikeln 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 tillgänglighet, svarstid, dataflöde eller prestanda för arbetsbelastningen. 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öga prestanda och skala. Mer information finns i artikeln autoskalningsdataflöde .

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

Tänk på följande faktorer när du beräknar antalet RU:er som förbrukas av din arbetsbelastning:

  • 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: De starka och begränsade föråldringskonsekvensnivåerna förbrukar ungefär två gånger fler RU:er samtidigt som läsåtgärder utförs jämfört med andra avslappnade 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 på samma data kostar alltid samma antal RU:er vid upprepade körningar.

  • Skriptanvändning: Precis som med frågor använder 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) ser Cosmos DB till 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 etableras i 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å ungefär 2 x läsdataflöde för de mer avslappnade konsekvensnivåerna (session, konsekvent prefix och slutlig konsekvens) jämfört med starkare konsekvensnivåer (begränsad föråldring eller stark konsekvens).

Nästa steg