Dělení a horizontální škálování ve službě Azure Cosmos DB
platí pro:
SQL api
rozhraní API Cassandra
Gremlin api
rozhraní API pro tabulky
Azure Cosmos DB api pro MongoDB
Azure Cosmos DB používá dělení k škálování jednotlivých kontejnerů v databázi tak, aby splňovaly požadavky vaší aplikace na výkon. Při dělení se položky v kontejneru dělí na samostatné podmnožiny nazývané logické oddíly. Logické oddíly se vytvářejí na základě hodnoty 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 UserID vlastnosti . Pokud slouží jako klíč oddílu pro položky v kontejneru a existuje 1 000 jedinečných hodnot, vytvoří se pro kontejner UserID UserID 1 000 logických oddílů.
Kromě klíče oddílu, který určuje logický oddíl položky, má každá položka v kontejneru ID položky (jedinečné v rámci logického oddílu). Kombinace klíče oddílu a ID položky vytvoří index položky , který jednoznačně identifikuje položku. Výběr klíče oddílu je důležité rozhodnutí, které bude mít vliv na výkon vaší aplikace.
Tento článek vysvětluje vztah mezi logickými a fyzickými oddíly. Popisuje také osvědčené postupy pro dělení a poskytuje podrobné informace o tom, jak horizontální škálování funguje v Azure Cosmos DB. K výběru klíče oddílu není nutné rozumět těmto interním podrobnostem, ale prokryli jsme je, abyste měli přehled o tom, jak Azure Cosmos DB funguje.
Logické oddíly
Logický oddíl se skládá ze sady položek, které mají stejný klíč oddílu. Například v kontejneru, který obsahuje data o jídle, obsahují všechny položky foodGroup vlastnost . Jako klíč foodGroup oddílu kontejneru můžete použít . Skupiny položek, které mají konkrétní hodnoty pro , například foodGroup , a , tvoří odlišné logické Beef Products Baked Products Sausages and Luncheon Meats 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 s izolací snímku. Při přidání nových položek do kontejneru systém transparentně vytvoří nové logické oddíly. Při odstranění podkladových dat se nemusíte starat o odstranění logického oddílu.
Počet logických oddílů v kontejneru není žádný limit. Každý logický oddíl může uchovávat až 20 GB dat. Vhodné volby klíče oddílu mají širokou škálu možných hodnot. Například v kontejneru, kde všechny položky obsahují vlastnost, se data v rámci logického oddílu mohou zvětšovat foodGroup Beef Products až na 20 GB. Výběrem klíče oddílu s širokou škálou možných hodnot zajistíte, že kontejner bude možné škálovat.
Fyzické oddíly
Kontejner se škáluje distribucí dat a propustnosti mezi fyzické oddíly. Interně se jeden nebo více logických oddílů mapuje na jeden fyzický oddíl. Obvykle menší kontejnery mají mnoho logických oddílů, ale vyžadují pouze jeden fyzický oddíl. Na rozdíl od logických oddílů jsou fyzické oddíly interní implementací systému a jsou plně spravované službou Azure Cosmos DB.
Počet fyzických oddílů v kontejneru závisí na následujících:
Počet zřízené propustnosti (každý jednotlivý fyzický oddíl může poskytovat propustnost až 10 000 jednotek žádostí 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 se mapuje pouze na jeden fyzický oddíl.
Celkové úložiště dat (každý jednotlivý fyzický oddíl může uchovávat až 50 GB dat).
Poznámka
Fyzické oddíly jsou interní implementací systému a jsou 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ů. Pokud zvolíte klíč oddílu, který rovnoměrně distribuuje spotřebu propustnosti mezi logické oddíly, zajistíte vyváženou spotřebu propustnosti mezi fyzickými oddíly.
Celkový počet fyzických oddílů v kontejneru není žádný limit. S tím, jak vaše zřízená propustnost nebo velikost dat roste, Azure Cosmos DB automaticky vytvoří 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ých oddílů jednoduše vytvoří nové mapování logických oddílů na fyzické oddíly.
Propustnost zřízená pro kontejner se rovnoměrně rozdělí mezi fyzické oddíly. Návrh klíče oddílu, který žádosti nesměruje rovnoměrně, může vést k příliš mnoha požadavkům směrům na malou podmnožinu oddílů, které se stanou "horkými". Horké oddíly vedou k neefektivnímu využití zřízené propustnosti, což může vést k omezování rychlosti a vyšším nákladům.
Fyzické oddíly kontejneru se zobrazí v části Storage okna Metriky v okně Azure Portal:
Na výše uvedeném snímku obrazovky má kontejner /foodGroup jako klíč oddílu . Každý ze tří pruhů v grafu představuje fyzický oddíl. V i image je rozsah klíčů oddílu stejný jako u fyzického oddílu. Vybraný fyzický oddíl obsahuje 3 nejdůležitější logické oddíly velikosti: Beef Products Vegetable and Vegetable Products , a Soups, Sauces, and Gravies .
Pokud zzřídit propustnost 18 000 jednotek žádostí za sekundu (RU/s), může každý ze tří fyzických oddílů využít 1/3 z celkové zřízené propustnosti. V rámci vybraného fyzického oddílu mohou klíče logického oddílu a společně využívat Beef Products Vegetable and Vegetable Products Soups, Sauces, and Gravies 6 000 zřízených RU/s fyzického oddílu. Vzhledem k tomu, že zřízená propustnost je rovnoměrně rozdělená mezi fyzické oddíly kontejneru, je důležité zvolit klíč oddílu, který rovnoměrně distribuuje spotřebu propustnosti výběrem vlastního logického klíče oddílu.
Správa logických oddílů
Azure Cosmos DB transparentně a automaticky spravuje umístění logických oddílů na fyzických oddílech, aby efektivně vyhověl požadavkům kontejneru na škálovatelnost a výkon. Se zvyšující se propustností a požadavky na úložiště azure Cosmos DB přesouvá logické oddíly, aby se zatížení automaticky rozděluje mezi větší počet fyzických oddílů. Další informace o fyzických oddílech
Azure Cosmos DB používá dělení na základě hodnoty hash k rozložení logických oddílů mezi fyzické oddíly. Azure Cosmos DB hodnotu hash klíče oddílu položky. Výsledek s hodnotou hash určuje fyzický oddíl. Azure Cosmos DB pak rovnoměrně přidělí prostor klíčů oddílů mezi fyzické oddíly.
Transakce (v uložených procedurách nebo triggerech) jsou povoleny pouze pro položky v jednom logickém oddílu.
Sady replik
Každý fyzický oddíl se skládá ze sady replik, které se také označují jako sada replik. Každá sada replik hostuje instanci databázového stroje. Sada replik zajišťuje, že data uložená v rámci fyzického oddílu jsou odolná, vysoce dostupná a konzistentní. Každá replika, která tvoří fyzický oddíl, dědí kvótu úložiště oddílu. Všechny repliky fyzického oddílu společně podporují propustnost přidělenou fyzickému oddílu. Azure Cosmos DB automaticky spravuje sady replik.
Menší kontejnery obvykle vyžadují jenom jeden fyzický oddíl, ale stále budou mít alespoň 4 repliky.
Následující obrázek ukazuje mapování logických oddílů na fyzické oddíly, které jsou distribuovány globálně. Sada oddílů v bitové kopii odkazuje na skupinu fyzických oddílů, které spravují stejné klíče logických oddílů napříč několika oblastmi:
Výběr klíče oddílu
Klíč oddílu má dvě komponenty: cestu ke klíči oddílu a hodnotu klíče oddílu. Představte si například položku { "userId": "Andrew", "worksFor": "Microsoft" }, pokud jako klíč oddílu zvolíte userId, jsou následující dvě komponenty klíče oddílu:
Cesta ke klíči oddílu (například/userId). Cesta ke klíči 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 typu řetězec nebo číselný typ.
Další informace o omezeních 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, není možné ho změnit na místě. Pokud potřebujete změnit klíč oddílu, měli byste data přesunout do nového kontejneru s novým požadovaným klíčem oddílu.
U všech kontejnerů by váš klíč oddílu měl:
Musí být vlastnost, která má hodnotu, která se nemění. Pokud je vlastnost klíčem oddílu, nemůžete aktualizovat hodnotu této vlastnosti.
Má vysokou kardinalitu. Jinými slovy, vlastnost by měla mít širokou škálu možných hodnot.
Rovnoměrně rozdělte spotřebu jednotek žádostí (RU) a úložiště dat napříč všemi logickými oddíly. Tím se zajistí i spotřeba RU a distribuce úložiště mezi fyzickými oddíly.
Pokud ve službě Azure Cosmos DB potřebujete transakce ACID s více položkami, budete muset 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.
Klíče oddílů pro kontejnery pro čtení a těžký přístup
U většiny kontejnerů je výše uvedená kritéria při vybírání klíče oddílu všechno potřeba zvážit. U velkých kontejnerů pro čtení ale můžete chtít zvolit klíč oddílu, který se často objevuje jako filtr v dotazech. Dotazy mohou být efektivně směrovány pouze na příslušné fyzické oddíly zahrnutím klíče oddílu do predikátu filtru.
Pokud jsou většina požadavků na vaše úlohy dotazy a většina vašich dotazů má pro stejnou vlastnost filtr rovnosti, může být tato vlastnost vhodnou volbou klíče oddílu. Pokud třeba často spustíte dotaz, který filtrujete UserID , pak výběrem možnosti UserID klíč oddílu snížíte počet dotazů mezi oddíly.
Pokud je ale váš kontejner malý, pravděpodobně nemáte dostatek fyzických oddílů, abyste se museli starat o dopad na 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 váš kontejner mohl růst na více než několik fyzických oddílů, měli byste si vybrat klíč oddílu, který minimalizuje dotazy mezi oddíly. Váš kontejner bude vyžadovat více než několik fyzických oddílů, pokud je splněna jedna z následujících podmínek:
Váš kontejner bude mít zajištěné více než 30 000 RU.
Váš kontejner bude uchovávat více než 100 GB dat.
Použití ID položky jako klíče oddílu
Pokud má váš kontejner vlastnost, která má široké spektrum možných hodnot, je pravděpodobné, že je vhodný klíč oddílu. Jedním z možných příkladů takové vlastnosti je ID položky. Pro malé kontejnery pro čtení nebo zapisovatelné kontejnery libovolné velikosti je ID položky přirozeně skvělým výběrem pro klíč oddílu.
ID položky systémové vlastnosti existuje v každé položce v kontejneru. Můžete mít další vlastnosti, které reprezentují logické ID vaší položky. V mnoha případech jsou to také skvělé volby klíče oddílu ze stejných důvodů jako ID položky.
ID položky je skvělý výběr klíče oddílu z následujících důvodů:
- Existuje celá řada možných hodnot (jedno jedinečné ID položky na jednu položku).
- Vzhledem k tomu, že existuje jedinečné ID položky na jednu položku, má ID položky skvělou úlohu s rovnoměrně vyvážením využití ru a úložiště dat.
- Můžete snadno provádět efektivní čtení bodů, protože poznáte jeho ID, vždy znát klíč oddílu položky.
Je potřeba vzít v úvahu několik věcí, které byste měli zvážit při výběru ID položky jako klíč oddílu:
- Pokud je ID položky klíč oddílu, stane se jedinečným identifikátorem v celém rámci celého kontejneru. Nebudete moct mít položky, které mají duplicitní ID položky.
- Pokud máte kontejner pro čtení s velkým množstvím fyzických oddílů, dotazy budou efektivnější, pokud mají filtr rovnosti s ID položky.
- Uložené procedury nebo triggery nemůžete spouštět v několika logických oddílech.
Další kroky
- přečtěte si o zřízené propustnosti v Azure Cosmos DB.
- přečtěte si o globální distribuci v Azure Cosmos DB.
- naučte se zřídit propustnost na kontejneru Azure Cosmos.
- naučte se zřídit propustnost pro databázi Azure Cosmos.
- podívejte se na modul naučte se, jak modelovat a rozdělit data do oddílů v Azure Cosmos DB.
- chcete se pokusit plánování kapacity pro migraci na Azure Cosmos DB? Pro plánování kapacity můžete použít informace o vašem existujícím databázovém clusteru.
- Pokud znáte počet virtuální jádra a serverů v existujícím databázovém clusteru, přečtěte si téma odhadování jednotek žádostí pomocí virtuální jádra nebo vCPU .
- pokud znáte typické míry požadavků pro aktuální databázovou úlohu, přečtěte si téma odhadace jednotek žádostí pomocí Azure Cosmos DB kapacity plánovače .