Herzlich willkommen zu einer neuen Episode im Urlaubs-Kiost-Podcast.

Während wir sonst häufig vor allem News besprechen, reden wir heute über ein Thema, das du vielleicht nicht mehr auf dem Radar hast, das du vielleicht verdrängt hast.

Und hier kommen wir natürlich wieder ins Spiel.

Wir schubsen euch gerne in nischige Sidequests oder Themen, die euch vielleicht noch gar nicht interessieren.

In der heutigen Episode springen wir in ein nicht mehr ganz so häufig thematisiertes, aber nicht ganz unwichtiges Thema.

Es geht nämlich um eine sehr berühmte Datenbank, die ein 30-jähriges Jubiläum feiert.

Und zusammen mit unserem Gast der Episode, Wolfgang Gassler, springen wir tief in den Tablespace.

Wir klären, wie man die Datenbank eigentlich ausspricht.

Heißt es MySQL?

Heißt es MySQL?

MySQL oder MySQL?

Wir besprechen die Historie, die die Datenbank zu dem machte, was sie ist.

Und auch die Grundlagen kommen nicht zu kurz.

Wir erklären, was SQL, ACID, Storage Engines und Galera Cluster sind.

Und natürlich sprechen wir auch über unsere persönlichen Highlights.

Also wir springen direkt rein.

Viel Spaß!

Sag mal Enrico, wie sprichst du eigentlich unsere Datenbank aus?

Also ich sage da MySQL zu.

Okay, und was macht er so mit dir, Wolfi, wenn du das so hörst?

Ist das richtig?

Was sagst du als Datenbank-Experte?

Es bringt mein Herz zum Glühen, würde ich fast sagen.

Also genau so, wie ich das auch richtig ausspreche.

MySQL.

Aber ich finde, das ist deutlich einfacher geworden mit MariaDB.

Da fällt es mir, also da habe ich, weiß ich nicht, fällt mir leichter, glaube ich.

Ja, bei MariaDB gibt es wenig Möglichkeiten, würde ich sagen.

Vielleicht mach ich's da aber auch noch falscherer.

Falscherer?

Naja.

Wobei, alles ist ja irgendwie richtig.

Also, da so, ist ja nur ein Name.

Ja, und es kommt auch darauf an, mit wem man sich unterhält.

Also ich könnte mir vorstellen, wenn du so im US-amerikanischen Kontext unterwegs bist, dass da auch gerne mal die MariahDB ist, genauso wie wenn du auf US-Konferenzen bist, Leute auch von Linux sprechen und ich denke mir so, ah, es heißt Linux, stop it, please.

Ja.

Ja, aber da würde ich ja schon sagen, es geht eigentlich immer darauf zurück, wer es erfunden hat und der darf entscheiden, wie man das Ganze nennt.

Insofern MySQL, zumindest ist das mein Wissensstand, Monty hat das MySQL genannt und insofern ist es eigentlich MySQL.

Da würde ich auch voll mitgehen.

Es gibt aber manchmal auch Ausnahmen, die die Regel bestätigen.

War das nicht so, dass der GIF-Erfinder es JIF ausspricht?

Und das ist ja hinderlich bekannt, dass das falsch ist.

Okay, du hast immer ein gutes Gegenbeispiel, ja?

mit euch den Podcast aufzeichnen.

Okay, ich sage jetzt lieber nicht, was ich mache.

Nein!

Also eine geheime Kombi, die ich sehr, sehr geil finde, ist Croissant, Ofen warm, Nutella, aber dazwischen noch schön Frischkäse.

Dank mir später.

Sagt dir eigentlich die Butter oder der Butter?

Dem Buddha.

Die Mutter.

Also eher der eigentlich, oder?

Bei dir, Christian

Also ich glaube, in Hessen sagt man die Buddha, der Schwabe würde sagen, kosch mir mal den Buddha-Gabbit.

Eben, eben Ja, ich bin auch bei die Butter.

Aber in Österreich gibt es ganz viele Bereiche, die auch der Butter sind.

Oder das Teller, der Teller, gibt es alles.

Herrlich.

Wunderbar.

Ja, das bringt uns direkt zur Vorstellungsrunde.

Wir haben heute einen tollen Gast, Wolfgang, wir haben jetzt deine Stimme schon gehört und einige erkennen vielleicht dich an der Stimme oder am Intro, dass du hier zu Gast sein könntest.

Aber für die Leute, die dich vielleicht noch nicht kennen, stell dich doch gerne mal vor und klär uns auf, womit beschäftigst du dich, was machst du heute so und was ist so dein Bezug eigentlich zu der Datenbank, über die wir heute sprechen?

Stimme kennen und heute habe ich gute Ausrede, dass ich mit halber Stimme leicht verkühlt, wie man bei uns sagt, unterwegs bin.

Aber wenn man meine Stimme kennt, dann am ehesten vom Engineering Kiosk Podcast, wo ich ja mit meinem Co-Host Andi aus Duisburg mich so jede Woche, ich würde nicht sagen streite, aber über viele Themen diskutiere, unter anderem auch Datenbanken, aber wir haben neben der Technik eigentlich, die für uns so ein gelöstes

...

Problem eigentlich darstellt, ganz viele Themen außerhalb der Technik auch, also sei es psychologische Themen, Team, Leadership, ganzen Prozesse rundherum, also wir bearbeiten da eigentlich alles auch abseits der Technik und natürlich auch Technikthemen, ganz klar.

Also wir haben auch ganz viele Datenbank-Episoden schon gemacht.

Jetzt wenn du fragst zu meiner Person selber, was mich so mit Datenbanken verbindet, auch wenn ich jetzt eigentlich eher so im Consulting-Bereich unterwegs bin und mehr im Leadership-Bereich, kommt mein Ursprung eigentlich schon aus der Datenbankwelt oder mein Herz schlägt für Datenbanken.

Habe ganz früher lange an der Uni an einem Lehrstuhl für Datenbanken geforscht und gelehrt und habe da auch mal so ein MySQL-Buch geschrieben, im Galileo Verlag damals, oder Rheinwerk heißt er ja mittlerweile.

Also es war so ein richtiger Wälzer, irgendwie so 800 Seiten, habe ich mit zwei Co-Autorinnen geschrieben, so ein Standardwerk.

Und seitdem brennt mein Herz natürlich schon irgendwie für Datenbanken, auch wenn ich mittlerweile natürlich weniger mit Datenbanken zu tun habe, wobei in allen Side-Projects, und das sind viele von mir, kommen natürlich immer irgendwo Datenbanken vor.

Und da bin dann ich, der sich gerne natürlich um die Datenbank kümmert oder kümmern muss meistens.

So SQL-Quals werden dann immer zu mir geschoben.

Wolfi, fix mal dies langsam oder so, du kannst es besser.

Ja, spannend.

Also das ist auch so meine erste Assoziation, wenn ich deinen Namen immer lese.

Wolfgang, der Meister der Sidequests, weil wie viele Lebenprojekte hast du?

Ich glaube, das ist schon fast im zweistelligen Bereich, oder?

Na ja, wenn es nach den Domains geht, auf jeden Fall.

Also Domains sind sicher um die 40 oder so, die ich habe.

Jetzt Projekte, die wirklich live sind und Startups, ich weiß nicht, ob es zweistellig ist, aber im höheren einstelligen Bereich auf jeden Fall, ja.

Das wäre doch auch mal spannend, wer von euch mehr Domains hat, weil von Enrico weiß ich, dass er Domains auch hortet, wie manche andere Leute Hardware horten.

Wie viel hast du?

Das müsste ich jetzt bei mehreren Providern einmal durchgucken.

Okay, das sagt halt schon viel über dein Domain-Kaufverhalten aus, wenn es nicht ein Provider ist, sondern direkt mehr.

Ja, aber man muss doch erstmal irgendwie den Namen sichern, gucken, wie man sich mit dieser Domain so fühlt.

Da muss man so die ersten drei Jahre vergehen lassen, um zu gucken, ob man immer noch genügend Gefühle für den Namen hat oder ob es sich verschwendet anfühlt und dann kann man so langsam anfangen, das reifen zu lassen.

So ist zumindest bei mir häufig der Prozess.

Ich habe eine neue Regel: Solange es kein Produkt gibt, was wirklich funktioniert und quasi online geschaltet werden kann, gibt es keine Domain.

Ja, ich sollte dich mit meiner Frau verbinden.

Die hat auch gesagt, ich darf keine neuen Power-Tools mehr kaufen, bevor ich ihr nicht mindestens sagen kann, was ich damit genau umsetzen möchte.

Dadurch ist der Schuppen etwas aufgeräumter, aber diese Art der Beschränkung möchte ich bei meinen Domain-Impuls-Käufen noch nicht zulassen.

Ja.

Also ich mache das so, immer wenn ich eine neue Domain kaufe, habe ich mir jetzt angewöhnt bei den letzten 1, 2, mache ich Marie Kondo-Style-mäßig mal mein Admin-Panel auf und gucke, ob ich die anderen noch brauche.

Dann stelle ich dann traurig fest, dass es Domains gibt, die ich seit Jahren nicht verwende und dann entsorge ich eine, bevor ich die nächste kaufe.

Aber ist das bei Marie Kondo nicht so, dass sie sagt, hey, mach dir das noch Freude und ich gucke mir den Namen an und denke mir, was für eine geile Idee, was war das für, also wie konnte ich diesen coolen Gedanken haben und das macht mich dann glücklich, auch wenn ich es nicht nutze.

Er ist bei mir anders.

Ich schäme mich dann und denke mir dann so, das ist verschenktes Potenzial und jetzt gehe ich mich duschen besonders lange, um das abzuwaschen.

Oh Mann, oh Mann.

Wie ist die Situation in der Welt?

Ja, okay, also in deinen Site-Projects ist natürlich auch eine Datenbank bei dem einen oder anderen Projekt auch relevant, ist natürlich klar.

Also du machst vor allem ja auch, glaube ich, viel Web-Anwendung, wenn ich es richtig weiß.

Und da ist natürlich auch, muss man irgendwo Daten persistieren.

Obwohl ich das jetzt für eine schlechte Idee halte grundsätzlich, aber macht man trotzdem oft.

Und da kommen schon ordentliche Datenmengen zusammen.

Also zeig mir ein Projekt, wo du eigentlich keine Datenbank mehr hast.

Und sogar wenn du irgendwie eine Handy-App hast, hast du eine SQLite auf deinem Handy als kleine Embedded-Datenbank.

Ja.

Also Datenbanken hast du heutzutage meiner Meinung nach überall.

Ich weiß, die Frage soll man nie stellen, aber hast du ein Lieblings-Side-Projekt?

Also die Frage nach dem Lieblingskind.

Ist sehr schwierig, aber ich würde mal sagen, eines der längsten Side-Projects, die konstant jetzt wirklich durchgehen, ist wirklich das Engineering-Kiosk, weil der Andi mich einfach immer pusht scheinbar, muss man eben lassen.

Und das machen wir jetzt, glaube ich, fast drei Jahre.

Das heißt, konsistent jede Woche eine Episode raushauen und euch brauche ich wenig sagen, wie viel Arbeit das ist.

Also das ist sicher ein Projekt, was auf jeden Fall sehr wichtig ist und sehr viel Zeit in Anspruch nimmt.

Absolut.

Und da leistet ihr natürlich auch einen wertvollen Beitrag zur deutschsprachigen Podcast-Bubble, muss man mal ganz ehrlich sagen.

Denn so haben wir uns auch eigentlich kennengelernt.

Also ihr habt nicht nur selbst einen Podcast, sondern ihr kuratiert auch selbst eine Liste an deutschsprachigen Tech-Podcasts.

Und da habt ihr einfach ein paar Leute angeschrieben und da ist echt viel gutes Zeug bei.

Und davon profitiert man natürlich, wenn man auf der Seite ist und entdeckt da, was es sonst so Spannendes draußen gibt.

Genau.

Also eigentlich war der Ursprung, dass wir uns überlegt haben, wir machen einen Podcast, einen technischen Podcast, auch so ein bisschen Metademen, weil es gibt da draußen noch keine anderen Podcasts.

Dann haben wir gestartet und haben uns überlegt, eigentlich schauen wir mal, was es sonst gibt und plötzlich haben wir einen Podcast nach dem anderen gefunden.

Dann haben wir gedacht, okay, da braucht es eindeutig eine Liste und jetzt haben wir eine Liste gleich von 60 Podcasts auf der Liste, die wirklich deutschsprachig im Tech-Bereich unterwegs sind.

Und ja, ist auch so eine Anlaufstelle geworden.

Also wenn man langweilig ist, wer zu wenig Podcast noch hat, zu wenige Episoden zum Hören, also hoffentlich haben alle da draußen ja mindestens 60 weitere Episoden in der Playlist zum Hören.

Also wer da noch weniger als 60 hat, findet dort sicher noch ein paar Podcasts, die man hören kann aus allen Bereichen von Security bis zu Gaming haben wir alles drin.

...

...

packen wir natürlich auch für die geneigten Zuhörenden in die Shownotes.

Ja, heute geht es um MySQL, wie wir jetzt festgelegt haben und ich glaube, da fangen wir einfach mal mit einem Einstieg ein, um wirklich alle abzuhören, denn ich könnte mir vorstellen, dass unter unseren Zuhörenden es Leute gibt, die das alles schon längst wissen, die jetzt vermutlich schon skippen und sagen, jetzt kommt doch mal zum Punkt.

Mancher anderer sagt vielleicht, was ist eigentlich dieses relationale Datenbankverwaltungssystem und was bedeutet das?

Vielleicht beginnen wir mal damit, damit wir alle dasselbe Verständnis haben.

Also Wie würdest du das definieren?

Was ist das zusammengefasst?

Ich bin mir gar nicht sicher, ob das alle wissen, weil es gibt ja auch keine so Datenbanken wie MongoDB, die eigentlich sehr beliebt sind, immer noch, würde ich mal sagen.

Und wenn man natürlich mit so einem Datenbanksystem einsteigt, hat man eigentlich wenig Berührungen mit einem klassischen relationalen Datenbankmodell, das sich ja eigentlich jetzt so durchgesetzt hat seit den 60er Jahren, würde ich fast sagen, 70er Jahren.

So alt ist das Ganze ja schon.

Und das ist eigentlich das, was wir so als klassische Datenbank kennen.

Also das hat damals der Edgar Cott irgendwann mal vorgestellt in den 70er Jahren mit einem Paper.

Da waren so ein paar Grabenkämpfe, da hat es noch ein paar unterschiedliche Modelle gegeben und da hat sich dann das klassische relationale Modell eigentlich durchgesetzt.

Aus dem Grund, weil das relationale Modell eigentlich das erste Datenbankmodell war, das gesagt hat, unsere Daten sind getrennt von der Abfragesprache.

Also früher hat man die Daten immer so abgespeichert, wie man sie auch gebraucht hat,

Hm?

wie wenn man sie jetzt in Variablen oder so abspeichern würde.

das war natürlich sehr aufwendig, wenn da das Ganze auf Band gespeichert worden ist wie früher, diese rotierenden Bänder, wie man sie noch kennt aus irgendwelchen alten James-Bond-Filmen oder so da irgendwas zu finden, wenn man da hin und her spulen muss und so weiter und dann ist das nur irgendwie in dem Muster abgelegt, wie man das halt braucht wie man die Anfragen macht und das war natürlich nicht sehr flexibel und das relationale Datenbankmodell hat das eigentlich aufgeweicht, dass man einerseits eine Anfragesprache hat SQL in dem Fall und das relationale Modell, wie das abgespeichert ist und dann kann man je nachdem, wie man es braucht, der Buchhalter braucht es in einer anderen Form als vielleicht die Programmiererin vom User Interface im Web, kann dann über die richtigen Anfragen die Daten so bekommen, wie man sie eben gerne hätte.

Und im Hintergrund liegen halt ganz klassisch diese Tabellen, wie man sie kennt oder Tupeln, wie sie offiziell heißen, wo man dann definiert, ich habe diese Spalten mit diesen Typen, sollen Integer wert sein, sollen numerischer wert sein, sollen String sein, kann da auch noch Checks machen, auch komplexere Checks mit Fremdschlüsselbeziehungen.

Das kennen auch die wenigsten, muss man sagen.

Also ich kenne ganz viele ProgrammiererInnen, die eigentlich nie was mit Fremdschlüsseln zu tun gehabt haben, das vielleicht mal gehört haben, so im Hintergrund, aber dass man wirklich sagen kann, zwei Tabellen hängen in irgendeiner Form miteinander zusammen und eine Rechnung darf zum Beispiel nur existieren, wenn es auch den Kunden dazu gibt mit der Kundennummer.

Solche Fremdschlüsselbeziehungen sieht man, muss man zugeben, auch sehr selten.

Also wenn du jetzt auf irgendwelche Open-Source-Gitarr-Projekte schaust, sieht man da ganz oft klassische Tabellenstrukturen, MySQL wird verwendet, aber dass da mal Foreign Keys, Fremdschlüsselbeziehungen sinnvoll definiert sind, das passiert eigentlich seltener, als man denkt.

Und seit den 70ern hat sich das dann eben weiterentwickelt.

Ganz klassisch war da Oracle und DB2.

Das waren so die zwei großen Player.

Und irgendwann dann in den 90ern ist da Monty um die Ecke gekommen.

Also das ist so der Vater von MySQL, könnte man sagen.

Der hat das auch damals definiert, den Namen.

Also Mai ist die Tochter von ihm, die heißt so.

Drum heißt es Mai SQL.

Hat also nichts mit meiner SQL-Datenbank zu tun, sondern wirklich mit seiner Tochter.

Und der hat damals eine Datenbank entwickelt, die Open Source und kostenlos war.

Und das war eigentlich die große Neuerung damals, weil davor hat es nur Oracle gegeben und DB2 und da hast du richtig viel Geld ablegen müssen, damit du die bekommen hast.

Hm.

Also ist ja immer noch so, Oracle lässt sich das auch zahlen.

Auch früher war das Modell schon pro CPU.

Das heißt nicht, wie viele User oder Daten du hast, sondern meistens auf wie viele CPUs du das laufen lässt.

Mittlerweile gibt es da mehrere Modelle natürlich.

Aber da hast du schon mal irgendwie eine Million oder so abgelegt nur für die Datenbank.

Und dann kommt da jemand um die Ecke und sagt, hey, ich bringe da eine kostenlose Datenbank auf den Markt, Open Source.

Und das war eigentlich die große Änderung damals, weil heutzutage würde ich sagen, fast alle Datenbanken, die es so gibt am Markt, die so auch neu aufbabbeln, gibt ja immer wieder mal so die eine oder andere Datenbank, die ist Open Source und die ist kostenlos.

Also es ist fast so eine Infrastruktur, die bereitgestellt wird und das kostenlos.

Und das war früher absolut nicht der Fall und da war MySQL einfach ein kompletter Vorreiter als kostenlose Datenbank.

Ja, stimmt.

Und da kann ich mich so daran erinnern, dass als ich das erste Mal am Rechner saß und das auch mitbekommen habe in meinem Familienkreis, Leute, die auch in der EDV, sagt man ja früher, gearbeitet haben, da war das immer extrem kritisch und teuer, wenn man Datenbanken hatte.

Also das waren dann immer teuer eingekaufte Produkte und das ist ja schon sehr rebellisch in den 90ern, einfach so eine Datenbank für Laura auszubringen.

Kann ich mir vorstellen, dass es da einige Leute gab bei Oracle und Co., die das nicht so toll fanden.

Ja, die haben das eher eingeschaut.

so belächelt.

Also ich kann mich noch erinnern, in den 90ern, mein Bruder, der ist zehn Jahre älter, war aber auch schon in der Programmierung tätig, der hat das auch immer so belächelt und der hat immer so gesagt, ja, MySQL ist ja nur ein Adressbuch, was irgendwie SQL versteht.

Also viel sicherer kann man da ja Daten eigentlich nicht ablegen, als ein paar irgendwie Adressdaten.

Hat sich mittlerweile auch geändert, war teilweise damals vielleicht auch so.

Aber der große Unterschied, der eigentlich auch noch zusätzlich zum Preis war, war, dass MySQL super einfach zu installieren war.

Das heißt, ich kann mich da auch noch erinnern, in den 90ern, da war ich noch in der Schule teilweise, aber ich habe es geschafft, eine MySQL-Datenbank aufzusetzen.

Ich hätte nie im Leben eine Oracle aufsetzen können.

Ich habe mal so ein Oracle-Handbuch damals in den 90ern bekommen und ich habe einfach Nüsse verstanden, wirklich null.

Und MySQL hast du installiert, das war sicher einfach und vielleicht war es nur ein Telefonbuch damals, aber es hat funktioniert.

Es war ein funktionierendes Telefonbuch und für irgendwelche Internetprojekte leicht ausreichend und vor allem kostenlos.

Weil wenn du da mal ein Internetprojekt startest, du hast halt keine 100.000 Euro mal so auf der Seite, wo du einfach eine Oracle oder DB2 kaufen kannst, damit du da irgendwas abspeichern kannst.

Und da hat MySQL natürlich komplett den Markt gedreht damals.

War auch so die erste Datenbank, mit der ich mich damals beschäftigt habe.

Ich habe gerade so ein bisschen darüber nachgedacht, als du erzählt hast, wo das Projekt eigentlich herkam.

Da ist direkt eine sehr starke Erinnerung an meine Berufsschulzeit hochgekommen.

Mal gucken, ob es Enrico genauso geht.

Normalisierung von Datenbanken.

Hier, Herr Barz, erste Normalform, bitte, an die Tafel.

Ich habe mich damals schon dem verweigert und gesagt, guck mal, wenn ihr das zu Tode normalisiert, habt ihr Performance-Impacts und das geht manchmal vielleicht, also manchmal ist nicht normalisieren auch optimieren.

Ja, das ist eine Diskussion, die habe ich mit meinem Datenbanklehrer auch geführt, da kann ich mich auch sehr lebhaft daran erinnern.

Ja, ja, ja und wahrscheinlich bin ich dann rausgeflogen deswegen kann ich dir nicht mehr sagen, wie es ausgegangen ist

Kleiner Funfact, es gibt fünf davon.

Ich kannte nur die ersten drei.

Aber die Berufsschulzeit ist bei mir halt auch schon eine zweistellige Anzahl an Jahren fast schon her und vermutlich hat sich da einfach ein bisschen was getan seitdem.

Ja, die ersten drei sind ja eigentlich so die essentiellen, würde ich fast sagen.

Die Normalform 1 ist übrigens wirklich easy, die sagt ja nur, dass man eigentlich in einem Feld nicht zwei Informationen speichern sollte.

Also du sollst nicht in einem Feld jetzt in Vornamen, Nachnamen und die Adresse rein speichern, sondern sollst halt einfach eigene Spalten machen, das ist ja relativ easy.

Und ihr habt natürlich schon recht, also diese Normalisierungssache, die wurde auch mal so dämonisiert, auch von der Webwelt, weil die halt so eher nicht skaliert und wenn du dann immer in Google-Sphären oder so denkst, dann hast du natürlich irgendwie diese Duplizierung schon im Kopf und irgendwie musst du ja auch Daten teilweise duplizieren, wenn du sie auf mehreren Servern haben willst.

Hm.

Also das ist dann schon ein bisschen aufgeweicht worden, ist heutzutage, würde ich mal sagen, kein Problem mehr, einfach aus dem Grund, weil die Geschwindigkeit viel ein kleineres Problem mittlerweile ist.

Also wenn du eine MySQL-Datenbank hast, dieses Projekt, musst du mir erstmal zeigen, wo du dann duplizieren musst und denormalisieren musst, damit es noch in einigermaßen sinnvollen Sphären sich bewegt, geschwindigkeitstechnisch, glaube ich, ist schon eine Seltenheit.

Und dann gibt es vielleicht auch noch andere Maßnahmen, die man dann treffen kann, um das zu optimieren.

Also dieser Kampf ist meiner Meinung nach ausgefochten.

Zumindest habe ich ihn in der Realität weniger erlebt.

Zu Anfangszeiten, wie gesagt in den 90ern, wo du halt um jeden CPU-Cycle irgendwie gekämpft hast und dann der Webscale ein anderer Scale war früher, weil da, wenn du 1000 User hattest, plötzlich, das war ja, eine Oracle-Datenbank hatte nie 1000 User oder ganz selten 1000 User.

...

Hm.

Hm.

Eindeutig, ja.

Aber die Experience war wirklich eine tolle, dass das so einfach zu installieren war.

Da kommen wir bestimmt später noch drauf zu sprechen, was dazu führte, dass die Datenbank so beliebt geworden ist.

Also die waren ja einfach für andere Use Cases auch ausgelegt.

Da hat sich schon viel, viel geändert.

Ich habe auch mal versucht, in meiner Berufsschulzeit mich mit Oracle auseinanderzusetzen.

Ich glaube, mein Abschlussprojekt war die Migration eines Nagios Monitoring-Systems auf eine neue Plattform, wo eine Oracle 11g R2 drunter lag und da war die Lernkurve echt hoch.

Da hat mein Kopf sehr viel geraucht in der Zeit und das war bei MySQL bedeutend einfacher.

Also da konnte ich mit einzelnen Buffeten wirklich ganz schnell eine laufige Datenbank hinbekommen.

Und ja, heutzutage ist es vermutlich nicht mehr so relevant, so viel zu normalisieren.

Also ich kenne ganz viele Leute, die halt sagen, auf alles, wo ein Queue gemacht werden muss, da feuern wir irgendeinen Cache-Layer drauf.

Also statt zu normalisieren, schmeißt man heute überall Cache-Layer drauf, ist meine subjektive Wahrnehmung.

Es war ja auch ganz interessant, warum eigentlich Oracle viel komplexer war.

Die war natürlich älter, ist schon klar, und hatten mehr Features.

Aber geschichtlich gesehen ist das eigentlich auch sehr interessant, weil früher war die Hardware wesentlich teurer und eigentlich das begrenzte Gut.

Und du hattest ganz viele Personen, Menschen, die sich darum kümmern konnten.

Das heißt, du hast eigentlich optimiert, möglichst wenig Hardware zu brauchen und Menschen hattest du genug.

Das heißt, du konntest genug Database Administrators einstellen, die sich dann kümmern um diese Datenbank und die Datenbank auf den kleinen, also klein war die Hardware ja nicht, aber schwachen Hardware, das möglichst zu optimieren.

Und darum gab es bei Oracle tausende Schrauben, die du einstellen konntest,

Hm.

oder gibt es wahrscheinlich immer noch, weil du hast ja 100 Leute, die sich um diese Schrauben kümmern können.

Und es wäre teurer gewesen, zwei Racks dazu zu stellen, als eine zusätzliche Person zu hiren früher.

Und das hat sich natürlich mittlerweile auch komplett umgedreht, dass die Menschen viel, viel teurer sind, Gott sei Dank, muss man sagen.

Und die Hardware jetzt das Billige ist und du daher natürlich anders skalieren kannst und die Einfachheit viel, viel wichtiger ist, als dass du irgendwie tausende Schrauben hast, sondern es muss möglichst einfach installierbar sein, wartbar sein, damit du weniger Administratoren brauchst.

Und heutzutage ist es ja schon so, dass man eigentlich kaum mehr diesen klassischen Job von einem Datenbankadministrator hat oder der zumindest immer mehr abnimmt und das mehr dann ins Development hineinrutscht, dass die ProgrammiererInnen sich vielleicht auch selber kümmern oder Teile zumindest übernehmen von der Datenbankwelt und das mitbetreuen.

Und das ist natürlich nur möglich, wenn die Datenbanken das dementsprechend auch möglichst leicht machen.

Jetzt hast du ja gesagt, das Projekt ist von Monty gegründet worden.

Wo kommt der Name eigentlich her?

Ich glaube, der heißt ja eigentlich Michael Videnius.

Oder ist das ein Spitzname dann?

...

Genau, das ist ein Spitzname.

Ich kenne ihn eigentlich nur unter Monty.

Also wenn du ihn auf Konferenzen oder so triffst, spricht nur jeder von Monty.

Ich glaube, er ist aus Schweden, wenn mich jetzt nicht alles deutscht, zumindest irgendwo aus Skandinavien.

und es waren glaube ich drei Gründer, David Exmark und Alan Larson, die MySQL gegründet haben, aber der Monty war halt die Figur vorne dran und der sich um alles gekümmert hat.

Ich glaube, er hat auch einen Großteil programmiert und das ist die Person, die sich halt herumtreibt und die jetzt auch MariaDB natürlich irgendwie weiter treibt, wobei MariaDB jetzt schon viel breiter aufgestellt ist, muss man auch sagen.

Genau, weil MySQL ist passiert, was einigen anderen Projekten auch passiert ist.

Sie wurden irgendwann mal aufgekauft von der Firma, aber dazu später noch mehr.

Wir sehen, dass 2006 auch eine Firma gegründet wurde, die für die Geschichte auch ganz relevant ist, und zwar ist es Percona.

Das war ja eine US-amerikanische Firma.

Ja, Bacona war eigentlich so eine Firma, die unter anderem gegründet worden ist aus dem

Was hat es damit auf sich?

Consulting heraus.

Das Problem an MySQL war ja, dass es irgendwie keine große Firma wie Oracle hinter einer Datenbank gibt und wenn du natürlich jetzt als professionelle Firma eine Datenbank einkaufst, dann willst du da ja Support haben, willst du Hilfe haben, wenn du irgendwie ein Problem hast.

Und das gab es bei MySQL nicht so richtig.

Es gab schon die MySQL AB natürlich, die im Hintergrund war, aber Bacona hat sich dann eigentlich auf die Fahnen geschrieben, wir können euch helfen, wenn ihr wirklich ein Problem habt mit MySQL.

Und zwar, ihr braucht gar nichts zahlen, wenn ihr ein Problem habt, ruft ihr an, dann schließt ihr einen Vertrag ab und wir können euch sofort helfen.

Also so richtig Notfall-Hotline-mäßig.

Hm?

Und damit sind die eigentlich groß geworden und Bacona hat dann später auch den eigenen Bacona-Server released, also die haben eine eigene Datenbank gemacht, wobei eigene ist natürlich jetzt unter Anführungszeichen zu setzen, weil das eigentlich nur eine MySQL, also nur, auch wieder unter Anführungszeichen, eine MySQL war, die mit gewissen Patches, gewisse Einstellungsmöglichkeiten.

Also die haben so ein bisschen herumgeschraubt an MySQL, waren da auch sehr tief drin in der Entwicklung, sind immer noch sehr tief drin in der Entwicklung.

Also die gehören wirklich eigentlich zu dem ganzen Ecosystem dazu von MySQL, MariaDB und was alles rundherum ist.

Die haben sich dann auch darum gekümmert, dass es zum Beispiel sinnvolle Backup-Strategien gibt, also für den Enterprise-Bereich vor allem.

Amen.

Wie kann ich ein Backup machen, ohne dass ich die MySQL-Datenbank stoppen muss?

weil das war ja der Klassiker, wenn du einen MySQL-Dump aufrufst, dann wird mal die ganze Datenbank gelockt, nichts funktioniert mehr quasi und dann machst du das Backup und wenn es fertig ist, unlockst du die Datenbank wieder, was natürlich im produktiven Einsatz unmöglich ist.

Und die haben das Extra-DB-Backup herausgebracht, wo dann wirklich über das Binär-Log die Daten herausgeschrieben, beziehungsweise wird ein Snapshot gemacht und dann über die Binär-Daten werden die restlichen Daten, die sich in der Zwischenzeit geändert haben, nachgezogen.

Und damit sparst du dir dieses Locken, dieses Stoppen der Datenbank.

Also das war sicher auch, gerade wenn man im Enterprise-Bereich ist, natürlich ein Killer-Feature, weil wenn du das produktiv sinnvoll einsetzen willst, brauchst du einfach sowas, dass du incremental Backups machen kannst, die nicht Locking sind.

Und da hat bei Kona eben auch eine Möglichkeit geboten.

Und mit dem sind sie eigentlich dann in dieses ganze Ecosystem reingewachsen, haben natürlich dann auch Clusterlösungen und so betreut.

Alles, was so Enterprise-Features sind, haben aber eben auch mitentwickelt in der Community.

Und das war ganz klar sichtbar, wenn du auf MySQL-Konferenzen warst.

Der Peter Zeizeff, das ist so der Kopf von Bacona, der war immer vor Ort, der hat Talks gehalten, der hat wahnsinnig gut sich ausgekannt mit allen Variationen, allen Varianten.

Und auch heutzutage noch, sein Standard-Talk ist immer der Unterschied zwischen MySQL und MariaDB.

Den hält er, glaube ich, auf jeder Konferenz immer abgedatet.

Einfach, was sind aktuell die Unterschiede.

Also der kennt sich wirklich in der Tiefe aus.

Und das ist schon eigentlich fast ein Hauptentwickler geworden, würde ich fast sagen.

Ja, spannend.

Auch schön, dass das heute immer noch relevant ist.

Zu MariaDB kommen wir dann später jetzt noch.

Jetzt haben wir es gerade so ein bisschen auch von Backups gehabt und auch von, wie so eine Datenbank eigentlich funktioniert.

Du hast von einem Binärprotokoll gesprochen und häufig spricht man da auch von einer sogenannten Storage Engine.

Da habe ich, glaube ich, bis heute kein richtiges Verständnis von, was es eigentlich bedeutet.

Also ich habe schon ein paar Mal gemerkt, dass ich die wechseln muss bei manchen Anwendungen, weil die nicht kompatibel zueinander sind.

Aber schlau uns doch mal auf, was genau ist die Aufgabe einer Storage Engine?

Auch das war eigentlich damals relativ neu, dass MySQL so ein modulares System verwendet hat, dass du eigentlich die Datenbank an sich hast, das SQL-Interface, da kommt die SQL-Anfrage rein, dann wird die verarbeitet, dann gibt es Indizes und so weiter.

Aber wie die Daten an sich dann gespeichert sind, das entscheidet die Storage Engine.

Und du kannst MySQL heute noch, wie damals auch, mit unterschiedlichen Storage Engines betreiben.

Und mittlerweile ist die InnoDB Storage Engine eigentlich der Standard.

Da hast du referenzielle Integrität, also diese Fremdschlüssel, die wir schon erwähnt haben.

Du hast Transaktionen, alles was so eine gute Datenbank eigentlich ausmacht.

Und ganz ursprünglich war aber MySQL mit der ISAM, also MyISAM Storage Engine unterwegs.

Das war die erste, die klassische.

Und die war da wesentlich schwächer, würde ich mal sagen, auf der Brust, weil die hatte keine Transaktionssicherheit, die hatte kein ACID, die hatte keine Sicherheitsgarantien in dem Sinne.

Aber sie war super schnell und sie war halt gratis und sie war verfügbar und sie war einfach und man hat sich nicht groß irgendwie den Kopf zerbrechen müssen.

Das heißt, ideal für diesen simplen Use Case im Web, mach irgendeine Web-Anwendung, brauchst eine Datenbank im Hintergrund.

Im schlimmsten Fall fehlt mir da mal eine Row, also eine Zeile oder sowas.

Das ist ja kein Banksystem.

Haben sich alle darauf eingelassen.

Und später ist dann die InnoDB dazugekommen.

Da ist es parallel lange gelaufen.

Dazu geheißen, okay, für die sicheren Anwendungsfälle, wo deine Daten möglichst sicher sein müssen, verwende InnoDB.

Für die, wo es schnell gehen muss, verwende MyISM.

Und mittlerweile ist eigentlich die InnoDB so stark geworden und so schnell, dass die InnoDB die Standard-Engine ist, die heutzutage eigentlich überall verwendet wird.

und die auch weiterentwickelt wird, die quasi eigenständig ist.

Also man könnte sie auch irgendwo anders entwickeln und man könnte sie auch irgendwo anders einsetzen, in einer anderen Datenbank theoretisch.

Und es gibt mittlerweile auch Spezial-Storage-Engines, so wie MyRocks, die von Facebook entwickelt worden ist, zum Beispiel für ganz spezielle Anwendungsfälle.

Das heißt, du hast einen MySQL-Server, der ganz normal läuft, aber im Hintergrund unter der Haube wird dann MyRocks verwendet, um Daten zu speichern und da hat halt Facebook, die auch MySQL immer schon eingesetzt haben, das als Plugin, als Storage Engine entwickelt, um dann bei sich MySQL weiterverwenden zu können, aber mit einer speziellen Storage Engine, die darauf optimiert war, möglichst viele Daten speichern zu können, schnell, das ist so ein hierarchisches System, das hat früher dann auch stark auf RAM bzw.

auf SSDs gesetzt, was früher noch nicht so der Standard war.

Da hat Facebook sehr früh damit angefangen und die haben dann eine Optimierung dafür geschrieben.

Und so kannst du modular das austauschen.

Es gibt auch eine Storage Engine, die einfach, ich glaube Blackhole heißt sie sogar, die ist halt einfach eine Storage Engine, die nichts speichert.

Da kannst du alles reinschreiben, aber es wird halt nichts gespeichert.

Ist halt ein schwarzes Loch.

Okay, warum?

Also, wenn du die Daten nicht speichern willst, dann verstehe ich nicht ganz, warum man dann überhaupt eine Datenbank führt.

Also, wo ist da der Use Case?

Ja, das ist so ähnlich wie DefNull.

DefNull bringt dir ja eigentlich auch wenig, aber wenn du natürlich gewisse Sachen testen willst, wo es dir egal ist, ob das jetzt geschrieben wird im Hintergrund, wenn du davor die ganzen Stacks testen willst oder deine Applikation oder ganz viel schreiben willst in deiner Applikation, um irgendwas zu testen, dir ist aber egal, ob das im Hintergrund jetzt gespeichert wird, dann kannst du natürlich sowas verwenden.

Aber das hat eher natürlich nur für Testzwecke geeignet.

Okay, ja, wollte gerade sagen, das klingt irgendwie nach Anwendungstesting.

Du willst mal was verproben, mal gucken, wie deine Anwendung prinzipiell funktionieren würde.

Was ist das Klassische an den Datenbanken?

Okay, spannend.

Wieder was gelernt heute.

Storage Engines, von denen ich überhaupt nicht wusste, dass es die gibt.

Alles so der Nischenbereich, weil klassischerweise InnoDB ist so ein Schlachtschiff, was eh alles abfackeln kann.

Und dann nimmst du einfach InnoDB und das funktioniert im Normalfall.

Jetzt haben wir gerade schon auch gehört, Anforderungen für große Umgebungen.

Ich weiß nicht, wie würdest du das machen, Enrico, wenn du irgendeine super wichtige Anwendung ausrollst, die hochverfügbar sein soll, da würdest du vermutlich zum Kubernetes greifen, so wichtig einschätzen und dann auch schön die Datenbank im Container laufen lassen, oder wie macht man das?

Naja, also wenn du mich fragst und ich für den Betrieb verantwortlich bin, dann würde ich erstmal versuchen, so stateless wie möglich zu sein, damit ich das Problem nicht habe.

Nein, aber ansonsten hängt es natürlich davon ab, wo bist du unterwegs, wie groß sind irgendwie die Daten, was ist da irgendwie so mit drin.

Ich finde, wir hatten vorhin so ein bisschen darüber gesprochen, dass so damals eher das Problem von Rechenleistung bestand.

Du hattest dann noch gesagt, ja, heute ist vielleicht die Hoheit über die Datenbank mit Teil in einem cross-funktionalen Team statt in vorher vielleicht einzelnen Datenbank-verantwortlichen Team.

Und damit, finde ich, machen sich ein paar ganz neue Herausforderungen auf.

Und zwar, wer ist eigentlich für welchen Teil der Datenbanken zuständig oder für welchen Teil der Daten zuständig?

Gerade dann mit Microservices, wo dann vielleicht auch noch mehrere Services sind, die datenhaltend sind, die dann aber auch unabhängig voneinander vielleicht agieren.

Da fand ich das mal ganz interessant, wie das bei, hatte ich mal auf einem Meetup von einer Otto-Gruppe erfahren, die haben ihren Webshop im Endeffekt umgebaut und da war es dann so, dass sie gesagt haben, jeder, der hier Daten verarbeitet, hat seine eigene Datenbank für seine eigenen Microservices zu haben.

Das ist zwar dann, ich sag mal, Platzverschwendung oder ressourcentechnisch nicht das Optimalste, aber von der Verantwortlichkeit ist es halt klar abgegrenzt, wenn ich Daten speichern möchte und für irgendwo anders herkriege, dann habe ich meine eigene Datenbank zu betreiben.

Ja.

Und wenn ich dann so ein Konstrukt halt fahre, dann hätte ich gerne einen Automatismus, der sich darum kümmert.

Also wenn wir schon bei Kubernetes sind, dann vielleicht einen Operator, der sich vernünftig um die Datenbank kümmert, denn ich möchte eigentlich mit der möglichst wenig zu tun haben oder zumindest vom Lifecycle her sagen können, ich hätte jetzt gerne eine, dann wird die auch gebackupt und wenn die vergrößert werden soll, dann soll das ein Automatismus tun, der das irgendwie gut kann.

Und das impliziert dann, dass vielleicht auch Infrastruktur da sein muss, die damit um kann, die dynamisch ist und irgendwie all so diese Dinge mit sich bringt.

Aber ich glaube, das ist eine ganz andere Frage zu, wie mache ich das in so einem großen Konstrukt versus ich habe da mal einen WordPress-Blog.

Wie ist die Situation in der Cloud-Bank?

verwenden.

Also es ist auch so ein föderierter MySQL-Cluster.

Die Test ist damals von YouTube entwickelt worden.

Also es ist auch grundsätzlich Open Source, kann man einsehen.

Aber ich würde auch sagen, dass die Datenbanken eher kleiner werden heutzutage.

Und ich habe das auch mal miterlebt in einer sehr großen Firma, so eine Migration oder eine Teilmigration, weil im Endeffekt ist es nie migriert worden von einer großen MySQL-Datenbank, von einem Cluster auf kleinere Datenbanken.

Und das war fast ein Ding der Unmöglichkeit.

Also dieses große Ding hat man nicht anrühren dürfen.

Das war irgendeine alte MySQL-Version.

Keiner hat sich getraut, die irgendwie abzudaten.

Die Slaves, also die Replikationen waren schon auf neueren Versionen, aber dieses Ur-Ding in der Mitte, das war ein Heiligtum und das hat man irgendwie probiert, am Leben zu erhalten.

Und ich habe es zumindest in meiner Zeit über die vielen Jahre nicht erlebt, dass das komplett wegmigriert werden hat können.

Und daher finde ich den Ansatz, dass man kleinere, abgeschlossene Team-Datenbanken vielleicht hat, dass das absolut Sinn macht, wenn man sich sowas in der Architektur eben irgendwie leisten kann.

Du hast natürlich den Nachteil, du kannst jetzt keinen Join machen zwischen Team A und Team B.

Das funktioniert natürlich nicht, beziehungsweise du musst es komplizierter machen.

Du musst die Daten zuerst reinholen in deine Datenbank und dann den Join machen.

Aber ich würde mal auch sagen, rein jetzt von der Teamstruktur, und damit beschäftige ich mich ja auch relativ viel, macht es absolut Sinn, möglichst viel Ownership im Team zu haben und wenn da die Datenbank mit dabei ist, noch viel besser.

Und wie gesagt, das ist dann heutzutage eigentlich so automatisiert, dass ich mir die Datenbank dann einfach aus der Cloud hole, das ist gemanagt oder von meinem Team, von meinem Plattform-Team, Datenbank-Plattform-Team und dann sage ich einfach bei denen bitte eine Datenbank und ich bekomme dann automatisch den Container mit meiner Datenbank, der gebackupt ist, der sicher ist, wo alles funktioniert.

Also das ist sicher eine sinnvolle Herangehensweise und auch da sieht man, dass Maisquellet sicher nicht gestorben ist, sondern überall im Einsatz ist und eigentlich so ein de facto Standardfass geworden ist.

Jetzt hast du ja schon so ein paar Dinge genannt, die in die Richtung gehen, so Slaves.

Das impliziert ja, dass es vielleicht Master gibt und vielleicht gibt es ja auch so ein Multi-Master-Cluster.

Ich habe relativ häufig den Ausdruck Galera-Cluster gehört.

Ich glaube, das ist ja so eine Clusterlösung für MySQL.

Was hat es denn damit so auf sich?

Ist das heute noch ein relevantes Thema?

Grundsätzlich sind Clusterlösungen klarerweise ein großes Thema.

Also damals die Multimaster bzw.

Active-Active-Master, ich glaube MySQL hat mittlerweile auch die Terminologie geändert auf Source und Replication, glaube ich.

Ich weiß jetzt gerade nicht auswendig.

Hat es auf jeden Fall ursprünglich gegeben.

Das Active-Active-Cluster war so, dass es zwei Server gegeben hat, die beide schreiben durften,

Ja.

weil sonst war ja die klassische Herangehensweise, wenn ich skalieren will, ich habe eine Instanz, die schreibt, alle anderen replizieren und sind nur lesend zur Verfügung.

Das hat ja für die meisten Use Cases eigentlich ausgereicht, weil du hast ja nicht so viel schreibende Zugriff.

Also gerade im Web zum Beispiel hast du klassisch ganz viel lesende Zugriff und dann hast du halt ein paar schreibende und die funktionieren dann über diese zentrale Komponente, über die MySQL-Instanz, die eben die Schreibrechte sozusagen hat.

Und dann gab es eben einige Varianten, die in Richtung klassischen Cluster gegangen sind, also wirklich Active-Active-Cluster, wo alle schreiben können im Cluster.

Hm?

Und da war der Galera-Cluster eben einer der Anbieter.

Oracle hat dann auch dementsprechend Clusterlösungen angeboten.

Mittlerweile ist Galera von MariaDB übernommen worden in diesem Jahr.

Also das ist deren Clusterlösung.

Es gibt andere Clusterlösungen auch noch, die sich im Prinzip über die MySQL-Datenbank stülpen und die ganze Kommunikation übernehmen.

Also Facebook hatte das zum Beispiel auch ganz früh.

Die haben quasi ihre eigene Clusterlösung geschrieben.

Facebook hatte ja seit Anfang an PHP und MySQL im Einsatz.

Und die haben natürlich extreme Skalierungsschwierigkeiten oder Probleme gehabt.

Und die haben das eigentlich so gelöst, dass immer ein paar User gemeinsam auf einem Rechner waren und da war eine MySQL oben.

Und alle Daten zu dem User, von User 5 bis User 500, waren in dieser MySQL-Datenbank auf einem Server.

Und dann hat Facebook eine Schicht darüber geschrieben, wie man die Daten dann unter Anführungszeichen joinen kann oder zusammensammeln kann von den verschiedenen Rechnern.

Und so haben es die eigentlich geschafft, mit MySQL so eine riesenskalierende Cloud zu bauen, wenn man es so nennen will.

Und ich weiß leider die Zahlen nicht mehr auswendig, aber das waren sicher mehrere tausende MySQL-Server, wenn nicht zehntausende.

Wow.

Und die darum da auch sehr viel kontributet haben.

Also Facebook hat eine eigene MySQL-Version, einen eigenen Fork, den sie nur für sich maintainen.

Aber Facebook hatte für MySQL, ich glaube, fünf Developer, keine Ahnung, ob sie sie immer noch haben, die wirklich nur am Kern von MySQL gearbeitet haben und das auch wieder upstream zurück an die Community gegeben haben.

Und die haben natürlich vor allem dann solche Dinge herausgefunden, wie wenn dieses Ding unter absoluter Schreiblast, 24-7, immer Vollgas schreibt, dann kann es passieren, dass irgendwie nach acht Stunden irgendwo ein komisches Lock zuschlägt und dass die Datenbank dann irgendwie eineinhalb Sekunden kurz tot ist und solche Dinge.

Die hat einfach kein Mensch auf der Welt sonst gehabt, diese Probleme.

Und das ist ganz interessant, wo Facebook dann das wirklich herausgefunden hat.

Und die haben die dann schlussendlich gefixt in der InnoDB Storage Engine.

Also das muss man schon sagen, diese Skalierung und diese Reichweite, die MySQL hatte, die haben die natürlich auch genutzt oder konnten nutzen, dass das dann wirklich Bulletproof am Ende war, weil eben Facebook kontributet hat, weil Bacona kontributet hat.

Es war wirklich so viel im Einsatz, dass das halt auch dann rock solid am Ende ist.

Und natürlich im Vergleich zu irgendeiner Datenbank, die erst ein Jahr existiert, ist da natürlich ein großer Unterschied, als wenn du eine Datenbank bist, die jetzt 30 Jahre existiert und die größten Firmen auf der Welt eingesetzt haben und dementsprechend dann auch viele Bugs gefixt haben.

Spannend ist natürlich klar, bei den großen Plattformen, die viel Daten haben, die geschrieben werden müssen, die brauchen natürlich dann auch, haben sehr besondere Anforderungen an so eine Datenbank und das glaube ich natürlich gerne, dass man da über Datenmaßen spricht, die wir natürlich im Homelab nicht haben.

Ich glaube aber auch, so ein Galera-Cluster ist jetzt nichts, was man sich unbedingt ins Homelab stellt.

Oder wäre das was, wo du sagst, nachher gleich mal ein paar VMs hochziehen in Rico und dann geht's ab?

Kann man gerne machen, aber ich bin schon auch der Meinung, Tipps jetzt zuerst schon mal anklingen lassen.

Du kommst mittlerweile mit einem MySQL-Server so weit, mit einem

Hm?

einzelnen Server, dass du da wirklich tausende von Transaktionen pro Sekunde eigentlich durchbekommst.

Und wenn du wirklich ein Problem hast, dann teile das Ganze nochmal auf in eine Read-Replika und den Write-Server.

Dann hast du wieder eine Aufteilung und dass du dann an die Grenzen kommst, ist schon sehr unwahrscheinlich.

Aber wenn das dann natürlich passiert, dann kannst du auf irgendwelche Clusterlösungen umsteigen.

Oder du hast natürlich extreme Anforderungen bezüglich Sicherheit, dass das halt verteilt sein muss, dass immer mehrere Server gleichzeitig die gleichen Daten haben.

Aber im Endeffekt ist das große Problem, dass du bei einer Clusterlösung immer eigentlich an Throughput verlierst, das heißt an Geschwindigkeit.

Weil du natürlich irgendwelche Replikationsmechanismen hast und umso sicherer das sein soll, umso synchroner werden die Replikationsmechanismen.

Das heißt, wenn du jetzt sicher gehen willst, dass auf drei Rechnern immer also auf mindestens drei Rechnern mindestens dein Informationsstand verfügbar ist, und zwar immer, zu jeder Zeit, dann musst du natürlich eine synchronere Applikation machen mit drei Servern.

Das heißt, du machst einmal ein Insert Statement, ein Write Statement, und dann muss im Hintergrund das auf drei Servern abgeglichen werden und erst dann bekommst du das Commit, das okay, dass alles gut gelaufen ist.

Und dann kann man sich vorstellen, wenn du über Netzwerke mit drei Servern sprichst, wird das einfach dementsprechend langsamer.

Also das muss man schon immer auch mit einbeziehen.

Das heißt, Clusterlösungen würde ich wirklich nur für ganz spezielle Use Cases eigentlich in Betracht ziehen und die klassische Web-Anwendung, da skalierst du wirklich auf hunderttausende User, würde ich mal sagen, vor allem, weil es eh meistens lesend ist.

Also ich habe ein so ein Side-Project, da haben wir um die 200 Millionen User am Tag Zugriffe und ja, die Datenbank langweilt sich, ehrlich gesagt, den ganzen Tag.

Also das ist überhaupt kein Problem und die läuft auf einfach einem 0815-Hardware-Server und der ist zu 5% ausgelastet oder so.

Also das ist wirklich kein Bottleneck.

Da bist du mit den ganzen Webservern und so weiter, die da laufen, viel eher am Limit als bei einer klassischen Datenbank.

Da wird zwar nicht viel geschrieben, aber trotzdem, es ist wirklich überhaupt kein Problem.

Man unterschätzt es, wie weit man da wirklich rauskalieren kann auf einem Server.

Ja, und vermutlich, wenn das meiste Reads sind, fangt ihr das dann mit dem Cache Layer zwischendrin dann ab, so dass jetzt nicht jeder Read auch auf die Datenbank runtergeht?

Oder wie?

Da sind sehr viele Reads eigentlich auf der, also ich würde sagen von den zwei Millionen, da hast du schon bei mindestens zwei Millionen Queries, ja.

Also da hast du immer Reads mit dabei, das ist überhaupt kein Problem.

Klar, ein, zwei Sachen sind gecached, wo es möglich ist, aber da bekommt jeder User immer aktuell personalisierte Fragen.

Insofern musst du schon auf die Datenbank dann immer zugreifen und auch schreiben.

Es ist eine kostenlose Führerscheinplattform zur Vorbereitung auf den österreichischen Führerschein, existiert auch schon seit zehn Jahren, ist kostenlos für alle, sind die einzigen.

und da hämmern natürlich schon viele SQL-Querys drauf ein und der Lernstand wird ständig geschrieben mit jeder Frage, die du lernst und du bekommst natürlich auch personalisiert immer eine Frage vorgeschlagen, die für dich passt, also da sind schon immer SQL-Querys im Spiel.

Ich glaube, da hat sich aber auch eine ganze Menge getan.

sodass du jetzt nicht mehr mit einem selbstgebauten Cache oder einem Caching-Layer dazwischen immer arbeiten musst, sondern ich sag mal festplattentechnisch hat sich in den letzten 30 Jahren einiges getan, sodass wir nicht mehr irgendwie mit dem Lesekopf an die richtige Richtung springen müssen oder zumindest das heute auch eher die Seltenheit geworden ist.

Und auch betriebssystemseitig.

Wir haben ja jetzt, also ich meine, selbst mein Notebook hat ein bisschen mehr als zwei Megabyte an Arbeitsspeicher, ja, und je mehr da so verfügbar ist, desto mehr nutzt natürlich auch das Betriebssystem, um dann diese Sachen mit auszumerzen.

Also ich glaube, das Verhalten ist da schon nochmal deutlich anders.

Ja, vielleicht können wir da hinten nochmal mit zu Optimierungen, die so dein Go-To sind, was man da so macht.

Das fiel mir gerade so ein, weil ich denke, es ist bestimmt für manche auch interessant, einfach mal so rauszufinden, wie gehe ich eigentlich im Optimierungsguide an die richtige Stelle oder was sind so die common Optimierungen, die man so macht.

Und ich glaube, clustertechnisch ist halt auch einfach das Ding, guck halt, was du willst.

Willst du Datensicherheit, dann ist vielleicht einfach eine Replika was.

Wenn es nicht allzu kritische Daten sind, dann ist auch ein asynchrones Replizieren, was vielleicht auch nicht minütlich läuft, sondern vielleicht auch stündlich oder sowas.

Das kann man beliebig rausziehen.

Und je nachdem, was man halt will, gibt es ja unterschiedliche Mechanismen.

Und dass das eben so offen ist, das finde ich eigentlich eine ganz schöne Sache, dass du damit ganz unterschiedliche Anwendungsszenarien auch abbilden kannst.

Es ist auch wesentlich weniger geworden, dass du überhaupt optimieren musst.

Wie du schon richtig gesagt hast, der Hauptspeicher ist größer geworden.

Das ist sicher eigentlich der größte Unterschied.

Ja.

Das war ja auch, warum Facebook MyRocks dann entwickelt hat, dass die die verschiedenen Layer eben vom Hauptspeicher über SSDs bis hin zu klassischen Spinning Disks noch irgendwie abbilden konnten, weil die darauf optimiert haben.

Ja.

Die ganz klassischen relationalen Datenbankoptimierungen, Indexstrukturen, B-Bauben, die sind natürlich alle für Spinning Disks entwickelt worden damals.

Die funktionieren schon im Hauptspeicher auch, aber es gibt auch ganz viele Neuerungen, wenn es um Hauptspeicherindizes oder Indexstrukturen geht, die man dann dementsprechend dort einsetzt.

Aber man muss schon sagen, dass es allgemein schneller geworden ist und auch die Optimierer werden immer besser.

Also ich hatte das schon immer das Problem bei dem MySQL-Buch, was wir geschrieben haben.

Da war ich verantwortlich für das Optimierungskapitel.

Und wir hatten drei Auflagen und jedes Mal bei jeder Auflage haben alle meine Beispiele, meine Negativbeispiele nicht mehr funktioniert, weil die in der Zwischenzeit behoben worden sind von dem Optimierer

Hm.

und einfach nicht mehr da waren.

Ich habe mir immer neue Beispiele ausdenken müssen, um zu zeigen, wo es noch Probleme gibt, wie man dann Sachen optimieren kann.

Und da hat Oracle, wie Oracle die MySQL-Datenbank übernommen hat, nachdem sie ja von Sun zuerst aufgekauft wurde und dann von Oracle aufgekauft wurde, da hat Oracle sehr viel Zeit und wahrscheinlich auch Personenpower investiert am Ende, in diesen Optimierer, dass der im Vorhinein schon sich überlegt, wie kann ich eine Query möglichst optimiert dann verarbeiten.

Und auch MariaDB hat sehr viel da investiert in den Optimierer.

Da sind die zwei auch komplett unterschiedlich.

Also die Codebases sind da eigentlich komplett getrennt.

Wenn es um den Optimierer geht, die haben auch ganz andere Ansätze an den Optimierer.

Du kannst in MariaDB auch viel mehr dem Optimierer noch mitgeben, in welche Richtung er optimieren soll, also was die Variable ist, auf die optimiert werden soll zum Beispiel.

Und Oracle hat da aber einfach aus der ganzen Praxis natürlich von der Oracle-Datenbank, die die über Jahrzehnte gesammelt haben, vermutlich da auch viel mit reinbringen können von Enterprise-Use-Cases.

Und da ist schon viel passiert.

Und wenn du heutzutage eine Query reinwirfst in so eine Datenbank, auch eine sehr lange irgendwie mit Commentable Expressions, also wo du mehrere Subqueries und solche Dinge hast, dann werden die meisten schon ganz gut optimiert, würde ich mal sagen.

Auch wenn, ich habe es schon auch oft erlebt, wenn es dann noch Potenzial gibt, aber es wird von Version zu Version besser, würde ich sagen.

Ja, du hast schon gesagt, ja, also MySQL AB, die Firma, wurde dann von Sun Microsystems übernommen und die wiederum ja von Oracle, wie wir alle mitbekommen haben.

Und seitdem haben wir ja zwei Projekte.

MariaDB, da ist auf jeden Fall relativ einfach, wie man es ausspricht, würde ich sagen.

Da gibt es nicht so viele Komponenten.

Ist übrigens die zweite Tochter von Monty.

Also er hat sich sehr leicht gemacht, Mai und Maria, und das war einfach dann die zweite Tochter.

Sehr schön.

Das heißt, den nächsten Vorhaben gibt es dann erst, wenn das dritte Kind dann kommt, vermutlich.

Genau, ja, wahrscheinlich.

Ich glaube, mittlerweile ist Monty ja schon relativ alt.

Also er ist, glaube ich, nicht mehr so aktiv, wenn ich das jetzt mitbekommen habe.

Also nicht mehr so super involviert als zentrale Persönlichkeit zumindest.

Also er treibt sich natürlich schon überall noch herum auf den ganzen Konferenzen.

Aber er ist schon jetzt ein größeres Team natürlich bei MariaDB.

und seitdem die auch börsenorientiert sind, die haben da natürlich jetzt schon ziemlich einen Push und müssen auch deliveren und auch auf der finanziellen Seite, also da geht dann schon einiges weiter und sind auch größer.

Und das hat man eigentlich damals auch gemerkt, wie Oracle das Ganze übernommen hat, dass sich eigentlich, würde ich meiner Meinung nach sagen, die Datenbank am meisten bewegt hat, wie Oracle das Ganze übernommen hat, weil die hatten halt wirklich die Kohle und die personellen Mittel, dass sie da einfach ganz viele Leute draufgeworfen haben und die haben das Ganze dann optimiert.

Und es haben sehr viele kritisch gesehen, weil die meisten haben geglaubt, Oracle kauft MySQL, stampft es ein, damit sie keinen Konkurrenten mehr haben für ihre Oracle-Datenbank.

Mhm.

War aber genau andersrum, sondern die haben wirklich viel investiert und haben viel weitergebracht.

Und da hat es eine Zeit gegeben, da war eigentlich die MySQL, die Oracle MySQL, um Welten weiter vorne gegenüber der MariaDB.

Also da war sie wirklich stark und dann hat es irgendwann diese Zeit gegeben, wo der MariaDB auch Gas gegeben hat und auch eigenständige Features entwickelt hat, die zum Beispiel jetzt in Oracle nicht verfügbar sind, in MariaDB aber schon.

Also andersrum natürlich auch, die entwickeln sich immer weiter auseinander, wenn es um spezielle Features vor allem geht, also eine klassische SQL-Query funktioniert überall.

Aber wenn es dann um spezielle Features geht, um irgendwelche dynamisch berechneten Spalten zum Beispiel, die aus anderen Spalten berechnet werden und ob das dann persistiert wird oder nicht, da gibt es dann so Unterschiede in diesen Feature-Sets.

Aber auf jeden Fall hat Oracle MySQL sehr viel weitergebracht, würde ich mal sagen, damals.

...

Musik...

weil das war ja damals im Netz ein ganz anderer Tenor, den man gehört hat.

Also wie du gerade schon sagtest, haben ja viele erwartet, dass das Projekt dann eingestellt wird.

Man hat ja zum Beispiel auch bei anderen Projekten von Sun Microsystems gesehen, dass es denen nicht notwendigerweise besser ging nach der Übernahme.

Also so, mir fällt da direkt Solaris und Java ein.

Da war ja die Zukunft auch echt lange so ein bisschen düster.

Aber gab es noch einen weiteren Grund für diesen Fork?

Also war das einfach nur eine reine Sicherheitsmaßnahme, dass man halt sicherstellen wollte, dass das Projekt dann noch weiterlebt unter neuem Namen.

Ja, es war eigentlich, Sicherheitsmaßnahme, schön gesagt, Monty hat sich einfach extrem zerstritten mit Oracle oder wollte halt die Oracle-Übernahme nicht und hat dann einfach einen Fork gemacht.

Das war eigentlich der Hauptgrund.

Und darum gibt es jetzt die MariaDB mit Monty und natürlich der ganzen Firma drumherum und die Oracle-Seite.

Also das war eigentlich der einzige Grund, weil zu Sun-Zeiten hat man das ja auch teilweise schon kritisch gesehen, aber da war Monty noch komplett mit am Boot und darum hat es da keinen Fork gegeben.

Das war der einzige Grund eigentlich.

Also ich würde sagen, es war ein sehr persönlicher Grund, Aber da hatte natürlich auch die Community sehr viel mitzureden, weil natürlich Sun wesentlich offener grundsätzlich war, jetzt rein von der Firmenkultur, als eine Oracle.

Und diesbezüglich ist ja Oracle auch wirklich noch sehr geschlossen, weil du hast zum Beispiel keinen öffentlichen Bug-Tracker von MySQL.

Also du hast schon einen, aber das ist nicht der Oracle-Bug-Tracker.

Aha.

Und wenn du einen Bug einreichst, dann arbeiten die intern irgendwie daran und irgendwann sagen sie dir mal über den Öffentlichen wieder Bescheid, was passiert ist, vielleicht oder vielleicht auch nicht.

Oder du bekommst dann irgendwie eine Liste von internen Bug-IDs, auf die du alle keinen Zugriff hast, dass sie irgendwas gefixt haben und dann steht nur fix da und alle Details würden in irgendwelchen internen Bug-Tickets stehen, die aber niemand einsehen kann.

Also da spielt Oracle schon noch die klassische Oracle-Schiene, aber abgesehen davon sind sie schon relativ offen und das ist vielleicht auch eine Chance gewesen für MariaDB, da einfach dann auch offener zu sein und vielleicht auch die Community mehr in ihre Richtung zu treiben.

Und ist ja auch, wenn du jetzt in Linux zum Beispiel eine MySQL installierst, in fast allen Distributionen wird eigentlich MariaDB installiert.

Du kannst zwar MySQL-Befehle verwenden und MySQL eintippen auf der Konsole, aber im Hintergrund ist das einfach ein Link auf MariaDB.

Ja, das ist ein spannender Punkt.

Und da können wir vielleicht mal direkt reinspringen, wo da die großen Unterschiede sind.

Denn mir geht es genauso, wie du gerade sagtest.

Wenn ich so eine Datenbank brauche, dann installiere ich meistens die MariaDB, weil viele Distributionen einfach MySQL nicht mehr shippen oder nur optional shippen.

Oder dann so Vorstellungen kommen, meinten sie vielleicht MariaDB.

Und häufig sind es ja Symlinks.

Also das war ja auch so gedacht, als für die meisten Fälle ein einfaches Drop-in-Replacement sein zu können.

Aber die sind, glaube ich, nicht mehr featurekompatibel zueinander, oder?

Also beide Projekte, man nennt das ja glaube ich auch ein Hardfork, wenn dann Projekte divergieren voneinander und dann nicht mehr kompatibel zueinander sind.

Ich glaube, den Punkt haben wir mittlerweile erreicht, oder?

Den haben wir auf jeden Fall erreicht.

Am Anfang ist natürlich sehr viel noch zurückgeflossen.

Da hat MariaDB versucht, viele Änderungen von MySQL auch bei sich reinzunehmen.

Und irgendwann war dann eigentlich der Punkt erreicht, wo, also kann ich schwer feststellen, warum das jetzt so passiert ist.

Aber sie haben sich einfach, also MariaDB vor allem, ist dann einfach erwachsen geworden und hat eigene Features entwickelt.

Und es gibt auch eine Webseite auf der MariaDB-Webseite in der Knowledge Base, wo nur MariaDB versus MySQL aufgelistet wird und die Kompatibilitäten erklärt werden oder wo es eben keine Kompatibilität gibt und die Liste wird schon mittlerweile länger und länger und länger.

Und wie gesagt, gerade die ganzen detaillierteren Zusatzfeatures, also so, ich würde nicht sagen Nischenfeatures, weil mittlerweile sind es wirklich Standardfeatures geworden, aber da unterscheiden sie sich halt groß.

Ich habe schon die virtuellen Spalten genannt, zum Beispiel dynamische Spalten mit die Common Table Expressions, also diese klassischen With Statements.

Da waren sie auch unterschiedlich schnell.

Mittlerweile können das beide Datenbanken, haben aber auch teilweise unterschiedlichen Support, wie viel unterstützt wird, auch von so speziellen SQL-Features, die zum Beispiel Rolling Windows machen oder so Zwischensummen bilden, solche Dinge, die du ja mittlerweile alle machen kannst.

Da unterscheiden sie sich.

Wie gesagt, wenn du 0815, Create Table Statements, Select Statements, Joins, da ist es eigentlich Drop-in.

Aber sobald du spezielle Features verwenden willst, die jetzt nicht SQL 99 Standard sind, würde ich mal sagen, oder 92 vielleicht sogar.

Alles, was nach 92 kam an speziellen SQL-Features, da muss man dann wirklich schauen, okay, was unterstützt MariaDB, was unterstützt MySQL.

Da gibt es dann auch ganz große Unterschiede, wenn es um Performance geht, was unterstützt wird.

Und da gibt es übrigens auch ganz viele Unterschiede bei den ganzen Cloud-Anbietern, weil du kannst zum Beispiel, wenn du jetzt PlanetScale verwendest als skalierender Provider, was sie sich auf die Fahne schreiben, also dass die ins Endlose skalieren, die skalieren im Hintergrund alles für dich und du hast ein SQL-Interface, da kannst du zum Beispiel nur vier Union-Statements schreiben.

Da kannst du also nur vier Select-Statements vereinen.

Sobald du mehr willst, funktioniert das nicht mehr.

Das ist so eine Restriktion, in dem Fall von VITES im Hintergrund, aber auch da, je nachdem was für eine Storage Engine beziehungsweise was für eine, ob MySQL oder MariaDB du verwendest hast du bei solchen Queries dann unter Umständen Probleme, also wenn du so Queries vereinst, Commentable Expressions machst, wie viele kannst du da kombinieren, dann hast du auch teilweise noch so Zusatz-Hints, die du dem Optimierer geben kannst, dass der Optimierer zum Beispiel Zwischenergebnisse von diesen Commentable Expressions zwischenspeichert wirklich oder dann dynamisch berechnet, da unterscheiden sich die natürlich MariaDB und MySQL.

Also es sind schon dann Features, die, würde ich mal sagen, für das 0.8.15-Webprojekt nicht so wichtig sind.

Also für brauchschnell eine Datenbank kannst du sie äquivalent sehen.

Jetzt haben wir hier auch mit einigen Fachtermini um uns geworfen und wir verstehen uns ja hier auch so ein bisschen als Bildungsauftrag-Podcast.

Vielleicht machen wir mal einen kurzen Exkurs, was es denn eigentlich mit SQL so auf sich hat.

Also man benutzt das für Datenbanken, aber das gibt es ja auch schon.

Jetzt hast du schon von Standard von 1992 gesprochen.

Was hat es denn so damit auf sich?

Im Rahmen der Vorbereitung habe ich mich da auch ein bisschen eingelesen und habe für mich folgenden Merksatz abgeleitet.

SQL ist das Sequel zu Sequel.

Und vielleicht ergibt das ja gleich noch Sinn, wenn wir hören, wo das eigentlich herkommt.

Das Sequel zum Sequel, ja, sehr schön.

Ja, da sind wir jetzt eigentlich wieder beim Anfangsthema, bei dem Namen, bei der Aussprache.

Sagt man MySQL oder MySequel oder sagt man SQL oder Sequel?

Das Ganze geht ja zurück auf Sequel, also S-E-Q-U-E-L.

Das ist die Structured English Queer Language.

Das war eigentlich der Vorgänger zu SQL, beziehungsweise war eigentlich SQL.

Es hat dann aber rechtliche Probleme gegeben mit dem Namen.

Okay.

Das war eigentlich der Hauptgrund, warum das dann geändert wurde.

Und darum gibt es vor allem im amerikanischen Bereich ganz viele Leute, die Sequel sagen.

Weil eigentlich SQL, wie kommt man da auf Sequel?

Da gibt es gar keinen Zusammenhang.

Und gibt es eigentlich auch gar keine von den Buchstaben.

Das ist rein historisch bedingt, dass Sequel der Vorgänger quasi war von SQL.

Und SQL ist, glaube ich, 50 Jahre jetzt gerade gekürzlich worden.

Ich sollte es wissen, weil wir haben eine eigene Episode im Engineering Kiosk darüber gemacht, aber ich glaube es waren 50 Jahre, wo wir die ganze Geschichte von SQL beschreiben.

Das ist eigentlich sehr spannend, weil es halt wirklich viele Grabenkämpfe gegeben hat mit DB2 und Oracle und so weiter.

Oracle war damals der dynamische junge Hupfer, der da reingekommen ist in den Markt.

DB2 war da eigentlich das alte konservative Schlachtschiff und dann sind die modernen Oracle-Jungs reingekommen und haben da den Markt aufgeräumt.

Also es ist eigentlich ganz interessant, was da alles passiert ist.

Aber SQL hat sich eigentlich jetzt so wirklich als Standard durchgesetzt und hatte ja in den letzten zehn Jahren mit NoSQL auch so einen gewissen Gegner, wo es wieder geheißen hat, die relationalen Datenbankmodelle sind alle tot und es kommt jetzt was Neues.

Und dann ist aber die ganze Data-Science-Ecke wieder gekommen und Big Data und da haben dann alle irgendwie gemerkt, SQL ist doch ganz praktisch, wenn man mit Daten umgeht.

Und dann hat sich da eigentlich wieder SQL etabliert, dass man auf Daten einfach gut zugreifen kann mit SQL.

Und SQL ist ja auf der einen Seite die Query Language, das heißt zur Abfrage von Informationen, also die klassischen Select-Abfragen, die man hat.

Aber es gibt natürlich auch andere Untergruppen von SQL, die im SQL-Standard übrigens auch klassischerweise natürlich definiert sind.

Also Update, Insert, Delete nennt sich Data Manipulation Language.

Dann gibt es die Create Table Statements, die wahrscheinlich auch alle kennen.

Das ist die Data Definition Language, wo man die Tabellen alles anlegt.

Dann gibt es natürlich die Data-Control-Language, das heißt die Grant-Statements, wie kann ich User anlegen, wie kann ich Permissions vergeben.

Also auch da gibt es einen eigenen Subteil im SQL-Standard.

Dann gibt es Transaction-Control-Language, das sind alles, was irgendwie mit Transaktionen zu tun hat.

Und alle diese Blöcke sind definiert in dem SQL-Standard, in dem ISO-Standard, ist es?

ANSI-Standard, ich glaube, es ist ANSI-Standard, wenn mich nicht alles täuscht.

Und da kommen alle paar Jahre immer wieder neue Standards raus.

Der klassische, den wir eigentlich so verwenden, ist im Alltag der SQL92-Standard.

Da war eigentlich alles schon definiert, was wir heute so kennen.

Und dann kamen neuere Standards, da haben sich die Leute dann überlegt, ja, eigentlich, wie gehen wir mit Zeiten um, temporale Datenbanken, wie bekommen wir XML rein, wie bekommen wir JSON mit rein und alle Add-ons, die so cool wären in der SQL-Welt, also dass man in einer SQL-Abfrage eben auch eine JSON-XML-Path-Abfrage, Sub-Abfrage sozusagen reinsetzen kann.

Diese Dinge sind dann alle aus den neueren Standards gekommen.

Und da muss man auch sagen, war MySQL immer sehr rückständig.

Hm?

Das heißt, MySQL war da gerade vor der Oracle-Übernahme ganz schwach mit dem SQL-Standard.

und die haben dann aber nach der Oracle-Übernahme eigentlich sehr viel aufgeholt und haben da dann wirklich viel noch mit reingebracht.

Auch zum Beispiel kennen vielleicht viele aus der früheren Zeit, wie man umgestellt hat auf neuere MySQL-Versionen.

Ich glaube, ab MySQL 8 war das dann Standard, dass wenn du GroupBy machst in einer SQL-Anfrage, dass du im GroupBy alle Felder brauchst, die du auch im Select vorne hast, in der Projektion.

Das hat immer ganz viele gestört.

warum soll ich da hinten nochmal alles hinschreiben, obwohl das eigentlich gar nicht nötig ist.

Aber damit es sauberes SQL ist und eigentlich mathematisch okay und sound ist, brauchst du diese Dinge alle im Group bei.

Und solche Dinge waren im MySQL aber nie enforced.

Und es war halt eher so, dass die Leute das dann angenommen haben, obwohl es eigentlich nicht ganz korrekt ist.

Und das war dann mit der Umstellung eine große Veränderung für viele Leute, ist es wahrscheinlich immer noch.

Und ich persönlich bekomme diese Fehlermeldung auch noch ständig, also dass im Group bei diese Felder fehlen.

Mir passiert das auch immer noch.

Und solche Dinge haben sich dann einfach verändert und MySQL hat sich sehr stark an den Standard noch näher angenähert.

Und da sieht man auch schon ein bisschen den Unterschied zu Postgres zum Beispiel.

Postgres war einfach schon immer 100% standardkonform.

Also die haben sich immer ganz stark an den Standard gehalten, kommt ja auch aus dem wissenschaftlichen Umfeld Postgres.

Von Stonebreaker, dem bekannten Datenbank-Professor.

Und der hat das da eigentlich damals mitentwickelt.

Und der war natürlich immer sehr nah an diesem Standard.

Weil das halt klassische Wissenschaft, wir halten uns an den Standard.

Und da hat Postgres dann eigentlich MySQL auch ganz klar überholt.

Beziehungsweise war schon immer stärker, muss man auch zugeben.

Die hatten einfach immer schon viel mehr Features.

Ist die Frage, ob sie gleich schnell waren und gleich stabil und so.

Da kann man sich jetzt drüber streiten.

aber sie hatten auf jeden Fall immer mehr Features und waren immer näher am SQL-Standard als MySQL.

Wobei MySQL da aufgeholt hat, auch MariaDB hat aufgeholt.

Und Commentable Expressions zum Beispiel, die sind vor, ich glaube, vor drei Jahren oder so mal dazugekommen, ist gar nicht so lange her.

Und die waren aber garantiert im SQL-92-Standard schon.

Also vielleicht im 99er, aber auf jeden Fall vor der 2000-Wende, würde ich jetzt sagen, oder zumindest um den Dreh.

Und quasi 20 Jahre später erst hat dann MySQL wirklich mal dieses Feature eingebaut, was im Enterprise-Umfeld und wenn du mit großen Datenmengen hantierst, mit komplizierteren Daten auf jeden Fall nötig ist.

Spannend.

Ja, manchmal kann es lange dauern, etwas umzusetzen, denn wenn es mal draußen ist, dann ist es schwer, dann noch Änderungen reinzubringen.

Scheint mir zumindest so.

Jetzt haben wir ganz viel über Kommandos gehört und ich frage mich die ganze Zeit, ob ich ein Lieblingskommando habe.

Habt ihr denn eins?

SQL-Dump, mega.

Oh ja, stimmt.

Das ist auf jeden Fall das, was ich am häufigsten in der Bash-History, glaube ich, finde.

Das ist auch das, wo ich am wenigsten Angst hätte, einen Parameter nicht zu kennen oder so.

Oder wahrscheinlich gibt es Tausende, aber ich brauche nicht so viele.

Das ist echt sehr einfach und schön.

Bei euch?

Christian, deines?

Also ich glaube, ein Lieblingskommando habe ich jetzt so nicht.

Also ich weiß, dass damals es Klick gemacht hat in der Berufsschule, als ich das erste Mal mich mit Joins beschäftigt habe und auch so diese Abfrage über mehrere Tabellen und das erste Mal verstanden habe, wie man so ein Primär- und ein For-In-Key einfach mal richtig verwendet und in Relation setzt.

Amen.

Und ich habe aber eine Lieblingsfehler-Meldung, der habe ich sogar vor langer, langer Zeit meinem Blogartikel gewidmet, eben beim Backupen, wie Enrico gerade sagte.

Denn da gab es den Fehler 2006, my SQL Server has gone away, wenn der zwischendrin in Timeout läuft.

Und ich finde, das ist was Schönes, weil wir machen gerne Urlaub und so ein SQL Server, der macht auch gerne mal Urlaub.

Und deswegen ist er halt nicht da, ist doch nur legitim.

Team.

Ja, ist eine schöne Fehlermeldung.

Kann sich übrigens wieder erholen.

Also man braucht nichts machen.

Kann sein, wenn er dann wieder ab ist, kann man in einer kleinen Session einfach weiterarbeiten.

Ah, okay.

Ich habe damals

Aber...

halt unwissend, wie ich war, als Heranwachsender einfach den Timeout auf einen sehr unrealistisch hohen Wert gesetzt und somit eine höhere Auslastung forciert.

Naja.

Ja, es kommt darauf an, ob der Server wirklich weg ist.

Also wenn der Server abstürzt oder neu startet, dann hast du das ja auch, dieses Away.

Also je nachdem, was der Grund dann natürlich dafür ist.

Was mein Lieblingsstatement ist, ist also kein Lieblingsstatement in dem Sinne, aber ein Statement, was sehr wenige Leute kennen, ist das Create-Event-Statement.

Kennt ihr das?

Was tut das?

Es ist eigentlich ein Cron in MySQL.

Das heißt, du kannst sagen, Create Event und führe mir jetzt eine Query, ein Update Statement oder ein Delete Statement jeden Tag um 18 Uhr aus.

Das heißt, wenn du zum Beispiel irgendwo ganz viele Logs in deine Datenbank speicherst, dann kannst du ein Event kreieren, dass jeden Tag am Abend oder in der Nacht werden alle Logs weggeworfen, die älter als 14 Tage sind.

Das heißt, du kannst da wirklich wie in einem Cron Statements regelmäßig aufrufen lassen, vollautomatisch im Hintergrund.

Und gerade wenn es um so Clean-Up-Jobs geht oder gewisse Sachen, die du vielleicht einmal pro Tag berechnen willst, so vorberechnete Tabellen zum Beispiel, dann kannst du das über solche Event-Statements sehr gut abbilden und brauchst nicht extra wieder einen Cron, irgendwie eine Software außerhalb, irgendeinen Cron, den du überwachen musst.

Es läuft in der Datenbank ab und läuft stabil in der Datenbank ab und brauchst du dann nicht extra maintainen.

Spannend, das kannte ich echt noch nicht.

Ich hatte so einen ähnlichen Effekt mal, als ich mich mal eine kurze Zeit mit PLSQL, mit Oracle beschäftigen musste.

Ja, da dachte ich auch gerade dran, will man das wirklich?

Weil, also, so mit diesem, gut, ich meine, jetzt ist natürlich ein MySQL MariaDB nicht unbedingt ein Kostentreiber, im Gegensatz zu manch einer Datenbank, die Lizenzen haben möchte.

Und das war halt echt in vielen Fällen ein riesiges Problem, diese ganzen Dinge da in etwas anderes transferieren zu können.

Also will man diese Art von Logik und Dingen in der Datenbank abbilden oder wäre es nicht schöner, wenn das woanders lebt?

Ich frage für einen Freund.

weil du könntest ja auch noch viel mehr machen.

Also auch MySQL unterstützt das mittlerweile.

Du kannst Trigger haben, du kannst Funktionen haben, du kannst Procedures haben.

Teilweise ist es natürlich sehr praktisch, jetzt wenn du wirklich performance-kritische Sachen machst, wo du sagst, du musst irgendwie nah an den Daten sein bei Procedures oder Funktionen.

Es gibt auch so Dinge wie zum Beispiel, wenn du dir gewisse IDs errechnen lässt zum Beispiel, irgendwie zum Beispiel eine Mapping-Tabelle.

Also du hast irgendwo Strings, Du hast zum Beispiel Städte und jede Stadt hat eine ID und du willst jetzt die Stadt irgendwo einfügen, irgendwo verwenden und willst aber nicht jedes Mal manuell in deinem Source-Code diese ID den Lookup machen.

Also eine extra SQL-Select-Query, die dir die ID von der Stadt holt, sondern du kannst direkt im Insight-Statement eine Funktion aufrufen, die dir im Hintergrund checkt, gibt es diese Stadt schon, wenn nicht, leg sie an, gib mir dann die ID zurück.

Solche Dinge sind natürlich dann sehr praktisch, wenn du die in der Datenbank hast, weil die sind natürlich auf Source-Code-Seite komplizierter oder komplexer.

Und solche Dinge sehe ich schon in der Datenbank.

Du hast natürlich recht, wenn du sowieso in deiner Software irgendwelche Jobs hast, die regelmäßig durchlaufen, wo du das dann aufräumen kannst, dann würde es vielleicht auch eher in den Source-Code stecken.

Aber wenn du jetzt eine Query hast, die dir einfach, keine Ahnung, alle 14 Tage deine Tabellen aufräumt oder irgendwie ältere Daten wegwirft,

Hm.

dann ist das schon eigentlich ganz praktisch, auch im Code zu haben.

Aber du hast natürlich vollkommen recht, es ist irgendwie unsichtbar.

Das heißt, du siehst diese Dinger ja auch nicht.

Also du createst so ein Event, das lebt dann in der Datenbank und im Source-Code siehst du es nicht.

Das heißt, was man nicht sieht, ist aus dem Kopf, ist weg und man vergisst das Ganze.

Das kann dir natürlich schon passieren.

Also da gebe ich dir natürlich vollkommen recht.

Insofern ist es immer so eine Frage, wo macht man das, wenn ich jetzt aber in meiner Software noch keinen Cron habe, Wenn ich da jetzt ein Cron aufsetzen müsste, es ist vielleicht irgendein Webprojekt, wo ich gar keine Crons habe, ein Cron muss ich überwachen, wurde der wirklich ausgeführt?

Was hat der gemacht?

Was ist der Output von dem Cron?

Dann brauchst du wieder irgendein System, der ein Cron überwacht, wurden die Crons wirklich ausgeführt?

Ist da ein Fehler vielleicht passiert und so weiter?

Also das musst du auch wieder alles mitdenken.

Das hast du natürlich bei einem simplen Statement in der Datenbank nicht, wobei das natürlich auch fehlschlagen kann.

Das kann natürlich auch passieren, aber üblicherweise, die Datenbank ist ja so konsistent, wenn es einmal läuft, dann ist es schwer eigentlich, dass das SQL-Statement dann nicht mehr funktioniert plötzlich später.

Also da hast du ja die referenzielle Integrität von der Datenbank, da hast du schon den Vorteil.

Aus der Kategorie, wenn dein Werkzeug ein Hammer ist, ist jedes Problem ein Nagel.

Hast du weitere Anekdoten, wo dir das mal passiert ist und du dann dich irgendwann erwischt hast und gedacht hast, Moment kurz, was mache ich hier eigentlich?

Und das dann doch anders gelöst hast.

Also ich habe auch Trigger in Verwendung, aber da bin ich mir auch immer am überlegen, würde ich heute anders machen, aber die kommen noch aus einer Zeit, wo es schwieriger war per Code und da ging es wirklich darum, um einen Wert zu erhöhen in der Datenbank, da brauchst du Transaktionen und das ist dann schon wieder alles schwieriger, darum ist es damals ein Trigger geworden.

Aber ich kann das voll und ganz nachvollziehen, was du meinst.

Ja, ich glaube, PLSQL ist für mich auch etwas, was in manchen Situationen eine Trigger-Warning vorher braucht.

Im doppelten Sinne, genau.

Wie sieht das mit der Industrie aus?

Der Trigger einmal als Statement, natürlich der Trigger einmal als, oh Gott, da kommen Erinnerungen hoch.

Ja, schön.

Oder so, das schon.

Aber alles, was dann komplizierter wird, es gibt ja ganze Applikationen, die geschrieben sind im BLSQL Spaghetti Code.

Und es gibt auch diese Oracle App Plattform oder wie sie, ja, irgendwo, wo man wirklich nur in BLSQL schreibt.

Und das ist dann schon wildes Spaghetti Zeug.

Apex glaube ich, ne?

Ja.

Ich glaube, die haben mittlerweile auch so Klassen und so irgendwann mal eingeführt.

Aber ja, ich glaube, da sind wir jetzt alle so weit in der Industrie, dass wir sagen, es ist vielleicht nicht mehr the way to go.

Ja.

Es wurde damals, also Apex steht für Oracle Application Express und das ist eben diese Plattform, wo du SQL-Statements in eine Web-Anwendung konvertieren kannst, war mal als Low-Code-Environment angepriesen damals.

Ich glaube, mittlerweile haben die meisten Menschen eine andere Definition von Low-Code.

Ich bin dann mal raus.

Ciao.

Wobei mir sicher bin, dass Oracle noch garantiert irgendwelche anderen Plattforms mittlerweile

Hm?

hat, die da irgendwas in diese Richtung machen.

Vielleicht nicht mehr mit BLSQL, aber grundsätzlich diese Plattformen und ich glaube Oracle Forms

Ja, Oracle Forms Reports war dann halt vorher, also ich meine, es gab ja damals Menschen, die hatten mit Kobold schon die Idee, Menschen aus dem Business dazu zu enablen, fachliche Anwendungen zu machen und das ist mit Low-Code, No-Code und RPA jetzt auch nicht viel anders.

Ich fände es einfach, ich finde es gut, dass MySQL nicht versucht, eine eierlegende Wollmilchsau für alles zu sein.

Und auch wenn es schade ist, finde ich es irgendwo auch gut, dass Doom nicht in MySQL läuft.

Also irgendwie noch nicht.

Ja.

Noch nicht.

Ja, vielleicht hat das schon jemand gemacht.

Bin mir nicht so sicher.

Insert Shoot into db_enemies, where hp = 10

Es ist übrigens auch eine klassische Erweiterung von Datenbanken, Geo-Objekte drinnen zu speichern.

Oh ja, ja, ja.

Also 3D-Objekte oder im Raum zumindest Daten anlegen.

Karten sind ja ein Klassiker.

Ja.

Insofern könnte man da vielleicht Doom ganz gut reinbringen.

Also die 3D-Welt dann in irgendwelchen 3D-Indexstrukturen ablegen, durchaus eine Möglichkeit vielleicht.

Also zumindest habe ich es in der kurzen Recherche eben noch nicht gesehen, hatte mich aber gefragt, weil es dann, weil ich dann kurz eben einmal weitergegangen bin, was kann ich denn eigentlich noch so an Code da drin ausführen, der vielleicht in einer anderen Sprache oder sowas ist und ich finde es gut, dass sowas nicht geht, weil das einfach das fühlt sich irgendwie nicht richtig an und nicht alles, was geht, sollte man machen, das aber nur meine Meinung.

Ja, ich muss auch zugeben, es ist schön, wenn man Dinge nicht unnötig overengineert.

Also man kann ganz viel auf dem Layer machen, aber ob das immer sinnvoll ist, muss man halt selbst wissen.

Das war auch mein Lessons Learned damals nach einigen Monaten PLSQL, dass das cool ist, was da alles drin geht, aber allein der weirde Syntax, der hat mir schon Kopfschmerzen bereitet und würde ich jetzt vermutlich auch die Komplexität eher in die Anwendung verlagern oder in den Layer, der dazwischen liegt.

Aber jetzt haben wir schon auch ein bisschen was über Transaktionen gehört.

Lass uns mal kurz zusammenfassen für die Zuhörenden, die das jetzt vielleicht zum ersten Mal hören, was das jetzt Leute, ich stelle mir jetzt als Laie vor, dass es mehrere Befehle gibt, die halt hintereinander ausgeführt werden sollen.

Ist das zu kurz gefasst?

Ja, im weitesten Sinn schon.

Und idealerweise, wenn du mehrere Befehle hintereinander ausführst, dann willst du vielleicht, wenn die in irgendeiner Form zusammenhängen, dass die alle hintereinander ausgeführt werden und dass dir niemand anderer irgendwie hineingrätscht in deine Transaktion, in deine Abfolge von Queries.

Der Klassiker ist natürlich eine Bank, wenn du irgendwas überweisen willst, dann musst du auf dem einen Konto was abziehen, auf dem anderen Konto was hinzufügen.

Da willst du natürlich, dass diese Select-Query, dann die Update-Query, dann die nächste Update-Query, dass die auf jeden Fall in der richtigen Reihenfolge durchlaufen und dass nicht nach der zweiten Query, wo du minus 300 rechnest, dann plötzlich irgendwas passiert und das der neue Status ist, weil dann hast du gerade 300 Euro irgendwo verloren im Weltall, ohne dass es irgendwo anders auftaucht.

Hm?

Und dafür gibt es eigentlich Transaktionen, dass du eben sagen kannst, mit einem Start-Transaction und einem Commit am Ende, diese Queries, die dazwischen passieren, sollen auf jeden Fall durchlaufen.

Wenn etwas passiert, soll das Ganze wieder zurückgerollt werden, damit deine 300 Euro wieder am Konto landen und nicht irgendwo verschwinden.

Das heißt, entweder passiert alles oder gar nichts und zwischendrin wird auch noch sichergestellt, dass wenn ganz viele User auf der Datenbank sind, dass die sich nicht gegenseitig irgendwo in die Quere kommen.

Weil wenn du von demselben Konto mehrere User buchen da jetzt irgendwas ab und buchen es woanders wieder drauf, wenn du jetzt da ein Select-Statement machst, wie viel ist überhaupt auf dem Konto oben, dir den Wert merkst, dann 300 abziehst, in der Zwischenzeit hat aber irgendwer was anderes abgezogen oder hinaufgebucht, dann stimmt dein Wert schon nicht mehr von deiner Select-Anfrage.

Und das stellt ja die Datenbank sicher, wenn sie ACID-konform ist.

Also ACID steht für Atomicität, Consistency, wie heißt das auf Deutsch?

Konsistenz, danke, ja genau.

Konsistenz des Gerätes

Isolation und Dauerhaftigkeit, das sind eigentlich die vier Eigenschaften von ACID und die müssen eben sichergestellt werden, damit du so sinnvolle Banktransaktionen oder Bankapplikationen programmieren kannst.

Also das Atoma heißt eben alles oder nichts eigentlich.

Konsistent heißt, ich kann nicht zwischendrin irgendwie einen unkonsistenten Zustand haben, auch wenn mehrere User darauf zugreifen.

Die lesen immer den richtigen Kontostand zum Beispiel.

Der kann nie irgendwie falsch sein, wenn da mehrere Leute parallel arbeiten.

Isolation geht in dieselbe Richtung, also wenn ich jetzt gerade etwas ändere an der Datenbank, aber meine Transaktion noch nicht abgeschlossen ist und du, Christian, eine Transaktion startest, dann wirst du nie das sehen, was ich gerade mache, weil wir eben in Isolation eigentlich arbeiten, obwohl wir parallel arbeiten, aber die Datenbank stellt eben sicher, dass das trotzdem isoliert eigentlich stattfindet und die Dauerhaftigkeit heißt, wenn am Schluss das Commit passiert, das heißt, ich weiß, meine Transaktion ist durchgelaufen, meine 300 Euro wurden überwiesen,

Hm.

dann ist es auch wirklich so und dann ist es auf der Festplatte gespeichert.

Das heißt, wenn da ein Stromausfall ist, in dem Moment, wo ich das Commit bekomme, ist mir das egal, weil ich weiß, trotz Stromausfall liegt es auf der Platte festgeschrieben und nach einem Neustart ist es auch wieder da und das Geld ist nicht verloren gegangen.

Das sind eigentlich so die Transaktionen und das war damals die große Neuigkeit oder das Feature von InnoDB, weil das MyISAM damals nicht unterstützt hat.

Also MyISAM konnte kein ACID, InnoDB hat dann ACID eingeführt.

Und darum war eigentlich auch die Meinung, MySQL ist ein Telefonbuch mit SQL-Schnittstelle, weil natürlich die ganzen großen Datenbanken immer ACID unterstützt haben und darum alle gesagt haben, ja MyISAM, das ist ja nicht mal sicher, ich mache da ein Insert und dann bin ich mir nicht mal sicher, ob das gespeichert ist, mache ich zweimal Updates, bin ich mir auch nicht sicher, was da passiert.

Und darum war eigentlich die Kritik damals.

Wobei auch da wieder muss man sagen, wer verwendet heutzutage Transaktionen in den Applikationen?

Also welche ProgrammiererInnen hat schon mal Start Transaction und Commit wirklich explizit ausgeführt?

Brauchst du wahrscheinlich bei 99% aller Applikationen auch nicht.

Manchmal wäre es vielleicht schön und man könnte da mehr eigentlich einbauen, aber in der Realität wird es auch ganz selten gemacht, weil man eben selten eine Bank implementiert und wenn du in einem Shop arbeitest und der Strom fällt aus und du verlierst diese Banane, die du gerade in deinen Shopping-Basket gelegt hast oder deinen Sneaker, ja, dann wird die Welt nicht untergehen.

Liegt alles im Auge der betrachtenden Person.

Ich kenne da so einige Leute, wenn die jetzt neue Konzerttickets sich klicken wollen, dann ist das für die ein persönliches Drama.

Das stimmt natürlich.

Konzerttickets sind ein großer Punkt, weil da hast du zehntausende User, die auf nur, keine Ahnung, tausend Plätze wollen oder hunderttausend User auf zehntausend Plätze und da müssen dann Transaktionen natürlich gut funktionieren.

Da hast du dann aber meistens auch noch Transaktionen, die vielleicht dann übergreifender sind mit der Zahlungstransaktion.

Das heißt, da wird meistens eher der Platz reserviert in der Datenbank für 15 Minuten, dann wird die ganze Zahlung durchgeführt und dann hast du vielleicht so ein Aufräumstatement wieder, was dir nach 15 Minuten alle rauskickt, die noch nicht bezahlt wurden.

Jetzt haben wir ganz viel über die technischen Unterschiede gehört und wo die Standards eigentlich herkommen und die Geschichte des Projekts.

Wir können ja mal ein bisschen darüber reden, was eigentlich unser erster Berührungspunkt damit war.

Ich glaube, bei Enrico dürfte es ähnlich sein wie bei mir.

Was war das erste Projekt, das du mit MySQL umgesetzt hast damals?

Ich glaube, das ist gar nicht so ähnlich und es ist einigermaßen nasty und heute wird man es nicht mehr so tun.

Das sind die besten Geschichten.

Es war einmal vor langer, langer Weile, irgendwann 2008, da kam ein Kollege zu mir, der war da Security-Verantwortlicher und meinte, Mann, das ist voll doof, nee, das fing anders an, das war der Mail-Server-Beauftragte, der kam und sagte, hey, wir haben hier so unterschiedliche Mail-Server.

Da war Lotus Notes damals mit im Spiel, da gab es einen Virenscanner mit im Spiel und es gab einen, ich glaube das war ein Standard, was ist ein Postfix, wer versendet, was ist empfangend, irgendwas, irgendwas, irgendwas, also jedenfalls drei Stages, draußen in der DMZ ist was, dann kommt der Virenscanner, dann geht es zu Lotus Notes.

Alle davon schicken unterschiedliche Logs, alle davon sind mehrfach redundant ausgelegt und ab und zu geht was schief.

Dann hat er gesagt, das wäre doch jetzt voll cool, wenn irgendetwas hier diese ganzen Logs parsen könnte und das irgendwo hinschreiben könnte und mir dann genau sagen würde, welchen Verlauf hat denn jetzt eigentlich eine E-Mail über die unterschiedlichen Server gemacht, weil das vorher ein manueller Prozess war, wo er dann sich die Mail-ID genommen hat, auf alle Systeme sich verbunden hat und versucht hat rauszufinden, wo lief denn jetzt das Ding mit welchem Status lang.

So, und dann war da der kleine Enrico, der gedacht hat, eine Datenbank, gibt's bestimmt irgendwas, SQL hab ich schon mal gehört, also war es eine MySQL und da ich schon damals Sprachen verachtet hab, die sich, also die Variablen auf Datentypen festgelegt hat, gibt's eigentlich nur PHP, was für mich in Frage kam, weil ich ja auch dann eine Web-App draus machen sollte.

Hehehe.

Und hab dann tatsächlich einen Log-Parser geschrieben, der dann diese ganzen Mail-Logs einigermaßen normalisiert hat und irgendwie versucht hat, das waren teilweise mehrzeilige Outputs, die da irgendwie zusammengekriegt wurden, also ganz nasty Zeugs.

Und das waren dann gigabyteweise Daten, die ich da damals schon dann pro Tag da reinschieben musste und dann, also ich glaube, hätte es damals schon Elasticsearch gegeben, wäre das toll gewesen, gab es aber nicht und dann habe ich das in MySQL abgebildet und ich habe wilde Klassen geschrieben, die dann auf Basis der Felder, die requestet wurden, dynamisch die SQL-Statements dann zusammengebaut hat und das hat sich alles, ich habe das irgendwann noch später nochmal angeguckt, ich habe es nicht mehr verstanden.

Bin mir sicher, es kann alles viel besser gelöst werden, als ich das damals hatte, aber das war meine erste Berührung mit MySQL, eine Sache, die ich damit umsetzen durfte.

Und später kam dann noch so Checken von Referrern, also um Phishing-Seiten aufzudecken, wo irgendwie nochmal so Content nachgeladen wurde und dann wurde das immer mehr und mehr, was in diese Datenbank und in diese Anwendungssammlung reingeht.

wäre eigentlich interessant zu wissen, ob das heute immer noch so lebt oder ob und wann die das eigentlich ersetzt haben.

Ja, ich hoffe doch, dass Sie es ausgetauscht haben.

Ich hoffe auch.

Es war PHP 5.

Never change a running system.

Es ist lange her.

Ja, immerhin PHP 5 schon, nicht PHP 3 oder irgendwie sowas.

Ja.

Und du, Christian?

War das dieselbe Geschichte?

Nee, das ist irgendwie, habe ich da eine andere Erwartung gehabt.

Irgendwie sind wir da falsch, beide vielleicht falsch abgebogen.

Das muss man glaube ich selbst bewerten.

Das dürfen unsere Zuhörenden machen.

Aber es hat auch mit PHP zu tun im weitesten Sinne.

Denn ich habe damals so angefangen, wir hatten den ersten DSL-Anschluss, ich habe Bücher gelesen, die ich mir irgendwo gekauft habe und angefangen zu programmieren.

Und ja, was musste man damals haben in den frühen 2000ern?

Natürlich brauchst du ein Gästebuch und einen Besucherinnenzähler für deine Webseite.

Und da habe ich dann halt so Skripte, die es im Netz gab, genommen und habe dann auch angefangen, mich mit der Datenbank dahinter zu beschäftigen.

Auch völlig overengineert eigentlich.

Also eine vollwertige Datenbank, nur dass du da plus eins drin speicherst.

Das hätte man vermutlich einfacher lösen können.

Ja.

Und dann habe ich meine erste IT-Ausbildung abgeschlossen und da sollte man ein Abschlussprojekt eben abgeben und ja, da habe ich halt gedacht, komm, du machst jetzt schon ein bisschen PHP, du hast ein bisschen Datenbank gemacht, na dann mach doch so ein eigenes CMS.

Ich glaube, das war damals Standard, dass Menschen ihre eigenen CMS geschrieben haben, obwohl es schon, ich glaube, WordPress gab es damals auch schon.

Und ja, habe dann halt so ein kleines, sehr limitiertes CMS darin geschrieben, wo man halt einfache Inhalte hinterlegen konnte und auch so einen ganz, ganz billigen What-You-See-Is-What-You-Get-Editor drin hatte, wo du so Fats und Unterstrichen und Überschrift erster Ebene und so weiter machen konntest.

und ja, das hat mir dann eine gute Note eingebracht und ich habe es dann nie wieder weiterentwickelt.

Ich war total ambitioniert, komm, wir entwickeln das weiter.

Es gibt auch den Quellcode immer noch im Netz, so ist es nicht.

Lustig wäre jetzt gewesen, hättest du gesagt, ja, und das haben wir dann Drupal genannt und seitdem haben wir das ein bisschen weitergebaut.

Hahaha.

Nee, so weit war es dann nicht.

Aber ja, da ist dann nie groß was geworden.

2009 war das, also die Version gibt es immer noch, aber ich habe das nicht mehr weiterentwickelt, weil ich dann doch festgestellt habe, so dauerhaft große Projekte, Das ist jetzt so nichts, was ich vielleicht tagtäglich tun sollte.

Hm.

...

Und wie war es bei dir, Wolfgang?

Das war dein erstes Projekt?

Ich bin mir nicht mehr ganz sicher, wann MySQL wirklich dazugekommen ist, Weil ich habe damals in den 90ern, also ich glaube da war das 16 oder 17, so eine eigene Webseite gehabt.

Die habe ich übrigens immer noch, diese Domain.

By the way, weil wir gerade bei Domain sammeln sind.

Cool.

Handyinfo.at hat die geheißen, da ist nichts mehr oben.

Da hat man dann auch gratis SMS versenden können, was in den 90ern natürlich sehr cool war.

Ja.

Mit einem kleinen Hack, den ich da im Hintergrund betrieben habe, bis mal die Mobilfunkbetreiber draufgekommen sind.

Und mir ein böses E-Mail geschrieben haben.

Ich habe es dann aber weitermachen dürfen.

Sie wollten nur sagen, ich hätte eigentlich fragen sollen davor.

Das waren noch die guten alten 90er.

Und da hatte ich auch so eine Handybörse.

Und ich bin mir nicht mehr sicher, ob das File-based war oder schon mal SQL-based.

Auf jeden Fall später habe ich genau das gleiche gemacht wie der Christian.

Ich habe mir gedacht, ich entwickle meinen CMS.

Wobei in den 90ern hat es noch keine Open-Source-CMS gegeben.

Und die große Konkurrenz war, glaube ich, Imperia hat das geheißen, aus Bayern oder aus München, die haben irgendwie so eine Million verlangt, dass du dieses CMS installieren hast können.

Und das denkt man so als Informatiker, ja, man macht das natürlich selber, programmiert das selber.

Und da war eigentlich so das erste Mal mit PHP 3 übrigens, wo man sich noch so selber Cookies und so implementieren hat müssen, damit man überhaupt irgendwie ein Login macht.

Uff.

Und da habe ich auch eine sehr schräge Story, weil ich mir gedacht habe, wie man es so klassisch macht, wenn man jung ist.

Man will das natürlich perfekt machen und ich mir gedacht habe, Das CMS, bevor es fertig ist, braucht ein perfektes Rechte-Management-System, ein hierarchisches Rechte-Management-System, was keine Ahnung, was unterstützt hat.

Am Ende gab es immer nur einen Administrator, by the way.

Aber ich habe das gebaut mit einem super hierarchischen System und habe das damals über ein Neste-Set-Modell gemacht.

Keine Ahnung, ob das jetzt zufällig was sagt.

Ich habe damals vom Christian Köhn-Top, da gab es so ein paar Slidesfolien in den 90ern, wie man das schafft mit Self-Joints in MySQL so ein hierarchisches Baummodell in die Datenbank zu bekommen, ohne dass man da irgendwie Rekursion benötigt.

Und dass man mit einer simplen Anfrage komplexe Bäume, irgendwie Substrukturen abfragen kann.

Wie gesagt, ich habe es nie in meinem Leben gebraucht, es war absolut premature optimization, aber ich hatte ein hierarchisches Permissionssystem dank Christian Küntop.

Wahnsinn.

Das Internet vergisst du übrigens nie.

Ich habe gerade mal einen Link aus dem Internet-Archive von deiner alten Seite.

Emoticons gab es da offensichtlich auch.

Also da, ja, sehr schön.

Also falls du dich mal Throwback-mäßig da rein geben willst, können wir ja vielleicht die aus der Wayback-Maschine das mit in die Shownotes packen.

Cool.

Das kommt auf jeden Fall in die Shownotes.

...

sogar mit Bildern, wow!

Ja, es ist wirklich so Peak Early 2000 Webdesign.

...

Da fehlt eigentlich nur noch der Hinweis Best Viewed with IE6 bei.

Das war noch vor 2000, also das war dürft so...

...

wann habe ich damit gestartet?

Ich schätze mal so '98 oder so.

Ich wollte mal gucken, der letzte, der erste Punkt ist 1999

Ja.

Wow.

im November, dass die Wayback Machine das aufgesogen hat.

Wie viele CDs mit Word Arts hattest du?

Ich hatte auch noch eine Webseite davor, die hat geheißen all4free.net.

Das war nur so eine Auflistung, wo du gratis Zeug bekommen kannst.

Irgendwie so gratis Icons, gratis Webcounter für Administratoren, gratis anderes Zeug.

Das war glaube ich wirklich 96 oder so.

Hammer, ja, das hier, das, da gibt's auch noch einen Wegpunkt in der Waybig Machine, pack ich auch mit rein

Hammer.

das kann also sein, dass ich mein nicht selbst gebautes Gästebuch oder Besucher-Counter für meine BeepWorld-Seite oder was auch immer damals so aktiv war von dir noch bekommen habe

Wahnsinn, da kommen Erinnerungen hoch.

das Internet war ein schöner Platz

ja ist so also auch hier diese auflistung der emotikons von damals ja also

ich finde das passt aber auch in die Episode wir reden ja schließlich über 30 Jahre MySQL und da gehört auch irgendwie 30 Jahre Internetgeschichte mit dazu.

Machst du nix.

ja voll ab absolut ja ich finde es auch schön das sind schöne erinnerungen an die zeit von damals also auch an die erste webseite die man hochgeladen hat und dann sich rum ärgern musste wie man jetzt das PHP auf dem Managed Server aktiviert bekommt und in der Punkt-HTACCESS rumfummeln musste und so weiter.

Das möchte ich nicht missen.

Also es waren schöne Zeiten, wo man mit Tabellen noch irgendwelche, mit Icons in Tabellen,

Ja.

mit Images und Transparent GIFs und schöne Designs gebastelt hat.

Ja, ja, ja.

Das waren noch die guten alten Zeiten, ja.

HTML 4.0.1 in der Transitional und in der Strict Variante habe ich sehr intensiv genutzt damals, Das weiß ich noch.

Ja, wunderbar.

Wir haben auch ein paar Fragen aus der Community gesammelt und Enrico hat auch eine mit reingemogelt.

Was wollen die Leute denn da draußen so wissen über unser Thema heute?

Also Dirk wollte auf jeden Fall wissen, wie eigentlich aus der Tabellenverwaltung so eine echte Datenbank geworden ist.

So geschichtlich.

Haben wir das eigentlich schon, das haben wir schon so ein bisschen mit abgehandelt heute, oder?

Also grundsätzlich die Tabellenkalkulation, die klassische Tabellenkalkulation war eigentlich später, würde ich sagen.

Weil die ersten Datenbanken waren ja wirklich in den 60ern.

Das waren die Netzwerkdatenbanken, die eben wirklich als Netzwerk auf diesen Bändern oben gewesen sind.

Oder die hierarchischen Datenbanken, auch noch sowas, das waren so die ersten, wo man eben das noch nicht getrennt hat, wie speichert man die Daten, wie fragt man die ganzen ab und ich glaube, dass es zu dieser Zeit gar keine klassische Tabellenkalkulation schon gegeben hat.

Ja.

Ja.

Also ich vermute mal, die ist erst so mit Windows 3.11 gekommen.

Da gibt es ja dieses bekannte Werbevideo mit Steve Palmer, glaube ich, wo er so anpreist, dass sie jetzt Tabellenkalkulationen haben in 3.11 oder so.

Wobei wahrscheinlich hat es in DOS-Zeiten auch schon Tabellenkalkulationen gegeben.

Aber ich vermute fast, dass Datenbanken früher waren.

Ja, stimmt.

Und das...

Ja.

Ist auch so.

Also ich meine, wir reden, wenn wir über Tabellenkalkulation reden, dann denken die meisten Leute, glaube ich, erstmal an Excel bzw.

der Vorgänger davon, Microsoft Multiplan.

Und das war so zu Windows 2.0 Zeiten, also Anfang der 80er, so 82 rum.

Und das ist natürlich völlig recht, da gab es im wissenschaftlichen Bereich oder im industriellen Bereich auf jeden Fall vorher schon Datenbanken und das ist schon eine ganze lange Weile.

Ja, dann hatte ich mich noch gefragt, was ist eigentlich der Unterschied zwischen InnoDB und MyISAM und ich habe mich halt immer daran erinnert, dass man konnte das halt setzen, wenn man so eine, ich glaube, wenn du eine Datenbank angelegt hast, war es, da konntest du ein unterschiedliches Dingens davon wählen.

Sehr viel davon haben wir heute schon mit besprochen, dementsprechend würde ich mir merken, InnoDB ist the way to go.

Genau, das kann man auch so sagen.

Ich glaube, dass Maya Aysam gar nicht mehr mitgeschiebt wird.

Würde mich jetzt ehrlich gesagt sogar wundern.

Ja, ich bin mir nicht ganz sicher.

Vielleicht kann man, es liegt jetzt noch irgendwo im Hintergrund rum, aber heutzutage spricht eigentlich nichts mehr gegen InnoDB.

Ja.

und ist seit MySQL 5.5 auch der Standard und MySQL 5.5 ist schon schon ziemlich alt also es war irgendwann 2010 oder so ist man schon über 15 Jahre her sein

Ja.

...

Sounds about right.

...

Christian, hast du noch was aus

...

Musik...

Mastodon und anderen Kanälen an Fragen bekommen?

Philipp vom Klick-Klack-Hack-Podcast, der auch schon mal bei euch zu Gast war,

...

...

...

war eine schöne Folge über mechanische Tastaturen,

...

kann ich sehr empfehlen, packen wir auch mal in die Shownotes.

Der wollte wissen, woher der frühere All-Cups-Zwang kommt und ich muss zugeben, wenn ich Statements schreibe, ich schreibe die immer noch in Cups.

Macht ihr das auch oder bin ich jetzt hier der Boomer unter uns?

Na, ich mach das auch so meistens.

Ich schreibe keine Statements mehr.

Ja, du lässt die Vibe schreiben, ich weiß schon.

Wipe-Prompting für Sequel-Statements, das ist doch jetzt der neue heiße Scheiß vielleicht.

Ja, aber die KI schreibt normal auch Großbuchstaben.

Es hat sich irgendwie so etabliert als Standard, ist aber kein Standard, ist nur Konvention und funktioniert üblicherweise auch, kannst auch Camel Case schreiben oder so, funktioniert meistens auch, machen ja auch viele und kommt einfach historisch aus der ganzen Mainframe-Zeit beziehungsweise Terminal-Zeit, wo man wahrscheinlich einfach nur Großbuchstaben hatte oder keine Ahnung, dass halt Großbuchstaben immer geschrieben hat.

Also ich bin zwar alt, aber so alt bin ich jetzt auch noch nicht, dass ich Terminalzeiten miterlebt habe.

Das war dann wirklich vor meiner Zeit.

Aber scheinbar war das früher, aus den Zeiten kommt das Ganze.

Ob das da Pflicht war bei so ganz uralten IBM System R, das war so die erste relationale Datenbank, die es überhaupt gegeben hat, ist eine gute Frage.

Aber wie gesagt, der Standard sagt nichts dazu aus, beziehungsweise gibt keine Verpflichtung diesbezüglich.

Wobei, ich habe jetzt neulich mal mit Oracle zu tun gehabt, da war irgendeine Großschreibpflicht bei irgendeinem Keyword.

Beim Semikolon, oder?

Stimmt, verwechsel ich auch ständig.

Wobei, es gibt doch dieses eine Symbol, das wie ein Semikolon aussieht, aber halt einen anderen ASCII-Wert hat.

Und das war doch lange so ein geheimer Trick, wenn du deine Kolleginnen abnerven willst, dann tauschst du einfach an manchen Stellen das Semikolon durch dieses Zeichen aus, sie sehen es nicht und ärgern sich dann,

...

weil sie stundenlang debuggen.

Als Österreicher muss ich sowieso sagen, dass eigentlich ein Semikolon ja viel zu kompliziertes Wort ist, weil wir sagen einfach Strichpunkt.

Okay, ja, Strichpunkt, stimmt

Ah.

In Österreich heißt es Strichpunkt und das Komma heißt Beistrich.

Ah, okay, aber letzteres ergibt wenig Sinn Irgendwie für mich, oder liegt es jetzt an mir

Der Beistrich.

Ja, das klingt irgendwie merkwürdig

Ja, ihr habt da auch schon sehr viele Probleme in Pair Programming Sessions erlebt zwischen Österreichern und Deutschen, weil Beistrich einfach, passiert mir selber auch teilweise noch, aber bei uns sagt niemand Komma.

Das gibt es in Österreich nicht.

Sagt niemand.

Bei euch ist ja auch der Jänner und nicht der Januar, ne?

Genau, ja.

Ich war neulich auch mal in Österreich unterwegs im Urlaub und hab dann auch so manche Gepflogenheiten musste ich mir dann erstmal dolmetschen.

Ah, Januar heißt das.

Ja, willkommen im Kultur- und Sprachpodcast.

Genau.

Genau.

Das wäre doch

Finde ich gut.

auch mal so eine Folge wert, so die sprachlichen Gepflogenheiten.

Das könntet ihr doch auch mal bei euch mit aufnehmen, so kulturelle Challenges.

Wir machen das eigentlich eh ständig, also diese kulturelle Challenge besteht ständig zwischen mir und Andi.

Und ich habe mir gedacht, Andi hat nach drei Jahren jetzt irgendwas gelernt, aber wenn ich ihn jetzt frage, was heißt, es geht sich aus oder du gehst mir ab, sagt er mir garantiert auch wieder das Falsche.

Wunderbar.

Ja, ich blicke auf ein Pad, das voller Notizen ist und ich glaube, wir haben alles so mehr oder weniger abgehandelt.

Gibt es irgendwas, das wir vergessen haben zu fragen, Wolfgang?

Nö, ich glaube, wir sind ganz gut durch die Geschichte gesprungen und haben auch gezeigt, dass nach 30 Jahren MySQL immer noch gut am Weg ist und eine gute Datenbank ist.

Und auch wenn es jetzt so einen Postgres-Hype gibt, ich persönlich bleibe meistens zumindest MySQL immer noch treu.

Ich kann auch mit der Konsole irgendwie besser umgehen als mit der BG Shell und es ist einfach nicht meins.

Ja.

Aber ist natürlich auch unfair, wenn man das irgendwie 20 Jahre trainiert hat, dann ist klar, was man lieber macht und einfacher.

...

Musik...

Ja.

Vor allem habe ich so das Gefühl, dass da auch einfach andere Use Cases noch mit rein spielen.

Also wir haben jetzt ja gehört, MySQL und MariaDB sind vor allen Dingen relationale Datenbankmanagement-Systeme,

...

während Postgres ja ein objektrelationales Datenbankmanagement-System ist.

Das heißt, da ändert sich ja rudimentär, so mein Verständnis als Leier, auch die Art und Weise, wie Informationen gespeichert werden.

Wir haben halt keine Tubel, Zahlen, Spalten, sondern also schon in der Repräsentation, aber ich glaube, es wird im Binärformat ganz anders gehandhabt, oder?

Meines Wissens ist Postgres schon auch ganz klassisch relational.

Also die klassischen objektrelationalen Datenbanken, das waren eigentlich immer nur Aufsätze, die probiert haben, die Objektwelt irgendwie zu übertragen auf relationale Welten, also sowas ähnliches wie die Objektrelational Mapper, die ORMs, aber schon in der Datenbank quasi, dass die das direkt übersetzen, haben sich aber nie durchgesetzt.

Okay.

Vielleicht hat Postgres da mal irgendwie einen Anlauf auch gewagt, aber eigentlich speichert Postgres schon die Daten ganz klassisch auch in einem relationalen Modell ab.

Es gibt aber wesentlich mehr Plugins und Möglichkeiten, da auch andere Storage-Engines in dem Sinne zu verwenden bei Postgres, auch so Column-Stores, wobei MariaDB auch mittlerweile einen Column-Store hat.

Also wenn man das nicht zeilenbasiert, sondern spaltenbasiert abspeichern will, um der Performance rauszubekommen bei Big Data Anwendungen.

Also das kann MariaDB mittlerweile auch, aber Postgres hat da sicher mehr Möglichkeiten oder jetzt auch mit AI-Vektor-Datenbanken, die da drüber gestülpt werden.

Also da gibt es schon einiges, was bei Postgres passiert und das ist vielleicht auch aktuell dem Hype geschuldet, weil da einfach mehr Leute auf Postgres setzen.

Ich sehe das vor allen Dingen bei Anwendungen, muss ich zugeben, also Anwendungen im Sinne von Server-basierter Anwendung.

Und bei Web-Anwendungen sehe ich das gar nicht so häufig.

Also klar, das gibt es auch.

Wenn du dir einen WordPress oder generell einen CMS oder einen Wiki installierst, haben die meisten gängigen Projekte da auch Support für.

Aber ich sehe das häufig bei so Server-basierten Anwendungen, bei so einer Patch-Management-Suite zum Beispiel.

Da ist halt eine Postgres hinten dran.

Und da geht es mir wie Enrico, wenn ich da Dinge tun muss.

Also ich habe mir mittlerweile so ein paar Sachen gemerkt, wie Backslash-D, um die Tabellen zu sehen.

Backslash-Q, um die Shell wieder zu verlassen.

Und okay, man sich dann einfach in einen Switch-User, dann auch zu machen, auf den Datenbank-User und dann da in die Datenbank-Session reinzuspringen, kann ich mich auch dran gewöhnen.

Aber es gibt schon so ein paar Dinge, die kriege ich halt nach über zehn Jahren MySQL und MariaDB benutzen einfach nicht mehr eintrainiert.

Da bin ich ganz ehrlich.

Turns out, irgendjemand hat es auf jeden Fall geschafft, Doom auf Postgres zu laufen zu bringen.

Das habe ich für MySQL jetzt noch nicht gefunden.

Ah, ja, ja, ja.

Pegi Doom, sehr, sehr schön.

Auch die Namensgebung eingehalten.

Das ist ja grandios.

Okay, ich kann leider kein Kyrillisch, aber wir packen das.

Unten drunter ist noch ein Link mit Englisch.

Ah, super.

Cool.

Ja, was hat dich alles gebt, wa?

Ja, spannend.

Nee, aber Wolfgang hat es ja schon kurz zusammengefasst.

Also beide Projekte werden trotzdem weiterhin noch aktiv entwickelt.

Also MySQL 9.4 ist am 9.7.2025 erschienen, an meinem Geburtstag, sehr schön.

Und die 8.4.

LTS ist im April rausgekommen, 2024, und wird auch bis 2032 unterstützt.

Und ja, also Grunde, beide Projekte sind immer noch lebendig.

Es tut sich da viel.

Ich muss auch regelmäßig in meinen Setups die Container-Images hochbumpen, weil mal wieder eine neue Version rausgekommen ist.

Und gibt es irgendwas, das euch fehlt, dass ihr dem Projekt auf die To-Do-Liste packen würdet für die nächsten 30 Jahre?

Nein.

Also ich bin auch eigentlich sehr zufrieden, muss ich sagen.

Und eigentlich alle Use Cases, die ich so benötige, kann man eigentlich ganz gut mit irgendwelchen Tools abbilden.

Also ich bin nie eigentlich an Grenzen gestoßen, zumindest an keine klassischen Grenzen, die jetzt feature-technisch irgendwie wären.

Optimizer-Grenzen gibt es immer, aber die gibt es in jeder Datenbank.

Bei mir ähnlich.

Also ich glaube, ich nutze vermutlich 0,9% der Features der Datenbanken und seitdem auch Encoding mit UTF-8 nicht mehr so ein Thema ist, ich glaube, da habe ich irgendwann aufgehört, neue Features zu benötigen, zumindest in meiner Wahrnehmung.

Also würde ich mich anschließen.

Natürlich würde ich dem Projekt auch für die nächsten 30 Jahre alles Gute wünschen und hoffen, dass es mindestens genauso weiterentwickelt wird wie bisher.

Und ich glaube, das kann man auch mal zum Anlass nehmen, den EntwicklerInnen zu danken, die da regelmäßig ihrer Arbeit nachgehen und Bugs fixen, neue Features einbauen und dafür sorgen, dass man halt eben auch in einer aktuellen News-Distribution das einfach konsumieren kann.

Auch das, glaube ich, ist jetzt kein einfaches Unterfangen immer.

Ja, voll nett.

Und es ist einfach eine Datenbank, die sich 30 Jahre lang schon optimiert hat.

Also vielleicht ist sie einfach featuretechnisch ausgereizt schon, würde ich jetzt mal nicht sagen, weil PostgresCAD immer noch mehr Features, aber ich würde sagen, es ist schon eine solid Datenbank, die man jedem ans Herz legen kann, die super schnell ist, die auch funktioniert, wenn man zum Beispiel nur 100 Megabyte RAM oder so hat.

Das ist natürlich auch noch eine Seltenheit, die man zum Beispiel in einem Docker-Container betreiben kann, mit ganz wenig RAM.

Also das sind schon Vorteile und die Einfachheit.

Das heißt, ich würde es immer noch empfehlen, auch wenn heute ganz viele auf dem Postgres-Zug natürlich aufspringen.

Ich würde eher sagen, für die nächsten 30 Jahre wünsche ich dem Projekt, dass sie die Aufgabe, die sie gut machen, weiter gut machen und nicht anfangen, eine eierlegende Wollmichsau werden zu wollen.

Also du willst kein MySQL GPT, habe ich das jetzt richtig verstanden?

Das, also eine AI, die mir erklärt, wie ich damit umgehen kann, schon, aber ich will jetzt nicht, dass die nächste serverless Function, bau dir hier dein Frontend, hast du nicht gesehen, Clicky Wunty, Low-Code, No-Code, Workflow-Geschichte, daraus würde mich traurig machen.

Ja, dann würde ich sagen, springen wir mal in die Tool und Medien Tipps.

Wolfgang, du hast uns auch einen Tipp mitgebracht.

Worum geht es bei deinem Tool?

Und zwar ist das Schema.io ein wirklich cooles Tool, was ermöglicht, dass du, man kennt ist vielleicht klassischerweise, wenn man Migrations macht in der Software, das heißt, dass die Tabellen sich updaten, man hat da irgendwie eine komische, meistens eine DSL oder eine gewisse Syntax, wie man in Code dann die Tabellen definieren muss, damit man dann sagen kann, okay, eine neue Spalte und die wird dann abgedatet.

Und Schema geht da eigentlich einen bisschen anderen Weg.

Das ist eigentlich ein Management-System, das dir ermöglicht, die Unterschiede vor allem zwischen zwei Schema in einer Datenbank herauszufinden.

Das heißt, wenn du Produktiv-Schema hast, ein Developer-Schema, dann kann dir dieses Schema das alles managen.

Das heißt, es weiß genau, okay, bist du jetzt im Dev-Zustand, bist du im Prod-Zustand, erzeugt dir dann auch automatisch diese ganzen Queries, die du brauchst, um von einem Schema ins andere zu kommen, also diesen Migration-Pfad, auch diesen Pfad zurück, wenn du ein Rollback machen musst.

Mhm.

Also das ist eigentlich dafür ausgelegt, möglichst viel am Schema direkt zu arbeiten, ohne dass du jetzt irgendeinen speziellen Syntax brauchst.

Dann kannst du das Ganze natürlich in GitHub auch dokumentieren.

Äh, nicht in GitHub, natürlich mit jedem Git, sorry, keine Weibung.

Kannst du mit jedem Git machen, dass du wirklich die Änderungen von deinem Schema dementsprechend committest immer, dokumentierst und das unterstützt das Tool auch sehr gut damit.

Du kannst natürlich dann auch schnell in deinem Docker irgendwie in eine Datenbank hochfahren und gleich das Schema implementieren oder deployen.

Du kannst es auf verschiedenen Servern deployen, auch wenn du ein Cluster hast, gibt es da Möglichkeiten.

Und wer sich da mal anschauen will, wie das dann in der Königsklasse funktioniert, denen empfehle ich einen Vortrag von der FOSDEM.

2020 ist schon etwas älter, aber ist wirklich ein sehr cooler Vortrag vom Schlomi Noack, der bei GitHub, damals war der, war früher bei Booking, dann bei GitHub und hat sich immer im MySQL gekümmert und war da auch Contributor.

Und der hat eigentlich gezeigt, wie er mit Schema, beziehungsweise wie GitHub mit Schema zusammen die kompletten Datenbankänderungen von 1000 MySQL-Servern eigentlich managt.

Die haben sich da noch was drüber gebaut, weil die haben natürlich ganz viele Schema-Updates und so ein Schema-Update ist immer ein Problem, weil wenn du eine Spalte hinzufügst auf ein Produktivsystem, dann geht das System mal fünf Stunden schlafen oder 24 Stunden schlafen, macht eine Spalte hin dazu und dann kommt es wieder mal, was eher schlecht ist, wenn du GitHub bist.

Und darum haben die ein Online-Schema-Change-Tool entwickelt, das auf diesem Schema-IO basiert.

Das heißt, die Grundlage bietet das Schema-IO, die ganzen Unterschiede und wie die das dann ausrollen auf ihre tausenden Servern, automatisiert über Git natürlich mit Code Reviews oder SQL Reviews, wie man das auch sehen will.

Das muss am Ende dann noch ein DBA abnicken und dann geht das in eine komplett automatisierte Pipeline und wird auf allen Systemen ausgerollt.

Also es ist wirklich sehr cool zu sehen, der ganze Prozess.

Und darunter liegt eben dieses Schema I.O., mit dem man die ganzen Schema da managen kann.

Und kann ich demnach nur empfehlen, wer jetzt nicht auf Code Migrations arbeitet, Sobald man eben irgendwie mit Änderungen zu tun hat, ist das super, weil das einfach automatisch alle Unterschiede auch erkennt.

Und wenn man das mal händisch gemacht hat, weiß man, wie kompliziert das ist.

Und dann hat man im Dev-Schema noch irgendwo was geändert, vergisst da was abzudaten und man hat aktuell absolutes Chaos.

Und dieses Chaos verhindert dieses Tool.

Cool, klingt sehr spannend.

Was hast du uns mitgebracht, Enrico?

Ich bin heute mit dem Thema mal frech, aber da Jan noch im Urlaub ist, nehme ich mir einfach seinen Spot für seinen Tooltip.

Ich habe zwei Dinge, die visuell veranschaulichen, was denn die Datenbank so tut oder was man da so hat und wie das irgendwie so alles zusammenhängt.

Das eine ist das PRP My Admin.

Das hat wahrscheinlich jeder, der auf seinem XAMPP-Stack irgendwie mal sowas zusammengebastelt hat, das schon mal gesehen.

Einfach eine schöne Web-Editor oder beziehungsweise Web-Verwaltungsoberfläche, wo ich dann meine Daten sehen kann, Queries fahren kann, mal was exportieren kann, was am Schema ändern kann.

Das fand ich eine ganz schöne Sache.

Und wenn man jetzt nicht irgendwie noch einen Web-Server neben seiner Datenbank laufen hat, fand ich immer ganz gut MySQL Workbench als Client, den man nutzen kann.

Da fand ich auch ganz nett, das hat auch so einige Performance-Grafen und sowas, dass man ein bisschen reingucken kann, was ist da eigentlich gerade, was laufen da vielleicht gerade auch für Queries so mit drin.

Also das fand ich sehr interessant, hat mir oft geholfen, wenn kein PHP-MyAdmin vorhanden war und ich zu faul oder unwissend für die CLI war.

Und du, Christian?

coole sache ja ich habe einen exporter mitgebracht und zwar für promis es gibt es einen mysql die exporter und da kann man eben bei einer mysql oder maria db installation wenn das ausgeführt wird so diese gängigen metriken die man vielleicht im monitor haben möchte an promis aus senden das heißt man sie dann was für cues werden gerade gemacht ich kann auf gewisse datenbanken mich nur limitieren und kann dann sehen wird mehr lied gemacht wird mehr right gemacht.

Also alles, was man in so einem schönen Dashboard vielleicht mal visualisieren will, um zu gucken, ob es

...

meiner Anwendung und der Datenbank dahinter gut geht, das hilft bestimmt bei dem ein oder anderen Analyseproblem.

Und damit, glaube ich, haben wir das Thema ganz gut zusammengefasst.

Vielen Dank, lieber Wolfgang, dass du dir die Zeit genommen hast, mit uns über ein sehr wichtiges Thema zu sprechen.

Über Datenbanken spreche ich immer gerne, gar kein Problem.

Ja.

Stundenlang.

Ja, ich fand es auf jeden Fall spannend, auch mal so zu hören, wo das Ganze herkommt und Vor allen Dingen, was man damals für Probleme hatte und wie man sie vielleicht dann auch gelöst hat.

Und nicht alles schlecht war es ja der Übernahme von Oracle.

Das fand ich auch ganz interessant mal zu sehen, weil da habe ich überhaupt keinen Einblick zu gehabt.

Also vielen Dank für die ganzen Anekdoten und Details dazu.

wie der andy mein kohaus immer sagt der alte mann erzählt vom krieg Danke.

Ja, ich bin ohnehin mal gespannt, lieber Andi, falls du hier zugehört haben solltest, wie die Reaktion auf die Intro-Parodie bei dir angekommen ist.

war natürlich mit einem Augenzwingen und mit einer Wertschätzung verbunden.

Wir hoffen natürlich, das kam auch so an.

Abmahnung ist raus.

Abmahnung ist raus, genau, Jingle verwendet, zack.

Ja, wenn unsere Zuhörenden Feedback an uns richten wollen, wie machen sie das am besten, Enrico?

Ja, also erstmal sind alle Angaben natürlich wie immer ohne Proprietär.

Ihr könnt uns Kommentare hinterlassen.

Ihr könnt uns insbesondere auch mal im Apple-Universum da bei Apple Podcast mal eine Bewertung da lassen.

Wenigstens mal ein paar Sterne, das ist nämlich noch komplett blank.

Zumindest war es das das letzte Mal, als ich geguckt habe.

Ihr könnt das bei Spotify tun, im Podcatcher eurer Wahl und wenn euch das nicht reicht, dann tut ihr das bei uns auf der Website.

Und mein absolutes Lieblingsformat ist natürlich das gute alte analoge Fax.

Für diejenigen, die aus Österreich zuhören, ihr müsst dann eine Plus 4.9 vorwählen.

Aber ansonsten könnt ihr uns gerne auch einen Fax schicken unter 0421 417 37109 und das lesen wir dann auch gerne in der nächsten Episode vor.

Ansonsten erreicht ihr uns auf Mastodon unter atuserspace, atpodcast.social, im Matrix-Chat und Urlaub im Userspace auf Matrix.org.

Und ja, Christian, was ist eigentlich der Hashtag der Episode?

Ich hab mir gedacht, Wir könnten auf jeden Fall mal MySQL 30 nehmen und genau, richtig, MySQL 30, jetzt haben wir es schon, MySQL 30 und da wir hier so eine schöne Kollabo haben, finde ich, ist auch der Hashtag Urlaubskiosk auch angebracht, wie ich finde.

MySQL wolltest du sagen?

MySquirrel30, ja?

Sehr schön, sehr schön.

Ja, in dem Sinne, vielen Dank an euch, liebe Zuhörende, fürs Zuhören.

Vielen Dank an euch fürs Mitmachen.

Es war mir ein innerliches Blumenpflücken.

Hat sehr viel Spaß gemacht.

Ein seelischer Gabelbissen.

Vielen Dank.

Macht's gut, bis dahin.

Ciao.

Bis dann, ciao