Pokyny k dělení dat

V mnoha rozsáhlých řešeních jsou data rozdělená na oddíly , ke kterým je možné spravovat a přistupovat 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.

Strategie dělení však musí být zvolena pečlivě, aby se maximalizovaly výhody a zároveň minimalizovaly nežádoucí účinky.

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ů, každý hostovaný na samostatném serveru, můžete systém škálovat téměř na neomezenou dobu.

• Zvýšení výkonu. Operace přístupu k datům v jednotlivých oddílech probíhají v menších objemech dat. Správně provedené dělení může zefektivnit váš systém. Operace, které ovlivňují víc než jeden oddíl, mohou běžet paralelně.

• Vylepšení zabezpečení. V některýchpřípadechch

• Zajištění provozní flexibility. Dělení nabízí mnoho příležitostí k vyladění operací, maximalizaci efektivity správy 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 velká binární data se dají ukládat do úložiště objektů blob, zatímco strukturovanější data se dají uchovávat v databázi dokumentů. Další informace najdete v tématu Volba 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 jedna instance selže, nebudou k dispozici pouze data v tomto oddílu. Operace s dalšími oddíly mohou pokračovat. U úložišť dat PaaS (Managed Platform as a Service) je tento faktor méně relevantní, 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ým úložištěm dat, ale všechny oddíly mají stejné schéma. Každý oddíl se označuje jako horizontální oddíl a obsahuje konkrétní podmnožinu dat, například všechny objednávky pro určitou sadu 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. Například systém elektronického obchodování může ukládat data faktury do jednoho oddílu a data inventáře produktů v jiném oddílu.

Tyto strategie se dají kombinovat a při návrhu schématu dělení doporučujeme je všechny zvážit. 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 znázorňuje horizontální dělení nebo horizontální 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í dělení rozšiřuje zatížení na více počítačů, což snižuje kolize a zlepšuje výkon.

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

Nejdůležitějším faktorem je volba klíče horizontálního dělení. Jakmile je systém v provozu, může být změna klíčů někdy obtížná. Klíč musí zajistit, aby se data rozdělila tak, aby se úloha co nejvíce rozprostřela napříč horizontálními oddíly.

Horizontální oddíly nemusí mít stejnou velikost. Je důležitější vyvážit počet požadavků. Některé horizontální oddíly můžou být velmi velké, ale každá položka má malý 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í oddíl nepřekračoval limity škálování (z hlediska kapacity a prostředků zpracování) úložiště dat.

Vyhněte se vytváření "horkých" oddílů, které můžou ovlivnit výkon a dostupnost. Když například použijete první písmeno jména zákazníka, způsobí nevyváženou distribuci, protože některá písmena jsou běžnější. Místo toho pomocí hodnoty hash identifikátoru zákazníka distribuujte data rovnoměrněji napříč oddíly.

Zvolte klíč horizontálního dělení, který minimalizuje případné budoucí požadavky pro rozdělení velkých horizontálních oddílů, shodování malých horizontálních oddílů do větších oddílů 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 potřebovat omezit operace, které je možné provést během rekonfigurace. Například data v replikách mohou být označena jako jen pro čtení, aby se zabránilo nekonzistenci dat.

Další informace o horizontálním dělení najdete v tématu Vzor horizontálního dělení.

Vertikální dělení

Nejběžnějším využitím vertikálního dělení je snížit náklady na vstupně-výstupní operace a výkon spojené s načítáním často přístupných položek. 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 se přistupuje častěji, včetně názvu produktu, popisu a ceny. Další oddíl obsahuje data inventáře: počet zásob a datum poslední objednávky.

Obrázek 2 – Vertikální dělení dat podle 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 akcií a datum poslední objednávky se uchovávají v samostatném oddílu, protože tyto dvě položky se běžně používají společně.

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

• Relativně pomalá data (název produktu, popis a cena) je možné oddělit od dynamičtějších dat (úroveň zásob a datum poslední objednávky). Pomalé přesouvání dat je vhodným kandidátem pro aplikaci pro ukládání do mezipaměti v paměti.

• Citlivá data je možné ukládat do samostatného oddílu s dalšími bezpečnostními prvky.

• Vertikální dělení může snížit množství souběžného přístupu, který je potřeba.

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 samostatnou 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 funkčního dělení je oddělení dat pro čtení a zápis od dat 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 – Funkční dělení dat ohraničeným kontextem nebo subdoménou

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. Při horizontálním dělení je důležité zvolit správný klíč horizontálního oddílu, abyste měli jistotu, že je distribuce rovnoměrná. Další informace najdete v modelu horizontálního dělení.
3. Ujistěte se, že každý oddíl má dostatek prostředků pro zpracování požadavků na škálovatelnost z hlediska velikosti a propustnosti dat. V závislosti na úložišti dat může existovat omezení velikosti úložného prostoru, výpočetního výkonu nebo šířky pásma sítě na oddíl. Pokud požadavky pravděpodobně překročí tyto limity, možná budete muset upřesnit strategii dělení nebo rozdělit data dál a případně zkombinovat dvě nebo více strategií.
4. Monitorujte systém a ověřte, že jsou data distribuovaná podle očekávání a že oddíly můžou zpracovat zatížení. Skutečné využití neodpovídá tomu, co analýza predikuje. Pokud ano, může být možné znovu vyrovnat oddíly nebo přepracovat některé části systému tak, aby získaly požadovaný zůstatek.

Některá cloudová prostředí přidělují prostředky z hlediska hranic 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 Úložiště tabulek Azure, existuje omezení objemu požadavků, které je možné zpracovat jedním oddílem v určitém časovém období. (Další informace najdete v tématu Škálovatelnost a výkonnostní cíle služby Azure Storage.) Zaneprázdněný horizontální oddíl může vyžadovat více prostředků, než může zpracovat jeden oddíl. Pokud ano, horizontální oddíl může být potřeba znovu rozdělovat, aby se zatížení rozložilo. Pokud celková velikost nebo propustnost těchto tabulek překročí kapacitu účtu úložiště, budete možná muset vytvořit další účty úložiště a rozložit tabulky mezi tyto úč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 zavedené 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í obchodních požadavků můžete určit důležité dotazy, které musí vždy provádět rychle.
   • Sledujte systém a určete případné dotazy, jejichž zpracování je pomalé.
   • Zjistěte, které dotazy se provádějí nejčastěji. I když má jeden dotaz 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í, navrhejte klíč horizontálního oddílu tak, aby aplikace snadno vybrala 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ů stačí jedna strategie dělení, ale v některých případech je efektivnější kombinovat obě strategie.

4. Pokud chcete zvýšit výkon, zvažte paralelní spouštění dotazů napříč oddíly.

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é ovlivňují dostupnost:

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

• Zvažte ukládání důležitých dat do vysoce dostupných oddílů s odpovídající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 potřeba zálohovat častěji než oddíly, které uchovávají informace 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. Příklad:

• Pokud dojde k selhání oddílu, je možné ho 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 se zabránilo dokončení plánované údržby během tohoto období.

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é zavádět problémy s konzistencí. Synchronizace změn s každou replikou nějakou dobu trvá. Během tohoto období budou různé oddíly obsahovat různé hodnoty dat.

Aspekty návrhu aplikace

Dělení zvyšuje složitost návrhu a vývoje 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 řešíte dělení na oddíly jako po skončení, bude náročnější, protože už máte živý systém pro údržbu:

• Logika přístupu k datům bude potřeba upravit.
• Aby bylo možné je distribuovat mezi oddíly, může být potřeba migrovat velké množství existujících dat.
• Uživatelé očekávají, že budou moct systém během migrace dál používat.

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 pravdivé pro některé úlohy, ale řada komerčních systémů se musí s rostoucím počtem uživatelů rozšířit.

Kromě toho se nejedná pouze o velká úložiště dat, která využívají dělení. 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 napříč 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é než dotazování v rámci jednoho oddílu, ale optimalizace oddílů pro jednu sadu dotazů může nepříznivě ovlivnit jiné sady dotazů. Pokud se musíte dotazovat napříč oddíly, minimalizujte čas dotazu spuštěním paralelních dotazů a agregací výsledků v aplikaci. (Tento přístup nemusí být v některých případech možný, například když se v dalším dotazu použije výsledek jednoho dotazu.)

Zvažte replikaci statických referenčních dat. Pokud dotazy používají relativně statická referenční data, jako jsou tabulky PSČ nebo seznamy produktů, zvažte replikaci těchto dat ve všech oddílech, aby se snížily samostatné vyhledávací operace 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 z celého systému. K synchronizaci jakýchkoli změn referenčních dat ale jsou spojené další náklady.

Minimalizujte spojení napříč 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 je aplikace zodpovědná za zachování referenční integrity napříč oddíly. Dotazy, které spojují data napříč několika oddíly, jsou neefektivní, protože aplikace obvykle potřebuje 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 přes oddíly a připojte data v aplikaci.

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ů. Při vertikálním a funkčním dělení můžou dotazy přirozeně určit oddíl. Horizontální dělení může na druhé straně znesnadnit vyhledání položky, protože každý horizontální 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ího oddílu 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í můžou horizontální horizontální oddíly přispět k rovnoměrné distribuci dat podle velikosti a úloh, aby se minimalizovaly hotspoty, maximalizoval výkon dotazů a spolupracovaly s omezeními 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 selže jedna replika, dotazy se dají směrovat na funkční 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. Abyste zabránili nadměrnému růstu oddílů, musíte 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, abyste našli problémy s integritou dat, jako jsou data v jednom oddílu, který odkazuje na chybějící informace v jiném oddílu. Proces se může pokusit tyto problémy opravit automaticky, nebo vygenerovat sestavu pro ruční kontrolu.

Vyrovnávání oddílů

Vzhledem k tomu, že systém zralý, možná budete muset upravit schéma dělení. Například jednotlivé oddíly můžou začít dostávat nepřiměřený objem provozu a začnou být horké, což vede k nadměrnému kolizí. Nebo jste možná podcenili objem dat v některých oddílech, což způsobuje, že některé oddíly přistupují k limitům kapacity.

Některá úložiště dat, jako je azure Cosmos DB, můžou automaticky vyrovnát oddíly. V jiných případech je vyrovnávání úlohou správy, která se skládá ze dvou fází:

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

   • Které oddíly je potřeba rozdělit (nebo případně zkombinovat)?
   • Co je nový klíč oddílu?

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

V závislosti na úložišti dat můžete během jejich používání migrovat data mezi oddíly. Tomu se říká online migrace. Pokud to není možné, možná budete muset v době přemístění dat (offline migrace) znepřístupnit oddíly.

Offline migrace

Offline migrace je obvykle jednodušší, protože snižuje riziko kolize. Offline migrace funguje koncepčně takto:

1. Označte oddíl jako offline.
2. Rozdělte a přesuňte data do nových oddílů.
3. Verify the data.
4. Přeneste nové oddíly do online režimu.
5. Odeberte starý oddíl.

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

Online migrace

Online migrace je složitější, ale méně rušivá. Tento proces je podobný offline migraci, s výjimkou původního oddílu není označený jako offline. V závislosti na členitosti procesu migrace (například položky podle položek a horizontálních oddílů podle horizontálních oddílů) může kód přístupu k datům v klientských aplikacích zpracovávat čtení a zápis dat uložených ve dvou umístěních, původní oddíl a nový oddíl.

Další kroky

• Seznamte se se strategiemi dělení pro konkrétní služby Azure. Další informace najdete v tématu Strategie dělení dat.
• Škálovatelnost a cíle výkonu služby Azure Storage

Související prostředky

• Výběr správného úložiště dat

Pro váš scénář můžou být relevantní následující vzory návrhu:

• Model horizontálního dělení popisuje některé běžné strategie horizontálního dělení dat.

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

• Model materializovaného zobrazení popisuje, jak generovat předem vyplněná zobrazení, která shrnují data pro podporu rychlých operací dotazů. 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.