Horizontální, vertikální a funkční dělení dat

V mnoha velkých řešeních jsou data rozdělená na oddíly , které se dají spravovat a ke kterým se mají přihlížet samostatně. Dělení může vylepšit škálovatelnost, omezit kolize a optimalizovat výkon. Může také poskytovat mechanismus rozdělování dat podle způsobu používání. Můžete například archivovat starší data v levnějším úložišti dat.

Strategii dělení se ale dá pečlivě vybrat, aby se maximalizovaly výhody při minimalizaci nepříznivých účinků.

Proč dělit data?

• Zlepšení škálovatelnosti. Když vertikálně navyšujete kapacitu jednoho databázového systému, časem se dosáhne fyzického limitu hardwaru. Pokud rozdělíte data mezi více oddílů, které jsou hostovány na samostatném serveru, můžete škálovat systém téměř po neomezenou dobu.

• Zvyšte výkon. Operace přístupu k datům v jednotlivých oddílech probíhají v menších objemech dat. Při vytváření oddílů může být systém efektivnější. Operace, které ovlivňují víc než jeden oddíl, mohou běžet paralelně.

• Vylepšení zabezpečení. V některých případech můžete citlivá a necitlivá data oddělit do různých oddílů a použít pro citlivá data jiné ovládací prvky zabezpečení.

• Zajištění provozní flexibility. Dělení nabízí mnoho příležitostí pro jemné ladění operací, maximalizaci administrativní efektivity a minimalizaci nákladů. Můžete například definovat různé strategie pro správu, monitorování, zálohování a obnovení a další úlohy správy na základě důležitosti dat v jednotlivých oddílech.

• Zajištění shody mezi úložištěm dat a způsobem použití. Dělení umožňuje nasadit jednotlivé oddíly do různých typů úložišť dat, a to na základě nákladů a integrovaných funkcí, které úložiště dat nabízejí. Například rozsáhlá binární data mohou být uložena v úložišti objektů blob, zatímco v databázi dokumentů lze uchovávat více strukturovaných dat. Přečtěte si o volbě správného úložiště dat.

• Zlepšení dostupnosti. Rozdělení dat napříč několika servery umožňuje vyhnout se kritickému prvku způsobujícímu selhání. Pokud se jedna instance nezdařila, nejsou k dispozici pouze data v tomto oddílu. Operace s dalšími oddíly mohou pokračovat. Pro spravovaná úložiště dat PaaS je toto posouzení méně důležité, protože tyto služby jsou navržené s integrovanou redundancí.

Navrhování oddílů

Existují tři typické strategie dělení dat:

• Horizontální dělení (označované také jako sharding). V této strategii je každý oddíl samostatné úložiště dat, ale všechny oddíly mají stejné schéma. Každý oddíl je známý jako horizontálních oddílů a obsahuje konkrétní podmnožinu dat, například všechny objednávky konkrétní sady zákazníků.

• Vertikální dělení. Při použití této strategie každý oddíl obsahuje podmnožinu polí pro položky v úložišti dat. Pole jsou rozdělená podle způsobu jejich použití. Můžete například dát často používaná pole do jednoho vertikálního oddílu a méně používaná pole do jiného.

• Funkční dělení. Při použití této strategie jsou data agregovaná podle způsobu použití v jednotlivých ohraničených kontextech v rámci systému. Systém elektronického obchodování může například ukládat data faktury v jednom oddílu a daty inventáře produktů v jiném.

Tyto strategie je možné kombinovat a při navrhování schématu dělení doporučujeme, abyste je měli. Můžete například rozdělit data do horizontálních oddílů a data v jednotlivých horizontálních oddílech dál rozdělit pomocí vertikálního dělení.

Horizontální dělení (sharding)

Obrázek 1 ukazuje horizontální dělení nebo horizontálního dělení. V tomto příkladu jsou data o zásobách produktů rozdělená do horizontálních oddílů na základě kódu Product Key. Každý horizontální oddíl uchovává data pro souvislý rozsah klíčů horizontálního oddílu (A-G a H-Z) v abecedním pořadí. Horizontálního dělení šíří zatížení do více počítačů, což snižuje kolizí a zvyšuje výkon.

Obrázek 1 – data horizontálního dělení na oddíly (horizontálního dělení) na základě klíče oddílu

Nejdůležitějším faktorem je volba horizontálního dělení klíče. Jakmile je systém v provozu, může být změna klíčů někdy obtížná. Klíč musí zajistit, aby data byla rozdělená na oddíly, aby bylo možné rovnoměrně rozprostření zatížení napříč horizontálních oddílů.

Horizontálních oddílů nemusí mít stejnou velikost. Je důležitější, abyste si vyrovnali počet požadavků. Některé horizontálních oddílů můžou být velmi velké, ale každá položka má nízký počet operací přístupu. Jiné horizontální oddíly mohou být menší, ale k jednotlivým položkám se přistupuje mnohem častěji. Je také důležité zajistit, aby jeden horizontálních oddílů nepřekročil limity škálování (z pohledu kapacity a prostředků zpracování) úložiště dat.

Vyhněte se vytváření "aktivních" oddílů, které mohou ovlivnit výkon a dostupnost. Například použití prvního písmene názvu zákazníka způsobí nevyváženou distribuci, protože některé dopisy jsou běžnější. Místo toho použijte hodnotu hash identifikátoru zákazníka k rovnoměrné distribuci dat napříč oddíly.

Vyberte horizontálního dělení klíč, který minimalizuje případné budoucí požadavky na rozdělení velkých horizontálních oddílů, sloučení malých horizontálních oddílů na větší oddíly nebo změnu schématu. Tyto operace mohou být časově velmi náročné a jejich provádění může vyžadovat převedení jednoho nebo více horizontálních oddílů do offline režimu.

Pokud se horizontální oddíly replikují, je možné zachovat některé z replik online, zatímco se jiné dělí, slučují nebo se mění jejich konfigurace. Systém však může vyžadovat omezení operací, které lze provést během překonfigurování. Například data v replikách mohou být označena jako jen pro čtení, aby se zabránilo inconsistencesí dat.

Další informace o horizontálním dělení na oddíly naleznete v tématu horizontálního dělení Pattern.

Vertikální dělení

Nejběžnějším použitím vertikálního dělení je snížení nákladů na vstupně-výstupní operace a náklady na výkon spojené s načtením položek, ke kterým se často používá. Obrázek 2 ukazuje příklad vertikálního dělení. V tomto příkladu jsou různé vlastnosti položky uloženy v různých oddílech. Jeden oddíl obsahuje data, ke kterým dochází častěji, včetně názvu produktu, popisu a ceny. Další oddíl obsahuje data inventáře: počet skladových položek a datum posledního obobjednaného data.

Obrázek 2 – vertikálně dělená data podle jejich způsobu použití.

V tomto příkladu se aplikace pravidelně se dotazuje na název, popis a cenu produktů, když zákazníkům zobrazuje informace o produktech. Počet a datum poslední obobjednaného stavu se uchovávají v samostatném oddílu, protože tyto dvě položky se běžně používají dohromady.

Další výhody vertikálního dělení:

• Poměrně pomalé – přesun dat (název produktu, popis a cena) může být oddělený od více dynamických dat (na úrovni zásob a z posledního objednaného data). Pomalá přesunutí dat je dobrým kandidátem na ukládání do mezipaměti v paměti.

• Citlivá data mohou být uložena v samostatném oddílu s dalšími ovládacími prvky zabezpečení.

• Vertikální dělení může snížit potřebný počet souběžných přístupů.

Vertikální dělení funguje v rámci úložiště dat na úrovni entit, částečně je normalizuje a dělí široké položky do sady úzkých položek. Je ideální pro sloupcově orientovaná úložiště dat, jako je například HBase a Cassandra. Pokud se data v kolekci sloupců pravděpodobně nebudou měnit, měli byste také zvážit použití sloupcových úložišť v SQL Serveru.

Funkční dělení

Pokud je možné identifikovat ohraničený kontext pro každou jednotlivou obchodní oblast v aplikaci, funkční dělení je způsob, jak zlepšit izolaci a výkon přístupu k datům. Dalším běžným použitím pro funkční dělení je oddělení dat pro čtení i zápis z dat, která jsou jen pro čtení. Obrázek 3 ukazuje přehled funkčního dělení, kde jsou data o zásobách oddělená od zákaznických dat.

Obrázek 3 – funkce dělení dat pomocí ohraničeného kontextu nebo subdomény

Tato strategie dělení pomáhá omezit kolize přístupu k datům napříč různými částmi systému.

Navrhování oddílů pro zajištění škálovatelnosti

Pro dosažení maximální škálovatelnosti je potřeba vzít v úvahu velikost a úlohy pro každý oddíl a vyvážit je tak, aby byla data distribuovaná. Musíte ale data rozdělit tak, aby nepřekračovala limity škálování pro oddíly úložiště.

Při navrhování oddílů pro zajištění škálovatelnosti postupujte takto:

1. Proveďte analýzu aplikace, abyste pochopili vzory přístupu k datům, jako je například velikost sad výsledků vracených jednotlivými dotazy, četnost přístupu a s ní spojená latence a požadavky na zpracování výpočetních funkcí na straně serveru. V řadě případů bude většinu prostředků zpracování požadovat jenom několik málo hlavních entit.
2. Pomocí této analýzy stanovte aktuální a budoucí cíle škálovatelnosti, jako je například velikost dat a zatížení. Distribucí dat napříč oddíly potom splňte cíle škálovatelnosti. V případě horizontálního dělení je důležité zvolit správný horizontálních oddílů klíč, abyste se ujistili, že je distribuce sudá. Další informace najdete v tématu horizontálního dělení vzor.
3. Ujistěte se, že každý oddíl má dostatek prostředků pro zpracování požadavků na škálovatelnost, a to z hlediska velikosti a propustnosti dat. V závislosti na úložišti dat může existovat omezení velikosti prostoru úložiště, výkonu zpracování nebo šířky pásma sítě na oddíl. Pokud jsou tyto limity pravděpodobně překročeny, možná budete muset vylepšit strategii dělení nebo rozdělit data dále, případně zkombinovat dvě nebo více strategií.
4. Sledujte systém a ověřte, že jsou data distribuována podle očekávání a že oddíly můžou zatížení zpracovat. Skutečné využití se vždy neshoduje s tím, co předpověď analýz provádí. Pokud ano, může být možné znovu vyvážit oddíly nebo jinak změnit návrh některých částí systému, aby získaly požadovaný zůstatek.

Některá cloudová prostředí přidělují prostředky z pohledu na hranice infrastruktury. Zajistěte, aby omezení vaší vybrané hranice poskytovala dostatek místa pro veškerý předpokládaný nárůst objemu dat, a to z hlediska úložiště dat, výpočetního výkonu a šířky pásma.

Pokud například používáte službu Azure Table Storage, existuje omezení objemu požadavků, které lze v určitém časovém úseku zpracovat v jednom oddílu. (Další informace najdete v tématu škálovatelnost a cíle výkonnosti služby Azure Storage.) Zaneprázdněná horizontálních oddílů může vyžadovat víc prostředků, než může zvládnout jeden oddíl. V takovém případě může být pro rozprostření zátěže nutné přerozdělit horizontálních oddílů. Pokud celková velikost nebo propustnost těchto tabulek překročí kapacitu účtu úložiště, možná budete muset vytvořit další účty úložiště a rozprostřít tabulky napříč těmito účty.

Navrhování oddílů pro zajištění výkonu dotazů

Výkon dotazů se často dá zvýšit použitím menších sad dat a spouštěním paralelních dotazů. Každý oddíl by měl obsahovat malou část celé datové sady. Toto omezení objemu může zlepšit výkon dotazů. Vytváření oddílů ale není alternativou správného návrhu a konfigurace databáze. Ujistěte se například, že máte potřebné indexy.

Při navrhování oddílů pro zajištění výkonu dotazů postupujte takto:

1. Prověřte výkon a požadavky aplikací:

   • Pomocí podnikových požadavků můžete určit kritické dotazy, které se musí vždycky rychle provádět.
   • Sledujte systém a určete případné dotazy, jejichž zpracování je pomalé.
   • Vyhledá, které dotazy se provádějí nejčastěji. I v případě, že jeden dotaz má minimální náklady, může být kumulativní spotřeba prostředků významná.

2. Data, která jsou příčinou nízkého výkonu, rozdělte do oddílů:

   • Omezte velikosti jednotlivých oddílů, aby doba odezvy dotazů odpovídala cílovým hodnotám.
   • Pokud používáte horizontální dělení, navrhněte klíč horizontálních oddílů tak, aby aplikace mohla snadno vybrat správný oddíl. Zabrání tak tomu, aby dotaz musel procházet všechny oddíly.
   • Zamyslete se nad umístěním oddílu. Pokud je to možné, zkuste ponechat data v oddílech, které jsou geograficky umístěné blízko aplikacím a uživatelům, kteří k nim přistupují.

3. Pokud nějaká entita má požadavky na propustnost a výkon dotazů, použijte funkční dělení na základě této entity. Pokud ani to požadavky nesplní, použijte také horizontální dělení. Ve většině případů bude stačit jedna strategie dělení, ale v některých případech je efektivnější obě strategie kombinovat.

4. Zvažte spouštění dotazů paralelně napříč oddíly za účelem zvýšení výkonu.

Navrhování oddílů pro zajištění dostupnosti

Rozdělení dat do oddílů může vylepšit dostupnost aplikací, protože zajistí, že celá datová sada nepředstavuje jeden kritický prvek způsobující selhání a že jednotlivé dílčí sady se dají spravovat nezávisle.

Vezměte v úvahu následující faktory, které mají vliv na dostupnost:

Důležitost dat pro obchodní operace. Určete, která data jsou důležité obchodní informace, jako jsou například transakce, a která data jsou méně kritická provozní data, jako jsou například soubory protokolu.

• Zvažte ukládání důležitých dat v oddílech s vysokou dostupností s vhodným plánem zálohování.

• Vytvořte samostatné postupy správy a monitorování pro různé datové sady.

• Data se stejnou úrovní důležitosti umístěte do stejného oddílu, aby je bylo možné zálohovat společně s odpovídající frekvencí. Například oddíly, které obsahují data transakcí, mohou být nutné zálohovat častěji než oddíly, které uchovávají informace o protokolování nebo trasování.

Způsob správy jednotlivých oddílů. Navrhování oddílů pro podporu nezávislé správy a údržby má několik výhod. Například:

• Pokud oddíl selhává, dá se obnovit nezávisle bez aplikací, které přistupují k datům v jiných oddílech.

• Dělení dat podle zeměpisné oblasti umožňuje provádění úloh plánované údržby mimo špičku v jednotlivých oblastech. Ujistěte se, že oddíly nejsou příliš velké, aby nedošlo k dokončení plánované údržby během této doby.

Určení, jestli se mají důležitá data replikovat napříč oddíly. Tato strategie může zlepšit dostupnost a výkon, ale může také způsobit problémy s konzistencí. Synchronizace změn u každé repliky trvá čas. Během tohoto období budou různé oddíly obsahovat různé hodnoty dat.

Aspekty návrhu aplikace

Vytváření oddílů přináší složitost pro návrh a vývoj systému. Berte dělení jako základní část návrhu systému, i když systém zpočátku obsahuje pouze jeden oddíl. Pokud vytváříte oddíly jako dodatečně, bude to náročnější, protože už máte živý systém k údržbě:

• Logika přístupu k datům bude potřeba upravit.
• Je možné, že bude potřeba migrovat velké množství stávajících dat, aby je bylo možné distribuovat mezi oddíly.
• Uživatelé v průběhu migrace očekávají, že budou moci pokračovat v používání systému.

V některých případech se dělení nepovažuje za důležité, protože počáteční datová sada je malá a snadno ji zvládne jediný server. To může být pro některé úlohy pravdivé, ale mnoho komerčních systémů se musí rozšířit, jak se zvyšuje počet uživatelů.

Nejedná se navíc o velká úložiště dat, která využívají dělení na oddíly. Například k malému úložišti dat můžou hromadně přistupovat stovky klientů souběžně. Dělení dat v této situaci může pomoct omezit kolize a vylepšit propustnost.

Při návrhu schématu dělení dat zvažte následující body:

Minimalizujte operace přístupu k datům mezi oddíly. Pokud je to možné, udržujte v každém oddílu pohromadě data nejběžnějších operací s databází, abyste minimalizovali množství operací přístupu k datům napříč oddíly. Dotazování napříč oddíly může být časově náročnější než dotazování v rámci jednoho oddílu, ale optimalizace oddílů pro jednu sadu dotazů může negativně ovlivnit jiné sady dotazů. Pokud musíte zadat dotaz napříč oddíly, minimalizujte čas dotazu spuštěním paralelních dotazů a agregací výsledků v rámci aplikace. (Tento přístup nemusí být možný v některých případech, například při použití výsledku z jednoho dotazu v dalším dotazu.)

Zvažte možnost replikace statických referenčních dat. Pokud dotazy používají poměrně statická referenční data, jako jsou tabulky PSČ nebo seznamy produktů, zvažte replikaci těchto dat ve všech oddílech, abyste snížili samostatné operace vyhledávání v různých oddílech. Tento přístup může také snížit pravděpodobnost, že se referenční data stanou "horkou" datovou sadou, s velkým provozem v celém systému. Při synchronizaci jakýchkoli změn referenčních dat se ale účtují další náklady.

Minimalizujte spojení mezi oddíly. Pokud je to možné, minimalizujte požadavky na referenční integritu napříč vertikálními a funkčními oddíly. V těchto schématech zodpovídá aplikace za údržbu referenční integrity napříč oddíly. Dotazy, které se připojují k datům napříč více oddíly, jsou neefektivní, protože aplikace obvykle musí provádět po sobě jdoucí dotazy na základě klíče a pak cizího klíče. Místo toho zvažte replikaci nebo denormalizaci relevantních dat. Pokud je potřeba spojení mezi oddíly, spusťte paralelní dotazy nad oddíly a připojte data v rámci aplikace.

Zapojte konečnou konzistenci. Vyhodnoťte, jestli je silná konzistence skutečně požadavkem. Běžným přístupem v distribuovaných systémech je implementace konečné konzistence. Data v každém oddílu se aktualizují nezávisle a logika aplikace zajišťuje úspěšné dokončení všech aktualizací. Zpracovává také nekonzistence, ke kterým může docházet v důsledku dotazování dat, zatímco je operace s konečnou konzistencí spuštěná.

Zvažte, jak dotazy zjišťují správný oddíl. Pokud dotaz musí pro nalezení požadovaných dat prohledávat všechny oddíly, má to výrazný dopad na výkon, a to i když je spuštěných více paralelních dotazů. Pomocí vertikálního a funkčního dělení můžou dotazy přirozeně určovat oddíl. Horizontální dělení na druhé straně může být obtížné najít položku, protože každá horizontálních oddílů má stejné schéma. Typické řešení pro údržbu mapy, která se používá k vyhledání umístění horizontálních oddílů pro konkrétní položky. Tuto mapu je možné implementovat do logiky horizontálního dělení aplikace nebo udržovat v úložišti dat, pokud podporuje transparentní horizontální dělení.

Zvažte pravidelné vyrovnávání horizontálních oddílů. Díky horizontálnímu dělení horizontálních oddílů může funkce Vyrovnávání zatížení lépe distribuovat data rovnoměrně podle velikosti a zatížení, aby se minimalizovala velikost aktivních bodů, maximalizovat výkon dotazů a obejít omezení fyzického úložiště. Jedná se však o složitou úlohu, která často vyžaduje použití vlastního nástroje nebo procesu.

Replikujte oddíly. Pokud budete replikovat každý oddíl, získáte další ochranu před selháním. Pokud se jedna replika nezdařila, dotazy mohou být směrovány na pracovní kopii.

Pokud dosáhnete fyzických omezení strategie dělení, možná bude potřeba rozšířit škálovatelnost na jinou úroveň. Pokud například dělení probíhá na úrovni databáze, možná bude potřeba umístit nebo replikovat oddíly do více databází. Pokud dělení již probíhá na úrovni databáze a přesto dochází k problémům kvůli fyzickým omezením, může to znamenat, že je potřeba umístit nebo replikovat oddíly do více hostitelských účtů.

Vyhněte se transakcím, které přistupují k datům v několika oddílech. Některá úložiště dat implementují pro operace upravující data transakční konzistenci a integritu, ale pouze pokud se tato data nacházejí v jednom oddílu. Pokud potřebujete transakční podporu napříč několika oddíly, pravděpodobně ji budete muset implementovat jako součást logiky aplikace, protože většina systémů dělení neposkytuje nativní podporu.

Všechna úložiště dat vyžadují určité aktivity provozní správy a monitorování. Těmito úlohami může být například načtení dat, zálohování a obnovení dat, změna uspořádání dat a zajištění správného a efektivního fungování systému.

Vezměte v úvahu následující faktory, které ovlivňují provozní správu:

• Způsob implementace odpovídajících úloh správy a provozních úloh při dělení dat. Mezi tyto úlohy může patřit zálohování, obnovení a archivace dat, monitorování systému a další úlohy správy. Například udržování logické konzistence během operací zálohování a obnovení může být náročné.

• Způsob načtení dat do několika oddílů a přidání nových dat přicházejících z jiných zdrojů. Některé nástroje a pomůcky nemusí podporovat operace s horizontálně dělenými daty, jako je například načtení dat do správného oddílu.

• Způsob pravidelné archivace a odstraňování dat. Aby nedocházelo k nadměrnému růstu oddílů, je třeba pravidelně archivovat a odstraňovat data (například měsíčně). Data možná bude nutné transformovat, aby odpovídala jinému schématu archivu.

• Způsob zjišťování problémů s integritou dat. Zvažte spuštění pravidelného procesu, který vyhledá případné problémy s integritou dat, například data v jednom oddílu, který odkazuje na chybějící informace v jiném. Proces se může pokusit tyto problémy vyřešit automaticky nebo vytvořit sestavu pro ruční kontrolu.

Vyrovnávání oddílů

V případě zralosti systému může být nutné upravit schéma dělení. Jednotlivé oddíly můžou například začít získávat neúměrný objem provozu a stát v chodu, což vede k nadměrnému sporu. Nebo možná jste v některých oddílech rozpředpokládali objem dat, což způsobuje, že některé oddíly mají přístup k omezením kapacity.

některá úložiště dat, například Cosmos DB, můžou automaticky znovu vyrovnávat oddíly. V ostatních případech je vyrovnávání administrativní úlohou, která se skládá ze dvou fází:

1. Určete novou strategii dělení.

   • Které oddíly je třeba rozdělit (nebo případně kombinovat)?
   • Jaký je nový klíč oddílu?

2. Migruje data ze starého schématu dělení na novou sadu oddílů.

V závislosti na úložišti dat může být možné migrovat data mezi oddíly, když se používají. To se označuje jako Online migrace. Pokud to není možné, možná budete muset při přemístění dat (offline migrace) nastavit oddíly jako nedostupné.

Offline migrace

Offline migrace je obvykle jednodušší, protože snižuje pravděpodobnost výskytu sporů. V koncepčním režimu offline migrace funguje takto:

1. Označí oddíl jako offline.
2. Rozdělí a přesune data na nové oddíly.
3. Ověření dat.
4. Přepněte nové oddíly online.
5. Odeberte starý oddíl.

Volitelně můžete označit oddíl jako jen pro čtení v kroku 1, aby aplikace mohli během přesouvání data dál číst.

Online migrace

Online migrace je složitější, aby se prováděla, ale méně narušila. Tento proces je podobný offline migraci, s výjimkou toho, že původní oddíl není označen jako offline. V závislosti na členitosti procesu migrace (například položka podle položky oproti horizontálních oddílů podle horizontálních oddílů) může být kód pro přístup k datům v klientských aplikacích schopný zpracovat čtení a zápis dat, která jsou uložená ve dvou umístěních, v původním oddílu a v novém oddílu.

Související vzory

K vašemu scénáři můžou být relevantní tyto vzory návrhu:

• Vzor horizontálního dělení popisuje některé běžné strategie pro data horizontálního dělení.

• Vzor tabulky indexů ukazuje, jak vytvořit sekundární indexy pro data. Díky tomuto přístupu může aplikace rychle načítat data pomocí dotazů, které neodkazují na primární klíč kolekce.

• Vzor materializované zobrazení popisuje, jak generovat předem vyplněná zobrazení, která shrnují data pro podporu operací rychlého dotazování. Tento přístup může být užitečný v děleném úložišti dat, pokud jsou oddíly obsahující data, která se sumarizují, distribuované napříč několika lokalitami.

Další kroky

• Přečtěte si o strategiích dělení pro konkrétní služby Azure. Zobrazit strategie dělení dat