På den tiden när någon sa MySQL, fanns det bara MySQL. Du kunde välja olika versioner (4.0, 4.1) men leverantören var densamma. Detta förändrades kring MySQL 5.0/5.1 när Percona bestämde sig för att släppa sin egen smak av MySQL - Percona Server. Lite senare gick MariaDB med MariaDB 5.1 och det roliga (eller förvirringen) ökade. Vilken version ska jag använda? Vad är skillnaden mellan MySQL 5.1, Percona Server 5.1 och MariaDB 5.1? Vilken är snabbare? Vilken är mer stabil? Vilken har överlägsen funktionalitet? Med tiden blev detta värre eftersom fler och fler förändringar infördes i var och en av smakerna. Det här blogginlägget kommer att vara vårt försök att sammanfatta nyckelfunktionerna som skiljer dem åt. Vi ska också försöka ge dig några förslag på vilken smak som kan vara den bästa för en given typ av projekt. Låt oss komma igång.
Oracle MySQL
Det brukade vara MySQL, nu är det uppströms. Det mesta av utvecklingen börjar här, varje version från 5.6 löser vissa interna konflikter och ger bättre prestanda. Nya funktioner läggs också till regelbundet. MySQL 5.6 gav oss (bland andra) GTID och en initial implementering av parallell replikering. Det gav oss också möjlighet att exekvera de flesta ALTERs på ett online-sätt. Låt oss ta en titt på funktionerna i den senaste MySQL-versionen - MySQL 5.7
Funktioner i MySQL 5.7
En av de stora förändringarna är förändringar i distributionsprocessen - istället för olika skript, kan du bara köra mysqld --initialize för att ställa in MySQL från början. En annan mycket viktig förändring - parallell replikering baserad på logisk klocka. Slutligen kan vi använda parallell replikering i alla fall - oavsett om du använder flera scheman eller inte. En annan replikeringsförbättring är replikering med flera källor - en 5.7-slav kan ha flera masters - det är en fantastisk funktion om du vill bygga en aggregeringsslav och, låt oss säga, kombinera data från flera, separata kluster.
InnoDB började stödja rumsliga typer, InnoDB buffertpool kan äntligen ändras i storlek under körning, online ALTERs har förbättrats för att stödja fler fall som partitionering och no-op ALTERs.
MySQL började stödja JSON-datatyper inbyggt tillsammans med flera nya funktioner som är fokuserade på att lägga till funktionalitet kring JSON. Säkerheten för din data är mycket viktig nuförtiden, MySQL 5.7 stöder data-at-rest-kryptering för fil-per-tabell-tabellutrymmen. Vissa förbättringar har också lagts till i SSL-stödet (SSL kommer att konfigureras om nycklar finns på plats, ett skript ingår som kan användas för att skapa certifikat). Ur ett användarhanteringsperspektiv har inställningar för lösenordslivstid lagts till, vilket borde göra utformningen av policyer för utgångsdatum för lösenord lite enklare.
En annan funktion som är avsedd att hjälpa DBA är "sys"-schemat, en uppsättning vyer utformade för att göra det enklare att använda Performance Schema. Den har inkluderats som standard i MySQL 5.7.
Slutligen har MySQL Group Replication (och så småningom MySQL InnoDB Cluster) lagts till i MySQL 5.7. Det fungerar som ett plugin och ingår i de senaste versionerna av 5.7-grenen, men det är ett eget ämne. Kort sagt låter gruppreplikering dig bygga ett "nästan" synkront kluster.
Det här är definitivt inte en fullständig lista över funktioner - om du är intresserad av dem alla kan du läsa MySQL 5.7-dokumentationen.
Percona Server
I början fanns det en uppsättning patchar att applicera på MySQL-källkoden som lade till vissa prestandaförbättringar och funktionalitet. Vid något tillfälle bestämde Percona sig för att släppa sin egen version av MySQL som inkluderade dessa patchar. Med tiden blev fler utvecklingsresurser tillgängliga, så fler och fler funktioner har lagts till.
I allmänhet kan du se Percona Server som den senaste MySQL-versionen med flera patchar/förbättringar. Med tiden ersätts vissa av Percona Server-funktionsförbättringarna av funktioner från uppströms - närhelst Oracle utvecklar en funktion som ersätter en av funktionerna som läggs till i Percona Server. Så länge implementeringen är i nivå, tar Percona bort sin egen kod till förmån för kod från uppströms. Detta gör Percona Server i princip till en drop-in-ersättning för Oracles MySQL. Ett av de områden där stora prestandaförbättringar har gjorts är InnoDB. Det har modifierats tillräckligt avsevärt för att varumärket det som XtraDB. För närvarande är det helt kompatibelt med InnoDB men det har inte alltid varit så. Till exempel var vissa funktioner i Percona Server 5.5 inte kompatibla med MySQL 5.5. Det gäller även för nyare versioner av Percona Server. Det som är viktigt är att Percona Server som standard levereras med alla inkompatibla funktioner inaktiverade - det gör det enkelt att testa den och rulla tillbaka till Oracles MySQL om det behövs. Med hänsyn till allt ovan bör du fortfarande vara försiktig när du planerar att migrera från Percona Server till MySQL – någon kanske har aktiverat en av inkompatibla funktioner.
Det som är värt att lyfta fram är att Percona strävar efter att återimplementera företagsfunktioner i upstream. När det gäller MySQL är exempel implementering av en trådpool eller PAM-autentiseringsplugin. Låt oss ta en snabb titt på några av funktionerna i Percona Server.
Funktioner i Percona Server 5.7
En av huvudfunktionerna i XtraDB är förbättrad skalbarhet i buffertpoolen – även om det blir mindre och mindre stridigheter på grund av det arbete som Oracle gör på varje MySQL-version, strävar Perconas ingenjörsteam efter att driva prestandan ännu längre och ta bort ytterligare mutexer som kan begränsa prestandan. Dessutom skrivs mer data in i InnoDB-monitorn (tillgänglig via SHOW ENGINE INNODB STATUS) angående påståenden inom InnoDB - t.ex. har ett avsnitt om semaforer lagts till.
Ytterligare en uppsättning förbättringar har gjorts inom området I/O. I InnoDB kan du ställa in en tömningsmetod endast för InnoDB-tabellutrymmen och detta orsakar dubbelbuffring för InnoDB-redologgar. XtraDB gör det möjligt att använda O_DIRECT även för dessa filer. Den lägger också till mer information om kontrollpunkter till utgången av SHOW ENGINE INNODB STATUS. Utöver det har parallell dubbelskrivningsbuffert och flertrådad LRU-spolare implementerats för att minska konflikter i I/O-operationer inom InnoDB.
Trådpool är en annan funktion som gjorts tillgänglig av Percona Server. I Oracle MySQL är det endast tillgängligt i Enterprise-utgåvan. Här kan du använda Perconas implementering gratis. Generellt sett minskar trådpoolen konflikter samtidigt som det betjänar ett stort antal anslutningar från applikationen genom att återanvända befintliga anslutningar till databasen.
Ytterligare två funktioner är direkta ersättningar av funktioner från Enterprise-versionen av MySQL. En av dem är PAM-autentiseringsplugin som har utvecklats av Percona och är designad för att tillåta användning av många olika autentiseringsalternativ som LDAP, RSA SecurID eller andra metoder som stöds av PAM. Den andra funktionen är också relaterad till säkerhet - plugin för revisionslogg. Det kommer att skapa en fil med en förteckning över åtgärder som vidtagits på databasservern.
Då och då introducerar Percona betydande förbättringar av andra lagringsmotorer, som de ändringar de gjorde i MEMORY-motorn som gjorde det möjligt att använda data av typen VARCHAR eller BLOB.
Införandet av säkerhetslås var också en ganska betydande förbättring. I Oracle och MariaDB var den enda metoden för att låsa tabellen för att få en konsekvent säkerhetskopiering att använda SPOLA TABELLER MED LÄSSLÅS (FTWRL). Det är ganska tungt och det tvingar MySQL att stänga alla öppna tabeller. Säkerhetskopieringslås, å andra sidan, använder ett lättare tillvägagångssätt för metadatalås. I många fall av tungt belastad server som kör FTWRL tar det för lång tid (och låser servern för länge) för att anses vara genomförbart medan säkerhetskopieringslås gör det möjligt att ta en säkerhetskopia med mysqldump eller xtrabackup.
Percona är även öppen för porteringsfunktioner från andra leverantörer. Ett sådant exempel är porten av MariaDB:s START TRANSAKTION MED KONSISTENT SNAPSHOTS. Den här funktionen är också relaterad till säkerhetskopior - med dess hjälp kan du ta en konsekvent logisk säkerhetskopia (med mysqldump) utan att köra SPOLA TABELL MED LÄSSLÅS.
Slutligen tre funktioner som förbättrar observerbarheten - först:användarstatistik. Detta är en ganska lätt funktion som samlar in data om användare, index, tabeller och trådar. Det låter dig hitta oanvända index eller bestämma vilken användare som är ansvarig för belastningen på servern. För närvarande är det delvis överflödigt för performance_schema men det är lite lättare och det skapades under MySQL 5.0 - 5.1, där ingen ens drömde om performance_schema.
För det andra - förbättrad långsam frågelogg. Återigen lades det till i tider där den högsta granulariteten för long_query_time var 1 sekund. Med detta tillägg hade du mikrosekundsgranularitet och en massa ytterligare data om InnoDB-statistik per fråga eller dess övergripande prestandaegenskaper. Skapade det en tillfällig tabell? Använde den ett index? Har den cachats i MySQL-frågecachen?
Tredje funktionen som vi nämnde ett par gånger ovan - Percona Server exponerar betydligt mer data i SHOW ENGINE INNODB STATUS än uppströms. Det hjälper definitivt att förstå arbetsbelastningen ytterligare och fånga fler problem innan de utvecklas.
Naturligtvis är detta inte en fullständig lista - om du är intresserad av mer information, kanske du vill kontrollera Percona Servers dokumentation.
MariaDB
MariaDB började som en gaffel av MySQL men, med en del av det ursprungliga MySQL-utvecklingsteamet som gick med i MariaDB, fokuserade det snabbt på att lägga till funktioner. I MariaDB 5.3 hade massor av funktioner lagts till i optimeraren:Batch Key Access, MultiRange Read, Index Condition Pushdown för att nämna några. Detta gjorde att MariaDB kunde utmärka sig i vissa arbetsbelastningar där MySQL eller Percona Server skulle kämpa. Hittills har några av dessa funktioner lagts till i MySQL (mest i MySQL 5.6) men några är fortfarande unika för MariaDB.
En annan viktig funktion som introducerades av MariaDB var Global Transaction ID. Inte så mycket senare släppte Oracle sin egen implementering men MariaDB var först med den. Liknande historia är med en annan replikeringsfunktion - multisource replikering:MariaDB hade det före Oracle. Nu, nyligen släppt MariaDB 10.2 innehåller också funktioner som kommer att göras tillgängliga i MySQL 8.0, som fortfarande är under utveckling. Vi pratar till exempel om rekursiva vanliga tabelluttryck eller fönsterfunktioner.
Funktioner i MariaDB 10.2
Som vi nämnde introducerar MariaDB 10.2 fönsterfunktioner och rekursiva vanliga tabelluttryck - förbättringar i SQL som borde hjälpa utvecklare att skriva effektivare SQL-frågor.
Mycket viktig förändring är att MariaDB 10.2 använder InnoDB. Fram till 10.1 har XtraDB använts som standardlagring. Detta gör tyvärr att funktioner som lagts till i senaste XtraDB inte är tillgängliga för MariaDB 10.2-användare.
Förbättringar har gjorts i virtuella kolumner - fler begränsningar har tagits bort i 10.2.
Äntligen har stöd för flera triggers för samma händelse lagts till - nu kan du skapa flera, till exempel ON UPDATE-triggers på samma bord.
Utvecklare bör dra nytta av JSON-stöd, tillsammans med ett par funktioner som är relaterade till det. De borde också gilla nya funktioner som gör att de kan exportera rumslig data till GeoJSON-format. På tal om JSON, förbättringar har gjorts i EXPLAIN FORMAT=JSON-utgången - mer data visas.
På säkerhetsfronten har stöd för OpenSSL 1.1 och LibreSSL lagts till.
Naturligtvis är den här listan inte komplett och om du är intresserad av vad som har lagts till i MySQL 10.2 kan du läsa dokumentationen.
Förutom nya funktioner drar MariaDB 10.2 nytta av funktioner implementerade i tidigare versioner. Vi går igenom de viktigaste.
De viktigaste funktionerna i MariaDB 10.1
Först och främst kommer MariaDB sedan 10.1 med Galera-kluster - inget behov av att installera ytterligare bibliotek, allt är redo att användas.
MariaDB 10.1 tog med sig implementering av data-at-rest-kryptering. Jämfört med funktionen implementerad i Oracles MySQL, har MariaDB den mer utökad. Den krypterar inte bara tabellutrymmen utan den krypterar också redo-loggar, temporära filer och binära loggar. Detta kommer med vissa problem - CLI-verktyg som mysqldump eller xtrabackup kan inte komma åt binära loggar och kan ha problem med att säkerhetskopiera krypterade instanser (detta gäller särskilt för xtrabackup - ganska nyligen skapade MariaDB xtrabackup-gaffel som heter MariaDB Backup som stöder data-at-rest kryptering).
Ok, så vilken smak ska jag använda?
Som det brukar vara, skulle det korrekta svaret vara:"Det beror på" :-) . Vi kommer att dela några av våra observationer som kanske eller inte kan hjälpa dig att bestämma dig, men i slutändan är det upp till dig att köra riktmärken och hitta det alternativ som fungerar bäst för din miljö och applikation.
Först och främst, låt oss prata om flödet. Oracle släpper ny version - låt oss säga MySQL 5.7. Prestandamässigt, för tillfället, är detta den snabbaste MySQL-smaken på marknaden. Detta beror på att endast Oracle har tillräckligt med resurser för att arbeta med att förbättra InnoDB i den utsträckningen. Inom ett par månader (i fallet med 5.7 var det 4 månader) släpper Percona Percona Server 5.7 med sina förbättringar - beroende på typ av arbetsbelastning kan den ge ännu bättre prestanda än uppströms. Slutligen antar MariaDB en ny uppströmsversion och bygger sin nya version ovanpå den.
Så här såg det ut i en kalender (vi pratar fortfarande om MySQL 5.7).
MySQL 5.7 GA:21 oktober 2015
Percona Server 5.7 GA:23 februari 2016
MariaDB 10.2 GA:23 maj 2017
Observera hur lång tid det tog för MariaDB att släppa en version baserad på MySQL 5.7 - alla tidigare versioner har varit baserade på MySQL 5.6 och, uppenbarligen, levererat prestanda lägre än MySQL 5.7. Å andra sidan har MariaDB 10.2 släppts med InnoDB som ersätter XtraDB. Även om det är sant att Oracle mestadels täppte till prestandagapet mellan MySQL och Percona Server, är det fortfarande bara "för det mesta". Som ett resultat kan MariaDB 10.2 leverera lägre prestanda än Percona Server i vissa fall (och bättre i vissa andra fall - på grund av optimeringsarbete som gjorts i MariaDB 5.3, av vilka en del inte har återskapats ännu i MySQL).
Funktionsmässigt är det mer komplext. MariaDB har lagt till massor av funktioner, så om du är intresserad av några av dem kan du definitivt överväga att använda MariaDB. Det finns en baksida med det också. Percona Server hade en hel del funktioner som skilde den från uppströms MySQL, men när Oracle började implementera dem i MySQL, bestämde Percona sig för att avskriva deras implementeringar till förmån för att använda implementeringen från uppströms. Detta minskade mängden kod som skiljer sig mellan MySQL och Percona Server, gör det lättare att underhålla Percona Servers kod och, vad som är viktigast, gör Percona Server 100 % kompatibel med MySQL.
Detta är tyvärr inte sant för MariaDB. MariaDB introducerade GTID först, det är sant, men efter att Oracle utvecklat sin version av GTID, bestämde sig MariaDB för att hålla fast vid sin egen implementering. Den här bloggen är inte platsen att bestämma vilken implementering som är bättre, men som ett resultat måste vi hantera två olika, inkompatibla GTID-system - det lägger till bördan på alla verktyg som hanterar replikering och minskar interoperabilitet. Att hålla sig till replikering - gruppbekräftelse och parallell replikering:både Oracle och MariaDB har sin egen implementering och om du arbetar med båda måste du lära dig båda för att tillämpa den justering som krävs - rattarna är olika och fungerar på ett annat sätt. Liknande fall är med stöd för virtuella kolumner - två olika, inte 100% kompatibla implementeringar som, som ett resultat, gjorde det inte möjligt att enkelt dumpa data från MariaDB och ladda in i Oracles MySQL (och vice versa) eftersom syntaxen är något annorlunda. Så om du skulle besluta dig för att använda en version av MariaDB för någon helt ny funktion, kan du hamna i den även om du skulle vilja migrera tillbaka till MySQL för att använda Oracles implementering. I bästa fall skulle migreringen kräva mycket mer ansträngning att genomföra. Naturligtvis, om du vistas i samma miljö hela tiden, kanske det inte påverkar dig allvarligt. Men även då kommer en brist på kompatibilitet att märkas för dig, om så bara medan du läser bloggar på internet och hittar lösningar som inte riktigt är tillämpliga på din smak av MySQL.
Så, för att sammanfatta det - om du är intresserad av att upprätthålla kompatibilitet med MySQL, skulle Percona Server (eller MySQL självt, förstås) förmodligen vara rätt väg att gå. Om du är intresserad av prestanda, så länge det finns Percona Server byggd ovanpå den senaste MySQL, kan det vara rätt väg att gå. Naturligtvis kanske du vill jämföra MariaDB och se om din arbetsbelastning inte kan dra nytta av några av optimeringar som fortfarande är unika för MariaDB. Operativt sett är det förmodligen bra att hålla sig till någon av miljöerna (Oracle/Percona eller MariaDB), beroende på vilket som skulle fungera bäst för dig. MySQL eller Percona Server har en fördel på ett sätt att de är vanligare och det är något lättare att integrera dem med externa verktyg (eftersom inte alla verktyg stöder alla MariaDB-funktioner). Om du skulle dra nytta av en ny och glänsande funktion som just har implementerats i MariaDB, bör du överväga det, med tanke på eventuella kompatibilitetsproblem och eventuellt lägre prestanda.
Vi hoppas att det här blogginlägget gav dig några idéer om olika val vi har i MySQL-världen och olika vinklar från vilka du kan jämföra dem. I slutet av dagen blir det din uppgift att bestämma vad som är bäst för din installation. Det kanske inte är lätt men då borde vi ändå vara tacksamma för att vi har ett val och att vi kan välja det som fungerar bäst för oss.