#19 Datenbank-Deepdive (oder das Ende einer Ära): von Redis bis ClickHouse

Der zweite Datenbank-Deepdive im Engineering Kiosk.

Indirekt knüpfen wir an Episode 8 mit dem Thema Datenbanken. Diesmal fangen wir aber ganz vorne an: Mit hierarchischen Datenbanken über Objektorientierte Datenbanken, anschließend zu SQL bis hin zur NoSQL und Spaltenorientierten Datenbank-Ära. Dabei klären wir Fragen was zum Beispiel der Unterschied zwischen Datenbanken und Dateien ist, ob OOP-Datenbank immer noch ein Hype ist, was Indexe sind und wie diese funktionieren, warum die Migration weg von Oracle schwierig sein kann, ob Lucene eine Datenbank ist und noch viel viel mehr.

Bonus: Was Kürbiskerne mit Datenbanken zu tun haben und warum MySQL ein besseres Adressbuch mit SQL Interface ist.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Sprungmarken

(00:00:00) Intro

(00:00:55) Mathematik-Professoren und Kürbiskern-Brötchen

(00:02:27) Warum Datenbanken ein Herzensthema von Wolfgang ist

(00:04:08) Was ist denn eine Datenbank und wann verwendet man eine Datenbank?

(00:06:34) Sind klassische Dateien auch eine Datenbank?

(00:07:25) Hierarchische Datenbanksysteme: IBM IMS

(00:09:30) IBM Mainframes, Go, Docker und horizontale Skalierung

(00:11:30) Was wäre ein Use-Case von hierarchische und Objekt-Orientierte Datenbanken?

(00:16:15) Hast du bereits eine Objekt-Orientierte Datenbanken bereits in einem Projekt eingesetzt?

(00:16:52) Trennung von Daten und Applikationslogik und SQL als Basis-Datenbanken-Wissen

(00:18:55) Was ist der Unterschied von SQL-Datenbanken und Dateien

(00:19:32) Datenbank Index/Indize: Daten-Duplikation, Lese- und Schreibzugriffe

(00:23:54) Ist eine Excel-Datei eine Datenbank?

(00:24:58) Unterschied von Files und Datenbanken: Nutzung von mehreren Benutzern

(00:28:03) Recovery, persistentes und konsistentes Speichern bei Files und Datenbanken

(00:31:01) Relationale Datenbanken sind die eigentlich klassischen Datenbanken

(00:34:31) Proprietäre Datenbanken: Oracle Migration nach PostgreSQL

(00:37:06) Oracle Cloud und das Free-Tier

(00:38:29) MySQL wurde von Oracle übernommen und MariaDB als Alternative

(00:39:48) Logik in der Datenbank, Oracle-Migrationen und Application-Server

(00:41:10) Gibt es ein Killer-Argument für proprietäre Datenbanken?

(00:43:57) Woher kommt der Name MySQL und MariaDB kommt?

(00:45:19) Ist ElasticSearch eine Datenbank nach der klassischen Definition?

(00:46:38) Ist Redis und andere Key-Value-Stores eine Datenbank?

(00:48:42) NoSQL ist für Kinder, Feature-Ritis, Einfache Datenbanken und LevelDB / RocksDB und MyRocks

(00:53:19) Was sind Spalten-Datenbanken und wann sollten diese angewendet werden? Analytische Datenbanken und Clickhouse von Yandex

(00:58:15) Was für Fragen sind relevant um die richtige Datenbank für mich zu finden?

(01:01:43) Feedback zum Thema Datenbanken und Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

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

Andy Grunwald (00:00:03 - 00:00:50)

Willkommen in eurem Lieblingskiosk. Thementechnisch sind wir in dieser Episode Wiederholungstäter und mal wieder mit einem technischen Thema. Wolfgang ist mir so lange auf die Nerven gegangen, bis er wieder über sein Wunschthema sprechen darf, Datenbanken. Wir knüpfen nicht direkt an Episode 8 an, wo wir bereits über Datenbanken gesprochen haben, sondern fangen ganz vorne an, bei hierarchischen Daten. Wir klären, was eine Datenbank ist, wo die Unterschiede zu normalen Dateien sind, ob objektorientierte Datenbanken noch in Benutzung sind, was eigentlich spaltenorientierte Datenbanken sind und wieso die gerade im analytischen Umfeld so viel Anklang finden. Weiterhin geht es auch um die Fragen, ob Redis nur eine Hashmap mit IP-Interface, MySQL nur ein Adressbuch mit SQL-Schnittstelle und NoSQL wirklich nur für Kinder ist. Viel Spaß mit dieser Episode und los geht's mit Kürbiskernen.

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

Hallo Wolfgang. Einen wunderschönen, sonnigen guten Morgen aus Österreich.

Andy Grunwald (00:01:00 - 00:01:18)

Ich freue mich, dass ich dich so früh aus dem Bett holen konnte. Und ich habe mich gerade gefragt, es gibt ja den Begriff eine unchristliche Zeit. Gibt es auch den Begriff unakademische Zeit? Oder wie nennt man das, wenn man Akademiker so früh aus dem Bett holt? Weil ich meine, die erste Vorlesung wird doch erst, wenn sie überhaupt besucht wird, gegen elf oder zwölf besucht, oder?

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

Also wir hatten einen Mathematikprofessor, der um Punkt 8 Uhr seine Vorlesung begonnen hatte.

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

Und die Skripte hast du in Eigenarbeit nachgearbeitet?

Wolfi Gassler (00:01:27 - 00:01:31)

Ich glaube diese Vorlesung war nicht Pflicht, ich habe sie dann irgendwie geskippt.

Andy Grunwald (00:01:31 - 00:02:02)

Für alle Hörer und Hörerinnen ein bisschen Kontext. Wir schreiben 8 Uhr 38 in der Früh, weil unser Terminkalender wieder bis an die Decke gefüllt ist. Und Wolfgang, weil wir direkt an einem Morgen aufnehmen, und morgens frühstückt man in der Regel, ich habe mir gestern eine Frage gestellt, und zwar waren wir gestern beim Bäcker, wir haben Kürbiskernbrötchen gekauft, und ich habe mir das Kürbiskernbrötchen aufgeschnitten, und dann fallen mir, aus welchen Gründen auch immer, immer alle Kürbiskerne vom Brötchen. Passiert dir das auch?

Wolfi Gassler (00:02:02 - 00:02:04)

Deine Probleme möchte ich haben.

Andy Grunwald (00:02:05 - 00:02:19)

Passiert dir das auch? Weil ich habe mich gefragt, wenn das jeden passiert, warum kauft man dann ein Kürbiskernbrötchen, wenn doch eh alle Kürbiskerne vom Brötchen fallen, wenn man das aufschneidet? Also mein Teller war voll Kürbiskernbrötchen und ich glaube, ich hatte nur noch zwei oder drei Kürbiskerne auf dem Oberteil des Brötchens.

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

Ja, du kannst die zusammen sammeln und dann wieder in das Brot hineintun.

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

Liebe Hörerinnen und Hörer, mich würde mal interessieren, ob ihr einen solchen logistischen Aufwand am frühen Morgen macht.

Wolfi Gassler (00:02:28 - 00:02:31)

Dinge, die die Welt bewegt oder nicht bracht.

Andy Grunwald (00:02:31 - 00:03:27)

Kommen wir mal zu einem Thema, was hoffentlich die Welt bewegt. Und zwar, heute kümmern wir uns um ein Wunschthema vom Wolfgang. Ich habe den Wolfgang gefragt, welches Thema sollen wir denn als nächstes aufnehmen und er hat sich ein Thema gewünscht, was ihm natürlich ganz am Herzen liegt. Und zwar knüpfen wir an eine vorherige Episode an, an die Episode 8. Da ging es um das Thema Datenbanken. Wir haben primär um relationale Datenbanken, MySQL, Postgre, SQLite und Co gesprochen. Und der Wolfgang hat da unter anderem ein sehr provokatives Statement rausgebracht, das besagt, viele Applikationen wären besser bedient, wenn sie Files nutzen würden, anstatt Datenbanken auf Basis der Read-Write-Patterns und der Datenmenge und auch generell, was sie mit den Daten machen. Da wollen wir heute mal ein bisschen anknüpfen und auch ein bisschen weitergehen. Und Wolfgang, ich würde gerne mal von dir wissen, warum ist das ein Herzensthema von dir? Warum hast du dir dieses Thema für heute gewünscht?

Wolfi Gassler (00:03:27 - 00:04:47)

Das Hauptproblem war, dass ich als Datenbankakademiker, wenn ich das mal so nennen darf, eigentlich gechallenged wurde, weil wir ja eine Rückmeldung bekommen haben von einem Hörer, Herbert, vielen Dank. der irgendwie gemeint hat, wenn ihr schon so viel über Datenbankmodelle spricht und wenn man nur lesenden Zugriff hat, dass man Fals verwenden kann, warum macht ihr denn das nicht ordentlich und erwähnt auch Spaltendatenbanken oder warum man Zahlendatenbanken verwendet, wo der Unterschied ist und so weiter. Und das war natürlich für mich sofort eine Challenge, dass wir da mehr in die Tiefe gehen und das mal probieren zumindest ordentlich zu behandeln und da mal etwas in die Tiefe gehen, weil Klassischerweise ist halt Datenbanken bei den meisten Leuten nur MySQL oder wenn es in die hipster Richtung geht MongoDB und das war es dann auch schon. Und darum auch meine Frage jetzt von der akademischen Seite. Was ist denn für dich eine Datenbank und wann verwendet man eine Datenbank? Du hast ja letztes Mal schon auf die Wirtschaftsinformatik heraus geredet. Was du jetzt wahrscheinlich nicht weißt ist, dass ich mal die Einführungsvorlesung Datenbanken für Wirtschaftsinformatiker gemacht habe. Und ich habe mir da jetzt meine Slides von damals herausgesucht, meine Intro-Slides. Und da geht es genau um dieses Thema. Warum verwendet man Datenbanken und was ist eigentlich eine Datenbank? Und darum jetzt meine Frage an dich als Wirtschaftsinformatiker. Was ist denn eine Datenbank und wann verwendet man denn eine Datenbank?

Andy Grunwald (00:04:47 - 00:05:15)

Ich hatte im vorherigen Podcast bereits dazu aufgerufen, dass ich einen neuen Podcast-Host suche. Jetzt wäre mal wieder so eine Zeit. Ich fühle mich gerade so ein bisschen in einen Pranger gestellt. Meine Einführungsveranstaltung zu Datenbanken hatte ich, glaube ich, im Bereich Wirtschaftsinformatik im zweiten Semester, im dritten Semester, irgendwie sowas. Und ich glaube, wir hatten auch die ein oder andere Slide zu dem Thema, was ist eigentlich eine Datenbank? Ich muss aber sagen, das ist circa zwölf Jahre her.

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

Das ist ja Basiswissen, das vergisst man nie, so wie Fahrradfahren.

Andy Grunwald (00:05:19 - 00:05:40)

Was ist eine Datenbank? Ich würde sagen, und ich bewege mich jetzt weit von der akademischen Korrektheit, eine Datenbank ist ein System, und ein System kann auch eine Datei sein, die Daten vorhält und diese in einer strukturierten Form abfragbar und schreibbar macht.

Wolfi Gassler (00:05:40 - 00:05:46)

Klingt ziemlich plausibel, würde ich mal sagen. Was ist der Unterschied oder wo siehst du den Unterschied zu Files?

Andy Grunwald (00:05:46 - 00:06:13)

Prinzipiell erstmal gar keinen Unterschied, weil Files kann ich ja auch durch die klassischen Befehle strukturiert schreiben oder nicht schreiben. Die Datenbank selbst, die Definition von der Datenbank, enthält ja erstmal keine Information, wie die Daten gespeichert werden, in welchem Format oder ähnlichem. Und deswegen kann ich, je nachdem wie man die Daten selbst strukturiert, natürlich auch eine klassische Datei als Datenbank nutzen.

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

Also ich lese dir mal die Wikipedia-Definition vor. Eine Datenbank, auch Datenbanksystem genannt, ist ein System zur elektronischen Datenverwaltung. Die wesentlichen Aufgaben einer Datenbank ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern und benötigte Teilmengen in unterschiedlichen, bedarfsgerechten Darstellungsformen für Benutzer- und Anwendungsprogramme bereitzustellen. Ziemlich genau das, was du eigentlich schon gesagt hast.

Andy Grunwald (00:06:41 - 00:06:51)

Ja, wobei ich mir die Frage stelle jetzt, bei klassischen Dateien den zweiten Teil in verschiedenen Ansichten dem Nutzer bereitzustellen. Oder wie war der korrekte Wortlaut?

Wolfi Gassler (00:06:51 - 00:06:55)

Bedarfsgerechte Darstellungsformen für Benutzer- und Anwendungsprogramme.

Andy Grunwald (00:06:55 - 00:07:30)

Okay, das Wort bedarfsgerecht lässt natürlich sehr, sehr viel Freiraum, wo ich dann schon wieder sagen müsste, ach ja, Files könnten da eigentlich klassisch als Datenbank durchgehen. Ich meine, wenn ich jetzt mal an so eine CSV-Datei denke oder Ähnliches, dann ist das ja schon, die CSV bedient ja schon in irgendeiner Art und Weise einen Bedarf. Und dann kommt es, glaube ich, darauf an, wenn man jetzt mal an Datenbank Views denkt, dann kann es natürlich sein, dass man die CSV dann in eine JSON-Datei umwandelt oder XML, was dann natürlich andere Access-Patterns mit XPath und ähnliches ermöglicht. Also würdest du sagen, Files würden als Datenbank durchgehen?

Wolfi Gassler (00:07:31 - 00:07:45)

Das ist gar nicht so leicht zu beantworten, vor allem nach dieser Definition, wenn ich zurückdenke an die hierarchischen Datenbankmodelle in den 60er Jahren, das übrigens immer noch verwendet wird von IBM in der IMS und auch immer noch weiterentwickelt wird, erstaunlicherweise.

Andy Grunwald (00:07:45 - 00:08:11)

Wofür steht jetzt IMS? Weil IMS, erinnere ich mich auch an die letzte Episode, ist natürlich auch das Incident Management System der Feuerwehr. Wer mehr zum Thema Incident Management und Feuerwehr hören möchte, kann sich natürlich gerne mal unsere vorherige Episode anhören. Und zwar ist das die Episode 17, wo wir darüber gesprochen haben, was wir beim Incident Management von IT-Systemen von der Feuerwehr lernen können. Wofür steht EMS im Bereich Datenmarken?

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

Also es gibt die IBM EMS Information Management System, nennt sich das. Wie gesagt, hierarchische Datenbanken wurde in den 60ern entwickelt, gibt es mittlerweile in der Version 15. Interessanterweise habe ich mal einen Podcast gemacht, ich glaube vor 15 Jahren, zu Datenbanken. Da war das IMS 12 oder so und wir haben schon darüber gelacht, dass die immer noch weiterentwickelt wird, weil das wirklich aus den 60er Jahren ist das System. Und eigentlich gemacht wurde um, vielleicht kennst du das aus den alten Filmen, wo im Hintergrund so Bänder laufen, so James Bond oder so, wenn im Hintergrund ganz große Datencenter und irgendwie so diese Bänder ablaufen. Das waren hierarchische Datenbanksysteme für diese Bänder und darauf wurden die Daten gespeichert. Wenn du jetzt sagst, so wahlfreien Zugriff und so, was bei Files schwieriger möglich ist, das war natürlich auch bei diesen Bändern eigentlich nicht möglich, weil du hast dieses Band vor- und zurückspulen müssen, um überhaupt zu dieser Position zu kommen, wo deine Daten gespeichert waren. Also nach der Definition, nach der Wikipedia-Definition wären diese hierarchischen Datenbanken, die garantiert Datenbanken, waren eigentlich gar keine Datenbanken. Also es ist gar nicht so leicht zu sagen, ob jetzt Files dazugehören oder nicht.

Andy Grunwald (00:09:22 - 00:09:27)

Wenn wir über hierarchische Datenbanken sprechen, dann sagtest du, okay, die werden jetzt gerade also noch weiterentwickelt.

Wolfi Gassler (00:09:27 - 00:09:36)

Ja, ich kenne eigentlich nur IBM, dieses IMS. Ob es da noch andere Datenbanken gibt, wage ich zu bezweifeln. Wie gesagt, es ist ein System aus den 60ern.

Andy Grunwald (00:09:36 - 00:09:41)

Fun Fact, wusstest du eigentlich, dass IBM immer noch Mainframes entwickelt und diese auch noch produziert und verkauft?

Wolfi Gassler (00:09:42 - 00:09:45)

IMS ist also ein Klassiker im Mainframe Bereich.

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

Und wusstest du eigentlich, dass IBM sich natürlich nicht von den anderen großen Firmen abhängen lassen wollte und deswegen auch Sprachen wie Go, Golang und Co. auf die IBM Mainframe, auf die Z-Architektur portiert hat?

Wolfi Gassler (00:10:01 - 00:10:05)

Das heißt, du kannst jetzt normale Go-Programme auch auf der Z-Architektur laufen lassen?

Andy Grunwald (00:10:05 - 00:10:28)

Prinzipiell haben sie es gemacht, um Docker und Kubernetes lauffähig zu machen. Und es gibt in GitHub von IBM den offiziellen Go-Fork, also den Fork von der Go-Programmiersprache von Google, in der Docker und in der Kubernetes geschrieben ist. Und damit du halt Kubernetes und Docker und Co. und etcd und wie sie alle heißen auf einem IBM Mainframe laufen lassen kannst.

Wolfi Gassler (00:10:29 - 00:10:33)

Das heißt, ich kann ein Docker-Image jetzt auf einem Mainframe hochspinnen?

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

Kannst du. Und das Tolle ist ja eigentlich, ich mein, so ein Mainframe hat ja etliche CPUs und der hat ja, weiß ich nicht, wie viel Terabyte RAM. Also das Ding ist ja unglaublich ressourcenstark.

Wolfi Gassler (00:10:44 - 00:10:46)

Moderne Mainframes zumindestens.

Andy Grunwald (00:10:46 - 00:11:21)

Natürlich. Wir reden jetzt hier von einer IBM Z16 oder ähnliches, ja? Und da verlinken wir euch gerne mal die aktuelle Produktseite von IBM auch in den Shownotes. Aber das Lustige ist eigentlich, wenn du ein Kubernetes auf einem Mainframe betreiben würdest, dann brauchst du ja eigentlich gar nicht so viel horizontale Skalierung, weil die Kiste ist halt einfach so stark und hat, glaube ich, weiß ich gar nicht, wie viele Netzteile. Also ein Mainframe selbst ist ja schon ausfallsicher gebaut bis unters Dach. Und all diese Netzwerkprobleme und Cross-Kommunikationsprobleme, die hat man ja theoretisch dann mit einem Mainframe gar nicht. Oder bin ich da falsch?

Wolfi Gassler (00:11:22 - 00:11:33)

Du bist ein Mainframe Spezialist, aber grundsätzlich sollte eigentlich jedes Teil in dem Mainframe meines Wissens zweimal vorhanden sein, damit es ausfallen kann. Das war wirklich jedes Hardware Teil.

Andy Grunwald (00:11:33 - 00:11:36)

Das war ein kleiner Exkurs zu IBM.

Wolfi Gassler (00:11:36 - 00:11:38)

Aber kommen wir zurück zu Datenbanken, genau.

Andy Grunwald (00:11:38 - 00:11:50)

Erklär mir mal ganz kurz, was wäre denn ein Use Case von hierarchischen Datenbanken? Weil als ich studiert habe, dann wurden mir immer hierarchische Datenbanken und objektorientierte Datenbanken verkauft.

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

Du hast wirklich noch hierarchische Datenbanken gelernt?

Andy Grunwald (00:11:52 - 00:12:19)

Auf dem Papier. Ich wusste, dass es die irgendwie so gibt. Aber ich selbst hab sie noch nie implementiert. Genauso wie ich hab noch nie objektorientierte Datenbanken implementiert. Also nicht die Datenbank selbst, sondern benutzt. Und ich will jetzt von dir wissen, was wäre denn mal ein klassischer Use Case von einer hierarchischen Datenbank? Und, wenn du gleich dabei bist, von einer objektorientierten Datenbank. Weil ich glaube, danach, auf dem klassischen Zeitstrahl, da kommen dann die klassischen SQL-Datenbanken.

Wolfi Gassler (00:12:19 - 00:14:50)

Also hierarchische Datenbankmodelle waren eigentlich die ersten Datenbankmodelle und die Grundidee war damals, dass man die Daten und die Software, also das Programm, die Abarbeitung, nicht in demselben Bereich speichert, dass man einfach Daten vom Programm splittet. Das, was heutzutage eigentlich ganz klassisch ist, du speicherst nicht irgendwie den Programmcode und die Daten in derselben Datei, zum Beispiel in deinem Code. Das war halt früher alles zusammen in einem Bereich gespeichert und die hierarchischen Datenbanken haben das dann wirklich als eigenes Datenbanksystem ausgegliedert. Das ist einfach eine alte Technologie, die hierarchisch aufgebaut ist, so in einem Baum und das ist einfach ein Modell, was eigentlich gar nicht mehr verwendet wird. Da gibt es keinen Anwendungsbereich, dass man das heutzutage noch verwendet. Danach waren die Netzwerkdatenbanken, die werden heutzutage wieder in neuer Form mit Graf-Datenbanken bedient, wo man einfach ein Netzwerk hat, das heißt, wo die Einträge wahllos verknüpft sein können, also nicht so wie in einem Baum, wo es nur nach unten geht und ein Knoten in einem Baum kann natürlich nicht fünf Elternknoten zum Beispiel haben, bei Netzwerkdatenbanken oder heutzutage bei Graf-Datenbanken. kann es natürlich sehr wohl der Fall sein. Also diese Modelle werden dann schon noch verwendet, aber das hierarchische Datenbankmodell gibt es glaube ich nur mehr bei IBM. Aber vielleicht, wenn irgendwer da draußen IBM, IMS oder irgendwie das hierarchische Modell noch verwendet, bitte nur her mit der Info, würde mich auch schwer interessieren, ob das noch irgendwo verwendet wird. Heutzutage eben vor allem im modernen Umfeld irgendwo. Aber um zu deiner Frage nochmal zurückzukommen, objektorientierte Datenbanken, das war mal ein großer Hype, ich würde mal sagen vor 20, über 20 Jahren wahrscheinlich. Und die Idee war, bei objektorientierten Datenbanken vor allem durch die neue objektorientierte Programmierung, dass du ja immer mit Objekten arbeitest in deiner Programmiersprache, in Java zum Beispiel. Und da wäre es natürlich naheliegend, wenn die Datenbank auch diese Objektstrukturen verstehen kann und du die Objekte in Java einfach direkt in die Datenbank legen kannst, ohne sie umformen zu müssen in irgendeine Tabellenstruktur. Und das war eigentlich die Idee damals, hat sich aber eigentlich nie durchgesetzt. Es gibt heutzutage schon noch ein paar objektorientierte Datenbanken. Ich glaube im Java-Bereich ist DB 4.0 heißt die meines Wissens. Die war mal zumindestens recht verbreitet, die diese Objekte direkt annehmen kann und dann auch die Verknüpfungen zwischen den Objekten, also quasi die Relationen, auch direkt abspeichern kann. Das war so die Idee. Aber wie gesagt, hat sich einfach nie durchgesetzt.

Andy Grunwald (00:14:50 - 00:15:09)

Aber die Datenbank speichert die dann die interne Repräsentation des Objektes, weil die interne Repräsentation des Objektes ist ja meist an die Programmiersprache gebunden. Nehmen wir jetzt mal Java, da hat natürlich die JVM ziemlich viel zu sagen und da sieht dann ein Objekt anders aus als bei einer anderen objektorientierten Sprache, wie zum Beispiel C-Sharp.

Wolfi Gassler (00:15:10 - 00:15:39)

Ja, da geht es mehr darum, dass man ein Objekt hat, das halt mehrere Member-Variablen oder mehrere Einträge hat, verschiedene Integer-Werte, String-Variablen zum Beispiel, und die werden einfach direkt dann abgebildet. Und wenn es dann eine Verknüpfung gibt, wenn du einen Pointer hast auf ein anderes Objekt, dann wird halt dieser Pointer auch mit abgespeichert und dann wieder automatisch zurücktransferiert in Java, wenn du das Ganze liest. Dann hast du automatisch die Relationen zurückübersetzt in Pointer in deine Programmiersprache.

Andy Grunwald (00:15:39 - 00:15:57)

Und wie kann ich mir da die Abfragesprache vorstellen? Hol ich mir da immer ganze Objekte inklusive dem kompletten Objektbaum? Oder kann ich dann auch wirklich so was sagen wie, gib mir mal bitte alle Objekte, die in der Member-Variable foo gleich bar haben und die einen Pointer auf ein anderes Objekt haben? Oder wie sieht das aus?

Wolfi Gassler (00:15:57 - 00:16:07)

Da gibt's dann eigene Abfragesprachen oder Anfragesprachen, die genau das ermöglichen, dass du sagen kannst, okay, gib mir alle, die den Wert größer fünf haben oder so was.

Andy Grunwald (00:16:07 - 00:16:30)

Der Use Case erinnert mich aber schon irgendwie grad sehr stark an aktuelle Graf-Datenbanken mit Edges und Nodes und so, weil an eine Node kann man ja auch Metadaten dran packen und so weiter. Aber da kommen wir dann gleich mal zu. Objektorientierte Datenbanken, okay, sagtest du, die werden jetzt grad auch nicht mehr so wirklich angewandt. Hast du schon mal eine implementiert? Hast du schon mal ein Projekt gehabt, wo du eine objektorientierte Datenbank im Stack hattest?

Wolfi Gassler (00:16:31 - 00:16:42)

Ich glaube nicht. Im Java-Umfeld ist H2 noch sehr verbreitet, aber das ist meines Wissens eher eine relationale Datenbank. Ich kenne also kein System, das das wirklich verwendet.

Andy Grunwald (00:16:42 - 00:17:07)

Auch hier bitte an alle Hörerinnen und Hörer, falls ihr noch in einer Firma arbeitet, die noch produktiv eine objektorientierte Datenbank einsetzt, lasst es uns mal wissen, bitte auch mit der Information, ob diese zukunftsträchtig bei euch noch gesehen wird oder ob ihr irgendwie Migrationspläne Machen wir weiter. Wo sind wir auf dem nächsten Punkt im Zeitstrahl? Was kam danach? Kamen danach die SQL-Datenbanken, von denen ich gerade geredet habe, oder war da noch was dazwischen?

Wolfi Gassler (00:17:07 - 00:18:30)

Also wir springen jetzt schon wild hin und her in der Zeit, weil die objektorientierten Datenbanken sind nach den relationalen Datenbanken natürlich entwickelt worden, weil die relationalen Datenbanken waren glaube ich in den 70ern ungefähr und da war eigentlich das Neue, dass man die Daten von der Abfragesprache trennt. Also dass man wirklich sagt, man speichert die Daten in einem Tabellenformat dass man sich überlegt, eben das bekannte Schema, so wie man das heute in MySQL und in Oracle und in den ganzen relationalen Datenbanken macht. Und dann hat man eine Anfragesprache und die Anfragesprache kann diese Daten eben in mehreren Formen zur Verfügung stellen, dass du eben auch nicht immer dieses Format, diese Tabelle, dieses Schema bekommst, wie du es abgespeichert hast, sondern halt auch in irgendeinem anderen Format, dass du sagst, du kannst irgendwelche Tabellenspalten ausblenden zum Beispiel oder irgendwas in der SQL-Abfrage berechnen und du bekommst eine neue Spalte mit diesem berechneten Wert zum Beispiel. Also damit man das einfach trennt und dann auch mehr Möglichkeiten hat. Das ist, was du eigentlich am Anfang auch erwähnt hast, dass man eben die Daten in unterschiedlichen Formaten und in unterschiedlichen Darstellungsformen abfragen kann. Das war eigentlich die Neuerung von den relationalen Datenbanken. Und das ist das, was heute eigentlich so in der Datenbank gerne verstanden wird, beziehungsweise wenn man so als erstes an Datenbanken denkt.

Andy Grunwald (00:18:30 - 00:19:02)

Das ist auch mein Verständnis, beziehungsweise das, was ich so in der Gesellschaft beobachte. Jeder, der an Datenbanken denkt, und jeder, der irgendwie mit dem Thema Informationstechnologie in Berührung kommt, denkt und bekommt auch erst mal gelehrt, so was wie SQL, Primer, MySQL oder sehr, sehr viel PostgreSQL. In manchen Firmen natürlich auch proprietäre Datenbanken wie MSSQL von Microsoft oder Oracle. Aber das ist so das klassische, oh Datenbanken, oh wir haben SQL.

Wolfi Gassler (00:19:02 - 00:19:47)

Und wenn man da jetzt mal nochmal zurückgeht auf die ursprüngliche Frage, was ist denn der Unterschied zu Dateien, weil das kommt in meiner Einführungsvorlesung, damals war das auf den ersten Slides, was ist denn so der Unterschied oder der Vorteil zu Dateien überhaupt und ist eine Datei eigentlich auch ein Datenbanksystem? Wenn du natürlich jetzt drüber irgendwas aufpaust über die Datei und mehr Magic irgendwo reinpackst, dann ist das eigentlich deine Datenbank, weil die Datenbank muss natürlich die Dateien auch irgendwo abspeichern oder die Daten irgendwo abspeichern. Aber der Nachteil von Dateien ist natürlich einerseits die Effizienz. Du musst es immer sehr reell durchpausen und wenn du einfach extrem viele Daten hast, ist es halt langsam. Also das ist das Schlagwort Index eigentlich, dass Datenbanken durch Indizes optimieren können.

Andy Grunwald (00:19:48 - 00:19:55)

Kannst du einmal ganz kurz erklären, was ein Indiz ist auf einer klassischen SQL-Datenbank-Tabelle?

Wolfi Gassler (00:19:55 - 00:21:04)

Also die einfachste Form von einem Index ist eigentlich die Sortierung. Das heißt, wenn du ein Telefonbuch hast, dann sortierst du die Daten und wenn du dann nach irgendeinem Namen suchst, nach Andi Grundwald zum Beispiel, weißt du, okay, bei G musst du zu den Seiten springen, wo die Namen mit G sind. Und dann kannst du die Daten schneller suchen und abfragen. Man will aber natürlich jetzt nicht für jede Abfrage, wenn ich einmal nach Nachnamen suche und einmal nach Vornamen, einmal die Daten abspeichern, nach Vornamen sortiert und einmal nach Nachnamen sortiert, weil dann muss ich alle Daten duplizieren. Dafür gibt es nochmal diese Indizes, die halt wirklich nur aufgebaut werden, zum Beispiel für die Vornamen. Das heißt, ich mache eine eigene Sortierung mit den Vornamen, da stehen nur die Vornamen drin und dann weiß ich, okay, Wenn ich Andi suche, da steht dann drinnen, Datensatz 5 hat Andi, Datensatz 15 hat Andi und Datensatz 18 hat Andi. Also einfach so eine Lookup-Tabelle oder so ein Index, wie man es auch klassisch in einem Buch hinten zum Beispiel hat, wo die Schlagwörter stehen und dann die Seitenanzahl, wo man dieses Schlagwort findet. Das ist ganz klassisch ein Index, wie in der klassischen Bücherwelt.

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

Das bedeutet aber auch, dass die Daten partiell dupliziert werden, oder? Ja. Und doppelt vorgehalten werden.

Wolfi Gassler (00:21:09 - 00:21:20)

Genau, Teile werden natürlich doppelt gespeichert, hoffentlich in einem optimierten Format, aber darum brauchen Indizes auch Speicherplatz und Zeit, um sie zu erstellen und abzudaten.

Andy Grunwald (00:21:20 - 00:21:28)

Das wäre meine nächste Frage gewesen. Wie verhält sich denn ein Indiz bei Lese- und Schreiboperationen?

Wolfi Gassler (00:21:28 - 00:22:49)

Du musst dir das jetzt so vorstellen, du hast jetzt da zehn Bücher vor dir liegen, also zehn Indizes und in jedem Buch ist ein Index nach Vorname, im zweiten Buch ist der Index nach Straße, drittes Buch ist der Index nach Telefonnummer und so weiter. Also damit du die Daten eben suchen kannst nach Vorwahl von der Telefonnummer nach Vornamen, nach Nachnamen zum Beispiel. Und wenn du jetzt einen neuen Eintrag in dein Telefonbuch speichern willst, eben in Wolfgang zum Beispiel, dann musst du in all deinen drei Büchern, das Vornamenbuch, das Nachnamenbuch, Und das Straßenbuch musst du dementsprechend auch die jeweiligen Einträge eintragen und alles womöglich umsortieren, umändern. Und das kostet natürlich extrem viel Zeit. Das heißt, mit jedem Index, den man auch anlegt, muss man damit rechnen, dass Schreibzugriffe langsamer werden, weil man einfach mit jedem Schreibzugriff ganz viele Indizes updaten muss. Beim Lesen natürlich ist man viel schneller, wenn man jetzt sagt, okay, ich will nach der Straße suchen. Die beginnt mit G. Dann kann ich natürlich schnell zu allen Straßen mit G springen und muss nicht mein gesamtes Telefonbuch durchgehen, was ja eigentlich nur nach Vornamen oder nach Nachnamen sortiert ist und nach allen Straßen suchen, die mit G beginnen. Das heißt, beim Lesen hilft ein Index, beim Schreiben hat er eher Nachteile, weil alles länger wird und mehr Speicherplatz braucht.

Andy Grunwald (00:22:49 - 00:23:08)

Noch eine letzte Frage zu dem Thema Indizes. Muss ein Indiz beim Schreiben eines neuen Datensatzes komplett neu aufgebaut werden? Also wird der Indiz weggeschmissen und komplett neu geschrieben mit allen anderen Daten? Oder gibt es auch Algorithmen, die Indizes partiell updaten?

Wolfi Gassler (00:23:08 - 00:23:39)

Also hoffentlich geht es natürlich partiell, aber es gibt natürlich schon auch Systeme, die jetzt rein auf Lesen optimiert sind, sowas wie Lucene zum Beispiel. Die Frage ist, ist Lucene eine Datenbank? Kann man wieder diskutieren. Aber wenn du in Lucene zum Beispiel irgendwas änderst, musst du den Lucene-Index komplett neu aufbauen. Also Lucene, ein Volltext-Index, der zum Beispiel unter Solr oder unter Elasticsearch sitzt, den musst du einfach komplett neu aufbauen. Und das, was zum Beispiel Elasticsearch dazu baut, ist eben, dass man den partiell auch updaten kann.

Andy Grunwald (00:23:39 - 00:23:57)

Wenn wir von Lucene reden, sprechen wir von dem Apache Lucene Projekt. Das Projekt beschreibt sich selbst als Core Search Library und ist ein fundamentaler Basisbaustein von Apache Solr und so viel ich weiß auch von Elasticsearch. Ist das richtig?

Wolfi Gassler (00:23:57 - 00:24:00)

Ja, basiert alles auf Lucien unter der Haube.

Andy Grunwald (00:24:00 - 00:24:13)

Kommen wir zurück zu Files. Was gibt es noch für fundamentale Unterschiede zwischen Datenbanken und Files, zwischen Datenbanken und Dateien? Was mir gerade noch als Seitenfrage einfällt, ist eine Excel-Datei eine Datenbank?

Wolfi Gassler (00:24:13 - 00:24:15)

Was würdest du sagen?

Andy Grunwald (00:24:15 - 00:25:03)

Also wenn ich jetzt Excel, eine Excel-Datei mit SQLite vergleichen würde, würde ich sagen, ja. Weil die Daten werden in einer gewissen Struktur unten drunter gespeichert. Du kannst, du hast verschiedene Sheets in Excel. Das sind gegebenenfalls verschiedene Datenbanken. Dann kannst du S-Vorweise machen zwischen Datenbanken, Spalten, Zeilen. Du hast Funktionen da drauf. Du kannst gruppieren. Für mich ist das eigentlich, vielleicht sogar nutzt Excel eine SQLite und darunter weiß ich glaube ich gar nicht. Aber jetzt wo ich gerade drüber spreche würde ich sagen, yo, Excel ist eine Datenbank. Und wir reden nicht über Access. Access ist ja das kleine lokale Datenbank-Tool-Format. Oder vielleicht auch gar nicht so klein, weil ich glaube, in manchen Firmen wird das echt groß eingesetzt. Aber wir reden jetzt von Microsoft Excel, der Tabellenkalkulation.

Wolfi Gassler (00:25:04 - 00:26:19)

Im weitesten Sinne könnte man sicher sagen, dass es ein Datenbanksystem ist. Wenn man jetzt aber auf den nächsten Punkt geht, was der Unterschied zu File ist, sieht man schon, dass das Excel nicht anbietet. Und zwar ist es der ganze Bereich von Multi-User-Fähigkeit. Das heißt, dass mehrere User, mehrere Personen gleichzeitig auf den Daten arbeiten. Das funktioniert mit Excel eigentlich nicht mehr, außer du verwendest jetzt irgendwie so ein Google Excel, aber auch da werden jetzt keine Probleme zum Beispiel automatisch gefixt wie in klassischen Datenbanken, in relationalen Datenbanksystemen, wenn du jetzt zum Beispiel mit zwei Queries auf den gleichen Daten operierst. Das klassischste Beispiel, das es gibt, ist so ein Bankkonto. Du überweist Geld von Bankkonto 1 zu Bankkonto 2, musst auf Bankkonto 1 Geld abziehen und am anderen wieder Gutschreiben. Und wenn dazwischen irgendwo irgendwas passiert oder mehrere Programme auf diesen Konten gleichzeitig operieren, dass du dann Geld verlierst oder plötzlich mehr Geld am Konto ist oder im Umlauf ist, als es gibt. Und da bieten natürlich Datenbanken auch Systeme, mit der Serialisierung und mit Transaktionen, dass du das sicher machen kannst, dass du eben kein Geld verlierst.

Andy Grunwald (00:26:19 - 00:26:22)

Wenn du von operieren sprichst, sprichst du von lesen und Schreibzugriffen, oder?

Wolfi Gassler (00:26:22 - 00:26:58)

Genau. Wenn du Geld transferieren willst, musst du ja mal lesen, wie viel Geld ist auf diesem Konto oben. Dann berechnest du, okay, da waren 500 Euro oben. Ich will jetzt 200 Euro überweisen. Das heißt, es bleiben 300 Euro. Das berechnest du mal. Und dann sagst du, okay, jetzt will ich 300 Euro schreiben, dass der Kontostand nur mehr 300 Euro ist. Wenn in der Zwischenzeit aber irgendjemand auch da Geld abgebucht hat, dann überschreibst du plötzlich vielleicht den Wert mit 300, obwohl er in der Zwischenzeit eigentlich 0 sein sollte. Und dann hast du plötzlich irgendwie Geld erschaffen. Meistens ist es nicht im Sinne des Erfinders, dass du Geld schaffst. Also du bist irgendwie die Zentralbank oder irgendwelche Staaten.

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

Wobei natürlich, wenn man sich nur auf Lesezugriffe beschränkt und nicht auf Schreibzugriffe, ist es ja natürlich auch möglich, dass mehrere Prozesse, in diesem Fall Applikationen, eine Datei gleichzeitig lesen.

Wolfi Gassler (00:27:14 - 00:28:05)

Genau, das ist auch das, was wir in der Episode 8 besprochen haben, wo Files einfach gut funktionieren. Wenn du nur Lesezugriffe hast und ganz selten Schreibzugriffe und du weißt ganz genau, wie du schreibst und wer schreibt und dass keiner gleichzeitig schreibt, dann ist das eigentlich sehr performant, wenn du die Daten einfach genau so schreibst, wie du sie auch lesen willst. und dann können da einfach tausend Prozesse dieses File zum Beispiel lesen oder du hast In-Memory, können super schnell drauf zugreifen und du brauchst kein kompliziertes Datenbanksystem, weil man muss ja auch dazu sagen, die ganzen coolen Features, die du da bekommst, die sind natürlich auch extrem teuer, weil die sind hochkomplex, das Ganze zu zu berechnen und sicherzustellen, dass da alle Daten korrekt sind, konsistent sind. Und das ist natürlich alles andere als einfach. Darum sind Datenbanksysteme ja wirklich hochkomplexe Systeme.

Andy Grunwald (00:28:05 - 00:28:10)

Wenn du von dem Wort teuer sprichst, sprichst du nicht teuer im monetären Sinne, sondern eher im Applikations-Performance-Sinne.

Wolfi Gassler (00:28:11 - 00:28:11)

Genau.

Andy Grunwald (00:28:11 - 00:28:15)

Okay. Dateien, würde ich sagen, haben wir guten Abriss geliefert.

Wolfi Gassler (00:28:15 - 00:28:16)

Wo der Unterschied ist?

Andy Grunwald (00:28:16 - 00:28:19)

Er schüttelt den Kopf, er schüttelt den Kopf. So, jetzt hauen wir raus.

Wolfi Gassler (00:28:20 - 00:29:14)

Ein ganz wichtiger Punkt ist Recovery und persistentes Speichern, das bei klassischen Datenbanksystemen auch noch immer, also bei relationalen Systemen, immer als großer Vorteil angepriesen worden ist. Du weißt, wenn du was in der Datenbank gespeichert hast und die Datenbank dir zurückliefert, Thumbs up, ich habe das gespeichert, Dann kannst du dir sicher sein, dass das konsistent ist, dein Datenbanksystem. Das heißt, dass eben das gesamte Geld korrekt transferiert worden ist, dass die ganzen Konten korrekte Kontostände am Ende haben und dass die Daten irgendwo persistent auf deine Festplatte gespeichert worden sind. Irgendwo, irgendwann etwas crasht, dein Strom ausfällt, dein Server crasht, kannst du dir trotzdem sicher sein, dass du das Datenbanksystem wieder in den Recovery-Modus hochfahren kannst und keine Daten verloren hast. Und der stellt dir auch ein ordentliches Datenbanksystem sicher.

Andy Grunwald (00:29:14 - 00:29:22)

Und wieso stellt dir das eine Datei nicht sicher? Also ich meine, wann du die Daten schreibst und persistierst, obliegt ja der Applikationsarchitektur und Logik, oder?

Wolfi Gassler (00:29:23 - 00:30:03)

Klar, du kannst natürlich dein Datenbanksystem selber schreiben. Dann sind wir wieder da, wenn du die Magic selber baust von einem Datenbanksystem, dann hast du das natürlich in deinem selbstgebauten Datenbanksystem, in deiner Software, aber die Datenbank bietet dir das halt schon automatisch an, auch unter dem Gesichtspunkt, dass da mehrere Personen das gleichzeitig machen können. gleichzeitig auf der gleichen Datei operieren können und trotzdem alles sicher gespeichert ist. Und jeder, der weiß, wie das ist, wenn man gemeinsam eine Datei schreibt, auch in einer Software von zwei Prozessen, das ist eine Katastrophe. Du musst dann mit Locking arbeiten, kannst nur die ganze Datei locken, aber nicht nur eine Zeile. Also das ist extrem kompliziert und das nimmt dir die Datenbank eigentlich ab.

Andy Grunwald (00:30:03 - 00:30:54)

Man muss natürlich auch sagen, dass je nach verwendeter Datenbank man natürlich auch verschiedene Konfigurationsmöglichkeiten hat, was die Schreibpersistenz angeht. Also das bedeutet, bei verteilten Datenbanken kann man sagen, ich übergebe den zuschreibenden Rekord an die Datenbank und die Datenbank bestätigt mir, dass sie diesen Rekord empfangen hat. Dieser muss jedoch aber noch nicht auf die Festplatte persistiert worden sein, wohingegen man natürlich auch andere Settings haben kann, wie zum Beispiel, liebe Datenbank, bitte gib mir erst eine Rückmeldung, wenn dieser einzelne Rekord auf mindestens zwei Nodes wirklich auf die Festplatte geschrieben wurde und so weiter und so fort. Also je nach verwendetes Datenbanksystem. Und hier spreche ich primär von verteilten Datenbanksystemen. Kann man natürlich auch beim Schreiben verschiedene Schreibgarantien anfragen, was bei Dateien, glaube ich, eher mäßig möglich ist.

Wolfi Gassler (00:30:55 - 00:34:36)

Man muss jetzt auch dazu sagen, das sind diese Folien von meiner damaligen Vorlesung. Das sind ja auch schon einige Jahre her jetzt. Ich wollte es ja nur noch mal für dich rauskramen, damit du weißt, was du gelernt hast als Wirtschaftsinformatiker damals. Und das ist ein guter Punkt, den du erwähnt hast. Und ich habe ja auch immer gesagt, klassische Datenbanken oder das relationale Modell, Das war damals, sage ich mal, vor 30 Jahren eigentlich das Modell und wenn man von Datenbanken gesprochen hat, dann hat man von der relationalen Datenbank gesprochen, eine Oracle-Datenbank, eine IBM DB2-Datenbank, so die klassischen relationalen Datenbanksysteme. Es hat dann später auch in der akademischen Welt ein ziemlich bekanntes Paper gegeben, oder ein Paper, das dann ziemlich um die Welt gegangen ist. Und zwar hat es der Michael Stonebreaker unter anderem geschrieben. Das war 2008, ist by the way in Wien damals vorgestellt worden. Sorry, 2007 sehe ich gerade. 2007 auf der VLDB, Very Large Databases, die Konferenz. Da war ich zufällig auch, Wien, war ja um die Ecke. Und dieser Michael Stonebreaker, Erfinder von Postgres und Erfinder von extrem vielen Datenbanken, hat da ein Paper geschrieben, das sich nennt The End of an Architectural Era. Und was der eigentlich damals mit seinen Co-Autoren geschrieben hat, ist, dass es eigentlich nicht mehr diese Datenbank gibt, diese klassische Datenbank, die alles löst. Und er hat eigentlich prophezeit, beziehungsweise auch dargestellt, dass Datenbanken immer spezieller werden und du in Zukunft eigentlich Datenbanken hast, die dein spezielles Problem lösen und nicht mehr eine Datenbank wie die klassische Oracle Datenbank oder die IBM DB2, die einfach alles löst, wo du sagst, okay, das ist mein System für alle Use Cases, die ich in der Firma habe und nur diese Datenbank verwende ich. Das ist heutzutage auch ganz klar. Du hast Elasticsearch, wenn du das als Datenbank bezeichnen willst. Du hast klassische, relationale Datenbanksysteme. Du hast analytische Datenbanksysteme, wo es nur darum geht, Analytics zu machen, wo dann eben auch die spaltenbasierten Datenbanken meistens reinfallen, wo es darum geht, möglichst viele Daten schnell zu lesen, zu bearbeiten und dann Analytics draus zu machen. Du hast sowas wie Hadoop, Cluster oder Spark Cluster heutzutage. Also je nachdem, was du für Anwendungsfälle hast, hast du andere Datenbanken. Und das war eigentlich dieses Paper damals, das das eingeleitet hat und meiner Meinung nach auch sehr richtig vorhergesagt hat, dass es eben Spezialisierungen von Datenbanken gibt. Und da kommt dieser Punkt eben genau rein, dass du sagst, in vielen Anwendungsfällen brauchst du keine Transaktionen zum Beispiel, weil du hast einfach keine Geldszenarien, du bist keine Bank. Du willst einfach möglichst schnell Textsuche machen. Dann verwendest du Elasticsearch. Du wirst wahrscheinlich für eine Bank kaum ein Elasticsearch-Datenbanksystem verwenden, um die Konten zum Beispiel abzubilden. Also man muss sich einfach überlegen, was habe ich für einen Anwendungsfall und dann kann ich mir überlegen, was für Datenbank verwende ich, weil es halt heutzutage auch zahlreiche Datenbanken gibt und Datenbankmodelle gibt. Graf-Datenbanken haben wir auch schon zum Beispiel erwähnt, anderes Modell oder für Timeseries, für die ganzen Logdaten oder Metricking zum Beispiel würde man eher dann das verwenden. Und so gibt es halt zahlreiche Datenbanksysteme. Ich muss mir einfach überlegen, was ist das richtige System? Früher war es einfach. Früher ist der IBM-Vertreter vorbeigekommen, um Millionen irgendwie so eine DB2 oder eine Oracle gekauft und alles war erledigt. Und das funktioniert heute einfach weniger.

Andy Grunwald (00:34:36 - 00:35:11)

Du hast ein schönes Thema angesprochen, proprietäre Datenbanken, Oracle. Und ich habe mich die Tage mit einem Bekannten unterhalten, der mir erzählt hat, dass das wohl jetzt gerade ein sehr großer Teil seiner Arbeit ist, weil er ist Freelancer. Und mehr und mehr Kunden fragen an, ob er in der Lage ist, Oracle-Datenbanklogik auf eine Open-Source-Datenbank zu migrieren, Postgre-Datenbank. Hast du da in dem Bereich was gehört, ob das jetzt wirklich industrieweit ein Movement gibt, dass mehr und mehr Leute von Oracle nach Postgres migrieren oder ist das eine Momentaufnahme?

Wolfi Gassler (00:35:12 - 00:36:28)

Also ich glaube der Trend ist schon ziemlich lange eigentlich unterwegs, seitdem Postgres auch so stark geworden ist und so mächtig geworden ist oder auch MySQL. Mittlerweile früher, ich kann mich erinnern, vor vielen Jahren, wo ich MySQL verwendet habe, so in den 2000er Jahren, ich habe da so mit Leuten gesprochen, die halt so klassisch auf Oracle unterwegs waren oder andere Datenbanken, die haben immer gemeint, MySQL ist ja keine Datenbank, sondern ein Adressbuch, was eine SQL-Schnittstelle hat. Aber heutzutage ist natürlich MySQL oder Postgres super leistungsstark und kann extrem viel Use Cases abdecken und darum wird es auch immer interessanter, dass man Postgres zum Beispiel einsetzt statt Oracle und wenn man auf die Lizenzkosten schaut und jeder der Oracle mal verwendet hat, weiß wie teuer Oracle ist, vor allem probier mal Oracle auf einem virtualisierten Cluster oder so zu verwenden. da brauchst du eine große Geldtasche und darum wird einfach immer mehr Postgres verwendet oder andere Datenbanksysteme, MySQL, weil die alles abdecken können, leistungsstark sind und eigentlich der Mehrwert einfach immer weiter oder der Mehrwert immer mehr wegfällt, eine Oracle-Datenbank zu verwenden. Im Enterprise-Umfeld ist es natürlich was anderes als Bank zum Beispiel, aber ich glaube in ganz klassischen Szenarien, wer braucht noch eine Oracle-Datenbank, ganz ehrlich gesagt.

Andy Grunwald (00:36:29 - 00:36:38)

Ich meine mich zu erinnern, dass Oracle nach CPU-Cores abgerechnet wird, oder zumindest, dass das Lizenzmodell die Anzahl der CPU-Cores mit in die Berechnung einfließen lässt.

Wolfi Gassler (00:36:38 - 00:37:09)

Und meines Wissens ist es auch so, wenn du das auf einem virtualisierten Cluster betreibst, Oracle, dann zahlst du natürlich nicht die virtuellen Cores, die du der Datenbank zuordnest, sondern du zahlst nach Cores von deinem Host. Und wenn du einen fetten Virtualisierung-Cluster hast, weil da halt alles andere auch drauf läuft, dann zahlst du die Oracle-Datenbank nach den Cores, die du im Host-System drin hast. Und das ist natürlich für extrem viele Firmen ein riesen Problem, weil dann brauchst du wieder eigene Hardware zum Beispiel nur für deine Oracle-Datenbank.

Andy Grunwald (00:37:09 - 00:37:13)

Wusstest du aber eigentlich, dass Oracle jetzt auch eine Oracle Cloud hat?

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

Ja, die ist glaube ich sogar ziemlich groß.

Andy Grunwald (00:37:16 - 00:38:13)

Ich kann jetzt keine Angaben über die Größe, ich weiß nur, dass deren Free Tier ganz gut ist. Und zwar habe ich gerade mal nachgeschaut, dass du zwei AMD Compute virtuelle Maschinen kriegst, dass du sogar bis zu vier ARM Architektur Maschinen kriegst, dass du auch ein Teil Block und Object und Archive Storage im free tier hast und ich meine mich sogar erinnern zu können dass ein kollege viel größer an philip auch mal gesagt hat dass du mit dem free tier in der lage bist einen kompletten kubernetes cluster dauerhaft kostenfrei zu betreiben natürlich einen relativ kleinen kubernetes cluster aber du kannst einen betreiben wenn man bei oracle sein will Gut, Compute ist Compute, oder? Also ich meine, ich denke mal nicht, dass die VMs von Oracle jetzt Schindluder treiben oder anderen Schindluder als Amazon, Google oder Microsoft.

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

Ich hoffe nicht.

Andy Grunwald (00:38:14 - 00:38:38)

Ob du das jetzt selbst mit dir verantworten kannst, deine Software auf Oracle laufen zu lassen, das ist ja dein eigenes Problem. Also wie du zu Java, zu der Sun-Übernahme, der MySQL-Übernahme und den ganzen Open-Source-Gedanken von Oracle stehst, das kann jeder selbst entscheiden. Punkt ist aber, dass das Oracle Cloud Freetier schon recht ausgiebig ist, meines Erachtens nach.

Wolfi Gassler (00:38:38 - 00:39:54)

Muss man vielleicht auch nochmal erklären, ich glaube das wissen auch viele Leute gar nicht, dass MySQL ja mittlerweile bei Oracle ist und Oracle MySQL auch wirklich stark weiterentwickelt hat. Wer jetzt weniger mit Oracle anfangen kann, der kann ja auch auf MariaDB umsteigen, das ist ja ein Fork von MySQL, der auch sehr leistungsstark ist. Wobei immer weniger mit dem klassischen MySQL-System zu tun hat, weil die einfach auseinander driften immer weiter. Es wird auch immer schwieriger, da möglichst kompatibel zu bleiben, weil die einfach unterschiedliche Feature-Sets mittlerweile haben. Aber man muss schon sagen, Oracle hat MySQL stark vorangetrieben und was MySQL mittlerweile bieten kann mit Cluster-Varianten und mit den ganzen Features und auch SQL-Features mittlerweile, ist es auch wirklich ein sehr leistungsstarkes System, auch Feature. Was früher immer so großes Problem war, gerade wenn es um den SQL-Standard zum Beispiel gegangen ist, da war Postgres immer stärker und darum war Postgres auch eher so ein Kandidat, um Oracle abzulösen, weil einfach extrem viele Features in Postgres vorhanden sind, die in MySQL nicht vorhanden waren. Aber wie gesagt, auch das ist mittlerweile wesentlich besser, wenn es um Windows Functions zum Beispiel geht oder solche komplexeren SQL-Querys.

Andy Grunwald (00:39:54 - 00:40:17)

Ich selbst habe noch nie produktiv mit einer Oracle-Datenbank gearbeitet, aber das, was ich weiß, ist, dass ziemlich viele große Oracle-Architekturen sehr, sehr viel Logik in der Datenbank haben. Bei MySQL würde man sowas, glaube ich, Stored Procedures und Triggers nennen. Und ich glaube, das macht die Migration von Oracle-Datenbanken recht, recht tricky, oder?

Wolfi Gassler (00:40:17 - 00:41:18)

Ja, das kommt immer darauf an, was du dann noch als Datenbanksystem bezeichnest, aber du hast natürlich ganze Application Servers, die in PL, SQL oder so geschrieben sind und das ist eigentlich auch noch fast Teil der Datenbank und da hast du dann natürlich wirklich eigentlich Code in der Datenbank und das ist natürlich dann extrem schwer zu migrieren, das muss man schon sagen, ja. Aber BLSQL, keine Ahnung wie weit es noch verbreitet ist, wahrscheinlich weiter verbreitet als man so denkt, weil es wirklich stark gewachsen ist auch und mittlerweile sehr, sehr leistungsfähig ist. Also das kann man jetzt nicht vergleichen mit irgendwelchen Stored Procedures in MySQL oder in Postgres, was man damit mit so einem Application Server von Oracle in der Datenbank quasi machen kann. Da kann man ganze Formularsysteme entwickeln zum Beispiel und das ist natürlich dann schon schwierig zu migrieren. Aber das ist meiner Meinung nach auch nicht Aufgabe der Datenbank. Also da reden wir schon wirklich von einem Application Server. Das ist meiner Meinung nach nicht mehr Teil der Datenbank. Auch wenn es bei Oracle oft so angesehen wird.

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

Was ist denn das Argument für proprietäre Datenbanken, wie zum Beispiel Oracle oder MS SQL von Microsoft?

Wolfi Gassler (00:41:26 - 00:42:53)

Da fragst du den Falschen. Ich habe keine Ahnung. Da müsste man wirklich mal Enterprise Leute fragen. Ich hätte mir gedacht, früher war es immer so, ich habe eine Telefonnummer, ich kann irgendwo anrufen und dann kommt da ein Consultant eingeflogen, der irgendwie 5000 Euro am Tag verlangt. Aber mittlerweile habe ich das auch im Open-Source-Umfeld. Du hast einfach professionelle Firmen hinter MySQL, Oracle, aber auch hinter MariaDB, da steckt eine Firma dahinter. Aber auch andere Open-Source-Software ganz allgemein hat meistens Firmen dahinter, wo du einfach diese Consultant-Personen bekommst und auch, wenn es irgendwo ein Problem gibt, anrufen kannst. Percona zum Beispiel hat sich ja nur darauf spezialisiert, auf Consulting und da kannst du auch anrufen, wenn du ein Problem hast, klar, musst du dann zahlen, aber du kannst jederzeit anrufen, auch ohne Support Contract. Damit sind die eigentlich groß geworden für MySQL. Und daher sehe ich eigentlich weniger den Need für irgendwie kommerzielle große Datenbanken, muss ich ganz ehrlich sagen. Also klar, für Support muss man zahlen, für irgendwelche Wartungsverträge, aber für die Datenbank selbst sehe ich eigentlich wenig Gründe, warum man jetzt irgendwie kommerzielle Datenbanksysteme braucht. Klar hat man ein Ecosystem, was besser ist irgendwie, wenn es um das Monitoring geht und um das ganze Tooling rundherum. Das mag vielleicht besser sein als bei der einen oder anderen Open-Source-Software, aber im Allgemeinen zählt da jetzt wenig Need, da auf kommerzielle Tools zu setzen.

Andy Grunwald (00:42:54 - 00:43:29)

Firmen, die mir für offiziellen Support einfallen für MySQL, wären Oracle selbst und Percona, wie du schon genannt hast. Für Postgre fällt mir SecondQuadrant ein. Die stellen, so viel ich weiß, auch den einen oder anderen Postgre-SQL-Core-Dev und sind da sehr, sehr stark. Das ist, glaub ich, so das Percona-Pendat für ... Also, was Percona im MySQL-Wesen ist, ist SecondQuadrant im Postgre-SQL-Umfeld. Hast du grad wen im Kopf für MariaDB? Oder sagst du, jeder, der MySQL kann, Consultants kann, kann dann auch MariaDB bedienen, weil die sehr ähnlich sind?

Wolfi Gassler (00:43:29 - 00:44:05)

Es ist natürlich schon ähnlich, aber sie haben, gerade wenn man dann Consultants braucht und irgendwie schwierige Fälle zu lösen hat, da unterscheiden sie sich dann wahrscheinlich schon auch. Meines Wissens macht Bacona auch MariaDB Support, bin mir jetzt aber nicht ganz sicher. Die Firma hinter MariaDB, frage mich nicht, wie die jetzt heißt, Monty something, vielleicht keine ahnung die bieten garantiert auch consulting an und sonst gibt es wahrscheinlich auch kleinere kleinere firmen die speziell sich auf maria db fokussiert haben also dann müsste man das checken aber garantiert gibt es da gibt es da viele firmen dazu.

Andy Grunwald (00:44:05 - 00:44:13)

Wir hatten das schon mal in der vorherigen episode erwähnt aber kannst du uns noch mal ganz kurz erklären woher der name mysql und maria db kommt.

Wolfi Gassler (00:44:13 - 00:44:53)

Ja, ist ganz einfach. MySQL hat nichts mit mir zu tun, sondern My ist einfach die Tochter von Monty, dem Entwickler von MySQL. Und MariaDB ist ja ein Fork von MySQL, der dadurch entstanden ist, dass Sun, die damals MySQL aufgekauft haben, von Oracle aufgekauft wurden und Monty ein Problem mit Oracle hatte. Oder hat er schon ein Problem mit Sun? Ich glaube, es war zu Oracle-Zeiten und hat dann MariaDB geforkt oder kreiert durch einen Fork von MySQL und Maria ist einfach der Name von seiner zweiten Tochter. Der hat also seine Datenbanken einfach nach seinen Töchtern benannt.

Andy Grunwald (00:44:53 - 00:45:23)

Wer noch mehr solches Trivia-Wissen haben möchte, Wolfgang und ich haben mal ein GitHub-Repo erstellt, was wir gerne in den Shownotes verlinken. Das findet ihr auch unter github.com slash engineeringkiosk slash ussnames. Das Repository beinhaltet die Historie von diversen größeren Open-Source-Projekten und wie der Name zustande kam. Wie zum Beispiel, wie kam Laravel, das PHP-Framework, zu seinem Namen oder Hadoop oder vielleicht auch Kubernetes.

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

Und wenn ihr natürlich da was beitragen wollt, Pull-Request und gerne was hinzufügen.

Andy Grunwald (00:45:27 - 00:45:46)

Wir driften schon wieder in relationale Datenbanken ab. Wenn wir da so drüber sprechen und auch die Definition von einer Datenbank so durchgehen, habe ich mir die Frage gestellt, auch weil wir gerade über Lucene gesprochen haben, was die Basis von Elasticsearch ist. Ist Elasticsearch eigentlich eine Datenbank nach deiner klassischen Definition?

Wolfi Gassler (00:45:46 - 00:46:45)

Ja, wie gesagt, die Definition von Datenbanken ist extrem schwierig. Meiner Meinung nach Elasticsearch ist definitiv eine Datenbank. Du kannst Daten speichern, du kannst Daten ändern, du hast Indizes, sehr spezielle Indizes, Volltextsuche üblicherweise und du kannst die Daten auch wieder empfangen. Also würde ich mal eigentlich schon als Datenbanksystem sehen und ist heutzutage auch wahrscheinlich teilweise fast als Datenbank-System eingesetzt, also wirklich als System, dem ich vertraue und wo ich Daten wirklich abspeichere, ohne dass es irgendwo anders noch liegen habe. Weil der Lucene-Index ist ja klassischerweise wirklich nur ein Index. Das heißt, ich habe meine Daten irgendwo anders liegen, in einer klassischen Oracle-Datenbank, und die erstellen mir dann einen Lucene-Index nur für die Volltextsuche. Das wäre ja so eine klassische Herangehensweise gewesen. Und Elasticsearch nimmt mir das jetzt aber ab und wird wahrscheinlich in vielen Use Cases wirklich als vollwertige Datenbank, als Hauptspeicher sozusagen von meinen Daten verwendet.

Andy Grunwald (00:46:45 - 00:47:03)

Wenn ich da deiner Argumentation folge, sagst du auch, dass ein Memory Key Value Store, wie zum Beispiel Redis, wo das Wort Memory natürlich in Klammern ist, weil Redis auch auf Festplatte persistieren kann, dass sowas, ein NoSQL Key Value Store, also auch eine Datenbank ist nach deiner klassischen Definition.

Wolfi Gassler (00:47:04 - 00:47:28)

Ja, bei Redis kommt mir das immer schwer über die Lippen, aber wahrscheinlich ist es mittlerweile auch ein Datenbanksystem. Aber das ist wahrscheinlich so ähnlich wie die Leute, die früher zu mir gesagt haben, SQL ist ein Adressbuch mit SQL-Interface und keine Datenbank. Die Systeme werden leistungsstarker und auch heutzutage muss man sich fragen, okay, wenn ein System nur in Memory speichert, ohne irgendwas zu persistieren, ist es nicht dann auch eigentlich ein Datenbanksystem?

Andy Grunwald (00:47:29 - 00:47:35)

Ist das deine Kritik an Redis? Also weil du sagtest, das kommt dir schwer über die Lippen. Was ist deine Kritik an Redis selbst?

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

Ja, es ist keine Kritik, aber Redis ist für mich halt eine bessere Hashmap. Eine Hashmap mit IP-Interface.

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

Eine Remote-Hashmap sozusagen.

Wolfi Gassler (00:47:46 - 00:47:47)

Ja, genau.

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

Wobei man natürlich sagen muss, dass die letzten Entwicklungen wie Redis natürlich weit über eine klassische Hashmap-Implementation hinausgehen.

Wolfi Gassler (00:47:56 - 00:48:03)

Ja, ich kann jetzt nicht mit dir als Redis-Fanboy jetzt über so eine Definition sprechen, das ist eh klar.

Andy Grunwald (00:48:03 - 00:48:50)

Ich muss zugeben, in letzter Zeit verliere ich mehr und mehr meine Liebe für Redis, weil das System einfach so an Funktionalität gewachsen ist und dann natürlich auch eine große Komplexität mitkommt. Ich habe immer meine Liebe für Redis entdeckt, weil es gerade so einfach, so simpel, so überschaubar war, aber dennoch so viele Möglichkeiten geboten hat. Nachdem Redis Labs die ganze Sache übernommen hat und Antirest daraus ist, hab ich das Gefühl, Redis selbst, die Datenbank, wird mehr kommerziell betrieben, und es wird versucht, alles reinzuprogrammieren, was irgendein Kunde anfordert. Und ich hab so das Gefühl, dass die Einfachheit von Redis selbst so nach und nach verloren geht und die ganze Sache deutlich komplexer zu betreiben wird.

Wolfi Gassler (00:48:50 - 00:51:04)

Oder es war ja eigentlich auch immer das Versprechen von NoSQL, ganz einfach Daten zu speichern und das möglichst einfach anzubieten. Ich kann mich auch erinnern, ich war mal auf einer Datenbankkonferenz, ich glaub, es war eh auch die VLTB, also es ist eine der zwei größten Datenbankkonferenzen, war, glaub ich, damals in Singapur. Wo dieser no sql hype gerade so angefangen hat und in der akademischen welt ist er überhaupt nicht angekommen also ich kann mir erinnern da war so ein panel ich glaube stonebreaker war auch dabei mit den alten kranten und das ist irgendwie so um den no sql trend gegangen und die haben einfach alle gemeint, NoSQL ist absolut sinnlos und es ist keine Datenbank. Und die Meinung von diesen alten Kranken war so richtig, diese Kinder da draußen, die gespielt haben und jetzt NoSQL entwickelt haben, die sollen doch nicht die gleichen Fehler machen, die wir gemacht haben. Wir sind in den 70er und 80ern schon genau durch diese ganzen Schritte durchgegangen und haben das eigentlich alles schon gelernt und haben darum eben dieses ganze Transaktionsmodell ACID und so weiter entwickelt. Und wir waren doch schon mal so weit, warum kommt ihr jetzt wieder mit so Datenbanksystemen, die eigentlich nichts können? Und es war überhaupt nicht akzeptiert. Ich habe auch sehr das ganze belächelt von der anderen Seite. Ich habe mir gedacht, diese alten weißen Männer da verstehen halt keine neuen Entwicklungen. Aber ich muss schon sagen, jetzt im Nachhinein sehe ich schon auch so ein bisschen, es war schon ein gewisser Hype und ein gewisser Trend und mittlerweile sind die Systeme einfach so leistungsstark und es wurden immer wieder Sachen dazu programmiert, dass sie jetzt immer näher in diese Richtung von den klassischen relationalen Datenbanken kommen, die eben diese ganzen Features anbieten, weil man sie halt dann doch irgendwie braucht. Man will Transaktionen haben, man will in den Chasen-Feldern von MongoDB irgendwie was ändern und das vielleicht sogar gleichzeitig und Man will konsistente Daten haben und man will Recovery haben. Das heißt, am Ende ist man wieder bei so einem voll funktionsfähigen Datenbanksystem. Und das geht genau in die Richtung, was du sagst, zu Redis, dass einfach so viele Features dazukommen, dass das Ganze wieder größer wird und die klassische schlanke NoSQL-Datenbank, die so versprochen wurde, gibt es eben eh immer weniger eigentlich.

Andy Grunwald (00:51:05 - 00:52:25)

Ich sage nicht immer, dass mehr Features gleich schlecht, also dass das schlecht ist. Ich sage nur, es macht die ganze Sache deutlich komplexer zu verstehen. Da ist mehr Code in der Datenbank, der zu mehr Bugs führen kann, der gegebenenfalls unter Last oder unter spezieller Verwendung auch mal Seiteneffekte haben kann. Es gibt gegebenenfalls mehrere Arten, wie man ein Problem löst. Was natürlich auch zu enormen Diskussionen führen kann innerhalb des Teams. Wie machen wir das denn jetzt eigentlich? Das heißt aber auch, dass natürlich unter Umständen eine Datenbank für diverse Use Cases genutzt werden kann. Was dann wiederum schon wieder positiv ist, weil man nicht zwei oder drei verschiedene Datenbanktechnologien im Stack haben kann. Auf der anderen Seite, wenn wir jetzt von der Infrastruktur vom operativen Betrieb denken, umso komplexer die Datenbank, umso mehr Konfigurationssettings hat man natürlich, umso mehr Connections zu anderen Systemen, Storage oder ähnliches hat man gegebenenfalls, umso mehr Plugins muss man gegebenenfalls laden und updaten, umso einen größeren Angriffsvektor hat man etc. es hat nicht immer vorteil das hat nicht immer nachteil ich bin eher so ein fan von schlanken datenbanken von datenbanken die vielleicht eine sache. Gut machen die aber richtig gut deswegen ich war ja die entwicklung mit redis ich weiß grad nicht.

Wolfi Gassler (00:52:26 - 00:53:54)

Also du sprichst ja schon was was wichtiges eigentlich an und diesen Trend sieht man eigentlich auch, dass Datenbanksysteme modularer aufgebaut sind heutzutage. Also es gibt zum Beispiel LevelsDB, diese Open Source Grund Storage Engine von Google, die auf Bigtable basiert. die dann in ganz vielen anderen Datenbanksystemen wieder eingesetzt wird. Und jeder entwickelt irgendwas drüber. Zum Beispiel rocksdb von Facebook verwendet levelsdb und baut halt gewisse Sachen zusätzlich drüber. Und rocksdb kann dann als myrocks zum Beispiel in MySQL wieder als Storage Engine eingesetzt werden. Also es wird schon alles modularer und baut aufeinander auf. Und das hat den Vorteil, dass man sich dann wirklich eine Datenbank aussuchen kann, die halt genau dieses Problem löst und die modular vielleicht gewisse Sachen zusammensteckt und stöpselt, so damit man am Ende genau diesen Use-Case lösen kann. Und da kommen zum Beispiel dann auch so Spalten-Datenbanken, um wieder auf das ursprüngliche Kommentar, was wir vom Hörer Herbert bekommen haben, zurückzukommen. Die Spalten-Datenbanken speichern die gleichen Daten grundsätzlich ab, aber optimieren die Speicherung für Analytics. Und das ist eigentlich der große Unterschied. Das heißt, man kann, wenn man so eine Storage Engine hat, die auf Spalten basiert, dann kann man zwar normal mit den Daten arbeiten, aber im Hintergrund werden die Daten so optimiert abgespeichert, dass man eher für analytische Anfragen das Ganze optimiert hat.

Andy Grunwald (00:53:55 - 00:54:25)

Springen wir mal auf den letzten Punkt. Analytische Abfragen. Da gibt es ja in dem ganzen Database-Umfeld natürlich auch kontinuierlich neue Entwicklungen. Und einer der letzten Entwicklungen war wohl die Datenbank von Yandex, Clickhouse. Ich hatte die nicht irgendwas mit MySQL zu tun? War das nicht mal ein MySQL-Fork oder ein SQL-Fork? Oder habe ich, ich glaube ich habe das sogar falsch in Erinnerung, sondern Clickhouse war teilweise MySQL Query kompatibel.

Wolfi Gassler (00:54:26 - 00:57:43)

Ich habe das auch so im Kopf, dass es ein Drop-In Replacement sein kann für MySQL, dass es also kompatibel ist. Glaube ist aber eine Eigenentwicklung meines Wissens. Aber ist ein gutes Beispiel für spaltenorientierte Datenbank, weil auch die spaltenorientiert ist und vielleicht kurz zur Erklärung, was dieses spaltenorientiert heißt. Ganz klassisch in relationalen Datenbanken, wo man ja Tabellen hat, also das Schema ist immer eine Tabelle, so wie das halt in einer Excel-Tabelle auch ist und man speichert die Daten einfach zeilenweise ab. Das heißt, wenn wir wieder unser Telefonbuch Beispiel nehmen, Dann wird da abgespeichert Andi, dann Grunwald, dann die Adresse, dann die Telefonnummer und dann geht es weiter mit dem nächsten Datensatz Wolfgang, Gassler, Telefonnummer und so weiter. Jetzt muss man immer, wenn man die Daten durchscannt von A bis Z und einfach mal durchgeht durch die Daten, muss man immer eine gesamte Zeile scannen. Vorname, Nachname, Straße und so weiter. Wenn ich jetzt aber zum Beispiel nur an den Vornamen interessiert bin oder an den Straßen, dann muss ich trotzdem immer durch die Telefonnummer zum Beispiel gehen oder sonstige Metadaten. Das heißt, wenn ich nur eine Spalte brauche, muss ich trotzdem alle Daten lesen. Und spaltenbasierte Datenbanksysteme speichern eben das Ganze spaltenbasiert ab. Das heißt, sie speichern auf der Festplatte zum Beispiel ein langes Array mit allen Vornamen ab. Danach kommt ein langes Array mit allen Nachnamen. dann ein langes Array mit allen Straßen. Und das hat den Vorteil, dass man eben bei analytischen Szenarien meistens nur spezielle Spalten benötigt. Und da hat man unter Umständen extrem viele Spalten. Zum Beispiel von allen Kunden hat man irgendwie 200 Spalten, weil da gibt es eine Spalte mit den Umsätzen von dem Kunden, eine andere Spalte, wann der sich registriert hat, dann ein Geschlecht zum Beispiel vom Kunden, ein Alter vom Kunden und so weiter. Und wenn ich jetzt aber ausrechnen will, was ist denn mein Durchschnittsumsatz pro weiblicher Kunde, dann brauche ich eigentlich nur die Spalten Umsatz und die Spalte Geschlecht. Und das heißt, ich kann diese zwei Spalten wirklich optimiert von der Festplatte lesen und damit diese Anfrage beantworten. Und was dann noch zusätzlich dazukommt, ich habe nicht nur dieses verbesserte Zugriffsmuster, dass ich also nur zwei Spalten lesen muss auf der Festplatte, die genau hintereinander liegen, sondern ich kann auch super komprimieren. Weil wenn man sich jetzt vorstellt, man hat eine Million Kunden und hat da eine Million mal drinnen stehen weiblich, männlich, männlich, weiblich, weiblich, männlich und so weiter. Dann kann ich das super komprimieren, weil ich sagen kann, ich habe weiblich und die nächsten 100 Werte sind wieder weiblich. Das heißt, ich muss nicht 100 mal weiblich speichern, sondern ich speichere einmal weiblich und speichere mir dann dazu die nächsten 100 Einträge sind auch weiblich. Und so kann ich das super komprimieren und es braucht extrem wenig Platz auf der Festplatte und kann das beim Lesen dann natürlich auch noch mal optimiert einlesen, um die Abfrage zu beantworten, wenn alles da eben in Spalten gespeichert ist. Und darum sind spaltenorientierten Datenbanken meistens für OLAP Queries, wie es so heißt, Online Analytic Processing Queries, besser geeignet.

Andy Grunwald (00:57:43 - 00:58:30)

Um den Kontext abzuschließen, was ist Clickhouse? Clickhouse ist eine spaltenorientierte Datenbank aus dem Hause Yandex. Yandex ist ein Suchmaschinenriese primär aus Russland. Yandex hat intern Clickhouse entwickelt und dann später unter der Apache 2 Open Source Lizenz veröffentlicht. Und Clickhouse hat den Fokus, wie Wolfgang gerade besagt, auf Urlaub-Querys, auf analytische Datenreports in Real-Time. Sehr spannendes Produkt. Verlinken wir auch mal in den Shownotes. Jetzt haben wir ein bisschen über verschiedene Datenbanksysteme gesprochen. Spaltenorientierte Datenbanken, relationale Datenbanken, hierarchische Datenbanken, objektorientierte Datenbanken, Files. Und wir haben diverse Datenbanksysteme noch gar nicht besprochen. Graf-Datenbanken, dokumentenbasierte Datenbanken.

Wolfi Gassler (00:58:30 - 00:58:32)

Oder einfach nur Files.

Andy Grunwald (00:58:32 - 00:58:52)

Oder vielleicht einfach nur Files, das ist richtig. Wenn wir jetzt mal uns die besprochenen Datenbanken anschauen, Wie finden wir denn das richtige Datenbankensystem? Was für Entscheidungsgrundlagen würdest du denn zugrunde legen, um zu sagen, okay, nutze ich jetzt eine hierarchische, objektorientierte, relationale oder spaltenbasierte?

Wolfi Gassler (00:58:52 - 01:01:43)

Man kann es natürlich jetzt nicht so isoliert nur für ein paar Datenbanksysteme betrachten, weil es gibt ja noch viel mehr Datenbankmodelle und Systeme. Und da braucht man wahrscheinlich dann noch mal eine eigene Episode, wo man vielleicht in die Tiefe von unterschiedlichen Datenbanksystemen gehen und was es denn so gibt am Markt überhaupt. Aber ganz allgemein, um so eine grundlegende Entscheidung treffen zu können, muss man sich einfach mal gewisse Kriterien zurechtlegen, auf denen man so eine Entscheidung aufbaut. Ganz einfach, hierarchische Datenbanken verwendet man einfach gar nicht. Ist ganz easy. Alles andere wird dann schon schwieriger und da würde ich mir einfach mal überlegen, okay, wie groß ist denn meine Datenbank oder meine Daten? Wie groß sind meine Daten, die ich überhaupt abspeichern will? Und üblicherweise, je kleiner, desto weniger brauche ich überhaupt eine Datenbank. Vielleicht reicht eine Datei auch aus. Wie sind meine Zugriffspatterns? Habe ich mehr Read? Habe ich mehr Write? Habe ich mehrere Personen gleichzeitig? Brauche ich die Daten in unterschiedlichen Formaten später? Wie ist mein Schema? Habe ich überhaupt ein Schema oder bin ich komplett schemafrei? Habe ich einfach irgendwelche JSON-Dateien, die ich da reinschmeißen will? Wie schaut es mit dem ganzen Sicherheitsthema aus? Haben wir jetzt gar nicht besprochen. habe ich mehrere user die sich da irgendwie einloggen können sollen habe ich mehrere applikationen die aber nicht auf alle tabellen zugriff haben dürfen zum beispiel habe ich transaktionen bin ich überhaupt der bank zum beispiel die die ganz kritische anforderungen hat bezüglich sicherheit und Transaktionen, Isolation und diese ganzen Geschichten rund um ACID. ACID haben wir jetzt auch noch gar nicht behandelt, eigentlich auch sehr wichtig. Und wie groß soll das ganze skalieren am Ende? Also bin ich jetzt irgendwie Google oder bin ich eine kleine Webseite, brauche ich einen Server, brauche ich 20 Server, Also solche Dinge muss man sich einfach überlegen, damit man überhaupt dann entscheiden kann, okay, was brauche ich für ein Datenbanksystem. Und dann kann man natürlich in die Details gehen und anschauen, was ist denn am Markt so verfügbar und was löst mein Problem. Ganz allgemein gesagt, glaube ich eben, und das haben wir auch in Episode 8 schon kurz erwähnt, ganz viele Use Cases können mit Files bedient werden und sonst würde ich einfach eine ganz einfache Datenbank verwenden, wie SQLite oder MySQL, wo es viel Dokumentation gibt und die eigentlich sehr viele Use Cases abdeckt, wenn es zumindest um die klassische Softwareentwicklung geht. Wenn ich jetzt irgendwie ein Metricking-System baue, brauche ich wahrscheinlich wieder eine spezialisierte Datenbank. Aber klassisch für die meisten Use Cases reicht eine MySQL, eine SQLite oder vielleicht sogar eine Datei. Und darauf würde ich mich eigentlich konzentrieren. Und vielleicht können wir ja dann in einer anderen Episode nochmal wirklich mit konkreten Datenbanksystemen, was so verfügbar sind, dass wir alle mal beleuchten und vielleicht dann auch mit so einem Fragekatalog Entscheidungsgrundlagen dann mehr in die Tiefe gehen, wenn das für Hörer und Hörerinnen interessant wäre.

Andy Grunwald (01:01:44 - 01:02:54)

Ihr merkt schon, das ganze Thema rund um Datenbanken ist sehr, sehr groß. Lasst uns doch mal bitte Feedback zukommen und wissen, ob ihr das interessant findet und ob wir weitermachen sollen. Basierend auf dem Feedback würden wir dann gegebenenfalls die eine oder andere Datenbankfolge nochmal reinschieben und dann direkt nicht mit relationalen Datenbanken starten, sondern vielleicht mit Graf-Datenbanken, Dokument-Datenbanken oder ähnliches. Wir haben noch ziemlich viele Themen rausgelassen. Zum Beispiel einen Tiefgang in die Entscheidungsgrundlagen wie Schema, Transaktion, Isolation, Asset, Skalierung. Oder so was wie, sollte man seine Datenbank selbst programmieren? Sollte man sie selbst hosten? Oder sollte man Cloud-Anbieter nehmen? Und was haben die Cloud-Anbieter eigentlich für Vor- und Nachteile? Welche proprietären Datenbanken bietet zum Beispiel so ein Cloud-Anbieter? Nehmen wir mal Google Spanner, nehmen wir mal AWS DynamoDB. Wie sieht das eigentlich mit der Skalierung von Datenbanken aus? Skaliert jede Datenbank bis unters Dach? Oder gibt es naturelle Limits? Und Themen wie Data Streaming mit Debezium, Stichwort Change Data Capture, Cup Theorem und und und. Das Thema ist noch so groß. Lasst uns mal wissen, ob ihr darüber mehr hören wollt.

Wolfi Gassler (01:02:55 - 01:03:19)

Oder stellt uns wirklich konkrete Fragen, dann können wir die auch dementsprechend einfach abarbeiten. Also wenn ihr irgendwas wissen wollt oder auch vielleicht paar Use Cases habt, wo ihr sagt, okay, was könnten wir für Datenbank für diesen Use Case verwenden? Oder ich habe Problem XY, was wäre eine gute Lösung? Welche Datenbank? Dann können wir die auch wirklich gerne konkreter besprechen und da vielleicht auch ein paar Dinge abhandeln an konkreteren Fragen und Beispielen.

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

Und natürlich ist das Skript, das Einleitungsskript zum Thema Datenbank und für den Bereich Wirtschaftsinformatik von Wolfgang noch nicht am Ende. Ich glaube, wir haben da noch ein paar Slides offen, die wir besprechen können.

Wolfi Gassler (01:03:30 - 01:03:31)

Definitiv.

Andy Grunwald (01:03:31 - 01:03:46)

Wie immer gilt, empfehlt uns doch bitte gerne weiter, gebt uns Feedback, entweder über Twitter, at ingkios, oder via E-Mail stetisch, at engineeringkios.dev. Ansonsten hoffen wir, dass ihr wieder was mitnehmen konntet und wünschen euch einen schönen Tag.

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

Ciao.

Andy Grunwald (01:03:50 - 01:03:54)

Ich sag jetzt extra nichts mehr, weil hier kommen nämlich immer so ganz komische Outtakes.

Wolfi Gassler (01:03:54 - 01:03:58)

Ja, ich warte noch drauf. Ich wollte noch nicht den Stop-Button drücken. Genau dafür.

Andy Grunwald (01:03:58 - 01:04:00)

Drück den Stop-Button. Ich brauch noch einen Kaffee.

Wolfi Gassler (01:04:00 - 01:04:02)

Okay, aber nur weil du's bist.