Návrh škálovatelných a výkonných tabulek
Tip
Obsah tohoto článku se týká původní služby Azure Table Storage. Stejné koncepty se ale vztahují na novější službu Azure Cosmos DB for Table, která nabízí vyšší výkon a dostupnost, globální distribuci a automatické sekundární indexy. Je také k dispozici v bezserverovém režimu založeném na spotřebě. Mezi rozhraním TABLE API ve službě Azure Cosmos DB a Azure Table Storage existuje několik rozdílů mezi rozhraním TABLE API. Další informace najdete v tématu Azure Cosmos DB pro tabulku. Pro usnadnění vývoje teď poskytujeme jednotnou sadu SDK pro tabulky Azure, která se dá použít k cílení na Azure Table Storage i Azure Cosmos DB for Table.
Pokud chcete navrhnout škálovatelné a výkonné tabulky, musíte zvážit faktory, jako je výkon, škálovatelnost a náklady. Pokud jste dříve navrhli schémata pro relační databáze, jsou tyto aspekty známé, ale i když existují určité podobnosti mezi modelem úložiště Azure Table Service a relačními modely, existují i důležité rozdíly. Tyto rozdíly obvykle vedou k různým návrhům, které můžou vypadat jako neintuitivní nebo nesprávné pro někoho, kdo zná relační databáze, ale dává smysl, pokud navrhujete úložiště klíč/hodnota NoSQL, jako je služba Azure Table Service. Mnoho rozdílů v návrhu odráží skutečnost, že služba Table Service je navržená tak, aby podporovala aplikace v cloudovém měřítku, které můžou obsahovat miliardy entit (nebo řádků v terminologii relační databáze) dat nebo pro datové sady, které musí podporovat velké objemy transakcí. Proto se musíte zamyslet nad tím, jak ukládáte data, a porozumět tomu, jak služba Table Service funguje. Dobře navržené úložiště dat NoSQL umožňuje vašemu řešení škálovat mnohem více a s nižšími náklady než řešení, které používá relační databázi. Tato příručka vám pomůže s těmito tématy.
Informace o službě Azure Table Service
V této části jsou zvýrazněné některé klíčové funkce služby Table Service, které jsou zvláště důležité pro návrh pro zajištění výkonu a škálovatelnosti. Pokud s Azure Storage a tabulkovou službou teprve začínáte, přečtěte si nejprve článek Začínáme se službou Azure Table Storage pomocí .NET , než si přečtete zbytek tohoto článku. I když je tato příručka zaměřená na službu Table Service, obsahuje diskuzi o službách Azure Queue a Blob a o tom, jak je můžete používat se službou Table Service.
Co je služba Table Service? Jak můžete očekávat od názvu, služba Table Service používá k ukládání dat tabulkový formát. Ve standardní terminologii představuje každý řádek tabulky entitu a sloupce ukládají různé vlastnosti dané entity. Každá entita má pár klíčů k jedinečné identifikaci a sloupec časového razítka, který služba Table Service používá ke sledování, kdy byla entita naposledy aktualizována. Časové razítko se použije automaticky a časové razítko nelze ručně přepsat libovolnou hodnotou. Služba Table Service používá toto časové razítko poslední změny (LMT) ke správě optimistické souběžnosti.
Poznámka:
Operace ROZHRANÍ REST API služby Table Service vrátí také hodnotu značky ETag , kterou odvozuje z LMT. Tento dokument používá termíny ETag a LMT zaměnitelně, protože odkazují na stejná podkladová data.
Následující příklad ukazuje jednoduchý návrh tabulky pro ukládání entit zaměstnanců a oddělení. Mnoho příkladů uvedených dále v této příručce vychází z tohoto jednoduchého návrhu.
| PartitionKey | RowKey | Časové razítko | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Oddělení | 2014-08-22T00:50:30Z |
|
||||||||
| Prodej | 00010 | 2014-08-22T00:50:44Z |
|
Zatím se tato data podobají tabulce v relační databázi s klíčovými rozdíly v povinných sloupcích a schopnost ukládat více typů entit do stejné tabulky. Každá z uživatelem definovaných vlastností, jako je FirstName nebo Age , má také datový typ, například celé číslo nebo řetězec, stejně jako sloupec v relační databázi. I když na rozdíl od relační databáze, povaha služby Table Service bez schématu znamená, že vlastnost nemusí mít pro každou entitu stejný datový typ. Chcete-li ukládat složité datové typy do jedné vlastnosti, musíte použít serializovaný formát, jako je JSON nebo XML. Další informace o tabulkové službě, jako jsou podporované datové typy, podporované rozsahy kalendářních dat, pravidla pojmenování a omezení velikosti, najdete v tématu Vysvětlení datového modelu služby Table Service.
Váš výběr PartitionKey a RowKey je zásadní pro dobrý návrh tabulky. Každá entita uložená v tabulce musí mít jedinečnou kombinaci PartitionKey a RowKey. Stejně jako u klíčů v tabulce relační databáze se hodnoty PartitionKey a RowKey indexují k vytvoření clusterovaného indexu, který umožňuje rychlé vyhledávání. Služba Table Service však nevytváří žádné sekundární indexy, takže PartitionKey a RowKey jsou jedinými indexovanými vlastnostmi. Některé vzory popsané v vzorech návrhu tabulky ukazují, jak můžete toto zjevné omezení obejít.
Tabulka se skládá z jednoho nebo více oddílů a řada rozhodnutí o návrhu, která provedete, bude volby vhodného partitionKey a RowKey pro optimalizaci vašeho řešení. Řešení se může skládat z jedné tabulky, která obsahuje všechny entity uspořádané do oddílů, ale obvykle má řešení více tabulek. Tabulky pomáhají logicky uspořádat entity, pomáhají spravovat přístup k datům pomocí seznamů řízení přístupu a můžete celou tabulku odstranit pomocí jedné operace úložiště.
Oddíly tabulky
Název účtu, název tabulky a PartitionKey společně identifikují oddíl ve službě úložiště, ve kterém služba table ukládá entitu. Stejně jako součást schématu adresování entit definují oddíly rozsah transakcí (viz transakce skupiny entit níže) a tvoří základ způsobu škálování služby Table Service. Další informace o oddílech najdete v kontrolním seznamu výkonu a škálovatelnosti pro Table Storage.
Ve službě Table Service jednotlivé uzly obsluhuje jeden nebo více celých oddílů a služba se škáluje dynamicky vyrovnávajícími oddíly mezi uzly. Pokud je uzel pod zatížením, může služba Table Service rozdělit rozsah oddílů obsluhovaných tímto uzlem na různé uzly. Když provoz klesá, může služba sloučit rozsahy oddílů z tichých uzlů zpět do jednoho uzlu.
Další informace o interních podrobnostech služby Table Service a zejména o tom, jak služba spravuje oddíly, najdete v dokumentu Microsoft Azure Storage: Vysoce dostupná cloudová služba úložiště se silnou konzistencí.
Transakce skupin entit
Ve službě Table Service jsou transakce skupin entit (EGT) jediným integrovaným mechanismem pro provádění atomických aktualizací napříč více entitami. EGT se někdy také označují jako dávkové transakce. EgT mohou pracovat pouze s entitami uloženými ve stejném oddílu (tj. sdílet stejný klíč oddílu v dané tabulce). Takže kdykoli potřebujete atomické transakční chování napříč více entitami, musíte zajistit, aby tyto entity byly ve stejném oddílu. To je často důvod, proč zachovat více typů entit ve stejné tabulce (a oddílu) a nepoužít více tabulek pro různé typy entit. Jeden EGT může fungovat na maximálně 100 entitách. Pokud odesíláte více souběžných EGT ke zpracování, je důležité zajistit, aby tyto EGT nepracují s entitami, které jsou společné v rámci EGT; jinak může být zpracování zpožděno.
EgTs také představují potenciální kompromis, který můžete vyhodnotit ve svém návrhu. To znamená, že použití dalších oddílů zvyšuje škálovatelnost vaší aplikace, protože Azure nabízí více příležitostí pro vyrovnávání zatížení požadavků napříč uzly. Použití více oddílů ale může omezit schopnost vaší aplikace provádět atomické transakce a udržovat silnou konzistenci pro vaše data. Kromě toho existují konkrétní cíle škálovatelnosti na úrovni oddílu, které by mohly omezit propustnost transakcí, které můžete očekávat pro jeden uzel. Další informace o cílech škálovatelnosti pro účty úložiště Azure Úrovně Standard najdete v tématu Cíle škálovatelnosti pro účty úložiště úrovně Standard. Další informace o cílech škálovatelnosti pro službu Table Service najdete v tématu Škálovatelnost a výkonnostní cíle pro Table Storage.
Důležité informace o kapacitách
Následující tabulka popisuje kapacitu, škálovatelnost a cíle výkonnosti pro Table Storage.
| Prostředek | Cíl |
|---|---|
| Počet tabulek v účtu Azure Storage | Omezené jenom kapacitou účtu úložiště |
| Počet oddílů v tabulce | Omezené jenom kapacitou účtu úložiště |
| Počet entit v oddílu | Omezené jenom kapacitou účtu úložiště |
| Maximální velikost jedné tabulky | 500 TiB |
| Maximální velikost jedné entity, včetně všech hodnot vlastností | 1 MiB |
| Maximální počet vlastností v entitě tabulky | 255 (včetně tří systémových vlastností – PartitionKey, RowKey a Timestamp) |
| Maximální celková velikost jednotlivé vlastnosti v entitě | Liší se podle typu vlastnosti. Další informace najdete v tématu Typy vlastností v článku Vysvětlení datového modelu služby Table Storage. |
| Velikost PartitionKey | Řetězec o velikosti až 1024 znaků |
| Velikost RowKey | Řetězec o velikosti až 1024 znaků |
| Velikost transakce skupiny entit | Transakce může zahrnovat maximálně 100 entit a velikost datové části musí být menší než 4 MiB. Transakce skupiny entit může aktualizaci entity zahrnovat pouze jednou. |
| Maximální počet uložených zásad přístupu na tabulku | 5 |
| Maximální frekvence požadavků na účet úložiště | 20 000 transakcí za sekundu (předpokládá se velikost entit 1 KiB) |
| Cílová propustnost pro oddíl s jednou tabulkou (entity 1 KiB) | Až 2 000 entit za sekundu |
Důležité informace o nákladech
Table Storage je poměrně levné, ale měli byste zahrnout odhady nákladů na využití kapacity i množství transakcí v rámci vyhodnocení libovolného řešení služby Table Service. V mnoha scénářích je ale platným přístupem ukládání denormalizovaných nebo duplicitních dat, aby se zlepšil výkon nebo škálovatelnost vašeho řešení. Další informace o cenách najdete v tématu Ceny služby Azure Storage.