Strategie dělení dat (vytváření Real-World Cloud Apps v Azure)

Rick Anderson, Tom Dykstra

Stáhnout projekt Fix It nebo Stáhnout elektronickou knihu

Elektronická kniha Building Real World Cloud Apps with Azure je založená na prezentaci vyvinuté Scottem Guthriem. Vysvětluje 13 vzorů a postupů, které vám můžou pomoct s úspěšným vývojem webových aplikací pro cloud. Informace o této řadě najdete v první kapitole.

Dříve jsme viděli, jak snadné je škálovat webovou vrstvu cloudové aplikace přidáním a odebráním webových serverů. Pokud ale všechny zasahují do stejného úložiště dat, kritický bod vaší aplikace se přesune z front-endu na back-end a škálování datové vrstvy je nejhůře. V této kapitole se podíváme na to, jak můžete zajistit škálovatelnost datové vrstvy rozdělením dat do více relačních databází nebo kombinováním úložiště relačních databází s dalšími možnostmi úložiště dat.

Nastavení schématu dělení je nejlepší provést předem ze stejného důvodu, o kterém jsme se zmínili dříve: je velmi obtížné změnit strategii úložiště dat, jakmile je aplikace v produkčním prostředí. Pokud se předem zamyslíte nad různými přístupy, můžete se vyhnout "twitterové chvíli", kdy se aplikace zhroutí nebo se na dlouhou dobu zhroutí, zatímco přeuspořádáte data a přístupový kód aplikace.

Tři Vs úložiště dat

Pokud chcete zjistit, jestli potřebujete strategii dělení a jaká by měla být, zvažte tři otázky týkající se vašich dat:

• Objem – kolik dat nakonec uložíte? Pár gigabajtů? Pár set gigabajtů? Terabajty? Petabajty?
• Rychlost – jaká je rychlost, s jakou budou vaše data růst? Jedná se o interní aplikaci, která negeneruje velké množství dat? Externí aplikace, do které budou zákazníci nahrávat obrázky a videa?
• Variety – jaký typ dat budete ukládat? Relační, obrázky, páry klíč-hodnota, sociální grafy?

Pokud si myslíte, že budete mít velký objem, rychlost nebo rozmanitost, musíte pečlivě zvážit, jaký druh schématu dělení nejlépe umožní vaší aplikaci efektivně a efektivně škálovat, jak roste, a zajistit, že nenarazíte na žádné kritické body.

Existují v podstatě tři přístupy k dělení:

• Vertikální dělení
• Horizontální dělení
• Hybridní dělení

Vertikální dělení

Svislé dělení je podobné rozdělení tabulky podle sloupců: jedna sada sloupců jde do jednoho úložiště dat a druhá do jiného úložiště dat.

Předpokládejme například, že moje aplikace ukládá data o lidech, včetně obrázků:

Když tato data představujete jako tabulku a podíváte se na různé druhy dat, uvidíte, že tři sloupce vlevo obsahují řetězcová data, která mohou být efektivně uložena relační databází, zatímco dva sloupce vpravo jsou v podstatě bajtová pole, která pocházejí ze souborů obrázků. Data souboru obrázku je možné uložit do relační databáze a spousta lidí to dělá, protože je nechtějí uložit do systému souborů. Nemusí mít systém souborů, který by mohl ukládat požadované objemy dat, nebo nemusí chtít spravovat samostatný systém zálohování a obnovení. Tento přístup funguje dobře pro místní databáze a pro malé objemy dat v cloudových databázích. V místním prostředí může být jednodušší nechat správce databáze, aby se o všechno postaral.

V cloudové databázi je ale úložiště poměrně drahé a velký objem imagí by mohl zvětšovat velikost databáze nad rámec limitů, při kterých může efektivně fungovat. Tyto problémy můžete vyřešit vertikálním dělením dat, což znamená, že pro každý sloupec v tabulce dat zvolíte nejvhodnější úložiště dat. V tomto příkladu může nejlépe fungovat umístění řetězcových dat do relační databáze a obrázků do úložiště objektů blob.

Ukládání obrázků do úložiště objektů blob místo databáze je praktičtější v cloudu než v místním prostředí, protože se nemusíte starat o nastavení souborových serverů nebo správu zálohování a obnovení dat uložených mimo relační databázi. To vše za vás automaticky zpracovává služba Blob Storage.

Toto je přístup k dělení, který jsme implementovali v aplikaci Fix It, a na jeho kód se podíváme v kapitole Úložiště objektů blob. Bez tohoto schématu dělení a za předpokladu průměrné velikosti obrázku 3 megabajty by aplikace Fix It mohla před dosažením maximální velikosti databáze 150 gigabajtů uložit pouze asi 40 000 úloh. Po odebrání obrázků může databáze uložit 10krát tolik úkolů; můžete pokračovat mnohem déle, než budete muset přemýšlet o implementaci horizontálního dělení schématu. A s tím, jak se aplikace škáluje, rostou vaše výdaje pomaleji, protože většina vašich potřeb na úložiště jde do velmi levného úložiště Objektů blob.

Horizontální dělení (sharding)

Vodorovné dělení je jako rozdělení tabulky podle řádků: jedna sada řádků jde do jednoho úložiště dat a druhá do jiného úložiště dat.

S ohledem na stejnou sadu dat by další možností bylo uložit různé rozsahy jmen zákazníků v různých databázích.

Chcete být velmi opatrní, pokud jde o schéma horizontálního dělení, abyste měli jistotu, že jsou data rovnoměrně distribuovaná, abyste se vyhnuli horkým bodům. Tento jednoduchý příklad použití prvního písmena příjmení nesplňuje tento požadavek, protože spousta lidí má příjmení, která začínají určitými běžnými písmeny. Na omezení velikosti tabulky jste narazili dříve, než byste očekávali, protože některé databáze budou velmi velké, zatímco většina z nich zůstane malá.

Nevýhodou horizontálního dělení je, že může být obtížné provádět dotazy napříč všemi daty. V tomto příkladu by dotaz musel načíst až z 26 různých databází, aby získal všechna data uložená aplikací.

Hybridní dělení

Můžete kombinovat vertikální a vodorovné dělení. Například v ukázkových datech můžete uložit obrázky do úložiště objektů blob a horizontálně rozdělit řetězcová data.

Dělení produkční aplikace

Koncepčně je snadné zjistit, jak by fungovalo schéma dělení, ale jakékoli schéma dělení zvyšuje složitost kódu a přináší mnoho nových komplikací, se kterými se musíte vypořádat. Pokud přesouváte obrázky do úložiště objektů blob, co děláte, když je služba úložiště mimo provoz? Jak nakládáte se zabezpečením objektů blob? Co se stane, když se databáze a úložiště objektů blob nesynchronizují? Pokud provádíte horizontální dělení, jak budete zpracovávat dotazy napříč všemi databázemi?

Komplikace jsou zvládnutelné, pokud je plánujete, než přejdete do produkčního prostředí. Mnoho lidí, kteří to neudělali, si přáli později. V průměru náš tým cat (Customer Advisory Team) dostává vyděšené telefonní hovory asi jednou za měsíc od zákazníků, jejichž aplikace se rozjížděly opravdu velkým způsobem, a oni toto plánování neudělali. A řeknou něco jako: "Pomoc! Dal jsem všechno do jediného úložiště dat a za 45 dní na něm dojde místo!" A pokud máte spoustu obchodní logiky, která je integrovaná v tom, jak přistupujete k úložišti dat, a máte zákazníky, kteří používají vaši aplikaci, není čas na to, abyste během migrace na den přestali. Nakonec procházíme herkulovským úsilím, abychom zákazníkovi pomohli rozdělit data za chodu bez výpadku. Je to velmi vzrušující a velmi děsivé, a ne něco, do čeho se chcete zapojit, pokud se tomu můžete vyhnout! Když o tom budete přemýšlet předem a integrovat ho do aplikace, usnadní vám to život, pokud se aplikace později rozroste.

Souhrn

Efektivní schéma dělení může vaší cloudové aplikaci umožnit škálování na petabajty dat v cloudu bez kritických bodů. A nemusíte platit předem za rozsáhlé počítače nebo rozsáhlou infrastrukturu, jako kdybyste aplikaci spouštěli v místním datacentru. V cloudu můžete postupně přidávat kapacitu podle potřeby a platíte jenom za tolik, kolik používáte.

V další kapitole se podíváme, jak aplikace Fix It implementuje vertikální dělení ukládáním obrázků do úložiště objektů blob.

Zdroje informací

Další informace o strategiích dělení najdete v následujících zdrojích informací.

Dokumentace:

• Osvědčené postupy pro návrh služeb Large-Scale ve Windows Azure Cloud Services. Bílá kniha Marka Simmse a Michaela Thomassyho.
• Vzory a postupy Microsoftu – Vzory návrhu cloudu. Viz Pokyny k dělení dat, Model horizontálního dělení.

Videa:

• FailSafe: Vytváření škálovatelných a odolných Cloud Services. Devítidílné série od Ulricha Homanna, Marca Mercuriho a Marka Simmse. Prezentuje základní koncepty a principy architektury velmi přístupným a zajímavým způsobem, přičemž příběhy jsou čerpány ze zkušeností týmu CAT (Microsoft Customer Advisory Team) se skutečnými zákazníky. Podívejte se na diskuzi o dělení v epizodě 7.
• Building Big: Poznatky získané od zákazníků s Windows Azure – část I. Mark Simms popisuje schémata dělení, strategie horizontálního dělení, postup implementace horizontálního dělení a SQL Database federace od 19:49. Podobá se řadě Failsafe, ale obsahuje další podrobnosti o postupu.

Ukázkový kód:

• Základy cloudových služeb ve Windows Azure. Ukázková aplikace, která obsahuje horizontálně dělenou databázi. Popis implementovaného schématu horizontálního dělení najdete v tématu DAL – Sharding of RDBMS na blogu Windows Azure.

PředchozíDalší