Tilbage i de dage, hvor nogen sagde MySQL, var der kun MySQL. Du kunne vælge forskellige versioner (4.0, 4.1), men leverandøren var den samme. Dette ændrede sig omkring MySQL 5.0/5.1, da Percona besluttede at frigive deres egen smag af MySQL - Percona Server. Lidt senere sluttede MariaDB sig til MariaDB 5.1, og det sjove (eller forvirringen) steg. Hvilken version skal jeg bruge? Hvad er forskellen mellem MySQL 5.1, Percona Server 5.1 og MariaDB 5.1? Hvilken er hurtigere? Hvilken er mere stabil? Hvilken har overlegen funktionalitet? Med tiden blev dette værre, da flere og flere ændringer blev indført i hver af smagsvarianter. Dette blogindlæg vil være vores forsøg på at opsummere de vigtigste funktioner, der adskiller dem. Vi vil også forsøge at give dig nogle bud på, hvilken smag der kan være den bedste til en given type projekt. Lad os komme i gang.
Oracle MySQL
Det plejede at være MySQL, nu er det upstream. Det meste af udviklingen starter her, hver version fra 5.6 løser nogle interne stridigheder og giver bedre ydeevne. Nye funktioner tilføjes også med jævne mellemrum. MySQL 5.6 bragte os (blandt andre) GTID og en indledende implementering af parallel replikering. Det gav os også mulighed for at udføre de fleste af ALTER'erne på en online måde. Lad os tage et kig på funktionerne i den seneste MySQL-version - MySQL 5.7
Funktioner i MySQL 5.7
En af de store ændringer er ændringer i implementeringsprocessen - i stedet for forskellige scripts, kan du bare køre mysqld --initialize for at sætte MySQL op fra bunden. En anden meget vigtig ændring - parallel replikering baseret på logisk ur. Endelig kan vi bruge parallel replikering i alle tilfælde - uanset om du bruger flere skemaer eller ej. En anden forbedring af replikering er replikering med flere kilder - en 5.7-slave kan have flere mastere - det er en fantastisk funktion, hvis du vil bygge en aggregeringsslave og, lad os sige, kombinere data fra flere, separate klynger.
InnoDB begyndte at understøtte rumlige typer, InnoDB-bufferpuljen kan endelig ændres ved kørsel, online ALTERs er blevet forbedret til at understøtte flere tilfælde som partitionering og no-op ALTERs.
MySQL begyndte at understøtte JSON-datatyper indbygget sammen med flere nye funktioner, som er fokuseret på at tilføje funktionalitet omkring JSON. Sikkerheden af dine data er meget vigtig i disse dage, MySQL 5.7 understøtter data-at-rest-kryptering til file-per-table tablespaces. Nogle forbedringer er også blevet tilføjet til SSL-understøttelse (SSL vil blive konfigureret, hvis nøgler er på plads, et script er inkluderet, som kan bruges til at oprette certifikater). Fra et brugeradministrationsperspektiv er der tilføjet en opsætning af adgangskodelivstid, hvilket burde gøre designet af politikker for udløb af adgangskode en smule lettere.
En anden funktion, som er beregnet til at hjælpe DBA'er, er 'sys'-skemaet, et sæt visninger designet til at gøre det nemmere at bruge Performance Schema. Det er som standard inkluderet i MySQL 5.7.
Endelig er MySQL Group Replication (og i sidste ende MySQL InnoDB Cluster) blevet tilføjet til MySQL 5.7. Det fungerer som et plugin og er inkluderet i nyere versioner af 5.7-grenen, men det er et emne for sig selv. Kort sagt giver gruppereplikering dig mulighed for at bygge en "stort set" synkron klynge.
Dette er bestemt ikke en komplet liste over funktioner - hvis du er interesseret i dem alle, kan du se MySQL 5.7-dokumentationen.
Percona Server
I begyndelsen var der et sæt patches til at anvende på MySQL-kildekoden, som tilføjede nogle forbedringer af ydeevne og funktionalitet. På et tidspunkt besluttede Percona at frigive deres egen build af MySQL, som inkluderede disse patches. Med tiden blev flere udviklingsressourcer tilgængelige, så flere og flere funktioner er blevet tilføjet.
Generelt kan du se Percona Server som den nyeste MySQL-version med flere patches/forbedringer. Med tiden bliver nogle af Percona Server-funktionsforbedringerne erstattet af funktioner fra upstream - hver gang Oracle udvikler en funktion, der erstatter en af de funktioner, der er tilføjet i Percona Server. Så længe implementeringen er på niveau, fjerner Percona deres egen kode til fordel for kode fra upstream. Dette gør Percona Server grundlæggende til en drop-in-erstatning for Oracles MySQL. Et af de områder, hvor der er foretaget store præstationsforbedringer, er InnoDB. Det er blevet ændret betydeligt nok til at mærke det som XtraDB. I øjeblikket er det fuldt kompatibelt med InnoDB, men det har ikke altid været sådan. For eksempel var nogle funktioner i Percona Server 5.5 ikke kompatible med MySQL 5.5. Det gælder også for nyere Percona Server-versioner. Det, der er vigtigt, er, at Percona Server som standard kommer med alle inkompatible funktioner deaktiveret - det gør det nemt at teste det og rulle tilbage til Oracles MySQL, hvis det er nødvendigt. Når du tager alt ovenstående i betragtning, bør du stadig udvise forsigtighed, når du planlægger at migrere fra Percona Server til MySQL - nogen har muligvis aktiveret en af de inkompatible funktioner.
Det, der er værd at fremhæve, er, at Percona stræber efter at genimplementere virksomhedens funktioner i upstream. I tilfælde af MySQL er eksempler implementering af en trådpool eller PAM-godkendelsesplugin. Lad os tage et hurtigt kig på nogle af funktionerne i Percona Server.
Funktioner i Percona Server 5.7
En af hovedfunktionerne ved XtraDB er forbedret skalerbarhed i bufferpuljen - selvom der er mindre og mindre uenighed på grund af det arbejde, Oracle udfører på hver MySQL-version, stræber Perconas ingeniørteam efter at skubbe ydeevnen endnu længere og fjerne yderligere mutexes, som kan begrænse ydeevnen. Derudover skrives flere data ind i InnoDB monitor (tilgængelig via SHOW ENGINE INNODB STATUS) vedrørende påstande inden for InnoDB - f.eks. er der tilføjet et afsnit om semaforer.
Et andet sæt forbedringer er blevet foretaget inden for I/O-området. I InnoDB kan du kun indstille en flush-metode for InnoDB-tablespaces, og dette forårsager dobbeltbuffring for InnoDB-redo-logfiler. XtraDB gør det muligt at bruge O_DIRECT også til disse filer. Det tilføjer også flere data vedrørende checkpointing til outputtet af SHOW ENGINE INNODB STATUS. Derudover er parallel dobbeltskrivningsbuffer og multi-threaded LRU flusher blevet implementeret for at reducere konflikter i I/O-operationer i InnoDB.
Trådpulje er en anden funktion, der stilles til rådighed af Percona Server. I Oracle MySQL er det kun tilgængeligt i Enterprise-udgaven. Her kan du bruge Perconas implementering gratis. Generelt reducerer trådpuljen stridigheder, mens det betjener et stort antal forbindelser fra applikationen ved at genbruge eksisterende forbindelser til databasen.
Yderligere to funktioner er direkte erstatninger af funktioner fra Enterprise-versionen af MySQL. En af dem er PAM-godkendelses-pluginet, som er udviklet af Percona og er designet til at tillade brugen af masser af forskellige godkendelsesmuligheder som LDAP, RSA SecurID eller andre metoder, der understøttes af PAM. Anden funktion er også relateret til sikkerhed - audit log plugin. Det vil oprette en fil med en registrering af handlinger udført på databaseserveren.
Fra tid til anden introducerer Percona betydelige forbedringer til andre lagringsmotorer, som f.eks. de ændringer, de lavede i MEMORY-motoren, som gjorde det muligt at bruge data af typen VARCHAR eller BLOB.
Introduktion af backup-låse var også en ret væsentlig forbedring. I Oracle og MariaDB var den eneste metode til at låse tabellen for at få en konsistent backup at bruge FLUSH TABELLER MED READ LOCK (FTWRL). Det er ret tungt, og det tvinger MySQL til at lukke alle de åbne borde. Backup-låse bruger på den anden side en mere let tilgang til metadatalåse. I mange tilfælde, hvor tungt belastede servere, der kører FTWRL, tager det for lang tid (og låser serveren for længe) til at blive betragtet som muligt, mens backup-låse gør det muligt at tage en backup ved hjælp af mysqldump eller xtrabackup.
Percona er også åben for porteringsfunktioner fra andre leverandører. Et sådant eksempel er port af MariaDB's START TRANSAKTION MED KONSISTENT SNAPSHOTS. Denne funktion er også relateret til sikkerhedskopier - med dens hjælp kan du tage en konsekvent logisk backup (ved hjælp af mysqldump) uden at køre FLUSH TABLE MED LÆSELÅS.
Til sidst tre funktioner, der forbedrer observerbarheden - først:brugerstatistik. Dette er en ret let funktion, som indsamler data om brugere, indekser, tabeller og tråde. Det giver dig mulighed for at finde ubrugte indekser eller bestemme, hvilken bruger der er ansvarlig for belastningen på serveren. I øjeblikket er det delvist overflødigt for performance_schema, men det er en smule lettere, og det blev skabt i MySQL 5.0 - 5.1 dage, hvor ingen engang drømte om performance_schema.
Andet - forbedret langsom forespørgselslog. Igen blev det tilføjet i tider, hvor den højeste granularitet af long_query_time var 1 sekund. Med denne tilføjelse havde du mikrosekundgranularitet og en masse yderligere data om InnoDB-statistik pr. forespørgsel eller dens overordnede ydeevnekarakteristika. Oprettede det en midlertidig tabel? Brugte den et indeks? Er den blevet cachelagret i MySQL-forespørgselscachen?
Tredje funktion vi nævnte et par gange ovenfor - Percona Server eksponerer betydeligt flere data i SHOW ENGINE INNODB STATUS end upstream. Det hjælper helt sikkert med at forstå arbejdsbyrden yderligere og fange flere problemer, før de udfolder sig.
Dette er selvfølgelig ikke en komplet liste - hvis du er interesseret i flere detaljer, kan du tjekke Percona Servers dokumentation.
MariaDB
MariaDB startede som en forgrening af MySQL, men med en del af det originale MySQL-udviklingsteam, der sluttede sig til MariaDB, fokuserede det hurtigt på at tilføje funktioner. I MariaDB 5.3 var masser af funktioner blevet tilføjet til optimeringsværktøjet:Batch Key Access, MultiRange Read, Index Condition Pushdown for at nævne nogle få. Dette gjorde det muligt for MariaDB at udmærke sig i nogle arbejdsbelastninger, hvor MySQL eller Percona Server ville kæmpe. Indtil nu er nogle af disse funktioner blevet tilføjet til MySQL (for det meste i MySQL 5.6), men nogle er stadig unikke for MariaDB.
En anden vigtig funktion, som blev introduceret af MariaDB, var Global Transaction ID. Ikke så meget senere udgav Oracle sin egen implementering, men MariaDB var den første til at have den. Lignende historie er med en anden replikeringsfunktion - multisource-replikering:MariaDB havde det før Oracle. Nu indeholder nyligt udgivet MariaDB 10.2 også funktioner, som vil blive gjort tilgængelige i MySQL 8.0, som stadig er under udvikling. Vi taler for eksempel om rekursive almindelige tabeludtryk eller vinduesfunktioner.
Funktioner i MariaDB 10.2
Som vi nævnte, introducerer MariaDB 10.2 vinduesfunktioner og rekursive almindelige tabeludtryk - forbedringer i SQL, som skulle hjælpe udviklere med at skrive mere effektive SQL-forespørgsler.
Meget vigtig ændring er, at MariaDB 10.2 bruger InnoDB. Op til 10.1 er XtraDB blevet brugt som standardlager. Dette gør desværre funktioner tilføjet i seneste XtraDB utilgængelige for MariaDB 10.2-brugere.
Der er foretaget forbedringer i virtuelle kolonner - flere begrænsninger er blevet ophævet i 10.2.
Endelig er der tilføjet understøttelse af flere triggere for samme begivenhed - nu kan du oprette flere, for eksempel ON UPDATE-triggere på samme bord.
Udviklere bør drage fordel af JSON-understøttelse sammen med et par funktioner, der er relateret til det. De burde også kunne lide nye funktioner, som giver dem mulighed for at eksportere geografiske data til GeoJSON-format. Når vi taler om JSON, er der foretaget forbedringer i EXPLAIN FORMAT=JSON output - flere data vises.
På sikkerhedsfronten er understøttelse af OpenSSL 1.1 og LibreSSL blevet tilføjet.
Selvfølgelig er denne liste ikke komplet, og hvis du er interesseret i, hvad der er blevet tilføjet til MySQL 10.2, kan du eventuelt konsultere dokumentationen.
Ud over nye funktioner drager MariaDB 10.2 fordele af funktioner implementeret i tidligere versioner. Vi gennemgår de vigtigste.
De vigtigste funktioner i MariaDB 10.1
Først og fremmest kommer MariaDB siden 10.1 bundtet med Galera cluster - ingen grund til at installere yderligere biblioteker, alt er klar til brug.
MariaDB 10.1 bragte implementering af data-at-rest-kryptering. Sammenlignet med funktionen implementeret i Oracles MySQL, har MariaDB den mere udvidet. Det krypterer ikke kun tablespaces, men det krypterer også redo-logfiler, midlertidige filer og binære logfiler. Dette kommer med nogle problemer - CLI-værktøjer som mysqldump eller xtrabackup kan ikke få adgang til binære logfiler og kan have problemer med at sikkerhedskopiere krypterede instanser (dette gælder især for xtrabackup - for ganske nylig oprettede MariaDB xtrabackup-gaffel kaldet MariaDB Backup, som understøtter data-at-rest kryptering).
Ok, så hvilken smag skal jeg bruge?
Som det plejer at være, ville det rigtige svar være:"Det afhænger af" :-) . Vi vil dele et par af vores observationer, som måske eller måske ikke hjælper dig med at beslutte, men i sidste ende er det op til dig at køre benchmarks og finde den mulighed, der fungerer bedst for dit miljø og din applikation.
Først og fremmest, lad os tale om flowet. Oracle frigiver ny version - lad os sige MySQL 5.7. Ydelsesmæssigt er dette i det øjeblik den hurtigste MySQL-smag på markedet. Dette skyldes, at kun Oracle har ressourcer nok til at arbejde på at forbedre InnoDB i den grad. Inden for et par måneder (i tilfælde af 5.7, var det 4 måneder) frigiver Percona Percona Server 5.7 med deres sæt af forbedringer - afhængigt af typen af arbejdsbyrde, kan den levere endnu bedre ydeevne end upstream. Endelig adopterer MariaDB ny upstream-version og bygger sin nye version oven på den.
Sådan så det ud i en kalender (vi taler stadig om MySQL 5.7).
MySQL 5.7 GA:21. oktober 2015
Percona Server 5.7 GA:23. februar 2016
MariaDB 10.2 GA:23. maj 2017
Bemærk venligst, hvor lang tid det tog MariaDB at frigive en version baseret på MySQL 5.7 - alle tidligere versioner har været baseret på MySQL 5.6 og har naturligvis leveret en ydeevne lavere end MySQL 5.7. På den anden side er MariaDB 10.2 blevet frigivet med InnoDB, der erstatter XtraDB. Selvom det er rigtigt, at Oracle for det meste lukkede ydeevnegabet mellem MySQL og Percona Server, er det stadig bare "for det meste". Som følge heraf kan MariaDB 10.2 i nogle tilfælde levere lavere ydeevne end Percona Server (og bedre i nogle andre tilfælde - på grund af optimeringsarbejde udført i MariaDB 5.3, hvoraf nogle endnu ikke er blevet genskabt i MySQL).
Funktionsmæssigt er det mere komplekst. MariaDB har tilføjet masser af funktioner, så hvis du er interesseret i nogle af dem, kan du helt sikkert overveje at bruge MariaDB. Der er også en ulempe ved det. Percona Server havde en hel del funktioner, der adskiller den fra upstream MySQL, men da Oracle begyndte at implementere dem i MySQL, besluttede Percona at afskrive deres implementeringer til fordel for at bruge implementeringen fra upstream. Dette reducerede mængden af kode, der er forskellig mellem MySQL og Percona Server, gør det nemmere at vedligeholde Percona Servers kode og, hvad der er det vigtigste, gør Percona Server 100 % kompatibel med MySQL.
Dette er desværre ikke sandt for MariaDB. MariaDB introducerede GTID først, det er sandt, men efter at Oracle udviklede deres version af GTID, besluttede MariaDB at holde fast i deres egen implementering. Denne blog er ikke stedet for at beslutte, hvilken implementering der er bedre, men som et resultat er vi nødt til at administrere to forskellige, inkompatible GTID-systemer - det tilføjer en byrde på ethvert værktøj, der styrer replikering og reducerer interoperabilitet. Hold dig til replikering - gruppeforpligtelse og parallel replikering:både Oracle og MariaDB har deres egen implementering, og hvis du arbejder med dem begge, skal du lære dem begge for at anvende den nødvendige tuning - knapperne er forskellige og fungerer på en anden måde. Tilsvarende tilfælde er med understøttelse af virtuelle kolonner - to forskellige, ikke 100% kompatible implementeringer, som som et resultat gjorde det ikke muligt nemt at dumpe data fra MariaDB og indlæse i Oracles MySQL (og omvendt), fordi syntaksen er lidt anderledes. Så hvis du beslutter dig for at bruge en version af MariaDB til en helt ny funktion, kan du ende med at sidde fast med den, selvom du gerne vil migrere tilbage til MySQL for at bruge Oracles implementering. I bedste fald ville migration kræve meget mere indsats at udføre. Selvfølgelig, hvis du opholder dig i det ene miljø hele tiden, kan det selvfølgelig ikke påvirke dig alvorligt. Men selv da vil en mangel på kompatibilitet være mærkbar for dig, om ikke andet så mens du læser blogs på internettet og finder løsninger, der ikke rigtigt passer til din smag af MySQL.
Så for at opsummere det - hvis du er interesseret i at bevare kompatibilitet med MySQL, ville Percona Server (eller MySQL selv selvfølgelig) nok være vejen at gå. Hvis du er interesseret i ydeevne, så længe der er Percona Server bygget oven på den nyeste MySQL, kan det være vejen at gå. Selvfølgelig vil du måske benchmarke MariaDB og se, om din arbejdsbyrde ikke kan drage fordel af nogle af de optimeringer, som stadig er unikke for MariaDB. Driftsmæssigt er det nok godt at holde sig til et af miljøerne (Oracle/Percona eller MariaDB), alt efter hvad der ville fungere bedst for dig. MySQL eller Percona Server har en fordel på en måde, at de er mere almindeligt anvendte, og det er lidt nemmere at integrere dem med eksterne værktøjer (fordi ikke alle værktøjerne understøtter alle MariaDB-funktionerne). Hvis du ville drage fordel af en ny og skinnende funktion, som netop er blevet implementeret i MariaDB, bør du overveje det, mens du husker på eventuelle kompatibilitetsproblemer og mulig lavere ydeevne.
Vi håber, at dette blogindlæg gav dig nogle ideer om forskellige valg, vi har i MySQL-verdenen, og forskellige vinkler, hvorfra du kan sammenligne dem. I slutningen af dagen vil det være din opgave at beslutte, hvad der er bedst for dit setup. Det er måske ikke nemt, men så bør vi stadig være taknemmelige for, at vi har et valg, og vi kan vælge det, der fungerer bedst for os.