Výběr klíče oddílu
Mějte na paměti, že data v dokumentech JSON jsou uložená v databázích Azure Cosmos DB v kontejnerech, které se zase distribuují mezi fyzické oddíly a kde se data směrují do příslušného fyzického oddílu na základě hodnoty klíče oddílu.
Klíč oddílu je požadovaná vlastnost dokumentu, která zajišťuje, že dokumenty se stejnou hodnotou klíče oddílu se směrují a ukládají v rámci konkrétního fyzického oddílu. Fyzický oddíl podporuje pevný maximální objem úložiště a propustnosti (RU/s). Azure Cosmos DB automaticky distribuuje logické oddíly mezi dostupné fyzické oddíly, a to s použitím hodnoty klíče oddílu, aby to bylo předvídatelným způsobem.
V této lekci se dozvíte více o logických oddílech a o tom, jak se vyhnout horkým oddílům. Tyto informace nám pomůžou zvolit odpovídající klíč oddílu pro zákaznická data v našem scénáři.
Ve službě Azure Cosmos DB zvýšíte úložiště a propustnost přidáním dalších fyzických oddílů pro přístup k datům a jejich ukládání. Maximální velikost úložiště fyzického oddílu je 50 GB a maximální propustnost je 10 000 RU/s.
Logické oddíly ve službě Azure Cosmos DB
Logický oddíl je abstrakce nad základními fyzickými oddíly. V rámci jednoho fyzického oddílu je možné uložit více logických oddílů. Kontejner může mít neomezený počet logických oddílů. Jednotlivé logické oddíly se přesunou do nových fyzických oddílů, protože se zvětšují, aby se zajistilo optimální využití a růst úložiště. Přesunutí logických oddílů jako jednotky zajišťuje, že se všechny dokumenty v něm nacházejí ve stejném fyzickém oddílu. Maximální velikost logického oddílu je 20 GB. Použití klíče oddílu s vysokou kardinalitou vám umožní vyhnout se tomuto 20GB limitu rozložením dat do většího počtu logických oddílů. Můžete také použít hierarchické klíče oddílů, které uspořádají hodnoty klíče oddílu v hierarchii, aby se zabránilo tomuto limitu. Probíráme je v jiném studijním programu.
Klíč oddílu poskytuje způsob, jak směrovat data pro logický oddíl. Je to vlastnost, která existuje v rámci každého dokumentu v kontejneru, který směruje vaše data. Kontejner je další abstrakce pro všechna data uložená se stejným klíčem oddílu. Klíč oddílu se definuje při vytváření kontejneru.
V následujícím příkladu má kontejner klíč oddílu /username.
Vyhněte se horkým oddílům
Při modelování dat pro službu Azure Cosmos DB je důležité, aby klíč oddílu, který zvolíte, vytvořil rovnoměrné rozdělení dat a požadavků napříč logickým i rozšířením, fyzické oddíly ve vašem kontejneru. To platí zejména v případě, že se kontejnery zvětšují a mají rostoucí počet fyzických oddílů.
Pokud během vývoje neotestujete návrh databáze, která je zatížená, nemusí se odhalit špatná volba klíče oddílu, dokud nebude aplikace v produkčním prostředí a nebudou již zapsána důležitá data.
Pokud data nejsou správně rozdělená, můžou vést k horkým oddílům. Horké oddíly brání škálování úloh vaší aplikace a můžou k nim dojít v úložišti i propustnosti.
Horké oddíly úložiště
Horký oddíl v úložišti nastane, když máte klíč oddílu, který vede k vysoce asymetrickým vzorům úložiště. Představte si například aplikaci s více tenanty, která jako klíč oddílu používá Id tenanta se šesti tenanty: A až F. Tenanty B,C,E a F jsou velmi malé, tenant D má o něco více dat. Tenant A je ale obrovský a rychle dosáhne limitu 20 GB pro svůj oddíl. V tomto scénáři musíme vybrat jiný klíč oddílu, který rozšíří úložiště mezi více logických oddílů.
Horké oddíly propustnosti
Propustnost může trpět horkými oddíly, když většina nebo všechny požadavky přejdou do stejného logického oddílu.
Je důležité porozumět vzorům přístupu pro vaši aplikaci, abyste zajistili, že se požadavky rovnoměrně rozloží mezi hodnoty klíče oddílu. Pokud je pro kontejner ve službě Azure Cosmos DB zřízená propustnost, přiděluje se rovnoměrně napříč všemi fyzickými oddíly v rámci kontejneru.
Pokud máte například kontejner s 30 000 RU/s, tato úloha se rozdělí mezi tři fyzické oddíly pro stejných šest tenantů uvedených dříve. Každý fyzický oddíl tedy získá 10 000 RU/s. Pokud tenant D využívá všech svých 10 000 RU/s, bude omezený rychlostí, protože nemůže spotřebovat propustnost přidělenou ostatním oddílům. Výsledkem je nízký výkon tenanta C a D a ponechání nevyužité výpočetní kapacity v ostatních fyzických oddílech a zbývajících tenantech. Tento klíč oddílu nakonec vede k návrhu databáze, ve kterém se úloha aplikace nemůže škálovat.
Při rovnoměrné distribuci dat a požadavků může databáze růst způsobem, který plně využívá úložiště i propustnost. Výsledkem bude nejlepší možný výkon a nejvyšší efektivita. Stručně řečeno, návrh databáze se škáluje.
Zvažte čtení a zápisy.
Při výběru klíče oddílu je také potřeba zvážit, jestli jsou data velká nebo zapisovaná. Měli byste se snažit distribuovat požadavky náročné na zápis s klíčem oddílu, který má vysokou kardinalitu.
U úloh náročných na čtení byste měli zajistit, aby dotazy byly zpracovány jedním nebo omezeným počtem oddílů zahrnutím WHERE klauzule s filtrem rovnosti na klíč oddílu nebo operátorEM IN v podmnožině hodnot klíče oddílu v dotazech.
Ve scénářích, ve kterých je úloha aplikace náročné na zápis i čtení, existuje řešení. Prozkoumáme ho v dalším modulu.
Následující obrázek ukazuje kontejner, který je rozdělený podle uživatelského jména. Tento dotaz dosáhne pouze jednoho logického oddílu, takže jeho výkon bude vždy dobrý.
Dotaz, který filtruje jinou vlastnost, například favoriteColor"rozdám" pro všechny oddíly v kontejneru. To se také označuje jako dotaz napříč oddíly. Takový dotaz bude fungovat podle očekávání, když je kontejner malý a zabírá pouze jeden oddíl. S rostoucím počtem fyzických oddílů ale bude tento dotaz pomalejší a dražší, protože bude muset zkontrolovat každý oddíl, aby získal výsledky bez ohledu na to, jestli fyzický oddíl obsahuje data související s dotazem.
Volba klíče oddílu pro zákazníky
Když teď rozumíte dělení ve službě Azure Cosmos DB, můžeme se rozhodnout o klíči oddílu pro naše zákaznická data. Jak jsme si probrali dříve, provádíme u zákazníků tři operace: vytvoření zákazníka, aktualizaci zákazníka a načtení zákazníka. V tomto případě načteme zákazníka podle jeho ID. Vzhledem k tomu, že se tato operace bude volat nejvíce, je vhodné, aby ID zákazníka bylo klíčem oddílu kontejneru.
Můžete se zde obávat, že vytvoření ID klíče oddílu znamená, že budeme mít tolik logických oddílů, kolik existuje zákazníků, přičemž každý logický oddíl obsahuje jenom jeden dokument. Miliony zákazníků by výsledkem byly miliony logických oddílů.
Ale to je naprosto v pořádku! Logické oddíly představují virtuální koncept a neexistuje žádné omezení počtu logických oddílů, které můžete mít. Azure Cosmos DB shromáždí několik logických oddílů ve stejném fyzickém oddílu. S rostoucím počtem nebo velikostí logických oddílů je Cosmos DB v případě potřeby přesune do nových fyzických oddílů.