V dobách, kdy někdo říkal MySQL, existovalo pouze MySQL. Mohli jste si vybrat různé verze (4.0, 4.1), ale prodejce byl stejný. To se změnilo kolem MySQL 5.0/5.1, kdy se Percona rozhodla vydat vlastní variantu MySQL - Percona Server. O něco později se MariaDB spojila s MariaDB 5.1 a zábava (nebo zmatek) vzrostla. Jakou verzi bych měl použít? Jaký je rozdíl mezi MySQL 5.1, Percona Server 5.1 a MariaDB 5.1? Který je rychlejší? Který je stabilnější? Který z nich má lepší funkčnost? Postupem času se to zhoršovalo, protože bylo zaváděno více a více změn v každé z příchutí. Tento blogový příspěvek bude naším pokusem shrnout klíčové vlastnosti, které je odlišují. Pokusíme se vám také poskytnout několik návrhů, která příchuť může být pro daný typ projektu nejlepší. Začněme.
Oracle MySQL
Dříve to bylo MySQL, nyní je to upstream. Většina vývoje začíná zde, každá verze počínaje 5.6 řeší některé vnitřní spory a přináší lepší výkon. Nové funkce jsou také přidávány pravidelně. MySQL 5.6 nám přineslo (mimo jiné) GTID a počáteční implementaci paralelní replikace. Také nám to umožnilo provádět většinu změn ALTER online. Pojďme se podívat na funkce nejnovější verze MySQL – MySQL 5.7
Funkce MySQL 5.7
Jednou z hlavních změn jsou změny v procesu nasazení – místo různých skriptů stačí spustit mysqld --initialize a nastavit MySQL od nuly. Další velmi důležitá změna - paralelní replikace založená na logických hodinách. Konečně můžeme použít paralelní replikaci ve všech případech - bez ohledu na to, zda používáte více schémat nebo ne. Dalším vylepšením replikace je replikace z více zdrojů – 5.7 slave může mít více masterů – je to skvělá funkce, pokud chcete vytvořit agregační slave a, řekněme, kombinovat data z více samostatných clusterů.
InnoDB začalo podporovat prostorové typy, velikost bufferu InnoDB lze konečně změnit za běhu, online ALTER byly vylepšeny, aby podporovaly více případů, jako je dělení a neoperativní ALTER.
MySQL začalo nativně podporovat datové typy JSON spolu s několika novými funkcemi, které jsou zaměřeny na přidávání funkcí kolem JSON. Bezpečnost vašich dat je v dnešní době velmi důležitá, MySQL 5.7 podporuje šifrování dat v klidu pro tabulkové prostory typu soubor na tabulku. Některá vylepšení byla také přidána k podpoře SSL (SSL bude nakonfigurováno, pokud jsou na místě klíče, je zahrnut skript, který lze použít k vytváření certifikátů). Z pohledu správy uživatelů bylo přidáno nastavení doby trvání hesla, které by mělo usnadnit návrh zásad vypršení platnosti hesla.
Další funkcí, která má pomoci správcům databází, je schéma „sys“, což je sada pohledů navržených tak, aby usnadnily používání schématu výkonu. Ve výchozím nastavení je součástí MySQL 5.7.
Nakonec byla do MySQL 5.7 přidána MySQL Group Replication (a nakonec MySQL InnoDB Cluster). Funguje jako plugin a je součástí posledních verzí větve 5.7, ale to je téma samo o sobě. Stručně řečeno, replikace skupin vám umožňuje vytvořit „virtuálně“ synchronní cluster.
Toto rozhodně není úplný seznam funkcí – pokud vás zajímají všechny z nich, možná budete chtít nahlédnout do dokumentace MySQL 5.7.
Server Percona
Na začátku byla sada záplat pro použití na zdrojový kód MySQL, která přidala některá vylepšení výkonu a funkčnost. V určitém okamžiku se Percona rozhodla vydat své vlastní sestavení MySQL, které obsahovalo tyto záplaty. Časem bylo k dispozici více vývojových zdrojů, takže bylo přidáno více a více funkcí.
Obecně můžete Percona Server zobrazit jako nejnovější verzi MySQL s několika opravami/vylepšeními. Postupem času jsou některá vylepšení funkcí Percona Server nahrazena funkcemi z upstreamu – kdykoli Oracle vyvine funkci, která nahrazuje jednu z funkcí přidaných do Percona Server. Dokud je implementace na stejné úrovni, Percona odstraní svůj vlastní kód ve prospěch kódu z upstreamu. Díky tomu je Percona Server v podstatě náhradní náhradou za Oracle MySQL. Jednou z oblastí, ve kterých byla provedena zásadní vylepšení výkonu, je InnoDB. Byl dostatečně výrazně upraven, aby byl označen jako XtraDB. V současné době je plně kompatibilní s InnoDB, ale nebylo tomu tak vždy. Například některé funkce v Percona Server 5.5 nebyly kompatibilní s MySQL 5.5. To platí také pro novější verze Percona Server. Důležité je, že ve výchozím nastavení je Percona Server dodáván se všemi nekompatibilními funkcemi deaktivovanými – usnadňuje jeho testování a v případě potřeby návrat k Oracle MySQL. Vezmeme-li v úvahu vše výše uvedené, stále byste měli být opatrní, když plánujete migraci z Percona Server na MySQL – někdo mohl aktivovat jednu z nekompatibilních funkcí.
Co stojí za zdůraznění, je to, že Percona se snaží znovu implementovat podnikové funkce upstreamu. V případě MySQL jsou příklady implementace fondu vláken nebo autentizačního pluginu PAM. Pojďme se rychle podívat na některé funkce serveru Percona.
Funkce Percona Server 5.7
Jedním z hlavních rysů XtraDB je vylepšená škálovatelnost zásobníku vyrovnávacích pamětí – i když je stále méně sporů kvůli práci, kterou Oracle na každé verzi MySQL dělá, inženýrský tým Percony se snaží posunout výkon ještě dále a odstranit další mutexy, které mohou výkon omezovat. Navíc je do InnoDB monitoru (dostupného přes SHOW ENGINE INNODB STATUS) zapsáno více dat ohledně sporů v InnoDB – byla například přidána sekce o semaforech.
Další sada vylepšení byla provedena v oblasti I/O. V InnoDB můžete nastavit flush metodu pouze pro tabulkové prostory InnoDB, což způsobí dvojité ukládání do vyrovnávací paměti pro opakované protokoly InnoDB. XtraDB umožňuje používat O_DIRECT také pro tyto soubory. Také přidává další data týkající se kontrolních bodů do výstupu SHOW ENGINE INNODB STATUS. Kromě toho byly implementovány paralelní vyrovnávací paměti s dvojitým zápisem a vícevláknový proplachovač LRU, aby se snížily konflikty v I/O operacích v rámci InnoDB.
Další funkcí zpřístupněnou serverem Percona je fond vláken. V Oracle MySQL je k dispozici pouze ve verzi Enterprise. Zde můžete použít implementaci Percona zdarma. Obecně, fond vláken snižuje spory a zároveň obsluhuje vysoký počet připojení z aplikace opětovným použitím existujících připojení k databázi.
Další dvě funkce jsou přímou náhradou funkcí z verze Enterprise MySQL. Jedním z nich je autentizační plugin PAM, který byl vyvinut společností Percona a je navržen tak, aby umožňoval použití spousty různých možností autentizace, jako je LDAP, RSA SecurID nebo jakékoli jiné metody podporované PAM. S bezpečností souvisí i druhá vlastnost - plugin audit log. Vytvoří soubor se záznamem akcí provedených na databázovém serveru.
Čas od času společnost Percona zavádí významná vylepšení jiných úložných enginů, jako jsou změny provedené v enginu MEMORY, které umožnily použití dat typu VARCHAR nebo BLOB.
Poměrně významným zlepšením bylo také zavedení záložních zámků. V Oracle a MariaDB bylo jedinou metodou uzamčení tabulky pro získání konzistentní zálohy použití FLUSH TABLES WITH READ LOCK (FTWRL). Je poměrně těžký a nutí MySQL zavřít všechny otevřené tabulky. Záložní zámky na druhé straně používají lehčí přístup zámků metadat. V mnoha případech silně zatíženého serveru běží FTWRL příliš dlouho (a zamyká server na příliš dlouho), než aby to bylo považováno za proveditelné, zatímco zámky zálohy umožňují provést zálohu pomocí mysqldump nebo xtrabackup.
Percona je otevřená i pro funkce portování od jiných prodejců. Jedním z takových příkladů je port MariaDB ZAČNĚTE TRANSAKCI S KONZISTENTNÍMI SNÍMKY. Tato funkce také souvisí se zálohováním – s její pomocí můžete pořídit konzistentní logickou zálohu (pomocí mysqldump), aniž byste museli spouštět FLUSH TABLE WITH READ LOCK.
Nakonec tři funkce, které zlepšují pozorovatelnost – za prvé:statistiky uživatelů. Jedná se o poměrně nenáročnou funkci, která shromažďuje data o uživatelích, indexech, tabulkách a vláknech. Umožňuje vám najít nepoužívané indexy nebo určit, který uživatel je zodpovědný za zatížení serveru. V současnosti je částečně redundantní vzhledem k performance_schema, ale je o něco lehčí a vznikl v dobách MySQL 5.0 - 5.1, kde se o performance_schema nikomu ani nesnilo.
Za druhé - vylepšený protokol pomalých dotazů. Opět bylo přidáno v časech, kdy nejvyšší granularita long_query_time byla 1 sekunda. S tímto přidáním jste měli mikrosekundovou granularitu a spoustu dalších dat o statistikách InnoDB na dotaz nebo jeho celkových výkonnostních charakteristikách. Vytvořila dočasnou tabulku? Použil index? Byl uložen do mezipaměti dotazů MySQL?
Třetí vlastnost, kterou jsme několikrát zmínili výše - Percona Server vystavuje výrazně více dat v SHOW ENGINE INNODB STATUS než upstream. Rozhodně to pomáhá lépe porozumět pracovní zátěži a zachytit více problémů, než se rozvinou.
Toto samozřejmě není úplný seznam – pokud vás zajímají další podrobnosti, můžete se podívat do dokumentace serveru Percona.
MariaDB
MariaDB začala jako fork MySQL, ale když se k MariaDB připojila část původního vývojářského týmu MySQL, rychle se zaměřila na přidávání funkcí. V MariaDB 5.3 bylo do optimalizátoru přidáno mnoho funkcí:Batch Key Access, MultiRange Read, Index Condition Pushdown, abychom jmenovali alespoň některé. To umožnilo MariaDB vyniknout v některých pracovních zátěžích, kde by se MySQL nebo Percona Server potýkaly. Až dosud byly některé z těchto funkcí přidány do MySQL (většinou v MySQL 5.6), ale některé jsou stále jedinečné pro MariaDB.
Další důležitou funkcí, kterou MariaDB zavedla, bylo Global Transaction ID. Ne příliš mnoho později Oracle vydal svou vlastní implementaci, ale MariaDB byla první, kdo ji měl. Podobný příběh je s další funkcí replikace - replikace z více zdrojů:MariaDB ji měla před Oracle. Nyní nedávno vydaná MariaDB 10.2 také obsahuje funkce, které budou k dispozici v MySQL 8.0, která je stále ve vývoji. Hovoříme například o rekurzivních běžných tabulkových výrazech nebo okenních funkcích.
Funkce MariaDB 10.2
Jak jsme zmínili, MariaDB 10.2 zavádí funkce oken a rekurzivní běžné tabulkové výrazy – vylepšení v SQL, která by měla vývojářům pomoci psát efektivnější SQL dotazy.
Velmi důležitou změnou je, že MariaDB 10.2 používá InnoDB. Až do 10.1 se jako výchozí úložiště používal XtraDB. To bohužel znemožňuje uživatelům MariaDB 10.2 funkce přidané do nejnovější XtraDB.
Vylepšení byla provedena ve virtuálních sloupcích – ve verzi 10.2 byla zrušena další omezení.
Konečně byla přidána podpora pro více spouštěčů pro stejnou událost – nyní můžete vytvořit několik, například ON UPDATE spouštěčů ve stejné tabulce.
Vývojáři by měli těžit z podpory JSON spolu s několika funkcemi, které s tím souvisejí. Také by se jim měly líbit nové funkce, které jim umožní exportovat prostorová data do formátu GeoJSON. Když už mluvíme o JSON, byla provedena vylepšení ve výstupu EXPLAIN FORMAT=JSON – je zobrazeno více dat.
Na frontě zabezpečení byla přidána podpora pro OpenSSL 1.1 a LibreSSL.
Tento seznam samozřejmě není úplný a pokud vás zajímá, co bylo přidáno do MySQL 10.2, možná budete chtít nahlédnout do dokumentace.
Kromě nových funkcí MariaDB 10.2 těží z funkcí implementovaných v předchozích verzích. Projdeme si ty nejdůležitější.
Nejdůležitější funkce MariaDB 10.1
Za prvé, MariaDB od verze 10.1 je dodávána s clusterem Galera – není třeba instalovat další knihovny, vše je připraveno k použití.
MariaDB 10.1 přinesla implementaci šifrování dat v klidu. Ve srovnání s funkcí implementovanou v Oracle MySQL je MariaDB rozšířenější. Nejen, že šifruje tabulkové prostory, ale také šifruje redo logy, dočasné soubory a binární logy. S tím jsou spojeny některé problémy – nástroje CLI jako mysqldump nebo xtrabackup nemají přístup k binárním protokolům a mohou mít problémy se zálohováním zašifrovaných instancí (to platí zejména pro xtrabackup – nedávno MariaDB vytvořila xtrabackup fork nazvaný MariaDB Backup, který podporuje data v klidu šifrování).
Dobře, takže jakou příchuť bych měl použít?
Jak už to tak bývá, správná odpověď by byla:„Záleží“ :-) . Podělíme se o pár našich postřehů, které vám mohou nebo nemusí pomoci při rozhodování, ale nakonec je na vás, abyste spustili srovnávací testy a našli možnost, která bude pro vaše prostředí a aplikaci nejlépe vyhovovat.
Nejprve si promluvme o toku. Oracle vydává novou verzi – řekněme MySQL 5.7. Z hlediska výkonu se v tu chvíli jedná o nejrychlejší variantu MySQL na trhu. Je to proto, že pouze Oracle má dostatek zdrojů, aby mohl pracovat na vylepšení InnoDB v tomto rozsahu. Během několika měsíců (v případě 5.7 to byly 4 měsíce) Percona vydává Percona Server 5.7 se sadou vylepšení - v závislosti na typu zátěže může poskytovat ještě lepší výkon než upstream. Nakonec MariaDB přijímá novou upstreamovou verzi a staví na ní svou novou verzi.
Takto to vypadalo v kalendáři (stále mluvíme o MySQL 5.7).
MySQL 5.7 GA:21. října 2015
Percona Server 5.7 GA:23. února 2016
MariaDB 10.2 GA:23. května 2017
Všimněte si prosím, jak dlouho trvalo MariaDB, než vydala verzi založenou na MySQL 5.7 - všechny předchozí verze byly založeny na MySQL 5.6 a samozřejmě podávaly výkon nižší než MySQL 5.7. Na druhou stranu byla vydána MariaDB 10.2 s InnoDB, která nahrazuje XtraDB. I když je pravda, že Oracle většinou zacelil mezeru ve výkonu mezi MySQL a Percona Server, stále je to jen „většinou“. Výsledkem je, že MariaDB 10.2 může v některých případech poskytovat výkon nižší než výkon Percona Serveru (a v některých jiných případech lepší – kvůli práci optimalizátoru provedené v MariaDB 5.3, z nichž některé ještě nebyly znovu vytvořeny v MySQL).
Co se týče funkcí, je to složitější. MariaDB přidává spoustu funkcí, takže pokud vás některé z nich zajímají, můžete určitě zvážit použití MariaDB. Má to i svou nevýhodu. Percona Server měl mnoho funkcí, které jej odlišovaly od upstream MySQL, ale když je Oracle začal implementovat do MySQL, Percona se rozhodla odepsat jejich implementace ve prospěch použití implementace z upstreamu. To snížilo množství kódu, který se mezi MySQL a Percona Serverem liší, usnadňuje údržbu kódu Percona Serveru a co je nejdůležitější, Percona Server je 100% kompatibilní s MySQL.
To bohužel neplatí pro MariaDB. MariaDB představila GTID jako první, to je pravda, ale poté, co Oracle vyvinul jejich verzi GTID, MariaDB se rozhodla držet své vlastní implementace. Tento blog není místem, kde se rozhoduje, která implementace je lepší, ale v důsledku toho musíme spravovat dva různé, nekompatibilní systémy GTID – přidává to zátěž pro jakýkoli nástroj, který spravuje replikaci, a snižuje interoperabilitu. Držet se replikace – skupinové potvrzení a paralelní replikace:Oracle i MariaDB mají svou vlastní implementaci a pokud pracujete s oběma, musíte je oba naučit, abyste mohli aplikovat požadované ladění – knoflíky jsou různé a fungují jiným způsobem. Podobný případ je s podporou virtuálních sloupců – dvou různých, ne 100% kompatibilních implementací, které ve výsledku neumožňovaly snadné ukládání dat z MariaDB a načítání do Oracle MySQL (a naopak), protože syntaxe je mírně odlišná. Pokud se tedy rozhodnete použít verzi MariaDB pro nějakou zbrusu novou funkci, můžete s ní uvíznout, i když byste chtěli migrovat zpět na MySQL a používat implementaci Oracle. V nejlepším případě by migrace vyžadovala mnohem více úsilí. Samozřejmě, pokud zůstanete v jednom prostředí po celou dobu, nemusí vás to vážně ovlivnit. Ale i tak pro vás bude nedostatek kompatibility patrný, i když budete číst blogy na internetu a hledat řešení, která nejsou ve skutečnosti použitelná pro vaši verzi MySQL.
Takže abych to shrnul – pokud máte zájem o zachování kompatibility s MySQL, Percona Server (nebo samozřejmě samotné MySQL) by byla pravděpodobně správná cesta. Pokud vás zajímá výkon, pokud je Percona Server postaven na nejnovějším MySQL, může to být správná cesta. Samozřejmě můžete chtít porovnat MariaDB a zjistit, zda vaše pracovní zatížení nemůže těžit z některých optimalizací, které jsou pro MariaDB stále jedinečné. Z provozního hlediska je pravděpodobně dobré držet se jednoho z prostředí (Oracle/Percona nebo MariaDB), podle toho, které by vám vyhovovalo lépe. MySQL nebo Percona Server mají výhodu v tom, že jsou běžněji používané a je o něco jednodušší je integrovat s externími nástroji (protože ne všechny nástroje podporují všechny funkce MariaDB). Pokud byste měli prospěch z nové a zářivé funkce, která byla právě implementována do MariaDB, měli byste ji zvážit a mít na paměti všechny potenciální problémy s kompatibilitou a možný nižší výkon.
Doufáme, že vám tento příspěvek na blogu dal nějaké nápady ohledně různých možností, které máme ve světě MySQL, a různých úhlů pohledu, ze kterých je můžete porovnávat. Na konci dne bude vaším úkolem rozhodnout, co je pro vaše nastavení nejlepší. Nemusí to být snadné, ale přesto bychom měli být vděční, že máme na výběr a můžeme si vybrat to, co je pro nás nejlepší.