Tento článek se poprvé objevil v InfoWorld . Se svolením je přetištěno. © IDG Communications, Inc., 2020. Všechna práva vyhrazena Jak MariaDB dosahuje globálního měřítka s Xpand. Xpand je nyní k dispozici v MariaDB SkySQL přidáním distribuovaného SQL pro škálovatelnost a elasticitu v cloudu.
S rostoucími potřebami informací a zpracování si problémy, jako je výkon a odolnost, vyžádaly nová řešení. Databáze musí udržovat shodu a konzistenci ACID, poskytovat vysokou dostupnost a vysoký výkon a zvládat masivní pracovní zátěž, aniž by se staly vyčerpávajícími prostředky. Sharding nabídl řešení, ale pro mnoho společností sharding dosáhl svých limitů kvůli své složitosti a nárokům na zdroje. Lepším řešením je distribuované SQL.
V distribuované implementaci SQL je databáze distribuována na více fyzických systémech a poskytuje transakce na globálně škálovatelné úrovni. MariaDB Platform X5, hlavní vydání, které zahrnuje upgrady všech aspektů platformy MariaDB, poskytuje distribuovaný SQL a masivní škálovatelnost díky přidání nového inteligentního úložiště s názvem Xpand. Díky architektuře sdíleného nic, plně distribuovaným transakcím ACID a silné konzistenci vám Xpand umožňuje škálovat na miliony transakcí za sekundu.
Optimalizované zásuvné chytré motory
MariaDB Enterprise Server je navržen tak, aby používal zásuvné moduly úložiště (jako Xpand) k optimalizaci pro konkrétní pracovní zátěže z jediné platformy. Není potřeba specializovaných databází pro zpracování konkrétních úloh. MariaDB Xpand, náš inteligentní engine pro distribuované SQL, je nejnovějším přírůstkem do naší řady. Xpand přidává masivně škálovatelné distribuované transakční schopnosti k možnostem poskytovaným našimi dalšími motory. Naše další zásuvné motory poskytují optimalizaci pro analytické (sloupcové), zátěže náročné na čtení a velké zátěže pro zápis. Můžete kombinovat replikované, distribuované a sloupcové tabulky a optimalizovat tak každou databázi pro vaše specifické požadavky.
Přidání MariaDB Xpand umožňuje podnikovým zákazníkům získat všechny výhody distribuovaného SQL – rychlost, dostupnost a škálovatelnost – při zachování výhod MariaDB, na které jsou zvyklí.
Pojďme se na vysoké úrovni podívat na to, jak MariaDB Xpand poskytuje distribuované SQL.
Distribuované SQL až do indexů
Xpand poskytuje distribuované SQL rozdělením, replikací a distribucí dat mezi uzly. Co to znamená? K demonstraci konceptů použijeme velmi jednoduchý příklad s jednou tabulkou a třemi uzly. V tomto příkladu není ukázáno, že všechny řezy jsou replikovány.
Na obrázku 1 výše máme tabulku se dvěma indexy. Tabulka má některá data a máme index na sloupci dva a další na sloupcích tři a jedna. Indexy jsou v jistém smyslu samotné tabulky. Jsou to podmnožiny tabulky. Primární klíč je id , první index v tabulce. To je to, co bude použito k hašování a šíření dat tabulky v databázi.
Nyní přidáme pojem řezy . Řezy jsou v podstatě horizontální přepážky stolu. V naší tabulce máme pět řádků. Na obrázku 2 je tabulka rozdělena a rozdělena. Uzel #1 má dva řádky. Uzel #2 má dva řádky a uzel #3 má jeden řádek. Cílem je mít data co nejrovnoměrněji distribuována mezi uzly.
indexy byly také nakrájeny a distribuovány. Toto je klíčový rozdíl mezi Xpand a jinými distribuovanými řešeními. Distribuované databáze mají obvykle lokální indexy, takže každý uzel má index svých vlastních dat. V Xpand jsou indexy distribuovány a ukládány nezávisle na tabulce. Tím odpadá nutnost posílat dotaz všem uzlům (scatter/gather). Ve výše uvedeném příkladu obsahuje uzel #1 řádky 2 a 4 tabulky a také obsahuje indexy pro řádky 32 a 35 a řádky duben a březen. Tabulka a indexy jsou nezávisle rozděleny, distribuovány a replikovány mezi uzly.
Dotazovací stroj používá distribuované indexy k určení, kde najít data. Vyhledá pouze potřebné indexové oddíly a poté odešle dotazy pouze do míst, kde se nacházejí potřebná data. Všechny dotazy jsou distribuovány. Dělají se souběžně a paralelně. Kam jdou, zcela závisí na datech a na tom, co je potřeba k vyřešení dotazu.
Všechny řezy se replikují alespoň dvakrát. Pro každý řez existují repliky umístěné na jiných uzlech. Ve výchozím nastavení budou k dispozici tři kopie těchto dat – řez a dvě repliky. Každá kopie bude na jiném uzlu, a pokud byste běželi ve více zónách dostupnosti, tyto kopie by se také nacházely v různých zónách dostupnosti.
Ovládání čtení a zápisu
Vezměme si další příklad. Na obrázku 3 máme pět instancí MariaDB Enterprise Server s Xpand (uzly). Je zde tabulka pro uložení profilů zákazníků. Řez s Shaneovým profilem je na uzlu #1 s kopiemi na uzlu #3 a uzlu #5. Dotazy mohou přicházet na jakýkoli uzel a budou zpracovány odlišně v závislosti na tom, zda se jedná o čtení nebo zápis.
Zápisy se provádějí do všech kopií synchronně v rámci distribuované transakce. Kdykoli aktualizuji svůj profil „Shane“, protože jsem změnil svůj e-mail nebo jsem změnil svou adresu, tyto zápisy půjdou do všech kopií ve stejnou dobu v rámci transakce. To zajišťuje silnou konzistenci.
Na obrázku 3 se příkaz UPDATE přesunul do uzlu #2. Na uzlu č. 2 není nic, co by se týkalo mého profilu, ale uzel č. 2 ví, kde se můj profil nachází, a odesílá aktualizace do uzlu #1, uzlu #3 a uzlu #5, poté provede transakci a vrátí se zpět do aplikace.
Čtení se řeší jinak. V diagramu je řez s mým profilem na uzlu #1 s kopiemi na uzlu #3 a uzlu #5. To dělá z Node #1 hodnocenou repliku. Každý řez má hodnotící repliku, o které by se dalo říci, že je to uzel, který „vlastní“ data. Ve výchozím nastavení, bez ohledu na to, na kterém uzlu se čtení objeví, vždy přejde do hodnotící repliky, takže každý SELECT, který se mi vyhodnotí, půjde do uzlu #1.
Zajištění pružnosti
Distribuované databáze jako Xpand se neustále mění a vyvíjejí v závislosti na datech v aplikaci. Proces rebalancer je zodpovědný za přizpůsobení distribuce dat aktuálním potřebám a udržování optimální distribuce řezů mezi uzly. Existují tři obecné scénáře, které vyžadují redistribuci:přidávání uzlů, odstraňování uzlů a předcházení nerovnoměrnému pracovnímu zatížení nebo „horkým místům“.
Řekněme například, že běžíme se třemi uzly, ale zjistíme, že provoz roste a potřebujeme škálovat – přidáme čtvrtý uzel, který provoz zvládne. Uzel #4 je prázdný, když jej přidáme, jak je znázorněno na obrázku 4. Rebalancer automaticky přesune řezy a repliky, aby využil uzel #4, jak je znázorněno na obrázku 5.
Pokud uzel #4 selže, rebalancer automaticky znovu začne fungovat; tentokrát znovu vytvořit plátky z jejich replik. Žádná data se neztratí. Repliky jsou také znovu vytvořeny, aby nahradily ty, které byly umístěny v uzlu #4, takže všechny řezy mají opět repliky na jiných uzlech, aby byla zajištěna vysoká dostupnost.
Obrázek 6. Pokud uzel selže, Xpand rebalancer znovu vytvoří řezy a repliky, které se nacházely na neúspěšném uzlu, z dat replik na ostatních uzlech.
Vyvážení pracovní zátěže
Kromě škálování a vysoké dostupnosti rebalancer zmírňuje nerovnoměrné rozložení pracovní zátěže – buď horká místa, nebo nedostatečné využití. I když jsou data náhodně distribuována pomocí dokonalého hashovacího algoritmu, mohou se vyskytnout horká místa. Mohlo by se například stát náhodou, že 10 produktů v prodeji tento měsíc se nachází v uzlu #1. Data jsou rovnoměrně rozložena, ale pracovní zátěž nikoli (obrázek 7). V tomto typu scénáře rebalancer přerozdělí řezy, aby vyvážil využití zdrojů (obrázek 8).
Obrázek 7. Xpand rozložil data rovnoměrně, ale zátěž je nerovnoměrná. Uzel 1 má výrazně vyšší zátěž než ostatní tři uzly.
Obrázek 8. Xpand rebalancer přerozděluje datové segmenty, aby vyrovnal pracovní zátěž mezi uzly.
Škálovatelnost, rychlost, dostupnost, vyváženost
Potřeby informací a zpracování budou nadále růst. To je dané. MariaDB Xpand poskytuje konzistentní škálovací řešení vyhovující ACID pro podniky s požadavky, které nelze splnit jinými alternativami, jako je replikace a sharding.
Distribuované SQL poskytuje škálovatelnost a MariaDB Xpand poskytuje flexibilitu, abyste si vybrali, jakou škálovatelnost potřebujete. Distribuujte jednu tabulku nebo více tabulek nebo dokonce celou databázi, volba je na vás. Provozně lze kapacitu snadno upravit tak, aby vyhovovala měnícím se požadavkům na pracovní zatížení v kteroukoli danou chvíli. Nikdy nemusíte mít nadměrnou rezervu.
Xpand také transparentně chrání před nerovnoměrným využíváním zdrojů, dynamicky redistribuuje data, aby vyrovnal pracovní zátěž mezi uzly a zabránil horkým místům. Vývojáři se nemusí starat o škálovatelnost a výkon. Xpand je elastický. Xpand také poskytuje redundanci a vysokou dostupnost. S daty rozdělenými, replikovanými a distribuovanými mezi uzly jsou data chráněna a je zachována redundance v případě selhání hardwaru.
A s architekturou MariaDB budou vaše distribuované stoly hrát pěkně – včetně cross-engine JOINů – s vašimi ostatními stoly MariaDB. Vytvořte databázové řešení, které potřebujete, smícháním a spárováním replikovaných, distribuovaných nebo sloupcových tabulek, vše v jediné databázi na platformě MariaDB.