Pokyny k dělení dat

Azure Blob Storage

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.

Poznámka:

V tomto článku termín dělení znamená proces fyzického rozdělení dat do samostatných úložišť dat. Není to stejné jako dělení tabulek SQL Serveru.

Proč rozdělovat data?

• Zlepšení škálovatelnosti Při vertikálním navýšení kapacity jednoúčelového databázového systému se nakonec dosáhne limitu fyzického 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í přes menší objem dat. Správně provedené dělení může zefektivnit váš systém. Operace, které ovlivňují více než jeden oddíl, se můžou spouštět paralelně.

• Zlepš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 správy, monitorování, zálohování a obnovení a další úlohy správy na základě důležitosti dat v jednotlivých oddílech.

• Porovná úložiště dat se vzorem použití. Dělení umožňuje nasazení jednotlivých oddílů do jiného typu úložiště dat na základě nákladů a integrovaných funkcí, které úložiště dat nabízí. 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. Oddělení dat mezi více servery zabraňuje jedinému bodu selhání. Pokud jedna instance selže, nebudou k dispozici pouze data v tomto oddílu. Operace s jinými oddíly můžou 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í.

Návrh oddílů

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

• Horizontální dělení (často označované jako horizontální dělení) 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í. V této strategii každý oddíl obsahuje podmnožinu polí pro položky v úložišti dat. Pole jsou rozdělena podle jejich způsobu použití. Často přístupná pole se můžou například umístit do jednoho vertikálního oddílu a méně často přístupná pole v jiném.

• Funkční dělení V této strategii se data agregují podle toho, jak se používají podle jednotlivých ohraničených kontextů v 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 pak pomocí vertikálního dělení dále rozdělit data v jednotlivých horizontálních oddílech.

Horizontální dělení (horizontální dělení)

Obrázek 1 znázorňuje horizontální dělení nebo horizontální dělení. V tomto příkladu se data inventáře produktů dělí na horizontální oddíly na základě kódu Product Key. Každý horizontální oddíl obsahuje data pro souvislou oblast klíčů horizontálních oddílů (A-G a H-Z) uspořádaných abecedně. 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í. Po spuštění systému může být obtížné změnit klíč. 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 můžou být menší, ale ke každé položce 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 můžou být velmi časově náročné a můžou vyžadovat offline jeden nebo více horizontálních oddílů.

Pokud se horizontální oddíly replikují, může být možné zachovat některé repliky online, zatímco jiné jsou rozdělené, sloučené nebo překonfigurované. 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 aplikace při zobrazování podrobností o produktu zákazníkům pravidelně dotazuje název produktu, popis a cenu. 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 na úrovni entity v úložišti dat a částečně normalizuje entitu, aby ji rozdělila od široké položky do sady úzkých položek. Je ideální pro úložiště dat orientovaných na sloupce, jako jsou HBase a Cassandra. Pokud se data v kolekci sloupců pravděpodobně nezmění, můžete také zvážit použití úložišť sloupců na 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 inventáře 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í může pomoct omezit kolize přístupu k datům v různých částech systému.

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

Je důležité zvážit velikost a úlohu pro každý oddíl a vyvážit je tak, aby se data distribuovala, aby se dosáhlo maximální škálovatelnosti. Musíte ale také rozdělit data tak, aby nepřekračovala limity škálování jednoho úložiště oddílů.

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

1. Analyzujte aplikaci, abyste porozuměli vzorům přístupu k datům, jako je například velikost sady výsledků vrácené jednotlivými dotazy, frekvence přístupu, vlastní latence a požadavky na zpracování výpočetních prostředků na straně serveru. V mnohapřípadechch
2. Pomocí této analýzy můžete určit aktuální a budoucí cíle škálovatelnosti, například velikost dat a úlohy. Pak distribuujte data napříč oddíly, aby se splnil cíl š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. Ujistěte se, že limity vybrané hranice poskytují dostatek místa pro jakýkoli očekávaný nárůst objemu dat 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.

Návrh oddílů pro výkon dotazů

Výkon dotazů se často zvyšuje pomocí menších datových sad a spouštěním paralelních dotazů. Každý oddíl by měl obsahovat malou část celé datové sady. Toto snížení objemu může zlepšit výkon dotazů. Dělení ale není alternativou pro návrh a konfiguraci databáze odpovídajícím způsobem. Ujistěte se například, že máte zavedené potřebné indexy.

Při návrhu oddílů pro výkon dotazů postupujte takto:

1. Prozkoumejte požadavky a výkon aplikace:

   • Pomocí obchodních požadavků můžete určit důležité dotazy, které musí vždy provádět rychle.
   • Monitorujte systém a identifikujte všechny dotazy, které se provádějí pomalu.
   • 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. Rozdělte data, která způsobují nízký výkon:

   • Omezte velikost každého oddílu tak, aby doba odezvy dotazu byla v cíli.
   • Pokud používáte horizontální dělení, navrhejte klíč horizontálního oddílu tak, aby aplikace snadno vybrala správný oddíl. Tím zabráníte, aby dotaz musel prohledávat všechny oddíly.
   • Zvažte umístění oddílu. Pokud je to možné, zkuste zachovat data v oddílech, které jsou geograficky blízko aplikacím a uživatelům, kteří k němu přistupují.

3. Pokud má entita požadavky na propustnost a výkon dotazů, použijte funkční dělení na základě této entity. Pokud tyto požadavky stále nevyhovují, 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.

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

Rozdělení dat může zlepšit dostupnost aplikací tím, že zajistí, že celá datová sada nepředstavuje jediný bod selhání a že jednotlivé podmnožina datové sady je možné spravovat nezávisle.

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

Jak důležitá jsou data 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, která mají stejnou úroveň závažnosti, umístěte do stejného oddílu, aby je bylo možné zálohovat společně s příslušnou 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í.

Jak je možné spravovat jednotlivé oddíly. Návrh oddílů pro podporu nezávislé správy a údržby nabízí několik výhod. Napří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.

• Rozdělení dat podle geografické oblasti umožňuje, aby úlohy plánované údržby probíhaly v době mimo špičku pro každé umístění. 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čuje, jestli se mají replikovat důležitá data 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é datové hodnoty.

Aspekty návrhu aplikací

Dělení zvyšuje složitost návrhu a vývoje systému. Zvažte dělení jako základní součá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 lze ji snadno zpracovat jedním serverem. 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 malé úložiště dat může mít velký přístup stovky souběžných klientů. Rozdělení dat v této situaci může pomoct snížit kolize a zlepš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 data pro nejběžnější databázové operace v jednotlivých oddílech, abyste minimalizovali operace 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 zrušení normalizace 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.

Přijměte konečnou konzistenci. Vyhodnoťte, jestli je ve skutečnosti požadavkem silná konzistence. Běžným přístupem v distribuovaných systémech je implementace konečné konzistence. Data v každém oddílu se aktualizují samostatně a logika aplikace zajišťuje úspěšné dokončení aktualizací. Zpracovává také nekonzistence, které můžou vzniknout z dotazování na data, zatímco je spuštěná operace, která je nakonec konzistentní.

Zvažte, jak dotazy vyhledá správný oddíl. Pokud dotaz musí prohledat všechny oddíly a vyhledat požadovaná data, má významný dopad na výkon, i když je spuštěno 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 v logice horizontálního dělení aplikace nebo ji udržovat úložiště 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 ale o složitý úkol, který často vyžaduje použití vlastního nástroje nebo procesu.

Replikujte oddíly. Pokud replikujete každý oddíl, poskytuje dodatečnou ochranu proti selhání. Pokud selže jedna replika, dotazy se dají směrovat na funkční kopii.

Pokud dosáhnete fyzických limitů strategie dělení, možná budete muset rozšířit škálovatelnost na jinou úroveň. Pokud je například dělení na úrovni databáze, možná budete muset vyhledat nebo replikovat oddíly ve více databázích. Pokud už dělení probíhá na úrovni databáze a fyzická omezení jsou problém, může to znamenat, že potřebujete vyhledat nebo replikovat oddíly v několika hostitelských účtech.

Vyhněte se transakcím, které přistupují k datům v několika oddílech. Některá úložiště dat implementují transakční konzistenci a integritu operací, které upravují data, ale pouze v případě, že jsou data umístěná v jednom oddílu. Pokud potřebujete transakční podporu napříč několika oddíly, budete ji pravděpodobně 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čitou provozní správu a monitorování aktivit. Úlohy můžou být v rozsahu od načítání dat, zálohování a obnovování dat, přeuspořá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:

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

• 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 nástroje nemusí podporovat operace horizontálně dělených dat, jako je načtení dat do správného oddílu.

• Jak pravidelně archivovat a odstraňovat data. Abyste zabránili nadměrnému růstu oddílů, musíte pravidelně archivovat a odstraňovat data (například měsíčně). Může být nutné transformovat data tak, aby odpovídala jinému schématu archivu.

• Jak najít problémy 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. Ověřte 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. Aplikace může pomocí tohoto přístupu 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 se oddíly obsahující souhrnná data distribuují napříč několika lokalitami.

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.

Poznámka:

V tomto článku termín dělení znamená proces fyzického rozdělení dat do samostatných úložišť dat. Není to stejné jako dělení tabulek SQL Serveru.

Proč rozdělovat data?

• Zlepšení škálovatelnosti Při vertikálním navýšení kapacity jednoúčelového databázového systému se nakonec dosáhne limitu fyzického 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í přes menší objem dat. Správně provedené dělení může zefektivnit váš systém. Operace, které ovlivňují více než jeden oddíl, se můžou spouštět paralelně.

• Zlepš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 správy, monitorování, zálohování a obnovení a další úlohy správy na základě důležitosti dat v jednotlivých oddílech.

• Porovná úložiště dat se vzorem použití. Dělení umožňuje nasazení jednotlivých oddílů do jiného typu úložiště dat na základě nákladů a integrovaných funkcí, které úložiště dat nabízí. 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. Oddělení dat mezi více servery zabraňuje jedinému bodu selhání. Pokud jedna instance selže, nebudou k dispozici pouze data v tomto oddílu. Operace s jinými oddíly můžou 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í.

Návrh oddílů

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

• Horizontální dělení (často označované jako horizontální dělení) 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í. V této strategii každý oddíl obsahuje podmnožinu polí pro položky v úložišti dat. Pole jsou rozdělena podle jejich způsobu použití. Často přístupná pole se můžou například umístit do jednoho vertikálního oddílu a méně často přístupná pole v jiném.

• Funkční dělení V této strategii se data agregují podle toho, jak se používají podle jednotlivých ohraničených kontextů v 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 pak pomocí vertikálního dělení dále rozdělit data v jednotlivých horizontálních oddílech.

Horizontální dělení (horizontální dělení)

Obrázek 1 znázorňuje horizontální dělení nebo horizontální dělení. V tomto příkladu se data inventáře produktů dělí na horizontální oddíly na základě kódu Product Key. Každý horizontální oddíl obsahuje data pro souvislou oblast klíčů horizontálních oddílů (A-G a H-Z) uspořádaných abecedně. 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í. Po spuštění systému může být obtížné změnit klíč. 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 můžou být menší, ale ke každé položce 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 můžou být velmi časově náročné a můžou vyžadovat offline jeden nebo více horizontálních oddílů.

Pokud se horizontální oddíly replikují, může být možné zachovat některé repliky online, zatímco jiné jsou rozdělené, sloučené nebo překonfigurované. 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 aplikace při zobrazování podrobností o produktu zákazníkům pravidelně dotazuje název produktu, popis a cenu. 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 na úrovni entity v úložišti dat a částečně normalizuje entitu, aby ji rozdělila od široké položky do sady úzkých položek. Je ideální pro úložiště dat orientovaných na sloupce, jako jsou HBase a Cassandra. Pokud se data v kolekci sloupců pravděpodobně nezmění, můžete také zvážit použití úložišť sloupců na 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 inventáře 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í může pomoct omezit kolize přístupu k datům v různých částech systému.

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

Je důležité zvážit velikost a úlohu pro každý oddíl a vyvážit je tak, aby se data distribuovala, aby se dosáhlo maximální škálovatelnosti. Musíte ale také rozdělit data tak, aby nepřekračovala limity škálování jednoho úložiště oddílů.

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

1. Analyzujte aplikaci, abyste porozuměli vzorům přístupu k datům, jako je například velikost sady výsledků vrácené jednotlivými dotazy, frekvence přístupu, vlastní latence a požadavky na zpracování výpočetních prostředků na straně serveru. V mnohapřípadechch
2. Pomocí této analýzy můžete určit aktuální a budoucí cíle škálovatelnosti, například velikost dat a úlohy. Pak distribuujte data napříč oddíly, aby se splnil cíl š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. Ujistěte se, že limity vybrané hranice poskytují dostatek místa pro jakýkoli očekávaný nárůst objemu dat 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.

Návrh oddílů pro výkon dotazů

Výkon dotazů se často zvyšuje pomocí menších datových sad a spouštěním paralelních dotazů. Každý oddíl by měl obsahovat malou část celé datové sady. Toto snížení objemu může zlepšit výkon dotazů. Dělení ale není alternativou pro návrh a konfiguraci databáze odpovídajícím způsobem. Ujistěte se například, že máte zavedené potřebné indexy.

Při návrhu oddílů pro výkon dotazů postupujte takto:

1. Prozkoumejte požadavky a výkon aplikace:

   • Pomocí obchodních požadavků můžete určit důležité dotazy, které musí vždy provádět rychle.
   • Monitorujte systém a identifikujte všechny dotazy, které se provádějí pomalu.
   • 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. Rozdělte data, která způsobují nízký výkon:

   • Omezte velikost každého oddílu tak, aby doba odezvy dotazu byla v cíli.
   • Pokud používáte horizontální dělení, navrhejte klíč horizontálního oddílu tak, aby aplikace snadno vybrala správný oddíl. Tím zabráníte, aby dotaz musel prohledávat všechny oddíly.
   • Zvažte umístění oddílu. Pokud je to možné, zkuste zachovat data v oddílech, které jsou geograficky blízko aplikacím a uživatelům, kteří k němu přistupují.

3. Pokud má entita požadavky na propustnost a výkon dotazů, použijte funkční dělení na základě této entity. Pokud tyto požadavky stále nevyhovují, 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.

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

Rozdělení dat může zlepšit dostupnost aplikací tím, že zajistí, že celá datová sada nepředstavuje jediný bod selhání a že jednotlivé podmnožina datové sady je možné spravovat nezávisle.

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

Jak důležitá jsou data 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, která mají stejnou úroveň závažnosti, umístěte do stejného oddílu, aby je bylo možné zálohovat společně s příslušnou 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í.

Jak je možné spravovat jednotlivé oddíly. Návrh oddílů pro podporu nezávislé správy a údržby nabízí několik výhod. Napří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.

• Rozdělení dat podle geografické oblasti umožňuje, aby úlohy plánované údržby probíhaly v době mimo špičku pro každé umístění. 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čuje, jestli se mají replikovat důležitá data 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é datové hodnoty.

Aspekty návrhu aplikací

Dělení zvyšuje složitost návrhu a vývoje systému. Zvažte dělení jako základní součá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 lze ji snadno zpracovat jedním serverem. 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 malé úložiště dat může mít velký přístup stovky souběžných klientů. Rozdělení dat v této situaci může pomoct snížit kolize a zlepš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 data pro nejběžnější databázové operace v jednotlivých oddílech, abyste minimalizovali operace 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 zrušení normalizace 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.

Přijměte konečnou konzistenci. Vyhodnoťte, jestli je ve skutečnosti požadavkem silná konzistence. Běžným přístupem v distribuovaných systémech je implementace konečné konzistence. Data v každém oddílu se aktualizují samostatně a logika aplikace zajišťuje úspěšné dokončení aktualizací. Zpracovává také nekonzistence, které můžou vzniknout z dotazování na data, zatímco je spuštěná operace, která je nakonec konzistentní.

Zvažte, jak dotazy vyhledá správný oddíl. Pokud dotaz musí prohledat všechny oddíly a vyhledat požadovaná data, má významný dopad na výkon, i když je spuštěno 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 v logice horizontálního dělení aplikace nebo ji udržovat úložiště 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 ale o složitý úkol, který často vyžaduje použití vlastního nástroje nebo procesu.

Replikujte oddíly. Pokud replikujete každý oddíl, poskytuje dodatečnou ochranu proti selhání. Pokud selže jedna replika, dotazy se dají směrovat na funkční kopii.

Pokud dosáhnete fyzických limitů strategie dělení, možná budete muset rozšířit škálovatelnost na jinou úroveň. Pokud je například dělení na úrovni databáze, možná budete muset vyhledat nebo replikovat oddíly ve více databázích. Pokud už dělení probíhá na úrovni databáze a fyzická omezení jsou problém, může to znamenat, že potřebujete vyhledat nebo replikovat oddíly v několika hostitelských účtech.

Vyhněte se transakcím, které přistupují k datům v několika oddílech. Některá úložiště dat implementují transakční konzistenci a integritu operací, které upravují data, ale pouze v případě, že jsou data umístěná v jednom oddílu. Pokud potřebujete transakční podporu napříč několika oddíly, budete ji pravděpodobně 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čitou provozní správu a monitorování aktivit. Úlohy můžou být v rozsahu od načítání dat, zálohování a obnovování dat, přeuspořá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:

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

• 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 nástroje nemusí podporovat operace horizontálně dělených dat, jako je načtení dat do správného oddílu.

• Jak pravidelně archivovat a odstraňovat data. Abyste zabránili nadměrnému růstu oddílů, musíte pravidelně archivovat a odstraňovat data (například měsíčně). Může být nutné transformovat data tak, aby odpovídala jinému schématu archivu.

• Jak najít problémy 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. Ověřte 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. Aplikace může pomocí tohoto přístupu 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 se oddíly obsahující souhrnná data distribuují napříč několika lokalitami.