Přechod na novou major verzi s sebou vždy nese mnoho zajímavých novinek a často také některé nekompatibility. Před upgradem je tedy nutné zálohovat a po upgradu spustit utilitu mysql_upgrade. Více o upgradu doporučuji prostudovat na stránkách upstreamu.

MySQL 5.6

Předchozí článek vysvětlil, kde se berou nápady pro nové verze relačních databází, a nyní se již můžeme konkrétně podívat na vybrané novinky. Nejprve v databázi MySQL 5.6, kterou najdeme ve Fedoře 21 v balíku community-mysql (CLI klient) a community-mysql-server. Ta sice není sice výchozí a doporučovanou implementací, ale v podstatě slouží jako předloha pro MariaDB, která z ní stále bere většinu commitů, takže následující výčet víceméně platí i pro ni.

Tahákem každé nové verze vesměs všech databází je zlepšení rychlosti a škálovatelnosti. K tomu přispívá mj. Index Condition Pushdown, což dovolí podmínku WHERE přenést do samotného enginu, zatímco dříve engine vrátil vše a podmínku WHERE zpracovával server obecně, nezávisle na enginu. Jisté zvýšení efektivity a tím pádem rychlosti je zřejmé.

Dále, Multi-range read, dokáže číst větší bloky při práci s indexy a tím je efektivnější na klasických HDD, které, jak známo, mají vyšší rychlost při čtení a zápisu větších souvislých bloků. File soft optimization zrychluje dotazy, které se vejdou do soft bufferu a obsahují dvojici ORDER BY + LIMIT.

Nově můžeme také definovat velikost vzorku pro statistiky indexů, které se výrazně podílejí na ovlivňování plánu executeru. Explicitní partitioning nám dovoluje pracovat s explicitními oddíly; například můžeme načíst existující tabulky do jednotlivých oddílů, exportovat je obdobným způsobem apod.

Crash-safe slaves dovolují automatické zotavení slave serveru při pádu, což je cílem každého správce databáze v cloudu. Tomu také přispívá novinka globální transakční ID, zkráceně GTID, které lze využít při replikaci založené na transakčním logu. GTID výrazně zjednodušuje tento typ replikace, neboť se nemusíme nadále starat o jméno nebo pozici v transakčním logu.

Trochu překvapivá novinka je memcached server, který v nové verzi MySQL najdeme -- zaslouží si náležité vysvětlení. Nejedná se, jak by se mohlo zprvu zdát, o funkci pro přístup k memcached databázi pomocí SQL, ale přesně naopak. Pomocí dalšího démona, který běží na vlastním portu jako proxy v rámci MySQL, lze pomocí memcached klienta přistupovat k datům enginu InnoDB. Takový přístup, který obchází planner, SQL parser a kdoví co ještě, je tím pádem rychlý a v dnešním agilním světě může ponoření se na nižší úroveň najít své opodstatnění.

Novinky v MariaDB 10.0

Databázi MariaDB ve Fedoře 21 i nadále najdeme jako výchozí implementaci MySQL. Je k dispozici jak v nativní verzi mariadb (klient) a mariadb-server, tak s patchem Galera (vizte předešlý článek) v balíku mariadb-galera-server. Zajímavostí je, že zbytek podpůrných podbalíků obě tyto varianty sdílí, tedy nehledejte klientské balíky jménem mariadb-galera, mariadb-galera-libs a podobně, jednoduše místo nich využijte výchozí balíky MariaDB.

Verze 10.0, jak už je známo, symbolizuje odklonění od 100% kompatibility s MySQL 5.6, ze které ovšem i nadále ve většině ohledů vychází. Kromě novinek představených již v 5.6 obsahuje i několik vlastních. Zajímavý přehled podporovaných funkcí je k dispozici na stránkách upstreamu.

Jednou z prvních vlaštovek nekompatibilních změn je implementace GTID, tedy globální transakční ID, o kterém již byla řeč výše. Podporu najdeme i v MariaDB 10.0, ale v MariaDB server specifikuje dvojice integerů domain ID a server ID, zatímco MySQL pro označení serveru používá UUID.

Dalším viditelným rozdílem může být chybějící rozhraní memcached.

V MariaDB 10.0 oproti MySQL najdeme navíc například sadu nových enginů -- Spider engine nabízí možnost škálovat server pomocí tzn. shardingu, tedy rozdělení dat na více uzlů, kdy každý uzel obsluhuje svoji část dat.

Cassandra engine dovoluje připojit se jako klient k běžícímu clusteru databáze Cassandra a s daty pracovat pomocí SQL. Connect engine udělá z MariaDB centrální bod přístupu k široké škále dat od souborů přes dokumenty až k libovolným databázím, ke kterým existuje ODBC konektivita.

Flexible parallel slave umožňuje MariaDB paralelně replikovat i jednu databázi na slave serveru, zatímco v MySQL můžeme paralelně replikovat jen různé databáze. Na výběr jsou módy in-order a out-of-order a záleží na aplikaci, který z módů si dovolí použít.

Zajímavou novinkou v oblasti replikace je i multi-source replikace, tedy možnost replikovat z více master serverů najednou. Engine independent statistics pomohou zvýšit efektivitu sestavením správného exekučního plánu pro každý engine zvlášť.

Dynamické sloupce umožní ukládat více hodnot do jednoho sloupce a verze 10.0 v tomto ohledu přináší jistá zlepšení.

V neposlední řadě v MariaDB najdeme i vlastnosti, které sice jsou k dispozici i v MySQL, ale jen v placené Enterprise verzi. Jedná se například o PAM modul pro autentizaci nebo o audit plugin, který umožňuje sledovat, který uživatel přistupuje ke kterým datům.

MariaDB také navíc nabízí model rolí, kdy administrátor může přiřadit rolím různá oprávnění a uživatele potom přiřazovat do těchto rolí. Taky nechápete, jak jste dodnes mohli přežít bez rolí v MySQL nebo MariaDB?

Jak je vidět, MariaDB tak trochu zrychluje tempo a má náběh stát se mainstreamem v MySQL-kompatibilním světě SQL. Velmi mě těší, že ve Fedoře volba z dalších alternativ před dvěma lety padla právě na MariaDB.

A jelikož se nám láme rok, rád bych MariaDB popřál i v dalším roce mnoho úspěšných commitů, zapálených přispěvatelů a zejména spokojených uživatelů.