Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Azure DocumentDB podporuje horizontální dělení pro horizontální distribuci dat a provozu. Dokumenty v kolekci jsou rozdělené na bloky označované jako logické shardy.
Sharding je definováno jednotlivě pro každou kolekci pomocí určeného shardovacího klíče ze struktury dokumentu kolekce. Data se pak rozdělí do bloků dat s jednotlivými bloky odpovídajícími logickému oddílu. Dokumenty pro každou jedinečnou hodnotu klíče shardu se nacházejí ve stejném logickém šardu.
Pro každý dokument vložený do horizontálně dělené kolekce je hodnota vlastnosti klíče shardu hashována k určení příslušného logického shardu. Povinnost umístění logického datového úlomku a distribuce všech logických datových úlomků v clusteru je skryta před uživatelem a plně spravována službou.
Logické fragmenty
Všechny dokumenty obsahující stejnou hodnotu klíče fragmentu patří do stejného logického fragmentu.
Představme si například kolekci s názvem Zaměstnanci s následující strukturou dokumentů.
Tato tabulka ukazuje mapování hodnot rozdělovačích klíčů na logické části.
| ID dokumentu | Hodnota klíče fragmentu | Logický fragment |
|---|---|---|
| "12345" | "Steve Smith" | Horizontální oddíl 1 |
| "23456" | "Jane Doe" | Část 2 |
| "34567" | "Steve Smith" | Horizontální oddíl 1 |
| "45678" | "Michael Smith" | Shard 3 |
| "56789" | "Jane Doe" | Horizontální oddíl 2 |
Počet logických částí pro kolekci není nijak omezen. Kolekce může mít tolik logických shardů, kolik existuje dokumentů s jedinečnou hodnotou pro vlastnost shard klíče v každém dokumentu.
Velikost jednoho logického úlomku není nijak omezena.
Kromě toho služba neomezuje transakce pouze na rozsah logického dílu. Azure DocumentDB podporuje transakce čtení a zápisu, které platí pro více logických horizontálních oddílů a napříč několika fyzickými horizontálními oddíly v clusteru.
Fyzické fragmenty
Fyzické shardy jsou základní počítače a disky, které jsou zodpovědné za uchování dat a plnění databázových transakcí. Na rozdíl od logických shardů spravuje služba fyzické shardy v zákulisí.
Počet fyzických shardů se definuje při vytvoření clusteru a může být zvýšen, pokud velikost databáze časem roste. Clustery s jedním horizontálním oddílem mají jeden fyzický horizontální oddíl (uzel), který je zcela zodpovědný za transakce úložiště a databáze clusteru. Clustery s více horizontálními oddíly distribuují data a objem transakcí mezi fyzické horizontální oddíly v clusteru.
Mapování logických shardů na fyzické shardy
Když se přidají nové logické šardy, cluster plynule aktualizuje mapování logických na fyzické šardy. Podobně se přiřazení adresního prostoru ke každému fyzickému horizontálnímu oddílu změní, protože se do clusteru přidají nové fyzické horizontální oddíly, po kterých se logické horizontální oddíly znovu vyrovnávají v rámci clusteru.
Rozsah hodnot hash používaný k mapování logických a fyzických shardů je rovnoměrně rozložen mezi fyzické shardy v clusteru. Každý fyzický fragment vlastní rovnoměrně velikou část rozsahu hash. Pro každý dokument, který je napsán, je hodnota vlastnosti klíče horizontálního oddílu převedena na hash a hashová hodnota určuje přiřazení dokumentu na podkladový fyzický horizontální oddíl. Interně se několik logických shardů mapuje na jeden fyzický shard. Logické segmenty se navíc nikdy nerozdělují mezi fyzické segmenty a všechny dokumenty pro logický segment se mapují pouze na jeden fyzický segment.
Na základě předchozího příkladu pomocí clusteru se dvěma fyzickými horizontálními oddíly ukazuje tato tabulka ukázkové mapování dokumentů na fyzické horizontální oddíly.
| ID dokumentu | Hodnota shardového klíče | Logický fragment | Fyzický fragment |
|---|---|---|---|
| "12345" | "Steve Smith" | Horizontální oddíl 1 | Fyzický shard 1 |
| "23456" | "Jane Doe" | Horizontální oddíl 2 | Fyzický shard 2 |
| "34567" | "Steve Smith" | Horizontální oddíl 1 | Fyzický shard 1 |
| "45678" | "Michael Smith" | Shard 3 | Fyzický datový fragment 1 |
| "56789" | "Jane Doe" | Horizontální oddíl 2 | Fyzický shard 2 |
Kapacita fyzických horizontálních oddílů
Úroveň clustru vybraná při poskytování clustru určuje kapacitu procesoru a paměti fyzického úlomku. Podobně SKU úložiště určuje kapacitu úložiště a IOPS fyzického shardu. Větší úrovně clusteru poskytují větší výpočetní výkon a větší paměť, zatímco větší disky úložiště poskytují větší úložiště a IOPS. Úlohy náročné na čtení těží z větší úrovně clustru, zatímco úlohy náročné na zápis mají výhodu větší SKU úložiště. Po vytvoření clusteru na základě měnících se potřeb aplikace je možné vertikálně navýšit a snížit kapacitu vrstvy clusteru.
V clusteru s více horizontálními oddíly je kapacita každého fyzického horizontálního oddílu stejná. Navýšení kapacity úrovně clusteru nebo konfigurace úložiště nemění umístění logických fragmentů na fyzické fragmenty. Po operaci zvětšení zůstane počet fyzických oddílů stejný, takže dat není třeba znovu vyrovnávat v clusteru.
Výpočetní výkon, paměť, úložiště a IOPS fyzického shardu určují prostředky dostupné pro logické shardy. Klíče horizontálních oddílů, které nemají nevyváženou distribuci úložiště a četnosti požadavků, můžou způsobit nerovnoměrnou spotřebu úložiště a výkonu v rámci clusteru. Horké partitiony můžou způsobit nerovnoměrné využití fyzických shardů, které vedou k nepředvídatelnou propustností a výkonem. Proto horizontální clustery vyžadují pečlivé plánování předem, aby se zajistilo, že výkon zůstane konzistentní, protože se požadavky aplikace v průběhu času mění.
Replikační sady
Každý fyzický shard se skládá ze sady replik, označovaných také jako sada replik. Každá replika hostuje instanci databázového stroje. Sada replik dělá úložiště dat v rámci fyzického shardu trvanlivé, vysoce dostupné a konzistentní. Každá replika, která tvoří fyzický shard, dědí úložiště a výpočetní kapacitu fyzického shardu. Azure DocumentDB automaticky spravuje sady replik.
Osvědčené postupy pro horizontální dělení dat
Horizontální dělení v Azure DocumentDB není požadováno, pokud úložný prostor kolekce a objem transakcí nemohou překročit kapacitu jednoho fyzického shardu. Služba například poskytuje disky o velikosti 32 TB na jeden datový shard. Pokud kolekce vyžaduje více než 32 TB, měla by být shardována.
Není nutné rozdělovat na části každou kolekci v clusteru s několika fyzickými shardy. Shardované a neshardované kolekce mohou existovat ve stejném clusteru. Služba optimálně distribuuje kolekce v rámci clusteru, aby rovnoměrně využívala výpočetní prostředky a prostředky úložiště clusteru co nejvíce rovnoměrně.
U aplikací náročných na čtení musí být shardovací klíč vybrán podle nejčastějších vzorů dotazů. Nejčastěji používaný filtr dotazů pro kolekci by měl být vybrán jako shard key, aby se optimalizovalo nejvyšší procento databázových transakcí lokalizací vyhledávání na jeden fyzický shard.
U aplikací náročných na zápis, které upřednostňují výkon zápisu před čtením, by se měl zvolit shardovací klíč, který rovnoměrně distribuuje data mezi fyzické shardy. Klíče shardů s nejvyšší kardinalitou poskytují nejlepší příležitost pro co nejrovnoměrnější distribuci.
Pro zajištění optimálního výkonu by velikost úložiště logického fragmentu měla být menší než 4 TB.
Pro zajištění optimálního výkonu by logické oddíly měly být rovnoměrně distribuovány v úložišti a objemu požadavků napříč fyzickými oddíly clusteru.
Jak horizontálně dělit kolekci
Zvažte následující dokument v databázi "cosmicworks" a v kolekci "employee".
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Následující ukázka rozčleňuje kolekci zaměstnanců v rámci databáze Cosmicworks podle vlastnosti "firstName".
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
Kolekci je také možné horizontálně dělit pomocí příkazu správce:
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
I když není ideální změnit klíč fragmentu poté, co kolekce výrazně vzrostla na objemu v úložišti, lze k úpravě klíče fragmentu použít příkaz reshardCollection.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
Kolekci je také možné horizontálně dělit pomocí administrátorského příkazu:
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
Osvědčeným postupem je vytvoření indexu na klíči shardu.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})