#69 MySQL vs. MariaDB

Wie viel MySQL Drop In-Replacement steckt wirklich in MariaDB?

MariaDB, ein Fork der populären Datenbank MySQL. Angetreten, um ein Drop-In-Replacement und eine direkte Alternative zu MySQL darzustellen. Doch wie viel ist da dran? Ist MariaDB MySQL kompatibel? Wo liegen die Gemeinsamkeiten und Unterschiede? Was war eigentlich der Grund für den Fork? In welchen Bereichen entwickeln sich beide Datenbanken vollkommen anders? Und was hat sich im Bereich der Storage-Engines alles so getan?

In dieser Episode bringen wir etwas Licht in den direkten Vergleich zwischen MySQL und MariaDB.

Bonus: Was ein Weber-Grill mit MySQL und MariaDB zu tun hat.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Links

MySQL 8.0 Release Notes: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/
InnoDB Storage Engine: https://de.wikipedia.org/wiki/InnoDB
MariaDB: https://mariadb.org/
MySQL-Server Source-Code: https://github.com/mysql/mysql-server
FOSDEM: https://fosdem.org/
MyRocks: http://myrocks.io/
Galera Cluster: https://galeracluster.com/
Vitess: https://vitess.io/
PlanetScale: https://planetscale.com/
MySQL: https://www.mysql.com/de/
Ranking bei DB-Engines: https://db-engines.com/de/ranking/relational+dbms
MySQL AB: https://en.wikipedia.org/wiki/MySQL_AB
MySQL InnoDB memcached Plugin: https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html
Michael "Monty" Widenius: https://de.wikipedia.org/wiki/Michael_Widenius
Wolfi’s non-blocking MySQL und MariaDB Backup Docker Image https://wolfgang.gassler.org/docker-image-mysql-mariadb-backups/
Percona: https://www.percona.com/
RocksDB: https://rocksdb.org/
LevelDB: https://github.com/google/leveldb
MariaDB - Choosing the Right Storage Engine: https://mariadb.com/kb/en/choosing-the-right-storage-engine/
ProxySQL: https://proxysql.com/
Engineering Kiosk #64 Infrastruktur-Bingo: Forward-, Reverse-, SOCKS-Proxy, Load Balancing und gibt es einen Unterschied zwischen Load-Balancer und Reverse-Proxy?: https://engineeringkiosk.dev/podcast/episode/64-infrastruktur-bingo-forward-reverse-socks-proxy-load-balancing-und-gibt-es-einen-unterschied-zwischen-load-balancer-und-reverse-proxy/
MySQL Clone Plugin: https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html
MySQL Generated Columns: https://dev.mysql.com/doc/refman/5.7/en/create-table-generated-columns.html
Incompatibilities and Feature Differences Between MariaDB 10.7 and MySQL 8.0: https://mariadb.com/kb/en/incompatibilities-and-feature-differences-between-mariadb-10-7-and-mysql-8-/
MariaDB ColumnStore: https://mariadb.com/kb/en/mariadb-columnstore/

Sprungmarken

(00:00:00) Intro

(00:00:58) Wetter, Zecken in der Software-Engineering und die MySQL OpenSource Community

(00:06:11) Was ist InnoDB und das MySQL Changelog

(00:08:37) MySQL vs. MariaDB - Ein Drop-In-Replacement?

(00:10:43) Was ist eigentlich MySQL und was ist MariaDB?

(00:14:15) Wo kommt MySQL und MariaDB eigentlich her?

(00:22:26) MariaDB ist kein volles Drop-In-Replacement für MySQL

(00:25:51) Der SQL Standard bei MySQL und MariaDB

(00:29:47) Storage Engines und Object-Storage

(00:39:09) Replikation zwischen MySQL und MariaDB und Traffic auf andere Datenbanken spiegeln

(00:45:52) Ist MariaDB performanter als MySQL?

(00:48:32) Aussprache von MySQL

(00:50:37) Einfachheit und Konfigurationsmöglichkeit

(00:52:44) Die Liste von Inkompatibilitäten wird länger und Traffic spiegeln

(00:57:20) Version Scheme von MySQL und MariaDB

(00:58:41) Welchen Grund gibt es für MySQL bei einem neuen Projekt?

(01:03:42) Mögliche MariaDB Lizenz-Änderung und UUID-Datentyp

(01:04:54) Feature-Support von Vitess

(01:10:03) Logo von MariaDB

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:01:08)

Es gab mal eine Zeit, da ist ein Milliardenkonzern aus Austin, Texas mit dem Namen Oracle auf Shoppingtour gegangen. Man dachte sich, och lass uns doch mal Sun Microsystems kaufen. Mit dem Deal ging nicht nur die Programmiersprache Java an Oracle, sondern auch eine kleine Datenbank namens MySQL. Der Hauptentwickler, Monty, fand dies alles andere als lustig und hat in keinster Weise an Oracles Open Source Philosophie geglaubt. Da hat er direkt Nägel mit Köpfen gemacht und MySQL geforkt. MariaDB wurde geboren. Angetreten als MySQL Drop-In Replacement. Doch wie viel ist davon noch übrig? Wo ist MariaDB mit der MySQL Kompatibilität treu geblieben? Und in welchen Bereichen ist die Datenbank ihren eigenen Weg gegangen? Was gibt es Neues im Bereich Storage Engines? In dieser Episode schauen wir uns das Original und den Fork mal genauer an. Und nun zum Wetter. Wolfgang, ich hörte die Tage in den Nachrichten, dass das Wetter wieder verrückt spielt und in Tirol es um Ostern oder kurz nach Ostern wieder Schnee gab.

Wolfi Gassler (00:01:08 - 00:01:14)

Es ist schon ziemlich deutsch, über das Wetter zu reden und ein Podcast mit dem Wetter einzuleiten. Aber ja, wir hatten Schnee, ja klar.

Andy Grunwald (00:01:14 - 00:01:24)

Hast du die Chance nochmal genutzt und bist auf die Berge gegangen oder hast du dich zu Hause verkrochen, weil du dich schon für den Frühling eingestellt hast und hast dich wieder über irgendeinen Bug bei irgendeinem Side-Project aufgeregt?

Wolfi Gassler (00:01:24 - 00:01:41)

Ja, es war ja nicht so, dass ich mich im Winter über keine Bugs aufregen würde. Also die Bugs sind im Winter und im Sommer da. Bugs sind leider immer da, wobei jetzt Zecken schon sehr früh da sind. Also die globale Erdbeerwärmung merkt man extrem, dass die Zecken schon wieder da sind, wenn wir schon von Bugs sprechen.

Andy Grunwald (00:01:41 - 00:01:48)

Was ist denn die Zecke im Software Engineering? Ist das ein Datenverlust bei einer Datenbank oder ist das auch noch ein Bug? Also was ist die Zecke?

Wolfi Gassler (00:01:49 - 00:01:57)

Vielleicht ist es so ein Hackerangriff. Die Zecke saugt dir Blut, der Hacker saugt vielleicht Daten aus der Datenbank. Würde es mal mit einem Hackerangriff vergleichen.

Andy Grunwald (00:01:57 - 00:02:22)

Ich hab mich die Tage wieder über was aufgeregt, wo ich jetzt nicht weiß, ob das jetzt ein Bug oder schon eine Zecke ist oder vielleicht irgendwie so ein kleiner Käfer, der so eine kleine Larve, die noch wirklich zu einem Bug wird oder so. Auf jeden Fall habe ich die Tage erst festgestellt, dass es um MySQL eigentlich gar keine Open-Source-Community mehr gibt, weil ich herausgefunden habe, wie Pull-Requests bei MySQL funktionieren.

Wolfi Gassler (00:02:23 - 00:02:38)

Also ich finde es immer gut wie du am anfang sowas ganz provokantes sagen kannst es gibt keine opensource community mehr bei mysql aber bin mal gespannt warum gibt es keine community mehr was hat das zu tun mit dem bugreporting und hast du den bugreported, viel spannender.

Andy Grunwald (00:02:38 - 00:02:52)

Ich selbst habe keinen Bug reported, aber ein Kollege hat ein bisschen den MySQL-Source-Code gelesen und hat dabei einen Tippfehler gefunden. Und den wollten wir erst mal fixen. Einfach nur, um zu sehen, wie kontributiert man eigentlich zu MySQL.

Wolfi Gassler (00:02:52 - 00:02:54)

Gar nicht, würde ich sagen, oder?

Andy Grunwald (00:02:54 - 00:04:36)

Genau, aktuell ist es grad gar nicht. Was passiert ist, du machst was auf GitHub auf, dann hast du den CLR, das Contributor License Agreement unterzeichnet, dann machst du das. Und dann kommt irgendein Bot vorbei, der nimmt sich den Patch, kopiert den irgendwo nach Oracle intern und fließt dann in den PR. Und du hast halt einfach gar keine Rückmeldung, du weißt halt nicht, was passiert damit. Und dann hast du ja entweder Glück oder nicht Glück, ob sich das wer anschaut. Und zugegeben, die heftige Aussage, dass es gar keine Open-Source-Community um MySQL gibt, ist vielleicht ein bisschen drastisch. Ich würde es dann vielleicht eher ein bisschen zurückziehen und so formulieren, dass die Open-Source-Communities, die ich so kenne, die gibt es bei MySQL nicht, weil Pull-Requests werden ja nicht wirklich gut gehandhabt. eine richtige Issue-Tracker-Diskussion gibt's halt vielleicht schon noch, aber es gibt ja auch zwei Bug-Tracker, also einmal den auf bugsmysql.com und dann einmal einen Oracle-Internen. Und wenn du dir das MySQL-Change-Log mal ansiehst, und das ist für mich eine richtige Zecke jetzt, nenn mir mal eine Person, die du persönlich kennst, die das MySQL-Changelog vorsteht. Also du machst dir das auf und dann hast du Changelog-Entries, so wie eigentlich in jedem Changelog, alles super. Und jeder Changelog-Entry hat eine Bug-Ticket-ID. Aber du kannst auf diese Bug-Tickets nicht zugreifen, weil die Bug-Ticket-IDs von einem Oracle-Intern-Bug-Tracker sind, das ist die erste Baustelle. Die zweite Baustelle, die Changelog-Entries, Wenn du jetzt kein Storage-Engine-Engineer bist, dann sind die gar nicht mal so einfach zu verstehen, weil dann steht da ab und zu fix InnoDB-Crash, wenn irgendwas, was ich noch nie in meinem Leben gehört habe, zutrifft.

Wolfi Gassler (00:04:36 - 00:04:55)

Aber auch wenn du jetzt mehr Informationen hättest, ich mein, diese gefixten Bugs sind ja wirklich für Storage-Entwickler, Storage-Engine-Entwickler. Weil du kannst ja mit dem gar nichts anfangen, oder? Also ist schon klar, dass es natürlich schön wäre, um da mehr Einblick zu bekommen und so weiter. Aber die sind natürlich allgemein schwierig zu verstehen, weil so Storage-Engines sind einfach komplexe Dinge.

Andy Grunwald (00:04:56 - 00:05:38)

Naja, also erstmal gehe ich stark davon aus, dass dann bei Datenbanken ein Unit-Test hinzugefügt wird. Oder es von außen irgendeinen Use-Case gibt, wie du den Bug triggerst. Also unter welchen Umständen. Wenn ich irgendeinen Datensatz schreibe, wenn ich irgendeinen Datensatz schreibe mit fünf Emojis drin, wenn ich das und das habe. Keine Ahnung. Also das bedeutet diese fehlende Transparenz hindert mich ja blockiert mich ja überhaupt mehr oder weniger storage engine entwickler zu werden weil ich kann darüber ja nicht lernen, nicht dass ich das jetzt vor hätte aber es ist es finde es halt unglaublich interessant da mal reinzuschauen über themen die ich mich ja gar nicht auskenne und die zweite geschichte ist weswegen ich mich da eigentlich so darüber aufrege, Ich arbeite ja bei einem Datenbank-As-a-Service-Provider.

Wolfi Gassler (00:05:38 - 00:05:43)

Genau, warum verwendet ihr kein MariaDB, ist meine Frage. Warum verwendet ihr denn überhaupt MySQL?

Andy Grunwald (00:05:43 - 00:06:10)

Die Entscheidung wurde getroffen, bevor ich dort angefangen habe. Aber wenn man natürlich eine ganze Menge an Datenbanken für Kunden hostet und natürlich auch MySQL, dann sage ich dir, dann stolpert man auch über InnoDB-Data-Corruption-Bugs. Und wenn ich jetzt, zugegeben, ich arbeite nicht am MySQL-Produkt in unserer Firma, Aber ich würde trotzdem gerne wissen, ob das nächste Release diesen Bug, den wir hatten, gefixt hat.

Wolfi Gassler (00:06:11 - 00:06:18)

Was ist denn überhaupt InnoDB? Für alle, die jetzt keine MySQL-User sind oder vielleicht keine Hardcore-User sind, was ist denn InnoDB?

Andy Grunwald (00:06:18 - 00:06:28)

InnoDB ist eine, und jetzt gerade soviel ich weiß, die aktuelle Default-Storage-Engine von MySQL. Vorher war es, glaube ich, MyISM, aber.

Wolfi Gassler (00:06:28 - 00:06:35)

Seit Version... Ja, schlag mich tot, seit Ewigkeiten, seitdem ich was denken kann. Ja, okay, das stimmt nicht ganz, aber es ist schon relativ alt.

Andy Grunwald (00:06:35 - 00:07:13)

Es ist auf jeden Fall eine der Storage Engines. Na ja, auf jeden Fall denke ich, auf diesem Planeten, ich glaub, ich hab das schon mal im Podcast genannt, gibt es ungefähr, ich glaube, drei Firmen, beziehungsweise die Datenbankteams dieser Firmen, die das MySQL-Chain-Schlupf verstehen. Und zwar ist das einmal Oracle selbst, dann wird's mit hoher Wahrscheinlichkeit Pekona sein, und mit sehr hoher Wahrscheinlichkeit noch die Damen und Herren von PlanetScale, was dann eigentlich die Datenbankteams von Booking und GitHub damals ist. Also, ich glaub, diese ... Drei Firmen, beziehungsweise diese Teams, die sich um die Datenbanken kümmern. Ich glaub, die Leute verstehen ... Und noch vielleicht die Jungs um MariaDB.

Wolfi Gassler (00:07:13 - 00:07:28)

Wollt ich grad sagen, wollte ich gerade unterbrechen, wenn du MariaDB vergisst. Es gibt, glaub ich, auch ganz viele andere. Es gibt auch Facebook zum Beispiel. Facebook hat eine interne MySQL am Start. Und die verstehen garantiert auch extrem viel interner. Kann ich dir garantieren.

Andy Grunwald (00:07:29 - 00:07:45)

Du stimmst mir aber schon zu, dass das echt doof ist, oder? Also, intern ne Bugtracker und dann gar nicht so ne richtigen Paragrafen pro Changelog-Engine zu haben. Ich würd mir da schon was anderes wünschen. Besonders auch für MySQL, die dir auch kommerziell angeboten wird, wo ja Oracle auch Geld mitverdient und allem Drum und Dran.

Wolfi Gassler (00:07:46 - 00:08:36)

Ich glaube, man muss auch einfach dazu sagen, dass diese Datenbankwelt eine andere Welt ist und da will ich jetzt gar nicht Oracle in Schutz nehmen, aber wenn du mal so durch den Source Code schaust, MariaDB, MySQL, wenn du die Webseiten betrachtest, das Design, das ist einfach eine andere Welt und das fühlt sich so richtig 90er an. Und sogar wenn du zum Beispiel auf der FOSDEM in so einem MySQL-Devroom bist und die Folien anschaust, dann denkst du dir auch, um Gottes Willen habe ich jetzt einen Foliensatz aus den 90ern erwischt, da steht nur irgendwie großer Text oben, kein Design, keine Farbe, nichts. Also das ist einfach eine andere Welt und ich glaube auch, dass sich da recht viel auswirkt auf eben genau die Art, wie man Open Source lebt und wie das gemacht wird. Aber ich glaube bei MariaDB ist es natürlich wesentlich besser, muss man schon auch sagen.

Andy Grunwald (00:08:36 - 00:08:52)

Aber bevor wir jetzt hier weiter einsteigen, wir sind genau beim Thema und zwar heute geht es um den Kampf der Giganten. MySQL versus MariaDB. Ich könnte auch so einen journalistischen Podcast machen, merke ich gerade.

Wolfi Gassler (00:08:52 - 00:09:02)

Okay, aber warum sprechen wir über MySQL und MariaDB? Weil du hast mir noch vor ein paar Tagen erklärt, das ist sowieso nur ein Drop-In Replacement MariaDB und es ist alles selber und warum müssen wir da eine Episode drauf machen?

Andy Grunwald (00:09:02 - 00:09:08)

Weil von dir eine Antwort kam, mit der ich eigentlich gar nicht gerechnet habe. Du hast gesagt, was? Das stimmt ja gar nicht.

Wolfi Gassler (00:09:08 - 00:09:09)

Das müssen wir ändern.

Andy Grunwald (00:09:10 - 00:09:20)

Mache ich so, ja Moment, aber das ist doch, was da immer kommuniziert wurde. Du hast nochmal SQL, dann gibt es da jetzt einen Fork, nennt sich MariaDB, Drop-In-Replacement und weiter geht's.

Wolfi Gassler (00:09:20 - 00:10:43)

Also grundsätzlich stimmt das mal nicht und dann gibt es ja auch noch den Bacona Server, dann gibt es mittlerweile MyRocks, dann gibt es Cluster-Varianten, Bacona, ExtraDB Cluster, Galera Cluster, dann gibt es die ganzen Cloud-Varianten, RDS von AWS, Cloud SQL, sogar Azure hat eine MySQL-Variante. Dann gibt es Planetscale, Vitesse, also dieses Spektrum kann man fast endlos fortführen und nachdem es so viele Lösungen gibt, kann ich dir jetzt schon garantieren, es gibt Unterschiede, weil sonst gäbe es die ganzen Lösungen nicht, wenn es ja alles nur MySQL wäre. Auch wenn man das oft so sieht, aber es ist mittlerweile nicht nur mehr im Detail, sondern sogar teilweise gibt es sehr, sehr, sehr große Unterschiede. Und mir geht es selber so, obwohl ich mich eigentlich, würde ich mal sagen, in dem ganzen Space doch ganz gut auskenne, renne ich selbst immer wieder an irgendwelche Wände. Und ich habe kürzlich in einem Projekt Planet Scale eingesetzt, wo im Hintergrund Vitesse läuft. Und es war echt schwierig. Auch ein anderer Entwickler hat mir regelmäßig irgendwelche Errors gesendet. Diese Query funktioniert nicht und das, was du mir da geschickt hast, funktioniert schon wieder nicht. Und da merkt man erst, wie groß eigentlich die Unterschiede sind und wie viele Probleme es gibt, die man am Anfang vielleicht gar nicht erkennt, weil man halt der Marketing-Webseite traut. Das ist ein MySQL quasi Drop-in-Replacement und alles funktioniert. Und wenn man das Ganze dann anwendet, sieht man erst, wie groß die Unterschiede sind und in welche Probleme man da hineinläuft.

Andy Grunwald (00:10:43 - 00:10:51)

Aber für alle Leute, die jetzt nicht so viel im Web-Umfeld unterwegs sind, beziehungsweise in der Datenbankwelt, Ich wollte gerade sagen.

Wolfi Gassler (00:10:51 - 00:10:57)

Beleidigt nicht die ganze Datenbank-Welt. Ich glaube, MySQL ist viel weiter verbreitet als nur im Web unter Anführungszeichen.

Andy Grunwald (00:10:58 - 00:11:17)

Ja, aber ich kann mir auch schon vorstellen, dass viel außerhalb des Webs eher so Postgre und so weiter genutzt wird. Wolfgang, fass mir doch mal bitte in zwei Sätzen zusammen, wirklich super high-level, was ist eigentlich MySQL und was ist eigentlich MariaDB? Also was vergleichen wir hier gerade miteinander? Was ist das hier, worüber reden wir? Ist das ein neues JavaScript-Framework?

Wolfi Gassler (00:11:17 - 00:12:36)

Du hast jetzt gedacht, du sagst das JavaScript-Framework, weil das ist am weitesten weg, aber sogar da gibt es extrem viele Probleme mit diesen JavaScript-Frameworks, die dann die Datenbanken ansprechen, aber das ist nochmal ein anderes Thema. Also gehen wir mal auf MySQL und MariaDB ein. Grundsätzlich für alle, die MySQL noch nie verwendet haben, ich vermute, es hat schon jeder mal gehört, es ist einfach eine relationale Datenbank, die mittlerweile 27 Jahre alt ist, also 95, gegründet wurde oder erstellt wurde und sich seitdem eigentlich den Weg zur Nummer 1 würde ich fast sagen, jetzt wirst du mich gleich unterbrechen, das ist sicher nicht mehr die Nummer 1 Datenbank, aber ich würde mal sagen es war zeitweise zumindest die meist installierte Datenbank. Und viele haben ja zu meiner Zeit, wie ich so angefangen habe zu programmieren, hat man immer so geschimpft, vor allem die ganzen Leute, die so von der Oracle-Welt kommen oder DB2-Welt von IBM, haben immer gemeint, das ist ja nur ein Adressbuch mit einem SQL-Interface. Aber mittlerweile hat die Datenbank ja auch Oracle übernommen. Und MySQL ist zu einer wirklich leistungsstarken, relationalen Datenbank gewachsen, die wirklich einen Großteil des Internet-Traffic backt. Und um nur ein paar Große Firmen zu nennen, YouTube läuft drauf, Facebook läuft drauf. Also das sind schon große Firmen, die MySQL auch einsetzen und es geht halt runter bis zum kleinen Block WordPress, wo normal MySQL einfach im Hintergrund als Datenbank läuft.

Andy Grunwald (00:12:37 - 00:13:03)

Du hattest gerade gesagt, Nummer 1 Datenbank. Das ist immer so ein bisschen schwierig, finde ich, wenn man so Rankings hat. Ich sehe auch immer so Kategorisierungen, das ist die schnellste Person in Nordrhein-Westfalen in der Altersklasse 30 bis 35 im Schwergewicht über 25 Meter. So nach dem Motto, man kategorisiert das einfach so tief runter, dass die Gruppe halt einfach nur noch, weiß ich nicht, zwei Leute enthält und dann ist man halt erster.

Wolfi Gassler (00:13:03 - 00:13:25)

Dir gefällt ja nun nicht, dass Postgres weiter hinten ist auf dem offiziellen Ranking. Das Ranking, was immer gerne genommen wird, ist dbengines.com. Hab grad nachgegoogelt, MySQL liegt da an zweiter Stelle, Oracle Platz 1, Microsoft SQL Server Platz 3, dann kommt Postgres schon auf 4, auf 5 immer noch IBM DB2, unglaublicherweise, und sehr cool auf Platz 6 mittlerweile SQLite.

Andy Grunwald (00:13:26 - 00:13:59)

Genau, du hast natürlich jetzt im Ranking von den relationalen Datenbanken geguckt, aber auch im globalen Ranking von relationalen Document-Datenbanken, Key-Values und so weiter und so fort, ist MySQL trotzdem auf Platz zwei. Faszinierend. Ich muss aber zugeben, ich weiß gar nicht, wonach die ranken. Hier, lesen Sie mehr über die Berechnungsmethode der Bewertung. Aber das Anzahl der Nennungen des Systems auf Webseiten, allgemeines Interesse durch Google Trends, Technische Diskussionen auf Stack Overflow und DBA Stack Exchange und Anzahl der Jobangebote auf Indeed. Okay, gut.

Wolfi Gassler (00:14:00 - 00:14:14)

Ja, die probieren im Prinzip zu googeln und schauen, wie viele Treffer es gibt, wenn man es mal ganz einfach zusammenfasst. Aber da sieht man schon, dass MySQL auf jeden Fall eine der Top Datenbanken ist. Darum glaube ich, dass schon jeder in irgendeiner Form mal Kontakt damit hatte.

Andy Grunwald (00:14:15 - 00:14:52)

Ich finde es ja immer persönlich sehr spannend mal eben hinter die Kulissen zu gucken, also jetzt nicht nur auf die Dokumentation und was kann das alles, sondern wo kommt die ganze Sache denn her, denn ich sage immer öfter in letzter Zeit, die Technologie ist oft nicht die Herausforderung, Technologie ist schwierig, was aber schwieriger ist, sind die Menschen dahinter, also alle auf ein Ziel einzustimmen und so weiter und so fort. würde ich gern immer die Motivation verstehen und wo kommen die ganzen Leute her und was ist so eigentlich die Story, weil für mich ist das immer so ein bisschen Kontext. Und da habe ich mich in der Vorbereitung dieser Episode mal ein bisschen mit beschäftigt. Ich habe nämlich immer gedacht, Sun Microsystems hat MySQL gebaut.

Wolfi Gassler (00:14:52 - 00:14:57)

Jetzt musst du mal kurz erklären, was oder wer Sun Microsystems ist. Gibt's die, Sun überhaupt noch?

Andy Grunwald (00:14:58 - 00:15:08)

Komme ich ja gleich zu, das ist es ja gerade. Also MySQL selbst wurde durch eine schwedische Softwarefirma namens MySQL AB gebaut.

Wolfi Gassler (00:15:08 - 00:15:21)

Eigentlich durch einen Kerl, Michael, weiß leider nicht, wie man es ausspricht richtig, Videnius, aber das war eigentlich der Kerl hinter dieser ganzen MySQL AB. Also gestartet hat es einfach, dass der.

Andy Grunwald (00:15:21 - 00:15:44)

Mal begonnen hat mit der datenbank genau und die haben 1995 die erste version von mysql rausgebracht mysql ab die firma selbst wurde aber dann anfang 2008 von zahn microsystems gekauft und zahn microsystems ist eigentlich die firma hinter java Die haben natürlich noch ein bisschen anderes gemacht, so was wie Star Office oder das ZFS-Filesystem.

Wolfi Gassler (00:15:44 - 00:15:57)

Ja, und sie haben natürlich auch Hardware gemacht. Die waren ja damals wirklich superstark im Serverbereich. Die haben Unix-Server gemacht, auch Workstations teilweise, und hatten ihr eigenes Sun-Betriebssystem.

Andy Grunwald (00:15:57 - 00:16:23)

Solaris ist es ja. SunOS ist ja Solaris. Auf jeden Fall hat MySQL eigentlich die ganze Popularität meines Erachtens nach durch den sogenannten LAMP-Stack bekommen. Also für die Leute, die ganz klassisch im Web unterwegs sind, LAMP, Linux, Apache 2, MySQL und PHP, obwohl sich natürlich auch Reddit und Stack Overflow sich ein bisschen darüber streitet, ob das P in LAMP Stack für PHP oder für Perl steht.

Wolfi Gassler (00:16:23 - 00:16:27)

Ja, im Zweifelsfall immer gegen Pearl und für BHB.

Andy Grunwald (00:16:27 - 00:16:38)

Auf jeden Fall, Januar, Februar 2008 wurde dann MySQL AB von Sun Microsystems gekauft. Und ein Jahr später wurde Sun Microsystems dann selbst von dem großen roten O von Oracle geschluckt.

Wolfi Gassler (00:16:39 - 00:16:45)

Und dann ist alles bergab gegangen. Zumindest wenn man Monty glaubt, also dem Gründer.

Andy Grunwald (00:16:45 - 00:17:34)

Ab da ging's eigentlich rund, genau. Und zwar der CTO von der originalen MySQL-AB ist bei den ganzen Transitions einfach mitgegangen und hat weiterhin an seiner kleinen Datenbank MySQL gearbeitet. Und als dann 2009 bekannt wurde, dass Oracle Sun Microsystems übernimmt, sagte er, oh mein Gott, was ist denn jetzt hier los? Und daraufhin wurde ein Fork von MySQL erstellt. Und zwar hat Monty, Michael Videnius, hat MySQL geforkt, weil er eigentlich sagte, dass er wirkliche Concerns hat, wie Oracle selbst mit Open Source umgeht. Und hat auch wirklich keine Zukunft darin gesehen. Und sein Anliegen war eigentlich, dass MySQL frei und Open Source bleibt. Und das kann er dann mit dem Fork von MariaDB natürlich verwirklichen.

Wolfi Gassler (00:17:35 - 00:18:49)

Er hatte auch natürlich extreme Probleme zu glauben überhaupt, dass MySQL wirklich weiterentwickelt wird. Es gab da extrem viele Stimmen, die geglaubt haben, MySQL wird eingestampft, weil MySQL einfach der große Gegner für die Oracle Datenbank an sich war. MySQL ist leistungsstark, kann extrem viel Clients bedienen, die Oracle sonst nur verwenden. Und da haben eigentlich die meisten gedacht, MySQL wird eingestampft und es wird sicher nicht so weitergeführt, wie das bisher der Fall war. Es stimmt natürlich, es wurde nicht so weitergeführt. Was man aber unterschätzt hat, ist, dass Oracle wirklich so viel Energie in MySQL pumpt und wirklich MySQL weiterentwickelt und richtig weiter pusht. Also da hat sich extrem viel bewegt und ich würde sagen zum Positiven. Also auch wenn das natürlich die Open Source Community nicht mehr so richtig existent ist, würde ich mal sagen, aber die Datenbank hat sich auf jeden Fall in die richtige Richtung bewegt und ich glaube sogar durch den Druck den Oracle auf MariaDB durch die neuen Features usw. aufgebaut hat, dass da insgesamt im Ecosystem wesentlich mehr weitergegangen ist und schneller die Dinge weitergegangen sind, als wenn es nur eine kleine Open-Source-Firma gewesen wäre.

Andy Grunwald (00:18:49 - 00:19:16)

Generell ist MariaDB angetreten, um ein Drop-in-Replacement für MySQL zu sein. Ob das dann wirklich so ist? Schauen wir dann gleich nochmal ein bisschen. Und das erste Release von MariaDB 5.1 war dann im Oktober 2009, galt als das Release der initialen Abspaltung. Aber was ich auf jeden Fall auch faszinierend finde, ist der Name. Woher kommt der Name? Maria ist der Monty Gläubisch.

Wolfi Gassler (00:19:16 - 00:19:51)

Das kann ich jetzt leider nicht beantworten, ob er gläubig ist. Auf jeden Fall hat die Maria meines Wissens zumindest nichts mit der katholischen Maria zu tun, genauso wenig wie das Mai, weil Mai hat nichts mit dem englischen Meine, SQL-Datenbank, zu tun. sondern Mai ist der Name von seiner Tochter. Scheint in Finnland ein häufiger Name zu sein und daraus ist eigentlich dieses Mai-SQL entstanden. Und bei dem Fork hat er sich einfach gedacht, er macht dasselbe wieder und hat einfach den Namen seiner zweiten Tochter verwendet und die heißt Maria. Und darum ist das Ganze MariaDB geworden.

Andy Grunwald (00:19:52 - 00:20:53)

Und irgendwie hat Monty da auch so ein bisschen recht gehabt mit seinem initialen Gedanken, dass Oracle jetzt gar nicht so im Open-Source-Game mitspielen möchte mit MySQL. Weil MySQL ist danach auch so ein bisschen mehr und mehr commercial gegangen. Und zwar nach der Akquisition von Sun Microsystems haben sie dann kommerzielle MySQL-Extensions angeboten. Und auf einmal hat MySQL auch zum Beispiel eine native Memcache-API beziehungsweise eine Memcache-kompatible API bekommen. Die Extension wurde aber in letzter Zeit wieder rausgenommen, in einem der letzten Releases. Warum und wieso, weiß man nicht. Steht im internen Bugtracker, kommt man da nicht ran. Ich vermute mal, die haben sie eingebaut, weil irgendein Enterprise-Kunde das haben wollte und diesen Enterprise-Kunden gibt es dann jetzt anscheinend nicht mehr oder ähnliches, ich weiß es nicht. Das finde ich sehr schade. Aber ich hatte auch schon im Intro erwähnt, das ganze Ding hat jetzt zwei Bug-Tracker. Einen öffentlichen Bugs.mysql.com und einen Oracle intern, wo keiner Zugriff drauf hat und da gehen halt die meisten Bugs ein. Schade eigentlich. Also die ganze Sache wurde halt mehr kommerziell gehalten.

Wolfi Gassler (00:20:53 - 00:22:25)

Wobei man natürlich fairerweise jetzt auch sagen muss, dass gerade jetzt die Firma hinter MariaDB ist gerade kürzlich public gegangen, ist also jetzt wirklich eine Aktiengesellschaft, kannst dir da auch gerne Aktien kaufen. Und die leben natürlich schon mehr den Open Source Gedanken, aber auch da sieht man in den letzten Jahren eine ganz klare Positionierung Richtung kommerziellen Enterprise-Verträgen, manche Dinge, die nicht so open source sind, auch wenn das Monty teilweise anders sieht. Und es ist immer spaßig, irgendwelche Vorträge zu sehen. Es gibt so Vorträge von dem Bacona-Chef. Also Bacona ist so eine Consulting-Firma, die auch eigene MySQL-Varianten rausbringt. Aber der Gründer von Bacona, Peter Zeitzew, ist sehr bekannt in der Community. und macht immer sehr gerne Vorträge und vergleicht MariaDB und MySQL. Und da sitzt natürlich Monty auch immer im Publikum und der Bieter hat glaube ich meistens drei bis fünf Sätze, würde ich mal sagen, die er ohne Unterbrechung sprechen kann. Und dann springt schon der Monty aus dem Publikum immer in seinen Vortrag rein und sagt, ja, aber das ist so und eigentlich, na, dort haben wir eigentlich eine andere Lizenz und eigentlich ist das ja gar nicht so. Also es wird dann immer so ein Streitgespräch fast zwischen den Zweien und weniger ein Vortrag. Kann man sich gerne mal anschauen, ist immer sehr lustig, weil Monty eigentlich immer in diesen Vorträgen drinnen sitzt bei den ganzen Konferenzen. Also der ist auch wirklich noch voll drinnen, aber wie gesagt mittlerweile auch da kommerzielle Gedanken dahinter natürlich, was ja auch fair ist, weil die haben alle Entwickler, die einfach voll an dieser Datenbank arbeiten und die muss man halt auch irgendwie bezahlen.

Andy Grunwald (00:22:25 - 00:22:41)

Also jetzt wissen wir woher die ganzen beiden Datenbanken denn so kommen, aber was ist es denn jetzt? Ist es MySQL oder MariaDB? Ist es wirklich ein Drop-In Replacement? Gibt es da Unterschiede? Klären wir es mal ein bisschen auf Wolfgang. Lass mal in diese MariaDB vs. MySQL Diskussion gehen.

Wolfi Gassler (00:22:42 - 00:25:06)

Also natürlich ist es eine gewisse Art von Drop-in-Replacement und jeder, der Linux verwendet, eine klassische Distribution heutzutage, wenn du sagst zum Beispiel bei Fedora irgendein dnf yum install mysql-server, dann wird üblicherweise einfach MariaDB installiert, ohne dass du das mitbekommst. Also wenn du sagst mysql-server, nachdem Oracle ein bisschen schwierig ist mit wirklich open source und so weiter, den Lizenzen wird da einfach standardmäßig MariaDB installiert und du kannst da MySQL auf der Command Line eingeben. Du bekommst MySQL-Shell. Es funktioniert eigentlich wie mit einer MySQL-Datenbank. Du siehst beinahe keinen Unterschied. Also klar wird angezeigt, du bist jetzt mit dem MariaDB-Server verbunden, aber die Kommandos sind dieselben. Du kannst die meisten Commands auch verwenden in der MariaDB. Kommt ja auch aus dem gleichen Produkt. Ist ja ein Fork einfach, der gespiegelt wurde. Aber man muss sagen, bei allen neueren Funktionalitäten von MySQL und auch von MariaDB gehen sie einfach komplett auseinander und da hast du keine Kompatibilität mehr. Also wenn es zum Beispiel um JSON Functions geht, die heißen teilweise einfach komplett anders, der Syntax ist anders, du kannst sie einfach nicht mehr eins zu eins verwenden. Es gibt natürlich spezielle Datentypen, es gibt spezielle Konstrukte, du kannst mittlerweile virtuelle Columns zum Beispiel machen, das funktioniert in den Datenbanken unterschiedlich, also MySQL und MariaDB. Also umso tiefer du in das Datenbank je mehr rein gehst, umso größer werden dann die Unterschiede. Und diese Liste kann man auch gerne verlinken, die die Unterschiede anzeigt. Gibt es auf MariaDB eine nette Übersicht. Die wird einfach immer, immer, immer länger. Und es wird immer schwieriger, kompatiblen Code oder SQL-Code zu schreiben, der in beiden Datenbanken wirklich läuft sogar. Kürzlich habe ich gemerkt, ich habe so ein Backup-Tool geschrieben, das in Docker läuft, wo man einfach so bei Docker ein Backup erzeugen kann. Für MySQL und MariaDB läuft komplett unterschiedlich, also auch die Backup-Tools haben sich komplett geändert. Da musst du jeweils für MariaDB andere Tools verwenden als für MySQL, für Oracle und musst dementsprechend alles anpassen. Also das Drop-in Replacement von früher ist nun mal eigentlich halbgültig. Aber wenn du natürlich nur so klassische Datenbank erstellst, eine Tabelle und da ein paar Insights machst und keine Special Features verwendest, dann kannst du das 1 zu 1 in MariaDB und MySQL machen.

Andy Grunwald (00:25:06 - 00:25:21)

Naja, ich weiß jetzt nicht, ob ich eine Jason Function in der heutigen Zeit, wo sich alles um APIs dreht und diverse Systeme miteinander verbinden und Co. wirklich als spezielle Funktion beschreiben würde, wie du es gerade getan hast.

Wolfi Gassler (00:25:21 - 00:25:50)

Es geht natürlich auch um den SQL-Standard irgendwo und die klassischen INSERT-Statements, SELECT-Statements, die man so macht, die sind kompatibel, aber wie gesagt, sobald du halt irgendwelche BUILD-IN-Functions, wie es halt bei Datenbanken so ist, verwendest, irgendwelche Spezialfunktionen, die nicht dem absoluten SQL-Standard von, keine Ahnung, 92 ist, glaube ich, oder 91 ist der klassische SQL-Standard entsprechen, dann hast du Probleme einfach mit der Kompatibilität und da muss man immer, immer mehr aufpassen.

Andy Grunwald (00:25:51 - 00:25:59)

Schön, dass du es nochmal gesagt hast, weil meine nächste Frage wäre gewesen, welcher SQL-Standard denn? Weil es gibt ja nicht nur einen.

Wolfi Gassler (00:25:59 - 00:27:51)

Ich glaube es ist, vielleicht ist der 91er sogar zu modern. Man muss sagen, beim SQL-Standard ist MySQL historisch extrem schlecht, grottenschlecht, wie man bei uns sagen würde. Also früher war MySQL, hat einen eigenen Syntax eigentlich fast gehabt bei vielen Dingen. und hat sich überhaupt nicht an den SQL-Standard gehalten. Natürlich, so ein klassisches Insight entspricht schon dem SQL-Standard, aber alles, was ein bisschen darüber hinweg geht, da hat MySQL immer eigene Dinge gebaut rundherum und hat sich auch wenig daran gehalten. Ist vielleicht bei MySQL immer noch so, MariaDB hingegen hat sich jetzt bemüht, sehr viele SQL-Features wieder einzubauen und wirklich Standards einzubauen und so möglichst SQL-kompatibel zu sein. Und auch, man muss fairerweise dazu sagen, auch MySQL probiert das natürlich in Teilen. Ein ganz klassisches Beispiel ist, vielleicht kennt das jemand, wenn man eine SQL-Anfrage, eine ganz simple SQL-Anfrage macht mit einem Group By, dann musst du, wenn du vorne etwas selektieren willst, also ein Select Andeswert, dann muss dieser Andeswert auch hinten im Group By vorkommen, nach SQL-Standard. MySQL hat es immer erlaubt, dass es auch möglich ist, dass es nicht im Group By vorkommt und man hat es trotzdem selektieren können, was eigentlich mathematisch falsch ist, weil es kein sicheres Ergebnis zurückliefert und seit den MySQL-Versionen, wo dann das Strict Mode aktiviert ist, bekommst du da eine Fehlermeldung und solche Dinge haben sich einfach weiterentwickelt und da ist MySQL und MariaDB wesentlich stärker geworden. MariaDB hat zum Beispiel kürzlich die Sequences eingebaut, die man aus der Oracle-Welt zum Beispiel kennt, ist auch ein SQL-Standard, wo du so Auto-Increment-Sequenzen bauen kannst, aber ein bisschen flexibler, dass du zum Beispiel sagen kannst, ich brauche einen Counter, der sich aber immer um 5 erhöht und nicht nur um 1 und solche Dinge kann man dann einbauen und als Primary Key verwenden. Also es sind so Spezialfeatures, aber die im SQL-Standard schon seit Jahrzehnten drin sind.

Andy Grunwald (00:27:52 - 00:28:27)

Naja gut, aber MySQL korrigiert's ja auch. Du sagst zwar gerade, dass MariaDB auch diese Flaws, würd ich schon fast sagen, nachzieht, aber wenn du jetzt eine neue MySQL-Version 8 installierst und da ist der SQL-Mode zu viel, ich weiß, Standard auf dieses Verhalten, wie du's grad beschrieben hast, das nennt man only full group by. Nur wenn man von einer MySQL-5er-Version, 5.5 oder ähnliches oder 5.3, migriert auf eine 8er, dann bleibt das Setting des SQL-Modes natürlich. Also eigentlich kannst du sagen, MySQL hat eine ganze Zeit lang so eine Art inkompatiblen SQL-Modus unterstützt.

Wolfi Gassler (00:28:27 - 00:28:30)

Genau, das war der eigene MySQL-Standard eigentlich.

Andy Grunwald (00:28:30 - 00:28:37)

Genau, MariaDB hat es durch den Fork dann rausgeschmissen und später wieder introduced anscheinend.

Wolfi Gassler (00:28:37 - 00:29:47)

Ja, es kommt wirklich darauf an, was für Elemente aus dem Standard. Aber zum Beispiel, was MariaDB jetzt ganz neu hat, ist, dass es so einen SQL-Mode Oracle hat und da wirklich Oracle-Statements unterstützt bis natürlich zum gewissen Grad und du kannst auch gewisse Stored Procedures bauen, die du sonst bei MySQL zum Beispiel nicht verwenden könntest, also wirklich Oracle PL SQL Syntax verwenden kannst oder Packages zum Organisieren von Procedures. Also da gibt es wirklich viele Neuerungen. Und da zieht MariaDB also auch wirklich nach und hat teilweise mehr Funktionalität als MySQL. Also auch diese Ansicht in der Szene, dass MySQL immer mehr Features hat als MariaDB, war zeitweise gültig und valide. hat sich aber jetzt auch stark geändert und die MariaDB-Fraktion geht wirklich in eine andere Richtung, baut nicht alles nach, übernimmt natürlich auch Teile von MySQL, ist ja alles Open Source, aber es wird immer wieder weniger, was überhaupt übernommen wird und die gehen wirklich in eine eigene Richtung, entwickeln neue Features, eigene Features, bauen einen eigenen Optimizer, also da passiert wirklich extrem viel und es gibt wirklich einige Punkte, wo MariaDB punkten kann und MySQL nicht.

Andy Grunwald (00:29:47 - 00:30:36)

In der Vorbereitung zu diesem Podcast habe ich nämlich sowas gelesen, wie du es gerade erwähnt hast, dass MariaDB auch eine ganze Menge von MySQL wieder übernimmt. Und zwar habe ich gelesen, dass als MariaDB von MySQL abgespalten wurde, also einmal, ich sag mal, den Code kopiert, dann wurden sehr viele Code Changes in diversen Arealen gemacht, wie zum Beispiel im Bereich der Replikation oder im SQL Optimizer. Dann wurde aber auch explizit gesagt, in manchen Bereichen Machen wir einfach so gut wie gar keine Änderungen, nämlich bei der InnoDB Storage Engine, damit wir die Bugfixes, die in MySQL implementiert werden, relativ schnell in MariaDB zurückporten können. Relativ smarter Move, muss ich zugeben. Und jetzt möchte ich von dir wissen, welche Änderungen gibt es denn wirklich im Optimizer, zum Beispiel jetzt, die wirklich signifikant sind?

Wolfi Gassler (00:30:37 - 00:32:31)

Vielleicht sollte man vorab nochmal das mit den Storage Engines erwähnen, weil wir haben jetzt wirklich ständig Storage Engines erwähnt und das ist ein wirkliches Merkmal von MySQL und von MariaDB, wie das Ganze aufgebaut ist. Und zwar gibt es die eigentliche Datenbank MySQL, MariaDB, die kümmert sich um das SQL, um User Login, um das Parsen, aber dann die eigentliche Storage Engine dahinter, die die Daten wirklich ablegt, die sich um die Indices kümmert, um die Datentypen von Spalten und die ganzen Dinge, die laufen dann in der Storage Engine ab. Also das ist wie so ein Plug-in System und es gibt da natürlich als InnoDB die Standard Storage Engine, aber du kannst es natürlich auch komplett ändern und eine andere Storage Engine verwenden. MyISAM war die erste Storage Engine, die war nicht Transaktionssicher, also nicht ACID. Das hat man mit InnoDB dann geändert. Es gibt ARIA, die ist so der Nachfolger von MyISAM im MariaDB-Bereich. Aber es gibt sogar zum Beispiel Column Stores in MariaDB als Storage Engine, die dann die Daten komplett anders ablegen. Also die kann man wirklich komplett austauschen. Facebook ist sogar so weit gegangen, die haben ja eine eigene Storage Engine geschrieben mit RocksDB. und hat dann als Plugin die MyRocks Storage Engine für MySQL gebaut. Nachdem Facebook auf MySQL basiert und die natürlich nicht die ganze Datenbank neu schreiben wollten, aber für ihren Anwendungsfall eine bessere Storage Engine wollten, haben die eben nur die Storage Engine ausgetauscht und haben so den gesamten Stack bei ihnen weiterverwenden können, aber mit einer optimierten Storage Engine. Und drum haben Storage Engines so einen wichtigen Einfluss auf die ganze Datenbank. Und wenn du da einen Storage Engine austauschst, kannst du eigentlich eine neue Datenbank fast haben oder gerade wenn es um die Performance geht, wirklich große Änderungen oder Performance Gains aus dem ganzen rausholen, aus dem Stack.

Andy Grunwald (00:32:31 - 00:32:55)

Du hast das so beschrieben oder beziehungsweise hat sich das so angehört als könnte ich mit MariaDB nur eine Storage Engine pro Datenbank nutzen. Aber die Storage Engine kann man ja pro Tabelle innerhalb einer Datenbank konfigurieren. Also das bedeutet, ich kann ja InnoDB für meine 5 Tabellen nutzen und die MyRocks bzw. ja MyRocks Storage Engine für eine andere Art von Tabellen, je nach Abfrage, Speicherung, Konzeption der Daten, oder?

Wolfi Gassler (00:32:56 - 00:33:34)

Genau, ist pro Tabelle möglich. Es gibt zum Beispiel auch mittlerweile meines Wissens nur auf der MariaDB Seite, habe ich bei MySQL jetzt noch nicht gesehen, aber könnte sein, dass da schon auch was gibt, dass man zum Beispiel eine Tabelle in S3 ablegen kann. Das ist natürlich vor allem, wenn man große Datenmengen hat und vielleicht auch in Kombination mit dem Column Store in MariaDB kann man die Daten wirklich zur Analyse in S3 ablegen und dann wirklich darauf zugreifen. Also da gibt es Auch wirklich solche Analyse-Engines, die man dann natürlich vielleicht nur auf die eine oder andere Tabelle anwendet, während man diese Hot Tables, auf die man ständig zugreift, auf die man ständig schreibt, die kann man mit InnoDB zum Beispiel weiterverwenden.

Andy Grunwald (00:33:34 - 00:34:20)

Aber die Nutzung von Object Storage ist ja gerade so ein super neuer Move in der ganzen Datenbankwelt. gibt es ja auch im Kafka das Konzept von Tiered Storage. Das bedeutet, du kannst auch gewisse Topics beziehungsweise Partitionen auch auf Object Storage ablegen. Clickhouse kann das ebenfalls von Haus aus. Analytische Daten einfach in Object Storage ablegen. Dann hast du sowas wie Timeseries-Datenbanken, Metric-Datenbanken, sowas wie Thanos, was oft auch im Cloud-Native-Umfeld genutzt wird, was ebenfalls deine Monitoring-Metriken oder IoT-Metriken oder was auch immer in Object Storage abliefert. Also das finde ich sehr, sehr geil, dass da langsam ein bisschen frischer Wind in diese, ich sag mal, ein bisschen angestaubte SQL-Datenbank-Geschichte reinkommt und dann auch solche neuen Konzepte dann damit einfließen.

Wolfi Gassler (00:34:20 - 00:35:36)

Also ich glaube, auf der Storage-Ebene hat sich extrem viel getan. Und man muss ja auch dazu sagen, Datenbanken, das ist eigentlich deren Kernelement. Wie speichere ich die Daten sicher und kann schnell darauf zugreifen? Und wo sollte sich sonst was ändern, wenn nicht beim Storage? Und da hat natürlich RocksDB zum Beispiel auch angefangen, vor jetzt schon zehn Jahren bei Facebook eine eigene Storage Engine zu entwickeln, wie die ganzen SSD, Solid State Drives, aufgekommen sind, wo man weggegangen ist von den beweglichen Festplatten zu den Speicher-Storage und da haben die natürlich speziell dafür eine Storage-Engine entwickelt, die mittlerweile extrem weit ist, die es in verschiedenen Datenbanken gibt und die eben wirklich optimiert ist, auf den Use-Case-SSDs zu haben. Mittlerweile ist es so weit gegangen, dass MariaDB sogar bei ihrem Optimizer, weil du ja zuerst auch gefragt hast, alles so umgestellt haben, jetzt ganz neu, dass alles auf SSDs optimiert ist. Also auch der Default bei MariaDB im Optimizer ist mittlerweile auf SSDs und die nehmen an, dass du eine SSD hast. Das heißt, du kannst eigentlich Spinning Disks gar nicht mehr verwenden mit MariaDB. Zumindest ist der Optimierer nicht mehr drauf ausgelegt.

Andy Grunwald (00:35:36 - 00:35:42)

Was ist jetzt das Spezielle an RocksDB beziehungsweise MyRocks? Also warum sind die so schnell gegenüber InnoDB?

Wolfi Gassler (00:35:43 - 00:37:29)

Also ob sie jetzt gegen InnoDB viel viel schneller sind, da fighten sie sich eher. Aber ich würde mal sagen für den Use Case, für den sie entworfen sind, da sind sie auf jeden Fall schneller. Und zwar ist es darum gegangen, dass Facebook eben die SSDs eingeführt hat und nicht mal die Spinning Disks und wirklich sehr viel geschrieben hat. Also für Write Heavy Loads, im Gegensatz zu Read Heavy Loads. Und daraufhin haben die das eigentlich optimiert. Ist eigentlich ein Fork von der LevelDB, die Google eingeführt hat. Und darunter, das eigentliche Modell, sind sogenannte LSM-Trees, die Log-Structured-Merge-Trees. Klingt jetzt sehr kompliziert. Ganz einfach erklärt, im Prinzip hast du durch so eine Baumstruktur mehrere Ebenen und kannst darum zum Beispiel auch ganz gut mit unterschiedlichen Speichertechnologien umgehen. Du hast in der ersten Ebene den Hauptspeicher zum Beispiel, die zweite Ebene ist dein SSD-Storage, die dritte Ebene ist dann deine Spinning Oldschool-Harddisk und die Daten werden immer nach unten propagiert und zwar aber erst nach einer gewissen Zeit. Das heißt, du schreibst zuerst mal in der ersten Schicht, irgendwann geht es dann in die zweite runter, irgendwann in die dritte, aber mehr so langsam, nicht synchron wie bei klassischen Datenbanken oder B-Bäumen. sondern asynchron und dadurch kannst du wesentlich mehr rausholen. Du machst auch nur ein Event-Only-Log quasi, also du hängst nur immer Daten dran und nach einer gewissen Zeit werden die Daten komprimiert und in die Ebenen darunter wieder weitergegeben. Und dadurch bist du sehr schnell, weil du eben nur immer Daten anhängst und nie Daten änderst im Place, nie herumspringen musst. Also es ist eine eigene Technik und die haben sich wirklich darauf gestützt und haben da einen Key-Value-Store gebaut auf diesen LSM-Trees und haben das Ganze dann MySQL zur Verfügung gestellt als Storage-Engine.

Andy Grunwald (00:37:29 - 00:37:56)

Ich meine, die richtige Wahl der richtigen Storage Engine für deinen Use Case ist ja gar nicht so einfach. Auf MariaDB gibt es sogar eine eigene Seite, Choosing the Right Storage Engine, und da gibt es wirklich Kategorien, General Purpose, Scaling, Compression, Connecting with Other Data Sources, Search Optimized, Cache Read Only. Da muss man immer und immer und immer wieder genau in seine Daten reingehen und schauen, okay, was habe ich für Daten, wie greife ich auf diese zu, was möchte ich damit machen?

Wolfi Gassler (00:37:57 - 00:38:55)

Wobei da auch mein Ansatz immer ist, verwend einfach mal InnoDB und wenn du ein Problem hast, kannst du immer noch die anderen checken. Aber man muss schon sagen, dass im Allgemeinen InnoDB einfach so hoch optimiert ist und seit Jahrzehnten optimiert wird, dass das einfach eine extrem ausgereifte Storage Engine ist und darum setzen auch alle drauf. Mittlerweile kann sie auch Replikationen und in Cluster-Systemen eingesetzt werden, als Master-Master-Replikationen oder also wirklich in einem Cluster-System. Also da tut sich so viel und den Use-Case musst du mir erst zeigen, der nicht mit InnoDB abgebildet werden kann. Natürlich gibt es immer extreme Use Cases und da kann man dann in die anderen Storage Engines durchaus mal reinschauen, aber für 99% der Fälle, wenn du einfach sagst, ich habe eine klassische, relationale Datenbank, wo ich meine Daten ablegen will, meine Daten wieder rausbekommen will, vielleicht noch Transaktionen nutzen will, was eh die wenigsten wirklich tun, dann ist InnoDB ganz einfach die richtige Storage Engine.

Andy Grunwald (00:38:55 - 00:39:32)

Ja, ich glaube generell, da kommt man sehr, sehr weit mit. Also es gibt ja auch noch immer noch sehr, sehr große Firmen, die mit sehr hoher Wahrscheinlichkeit InnoDB im Einsatz haben. Wikimedia Foundation, worauf natürlich Wikipedia basiert. Also ich glaube, da kommt man schon sehr, sehr, sehr weit mit. Kommen wir mal in das ganze Thema der Replikation. Ich meine, fast jede Firma, die auf MySQL oder MariaDB basiert, die wird ja keine Einserver-Datenbank haben, hoffe ich zumindest. Ich hoffe, zumindest hat man wenigstens mal ein Read-Replica oder ein Replica für Disaster-Recovery. Gibt's da irgendwie was Tolles? Ich meine, sticht da irgendwie MariaDB heraus? Also ich weiß, dass MySQL ja so eine Galera-Cluster-Geschichte hat, die das alles ein bisschen einfacher machen soll.

Wolfi Gassler (00:39:33 - 00:40:39)

Also Galera ist eine externe Entwicklung und wird von MariaDB verwendet und von Percona für ihre jeweiligen Cluster-Versionen, wird von Codership entwickelt und ist eigentlich so eine Schicht über der Datenbank, die dann die ganzen Sachen mit Leader Election und so weiter macht, die verwenden Baxos dafür. Und die kümmern sich dann um das gesamte Cluster-Management. Also das ist Galera, ist im MariaDB-Umfeld zu Hause. Auf der MySQL-Seite gibt es mittlerweile die Group Replication. Ich finde den Namen immer noch schrecklich, ehrlich gesagt, weil ich verstehe nicht, was eine Group Replication mit Cluster zu tun hat. Also ich bin da immer verwirrt, ich würde da nie auf Cluster schließen. Aber was dahinter steckt ist, dass du wirklich eine synchrone Replikation machen kannst und wenn du in einem wirklichen Cluster arbeitest, brauchst du eine synchrone Replikation, damit du weißt, okay, die Daten sind auf anderen Knoten auch abgelegt, sicher abgespeichert und erst dann darfst du eine Transaktion wirklich abschließen. Das heißt, auf der MySQL Cluster Seite wird MySQL Group Replication verwendet, die quasi von InnoDB nativ angeboten wird.

Andy Grunwald (00:40:40 - 00:40:53)

Gibt's die Möglichkeit, dass ich einen MySQL-Server hab und dann nach MariaDB repliziere? Dass ich einfach zwei Datenbanken in meinem Stack hab, die ja mehr oder weniger ein Drop-In-Replacement sein sollten, beziehungsweise jetzt nicht mehr sind, also...

Wolfi Gassler (00:40:53 - 00:43:19)

Das kommt schwer drauf an, was für Version du verwendest, und es ist natürlich schon klar, wenn du jetzt eine Statement-based Replication machst, und wir haben ja schon gesagt, die Statements können unterschiedlich sein, dann funktioniert das einfach nicht mehr auf den zwei Datenbanken. Also es gibt schon Möglichkeiten, je nachdem, was du aktiviert hast, welche Versionen du fährst. Wenn du ältere Versionen fährst, die sind eher noch kompatibel zueinander. Je nachdem, was du für ein Binary Log fährst mit Global Transaction Identifiers und so weiter. Also da gibt es viele Dinge, die man beachten müssen. Darum würde ich es auf keinen Fall empfehlen, sowas zu machen. Aber was man zum Beispiel machen kann und ich finde das immer noch eine sehr coole Geschichte, die ich mal von Booking gehört habe, wenn die Leute von Oracle bei denen vorbeischauen, um mal wieder eine neue Lizenz auszuverhandeln, weil die verwenden eben MySQL, dann haben die denen immer gezeigt, ja wir haben da unseren MariaDB Cluster stehen und der bekommt den gleichen Traffic ab und wir testen einfach mal ständig, wie MariaDB performt. Und mittlerweile gibt es im MySQL Ecosystem auch den sehr coolen Proxy SQL. Das ist eine Software, die den MySQL Traffic oder Maria Traffic routen kann und sich im Prinzip dazwischen hängt. Das ist ein klassischer Proxy. Haben wir in unserer Proxy Episode gerade kürzlich auch erklärt. Und der kann natürlich sehr viel. Der kann zum Beispiel auch den Traffic spiegeln und der sendet den ganzen Traffic an deinen klassischen MySQL Server. Der kann aber auch den gesamten Traffic noch parallel zu MariaDB schicken. Und dann bekommst du in Logs direkt zu sehen, wo gibt's Statements, die fehlen, wo gibt's Probleme. Du kannst den MariaDB-Server natürlich auch monitoren, siehst, ob der mehr Last hat als der MySQL-Server. Kannst also wirklich Last-Tests fahren. Du kannst es natürlich auch machen mit neuen MySQL-Versionen oder MariaDB-Versionen, wenn du zum Beispiel ein Upgrade planst. kannst du mal den gesamten Traffic einfach auf eine neue Version spiegeln und checken, gibt es irgendwo Probleme, habe ich irgendwo Dinge drin, die mit einem Upgrade nicht mehr funktionieren würden. Also dieser Proxy SQL ist super praktisch, geniales Tool, super einfach zu installieren, kann ich also wirklich nur empfehlen, man kann auch ganz komplexe Dinge damit machen, umrouten und so weiter. Also wirklich ein geniales Ding. Aber man muss natürlich auch da sagen, du hast natürlich das gleiche Problem wieder, wenn du da irgendwelche JSON-Functions oder sonstige Dinge verwendest, die nicht kompatibel sind, dann hast du dasselbe Problem. Und darum würde ich eben auch keine Replikation empfehlen zwischen MariaDB und MySQL, wenn nicht unbedingt nötig.

Andy Grunwald (00:43:19 - 00:43:29)

Aber du hast gesagt, okay, wenn du eine Statement-based Replikation hast, dann wird es ein bisschen schwierig. Wie sieht es denn mit der Row-based Replikation aus? Weil da schiebe ich ja eigentlich nur Daten über die Leitung und keine Statements.

Wolfi Gassler (00:43:30 - 00:44:42)

Sollte im Normalfall meines Wissens noch funktionieren, aber auch da wieder kommt drauf an, zum Beispiel die Global Transaction Identifiers, die mal eingeführt worden sind bei MySQL, die werden mittlerweile in MariaDB und MySQL leicht anders gehandhabt, sind nicht mehr hundertprozentig kompatibel und die sind mittlerweile eigentlich das Wichtigste in der Replikation, da werden alle Änderungen mit IDs erfasst. Und da kann es auch zu Problemen führen, also ich würde es einfach nicht empfehlen. Es ist schon möglich, wie gesagt, aber da muss auch wirklich sichergestellt werden, dass du keine Spezialfeatures verwendest, dass das alles dasselbe ist. Aber natürlich, wenn du eine klassische InnoDB hast im Hintergrund, die ist ja so selbstständig, das läuft alles eigentlich in der InnoDB, in der Storage Engine ab und dann ist nicht mehr so viel Unterschied, ob du die InnoDB natürlich in MySQL oder in MariaDB verwendest. Aber noch einmal, also ich sehe auch keinen Anwendungsfall, ehrlich gesagt, dafür und ich sehe eher mehr Probleme, die das auf Dauer machen könnte. Natürlich für eine Migration, wenn du das ganz klar mal analysierst und ausprobierst, dann macht das vielleicht Sinn für den Umstieg an sich, aber für ein Produktivsystem sehe ich jetzt weder den Need noch eigentlich die Sinnhaftigkeit und ich würde mich nicht darauf verlassen, ehrlich gesagt.

Andy Grunwald (00:44:42 - 00:45:04)

Naja, aber der Killer-Use-Case, den hast du ja gerade genannt, die Migration von MySQL nach MariaDB, weil natürlich gibt es immer wieder Mechanismen, wie du Datenbankmigration machen kannst. Also das Aufsetzen von einer MariaDB-Replika und nach abgeschlossener Replikation dann das Promoten des Replikas zum Primary ist ja ein Standardmechanismus für eine Migration.

Wolfi Gassler (00:45:05 - 00:45:51)

Kannst du auf jeden Fall machen, ja. Also wenn du das so hinbekommst, macht das natürlich durchaus Sinn. Wenn du wirklich im Live-Betrieb migrieren musst, ja. Aber weil du gerade Replikation und Migration sagst, es gibt auch bei MySQL jetzt ein sehr cooles Clone-Plugin, was es ermöglicht, eine Datenbank zu klonen, weil früher hat man da komplizierten Backup machen müssen, dann das in die Replika einspielen und dort wieder synchronisieren mit der ID, mit dem Zeitpunkt genau, wo man das Backup gemacht hat und so weiter. Und das funktioniert jetzt mit dem MySQL-Clone-Plugin automatisch. Man klont es und kann dann direkt die Replikation drauf starten, weil genau der Zeitpunkt alles mitgeklont wird. Also das macht mittlerweile das Einführen einer Replikation oder von einem Replika auch nochmal einfacher. Also da tut sich ziemlich viel auf dem Gebiet.

Andy Grunwald (00:45:52 - 00:46:02)

Okay, aber die Replikation ist ja nicht da, wo wir die Performance herkriegen, sondern in der Regel im Optimizer, der entscheidet, okay, welches Indizier wird denn jetzt genommen? Wie wird die Query denn optimiert?

Wolfi Gassler (00:46:02 - 00:46:13)

Naja, die Replikation macht dir natürlich auch einen großen Geschwindigkeitsgewinn, weil du natürlich mehrere Server zur Verfügung hast. Aber in der einzelnen Query natürlich spielt der Optimizer die Rolle.

Andy Grunwald (00:46:13 - 00:46:18)

Kann MariaDB auch da punkten mit, ich bin schneller als MySQL?

Wolfi Gassler (00:46:18 - 00:48:32)

Ja, das ist natürlich super schwer. MySQL hatte lang die Nase vorn, meiner Meinung nach, weil da Oracle gerade am Anfang nach dem Fork von MariaDB extrem viel rein investiert hat und MariaDB da relativ lang gebraucht hat. Aber mittlerweile hat der MariaDB auch nachgezogen und die haben gerade in der letzten Version sehr viel geändert im Optimizer, haben da Dinge umgestellt. haben zum Beispiel ihren Hauptalgorithmus umgestellt von einem regelbasierten Algorithmus zu einem kostenbasierten Algorithmus. Das ist eigentlich sehr cool. Man kann mittlerweile genau checken, welche Operation wie teuer ist in MariaDB. Da gibt es Default-Werte. Aber man kann die sogar selbstständig ändern und wirklich auf sein System anpassen. Das heißt, wenn ein Read von der Festplatte eine gewisse Mikrosekundenanzahl bedeutet und eingestellt ist, dann kann man das checken oder im Notfall sogar ändern, wirklich, wenn man so weit runter geht in den Optimierer. Also da hat sich viel getan. Man kann mittlerweile Explain Statements, also wer das nicht kennt, man kann einfach vor eine Select Query ein Explain schreiben, bekommt er dann Informationen zum Optimierer, wie eine Query abgearbeitet werden würde. Bei MariaDB kann man da mittlerweile weitergehen, man kann sogar ein Trace einschalten für den Optimierer, dann bekommt man noch tiefere Informationen, wie der Optimierer wirklich die Query behandelt, was der vorschlagen würde und das Ganze kann man eben selbst auch tweaken. Und das ist eigentlich die große Änderung jetzt bei dem MariaDB Optimizer. Am Ende, ob der jetzt schneller ist als MySQL, kann man eigentlich so global nicht sagen, weil es kommt halt wirklich auf den Use Case drauf an, welche Queries du verwendest, welche Daten du gespeichert hast, wie viel Daten, wie die Daten. aussehen und das sind halt alles statistische Verfahren, die da im Hintergrund laufen in den Optimizern und darum ist es auch schwer, diese Dinge einfach zu vergleichen, eins zu eins zu vergleichen. Aber man kann auf jeden Fall sagen, MariaDB hat super aufgeholt, hat einen super Optimizer jetzt gemacht mit viel Flexibilität, den du bei MySQL nicht hast, aber ehrlich gesagt für den normalen User ist das sowieso irrelevant, weil du bist einfach froh, dass deine Query schnell abläuft. Und vielleicht schreibst du mal einen Explainer vor, um zu checken, verwendet der auch wirklich meinen Index, den ich angelegt habe.

Andy Grunwald (00:48:32 - 00:49:07)

Jetzt sagst du MariaDB ist hier besser und da besser, das hat mehr Funktionalitäten und da bin ich zukunftssicherer, weil ich viel mehr einstellen kann und den Optimizer sogar so hart tweaken kann und ich benutze sowieso nur Server mit SSD-Platten, deswegen ist jetzt die nächste Storage Engine MyRocks und nicht mehr InnoDB. Ist das jetzt der Weber-Grill mit den fünf Brennern? und der Sizzle Zone mit 35 IoT Sensoren oder ist MariaDB eigentlich nur dieser günstige Drei-Stelzen-Grill von der Tanke nebenan mit gutem Marketing?

Wolfi Gassler (00:49:07 - 00:49:09)

Du meinst das Adressbuch mit SQL-Interface?

Andy Grunwald (00:49:10 - 00:49:21)

Ganz genau das. Also meine Frage ist eigentlich nur, spielt MySQL eigentlich noch eine Rolle oder wenn ich jetzt vor einem neuen Projekt stehe, ist MariaDB die Qual der Wahl?

Wolfi Gassler (00:49:21 - 00:49:24)

Warum sagst du eigentlich MySQL und nicht MySQL?

Andy Grunwald (00:49:24 - 00:49:30)

Ich glaube, wenn ich ins Internet gehe, gibt es sieben verschiedene Aussprachen davon. Also ich weiß es bis heute nicht.

Wolfi Gassler (00:49:30 - 00:49:37)

Also bei MySQL kann man eindeutig sagen, es heißt MySQL und nicht MySQL, weil das einfach der Monty so sagt.

Andy Grunwald (00:49:37 - 00:49:42)

Ich nutze das jetzt, ich sage jetzt einfach immer nur noch My Structured Query Language. So, da kann mir einfach gar keiner mehr was.

Wolfi Gassler (00:49:43 - 00:49:47)

Ja, warum sagst du überhaupt SQL? Das ist ja eine ganz komische Aussprache.

Andy Grunwald (00:49:47 - 00:49:48)

Es gibt aber Leute, die sagen das so.

Wolfi Gassler (00:49:49 - 00:50:34)

Man merkt, du passt nicht gut auf, Andi. Das haben wir, glaube ich, in einer Episode mal schon irgendwann besprochen, wenn mich nicht alles täuscht. Also, da kann ich gleich mein historisches Wissen natürlich anbringen. Vor allem im amerikanischen Bereich wird gern SQL gesagt für SQL. Und das hat damit zu tun, dass der Vorgänger von SQL, SQL war. Und der war wirklich mit S-E-Q-E-L, glaube ich, geschrieben. Und nachdem das einfach der Nachfolger war und alle schon irgendwie auf dem SQL-Trip waren und das sich irgendwie leichter aussprechen lässt, vor allem scheinbar für Amerikaner, haben die einfach weiterhin SQL gesagt. Und daher ist es heutzutage einfach im amerikanischen Bereich ganz oft SQL statt SQL. Hat aber nichts damit zu tun, als wenn man das nur irgendwie so aussprechen könnte, SQL. Das ist einfach historisch bedingt von dem Vorgänger SQL.

Andy Grunwald (00:50:34 - 00:50:39)

Vielen Dank, Klugscheißer Dr. Wolfgang. Kommen wir zurück zu meiner wichtigen Frage, zu meiner relevanten Frage.

Wolfi Gassler (00:50:39 - 00:50:41)

Zum Weber Grill.

Andy Grunwald (00:50:41 - 00:50:44)

Ist MariaDB jetzt der Fünffachbrenner mit Sizzlezone?

Wolfi Gassler (00:50:44 - 00:52:44)

Also das coole an MySQL und auch an MariaDB ist meiner Meinung nach die Flexibilität, aber gleichzeitig die Einfachheit. weil jeder der schon mal MySQL verwendet hat oder MariaDB weiß, wie einfach das ist und du kannst das einfach in dem Docker zum Beispiel hochfahren, machst dann Docker run und das Ding läuft und das Ding läuft stabil und da kannst du wahrscheinlich Gigabyte an Daten reinladen und es wird nichts passieren und es wird super safe sein, ohne dass du nur einen Parameter änderst. Und das war ja eigentlich damals auch, wie MongoDB den Markt aufgeräumt hat. Die haben ja, oder ganz allgemein diese ganzen Key-Value-Stores und NoSQL, die haben ja behauptet, du musst nichts konfigurieren. Du installierst und es läuft auf Anhieb. Und da ist aber MySQL auch in der Schiene. Das war sie früher schon meiner Meinung nach und jetzt vielleicht sogar noch umso mehr, weil es einfach super durchoptimiert ist, dass du das standardmäßig einfach super safe betreiben kannst. Aber wenn du einen schwierigen Use Case hast, wenn du viele Daten hast, wenn du einen speziellen Use Case mit speziellen Anforderungen hast, dann kannst du in die Tiefe gehen. Und dieses System ermöglicht dir wirklich in die Tiefe zu gehen, was MongoDB zum Beispiel früher nicht konnte, weil du konntest MongoDB nicht so tweaken zu Anfangszeiten. Und bei MySQL kannst du wirklich bis auf die Storage Engine nach unten gehen. Du kannst die Storage Engine austauschen. Du kannst, wie wir erwähnt haben, bei MariaDB jetzt sogar den Optimizer tweaken. Also da gibt es Möglichkeiten, die du bei anderen Datenbanksystemen gar nicht hast, aber du musst sie nicht verwenden. Und darum finde ich das immer noch so ein cooles System, dass sich so viel tut auf dem Markt, auch im Ecosystem, was es für Tools dafür gibt, so wie in ProxySQL oder PlanetScale oder wie Tess, was ja PlanetScale auch verwendet. Also da hat man einfach viele Möglichkeiten, die es natürlich jetzt unter Umständen auch schwieriger machen, weil man mit ganz vielen unterschiedlichen Systemen unter Umständen zu tun hat und nicht mehr so klar ist, es gibt die einzige MySQL, sondern es gibt halt viele Variationen, viele Storage Engines. Das kann es unter Umständen mal schon schwieriger machen, aber als Einstiegsdatenbank immer noch super geeignet.

Andy Grunwald (00:52:44 - 00:53:15)

Jetzt ist ja MariaDB angetreten, um ein Drop-In-Replacement zu sein. Jetzt erzählst du mir aber eigentlich, okay, das ist gar kein Drop-In-Replacement mehr. Besonders wenn man jetzt, du nennst es speziellere Funktionen, JSON-Funktionen in einer relationalen Datenbank verwenden, ist für mich jetzt nicht speziell, würde ich sagen. Aber was ich so raushöre, ist halt, dass die Liste der Incompatibilitäten mit jedem Release länger wird. Das bringt mich zu der Frage, brauche ich jetzt, wenn ich jetzt ein Produkt erstelle, was eine SQL-Datenbank als Backend hat, muss ich da jetzt eine URM implementieren?

Wolfi Gassler (00:53:15 - 00:54:02)

Bei ORMs ist meine Standard-Antwort immer, bitte nicht. Aber man muss schon sagen, es ist kein Drop-in-Replacement mehr. Ganz klar. Es ist schon noch kompatibel im Großen und Ganzen, würde ich mal sagen. Die zwei Datenbanken sind kompatibel zueinander. Vielleicht in, würde man sagen, in 80 Prozent aller Fälle. Aber umso tiefer du natürlich gehst, umso schwieriger wird das Ganze. Und wenn du natürlich die Column-Store-Engine verwendest bei MariaDB, dann hast du da natürlich mit MySQL Probleme. Das ist ganz klar. Also umso mehr du customizest, umso mehr Spezialfeatures du verwendest. MariaDB hat jetzt zum Beispiel ganz neu temporale Tabellen, wo du wirklich pro Zeile definieren kannst, wann diese Zeilen gültig sind. Da hast du in MySQL dann einfach keine Chance. Wenn du dieses Feature verwendest von MariaDB, das gibt es in MySQL einfach nicht. Das ist ganz klar.

Andy Grunwald (00:54:02 - 00:54:23)

Was würdest du mir denn für ein Vorgehen empfehlen, wenn ich sage, okay, ich würde MariaDB gerne mal ausprobieren, habe jetzt gerade ein MySQL immer im Stack, möchte aber nicht meine ganze Live-Umgebung dem Risiko aussetzen. Also was würdest du empfehlen, wie ich das einfach mal durchweg teste und schaue, ist MariaDB ein Ding für mich?

Wolfi Gassler (00:54:24 - 00:55:03)

Ja, wie ich zuerst schon erwähnt habe, ProxySQL dazwischenhängen sollte in jedem großen Umfeld sowieso irgendwo drin sein, meiner Meinung nach, um die Flexibilität zu haben. Auch wenn du ein Cluster-System hast, brauchst du es einfach sowieso. Aber sonst, wenn du ein bisschen größeres System hast, ist es sowieso zu empfehlen. Und dann kannst du einfach den ganzen Traffic spiegeln und auf MariaDB mal abfeuern und einfach checken, funktioniert das Ganze auf MariaDB auch? Ist es vielleicht sogar schneller? Ist der Optimierer besser oder nicht? Und dann kann man dementsprechend analysieren, ob sich ein Umstieg wirklich rentiert. Wie gesagt, bei ganz klassischen Anwendungsfällen, bei einem WordPress oder so, kannst du einfach wechseln, da wird nichts passieren.

Andy Grunwald (00:55:03 - 00:55:14)

Wenn du sagst rentiert, gehst du da nur auf das Performance Kriteria ein oder auch auf irgendeine Lizenzkriterien oder Zukunftsangst, dass MySQL jetzt von Oracle eingestellt wird?

Wolfi Gassler (00:55:14 - 00:56:17)

Also grundsätzlich ist MariaDB natürlich sowieso zu empfehlen, weil meiner Meinung nach der Ansatz einfach der offenere ist. Und wenn du mit MariaDB zurechtkommst, bist du sicher flexibler, weil es halt ein offeneres System ist. Es kann natürlich sein, dass MySQL gewisse Features entwickelt. die angenehmer werden für dich, aber es kann dir mittlerweile noch umgekehrt passieren. Wie gesagt, die temporalen Datenbanken oder den Oracle-Syntax in MariaDB, den hat MySQL einfach nicht. Also es ist mittlerweile wirklich auf gleicher Höhe, würde ich mal sagen, die zwei Systeme und man kann es so ganz allgemein nicht mehr sagen, aber wenn man klassischen Open-Source-Gedanken lebt, dann muss man eigentlich sowieso MariaDB verwenden. Und sie ist gleich stark wie MySQL, hat teilweise sogar zusätzliche Features. Also würde ich im Zweifelsfall eher auf MariaDB setzen. Wenn das Ganze natürlich mit Lizenzen und so auch noch dazukommt, dann ist MariaDB unter Umständen auch kostengünstiger. Wobei, wenn man natürlich Enterprise Lizenzen bei MariaDB kauft, hat man eigentlich dieselben Geschichten. Auch in der Cloud sind die Angebote ähnlich teuer, würde ich mal sagen.

Andy Grunwald (00:56:17 - 00:56:22)

Ich muss zugeben, du hast mir ein bisschen Lust darauf gemacht, MariaDB mal auch so probieren. Und jetzt ist die Frage...

Wolfi Gassler (00:56:22 - 00:56:44)

Wahrscheinlich hast du MariaDB eh schon formell verwendet, weil wenn du auch bei deinem Linux-System einfach mal ein MySQL installierst, hast du schon MariaDB und merkst es gar nicht. Also wahrscheinlich laufen schon gewisse Dinge auf MariaDB bei dir, ohne dass du es überhaupt weißt. Und ganz konkret, zum Beispiel, ich glaube, MySQL hat immer noch kein Docker-Image, das auf dem neuen Apple funktioniert. MariaDB schon.

Andy Grunwald (00:56:44 - 00:56:46)

Das stimmt nicht. MySQL 8 läuft da drauf.

Wolfi Gassler (00:56:47 - 00:56:50)

Ja, aber was hast du für einen Flag? Du hast einen Flag dazu schreiben müssen.

Andy Grunwald (00:56:50 - 00:56:55)

Nein, nein, nein, nein. Die neueste 8032 oder 8031.

Wolfi Gassler (00:56:55 - 00:56:56)

Gibt's jetzt endlich.

Andy Grunwald (00:56:56 - 00:57:00)

Läuft auf Arm. Die 8023 läuft nicht auf Arm.

Wolfi Gassler (00:57:00 - 00:57:01)

Okay, gut.

Andy Grunwald (00:57:01 - 00:57:07)

Das sind jetzt so die beiden Versionen, in denen ich gerade rumspringe. 8023 und 8031 oder 8032.

Wolfi Gassler (00:57:07 - 00:57:09)

Da war auf jeden Fall MariaDB auch wesentlich früher drin.

Andy Grunwald (00:57:09 - 00:57:44)

Ja, MySQL hat auch ein InnoDB-Corruption-Bug, was mich halt auf der Arbeit dann halt immer auf die Palme bringt, bei 8.0.30, was in 8.0.32 gefixt wurde. Also MySQL-Version-Scheme, hat sich da eigentlich was bei Maria getan? MySQL-Version-Scheme ist ja immer so eine schwierige Geschichte, die nutzen ja keinen Semantik-Versioning. Bei denen ist das ja völlig egal, also die machen auch Breaking Changes in einer Sub-Minor-Version. Und deswegen ist das Changelock ja so wichtig, worüber ich mich am Anfang so aufgeregt habe, dass man es nicht versteht, weil die halt kein Semantic Versioning machen. Ist das bei MariaDB anders oder folgt MariaDB eigentlich dem Versioning-Schirm von MySQL?

Wolfi Gassler (00:57:44 - 00:57:49)

Guter Punkt, haben wir noch gar nicht erwähnt. MariaDB versucht Semantic Versioning zu folgen.

Andy Grunwald (00:57:49 - 00:57:54)

Okay, das ist ein Grund für mich zu wechseln. Weil bei MySQL kriege ich da langsam echt graue Haare.

Wolfi Gassler (00:57:55 - 00:58:41)

Wobei interessant finde, dass Sie sagen Versuche. Das klingt sehr interessant. Aber grundsätzlich sollte das eigentlich besser funktionieren. Und da hat sich MySQL natürlich ziemlich viele Feinde gemacht. Und jeder, der MySQL einsetzt, kennt die ganzen Änderungen, vor allem im Security-Bereich. Da hat es viele Probleme gegeben. Schon früher mit den ganzen Passwörtern und mit den Passwort-Algorithmen und wie oft Passwörter geändert werden müssen, dass Passwörter eine gewisse Länge haben müssen und dann Probleme mit den jeweiligen Clients. Da hat sich in letzter Zeit schon viel getan. Man muss auch sagen, es ist immer schwierig bei Security, weil das halt selten abwärtskompatibel ist, wenn du bessere Security einbaust. Aber da ist meistens ein MariaDB-Server etwas flexibler und noch leichter anzusprechen. Also das hat schon auch Vorteile natürlich.

Andy Grunwald (00:58:42 - 00:58:46)

Welchen Grund gibt es, bei neuen Projekten noch auf MySQL zu setzen?

Wolfi Gassler (00:58:46 - 00:59:24)

Also ich habe gerade selber kürzlich auf MySQL gesetzt, wollte eigentlich MariaDB verwenden, aber ich habe in dem Fall unbedingt virtuelle Spalten benötigt, virtual columns, die materialisiert werden und das kann in dem Fall MariaDB nicht, so wie ich das gerne hätte. Und darum habe ich MySQL eingesetzt. Ist aber schon ein sehr spezieller Use Case und jetzt im Nachhinein wäre das Feature gar nicht so wichtig gewesen. Ja, mittlerweile könnt ihr wieder auf MariaDB umsteigen und die ganzen SQL Standards mit Table Expressions, mit diesen With Statements, das kann mittlerweile MariaDB und MySQL. Das ist also auch kein Grund mehr für das eine oder andere.

Andy Grunwald (00:59:24 - 00:59:31)

Was sind Virtual Columns? Ich kenne Views, also virtuelle Tabellen, die aus SQL Statements erstellt werden. Aber was sind Virtual Columns?

Wolfi Gassler (00:59:31 - 01:00:41)

Also virtuelle Columns, in meinem Use-Case zum Beispiel, habe ich es so verwendet, ich hatte einen JSON-Datatype, wo JSON reinfließt, in MySQL übrigens binär abgespeichert, in MariaDB als Text, hat aber im Endeffekt gar nicht so große Auswirkungen. Aber was du machen kannst, du kannst aus diesem JSON-Objekt einen speziellen Wert herausnehmen und virtuell in eine eigene Spalte legen. Und dann hast du diesen Wert aus diesem JSON-Objekt immer in einer Spalte zur Verfügung und kannst den in SQL einfach ansprechen, ohne eine JSON-Function zu verwenden. Da hast du wirklich im Create-Table-Statement drin stehen, dieser JSON-Pfad, hol mir diesen Wert und setz ihn in eine eigene Spalte und das kannst du materialisieren. oder on the fly berechnen. Also wirklich auf Platte legen, extrahieren oder jedes Mal dynamisch berechnen. Und das ermöglicht dir natürlich, dass du dann auf spezielle JSON-Werte zugreifst, ohne dass du die kompliziert extrahierst, sondern du hast die einfach als Spalten zur Verfügung. Und so kannst du auch Spalten machen, die zum Beispiel irgendwas berechnen aus drei anderen Spalten oder so. Das kann einfach dein Leben etwas erleichtern, weil du das nicht jedes Mal in einer ganz komplexen Query angeben musst.

Andy Grunwald (01:00:41 - 01:00:52)

Aber ist das nicht auch super einfach machbar durch einen Trigger? Also, onInsert, onUpdate, dann den Wert, der in dieser JSON-Column geschrieben wird, extrahier den raus durch diese Query?

Wolfi Gassler (01:00:52 - 01:01:06)

Also, wenn du Trigger als supereinfach empfindest, dann ja. Ich bin kein großer Fan von Triggern. Auch, wir kennen das ja alle mit der Logik, die dann irgendwo anders liegt und auch so versteckt irgendwo anders liegt. So hast du das im CreateTableStatement drin.

Andy Grunwald (01:01:06 - 01:01:06)

Ah!

Wolfi Gassler (01:01:07 - 01:01:08)

Trigger läuft wieder irgendwo anders.

Andy Grunwald (01:01:08 - 01:01:13)

Also die Virtual Function wird wirklich beim Create Table Statement dann beim Feld.

Wolfi Gassler (01:01:13 - 01:01:50)

Definierst du diese Column, heißt, Jason, fahrt, hol mir den Wert dort raus und das machst du wirklich im Create Table Statement. Oder zum Beispiel, die Column C ist eine virtuelle Column und multipliziert Column A und B. Dann hast du das wirklich konkret immer dort drinnen und C ist immer die Multiplikation von A und B. Das kannst du also wirklich da drinnen definieren und sogar materialisieren. Das heißt, beim Einfügen wird es berechnet und dann wirklich auf Platte gelegt, das Ergebnis. Aber könntest du natürlich über einen Trigger genauso lösen, aber ich weiß nicht, ob jemand schon mal Trigger verwendet hat. Das ist meiner Meinung nach immer noch sehr, sehr, sehr, sehr mühsam.

Andy Grunwald (01:01:50 - 01:02:20)

Ich hab mal nachgeguckt, das heißt bei MySQL generated columns, nicht virtual columns, generated columns. Ah, deren Generated Column Beispiel geht auf eine Tabelle, die heißt Namen und dann hast du Firstname als einzelnes Feld, Lastname und Fullname und Fullname ist dann ein Zusammenhang von Firstname und Lastname. Das ist ja super interessant. Das wusste ich ja noch gar nicht. Aber wann wird das dann geschrieben? Wird das dann beim, auch wenn du das Materialisierst, wird das dann beim Insert Update direkt durchgeführt oder beim ersten Lesen?

Wolfi Gassler (01:02:20 - 01:02:37)

Genau, ja, also das wird einfach dann beim Einfügen dementsprechend umbenannt. Ich sehe auch gerade, dass das MariaDB mittlerweile auch unterstützt, sogar persistent. Das heißt, ich vermute fast, dass das auch kein Grund mehr wäre und könnte in dem Projekt vielleicht sogar direkt sofort umsteigen.

Andy Grunwald (01:02:37 - 01:02:46)

Okay, also du sagst, MySQL sollte man nur noch verwenden, wenn man einen wirklich speziellen Use Case hat von einem Feature, was man nutzen möchte.

Wolfi Gassler (01:02:46 - 01:03:08)

Also grundsätzlich ist jedem und jeder freigestellt natürlich was man verwendet, aber ich sehe zumindest keinen Nachteil mehr. Ganz am Anfang, da hatte MySQL schon mal die Nase vorn, weil die einfach glaube ich viel viel mehr Power hatten, also Programmierpower und Leute dahinter. Aber die sind mittlerweile auf gleicher Ebene und daher würde ich einfach die für mich sympathischere Variante empfehlen und das ist einfach MariaDB.

Andy Grunwald (01:03:09 - 01:03:11)

Sympathisch auf Basis des Open-Source-Backgrounds.

Wolfi Gassler (01:03:11 - 01:03:16)

Genau, einfach auf die allgemeine Herangehensweise, wie man umgeht, wie offen man umgeht.

Andy Grunwald (01:03:16 - 01:03:19)

Bist du ein MariaDB-Investor?

Wolfi Gassler (01:03:19 - 01:03:42)

Nein, weil ich nicht glaube, dass sich dieser ganze Open-Source-Gedanke und neben Oracle noch dazu als Konkurrent vereinbaren lässt mit einem Aktienwachstum, den man sich ja eigentlich bei Aktien gerne erwarten würde. Noch dazu in dem aktuellen Jahr sind die glaube ich jetzt an die Börse gegangen, ist auch nicht der beste Zeitpunkt. Also bin ich kein Investor in dem Sinne.

Andy Grunwald (01:03:42 - 01:03:55)

Denkst du MariaDB zieht irgendwann den Elasticsearch Trigger mit der Lizenzänderung? Oder sagst du der Monty, der Ersteller von MariaDB ist da so fest in seinem Open Source Glauben, das wird er nie tun? Orakel Wolfgang.

Wolfi Gassler (01:03:56 - 01:04:19)

Ja, also ich kann es mir bei ihm nicht vorstellen. Also es hat ja einen Grund, warum der damals bei der Oracle-Übernahme einfach gegangen ist. Also ich kann mir nicht vorstellen, dass das funktioniert. Ich könnte mir eher vorstellen, dass die Investoren ein Problem haben und vielleicht dann so viel Druck ausüben, bis er dann sagt, okay, er gründet jetzt wieder einen Fork und macht seine dritte Datenbank. Ich habe keine Ahnung, ob er eine dritte Tochter hat, ob das noch funktioniert überhaupt mit dem Namen.

Andy Grunwald (01:04:20 - 01:04:29)

Er hat noch einen Sohn und es gibt aber den Namen, also der Sohn heißt Max und der Name ist im MaxScale drin, ist ja auch ein Produkt in dem ganzen Ecosystem.

Wolfi Gassler (01:04:29 - 01:04:32)

Stimmt stimmt MaxScale gibt es auch noch ja genau.

Andy Grunwald (01:04:32 - 01:04:38)

Ich glaube dann hat er jetzt so das Kind Problem, er müsste noch ein neues Kind haben um ein neues Produkt an den Start zu kriegen.

Wolfi Gassler (01:04:38 - 01:04:53)

Und was mir ganz persönlich zum Beispiel auch sehr gut gefällt an MariaDB ist, dass sie jetzt einen nativen UUID-Datatype haben. Über UUIDs haben wir ja schon öfters gesprochen und bin ja großer Fan von UUIDs. Gibt jetzt endlich einen nativen Datentyp. Auch sehr cool.

Andy Grunwald (01:04:54 - 01:05:12)

So und jetzt schließen wir mal den kompletten Kreis wieder. Am Anfang der Episode hast du irgendwas gesagt mit, du hast Planet Scale genutzt und dann hat der Kollege oder du kamen die ganze Zeit immer mit Fehlermeldungen an. Was ist denn jetzt das Ende vom Lied? Hat Planet Scale MariaDB genutzt und du hast gedacht MySQL ist da im Einsatz oder?

Wolfi Gassler (01:05:12 - 01:08:20)

Also vielleicht zur ganz kurzen Erklärung, was PlanetScale ist. PlanetScale verwendet Vitesse und Vitesse ist ein Aufsatz auf MySQL, der von YouTube entwickelt wurde, um mit den großen Datenmengen umzugehen. Und die Leute hinter PlanetScale, die kommen eigentlich aus der GitHub-Ecke, die Gründer, ist eine sehr kleine, neue, gehostete Datenbankfirma. Und die haben im Prinzip den Vitesse-Ansatz von einer sehr skalierbaren Datenbank vereint mit dem GitHub-Pull-Request-Ansatz, dass du Schemaänderungen in deiner Datenbank immer über so ein Pull-Request machst und alles verfolgbar ist und die Datenbank das automatisch dann umsetzt, wenn der Pull-Request durchgewunken wurde und so weiter. Also eigentlich ein sehr cooler Ansatz. Du zahlst pro Read and Write in deiner Datenbank. Es ist skaliert einfach. Du musst dann nicht pro Server, pro Note bezahlen, sondern einfach wirklich pro Benutzung. Ist also wirklich ein cooles System und ich habe das eingesetzt bei einem Projekt. Das große Problem ist aber, dass Vitesse durch den Überbau, weil das ja die ganzen Statements verteilen muss über viele Knoten hinweg und wieder zusammensammeln, also das ist ja nicht so trivial grundsätzlich eine Datenbank zu verteilen und dadurch verzichtet Vitesse auf einige Funktionalitäten. sprich gewisse JSON-Funktionen, diese Table Expressions, diese With-Statements und in diesem Fall habe ich sehr viele analytische Queries, das heißt sehr komplexe Queries, die eben genau diese With-Statements verwenden. Du kannst auch andere gewisse Features gar nicht verwenden, das heißt die basieren so auf der MySQL-Version, ich glaube 5.7 oder sowas oder 5.6 sogar nur auf diesem Feature-Set. Das heißt, dir fallen extrem viele Features weg und du bekommst ständig Fehlermeldungen, wenn du einfach gewöhnt bist, im SQL-Umfeld zu entwickeln oder MariaDB schreibst eine Query und bekommst immer ein Problem, das wird nicht unterstützt. Und du bekommst eine superskalierbare, schnelle Datenbank mit einem super genialen Schema-Online-Change-Tool über diese Pull-Requests, aber du hast eben weniger Features im SQL-Syntax verfügbar. Und das muss man halt einfach wissen. Und da muss man sich auch immer genau erkundigen, wenn man so ein Online-Angebot verwendet, das einfach extrem cool ist, muss man ganz klar sagen. Aber wenn man halt diese speziellen Features braucht, hat man dort ein Problem. Und ich kann jedem PlanetScale empfehlen, weil es einfach ein super System ist. Aber wenn du diese Spezialfeatures brauchst oder diesen neueren Syntax, von SQL mit den With Statements zum Beispiel oder auch mehr Unions, die werden zum Beispiel auch nicht unterstützt, dann hast du ein Problem mit PlanetScale. Aber das ist eher so ein Analytics Problem mit Vitesse in dem Fall. Aber das zeigt schon, nur weil MySQL draufsteht und dort steht MySQL-kompatibel heißt es im Detail natürlich noch nicht, dass du eine MySQL-Datenbank zur Verfügung hast. Selber mit MariaDB, nur weil MySQL-kompatibel steht, heißt es nicht, dass du genau eine MySQL-Datenbank zur Verfügung hast. Also da gehen die ganzen Systeme immer weiter auseinander und da muss man wirklich genau checken, was benötigt man und was bieten die Systeme an.

Andy Grunwald (01:08:20 - 01:08:55)

Ich würde mal fast sagen, das Problem, was du gerade beschreibst, ist kein Datenbankproblem, das ist generell ein Proxy-Problem beziehungsweise das, was der Proxy wirklich proxyt. Ich habe zum Beispiel Erfahrung mit einem Redis-Proxy. Der Redis-Proxy hat auch nicht Support für jeden Redis-Command. Und das liegt halt einfach nur daran, anhand der Proxy-Funktionalität kann es ja auch unter anderem sein, dass die Funktionalität gar nicht supportet werden kann auf Basis wie diese Funktionen auf dem Server verarbeitet werden muss und das dann das Proxy Feature Ad Absurdum führt also da muss man natürlich gucken also aber ich meine auf der anderen Seite tauscht du natürlich Features gegen andere Features aus.

Wolfi Gassler (01:08:56 - 01:09:00)

Genau die Geschwindigkeit in dem Fall ist einfach das Hauptfeature und die Skalierung.

Andy Grunwald (01:09:00 - 01:09:08)

Oder Datasharding oder ähnliches. Du nutzt ja keinen Proxy, weil ich kann den Datenbank nicht ohne Proxy benutzen, sondern nutzt ja den Proxy, um ein anderes Problem zu lösen.

Wolfi Gassler (01:09:09 - 01:09:52)

Also ich würde jetzt Vitesse nicht Proxy nennen, die wären, glaube ich, ziemlich beleidigt, weil Vitesse ist ein Riesenteil, das dir Daten verteilt über ganz viele MySQL Instanzen hinweg für YouTube ursprünglich. Also das ist schon wesentlich mehr, aber das Grundproblem ist dasselbe. Es ist eine Zwischenschicht, die dazwischenhängt. Und die kann natürlich auch, gerade wenn es um Verteilung geht, kann man gar nicht alles ermöglichen, unter Umständen durch diese Verteilung, weil es da natürlich gewisse Einschränkungen gibt, ganz klar. Aber es ist immer das Problem mit den Marketingseiten, da steht MySQL-kompatibel, du denkst, kann eh alles und dann fangst du an, irgendwie JSON-Functions zu verwenden und kommst darauf, diese Function gibt es nicht und das funktioniert nicht. Ihr seid so der Klassiker. Gibt es natürlich alles in der Dokumentation und wird genau aufgeschlüsselt, aber liest man halt selten am Anfang, wenn man irgendein Projekt startet.

Andy Grunwald (01:09:53 - 01:10:33)

Wer liest diese denn schon? Naja gut, noch kurz als Zusatz, wir kriegen kein Geld vom Planet Skate oder ähnliches. Das war jetzt hier Wolfgangs alleinige Überzeugung. Vielen Dank Wolfgang, dass du mich erleuchtet hast mit der Maria. Meine Frage ist, gibt es eigentlich auch, jetzt wo ich gerade sage Maria, habe ich mich gerade gefragt, okay ist die heilige Maria vielleicht irgendwie auf dem Logo von MariaDB? Weil bei MySQL ist es ja ein Delfin? Nein. Und ich schaue nach, es ist eine Seerobbe. Das ist ja geil. Gibt es da eigentlich eine Story zu?

Wolfi Gassler (01:10:35 - 01:10:45)

Gibt'S garantiert, aber kenne ich in dem Fall nicht. Also wenn jemand diese Story kennt von der Robbe von MariaDB, bitte schaut vorbei in unserer Community und lasst uns wissen, was die Robbe auf sich hat.

Andy Grunwald (01:10:45 - 01:10:51)

Wenn ihr bis hierhin gekommen seid, vielen lieben Dank und wir wünschen euch noch einen schönen Tag. Bis bald.

Wolfi Gassler (01:10:51 - 01:10:52)

Bye bye. Ciao.

Shownotes / Worum geht's?