Strategie dělení dat

Tento článek popisuje některé strategie dělení dat v různých úložištích dat Azure. Obecné pokyny k dělení dat a osvědčených postupů najdete v tématu Dělení dat.

Dělení služby Azure SQL Database

Pro jednu databázi SQL platí omezení objemu dat, která může obsahovat. Propustnost je omezená faktory architektury a počtem souběžných připojení, která architektura podporuje.

Elastické fondy podporují horizontální škálování pro databázi SQL. Pomocí elastických fondů můžete data rozdělit do horizontálních oddílů, které jsou rozložené do více databází SQL. S tím, jak se zvětšuje a zmenšuje objem dat, která potřebujete zpracovávat, můžete horizontální oddíly také přidávat nebo odebírat. Elastické fondy také můžou pomoct snížit kolize tím, že zatížení distribuují mezi databáze.

Každý horizontální oddíl se implementuje jako databáze SQL. Horizontální oddíl může obsahovat více než jednu datovou sadu (označovanou jako shardlet). Každá databáze uchovává metadata popisující shardlety, které obsahuje. Shardlet může být jedna datová položka nebo skupina položek, které sdílejí stejný klíč shardletu. Například ve víceklientské aplikaci může být klíč shardletu ID tenanta a všechna data pro tenanta se dají uchovávat ve stejném shardletu.

Klientské aplikace zodpovídají za přidružení datové sady k klíči shardletu. Samostatná databáze SQL funguje jako globální správce mapování horizontálních oddílů. Tato databáze obsahuje seznam všech horizontálních oddílů a shardletů v systému. Aplikace se připojí k databázi správce mapování horizontálních oddílů a získá kopii mapy horizontálních oddílů. Mapování horizontálních oddílů ukládá do mezipaměti místně a pomocí mapy směruje žádosti o data do příslušného horizontálního oddílu. Tato funkce je skrytá za řadou rozhraní API obsažených v klientské knihovně elastické databáze, která je k dispozici pro Javu a .NET.

Další informace o elastických fondech najdete v tématu Horizontální navýšení kapacity ve službě Azure SQL Database.

Pokud chcete snížit latenci a zlepšit dostupnost, můžete replikovat databázi globálního správce mapování horizontálních oddílů. S cenovými úrovněmi Premium můžete nakonfigurovat aktivní geografickou replikaci, která bude průběžně kopírovat data do databází v různých oblastech.

Případně můžete použít Synchronizace dat SQL Azure nebo Azure Data Factory k replikaci databáze správce mapování horizontálních oddílů napříč oblastmi. Tato forma replikace se spouští pravidelně a je vhodnější, pokud se mapa horizontálních oddílů změní zřídka a nevyžaduje úroveň Premium.

Elastic Database poskytuje dvě schémata pro mapování dat na shardlety a jejich ukládání v horizontálních oddílech:

• Mapa horizontálních oddílů seznamu přidruží k shardletu jeden klíč. Například ve víceklientském systému může být k datům pro každého tenanta přidružený jedinečný klíč a tato data můžou být uložená ve vlastním shardletu. Aby bylo možné zaručit izolaci, může být každý shardlet uložen v rámci svého vlastního horizontálního oddílu.

  

  Stáhněte si soubor Visia tohoto diagramu.

• Mapa horizontálních oddílů rozsahu přidruží sadu souvislých hodnot klíče k shardletu. Data pro sadu tenantů (každý s vlastním klíčem) můžete například seskupit do stejného shardletu. Toto schéma je levnější než první, protože tenanti sdílejí úložiště dat, ale mají menší izolaci.

  

  Stažení souboru Visia tohoto diagramu

Jeden horizontální oddíl může obsahovat data pro několik shardletů. Seznamy shardletů můžete použít například k ukládání dat pro různé nesouvislé tenanty ve stejném horizontálním oddílu. Můžete také kombinovat rozsahy shardletů a vypsat shardlety ve stejném horizontálním oddílu, i když budou adresovány prostřednictvím různých map. Následující diagram znázorňuje tento přístup:

Stáhněte si soubor Visia tohoto diagramu.

Elastické fondy umožňují přidávat a odebírat horizontální oddíly při zmenšení a růstu objemu dat. Klientské aplikace můžou dynamicky vytvářet a odstraňovat horizontální oddíly a transparentně aktualizovat správce mapování horizontálních oddílů. Odebrání horizontálního oddílu je však destruktivní operace, která vyžaduje také odstranění všech dat v daném horizontálním oddílu.

Pokud aplikace potřebuje rozdělit horizontální oddíl na dva samostatné horizontální oddíly nebo kombinovat horizontální oddíly, použijte nástroj pro rozdělení sloučení. Tento nástroj běží jako webová služba Azure a migruje data bezpečně mezi horizontálními oddíly.

Schéma dělení může výrazně ovlivnit výkon systému. Může také ovlivnit rychlost přidání nebo odebrání horizontálních oddílů nebo opětovné rozdělení dat napříč horizontálními oddíly. Zvažte následující skutečnosti:

• Seskupte data, která se používají společně ve stejném horizontálním oddílu, a vyhněte se operacím, které přistupují k datům z více horizontálních oddílů. Horizontální oddíl je databáze SQL sama o sobě a spojení mezi databázemi se musí provádět na straně klienta.

  I když SQL Database nepodporuje spojení mezi databázemi, můžete k provádění více horizontálních dotazů použít nástroje elastické databáze. Dotaz s více horizontálními oddíly odesílá jednotlivé dotazy do každé databáze a sloučí výsledky.

• Nenavrhujte systém, který má závislosti mezi horizontálními oddíly. Omezení referenční integrity, triggery a uložené procedury v jedné databázi nemohou odkazovat na objekty v jiné.

• Pokud máte referenční data, která se často používají dotazy, zvažte replikaci těchto dat napříč horizontálními oddíly. Tento přístup může odebrat potřebu spojení dat mezi databázemi. V ideálním případě by taková data měla být statická nebo pomalá, aby se minimalizovala úsilí replikace a snížila pravděpodobnost, že budou zastaralá.

• Shardlety, které patří do stejné mapy horizontálních oddílů, by měly mít stejné schéma. Sql Database toto pravidlo nevynucuje, ale správa dat a dotazování se stává velmi složitou, pokud má každý shardlet jiné schéma. Místo toho vytvořte pro každé schéma samostatné mapy horizontálních oddílů. Mějte na paměti, že data patřící různým shardletům se dají uložit do stejného horizontálního oddílu.

• Transakční operace jsou podporovány pouze pro data v rámci horizontálního oddílu, nikoli napříč horizontálními oddíly. Transakce můžou probíhat napříč shardlety, pokud jsou součástí stejného horizontálního oddílu. Proto pokud vaše obchodní logika potřebuje provádět transakce, buď uložte data do stejného horizontálního oddílu nebo implementujte konečnou konzistenci.

• Umístěte horizontální oddíly blízko uživatelům, kteří přistupují k datům v těchto horizontálních oddílech. Tato strategie pomáhá snižovat latenci.

• Vyhněte se kombinaci vysoce aktivních a relativně neaktivních horizontálních oddílů. Pokuste se rovnoměrně rozložit zatížení mezi horizontální oddíly. To může vyžadovat hashování klíčů horizontálního dělení. Pokud horizontální oddíly umisťujete geograficky, ujistěte se, že se hashované klíče mapují na shardlety v horizontálních oddílech uložených blízko uživatelům, kteří přistupují k datům.

Dělení služby Azure Table Storage

Azure Table Storage je úložiště klíč-hodnota, které je navržené pro dělení. Všechny entity jsou uložené v oddílu a oddíly se spravují interně službou Azure Table Storage. Každá entita uložená v tabulce musí obsahovat klíč se dvěma částmi, který zahrnuje:

• Klíč oddílu. Jedná se o řetězcovou hodnotu, která určuje oddíl, ve kterém azure Table Storage umístí entitu. Všechny entity se stejným klíčem oddílu jsou uložené ve stejném oddílu.

• Klíč řádku. Jedná se o řetězcovou hodnotu, která identifikuje entitu v rámci oddílu. Podle tohoto klíče jsou lexikálně seřazené všechny entity v rámci oddílu ve vzestupném pořadí. Kombinace klíče oddílu a klíče řádku musí být pro každou entitu jedinečná a její délka nesmí překročit 1 kB.

Pokud je entita přidána do tabulky s dříve nepoužitým klíčem oddílu, Azure Table Storage vytvoří pro tuto entitu nový oddíl. Další entity se stejným klíčem oddílu se uloží do stejného oddílu.

Tento mechanismus efektivně implementuje strategii automatického škálování na více instancí. Každý oddíl je uložený na stejném serveru v datacentru Azure, aby se zajistilo, že dotazy, které načítají data z jednoho oddílu, rychle poběží.

Microsoft publikoval cíle škálovatelnosti pro Azure Storage. Pokud váš systém pravděpodobně překročí tyto limity, zvažte rozdělení entit do více tabulek. Pomocí vertikálního dělení rozdělte pole do skupin, ke kterým se s největší pravděpodobností bude přistupovat společně.

Následující diagram znázorňuje logickou strukturu ukázkového účtu úložiště. Účet úložiště obsahuje tři tabulky: Customer Info (Informace o zákaznících), Product Info (Informace o produktech) a Order Info (Informace o objednávkách).

Každá tabulka obsahuje několik oddílů.

• V tabulce Informace o zákazníci jsou data rozdělena podle města, ve kterém se zákazník nachází. Klíč řádku obsahuje ID zákazníka.
• V tabulce Informace o produktu jsou produkty rozdělené podle kategorie produktu a klíč řádku obsahuje číslo produktu.
• V tabulce Informace o objednávce jsou objednávky rozdělené podle data objednávky a klíč řádku určuje čas přijetí objednávky. Všechna data jsou seřazená podle klíče řádku v každém oddílu.

Při návrhu entit pro Azure Table Storage zvažte následující body:

• Vyberte klíč oddílu a klíč řádku tím, jak se k datům přistupuje. Zvolte kombinaci klíče oddílu a klíče řádku, která podporuje většinu vašich dotazů. Nejúčinnější dotazy načítají data určením klíče oddílu i klíče řádku. Dotazy, které určují klíč oddílu a rozsah klíčů řádku, je možné dokončit prohledáním jednoho oddílu. To je poměrně rychlé, protože se data uchovávají v pořadí podle klíčů řádků. Pokud dotazy nespecifikují, který oddíl se má zkontrolovat, musí se zkontrolovat každý oddíl.

• Pokud má entita jeden přirozený klíč, použijte ho jako klíč oddílu a jako klíč řádku zadejte prázdný řetězec. Pokud má entita složený klíč skládající se ze dvou vlastností, vyberte nejpomalejší změnu vlastnosti jako klíč oddílu a druhý jako klíč řádku. Pokud má entita více než dvě vlastnosti klíče, použijte k zadání klíče oddílu a klíče řádku zřetězení těchto vlastností.

• Pokud pravidelně provádíte dotazy, které vyhledávají data pomocí jiných polí než klíčů oddílů a řádků, zvažte implementaci vzoru indexové tabulky nebo zvažte použití jiného úložiště dat, které podporuje indexování, jako je Azure Cosmos DB.

• Pokud vygenerujete klíče oddílů pomocí monotónní sekvence (například 0001, 0002, 0003) a každý oddíl obsahuje jenom omezené množství dat, azure Table Storage může tyto oddíly fyzicky seskupit na stejném serveru. Azure Storage předpokládá, že aplikace s největší pravděpodobností provádí dotazy v souvislém rozsahu oddílů (dotazů na rozsah) a je optimalizovaná pro tento případ. Tento přístup však může vést k hotspotům, protože všechny vložení nových entit budou pravděpodobně soustředěny na jednom konci souvislého rozsahu. Může také omezit škálovatelnost. Pokud chcete zatížení rovnoměrněji rozložit, zvažte zatřiďování klíče oddílu.

• Azure Table Storage podporuje transakční operace pro entity, které patří do stejného oddílu. Aplikace může provádět více operací vložení, aktualizace, odstranění, nahrazení nebo sloučení jako atomické jednotky, pokud transakce neobsahuje více než 100 entit a datová část požadavku nepřekračuje 4 MB. Operace, které zahrnují více oddílů, nejsou transakční a můžou vyžadovat implementaci konečné konzistence. Další informace o úložišti tabulek a transakcích naleznete v tématu Provádění transakcí skupiny entit.

• Zvažte členitost klíče oddílu:

  • Použití stejného klíče oddílu pro každou entitu vede k jednomu oddílu, který je uložený na jednom serveru. Tím zabráníte horizontálnímu navýšení kapacity oddílu a zaměříte se na zatížení na jeden server. V důsledku toho je tento přístup vhodný pouze pro ukládání malého počtu entit. Zajišťuje však, aby se všechny entity mohly účastnit transakcí skupin entit.

  • Použití jedinečného klíče oddílu pro každou entitu způsobí, že služba Table Storage vytvoří pro každou entitu samostatný oddíl, což může mít za následek velký počet malých oddílů. Tento přístup nabízí větší škálovatelnost než použití jednoho klíče oddílu, ale neumožňuje transakce skupin entit. Kromě toho můžou dotazy, které načítají více než jednu entitu, zahrnovat čtení z více než jednoho serveru. Pokud ale aplikace provádí dotazy na rozsah, může s optimalizací těchto dotazů pomoct použití monotónní sekvence klíčů oddílů.

  • Sdílení klíče oddílu mezi podmnožinou entit umožňuje seskupit související entity ve stejném oddílu. Operace, které zahrnují související entity, je možné provádět pomocí transakcí skupin entit a dotazy, které načítají sadu souvisejících entit, je možné splnit přístupem na jeden server.

Další informace najdete v průvodci návrhem tabulek Azure Storage a strategii škálovatelného dělení.

Dělení služby Azure Blob Storage

Azure Blob Storage umožňuje uchovávat velké binární objekty. Objekty blob bloku používejte ve scénářích, kdy potřebujete rychle nahrát nebo stáhnout velké objemy dat. Objekty blob stránky použijte pro aplikace, které místo sériového přístupu k částem dat vyžadují náhodný přístup.

Každý objekt blob (blok nebo stránka) se uchovává v kontejneru v účtu služby Azure Storage. Pomocí kontejnerů můžete seskupovat související objekty blob, které mají stejné požadavky na zabezpečení. Toto seskupení je spíše logické než fyzické. Uvnitř kontejneru má každý objekt blob jedinečný název.

Klíč oddílu pro objekt blob se skládá z názvu účtu, názvu kontejneru a názvu objektu blob. Klíč oddílu slouží k rozdělení dat do rozsahů a tyto rozsahy jsou v systému vyrovnávané zatížením. Objekty blob je možné distribuovat napříč mnoha servery za účelem škálování přístupu na více instancí, ale jeden objekt blob může být obsluhovaný pouze jedním serverem.

Pokud vaše schéma pojmenování používá časové razítko nebo číselné identifikátory, může vést k nadměrnému provozu do jednoho oddílu, což omezuje systém z efektivního vyrovnávání zatížení. Pokud máte například každodenní operace, které používají objekt blob s časovým razítkem, jako je například yyyy-mm-dd, veškerý provoz pro tuto operaci by šel na jeden server oddílů. Místo toho zvažte předponu názvu trojcifernou hodnotou hash. Další informace najdete v tématu Zásady vytváření názvů oddílů.

Akce zápisu jednoho bloku nebo stránky jsou atomické, ale operace, které zahrnují bloky, stránky nebo objekty blob, nejsou. Pokud potřebujete zajistit konzistenci při provádění operací zápisu napříč bloky, stránkami a objekty blob, pomocí zapůjčení objektu blob odstraňte zámek pro zápis.

Dělení front Azure Storage

Fronty azure Storage umožňují implementovat asynchronní zasílání zpráv mezi procesy. Účet Azure Storage může obsahovat libovolný počet front a každá fronta může obsahovat libovolný počet zpráv. Jediným omezením je dostupné místo v účtu úložiště. Maximální velikost jednotlivých zpráv je 64 kB. Pokud potřebujete větší zprávy, zvažte místo toho použití front Azure Service Bus.

Každá fronta úložiště má jedinečný název v rámci účtu úložiště, ve kterém se nachází. Azure dělí fronty podle názvu. Všechny zprávy pro jednu frontu se ukládají do stejného oddílu, což řídí jeden server. Různé fronty je možné spravovat různými servery a podpořit tak vyrovnávání zatížení. Přidělování front serverům je pro aplikace i uživatele transparentní.

V rozsáhlé aplikaci nepoužívejte stejnou frontu úložiště pro všechny instance aplikace, protože tento přístup může způsobit, že server, který je hostitelem fronty, se stane horkým místem. Místo toho používejte různé fronty pro různé funkční oblasti aplikace. Fronty Azure Storage nepodporují transakce, takže směrování zpráv do různých front by mělo mít malý vliv na konzistenci zasílání zpráv.

Fronta Azure Storage dokáže zpracovat až 2 000 zpráv za sekundu. Pokud potřebujete zpracovávat zprávy větší rychlostí, zvažte vytvoření několika front. V případě globální aplikace například můžete vytvořit samostatné fronty úložiště v samostatných účtech úložiště, které budou obsluhovat instance aplikace spuštěné v jednotlivých oblastech.

Dělení služby Azure Service Bus

Azure Service Bus zpracovává zprávy odeslané do fronty nebo tématu služby Service Bus pomocí zprostředkovatele zpráv. Ve výchozím nastavení se všechny zprávy odeslané do fronty nebo tématu zpracovávají stejným procesem zprostředkovatele zpráv. Tato architektura může způsobit omezení celkové propustnosti fronty zpráv. Frontu nebo téma však můžete dělit i při jejich vytvoření. Provedete to nastavením vlastnosti EnablePartitioning v popisu fronty nebo tématu na hodnotu true.

Dělená fronta nebo téma se rozdělí na několik fragmentů, z nichž každý využívá samostatné úložiště zpráv a zprostředkovatele zpráv. Za vytváření a správu těchto fragmentů je zodpovědná služba Service Bus. Když aplikace odešle zprávu do dělené fronty nebo tématu, Service Bus tuto zprávu přiřadí k fragmentu dané fronty nebo tématu. Když aplikace přijme zprávu z fronty nebo odběru, Service Bus zkontroluje v každém fragmentu další dostupnou zprávu a pak ji předá aplikaci ke zpracování.

Tato struktura pomáhá distribuovat zatížení mezi zprostředkovatele zpráv a úložiště zpráv a tím zvyšuje škálovatelnost a zlepšuje dostupnost. Pokud dojde k dočasné nedostupnosti zprostředkovatele zpráv nebo úložiště zpráv pro jeden fragment, Service Bus může načíst zprávy z některého ze zbývajících dostupných fragmentů.

Service Bus přiřazuje zprávy k fragmentům následujícím způsobem:

• Pokud zpráva patří do relace, všechny zprávy se stejnou hodnotou vlastnosti SessionId se odešlou do stejného fragmentu.

• Pokud zpráva není součástí relace, ale odesílatel zadal hodnotu vlastnosti PartitionKey (Klíč oddílu), pak se všechny zprávy se stejnou hodnotou PartitionKey odešlou do stejného fragmentu.

  Poznámka:

  Pokud je zadaná vlastnost SessionId i PartitionKey, musí obě být nastavené na stejnou hodnotu, jinak se zpráva odmítne.

• Pokud pro zprávu nejsou zadané vlastnosti SessionId a PartitionKey, ale je povolená detekce duplicit, použije se vlastnost MessageId (ID zprávy). Všechny zprávy se stejnou hodnotou MessageId se přesměrují do stejného fragmentu.

• Pokud zprávy neobsahují vlastnost SessionId, PartitionKey ani MessageId, přiřazuje Service Bus zprávy k fragmentům postupně. Pokud je nějaký fragment nedostupný, Service Bus se přesune k dalšímu. To znamená, že dočasná chyba v infrastruktuře zasílání zpráv nezpůsobí selhání operace odeslání zprávy.

Při rozhodování, jestli nebo jak dělit frontu zpráv nebo téma služby Service Bus, zvažte následující body:

• Fronty a témata služby Service Bus se vytváří v rámci rozsahu oboru názvů služby Service Bus. Service Bus aktuálně umožňuje v jednom oboru názvů až 100 dělených front nebo témat.

• Každý obor názvů služby Service Bus má kvóty na dostupné prostředky, jako je například počet odběrů na téma, počet souběžných požadavků na odeslání nebo přijetí za sekundu a maximální počet souběžných připojení, které je možné navázat. Tyto kvóty jsou popsané v kvótách služby Service Bus. Pokud očekáváte, že tyto kvóty překročíte, vytvořte další obory názvů s vlastními frontami a tématy a rozložte práci mezi tyto obory názvů. V případě globální aplikace například můžete vytvořit samostatné obory názvů v každé oblasti a nakonfigurovat instance aplikace tak, aby používaly fronty a témata v nejbližším oboru názvů.

• Zprávy odeslané v rámci transakce musí určovat klíč oddílu. Tím může být vlastnost SessionId (ID relace), PartitionKey (Klíč oddílu) nebo MessageId (ID zprávy). Všechny zprávy odeslané v rámci jedné transakce musí určovat stejný klíč oddílu, protože je musí zpracovat stejný proces zprostředkovatele zpráv. V rámci jedné transakce není možné odesílat zprávy do různých front nebo témat.

• Pro dělené fronty a témata není možné nakonfigurovat automatické odstranění, jakmile se stanou nečinné.

• Dělené fronty a témata aktuálně není možné používat s rozšířeným protokolem řízení front zpráv (AMQP), pokud vytváříte multiplatformní nebo hybridní řešení.

Dělení služby Azure Cosmos DB

Azure Cosmos DB for NoSQL je databáze NoSQL pro ukládání dokumentů JSON. Dokument v databázi Azure Cosmos DB je serializovaná reprezentace objektu nebo jiné části dat ve formátu JSON. Nevynucují se žádná pevná schémata kromě toho, že každý dokument musí obsahovat jedinečné ID.

Dokumenty jsou uspořádané do kolekcí. V kolekci můžete seskupovat související dokumenty. Například v systému, který uchovává blogové příspěvky, můžete obsah každého blogového příspěvku uchovávat jako dokument v kolekci. Můžete také vytvořit kolekce pro jednotlivé typy předmětů. Případně můžete ve víceklientské aplikaci, jako je například systém, kde různí autoři řídí a spravují své vlastní blogové příspěvky, dělit blogy podle autora a vytvářet samostatné kolekce pro jednotlivé autory. Prostor úložiště přidělený kolekcím ke elastický a podle potřeby se může zmenšit nebo zvětšit.

Azure Cosmos DB podporuje automatické dělení dat na základě klíče oddílu definovaného aplikací. Logický oddíl je oddíl, který uchovává všechna data pro jednu hodnotu klíče oddílu. Všechny dokumenty, které sdílí stejnou hodnotu klíče oddílu, se umisťují do stejného logického oddílu. Azure Cosmos DB distribuuje hodnoty podle hodnoty hash klíče oddílu. Logický oddíl má maximální velikost 20 GB. Proto je výběr klíče oddílu v době návrhu důležitým rozhodnutím. Zvolte vlastnost s širokou škálou hodnot a rovnoměrnými vzory přístupu. Další informace najdete v tématu Dělení a škálování ve službě Azure Cosmos DB.

Pokud mechanismus dělení, který služba Azure Cosmos DB poskytuje, nestačí, možná budete muset data horizontálně rozdělit na úrovni aplikace. Kolekce dokumentů představují přirozený mechanismus dělení dat v rámci jedné databáze. Nejjednodušší způsob implementace horizontálního dělení je vytvořit pro každý horizontální oddíl kolekci. Kontejnery jsou logické prostředky, které můžou využívat jeden nebo více serverů. Kontejnery s pevnou velikostí mají maximální limit 20 GB a propustnost 10 000 RU/s. Neomezené kontejnery nemají maximální velikost úložiště, ale musí zadat klíč oddílu. V případě horizontálního dělení aplikace musí klientská aplikace směrovat požadavky do odpovídajícího horizontálního oddílu, obvykle prostřednictvím implementace vlastního mechanismu mapování na základě některých atributů dat, které definují klíč horizontálního dělení.

Všechny databáze se vytvářejí v kontextu účtu databáze Azure Cosmos DB. Jeden účet může obsahovat několik databází a určuje, ve kterých oblastech se databáze vytvoří. Každý účet také vynucuje vlastní řízení přístupu. Účty Služby Azure Cosmos DB můžete použít k geografickému vyhledání horizontálních oddílů (kolekcí v databázích) blízko uživatelů, kteří k nim potřebují přístup, a vynutit omezení, aby se k nim mohli připojit jenom tito uživatelé.

Při rozhodování o tom, jak rozdělit data pomocí služby Azure Cosmos DB for NoSQL, zvažte následující body:

• Prostředky dostupné pro databázi Azure Cosmos DB podléhají omezením kvóty účtu. Každá databáze může obsahovat několik kolekcí a ke každé kolekci je přidružená úroveň výkonu, která pro danou kolekci řídí omezení frekvence RU (rezervovaná propustnost). Další informace najdete v tématu Limity, kvóty a omezení předplatného a služeb Azure.

• Každý dokument musí mít atribut, pomocí kterého je možné ho identifikovat v rámci kolekce, ve které se nachází. Tento atribut se liší od klíče horizontálního dělení, který definuje, ve které kolekci je dokument uložený. Kolekce může obsahovat velký počet dokumentů. Teoreticky je jediným omezením maximální délka ID dokumentu. ID dokumentu může obsahovat až 255 znaků.

• Všechny operace s dokumentem se provádějí v kontextu transakce. Transakce jsou vymezené kolekcí, ve které se dokument nachází. Pokud operace selže, práce, kterou prováděla, se vrátí zpět. V době provádění s dokumentem se na všechny provedené změny vztahuje izolace na úrovni snímku. Tento mechanismus zaručuje, že pokud například selže požadavek na vytvoření nového dokumentu, jinému uživateli, který databázi souběžně dotazuje, se nezobrazí částečný dokument, který se následně odstraní.

• Databázové dotazy jsou také vymezené úrovní kolekce. Jeden dotaz může načítat data pouze z jedné kolekce. Pokud potřebujete načítat data z několika kolekcí, musíte dotazovat každou kolekci samostatně a sloučit výsledky v kódu aplikace.

• Azure Cosmos DB podporuje programovatelné položky, které je možné uložit v kolekci společně s dokumenty. Patří mezi ně uložené procedury, funkce definované uživatelem a triggery (napsané v JavaScriptu). Tyto položky mají přístup ke všem dokumentům v rámci stejné kolekce. Navíc se tyto položky spouští buď v rámci ambientní transakce (v případě triggeru, který se aktivuje v důsledku operace vytvoření, odstranění nebo nahrazení provedené s dokumentem), nebo prostřednictvím spuštění nové transakce (v případě uložené procedury, která se spustí v důsledku explicitního požadavku klienta). Pokud kód v programovatelné položce vyvolá výjimku, transakce se vrátí zpět. Pomocí uložených procedur a triggerů můžete udržovat integritu a konzistenci mezi dokumenty, ale všechny tyto dokumenty musí být součástí stejné kolekce.

• U kolekcí, které chcete ukládat do databází, by nemělo být pravděpodobné překročení omezení propustnosti definovaného úrovněmi výkonu těchto kolekcí. Další informace najdete v tématu o jednotkách žádostí v Azure Cosmos DB. Pokud očekáváte překročení těchto omezení, zvažte rozdělení kolekcí mezi databáze v různých účtech, abyste snížili zatížení na jednu kolekci.

Dělení služby Azure Search

Možnost vyhledávat data je často hlavní metodou procházení a zkoumání, kterou řada webových aplikací poskytuje. Pomáhá uživatelům rychle najít prostředky (například produkty v aplikaci elektronického obchodování) na základě kombinací kritérií hledání. Služba Azure Search poskytuje možnosti fulltextového vyhledávání ve webovém obsahu a zahrnuje funkce, jako je našeptávání, navrhované dotazy na základě přibližných shod a fasetová navigace. Další informace najdete v tématu Co je Azure Search?

Azure Search ukládá prohledávatelný obsah do databáze jako dokumenty JSON. Můžete definovat indexy, které určují prohledávatelná pole v těchto dokumentech, a poskytnout tyto definice službě Azure Search. Když uživatel odešle požadavek hledání, Azure Search pomocí vhodných indexů vyhledá odpovídající položky.

Za účelem omezení kolizí je možné rozdělit úložiště používané službou Azure Search na 1, 2, 3, 4, 6 nebo 12 oddílů a každý oddíl je možné až 6krát replikovat. Výsledek vynásobení počtu oddílů počtem replik se označuje jako jednotka služby Search (SU). Jedna instance služby Azure Search může obsahovat maximálně 36 SU (databáze s 12 oddíly podporuje maximálně pouze 3 repliky).

Účtují se vám všechny SU přidělené vaší službě. Pokud se zvětší objem prohledávatelného obsahu nebo se zvýší frekvence požadavků hledání, můžete ke stávající instanci služby Azure Search přidat SU pro zpracování dalšího zatížení. Dokumenty rovnoměrné distribuuje napříč oddíly samotná služba Azure Search. Žádné strategie ručního dělení se aktuálně nepodporují.

Každý oddíl může obsahovat maximálně 15 milionů dokumentů nebo zabírat 300 GB prostoru úložiště (podle toho, která hodnota je menší). Můžete vytvořit až 50 indexů. Výkon služby se liší a závisí na složitosti dokumentů, dostupných indexech a vlivu latence sítě. V průměru by jedna replika (1 SU) měla být schopná zpracovat 15 dotazů za sekundu (QPS), ale pokud chcete získat přesnější míru propustnosti, doporučujeme provést srovnávací test s vlastními daty. Další informace najdete v tématu Omezení služeb ve službě Azure Search.

Nad způsobem, jakým Azure Search dělí data pro jednotlivé instance služby, máte omezenou kontrolu. V globálním prostředí byste však měli být schopni zlepšit výkon a ještě více snížit latenci a omezit kolize rozdělením samotné služby, a to s využitím některé z následujících strategií:

• Vytvořte instanci služby Azure Search v každé geografické oblasti a zajistěte, aby klientské aplikace byly směrovány na nejbližší dostupnou instanci. Tato strategie vyžaduje včasnou replikaci všech aktualizací prohledávatelného obsahu napříč všemi instancemi služby.

• Vytvořte dvě úrovně služby Azure Search:

  • V každé oblasti vytvořte místní službu obsahující data, ke kterým uživatelé v dané oblasti nejčastěji přistupují. Uživatelé můžou směrováním požadavků do této služby získat rychlé, ale omezené výsledky.
  • Vytvořte globální službu zahrnující všechna data. Uživatelé můžou směrováním požadavků do této služby získat pomalejší, ale úplnější výsledky.

Tento přístup je nejvhodnější v případě, že existují velké rozdíly mezi vyhledávanými daty v jednotlivých oblastech.

Dělení služby Azure Cache for Redis

Azure Cache for Redis poskytuje sdílenou službu ukládání do mezipaměti v cloudu založenou na úložišti dat klíč-hodnota Redis. Jak už název napovídá, služba Azure Cache for Redis je určená jako řešení ukládání do mezipaměti. Používejte ji pouze k ukládání přechodných dat, a ne jako trvalé úložiště dat. Aplikace, které používají Azure Cache for Redis, by měly být schopné dál fungovat, pokud mezipaměť není k dispozici. Azure Cache for Redis podporuje primární nebo sekundární replikaci, která poskytuje vysokou dostupnost, ale v současné době omezuje maximální velikost mezipaměti na 53 GB. Pokud potřebujete více místa, musíte vytvořit další mezipaměti. Další informace najdete v článku, který se věnuje službě Azure Cache for Redis.

Dělení úložiště dat Redis zahrnuje rozdělení dat mezi instance služby Redis. Každá instance představuje jeden oddíl. Azure Cache for Redis abstrahuje služby Redis za fasádou a nezpřístupňuje je přímo. Nejjednodušší způsob, jak implementovat dělení, je vytvořit několik instancí Azure Cache for Redis a rozdělit data mezi ně.

Ke každé datové položce můžete přidružit identifikátor (klíč oddílu) určující, ve které mezipaměti je datová položka uložená. Logika klientské aplikace pak pomocí tohoto identifikátoru může směrovat požadavky do příslušného oddílu. Toto schéma je velmi jednoduché, ale pokud se schéma dělení změní (například pokud se vytvoří další instance Azure Cache for Redis), může být potřeba překonfigurovat klientské aplikace.

Nativní Redis (nikoli Azure Cache for Redis) podporuje dělení na straně serveru na základě clusteringu Redis. V rámci tohoto přístupu můžete data rovnoměrně rozdělit mezi servery s využitím hashovacího mechanismu. Každý server Redis ukládá metadata popisující rozsah klíčů hash, které oddíl obsahuje, a také obsahuje informace o tom, které klíče hash jsou umístěné v oddílech na jiných serverech.

Klientské aplikace jednoduše odesílají požadavky na jakýkoli ze zúčastněných serverů Redis (pravděpodobně na ten nejbližší). Server Redis prozkoumá požadavek klienta. Pokud se dá vyřešit místně, provede požadovanou operaci. V opačném případě předá požadavek na příslušný server.

Tento model je implementovaný s využitím clusteringu Redis a je podrobněji popsaný na stránce věnované kurzu ke clusteru Redis na webu Redis. Clustering Redis je pro klientské aplikace transparentní. Do clusteru je možné přidat další servery Redis (a data je možné předělovat) bez nutnosti překonfigurovat klienty.

Stránka věnovaná dělení dat mezi několik instancí Redis na webu Redis poskytuje další informace o implementaci dělení s využitím Redis. Ve zbytku této části se předpokládá, že implementujete dělení na straně klienta nebo dělení s asistencí proxy.

Při rozhodování o tom, jak rozdělit data do služby Azure Cache for Redis, zvažte následující body:

• Azure Cache for Redis není zamýšlený jako trvalé úložiště dat, takže bez ohledu na schéma dělení, které implementujete, musí být kód aplikace schopný načíst data z umístění, které není mezipamětí.

• Data, ke kterým se často přistupuje společně, by se měla uchovávat ve stejném oddílu. Redis je výkonné úložiště párů klíč-hodnota, které poskytuje několik vysoce optimalizovaných mechanismů strukturování dat. Mezi tyto mechanismy patří následující:

  • Jednoduché řetězce (binární data o délce až 512 MB)
  • Agregované typy, například seznamy (které můžou fungovat jako fronty a zásobníky)
  • Sady (seřazené a neseřazené)
  • Hodnoty hash (které můžou seskupovat související pole, například položky představující pole v objektu)

• Agregované typy umožňují přidružení mnoha souvisejících hodnot ke stejnému klíči. Klíč Redis identifikuje seznam, sadu nebo hodnotu hash, a ne datové položky, které obsahují. Všechny tyto typy jsou dostupné ve službě Azure Cache for Redis a jsou popsány stránkou Datové typy na webu Redis. Například v části systému elektronického obchodování, která sleduje objednávky zadávané zákazníky, se můžou podrobnosti o jednotlivých zákaznících ukládat do hodnoty hash Redis, pro kterou se jako klíč použije ID zákazníka. Každá hodnota hash může obsahovat kolekci ID objednávek daného zákazníka. V samostatné sadě Redis se můžou uchovávat objednávky, opět strukturované jako hodnoty hash, pro které se jako klíč použije ID objednávky. Tato struktura je znázorněna na obrázku 8. Všimněte si, že Redis neimplementuje žádnou formu referenční integrity, takže za údržbu relací mezi zákazníky a objednávkami je zodpovědný vývojář.

Obrázek 8. Navrhovaná struktura v úložišti Redis pro zaznamenávání objednávek zákazníků a jejich podrobností

• Ukládáním souvisejících informací v různých agregacích do stejné databáze můžete implementovat vertikální dělení. Například v aplikaci elektronického obchodování můžete ukládat často používané informace o produktech do jedné hodnoty hash Redis a méně často používané podrobné informace do jiné. Obě hodnoty hash můžou jako součást klíče používat stejné ID produktu. Můžete například použít "product: nn" (kde nn je ID produktu) pro informace o produktu a "product_details: nn" pro podrobná data. Tato strategie může pomoct snížit objem dat, která bude pravděpodobně načítat většina dotazů.

• Úložiště dat Redis můžete znovu rozdělit, ale mějte na paměti, že se jedná o složitou a časově náročnou úlohu. Clustering Redis může automaticky předělovat data, ale tato funkce není v Azure Cache for Redis dostupná. Proto se při návrhu schématu dělení snažte v každém oddílu ponechat dostatek volného místa pro očekávaný nárůst dat v průběhu času. Mějte ale na paměti, že Azure Cache for Redis je určen k dočasnému ukládání dat do mezipaměti a že data uložená v mezipaměti můžou mít omezenou životnost určenou jako hodnotu TTL (Time to Live). Pro relativně nestálá data může být hodnota TTL nízká, ale pro statická data může být hodnota TTL mnohem vyšší. Vyhněte se ukládání velkých objemů dlouhodobých dat v mezipaměti, pokud je pravděpodobné, že objem těchto dat mezipaměť zaplní. Můžete zadat zásady vyřazení, které způsobí, že Azure Cache for Redis odebere data, pokud je prostor na úrovni Premium.

  Poznámka:

  Když použijete Azure Cache for Redis, zadáte maximální velikost mezipaměti (od 250 MB do 53 GB) výběrem příslušné cenové úrovně. Po vytvoření služby Azure Cache for Redis ale nemůžete zvětšit (nebo zmenšit) jeho velikost.

• Dávky a transakce Redis nemůžou využívat více připojení. Proto by veškerá data, která dávka nebo transakce ovlivňuje, měla být uložená ve stejné databázi (horizontální oddíl).

  Poznámka:

  Posloupnost operací v transakci Redis není nutně atomická. Příkazy, ze kterých se transakce skládá, se před spuštěním ověří a zařadí do fronty. Pokud během této fáze dojde k chybě, celá fronta se zahodí. Po úspěšném odeslání transakce se však příkazy ve frontě spouští v sekvenci. Pokud některý příkaz selže, zastaví se pouze tento příkaz. Všechny předchozí i následující příkazy ve frontě se provedou. Další informace najdete na stránce věnované transakcím na webu Redis.

• Redis podporuje omezený počet atomických operací. Jediné operace tohoto typu, které podporují více klíčů a hodnot, jsou operace MGET a MSET. Operace MGET vrací kolekci hodnot pro zadaný seznam klíčů a operace MSET ukládají kolekci hodnot pro zadaný seznam klíčů. Pokud potřebujete použít tyto operace, páry klíč-hodnota, na které příkazy MSET a MGET odkazují, musí být uložené ve stejné databázi.

Dělení Azure Service Fabric

Azure Service Fabric je platforma mikroslužeb, která poskytuje modul runtime pro distribuované aplikace v cloudu. Service Fabric podporuje spustitelné soubory hosta .NET, stavové a bezstavové služby a kontejnery. Stavové služby poskytují spolehlivou kolekci pro trvalé ukládání dat v kolekci párů klíč-hodnota v rámci clusteru Service Fabric. Další informace o strategiích pro dělení klíčů ve spolehlivé kolekci najdete v tématu Pokyny a doporučení pro spolehlivé kolekce v Azure Service Fabric.

Další kroky

• Přehled Azure Service Fabric představuje úvod do Azure Service Fabric.

• Dělení spolehlivých služeb Service Fabric poskytuje další informace o spolehlivých službách v Azure Service Fabric.

Dělení služby Azure Event Hubs

Služba Azure Event Hubs je navržená pro streamování dat ve velkém měřítku a obsahuje integrované dělení, které umožňuje horizontální škálování. Každý příjemce čte pouze konkrétní oddíl datového proudu zpráv.

Zdroj události zná jenom svůj klíč oddílu, a ne oddíl, do kterého se události publikují. Díky tomuto oddělení klíče a oddílu odesílatel toho nepotřebuje vědět o zpracování příjmu dat příliš mnoho. (Také je možné odesílat události přímo do daného oddílu, ale obecně se to nedoporučuje.)

Při výběru počtu oddílů vezměte v úvahu dlouhodobé škálování. Po vytvoření centra událostí už počet oddílů nejde změnit.

Další kroky

Další informace o používání oddílů ve službě Event Hubs najdete v tématu Co je Event Hubs?.

Důležité informace o kompromisech mezi dostupností a konzistencí najdete v tématu Dostupnost a konzistence ve službě Event Hubs.