In de tijd dat iemand MySQL zei, was er alleen de MySQL. Je kon verschillende versies kiezen (4.0, 4.1), maar de leverancier was hetzelfde. Dit veranderde rond MySQL 5.0/5.1 toen Percona besloot om hun eigen versie van MySQL - Percona Server, uit te brengen. Even later voegde MariaDB zich bij MariaDB 5.1 en het plezier (of de verwarring) nam toe. Welke versie moet ik gebruiken? Wat is het verschil tussen MySQL 5.1, Percona Server 5.1 en MariaDB 5.1? Welke is sneller? Welke is stabieler? Welke heeft superieure functionaliteit? Na verloop van tijd werd dit erger naarmate er meer en meer veranderingen werden aangebracht in elk van de smaken. Deze blogpost zal onze poging zijn om de belangrijkste kenmerken samen te vatten die hen onderscheiden. We zullen ook proberen u enkele suggesties te geven over welke smaak het beste is voor een bepaald type project. Laten we beginnen.
Oracle MySQL
Vroeger was het de MySQL, nu is het de upstream. Het grootste deel van de ontwikkeling begint hier, elke versie vanaf 5.6 lost enkele interne geschillen op en zorgt voor betere prestaties. Ook worden er regelmatig nieuwe features toegevoegd. MySQL 5.6 bracht ons (onder andere) GTID en een eerste implementatie van parallelle replicatie. Het gaf ons ook de mogelijkheid om de meeste ALTER's online uit te voeren. Laten we eens kijken naar de functies van de nieuwste MySQL-versie - MySQL 5.7
Kenmerken van MySQL 5.7
Een van de belangrijkste wijzigingen zijn wijzigingen in het implementatieproces - in plaats van verschillende scripts, kunt u gewoon mysqld --initialize uitvoeren om MySQL helemaal opnieuw in te stellen. Een andere zeer belangrijke verandering - parallelle replicatie op basis van logische klok. Ten slotte kunnen we in alle gevallen parallelle replicatie gebruiken - ongeacht of u meerdere schema's gebruikt of niet. Een andere verbetering van de replicatie is replicatie met meerdere bronnen - een 5.7-slave kan meerdere masters hebben - het is een geweldige functie als u een aggregatie-slave wilt bouwen en, laten we zeggen, gegevens uit meerdere, afzonderlijke clusters wilt combineren.
InnoDB begon ruimtelijke typen te ondersteunen, de grootte van de InnoDB-bufferpool kan tijdens runtime worden gewijzigd, online ALTER's zijn verbeterd om meer gevallen te ondersteunen, zoals partitionering en no-op ALTER's.
MySQL begon native JSON-gegevenstypen te ondersteunen, samen met verschillende nieuwe functies die gericht zijn op het toevoegen van functionaliteit rond JSON. Beveiliging van uw gegevens is tegenwoordig erg belangrijk, MySQL 5.7 ondersteunt data-at-rest-codering voor tabelruimten per tabel. Er zijn ook enkele verbeteringen toegevoegd aan de SSL-ondersteuning (SSL wordt geconfigureerd als er sleutels aanwezig zijn, er is een script meegeleverd waarmee certificaten kunnen worden gemaakt). Vanuit het oogpunt van gebruikersbeheer is het instellen van de levensduur van wachtwoorden toegevoegd, wat het ontwerp van beleid voor het verlopen van wachtwoorden een beetje eenvoudiger zou moeten maken.
Een andere functie die bedoeld is om DBA's te helpen, is het 'sys'-schema, een reeks weergaven die is ontworpen om het gebruik van het prestatieschema te vergemakkelijken. Het is standaard opgenomen in MySQL 5.7.
Ten slotte is MySQL Group Replication (en uiteindelijk MySQL InnoDB Cluster) toegevoegd aan MySQL 5.7. Het werkt als een plug-in en is opgenomen in recente versies van de 5.7-tak, maar dat is een onderwerp op zich. Kortom, met Groepsreplicatie kunt u een "virtueel" synchrone cluster bouwen.
Dit is zeker geen volledige lijst met functies - als je in alle functies geïnteresseerd bent, kun je de MySQL 5.7-documentatie raadplegen.
Percona-server
In het begin was er een reeks patches om toe te passen op de MySQL-broncode, wat enkele prestatieverbeteringen en functionaliteit toevoegde. Op een gegeven moment besloot Percona om hun eigen build van MySQL uit te brengen, inclusief deze patches. Na verloop van tijd kwamen er meer ontwikkelingsbronnen beschikbaar, dus er zijn steeds meer functies toegevoegd.
Over het algemeen kunt u Percona Server zien als de nieuwste MySQL-versie met meerdere patches/verbeteringen. Na verloop van tijd worden enkele van de verbeteringen aan de functies van Percona Server vervangen door functies uit de upstream - telkens wanneer Oracle een functie ontwikkelt die een van de functionaliteiten vervangt die in Percona Server zijn toegevoegd. Zolang de implementatie gelijk is, verwijdert Percona hun eigen code ten gunste van code uit de upstream. Dit maakt Percona Server in feite een drop-in vervanging voor Oracle's MySQL. Een van de gebieden waarop grote prestatieverbeteringen zijn doorgevoerd, is InnoDB. Het is aanzienlijk genoeg gewijzigd om het als XtraDB te bestempelen. Momenteel is het volledig compatibel met InnoDB, maar dat is niet altijd zo geweest. Sommige functies in Percona Server 5.5 waren bijvoorbeeld niet compatibel met MySQL 5.5. Dit geldt ook voor recentere versies van Percona Server. Wat belangrijk is, is dat Percona Server standaard wordt geleverd met alle incompatibele functies uitgeschakeld - het maakt het gemakkelijk om het te testen en indien nodig terug te draaien naar Oracle's MySQL. Rekening houdend met al het bovenstaande, moet u toch voorzichtig zijn wanneer u van plan bent te migreren van Percona Server naar MySQL - iemand heeft mogelijk een van de incompatibele functies ingeschakeld.
Wat de moeite waard is om te benadrukken, is dat Percona ernaar streeft bedrijfsfuncties van de upstream opnieuw te implementeren. In het geval van MySQL zijn voorbeelden de implementatie van een threadpool of PAM-authenticatieplug-in. Laten we eens kijken naar enkele functies van de Percona Server.
Kenmerken van Percona Server 5.7
Een van de belangrijkste kenmerken van XtraDB is de verbeterde schaalbaarheid van de bufferpool - hoewel er steeds minder controverse is vanwege het werk dat Oracle doet aan elke MySQL-versie, streeft het technische team van Percona ernaar om de prestaties nog verder te verbeteren en extra mutexen te verwijderen die de prestaties kunnen beperken. Bovendien worden er meer gegevens naar de InnoDB-monitor geschreven (toegankelijk via SHOW ENGINE INNODB STATUS) met betrekking tot geschillen binnen InnoDB - er is bijvoorbeeld een sectie over semaforen toegevoegd.
Op het gebied van I/O is nog een reeks verbeteringen doorgevoerd. In InnoDB kunt u alleen een flush-methode instellen voor InnoDB-tabelruimten en dit veroorzaakt dubbele buffering voor InnoDB-redo-logs. XtraDB maakt het mogelijk om O_DIRECT ook voor die bestanden te gebruiken. Het voegt ook meer gegevens met betrekking tot controlepunten toe aan de uitvoer van SHOW ENGINE INNODB STATUS. Daarnaast zijn parallelle dubbele schrijfbuffer en multi-threaded LRU-flusher geïmplementeerd om conflicten in I/O-bewerkingen binnen InnoDB te verminderen.
Discussiepool is een andere functie die beschikbaar is gesteld door Percona Server. In Oracle MySQL is het alleen beschikbaar in de Enterprise-editie. Hier kunt u gratis gebruik maken van de implementatie van Percona. Over het algemeen vermindert threadpool conflicten terwijl het een groot aantal verbindingen van de toepassing bedient door bestaande verbindingen met de database opnieuw te gebruiken.
Twee andere functies zijn directe vervangingen van functies uit de Enterprise-versie van MySQL. Een daarvan is de PAM-authenticatie-plug-in die is ontwikkeld door Percona en is ontworpen om het gebruik van tal van verschillende authenticatie-opties mogelijk te maken, zoals LDAP, RSA SecurID of andere methoden die door PAM worden ondersteund. De tweede functie heeft ook te maken met beveiliging - plug-in voor auditlogboeken. Het zal een bestand aanmaken met een overzicht van de acties die zijn ondernomen op de databaseserver.
Van tijd tot tijd introduceert Percona belangrijke verbeteringen aan andere storage-engines, zoals de wijzigingen die ze hebben aangebracht in de MEMORY-engine waardoor VARCHAR- of BLOB-gegevens konden worden gebruikt.
De introductie van back-upvergrendelingen was ook een nogal significante verbetering. In Oracle en MariaDB was de enige methode om de tabel te vergrendelen om een consistente back-up te krijgen, het gebruik van FLUSH TABLES WITH READ LOCK (FTWRL). Het is nogal zwaar en dwingt MySQL om alle geopende tafels te sluiten. Back-upvergrendelingen gebruiken daarentegen een lichtere benadering van metagegevensvergrendelingen. In veel gevallen duurt het uitvoeren van een zwaarbelaste server met FTWRL te lang (en vergrendelt de server te lang) om als haalbaar te worden beschouwd, terwijl back-upvergrendelingen het mogelijk maken om een back-up te maken met mysqldump of xtrabackup.
Percona staat ook open voor het overzetten van functies van andere leveranciers. Een voorbeeld hiervan is de port van MariaDB's START TRANSACTION WITH CONSISTENT SNAPSHOTS. Deze functie is ook gerelateerd aan back-ups - met zijn hulp kunt u een consistente logische back-up maken (met mysqldump) zonder FLUSH TABLE WITH READ LOCK uit te voeren.
Tot slot drie functies die de waarneembaarheid verbeteren - ten eerste:gebruikersstatistieken. Dit is een redelijk lichtgewicht functie die gegevens verzamelt over gebruikers, indexen, tabellen en threads. Hiermee kunt u ongebruikte indexen vinden of bepalen welke gebruiker verantwoordelijk is voor de belasting van de server. Momenteel is het gedeeltelijk overbodig voor performance_schema, maar het is een beetje lichter en het werd gemaakt in de dagen van MySQL 5.0 - 5.1, waar niemand zelfs maar over het performance_schema droomde.
Ten tweede - verbeterd logboek voor trage zoekopdrachten. Nogmaals, het werd toegevoegd in tijden waarin de hoogste granulariteit van long_query_time 1 seconde was. Met deze toevoeging had je microseconde granulariteit en een heleboel extra gegevens over InnoDB-statistieken per zoekopdracht of de algemene prestatiekenmerken. Heeft het een tijdelijke tabel gemaakt? Heeft het een index gebruikt? Is het in de cache opgeslagen in de MySQL-querycache?
Derde functie die we hierboven een paar keer noemden - Percona Server stelt aanzienlijk meer gegevens bloot in SHOW ENGINE INNODB STATUS dan stroomopwaarts. Het helpt zeker om de werklast beter te begrijpen en meer problemen op te vangen voordat ze zich ontvouwen.
Dit is natuurlijk geen volledige lijst - als u geïnteresseerd bent in meer details, kunt u de documentatie van Percona Server raadplegen.
MariaDB
MariaDB begon als een fork van MySQL, maar toen een deel van het oorspronkelijke MySQL-ontwikkelteam zich bij MariaDB voegde, richtte het zich al snel op het toevoegen van functies. In MariaDB 5.3 waren veel functies toegevoegd aan de optimizer:Batch Key Access, MultiRange Read, Index Condition Pushdown om er maar een paar te noemen. Hierdoor kon MariaDB uitblinken in sommige workloads waar MySQL of Percona Server moeite mee zouden hebben. Tot nu toe zijn sommige van die functies toegevoegd aan MySQL (meestal in MySQL 5.6), maar sommige zijn nog steeds uniek voor MariaDB.
Een andere belangrijke functie die door MariaDB werd geïntroduceerd, was Global Transaction ID. Niet veel later bracht Oracle zijn eigen implementatie uit, maar MariaDB was de eerste die het had. Een soortgelijk verhaal is met een andere replicatiefunctie - multisource-replicatie:MariaDB had het vóór Oracle. Nu bevat de onlangs uitgebrachte MariaDB 10.2 ook functies die beschikbaar zullen worden gemaakt in MySQL 8.0, dat nog in ontwikkeling is. We hebben het bijvoorbeeld over recursieve algemene tabeluitdrukkingen of vensterfuncties.
Kenmerken van MariaDB 10.2
Zoals we al zeiden, introduceert MariaDB 10.2 vensterfuncties en recursieve algemene tabeluitdrukkingen - verbeteringen in SQL die ontwikkelaars zouden moeten helpen efficiëntere SQL-query's te schrijven.
Zeer belangrijke verandering is dat MariaDB 10.2 InnoDB gebruikt. Tot 10.1 is XtraDB gebruikt als standaardopslag. Hierdoor zijn de functies die zijn toegevoegd in de nieuwste XtraDB helaas niet beschikbaar voor MariaDB 10.2-gebruikers.
Er zijn verbeteringen aangebracht in virtuele kolommen - meer beperkingen zijn opgeheven in 10.2.
Ten slotte is ondersteuning voor meerdere triggers voor dezelfde gebeurtenis toegevoegd - nu kunt u meerdere, bijvoorbeeld ON UPDATE-triggers maken op dezelfde tafel.
Ontwikkelaars moeten profiteren van JSON-ondersteuning, samen met een aantal functies die ermee verband houden. Ze zouden ook blij moeten zijn met nieuwe functies waarmee ze ruimtelijke gegevens kunnen exporteren naar GeoJSON-indeling. Over JSON gesproken, er zijn verbeteringen aangebracht in EXPLAIN FORMAT=JSON-uitvoer - er worden meer gegevens weergegeven.
Op het gebied van beveiliging is ondersteuning voor OpenSSL 1.1 en LibreSSL toegevoegd.
Deze lijst is natuurlijk niet compleet en als je geïnteresseerd bent in wat er is toegevoegd aan MySQL 10.2, kun je documentatie raadplegen.
Naast nieuwe functies profiteert MariaDB 10.2 van functies die in eerdere versies zijn geïmplementeerd. We zullen de belangrijkste doornemen.
De belangrijkste kenmerken van MariaDB 10.1
Allereerst wordt MariaDB sinds 10.1 gebundeld met Galera-cluster - het is niet nodig om extra bibliotheken te installeren, alles is klaar voor gebruik.
MariaDB 10.1 bracht implementatie van data-at-rest-codering. Vergeleken met de functie die is geïmplementeerd in MySQL van Oracle, heeft MariaDB deze meer uitgebreid. Het versleutelt niet alleen tablespaces, maar het versleutelt ook redo-logs, tijdelijke bestanden en binaire logs. Dit gaat gepaard met enkele problemen - CLI-tools zoals mysqldump of xtrabackup hebben geen toegang tot binaire logbestanden en kunnen problemen hebben met het maken van back-ups van versleutelde instanties (dit geldt met name voor xtrabackup - vrij recent heeft MariaDB een xtrabackup-fork gemaakt, genaamd MariaDB Backup, die data-at-rest ondersteunt encryptie).
Ok, dus welke smaak moet ik gebruiken?
Zoals het meestal is, zou het juiste antwoord zijn:"Het hangt ervan af" :-) . We zullen een aantal van onze observaties met u delen die u al dan niet kunnen helpen bij uw beslissing, maar uiteindelijk is het aan u om benchmarks uit te voeren en de optie te vinden die het beste werkt voor uw omgeving en toepassing.
Laten we het eerst hebben over de stroom. Oracle brengt nieuwe versie uit - laten we zeggen MySQL 5.7. Qua prestaties is dit op dat moment de snelste MySQL-smaak op de markt. Dit komt omdat alleen Oracle voldoende middelen heeft om in die mate aan het verbeteren van InnoDB te werken. Binnen een paar maanden (in het geval van 5.7 was het 4 maanden) brengt Percona Percona Server 5.7 uit met hun reeks verbeteringen - afhankelijk van het type workload kan het zelfs betere prestaties leveren dan de upstream. Ten slotte neemt MariaDB een nieuwe upstream-versie aan en bouwt er een nieuwe versie bovenop.
Zo zag het eruit in een kalender (we hebben het nog steeds over MySQL 5.7).
MySQL 5.7 GA:21 oktober 2015
Percona Server 5.7 GA:23 februari 2016
MariaDB 10.2 GA:23 mei 2017
Houd er rekening mee hoe lang het MariaDB duurde om een versie uit te brengen op basis van MySQL 5.7 - alle eerdere versies waren gebaseerd op MySQL 5.6 en leverden uiteraard lagere prestaties dan MySQL 5.7. Aan de andere kant is MariaDB 10.2 uitgebracht waarbij InnoDB XtraDB vervangt. Hoewel het waar is dat Oracle de prestatiekloof tussen MySQL en Percona Server grotendeels heeft gedicht, is het nog steeds "meestal". Als gevolg hiervan kan MariaDB 10.2 in sommige gevallen lagere prestaties leveren dan die van Percona Server (en in sommige andere gevallen beter - vanwege optimalisatiewerk in MariaDB 5.3, waarvan sommige nog niet opnieuw zijn gemaakt in MySQL).
Qua functionaliteit is het complexer. MariaDB heeft veel functies toegevoegd, dus als u geïnteresseerd bent in enkele ervan, kunt u zeker overwegen om MariaDB te gebruiken. Er zit ook een keerzijde aan. Percona Server had een groot aantal functies die het onderscheidden van upstream MySQL, maar toen Oracle ze begon te implementeren in MySQL, besloot Percona hun implementaties af te schrijven ten gunste van de implementatie van upstream. Dit verminderde de hoeveelheid code die verschilt tussen MySQL en Percona Server, maakt het gemakkelijker om de code van Percona Server te onderhouden en, wat het belangrijkste is, maakt Percona Server 100% compatibel met MySQL.
Dit geldt helaas niet voor MariaDB. MariaDB introduceerde eerst GTID, dat klopt, maar nadat Oracle hun versie van GTID had ontwikkeld, besloot MariaDB bij hun eigen implementatie te blijven. Deze blog is niet de plaats om te beslissen welke implementatie beter is, maar als gevolg daarvan moeten we twee verschillende, incompatibele GTID-systemen beheren - het legt een extra belasting op elke tool die replicatie beheert en vermindert de interoperabiliteit. Vasthouden aan replicatie - groepscommit en parallelle replicatie:zowel Oracle als MariaDB hebben hun eigen implementatie en als je met beide werkt, moet je ze allebei leren om de vereiste afstemming toe te passen - de knoppen zijn anders en werken op een andere manier. Een vergelijkbaar geval is met ondersteuning voor virtuele kolommen - twee verschillende, niet 100% compatibele implementaties die het daardoor niet mogelijk maakten om gemakkelijk gegevens uit MariaDB te dumpen en in Oracle's MySQL te laden (en vice versa) omdat de syntaxis iets anders is. Dus als u besluit een versie van MariaDB te gebruiken voor een geheel nieuwe functie, kunt u er uiteindelijk mee vast komen te zitten, zelfs als u terug wilt migreren naar MySQL om de implementatie van Oracle te gebruiken. In het beste geval zou migratie veel meer inspanning vergen om uit te voeren. Natuurlijk, als u de hele tijd in die ene omgeving blijft, heeft dit geen ernstige gevolgen voor u. Maar zelfs dan zal een gebrek aan compatibiliteit voor u merkbaar zijn, al was het maar terwijl u blogs op internet leest en oplossingen vindt die niet echt van toepassing zijn op uw smaak van MySQL.
Dus, om het samen te vatten:als u geïnteresseerd bent in het behouden van compatibiliteit met MySQL, is Percona Server (of MySQL zelf natuurlijk) waarschijnlijk de beste keuze. Als u geïnteresseerd bent in prestaties, zolang Percona Server is gebouwd op de nieuwste MySQL, is dit misschien de juiste keuze. Natuurlijk wilt u misschien MariaDB benchmarken en kijken of uw werklast niet kan profiteren van enkele optimalisaties die nog steeds uniek zijn voor MariaDB. Operationeel gezien is het waarschijnlijk goed om vast te houden aan een van de omgevingen (Oracle/Percona of MariaDB), afhankelijk van wat voor jou het beste werkt. MySQL of Percona Server hebben het voordeel dat ze vaker worden gebruikt en dat het iets gemakkelijker is om ze te integreren met externe tools (omdat niet alle tools alle MariaDB-functies ondersteunen). Als u baat zou hebben bij een nieuwe en glanzende functie die zojuist in MariaDB is geïmplementeerd, moet u deze overwegen, rekening houdend met mogelijke compatibiliteitsproblemen en mogelijk lagere prestaties.
We hopen dat deze blogpost je wat ideeën heeft gegeven over de verschillende keuzes die we hebben in de MySQL-wereld en verschillende invalshoeken van waaruit je ze kunt vergelijken. Aan het eind van de dag is het jouw taak om te beslissen wat het beste is voor je opstelling. Het is misschien niet gemakkelijk, maar dan moeten we toch dankbaar zijn dat we een keuze hebben en kunnen we kiezen wat het beste voor ons werkt.