Jednotky žádostí ve službě Azure Cosmos DB

  • Článek
  • 4 min ke čtení

platí pro: SQL api rozhraní API Cassandra Gremlin api rozhraní API pro tabulky Azure Cosmos DB api pro MongoDB

Azure Cosmos DB podporuje mnoho rozhraní api, například SQL, MongoDB, Cassandra, Gremlin a Table. Každé rozhraní API má svou vlastní sadu databázových operací. Tyto operace jsou v rozsahu od jednoduchých čtení a zápisů do složitých dotazů. Každá databázová operace spotřebovává systémové prostředky na základě složitosti operace.

Azure Cosmos DB normalizuje náklady na všechny databázové operace a vyjadřuje je v jednotkách žádostí (zkráceně RU). jednotka požadavku je výkon abstrakce systémových prostředků, jako jsou například CPU, IOPS a paměť, které jsou potřeba k provádění databázových operací, které Azure Cosmos DB podporuje.

Náklady na čtení bodu (tj. načtení jedné položky podle jejího ID a hodnoty klíče oddílu) pro položku 1 KB je 1 jednotka žádosti (nebo 1 RU). Podobně jsou náklady v RU přiřazené ke všem ostatním databázovým operacím. Bez ohledu na to, jaké rozhraní API používáte k interakci s kontejnerem Azure Cosmos, se náklady vždy měří v jednotkách RU. Bez ohledu na to, jestli je databázová operace zápis, čtení z bodu nebo dotazování, se náklady vždycky měří v ru.

Následující obrázek znázorňuje základní myšlenku jednotek RU:

Databázové operace spotřebovávají jednotky žádosti

Aby bylo možné spravovat a plánovat kapacitu, Azure Cosmos DB zajišťuje, že je počet RU pro konkrétní databázovou operaci nad danou datovou sadou deterministický. Pokud chcete sledovat počet RU spotřebovaných jakoukoli databázovou operací, můžete prozkoumat hlavičku odpovědi. Když rozumíte faktorům, které mají vliv na poplatky za ru a požadavky na propustnost vaší aplikace, můžete efektivně spouštět náklady na aplikace.

typ účtu Azure Cosmos, který používáte, určuje způsob, jakým se účtují poplatky za spotřebované ruy. Existují tři režimy, ve kterých můžete vytvořit účet:

  1. Zřízený režim propustnosti: v tomto režimu zřizujete počet ru pro vaši aplikaci za sekundu v přírůstcích po 100 ru za sekundu. Pro škálování zřízené propustnosti aplikace můžete zvýšit nebo snížit počet ru v jakémkoli okamžiku v přírůstcích nebo snižování 100 ru. Změny můžete naprogramovat nebo můžete použít Azure Portal. Poplatky se účtují po hodinách po dobu ru za sekundu, kterou jste zřídili. Další informace najdete v článku o zřízené propustnosti .

    Propustnost můžete zřídit na dvou různých úrovních:

  2. režim bez serveru: v tomto režimu nemusíte při vytváření prostředků v účtu Azure Cosmos zřizovat žádné propustnosti. Na konci fakturačního období se vám bude účtovat množství jednotek požadavků, které vaše databázové operace spotřebují. Další informace najdete v článku o propustnosti bez serveru .

  3. Režim automatického škálování: v tomto režimu můžete automaticky a okamžitě škálovat propustnost (ru/s) databáze nebo kontejneru na základě využití IT, aniž by to ovlivnilo dostupnost, latenci, propustnost nebo výkon úlohy. Tento režim je vhodný pro klíčové úlohy, které mají proměnlivé nebo nepředvídatelné vzory přenosů dat, a vyžadují SLA s vysokým výkonem a škálováním. Další informace najdete v článku o propustnosti automatického škálování .

Co ovlivňuje jednotky žádosti

Při odhadování počtu ru spotřebovaných úlohami Vezměte v úvahu následující faktory:

  • Velikost položky: Se vzrůstající velikostí položky se také zvyšuje počet jednotek žádosti spotřebovaných pro čtení a zápis.

  • Indexování položky: Ve výchozím nastavení se automaticky indexuje každá položka. Pokud se rozhodnete některé z položek v kontejneru neindexovat, spotřebujete tak méně jednotek žádosti.

  • Počet vlastností položky: Pokud u všech vlastností platí výchozí indexování, roste s počtem vlastností položky také počet jednotek žádosti spotřebovaných pro její zápis.

  • Indexované vlastnosti: Vlastnosti, které se ve výchozím nastavení indexují, jsou určovány zásadami indexování každého kontejneru. Pokud tedy chcete snížit spotřebu jednotek žádosti pro operace zápisu, omezte počet indexovaných vlastností.

  • Konzistence dat: silná a ohraničená úroveň konzistence odolná proti chybám spotřebovává během operací čtení ve srovnání s jinými uvolněnými úrovněmi konzistence přibližně dvojnásobek více ru.

  • Typ čtení: Point čte náklady významně méně ru než dotazy.

  • Struktura dotazů: Složitost dotazu má vliv na počet jednotek žádosti spotřebovaných operací. Mezi faktory ovlivňující náklady na operace dotazování patří:

    • Počet výsledků dotazu
    • Počet predikátů
    • Povaha predikátů
    • Počet funkcí definovaných uživatelem
    • Velikost zdrojových dat
    • Velikost sady výsledků
    • Projekce

    Stejný dotaz na stejná data bude vždy při opakovaném spuštění ru náklady na stejný počet.

  • Použití skriptu: stejně jako u dotazů, uložené procedury a triggery spotřebovávají ru na základě složitosti operací, které jsou prováděny. Abyste získali lepší přehled o tom, jakou kapacitu (vyjádřenou v jednotkách RU) každá operace spotřebuje, zkontrolujte při vývoji aplikace hlavičku zátěže žádostmi.

Jednotky žádostí a několik oblastí

pokud zřizujete ' r ' ru na kontejneru Cosmos (nebo databázi), Cosmos DB zajistí, že je v každé oblasti přidružené k vašemu účtu Cosmos k dispozici ru r . Ru nelze selektivně přiřadit ke konkrétní oblasti. ru zřízené na kontejneru Cosmos (nebo databázi) se zřídí ve všech oblastech přidružených k vašemu Cosmosmu účtu.

za předpokladu, že je kontejner Cosmos nakonfigurovaný pomocí R ru a ke Cosmos účtu se přidružit N oblastí, celkový ru dostupný globálně na kontejneru = R x N.

Vaše volba modelu konzistence má vliv také na propustnost. V porovnání s silnějšími úrovněmi konzistence můžete získat přibližně dvojnásobnou propustnost čtení pro příznivější úrovně konzistence (například relace, konzistentní předpony a konečná konzistence ).

Další kroky