Osvědčené postupy pro škálování zřízené propustnosti (RU/s)

PLATÍ PRO: NoSQL MongoDB Cassandra Skřítek Stůl

Tento článek popisuje osvědčené postupy a strategie škálování propustnosti (RU/s) databáze nebo kontejneru (kolekce, tabulky nebo grafu). Tyto koncepty platí při zvyšování zřízeného ručního počtu RU/s nebo maximálního maximálního počtu RU/s automatického škálování jakéhokoli prostředku pro libovolná rozhraní API služby Azure Cosmos DB.

Požadavky

• Pokud s dělením a škálováním ve službě Azure Cosmos DB teprve začínáte, doporučujeme nejprve si přečíst článek Dělení a horizontální škálování ve službě Azure Cosmos DB.
• Pokud plánujete škálovat ru/s kvůli 429 výjimkám, projděte si pokyny v tématu Diagnostika a řešení potíží s příliš velkými výjimkami požadavků služby Azure Cosmos DB (429). Než zvýšíte počet RU/s, identifikujte původní příčinu problému a zjistěte, jestli je správným řešením zvýšení POČTU RU/s.

Pozadí škálování RU/s

Když odešlete požadavek na navýšení počtu RU/s databáze nebo kontejneru v závislosti na požadovaných RU/s a aktuálním rozložení fyzického oddílu, operace vertikálního navýšení kapacity se buď okamžitě nebo asynchronně dokončí (obvykle 4 až 6 hodin).

• Okamžité vertikální navýšení kapacity
  • Pokud požadovaná RU/s může být podporována aktuálním rozložením fyzického oddílu, Azure Cosmos DB nemusí rozdělovat ani přidávat nové oddíly.
  • V důsledku toho se operace okamžitě dokončí a RU/s jsou k dispozici k použití.
• Asynchronní vertikální navýšení kapacity
  • Pokud je požadovaná hodnota RU/s vyšší, než co může podporovat rozložení fyzických oddílů, Azure Cosmos DB rozdělí existující fyzické oddíly. K tomu dochází, dokud prostředek nebude mít minimální počet oddílů potřebných pro podporu požadované hodnoty RU/s.
  • V důsledku toho může dokončení operace nějakou dobu trvat, obvykle 4 až 6 hodin. Každý fyzický oddíl může podporovat maximálně 10 000 RU/s (platí pro všechna rozhraní API) propustnosti a 50 GB úložiště (platí pro všechna rozhraní API s výjimkou Cassandry, která má 30 GB úložiště).

Poznámka:

Pokud provedete ruční operaci převzetí služeb při selhání oblasti nebo přidáte nebo odeberete novou oblast , zatímco probíhá asynchronní operace vertikálního navýšení kapacity, operace vertikálního navýšení kapacity propustnosti se pozastaví. Po dokončení operace převzetí služeb při selhání nebo přidání nebo odebrání oblasti se automaticky obnoví.

• Okamžité vertikální snížení kapacity
  • Pro operaci vertikálního snížení kapacity azure Cosmos DB není potřeba rozdělit ani přidávat nové oddíly.
  • V důsledku toho se operace okamžitě dokončí a RU/s jsou k dispozici k použití,
  • Klíčovým výsledkem této operace je snížení počtu RU na fyzický oddíl.

Vertikální navýšení kapacity RU/s beze změny rozložení oddílů

Krok 1: Vyhledání aktuálního počtu fyzických oddílů

Přejděte na Přehledy>>normalizované spotřeby RU (%) podle PartitionKeyRangeID. Spočítejte jedinečný počet PartitionKeyRangeIds.

Poznámka:

Graf zobrazí maximálně 50 PartitionKeyRangeIds. Pokud má váš prostředek více než 50, můžete pomocí rozhraní REST API služby Azure Cosmos DB spočítat celkový počet oddílů.

Každý PartitionKeyRangeId se mapuje na jeden fyzický oddíl a je přiřazen k uložení dat pro rozsah možných hodnot hash.

Azure Cosmos DB distribuuje vaše data napříč logickými a fyzickými oddíly na základě klíče oddílu, aby bylo možné horizontální škálování. Při zápisu dat azure Cosmos DB používá hodnotu hash klíče oddílu k určení logického a fyzického oddílu, ve kterém se data nacházejí.

Krok 2: Výpočet výchozí maximální propustnosti

Nejvyšší počet RU/s, které můžete škálovat bez aktivace služby Azure Cosmos DB pro rozdělení oddílů, se rovná Current number of physical partitions * 10,000 RU/s. Tuto hodnotu můžete získat od poskytovatele prostředků Azure Cosmos DB. Proveďte požadavek GET na objekty nastavení propustnosti databáze nebo kontejneru a načtěte instantMaximumThroughput vlastnost. Tato hodnota je dostupná také na stránce Škálování a nastavení databáze nebo kontejneru na portálu.

Příklad

Předpokládejme, že máme existující kontejner s pěti fyzickými oddíly a 30 000 RU/s ruční zřízené propustnosti. Počet RU/s můžeme okamžitě zvýšit na 5 × 10 000 RU/s = 50 000 RU/s. Podobně pokud bychom měli kontejner s maximálním maximálním limitem RU/s automatického škálování 30 000 RU/s (škáluje se mezi 3000 až 30 000 RU/s), mohli bychom naše maximální počet RU/s okamžitě zvýšit na 50 000 RU/s (škáluje se mezi 5000 až 50 000 RU/s).

Tip

Pokud vertikálně navyšujete počet RU/s tak, aby reagoval na příliš velké výjimky (429), doporučujeme nejprve zvýšit počet RU/s na nejvyšší počet RU/s, které jsou podporovány aktuálním rozložením fyzického oddílu, a posoudit, jestli nové RU/s nestačí, a teprve potom se zvýšit.

Jak zajistit rovnoměrnou distribuci dat během asynchronního škálování

Pozadí

Když zvýšíte počet RU/s nad aktuální počet fyzických oddílů * 10 000 RU/s, Azure Cosmos DB rozdělí existující oddíly až do nového počtu oddílů = ROUNDUP(requested RU/s / 10,000 RU/s). Během rozdělení jsou nadřazené oddíly rozdělené do dvou podřízených oddílů.

Předpokládejme například, že máme kontejner se třemi fyzickými oddíly a 30 000 RU/s ruční zřízené propustnosti. Pokud bychom zvýšili propustnost na 45 000 RU/s, Azure Cosmos DB rozdělí dva z existujících fyzických oddílů, aby celkem bylo ROUNDUP(45,000 RU/s / 10,000 RU/s) 5 fyzických oddílů.

Poznámka:

Aplikace můžou během dělení vždy přijímat a dotazovat data. Klientské sady SDK a služba Azure Cosmos DB tento scénář automaticky zpracovávají a zajistěte, aby se požadavky směrovaly do správného fyzického oddílu, takže není nutná žádná další akce uživatele.

Pokud máte úlohu, která je velmi rovnoměrně distribuovaná s ohledem na svazek úložiště a požadavků – obvykle se provádí dělením podle polí s vysokou kardinalitou, jako je /id, doporučujeme při vertikálním navýšení kapacity nastavit RU/s tak, aby se všechny oddíly rovnoměrně rozdělily.

Abychom zjistili, proč, podívejme se na příklad, kde máme existující kontejner se 2 fyzickými oddíly, 20 000 RU/s a 80 GB dat.

Díky výběru vhodného klíče oddílu s vysokou kardinalitou se data zhruba rovnoměrně distribuují v obou fyzických oddílech. Každému fyzickému oddílu je přiřazeno přibližně 50 % prostoru klíčů, který je definován jako celkový rozsah možných hodnot hash.

Kromě toho Azure Cosmos DB distribuuje RU/s rovnoměrně napříč všemi fyzickými oddíly. V důsledku toho má každý fyzický oddíl 10 000 RU/s a 50 % (40 GB) celkových dat. Následující diagram znázorňuje náš aktuální stav.

Předpokládejme, že chceme zvýšit počet RU/s z 20 000 RU/s na 30 000 RU/s.

Pokud bychom jednoduše zvýšili počet RU/s na 30 000 RU/s, rozdělí se jenom jeden z oddílů. Po rozdělení budeme mít:

• Jeden oddíl, který obsahuje 50 % dat (tento oddíl nebyl rozdělený)
• Dva oddíly, které obsahují 25 % dat (jedná se o výsledné podřízené oddíly z nadřazené položky, která byla rozdělena)

Vzhledem k tomu, že Azure Cosmos DB rovnoměrně distribuuje RU/s napříč všemi fyzickými oddíly, každý fyzický oddíl stále získá 10 000 RU/s. Teď ale máme nerovnoměrnou distribuci úložiště a požadavků.

V následujícím diagramu vidíme, že oddíly 3 a 4 (podřízené oddíly oddílu 2) mají 10 000 RU/s, aby mohly obsluhovat požadavky na 20 GB dat, zatímco oddíl 1 má 10 000 RU/s, aby mohl obsluhovat žádosti o dvojnásobné množství dat (40 GB).

Abychom zachovali rovnoměrnou distribuci úložiště, můžeme nejprve vertikálně navýšit kapacitu RU/s, abychom zajistili rozdělení všech oddílů. Pak můžeme snížit počet RU/s zpět na požadovaný stav.

Pokud tedy začneme se dvěma fyzickými oddíly, abychom zajistili, že jsou oddíly ještě po rozdělení, musíme nastavit RU/s tak, abychom skončili se čtyřmi fyzickými oddíly. Abychom toho dosáhli, nejprve nastavíme RU/s = 4 × 10 000 RU/s na oddíl = 40 000 RU/s. Po dokončení rozdělení můžeme snížit počet RU/s na 30 000 RU/s.

V následujícím diagramu vidíme, že každý fyzický oddíl získá 30 000 RU/s / 4 = 7500 RU/s pro obsluhu požadavků na 20 GB dat. Celkově udržujeme i úložiště a distribuci požadavků napříč oddíly.

Obecný vzorec

Krok 1: Zvyšte počet RU/s, abyste zajistili rovnoměrné rozdělení všech oddílů

Obecně platí, že pokud máte počáteční počet fyzických oddílů Pa chcete nastavit požadované RU/s S:

Zvyšte počet RU/s na: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Tím získáte nejbližší RU/s k požadované hodnotě, která zajistí rovnoměrné rozdělení všech oddílů.

Poznámka:

Když zvýšíte počet RU/s databáze nebo kontejneru, může to mít vliv na minimální počet RU/s, které můžete v budoucnu snížit. Minimum RU/s se obvykle rovná MAX(400 RU/s, aktuální úložiště v GB × 1 RU/s, nejvyšší RU/s, kdy zřízené / 100). Pokud je například nejvyšší počet RU/s, na který jste kdy škálovali, 100 000 RU/s, nejnižší POČET RU/s, které můžete nastavit v budoucnu, je 1000 RU/s. Přečtěte si další informace o minimálních RU/s.

Krok 2: Snížení počtu RU/s na požadované RU/s

Předpokládejme například, že máme pět fyzických oddílů, 50 000 RU/s a chceme škálovat na 150 000 RU/s. Nejprve bychom měli nastavit: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200 000 RU/s a pak snížit na 150 000 RU/s.

Když jsme vertikálně nastavili kapacitu až 200 000 RU/s, nejnižší ruční POČET RU/s, které teď můžeme nastavit v budoucnu, je 2000 RU/s. Nejnižší maximální počet RU/s automatického škálování, který můžeme nastavit, je 20 000 RU/s (škálování mezi 2000 až 20 000 RU/s). Vzhledem k tomu, že naše cílová RU/s je 150 000 RU/s, nemáme vliv na minimální počet RU/s.

Optimalizace RU/s pro příjem velkých objemů dat

Pokud plánujete migrovat nebo ingestovat velké množství dat do služby Azure Cosmos DB, doporučujeme nastavit RU/s kontejneru tak, aby služba Azure Cosmos DB předem zřídila fyzické oddíly potřebné k uložení celkového množství dat, která plánujete předem ingestovat. V opačném případě může azure Cosmos DB během příjmu dat muset rozdělit oddíly, které přidají více času k příjmu dat.

Můžeme využít skutečnost, že během vytváření kontejneru azure Cosmos DB používá heuristický vzorec spouštění RU/s k výpočtu počtu fyzických oddílů, se kterými se má začít.

Krok 1: Kontrola výběru klíče oddílu

Při výběru klíče oddílu postupujte podle osvědčených postupů , abyste měli jistotu, že budete mít i distribuci svazku požadavků a úložiště po migraci.

Krok 2: Výpočet počtu fyzických oddílů, které budete potřebovat

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Každý fyzický oddíl může obsahovat maximálně 50 GB úložiště (30 GB pro rozhraní API pro Cassandra). Hodnota, kterou byste měli zvolit, Target data per physical partition in GB závisí na tom, jak plně zabalené mají být fyzické oddíly a kolik očekáváte, že úložiště bude po migraci růst.

Pokud například předpokládáte, že úložiště bude i nadále růst, můžete nastavit hodnotu na 30 GB. Za předpokladu, že jste zvolili dobrý klíč oddílu, který rovnoměrně distribuuje úložiště, bude každý oddíl plný přibližně 60 % (30 GB z 50 GB). Při zápisu budoucích dat je možné je uložit do existující sady fyzických oddílů, aniž by služba vyžadovala okamžité přidání dalších fyzických oddílů.

Pokud se naopak domníváte, že se úložiště po migraci výrazně nezvětší, můžete nastavit vyšší hodnotu, například 45 GB. To znamená, že každý oddíl bude plný přibližně 90 % (45 GB z 50 GB). Tím se minimalizuje počet fyzických oddílů, mezi kterými jsou vaše data rozložená, což znamená, že každý fyzický oddíl může získat větší část celkového zřízeného POČTU RU/s.

Krok 3: Výpočet počtu RU/s pro všechny oddíly

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition.

Začněme příkladem s libovolným počtem cílových RU/s na fyzický oddíl.

• Initial throughput per physical partition = 10 000 RU/s na fyzický oddíl při použití automatického škálování nebo databází se sdílenou propustností
• Initial throughput per physical partition = 6000 RU/s na fyzický oddíl při použití ruční propustnosti

Příklad

Řekněme, že máme 1 TB (1000 GB) dat, která plánujeme ingestovat, a chceme použít ruční propustnost. Každý fyzický oddíl ve službě Azure Cosmos DB má kapacitu 50 GB. Předpokládejme, že se snažíme zabalit oddíly na 80 % (40 GB), takže máme prostor pro budoucí růst.

To znamená, že pro 1 TB dat budeme potřebovat 1000 GB / 40 GB = 25 fyzických oddílů. Abychom zajistili, že získáme 25 fyzických oddílů, pokud používáme ruční propustnost, nejprve zřídíme 25 × 6000 RU/s = 150 000 RU/s. Potom po vytvoření kontejneru zvýšíme počet RU/s na 250 000 RU/s před zahájením příjmu dat (k ingestování dojde okamžitě, protože už máme 25 fyzických oddílů). Každý oddíl tak získá maximálně 10 000 RU/s.

Pokud používáme propustnost automatického škálování nebo databázi se sdílenou propustností, abychom získali 25 fyzických oddílů, nejprve zřídíme 25 × 10 000 RU/s = 250 000 RU/s. Vzhledem k tomu, že již máme nejvyšší počet RU/s, které je možné podporovat s 25 fyzickými oddíly, nezvětšíme před příjmem dat zřízené RU/s.

Teoreticky, s 250 000 RU/s a 1 TB dat, pokud předpokládáme 1kb dokumenty a 10 RU vyžadované pro zápis, příjem dat může teoreticky dokončit v: 1000 GB * (1 000 000 kb / 1 GB) * (1 dokument / 1 kB) * (10 RU / dokument) * (1 s / 250 000 RU) * (1 hodina / 3600 sekund) = 11,1 hodiny.

Tento výpočet představuje odhad za předpokladu, že klient provádějící příjem dat může plně saturovat propustnost a distribuovat zápisy napříč všemi fyzickými oddíly. Osvědčeným postupem je "prohazovat" data na straně klienta. Tím se zajistí, že každý druhý klient zapisuje do mnoha různých logických (a tedy fyzických) oddílů.

Po dokončení migrace můžeme snížit počet RU/s nebo podle potřeby povolit automatické škálování.

Další kroky

• Monitorujte normalizovanou spotřebu RU/s databáze nebo kontejneru.
• Diagnostika a řešení potíží s příliš velkými výjimkami (429) požadavků
• Povolení automatického škálování v databázi nebo kontejneru