Dělení a horizontální škálování v Azure Cosmos DB

  • Platí pro: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB používá dělení na oddíly ke škálování kontejnerů v databázi tak, aby splňovaly požadavky vaší aplikace na výkon. Položky v kontejneru jsou rozdělené na různé podmnožina označované jako logické oddíly. Logické oddíly jsou založeny na hodnotě klíče oddílu přidruženého ke každé položce v kontejneru. Všechny položky v logickém oddílu mají stejnou hodnotu klíče oddílu.

Kontejner například obsahuje položky. Každá položka má jedinečnou hodnotu vlastnosti UserID . Pokud UserID slouží jako klíč oddílu pro položky v kontejneru a existuje 1 000 jedinečných UserID hodnot, vytvoří se pro kontejner 1 000 logických oddílů.

Každá položka v kontejneru má klíč oddílu , který určuje jeho logický oddíl a ID položky jedinečné v rámci daného oddílu. Kombinace klíče oddílu a ID položky vytvoří index položky, který položku jednoznačně identifikuje. Výběr klíče oddílu je důležitým rozhodnutím, které ovlivňuje výkon vaší aplikace.

Note

V některých distribuovaných databázových systémech a výukových materiálech se termín shard key používá k popisu vlastnosti, která určuje způsob distribuce dat napříč shardy. V Azure Cosmos DB se tento koncept nazývá klíč oddílu.

Oba termíny odkazují na hodnotu použitou k distribuci a vyhledání dat, ale klíč oddílu je oficiální a správný termín používaný v dokumentaci a rozhraních API služby Azure Cosmos DB.

Tento článek vysvětluje vztah mezi logickými a fyzickými oddíly, popisuje osvědčené postupy pro dělení a podrobně popisuje, jak funguje horizontální škálování v Azure Cosmos DB. Abyste mohli vybrat klíč oddílu, nemusíte rozumět těmto interním podrobnostem, ale tento článek je objasňuje, aby bylo jasné, jak Azure Cosmos DB funguje.

Logické oddíly

Logický oddíl je sada položek, které sdílejí stejný klíč oddílu. Například v kontejneru, který obsahuje data o výživě potravin, všechny položky obsahují foodGroup vlastnost. Použijte foodGroup jako klíč oddílu pro kontejner. Skupiny položek, které mají specifické hodnoty pro foodGroup, například Beef Products, Baked Productsa Sausages and Luncheon Meats, tvoří odlišné logické oddíly.

Logický oddíl také definuje rozsah databázových transakcí. Položky v rámci logického oddílu můžete aktualizovat pomocí transakce se snímkovou izolací. Když se do kontejneru přidají nové položky, systém transparentně vytvoří nové logické oddíly. Nemusíte se obávat o odstranění logického oddílu, když jsou odstraněna podkladová data.

Počet logických oddílů v kontejneru není nijak omezen. Každý logický oddíl může ukládat až 20 GB dat. Efektivní klíče oddílů mají širokou škálu možných hodnot. Například v kontejneru, kde všechny položky obsahují foodGroup vlastnost, mohou data v logickém oddílu Beef Products růst až o 20 GB. Výběr klíče oddílu s širokou škálou možných hodnot zajistí, že kontejner může škálovat.

Pokud máte scénáře, ve kterých klíče oddílů můžou překročit 20 GB dat, mohou vám pomoci hierarchické klíče oddílů. Pokud tuto funkci používáte, můžete pro klíče oddílů nakonfigurovat až tříúrovňovou hierarchii, abyste mohli dále optimalizovat distribuci dat a vyšší úroveň škálování. Podívejte se napřehled klíčů hierarchických oddílů.

Pomocí upozornění služby Azure Monitor můžete monitorovat, jestli velikost logického oddílu blíží 20 GB.

Fyzické oddíly

Kontejner se škáluje tak, že distribuuje data a propustnost napříč fyzickými oddíly. Jeden nebo více logických oddílů se interně mapuje na jeden fyzický oddíl. Menší kontejnery mají obvykle mnoho logických oddílů, ale potřebují pouze jeden fyzický oddíl. Na rozdíl od logických oddílů jsou fyzické oddíly interní implementací systému a Azure Cosmos DB je plně spravuje.

Počet fyzických oddílů v kontejneru závisí na těchto vlastnostech:

  • Množství zřízené propustnosti (každý jednotlivý fyzický oddíl může poskytovat propustnost až 10 000 jednotek požadavků za sekundu). Limit 10 000 RU/s pro fyzické oddíly znamená, že logické oddíly mají také limit 10 000 RU/s, protože každý logický oddíl je mapován pouze na jeden fyzický oddíl.

  • Celkové úložiště dat (každý fyzický oddíl může ukládat až 50 gigabajtů dat).

Note

Fyzické oddíly jsou interní implementací systému, která je plně spravovaná službou Azure Cosmos DB. Při vývoji řešení se nezaměřte na fyzické oddíly, protože je nemůžete ovládat. Místo toho se zaměřte na klíče oddílů. Volba klíče oddílu, který rovnoměrně distribuuje spotřebu propustnosti napříč logickými oddíly, zajišťuje vyváženou spotřebu propustnosti napříč fyzickými oddíly.

Celkový počet fyzických oddílů v kontejneru není nijak omezený. S rostoucí zřízenou propustností nebo velikostí dat Azure Cosmos DB automaticky vytváří nové fyzické oddíly rozdělením existujících oddílů. Rozdělení fyzických oddílů nemá vliv na dostupnost vaší aplikace. Po rozdělení fyzického oddílu budou všechna data v rámci jednoho logického oddílu stále uložena ve stejném fyzickém oddílu. Rozdělení fyzického oddílu jednoduše vytvoří nové mapování logických oddílů na fyzické oddíly.

Udělená propustnost pro kontejner se rovnoměrně rozdělí mezi fyzické oddíly. Návrh klíče oddílu, který nedistribuuje požadavky rovnoměrně, může vést k tomu, že mnoho požadavků bude směrováno do malé části oddílů, které se stanou "horkými". Horké oddíly způsobují neefektivní využití přidělené propustnosti, což může vést k omezení rychlosti a vyšším nákladům.

Představte si například kontejner s cestou /foodGroup zadanou jako klíč oddílu. Kontejner může mít libovolný počet fyzických oddílů, ale v tomto příkladu předpokládáme, že má tři oddíly. Jeden fyzický oddíl může obsahovat více klíčů oddílu. Například největší fyzický oddíl může obsahovat tři největší logické oddíly s největší velikostí: Beef Products, Vegetable and Vegetable Productsa Soups, Sauces, and Gravies.

Pokud přiřadíte propustnost 18 000 jednotek žádostí za sekundu (RU/s), každý ze tří fyzických oddílů používá jednu třetinu celkové zřízené propustnosti. V rámci vybraného fyzického oddílu můžou klíče logického oddílu Beef Products, Vegetable and Vegetable Products a Soups, Sauces, and Gravies společně využívat 6 000 rezervovaných RU/s fyzického oddílu. Protože je zřízená propustnost rovnoměrně rozdělena mezi fyzické oddíly vašeho kontejneru, je důležité zvolit klíč oddílu, který rovnoměrně rozděluje spotřebu propustnosti. Další informace najdete v tématu Volba správného klíče logického oddílu.

Správa logických oddílů

Azure Cosmos DB automaticky spravuje umístění logických oddílů na fyzické oddíly tak, aby vyhovovalo požadavkům na škálovatelnost a výkon kontejneru. Když se zvýší požadavky na propustnost a úložiště aplikace, Azure Cosmos DB přesune logické oddíly, aby se zatížení rozložilo mezi více fyzických oddílů. Přečtěte si další informace o fyzických oddílech.

Azure Cosmos DB používá dělení založené na hodnotě hash k distribuci logických oddílů mezi fyzické oddíly. Azure Cosmos DB zahashuje hodnotu klíče oddílu položky. Hashedovaný výsledek určuje logickou partition. Pak Azure Cosmos DB rovnoměrně přidělí prostor hash klíčů oddílů napříč fyzickými oddíly.

Transakce v uložených procedurách nebo triggerech jsou povoleny pouze pro položky v jednom logickém oddílu.

Replikační sady

Každý fyzický oddíl se skládá ze sady replik, označovaných také jako sada replik. Každá replika hostuje instanci databázového stroje. Sada replik zajišťuje, že datové úložiště v rámci fyzického oddílu je trvalé, vysoce dostupné a konzistentní. Každá replika ve fyzickém oddílu dědí kvótu úložiště tohoto oddílu. Všechny repliky fyzického oddílu společně podporují propustnost přidělenou danému fyzickému oddílu. Azure Cosmos DB automaticky spravuje sady replik.

Menší kontejnery obvykle vyžadují jediný poddíl, ale i tak mají alespoň čtyři repliky.

Tento obrázek ukazuje, jak se logické oddíly mapují na fyzické oddíly, které jsou globálně rozprostřené. Sada oddílů v obrazu odkazuje na skupinu fyzických oddílů, které spravují stejné klíče logického oddílu napříč několika oblastmi.

Diagram znázorňující dělení služby Azure Cosmos DB

Vyberte klíč oddílu

Klíč oddílu má dvě komponenty: cesta klíče oddílu a hodnota klíče oddílu. Představte si například položku { "userId" : "Andrew", "worksFor": "Microsoft" }, pokud jako klíč oddílu zvolíte "userId", jedná se o dvě komponenty klíče oddílu:

  • Cesta klíče oddílu (například: "/userId"). Cesta klíče oddílu přijímá alfanumerické znaky a podtržítka (_). Vnořené objekty můžete použít také pomocí standardní notace cesty(/).

  • Hodnota klíče oddílu (například „Andrew“). Hodnota klíče oddílu může být řetězcového nebo číselného typu.

Informace o omezeních týkajících se propustnosti, úložiště a délky klíče oddílu najdete v článku o kvótách služby Azure Cosmos DB.

Výběr klíče oddílu je jednoduchá, ale důležitá volba návrhu v Azure Cosmos DB. Jakmile vyberete klíč oddílu, nemůžete ho změnit. Pokud potřebujete změnit klíč oddílu, přesuňte data do nového kontejneru s požadovaným klíčem oddílu. Úlohy kopírování kontejnerů pomáhají s tímto procesem. Alternativně můžete přidat globální sekundární indexy (Preview) a vytvořit kopie dat s různými klíči oddílů optimalizovanými pro konkrétní vzory dotazů.

Pro všechny kontejnery by měl klíč oddílu být:

  • Buďte vlastností, která má hodnotu, která se nemění. Pokud je vlastnost vaším klíčem oddílu, nemůžete hodnotu této vlastnosti aktualizovat.

    Important

    Hodnoty klíče oddílu jsou neměnné. Po vytvoření položky nelze hodnotu klíče oddílu změnit. Operace nahrazení položky vyžaduje, aby klíč oddílu odpovídal existující položce – nelze ji použít k přesunutí položky mezi oddíly. Pokud chcete položku přesunout, musíte vytvořit novou položku s novou hodnotou klíče oddílu a odstranit původní položku. Tyto dvě operace nelze provádět atomicky napříč různými logickými oddíly.

  • Obsahují pouze String hodnoty – nebo převeďte čísla na String čísla, pokud by mohly překročit hranice dvojitých přesností podle standardu IEEE (Institute of Electrical and Electronics Engineers) 754 binary64. Specifikace JSON vysvětluje, proč je použití čísel mimo tuto hranici špatným postupem kvůli problémům s interoperabilitou. Tyto obavy jsou zvláště důležité pro sloupec klíče oddílu, protože je neměnný a vyžaduje, aby se migrace dat později změnila.

  • Má vysokou kardinalitu. Jinými slovy, vlastnost by měla mít širokou škálu možných hodnot.

  • Rovnoměrně rozložte spotřebu jednotek žádostí (RU) a ukládání dat mezi všechny logické oddíly. Toto rozložení zajišťuje rovnoměrnou spotřebu RU a distribuci úložiště napříč fyzickými oddíly.

  • Mají hodnoty, které nejsou větší než 2048 bajtů, obvykle nebo 101 bajtů, pokud nejsou povolené velké klíče oddílů. Další informace najdete v části velké klíče oddílů

Pokud potřebujete transakce ACID s více položkami ve službě Azure Cosmos DB, musíte použít uložené procedury nebo triggery. Všechny uložené procedury a triggery založené na JavaScriptu jsou vymezeny na jeden logický oddíl.

Note

Pokud máte jenom jeden fyzický oddíl nebo je počet oddílů malý, například <= 5, hodnota klíče oddílu nemusí být relevantní. U dotazů je režie při kontrole každého dalšího fyzického oddílu v případě, že klíč oddílu není zahrnutý, 2 až 3 RU na fyzický oddíl. Přečtěte si další informace o fyzických oddílech.

Typy klíčů oddílů

Strategie particionování Kdy ho použít Výhody Nevýhody
Běžný klíč oddílu (například CustomerId, OrderId) Použijte, když má klíč oddílu vysokou kardinalitu a odpovídá vzorům dotazu (například filtrování podle CustomerId). Vhodné pro úlohy, u kterých dotazy většinou cílí na data jednoho zákazníka (například načítání všech objednávek pro zákazníka). Správa je jednoduchá. Efektivní dotazy, když vzor přístupu odpovídá klíči oddílu (například dotazování všech objednávek podle CustomerId). Zabraňuje dotazům napříč oddíly, pokud jsou vzory přístupu konzistentní. Riziko horkých partičních oblastí, pokud některé položky (například několik náročnějších zákazníků) generují více dat než jiné. Pokud objem dat pro konkrétní klíč rychle roste, může dojít k dosažení limitu 20 GB na logický oddíl.
Syntetický klíč oddílu (například CustomerId + OrderDate) Použijte, když žádné jednotlivé pole nemá vysokou kardinalitu a zároveň neodpovídá vzorům dotazu. Vhodné pro úlohy náročné na zápis, kde je potřeba rovnoměrně distribuovat data napříč fyzickými oddíly (například mnoho objednávek zadaných ke stejnému datu). Pomáhá rovnoměrně distribuovat data mezi oddíly, což zamezuje vzniku horkých oddílů (například distribuci objednávek podle ID zákazníka i data objednávky). Rozdělí operace zápisu do více oddílů a zvýší propustnost. Dotazy, které filtrují pouze podle jednoho pole (například pouze Id zákazníka), můžou vést k dotazům napříč oddíly. Dotazy napříč oddíly můžou vést k vyšší spotřebě RU (2–3 RU/s navíc za každý fyzický oddíl, který existuje) a zvýšení latence.
Hierarchický klíč oddílu (HPK) (například CustomerId/OrderId, StoreId/ProductId) Používejte, když potřebujete víceúrovňové dělení pro podporu rozsáhlých datových sad. Ideální, když dotazy filtrují první a druhou úroveň hierarchie. Pomáhá vyhnout se limitu 20 GB vytvořením více úrovní dělení. Efektivní dotazování na obě hierarchické úrovně (například filtrování podle ID zákazníka a potom podle ID objednávky). Minimalizuje dotazy napříč oddíly pro dotazy, které cílí na nejvyšší úroveň (například načítání všech dat z konkrétního ID zákazníka). Vyžaduje pečlivé plánování, aby se zajistilo, že klíč první úrovně má vysokou kardinalitu a je součástí většiny dotazů. Správa je složitější než u běžného klíče oddílu. Pokud dotazy nejsou v souladu s hierarchií (například filtrování pouze podle ID objednávky, pokud je ID zákazníka první úroveň), může dojít k snížení výkonu dotazů.
Globální sekundární index (GSI) – Preview (například zdroj používá CustomerId, GSI používá OrderId). Použijte, když nemůžete najít jediný klíč oddílu, který by vyhovoval všem vzorům dotazů. Ideální pro úlohy, které efektivně dotazují více nezávislých vlastností a mají velký počet fyzických oddílů. Eliminuje dotazy napříč oddíly při použití klíče oddílu GSI. Umožňuje více vzorů dotazů na stejná data s automatickou synchronizací ze zdrojového kontejneru. Izolace výkonu mezi úlohami Každá GSI má další náklady na úložiště a RU. Data v GSI jsou nakonec konzistentní se zdrojovým kontejnerem.

Klíče oddílů pro kontejnery s vysokými nároky na čtení

U většiny kontejnerů je potřeba při výběru klíče oddílu vzít v úvahu všechna tato kritéria. U velkých kontejnerů náročných na čtení ale můžete chtít zvolit klíč oddílu, který se v dotazech často zobrazuje jako filtr. Zahrnutí klíče oddílu do predikátu filtru umožňuje efektivní směrování dotazů pouze na relevantní fyzické oddíly.

Vlastnost je vhodnou volbou pro klíč oddílu, pokud většina požadavků vaší pracovní zátěže jsou dotazy a většina těchto dotazů používá filtr rovnosti na stejné vlastnosti. Pokud například často spouštíte dotaz, který filtruje UserID, výběr UserID jako klíč oddílu by snížil počet dotazů napříč oddíly.

Pokud je váš kontejner malý, pravděpodobně nemáte dostatek fyzických diskových oddílů, aby vás musel znepokojovat výkon dotazů mezi oddíly. Většina malých kontejnerů v Azure Cosmos DB vyžaduje pouze jeden nebo dva fyzické oddíly.

Pokud by se kontejner mohl zvětšit na více než několik fyzických oddílů, měli byste se ujistit, že jste vybrali klíč oddílu, který minimalizuje dotazy napříč oddíly. Pokud platí některý z následujících scénářů, váš kontejner potřebuje více než několik fyzických oddílů:

  • Váš kontejner má přiděleno více než 30 000 jednotek žádostí.

  • Kontejner ukládá více než 100 GB dat.

Globální sekundární indexy pro dotazy napříč oddíly

Pokud vaše aplikace potřebuje dotazovat data pomocí několika různých vlastností efektivně, globální sekundární indexy (Preview) poskytují alternativu k použití jedné strategie klíče oddílu pro datovou sadu. Globální sekundární indexy jsou další kontejnery s různými klíči oddílů, které se automaticky synchronizují s daty ze zdrojového kontejneru.

Zvažte globální sekundární indexy v případech:

  • Máte různé vzory dotazů, které nelze splnit jedinou strategií dělicího klíče.
  • Změna existujícího klíče oddílu by byla rušivá
  • Potřebujete izolovat analytické úlohy nebo úlohy vyhledávání od transakčních operací.

Globální sekundární indexy pomáhají vyhnout se dotazům napříč oddíly tím, že ukládají stejná data s různými klíči oddílů optimalizovanými pro konkrétní vzory dotazů. Tento přístup může podstatně snížit spotřebu RU a zvýšit výkon dotazů v případech, kdy samotná optimalizace klíče oddílu nestačí.

Použijte ID položky jako klíč oddílu

Note

Tato část se týká především rozhraní API pro NoSQL. Jiná rozhraní API, jako je rozhraní API pro Gremlin, nepodporují jedinečný identifikátor jako klíč oddílu.

Pokud má váš kontejner vlastnost s širokou škálou možných hodnot, pravděpodobně je to skvělá volba pro klíč oddílu. Příkladem takové vlastnosti je ID položky. U malých kontejnerů náročných na čtení nebo kontejnerů s velkými zápisy je ID položky (/id) přirozeně skvělou volbou pro klíč oddílu.

Systémová vlastnost ID položky je přítomna v každé položce ve vašem kontejneru. Můžete mít další vlastnosti, které představují logické ID položky. V mnoha případech jsou tyto jedinečné identifikátory také skvělou volbou klíče oddílu ze stejných důvodů jako ID položky.

ID položky je skvělou volbou klíče oddílu z následujících důvodů:

  • Existuje široká škála možných hodnot (jedno jedinečné ID položky na položku).
  • Vzhledem k tomu, že pro každou položku existuje jedinečné ID položky, ID položky účinně pomáhá rovnoměrně vyrovnávat spotřebu RU a úložiště dat.
  • Efektivní čtení bodů můžete snadno provést, protože vždy znáte klíč oddílu položky, pokud znáte její ID.

Při výběru ID položky jako klíče oddílu zvažte následující upozornění:

  • Pokud je ID položky klíčem oddílu, stane se jedinečným identifikátorem pro celý kontejner. Nemůžete vytvářet položky s duplicitními identifikátory.
  • Pokud máte kontejner náročný na čtení s mnoha fyzickými oddíly, dotazy jsou efektivnější, pokud mají filtr rovnosti s ID položky.
  • Uložené procedury nebo triggery nemůžou cílit na více logických oddílů.

Související obsah

  • Last updated on