Pojďme se trochu zeširoka podívat, kde vlastně berou autoři relačních databází motivy a inspiraci pro nové funkce.

Cloud technologie, platformy nebo software jako služby (PaaS, SaaS) i kontejnerové technologie jako Docker s sebou přinášejí změnu pohledu na webové aplikace a zejména jejich vývoj. Na jedné straně je nutné reagovat na výrazně kolísavý počet uživatelů a zajistit rozumnou odezvu i nepřetržitou dostupnost (HA), na druhou stranu životnost jedné instance průměrně klesá, stejně jako doba vývoje samotné aplikace (agilní vývoj je dnes prakticky standard). A překvapením asi není, že změnu přístupu k vývoji aplikací potom musí odrážet i databáze coby prvek, který udržuje persistentní stav aplikace.

Vzhledem k výše zmíněným požadavkům je zřejmé, že programátoři často sahají po nových NoSQL databázích (např. MongoDB, CouchDB, Cassandra), které byly s ohledem na tyto požadavky vytvářeny od píky, a tím pádem mohly daleko rychleji implementovat nové požadavky. Často ukládají JSON nebo obecně cokoliv ve formátu klíč-hodnota, často nabízejí technologie jako sharding (škálování), vysokou dostupnost (HA) i automatickou replikaci již v samotném základu. To se aplikačním vývojářům jistě hodí do krámu.

Naproti tomu zaběhnuté technologie postavené na SQL mají výhodu v mnohaletém a tím pádem stabilním relačním konceptu. Pokud do něho doplníme funkce inspirované světem NoSQL, které uživatelé žádají, mohou stále držet krok s novými systémy. Ty totiž na druhou stranu mívají dětské nemoci, problémy se stabilitou a celkově nejsou zdaleka tak vymazlené. Další nevýhodou NoSQL může být obtížné zapojení do stávajícího ekosystému -- nový typ aplikace, kterou je potřeba zálohovat -- to vše může hrát roli při výběru vhodné databáze.

V následujícím článku, který se bude týkat již konkrétních funkcí v nových verzích MySQL a MariaDB, uvidíte, že mnoho z nich má původ právě ve světě NoSQL a tento trend můžeme očekávat i nadále. Pokud tedy chceme nahlédnout do věštecké koule a zeptat se na budoucnost SQL databází, můžeme se podívat na novější NoSQL alternativy a proč je uživatelé chtějí měnit za relační staříky.

Jak se má MariaDB k MySQL?

Pojďme si nyní udělat pořádek v pojmech, protože s posledními verzemi Fedory se nám to začíná zamotávat. Nejspíše můžeme bezpečně pominout představení projektu MySQL, který je notoricky známý snad všem programátorům. Po akvizici tohoto projektu firmou Sun, jež byla vzápětí koupena firmou Oracle, založila skupina původních autorů projekt MariaDB s cílem udržet tento fork nadále čistým open-source projektem.

Obavy z uzavírání MySQL se zatím plně nenaplnily, ale prakticky se již jedná pouze o open-source produkt, kde komunita mizí stejně rychle jako otevřenost upstreamu a jeho ochota spolupracovat. I přesto, že i za MariaDB je z business pohledu prakticky jedna společnost, jež projekt posouvá dále (SkySQL, nedávno přejmenovaná jednoduše na MariaDB), komunita se rozvíjí a podle všeho zatím projekt čeká světlá budoucnost. A to zejména od chvíle, kdy na MariaDB přešlo mnoho distribucí, včetně Fedory, a paradoxně i samotný Enterprise Linux od Oraclu, který má v základu MariaDB, a ne vlastní MySQL.

Celkem důležité je i to, jakým způsobem jsou varianty MySQL a MariaDB kompatibilní, neboť serverová část MariaDB v nových verzích již není 100% zaměnitelná s MySQL. Ještě ve verzi 5.5 se jednalo o drop-in replacement, tedy nebyl problém vyměnit MySQL za MariaDB a vše fungovalo bez jediného rozdílu. Tento krok, tedy odpojení od původního kódu MySQL, autoři MariaDB demonstrují verzí, která místo 5.6 dostala označení 10.0, a i release cyklus není tak pevně svázaný s release cyklem MySQL.

Dobrá zpráva však je, že klient i protokol kompatibilní zůstávají, takže je můžeme relativně bezpečně zaměňovat. Popravdě, ve většině případů to bude nadále platit i u serverové části, kde máme docela velkou šanci, že si nekompatibilit v reálu ani nevšimneme.

Co že je to vlastně ta Galera?

A nakonec se pojďme podívat na nejméně známý projekt -- Galera. Jedná se o projekt společnosti Codership, která do základu nativního MySQL implementovala master-master replikaci, tedy možnost zapisovat na libovolný replikovaný server. Pro úplnost doplním, že replikace v nativním MySQL funguje jako master-slave, kde zapisovat smíme jen na master a ze slave pouze čteme.

Ale zpět k projektu Galera -- patch pro MySQL i MariaDB, spolu s potřebným pluginem wsrep, vydává firma Codership jako samostatný open-source projekt. Ten aplikuje nyní i sám upstream MariaDB, takže uživatelé mají k dispozici i otestovanou variantu MariaDB-Galera. Tu je zatím nutné kompilovat i stahovat odděleně a ve Fedoře 21 je ve verzi 10.0 zabalená v balíku mariadb-galera-server.

Je důležité zmínit, že se master-master replikace je synchronní. To znamená, že při zápisu na jeden server klient nedostane potvrzení dříve, než se aplikuje na všech serverech. V mnoha případech tedy může být master-slave stále výhodnější řešení. Ale je dobré mít na výběr, ne?

Jak na to prakticky? Pro instalaci MariaDB Galera na Fedora 21 je tedy potřeba nejdříve odinstalovat balík mariadb-server a potom nainstalovat mariadb-galera-server. K tomu budete potřebovat zmíněný plugin, dostupný ve Fedoře v balíku galera. Pro konfiguraci doporučuji prostudovat upstreamovou dokumentaci.

V dalším článku se podíváme na to, co je v MySQL a MariaDB nového ve Fedoře 21.