MariaDB 10.4 er en nuværende udviklingsgren af MariaDB. For nylig, den 21. maj, blev den tredje udgivelseskandidat (10.4.5) frigivet, hvilket bringer os tættere på den officielle udgivelse. Derfor tænkte vi, at det kunne være en god idé at tage et kig på de nye 10.4-funktioner. Vi vil også dele nogle tanker om et nyligt blogindlæg udgivet af MariaDB Corporation. For information om selve udgivelsen kan du finde alle detaljerne i ændringsloggen for MariaDB 10.4.0.
Ydeevneændringer
Unicode-tegnsæt er typisk langsommere end tegnsæt som latin1, for det meste på grund af deres størrelse. MySQL 8.0 bragte betydelige forbedringer på dette område, og MariaDB 10.4 burde også være mærkbart hurtigere end 10.3 i denne henseende. Det er en ganske vigtig forbedring - folk elsker virkelig at bruge emojis, som kræver, at UTF8 er aktiveret. Noget arbejde er blevet udført i optimizeren - MariaDB 10.4 burde fungere bedre for IN() underforespørgsler, da det nu er muligt at skubbe betingelser ind i materialiserede underforespørgsler.
Start og stop af InnoDB kan tage et stykke tid, afhængigt af mængden af data i redologs. MariaDB 10.4 vil forbedre opstart, lukning og udrensning. Sådanne forbedringer er især vigtige i betragtning af populariteten af hot backup-værktøjer som mariabackup og xtrabackup. Disse værktøjer gennemgår i sidste ende InnoDB-startprocessen fra en uren nedlukning, når de anvender redo-logfiler, derfor bør enhver forbedring på det område reducere den tid, der er nødvendig for at gendanne sikkerhedskopier.
InnoDB-ændringer
MariaDB 10.4 har modtaget en øjeblikkelig DROP COLUMN operation. Det er nu også muligt at omarrangere kolonnerne i tabellen uden at skulle genopbygge den. Vi kan ikke understrege, hvor vigtigt dette er. Du spekulerer måske på, hvad er de mest almindelige operationer, du udfører i produktionsmiljøet? Vi vil sige, at det tilføjer eller fjerner et indeks. En anden mest almindelig operation ville være operationer på kolonnerne - tilføje en ny kolonne og fjerne eksisterende kolonne. Hidtil har den mest almindelige tilgang været at bruge eksterne værktøjer til at udføre jobbet:pt-online-schema-change eller, for nylig, gh-ost. Begge har deres begrænsninger (gh-ost virker for eksempel ikke for Galera Cluster), hvilket kan gøre det umuligt at bruge dem på dit system. Særligt vanskelige er fremmednøgler. Med instant DROP COLUMN (øjeblikkelig ADD COLUMN er allerede tilgængelig), kan en stor del af skemaændringerne udføres ad hoc uden detaljeret planlægning og planlægning, som det skal gøres nu. Det er vigtigt at huske på, at øjeblikkelige ændringer er, hvad vi ønsker at have. Der er ikke-blokerende skemaændringer, som at oprette et indeks, men sådanne operationer udgør en alvorlig udfordring, når replikeringen bruges, da de inducerer replikationsforsinkelse. Selvom operationen kunne have været udført på et live system, foretrækker vi at bruge løsninger som pt-online-schema-change for at holde bedre kontrol over processen.
Dette er ikke den eneste forbedring i, hvordan skemaændringer udføres. MariaDB 10.4 vil drage fordel af hurtigere udvidelse af VARCHAR-kolonner, desuden vil tegnsæt- og sorteringsændringer på ikke-indekserede kolonner være øjeblikkelige.
Generelle ændringer
En af de største ændringer er ændringer i brugerstyringen. Mysql.host-tabellen vil ikke blive oprettet, mysql.user-tabellen er forældet. Brugerkonti og globale privilegier vil blive opbevaret i tabellen mysql.global_priv. Dette er potentielt en alvorlig ændring for alle værktøjerne (inklusive ClusterControl), som har mulighed for at administrere MySQL- og MariaDB-brugere – nye sager skal skrives for at dække brugeradministration i MariaDB 10.4 og fremefter. Selvom vi anerkender, at der er behov for ændringer, hjælper dette bestemt ikke til at vedligeholde værktøjer til både MariaDB og MySQL, hvilket gør værktøjslandskabet endnu mere opdelt, end det allerede er. Når vi taler om brugere, kommer MariaDB 10.4 med en mulighed for udløbende brugeradgangskode. Dette er bestemt et skridt i en god retning - det hjælper med at håndhæve god praksis vedrørende adgangskodehåndtering.
Selvom vi vil dække det mere detaljeret i en separat blog, er vi nødt til at nævne support til Galera 26.4 - MariaDB 10.4 vil drage fordel af en ny Galera-version med funktioner som streaming-replikering eller forbedret SST takket være backup-låse.
Endelig kan du i MariaDB 10.4 indstille sql_mode=MSSQL. Dette er en indledende implementering, men sql_mode=ORACLE var også en indledende implementering på et tidspunkt. Dette viser MariaDBs fokus på virksomhedskunder - hvis Oracle-kunder beslutter sig for at migrere, er det ret sandsynligt, at MariaDB-adoption blandt Microsoft SQL Server også vil vokse, efterhånden som flere funktioner vil blive tilføjet, og migrering bliver mindre af et problem.
MariaDB er en gaffel
For ganske nylig så vi et blogindlæg, der forklarer MariaDBs holdning til InnoDB-ændringer og -kompatibilitet. Essensen er, at MariaDB ikke længere vil fusionere InnoDB-funktioner fra MySQL, fokus vil være på stabiliteten og ydeevneforbedringen udført af MariaDB. Dette betyder grundlæggende, at MariaDB bliver inkompatibel med MySQL. Selvom du tidligere kunne lave den binære opgradering, vil dette ikke være muligt i fremtiden. Selv lige nu kan det være vanskeligt at udføre. Dette øger vigtigheden af værktøjer som mydumper/myloader, da logisk backup vil være den eneste måde at migrere på. Hvad der er godt, MariaDB vil være i stand til at eje stabiliteten af deres InnoDB-gaffel - de skal ikke håndtere problemer introduceret af upstream-udviklere, derfor kan vi forvente, at der bliver introduceret færre fejl.
Ydelsesmæssigt må vi vente på benchmarks, men givet de historiske data kan vi antage, at MariaDB vil være langsommere end MySQL. I tidligere benchmarks, hvad vi typisk ser, er, at ydelsesforøgelsen for MariaDB starter, når nyere InnoDB-version er blevet integreret. Dette vil ikke længere være tilfældet, hvilket får os til at spekulere på, hvordan MariaDB vil klare sig i præstationssammenligningen fra nu af, og om de forbedringer, som MariaDB introducerede, vil være nok til at følge med MySQL 8.0 og andre versioner.
For os brugere betyder alt dette, at MariaDB 10.4 burde være mere stabil end de tidligere udgivelser. Det betyder også, at vi i sidste ende bliver nødt til at lære det interne i to forskellige lagermotorer – især hvis vi bekymrer os om ydeevnen. Dette er langt fra ideelt, men sådan er det. Værktøjer skal designes til at fungere med den ene eller den anden version af InnoDB (eller yderligere arbejde skal tilføjes for at understøtte både MySQL og MariaDB). Vi vil holde øje med, hvordan det vil udvikle sig. Når du tænker på det, er det ikke så overraskende et træk - MariaDB skulle altid tage sig tid til at integrere med nyere InnoDB-version. Med flere og flere inkompatible funktioner tilføjet til MariaDB og store ændringer introduceret i MySQL 8.0, giver det mening at fokusere på at udvikle ny funktionalitet i stedet for at portere inkompatibel InnoDB fra upstream MySQL.
Vi håber, at dette korte blogindlæg gav dig indsigt i ændringer, der vil ramme produktionssystemerne, når du går til MariaDB 10.4.