Transkript: PP05 - Datenbanken

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast in der mittlerweile fünften Episode.

Heute geht es ein bisschen um Datenbanken.

Ja, wir haben wieder den schönen Wintergarten vor uns.

Ich bin der Dominik und natürlich dabei ist wie immer der Jochen.

Jo, hallo.

Genau, Datenbanken.

Ja, voll gut.

Da freue ich mich schon drauf.

Das ist irgendwie ein Thema, mit dem ich schon viel zu tun hatte.

Wird wahrscheinlich ein bisschen längere Episode.

Wir versuchen wieder ein bisschen Struktur reinzubekommen.

Wir wissen auch nicht ganz, wo das gelingt.

Wir werden wieder hemmungslos abschweifen.

Wenn ihr Fragen, Anmerkungen dazu habt, Kommentare, Lob, alles was ihr uns mitteilen wollt, schickt eine E-Mail an hallo at python-podcast.de.

Und wie immer findet ihr die Links und zusätzlichen Infosversendungen in den Shownotes.

Ja, wollen wir das eigentlich vielleicht noch erwähnen, welches Datum wir haben?

Oder heute ist der 24.2.

Oh, wir hatten jetzt Mitte.

2019.

Ja, finde ich gut.

Oder genau, wir haben das, glaube ich, schon mal gemacht.

Haben wir das schon mal gemacht?

Ich glaube, dann haben wir es irgendwie nicht mehr gemacht, aber ich glaube, das ist wahrscheinlich eigentlich ganz interessant, wenn man das hört, von wann das, wann das aufgenommen wurde.

Ja, stimmt, Ende Februar 19.

Und es ist gerade ganz gutes Wetter und es ist ein Sonntag.

Ja.

Normalerweise nehmen wir immer abends auf, heute ausnahmsweise mal nach dem Brunchen.

War übrigens super lecker.

Ja, ich würde sagen, wir steigen fast direkt ins Thema ein und es geht halt so ein bisschen darum, ja, das ist glaube ich nicht das erste Mal, dass wir versuchen, so eine Folge mit Datenbanken zu strukturieren.

Das war auch der Grund, warum ihr so ein bisschen länger auf die letzte Folge warten musstet.

Hatten wir ja kurz erwähnt.

Ja, was ist überhaupt so eine Datenbank Jochen?

Und wir versuchen halt immer wieder euch vielleicht kurz zu erklären, was man damit noch mit Python machen kann oder welche Module es dafür gibt, aber das vielleicht nochmal als Warnung.

Python kommt in dieser Folge nicht nur vor und nicht ganz so viel, sondern es geht halt tatsächlich darum, wie man das, was man mit Python macht, also die Datenbanknutzung, so ein bisschen euch erklären, näherbringen kann.

Ja, wobei, weil ich denke, dass das halt eigentlich für alle, die Python entwickeln wollen, ein interessantes Thema ist, weil da wird man, egal in welchem Bereich man sich da tummelt, nicht drum herumkommen, irgendwann etwas mit Datenbanken zu machen.

Und ja, dafür muss man sich halt dann auch nicht nur mit Python auskennen, sondern muss halt auch so ein bisschen verstehen, wie das mit den Datenbanken funktioniert.

Und man kann halt nicht viel interessante Dinge machen, wenn man halt von Datenbanken da gar nichts versteht und insofern.

Wir werden ein bisschen drauf eingehen, was ist das überhaupt, ne?

Datenbank, Unterschiede der einzelnen Datenbanktypen ein bisschen darstellen.

Und wir wollen anhand eines kleinen Beispiels euch so ein bisschen so die Problematiken beim Skalieren und bei dem Arbeiten mit der Datenbank erklären.

Genau.

Und da hatten wir uns gedacht, nehmen wir einfach irgendwie etwas, was man halt kennt.

Ich meine, wozu ist das Internet da?

Irgendwie Dinge einkaufen, klar, weiß man ja.

So ein Buchladen, habe ich gehört, können wir als Beispiel nehmen.

Genau, Amazon hat bestimmt jeder schon mal benutzt und weiß halt, wie das funktioniert.

Und das ist halt eigentlich, denke ich, ein ganz gutes Beispiel für wofür braucht man eigentlich Datenbanken, weil die haben wahrscheinlich auch für fast alle Datenbanktypen irgendwie eine Anwendung.

Und darin kann man das vielleicht ganz gut erklären.

Ja, dann vielleicht fangen wir erstmal einfach an.

Also mit was würde man einfacherweise anfangen?

Wenn man Spicen hat, möchte Daten haben, man könnte ja einfach so ein Dictionary jetzt nehmen oder sich eine Liste erstellen und da irgendwie über Indizes iterieren, dann hätte man ja sowas wie einen kleinen Datensatz schon mal.

Ja, wenn man das Ganze jetzt mit etwas komplizierteren Daten braucht.

Wir hatten eben, glaube ich, im Vorgespräch ganz kurz über Struktur gesprochen.

Da gibt es dann eine Struktur, die man sich ausdenken muss.

Das ist gar nicht so trivial, das ist recht wichtig, dass man da so ein bisschen mehr gedanklich dazu macht.

Wie sieht denn meine Struktur der Daten überhaupt aus?

Und was will ich dir damit machen?

Wie würdest du da direkt vorgehen noch?

Ja, also das ist halt, das kommt tatsächlich auf den Anwendungsfall an und was sich halt in der Praxis irgendwie in den letzten Jahrzehnten so durchgesetzt hat, sind relationale Datenbanken, aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre Berechtigungen.

Alle, die das noch nicht drauf haben, ist ja so SQL oder NoSQL.

Ja.

Benannt oft, ja.

Genau, und ja, es hängt halt davon ab.

Also man kann natürlich auch einfach Objekte, Python-Objekte nehmen, die irgendwie serialisieren, nennt man das.

Also zum Beispiel gibt es da in der Standardbibliothek das Pickel-Modul für, was halt aus einem Python-Objekt das irgendwie beliebig aussehen kann, macht das halt eine String- oder Byte-Repräsentation.

Also eine Serialisierung ist tatsächlich irgendwie die Darstellung als Zeichenkette oder Byte-Strecke, damit man die übertragen kann über einen Kanal oder sowas.

Ja, genau, das nennt man Serialisierung, ist auch im Kontext von Datenbanken eine sehr wichtige Geschichte.

Und man könnte jetzt zum Beispiel diese Bytefolgen oder Strings nehmen und die halt zeilenweise in einen Pfeil reinschreiben und dann hinterher auch wieder auslesen.

Also man nimmt einfach zum Beispiel, wenn man jetzt den State von irgendeinem Programm speichern möchte, nimmt man einfach alle Objekte, die man jetzt so findet oder die man sich irgendwo gemerkt hat, dass man sie hat und serialisiert die halt in Zeilen und schreibt das Ganze in ein Pfeil.

Genau so habe ich das auch bei meiner ersten versuchten Datenbankoperation selber gemacht, nämlich einfach so die Daten, die ich hatte, es ging da um so Spielerdaten aus dem Sport, habe ich einfach alle Informationen über einen Spieler in eine Teile gepackt und die teilenweise in eine Datei reingeschrieben.

Genau, und dann, wenn man jetzt den Status wiederherstellen will des Programms, wenn man das startet, dann nimmt das einfach die Datei, liest alles wieder ein und dann ist es im gleichen Zustand wie vorher.

Und genau, wenn man das mit Python-Objekten macht, dann ist es halt nicht mehr menschenlesbar, aber man kann das halt genauso machen, indem man halt ein CSV schreibt oder sowas halt, dann wäre es halt noch menschenlesbar.

Da muss man sich halt überlegen, wie man die CSV-Zeilen in Objekte verwandelt und Objekte wieder in CSV zeigt.

Ich habe einfach den Dictionary-Code in eine Teile reingeschrieben, habe das dann ausgelesen und evaluiert.

Es war wahrscheinlich nicht die beste Methode, das zu tun, aber funktioniert hat es trotzdem.

Genau, und wenn man sowas macht, das wurde am Anfang irgendwie bei Webentwicklung auch häufig gemacht.

Das nannte sich dann Flat-Files, Datenbank mit Flat-Files.

Man hat nimmt einfach Files und schreibt den State da irgendwie rein.

Und natürlich ist auch das Filesystem ja schon irgendwie eine Art Datenbank.

Das ist halt eine hierarchische Datenbank, die halt so eine Baumstruktur hat.

Und ja, deren Blätter halt Files sind.

Wurzel ist halt Root slash bei Unix-Systemen oder weiß nicht, bei Windows ist es irgendwie was komisches mit dem Laufwerksbuchstaben.

Und ja, das ist natürlich auch eine Struktur.

Man hat halt irgendwie darüber die Verzeichnisse, die es da gibt, auch schon so Metadaten definiert, dass man halt weiß, wo bestimmte Sachen sind halt in einem bestimmten Verzeichnis und so.

Und das Ganze gibt es halt auch über Netzwerkgeschichten.

Die bekanntest hierarchische Datenbank im Netz ist halt sowas wie LDAP.

Windows nennt das irgendwie Active Directory oder ist auch vielleicht noch ein bisschen komplizierter.

Und ja, das ist halt auch schon mal eine grundsätzliche Art, wie man Datenbanken betreiben kann.

Aber vielleicht, was ich mich ganz gerne auch nochmal ansetzen würde, ist, wie Leute, also wenn man jetzt sich überlegt, wo könnten Leute etwas, das man sonst vielleicht mit Datenbanken tun könnte, irgendwie schon mal gesehen haben oder was machen viele Leute, was halt eigentlich auch gut in den Datenbankkontext passt, dann würde ich vielleicht sogar eher mit sowas wie Excel oder so anfangen.

Weil das wird dann oft so scherzhaft auch erwähnt.

Wenn man sich überlegt, was ist die meisten verwendete, am meisten ausgerollte Datenbanklösung der Welt, könnte man auch sagen, das ist halt Excel, weil viele Leute halt Excel quasi als Datenbank benutzen.

Allen möglichen Quatschen, irgendwelche Spalten und Teilen reinschreiben und ganz, ganz Ganzen.

Und das ist genau, das ist halt eigentlich, ach so, und vielleicht sollte man sich erstmal grundsätzlich überlegen, stimmt, wenn man schon so anfängt zu erklären, was Datenbanken sind, was sind eigentlich Daten, was sind eigentlich Informationen, was sind eigentlich Wissen, dafür hat man umgangssprachliche Definitionen, die halt, wo man dann weiß, was das ungefähr sein soll, aber wenn man das jetzt aus dem Datenbankkontext sehr präzisieren möchte, dann geht das eigentlich auch relativ schmerzlos.

Also Daten sind halt sowas wie, also ein Datum wäre irgendwas mit minus 3,5, wäre jetzt ein Datum.

Einfach nur ein Zahlenwert oder so.

Und das sagt einem halt natürlich noch nichts.

Weil es halt kein Bezug dafür, minus 3,5, was denn?

Grad Fahrenheit.

Und ja, wenn man, wenn man jetzt von Informationen spricht, dann spricht man von Daten, die halt schon so ein bisschen Kontext haben.

Also sowas wie minus 3,5 Grad, dann eine Temperatur.

Das heißt, man weiß halt, das steht jetzt in der Temperaturspalte.

Und damit weiß man schon mal so ein bisschen, worum es da überhaupt geht und dann nimmt man das Informationen.

Und das, was man aber eigentlich in Datenbanken speichern möchte und dann was machen möchte, das ist irgendwie so Wissen.

Begriff dafür ist Wissen und das wäre dann halt, wenn man jetzt eine ganze Reihe von Temperatursensoren hätte, die halt nicht nur die Temperatur über die Zeit irgendwie aufgenommen haben, sondern halt auch noch deren Position hat.

Und das halt in einer Struktur, die halt bestimmte Anfragen leichter macht, halt gespeichert hätte, dann kann man damit möglicherweise das Wetter vorhersagen oder sowas.

Das heißt, man halt halt Wissen über wie das Wetter ja gerade ist oder wie es war.

Oder man weiß zum Beispiel, dass es im Winter kälter wird als im Sommer.

Ja, genau.

Und dann kann man halt, wenn man Abfragen daran stellt, dann halt Schlussfolgerungen daraus ziehen und dann vielleicht Dinge vorhersagen oder halt auch einfach bestimmte Fragen beantwortet bekommen, die einen interessieren.

Also alle Städte, in denen es letztes Jahr kälter war als so und so oder irgendwie sowas.

Genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.

Da kann man auch Analysen irgendwann machen.

Das ist aber dann, glaube ich, wieder ein neues Thema, wie man Analysen dann mit Daten fährt.

Wenn wir heute, glaube ich, nicht machen, aber was wir machen wollen.

Doch, alles heute.

Doch, doch, alles.

Okay, ihr müsst heute lange, lange Geduld mitbringen.

Oder eine große Runde durch den Park oder ihr könnt ganze Wohnung putzen heute.

Ja, ich bin gespannt, wie schnell wir da durchkommen.

Aber ja, also ich denke, das ist eigentlich vielleicht ganz interessant, mal so einen Rubenüberblick.

Also ich versuche dann zu verhindern, zu sehr ins Detail zu gehen, aber wenn man einfach mal so das Gesamtthema Datenbanken mal überblickt hat, dass.

Ja, hatte ich so umkehren, davon ab, so ins Detail zu gehen, weil ich finde das unheimlich interessant, was da alles noch so drinter steckt.

Ich bin da sehr curious, was man auch alles so findet.

Und die Details sind halt auch irgendwie wichtig, ja.

Ja, ja, stimmt.

Wir schauen einfach mal.

Ich hoffe mal, dass es nicht allzu lang wird, aber.

Okay, ja, dann.

Fangen wir doch direkt mit dem Beispiel an oder wolltest du noch so ein paar grundsätzliche Daten?

Einmal grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken, auch um halt dann um darauf dann wieder Bezug nehmen zu können in dem Beispiel.

Und vielleicht auch das, was halt sich jetzt durchgesetzt hat.

Jedenfalls, das ist halt eben hierarchische Datenbanken gibt es schon ganz lange und ja, Sachen in Flat Files oder irgendwie strukturierten Dateien hat man auch schon lange.

Und dann irgendwann 1971, glaube ich, ist ein Paper rausgekommen von Ted Cott und der hat sich halt Gedanken darüber gemacht, wie man eigentlich dieses Problem, ich möchte wissen, irgendwie speichern und dann irgendwelche Dinge damit später machen, wie man das so grundsätzlich eingehen sollte.

Und dessen Idee war halt, also ein Problem, was er gesehen hat mit den bisherigen Ansätzen war, dass viele Leute Zeit damit verbracht haben, die Daten, die sie halt schon auch irgendwie strukturiert, aber halt im eigenen Format in Dateien gespeichert haben, da Algorithmen für zu schreiben, wie die jetzt abzufragen sind.

Also wenn man jetzt eben so eine Frage beantwortet haben möchte, wie, keine Ahnung, wie viel, was war denn jetzt die Stadt, in der es letztes Jahr am kaltesten war in Deutschland oder so.

Dann fingen Leute an, dann in Algorithmen zu schreiben, die für die Art, wie sie die Daten gespeichert hatten, halt das Problem gelöst haben.

Und jeder, der halt die Daten irgendwie anders speichern, muss sich halt einen neuen Algorithmus überlegen, wie er das macht.

Und dann war es ja eigentlich ziemlich blöde.

Also es wäre irgendwie schlauer, wenn man das standardisieren könnte und also nicht sich überlegt, welchen Algorithmus oder einen Algorithmus zu schreiben, der halt das irgendwie abfragt, sondern zu beschreiben, was man haben möchte und dann irgendeine Art von Datenbank-Managementsystem, das dann halt weiß, wie man irgendwie diverse Arten von Indizes baut oder so, dem dieses formalisierte Anfrage vorzulegen und das Ding sucht sich dann die beste Art, wie man das dann löst, raus und

macht das dann vor allem.

Und damit das alles gut geht, muss man halt die Daten auch in einem bestimmten Format speichern und man sollte die halt in Form von Relationen speichern.

Das heißt im Grunde mehr oder weniger wie in Tabellen.

Man kennt das halt aus Excel, wobei viele Excel-Tabellen halt nicht die Anforderungen erfüllen, die man eigentlich sozusagen dann dran stellen würde.

Weil in unterschiedlichen Spalten oder Zeilen irgendwie unterschiedliche Dinge drinstehen, die da nicht zu suchen haben oder.

Ja, weil sie halt nicht normalisiert sind, weil es nicht so wirkliche

Oh, jetzt kommen wir direkt wenig Normalisierungen, ja.

Weil es nicht wirkliche Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es das halt alles schon und da werden dann auch bestimmte Regeln und Constraints irgendwie überprüft und so.

Tabellen sie auf Tabellen zeigen oder sowas.

Genau, genau.

Ja, und das wird in Excel halt alles nicht gemacht und dann ja, das ist halt, das ist in der Praxis ein relativ großes Problem, denke ich.

Das halt, ich hab das, auf den kommen wir später noch zurück, vielleicht.

Der heißt Simon Willison, der hat für einen Guardian irgendwie vor zehn Jahren ungefähr irgendwie so einen Bereich Datenjournalismus irgendwie da, gab es das schon so, heute ist es ein großes Thema, aber damals hat das irgendwie keinen so richtig interessiert gearbeitet.

Und der ist halt eher so, hat was mit Datenbanken da zu tun.

Und da gab es schon jemanden, der sich damit beschäftigt hat, also von der Zeitung her, wenn es einen Artikel über irgendein Thema Arbeitslosigkeit oder keine Ahnung, irgendwas wirtschaftliche Themen irgendwie ging, wenn man da Schaubilder und Diagramme reinmachen wollte, wo kommen denn die Daten dafür eigentlich her?

Und er kannte irgendwie in allen Institutionen Leute, die ja nach diesen Daten fragen konnte, wusste, wo man die bekommt und so, super.

Aber das Problem ist jetzt, also der, also Simon Willison, also der aus der Programmiererecke, wollte halt die Daten auch anders noch zugänglich machen und wollte halt gucken, ob man da nicht übergreifend irgendwelche Anfragen stellen kann und fragte den dann so, wo denn die Daten wären oder wie er die denn speichern würde.

Und der sagte so, oh ja, ich habe da hier irgendwie ein paar tausend Excel-Files auf meinem Desktop und da sind die halt drin.

Und ich weiß halt, welches in welchen Daten in welchen Fall sind.

Da kannst du mal Blätthanken.

Und ich glaube, das ist tatsächlich eine Situation, die in vielen Unternehmen so ist oder so.

Dass man halt dann Experten hat dafür, für diese Domain.

Die Menschen aus dem Archiv.

Ja, die aber nicht unbedingt jetzt so Datenbankspezialisten sind und die machen dann halt Excel-Files und tun das irgendwo hin.

Aber das funktioniert halt nicht gut, weil man hat halt, man kann darüber jetzt keine übergreifenden Anfragen stellen, dann hat man auch so ein Problem, wenn man mit Leuten zusammenarbeitet.

Ja, wie ist das eigentlich, wenn mehrere Leute das jetzt ändern?

Dann gibt es auch wieder so komische Strategien wie, naja, man hat das dann irgendwie auf einem Netzwerkshare und dann muss man sich irgendwie Bescheid sagen, wenn man das ändert oder man macht das irgendwie über komisch benannte Dateinamen oder sowas.

Das ist natürlich alles total furchtbar.

Also man benutzt dann im Grunde zwei Datenbanken, die nicht wirklich dafür geeignet sind, was man da machen möchte, nämlich einmal das Fall-System, um halt so eine Art Versionskontrolle zu machen.

Und dann Excel als Datenbank, was halt auch nicht dafür geeignet ist, und dann macht man sich das Leben sehr, sehr schwer.

Obwohl es deutlich einfacher sein könnte.

Und ja, das sind also aus meiner Perspektive auch so die beiden Dinge, wo man.

So leichte Gewinne, die man machen könnte.

Also die beiden Themen, die halt vollkommen unterschätzt sind, aus meiner Perspektive sind einmal Versionskontrolle.

Also das sehe ich ganz oft, dass halt jetzt, also bei Programmierern, die wissen inzwischen, wie das funktioniert und machen das halt auch.

Und bei denen ist halt Verständnis, was jetzt Git ist und wie man das verwendet, irgendwie durchaus angekommen.

Einmal bitte den Git Flow, ja.

Aber in den meisten anderen Abteilungen, die jetzt nicht, wo es nicht um Programmieren geht, die haben von solchen Dingen noch nie irgendwas gehört.

Da nimmt man Tippex und malt halt kurz die Buchstaben, die falsch sind raus und zahlt dann darüber.

Wenn man wissen ja, was da vorher stand, dann muss man das Tipac abkropfen.

Ja, die wissen halt vielleicht, wie sie ihre Programme bedienen oder so, aber die wissen gar nicht, dass sowas geht und wissen gar nicht, wie das geht und machen dann sehr umständlich das, was ihnen arbeitet, sehr fehleranfällig, die ihnen gibt oder so.

Tabelle 1, Tabelle 1 neu, Tabelle 1 neu neu, neu final und ja, jetzt nicht wirklich und allerneueste Version.

Also da könnte man mit wenig Aufwand viel erreichen.

Und eben auch da, wenn man Daten speichert und halt auch, man hat ja in Excel dann oft nicht nur Daten, sondern man hat dann Daten und Logik, weil man jetzt irgendwelche Reports erzeugt für irgendwie ein Management-Layer oder so.

Und dann ist das viel Handarbeit, wo im Grunde man, wenn man jetzt ein bisschen.

Habt ihr gerade gehört, das war gerade ein super kurzer kleiner Nebensatz, wenn man kurz irgendwelche Daten erzeugt, so für den Management-Layer sehr schön.

Ja, das ist, denke ich, ein Grund, warum viele Leute da so Excel mit irgendwelchen Makros drin oder irgendwelchen Skriptschnipseln drin haben, warum sie das verwenden.

Das Problem ist halt, das funktioniert meistens und dann funktioniert es irgendwann nicht mehr oder die Daten ändern sich.

Und dann muss man halt irgendwie einen Teil von einem VBA-Skript oder so irgendwie so ein bisschen anpassen.

Dann geht was an einer anderen Stelle kaputt.

Und dann ist es auch so, dass man oft Sachen von Hand gefixt hat.

Also irgendwelche Werte sind halt nicht so, wie sie sein sollen.

Und bei Excel klickt man dann da rein und dann ändert man den Wert halt.

Und dann weiß man aber nicht, dass man das gemacht hat.

Dann kommen jetzt neue Daten rein, die sind wieder falsch und dann muss man es wieder ändern oder es geht halt kaputt oder so.

Und das ist einfach so aus einer Programmierersicht nicht so das, was man tun sollte.

Okay, man halt damit Stunden um Stunden, um Stunden,

um Stunden.

Genau, aus Programmierersicht, das ist so, wenn ich da irgendwie was ändere, dann ist das halt irgendwie Programmlogik und wenn dann neue Daten reinkommen, dann wird die halt genauso angewendet und dann muss ich das halt nur einmal hinschreiben und dann ist es sozusagen für immer irgendwie gelöst.

Und ja, es gibt auch ganz in VBA ist natürlich noch so ein extra Problem.

Das soll übrigens bald mit Python gehen, habe ich gehört.

Ja, ich weiß, dass bei Microsoft gibt es irgendwie so ein, die haben da auch so ein Priorisierungstool sozusagen, ich weiß nicht genau, was das ist.

Und ich glaube, das meiste nach Requested Feature ist es, VBA durch Python zu ersetzen.

Mit irgendwie tausenden Upvotes.

Aber ich glaube definitiv dazu geäußert, ob das irgendwie dann kommt, hat sich da auch noch niemand.

Aber das wäre natürlich auch eine interessante Geschichte.

Aber man hat auch bei Python dann immer noch das Problem, was ist, was man halt wahrscheinlich nicht machen können wird, ist sowas wie mit Pip irgendwie Dinge nachinstallieren oder so, selbst wenn es wenn Python jetzt die VBA ersetzen würde.

Gut, man hätte schon einen Vorteil dadurch, dass die Standardbibliothek von Python sehr viel mächtiger ist, als das, was es VBA kann, aber es ist halt immer noch nicht, also es gibt diverse Probleme, die noch gelöst werden müssten, damit das Ganze nicht smooth ist.

Und das Grundproblem ist natürlich, dass Excel das vollkommen ungeeignete Tool ist für vieles, was da in dem Bereich gemacht wird.

Ja, aber genau.

Also, also genau, also eigentlich wäre das, was viele Leute damit machen, die werden viel besser bedient, wenn sie halt Python nehmen würden und eine relationale Datenbank.

Und weil die eben diese ganzen Geschichten auch löst.

Da gibt es dann halt, wenn man mehrere Leute drauf zugreifen und Dinge ändern, dann sorgt das auch die Datenbank dafür, oder das Datenbankmanagementsystem, dass da nichts schief geht, dass alle Leute immer die gleichen Daten sehen, jedenfalls innerhalb von einer Transaktion und so.

Und da gibt es auch die ganze Zugriffskontrolle und all das ist alles, alles schon fertig implementiert.

Und ja, das ist halt so das, was Leute im Grunde verstehen, wenn man von Datenbanken spricht, denke ich.

Aber es gibt halt auch noch eine ganze Menge anderer Datenbanken und dass sich relationale Datenbanken so durchgesetzt haben, ist auch aus meiner Perspektive ein Stück weit Glück oder hängt halt an der Geschichte von einzelnen Firmen.

Also man hätte sich auch durchaus vorstellen können, dass sie andere Paradigmen durchgesetzt hätten, haben sie aber irgendwie nicht.

Und jetzt sind halt so relationale Datenbanken das, was alle irgendwie verwenden.

Aber es ist auch gar nicht so ein schlechter Ansatz.

Insofern kann man damit eigentlich ganz gut leben.

Aber nur mal so um.

Der Vollständigkeit halber, ja.

Der Vollständigkeit halber, um mal zu sagen, was es sonst noch alles so gibt.

Es gibt halt Dokumentendatenbanken, ja, gibt es auch schon ganz lange.

Lotus Notes ist ja so ein Beispiel für früher Microsoft auch ganz populär.

CouchDB, MongoDB, die fallen auch in diesen Dokumentdatenbankbereich rein, lösen halt so ein bisschen unterschiedliche Probleme.

CouchDB löst so ein bisschen das Problem, dass ich nicht unbedingt nicht in einen zentralen Master immer reinschreiben will, weil der halt auch weg sein kann.

Wenn ich zum Beispiel offline bin oder so, dann kann ich halt nicht da reinschreiben, sondern muss dann halt eventuell erst lokal schreiben und dann irgendwie die Daten synchronisieren hinterher.

Und das macht CouchDB sehr schlau.

Verwendet tatsächlich auch einen Algorithmus, der aus dem Lotus-Notes-Dings-Projekt kommt.

Es gibt Key-Value-Stores, wo man einfach nur irgendeinen Hash irgendwie, also man kann sich das vorstellen wie ein Python dickt, wo man halt irgendwelche Keys hat und dann hat man irgendwelche Werte, die man dann zurückbekommt, wenn man den Key da hinschickt.

Darunter fallen so Sachen wie Redis oder Memcache, die oder so oft zum Cachen verwendet, aber manchmal können sie auch kompliziertere Sachen oder weiter strukturierte Daten.

BerkeleyDB war lange ganz groß, wird heute gar nicht mehr so sehr verwendet.

Ja, aber auch sowas wie Amazon Dynamo oder so fällt da auch drunter.

Und dann gibt es halt noch so Spaltenorientierte Datenbanken, wobei ich auch da sagen würde, es gibt zwei unterschiedliche Arten, aber halt sowas wie Big Table, wo Google einen Index drin speichert oder das entsprechende Hadoop-Äquivalent oder das Äquivalent aus dem Hadoop-Ökosystem Edgebase.

Die Dinger sind halt dafür gedacht, gigantische Datenmengen irgendwie zu speichern und das halt machen sie dann irgendwie eher so spaltenbasiert.

Cassandra, Apache Cassandra ist auch so ein Projekt, das es genauso macht.

Dann ein komplett anderes Paradigma sind Graphendatenbanken, wo man Daten eben nicht in Tabellen speichert, sondern man speichert eher Knoten und Kanten.

Und die Relationen zwischen den Daten sind halt nicht dadurch dargestellt, dass man jetzt halt irgendwie Zeilen in einer Tabelle hat, sondern dadurch, dass man halt beliebige Beziehungen im Grunde zwischen Knoten irgendwie hat, ist jetzt ein bisschen abstrakt, weiß ich auch gar nicht genau, wie ich das erklären kann.

Vielleicht kann ich das, kann man das nachher nochmal im praktischen Beispiel ein bisschen besser erlauben.

Genau, aber das ist halt so eine ganz andere Art von Datenbanken, die aber auch, also da würde ich sagen, das hätte auch sich anstelle von relationalen Datenbanken durchsetzen können.

Und genau, auch das, was mit dem Semantic Web, vielleicht haben manche Leute davon schon gehört, so RDF, Tupelstores, das ist auch alles im Grunde Graphendatenbanken.

Okay, Semantic Web, ja, machen wir später.

Und dann gibt es natürlich noch so wirklich anwendungsspezifische Datenbanken, sowas wie Volltext-Suchmaschinen, also Volltext-Indizes oder für Zeitreihen gibt es auch spezialisierte Geschichten Influx-DB oder Timescale-DB.

Oder halt sowieso für, du hast halt ein bestimmtes Problem wie, du möchtest dieses, bei Google sieht man halt, Google Suggest hieß das Feature.

Wenn man Google Query eingibt, dann werden einem so Vorschläge gemacht.

Dafür braucht man halt eine spezielle Art, das zu inizieren, Suffix-Freeze.

Und das kann ja, ja, dafür gibt es dann auch wieder spezielle Server, mit denen man das machen kann und so.

Und das wäre jetzt etwas, was man sonst halt nicht so braucht.

Es gibt halt für bestimmte Anwendungsfälle gibt es sowas halt, aber ja, ist jetzt manchmal sind solche Funktionen auch in verbreiteren Datenbanken enthalten, aber es gibt halt auch mal spezialisierte Geschichten dafür.

Ja.

Vielleicht die ganzen Basissachen werden noch komplett nicht kurz erwähnt.

Ah, okay.

So, keine Ahnung, MySQL oder Postgres.

Achso, das sind, ja genau, das sind Beispiele für relationale Datenbanken, ja, MySQL, Postgres, das wären jetzt die Open Source Vertreter, Oracle und MSSQL-Server, Cybase, das werden so die kommerziellen Geschichten, DB2 von IBM, ja.

Oder zur Historie, im Grunde die, nachdem dieses Paper irgendwie, das übrigens sollte man die Show Nutzes packen, das ist sehr empfehlenswert, das sich mal zu lesen von Hedcott.

Der hat damals bei IBM gearbeitet.

Und da ist ein System daraus entstanden, das nennt sich System R.

Das haben irgendwie so ein paar Leute bei IBM geschrieben.

Und daraus ist halt die W2 auch von IBM entstanden, irgendwann, aber halt Oracle bezieht sich auch darauf, glaube ich.

Ich weiß jetzt aber nicht, wie die Verbindung zu Oracle ist.

Und dann gab es halt auch Leute in Berkeley, die versucht haben, das zu implementieren, das Paper, und dabei ist was rausgekommen namens Ingress.

Michael Stonebreaker war das damals und das war am Anfang noch gar keine Datenbank für beliebige Daten, sondern es war für Bilder irgendwie.

Und dann ist das Ganze zu Postgres geworden und wurde dann zu einer normalen, relationalen Datenbank sozusagen sozusagen.

Und also das ist auch faszinierend.

Also dieses ganze Postgres-Projekt ist der Wahnsinn eigentlich.

Das hat halt irgendwie im Mitte der 80er ist das gestartet.

Oder halt, wenn man Ingress dazu zählt, noch früher.

Und ist jetzt über 30 Jahre wahrscheinlich auch einen Buckel und ist immer noch top.

State of the art immer noch dabei.

Es kommen immer noch tolle Sachen dazu.

Ist wahrscheinlich auch so die, sie nennen sich selber irgendwie die, ich weiß gar nicht, wie ich das übersetzen soll, advanteste, die fortschrittlichste Open Source-Datenbank, ja.

Gut, Oracle und so hat wahrscheinlich noch ein bisschen mehr Funktionen, aber ja, tatsächlich wird meistens aber wahrscheinlich aus Kostengründen, tatsächlich jetzt so im Internetumfeld irgendwie dann meistens werden so Open Source-Datenbanken verwendet.

Ja, ich habe schon mal gesehen, dass Leute Oracle verwenden, aber das ist eher selten.

Jetzt so als Backend für Webseiten verwendet man normales.

Nicht Oracle, das ist halt auch einfach viel zu teuer.

Oder MSSQL-Server, doch, das gibt es tatsächlich Leute, die das als Backend für Webseiten verwenden.

Ein Beispiel einer populären Seite, die halt auf MSSQL-Server läuft, ist Stack Overflow.

Das ist auch faszinierend.

Ich meine, einer der war, ich weiß nicht, ob es der Gründer selber war, der war auch Produktmanager bei Microsoft, glaube ich, insofern.

Also die machen viel auf dem Microsoft Stack und holen da unglaubliche Sachen raus.

Also die haben irgendwie ein halbes Rack oder, also ich das letzte Mal, gut, das ist auch schon lange her, dass ich da irgendwie Artikel zu gelesen habe, aber dass ich das letzte Mal das gesehen habe, war Stack Overflow tatsächlich unter den Top Ten der trafficstarksten Webseiten weltweit und die haben dafür Hardware, war irgendwie so ein halbes Rack oder so.

Und das ist natürlich schon extrem beeindruckend.

Und das ist überhaupt sowas, was halt wahrscheinlich viele Leute nicht wissen, die jetzt nicht so viel Erfahrung haben mit Datenbanken, die können echt wahnsinnig viele Dinge tun gleichzeitig und so.

Also man kriegt aus so einer ordentlich konfigurierten und getunten relationalen Datenbank schon so ein paar, mindestens ein paar tausend, vielleicht auch ein paar 10.000 Requests oder Statements pro Sekunde raus, die die halt verarbeiten können.

Und dann kann man natürlich eine Menge machen.

Also ja, also Vorausgesetzt ist ganz krampfst den Hauptspeicher.

Man macht keine Dinge, die das irgendwie langsam machen.

Also es ist halt dann auch nicht so einfach, das zu optimieren, aber ja, genau.

Und das ist halt auch der, dieser Bereich der relationalen Datenbank ist halt also der größte Datenbankbereich eigentlich.

Ja, vielleicht kommen wir dann, wollen wir zu dem praktischen Beispiel.

Genau, super, wie macht man das jetzt alles und wie baut man das auf und warum und was kann man damit so Schönes machen und was für Probleme könnten wir darüber stolpern und sowas?

Ja, dann spannend sein.

Nehmen wir doch mal an, wir wollen jetzt Amazon nachbauen.

Wir haben einen kleinen Buchhandel in der Garage.

Wir überlegen jetzt uns jetzt so, ah

liegen jetzt ganz viele Bücher auf dem Boden und dann will irgendjemand bestellen, dann muss dann irgendjemand in die Gerate laufen, gucken, wie ist denn jetzt der Titel, habe ich den?

Dann liegt der ein Buch unterm anderen, das wäre natürlich doof, wenn man erstmal lange suchen muss.

Deswegen haben wir jetzt überlegt, ja, pass auf, wir schreiben das Ganze jetzt in eine Datenbank.

Wie fangen wir jetzt mal an?

Vielleicht reden wir kurz über das Schema, wie man sowas aufbaut, nochmal kurz.

Genau.

Also man würde jetzt zum Beispiel eben die Metainformationen über diese Bücher, also sowas wie Titel, ISBN-Preis und so würde man halt in eine Datenbank schreiben.

Durchschnittliche Anzahl von Buchstaben pro Seite.

Vielleicht, ja, was auch immer man da.

Man würde das halt in eine Tabelle schreiben.

Aber man würde jetzt möglicherweise schon nicht den Autor, ne?

Denn wenn man jetzt den Autor, also den Namen des Autors mit in diese Tabelle reinschreibt, dann hat man unter Umständen ein Problem, nämlich wenn jetzt halt.

Der Autor sich umgenennt, weil er heiratet

oder so?

Ja, genau.

Heiratet oder sonst irgendwie seinen Namen ändert, dann müsste man ja, dann kann man natürlich irgendwie alle Zeilen, in denen der Name drinsteht, die ändern.

Aber man kann ja auch Pech haben und wenn das jemand von Hand macht, dann ändert er halt das nur, weil er davon gehört hat, dass es jetzt für dieses Buch geändert werden soll, das nur in einer Zeile und lässt die anderen halt weg und dann hat man halt.

Wir könnten Suche und Ersätze machen und dann machen wir sowas, da machen wir für jedes Jahr, das wir Bestellung habe oder jeden Monat eine neue Datenbank, eine neue Tabelle.

Und dann müssten wir einmal nach drei Jahren oder sowas 36 verschiedene Dateien öffnen, immer Suche und Ersätze ausführen und dann den Namen ändern.

Ja, super, oder nicht?

Ich könnte sein, dass das nah dran ist an dem, was viele Leute tatsächlich machen, aber das kann man auch eleganter tun in der Datenbank.

Und dann hätte man möglicherweise nur einen sogenannten Fremdschlüssel in der Spalte Autor, in der Büchertabelle.

Und dann würde man den Namen des Autors halt von der Autortabelle ändern und dann wäre das automatisch in allen Zeilen, allen Büchern oder allen Zeilen der Büchertabelle, in denen das referenziert wird, würde das automatisch geändert werden.

Und dann brauchen wir ja noch eine andere Tabelle, Autorix, wo dann alle Autorinnen drin stehen.

Ja, wäre auch eine Möglichkeit, genau.

Und ich überlege gerade, das ist jetzt natürlich, also Autoren ein Beispiel, anderes Beispiel wäre User, die jetzt auf der Webseite irgendwas einkaufen wollen oder so.

Da gibt es, da würde man in der Bestellung halt auch nicht den User selber irgendwie in jede Bestellung schreiben, sondern halt irgendwie die ID von dem User, der irgendwas eingekauft hat.

Und im Grunde, also ja, das heißt Datenbanknormalisierung, wenn man jetzt dafür sorgt, erinnert so ein bisschen an, wenn man Software schreibt, nennt sich das Dry.

So Don't repeat yourself.

Also wenn man Software schreibt, sollte man auch Funktionalität, die man an mehreren Stellen verwendet, halt nicht an mehreren Stellen implementiert haben, weil wenn man das an einer Stelle ändert und jetzt ist halt an einer anderen, dann hat man halt ja einmal ist es dann inkonsistent, das halt.

Und ja, man hat halt auch die Gefahr, dass man Dinge, die man einmal gefixt hat, halt dann nochmal auftauchen.

Das ist halt bestimmt schon ein Tumor passiert, oder?

Also mir hat es früher ständig passiert und dann ist mir irgendwann aufgefallen, oh, ich mache eine Funktion und dann.

Dann macht man die Funktion und dann machen einen Test und dann ist es halt erledigt sozusagen.

Also sollte man halt möglichst versuchen, Dinge, die man, also Logik, die irgendwo ist, halt immer nur einmal irgendwo stehen zu haben.

Ist natürlich manchmal nicht so ganz einfach.

Und das ist bei Datenbanken halt auch nicht, weil das beißt sich so ein bisschen mit einer anderen Anforderungen, die man hat, wenn es halt schnell sein soll, dann ist das manchmal etwas schwierig, weil relationale Datenbanken, dann, wenn man halt viele Tabellen miteinander verknüpft, man dann das halt joinen.

Das heißt, man kann halt anhand von diesen Verzweigungs-, also Fremdschlüsseldings, kann man halt Tabellen aneinander ketten.

Ja, verketten.

Man kann sich das vorstellen, man legt die halt sozusagen nebeneinander.

Und sodass halt die Straße auf dem Schlüssel übereinander liegt, ja, sozusagen, wenn man das mit vielen macht, dann werden die Abfragen langsam.

So ein bisschen wie an so einem Spielautomaten.

Wenn ihr so einen einarmigen Banditen habt, dann zieht ihr einmal dran, da sind ja so drei verschiedene.

Und wenn die dann parallel sind und alles zeigt, gewinnen, dann habt ihr den Schlüssel, den braucht.

Dann hat man die Zeilart halt von dem Schlüssel irgendwie zusammengeführt, ja, genau.

Und ja, also das ist halt auch, wie man ein Schema designt und so, ist halt so ein bisschen eine Kunst und man braucht Erfahrung dafür.

Aber man kann halt sagen, ja, man sollte das so ein bisschen normalisieren.

Also meistens es gibt dann ganz viele unterschiedliche Normalformen und meistens die Formen, die man dann so hat, ist so irgendwas zwischen dritter und vierter Normalform oder so, so zwischen dritter und Boyscott-Normalform oder sowas.

Aber ich möchte gar nicht so sehr on detail drauf eingehen, was jetzt der Unterschied zwischen den Normalformen sind.

Irgendwie kann man sich auch durchlesen auf Wikipedia oder so.

Braucht man auch im Alltag eigentlich gar nicht zu wissen, sondern da hat man dann halt irgendwann ein Gefühl dafür, wenn ein Datenbankschema okay aussieht.

Und dann macht man das halt so.

Das heißt, ich gehe jetzt tatsächlich erstmal hin und nehme ein Whiteboard, einen Zettel und schreibe mir auf, wie die Daten aussehen sollen.

Ja, ja, tatsächlich.

Also wenn ich irgendwie Datenbank designe für irgendein Projekt, dann nehme ich mir einen Zettel und fange an, Entity Relationship-Diagramme zu malen.

So nennt man die.

Was passiert denn später, wenn ich während dem Projekt merke, hey, ich habe aber die und die Daten vergessen?

Bastle ich da einfach irgendwo rein?

Ergänzt sich dann dieses Schema einfach?

Ja, das kommt darauf an, was das dann für eine Änderung ist.

Also das ist auch so ein Problem.

Man kann man Datenbanken nicht so richtig super ändern.

Also relationale Datenbanken, das Schema lässt sich schon ändern, aber das ist halt so ein bisschen knifflig und wenn man das tut, muss man halt irgendwie aufpassen.

Dass das alte Datenbanken noch kompatibel sind oder sowas, oder?

Ja, dass man das so ändert, dass nicht irgendwelche Inkonsistenzen entstehen und auch das halt.

Wie ändert

sich das bei unserem Beispielbeispielsweise?

Also wenn ich mir jetzt überlege, ich brauche jetzt eine neue Spalte in dieser Büchertabelle, ja, was ich nicht, es gibt jetzt nicht nur die E-Spieler.

Jemand oder das Genre oder sowas, jeder sammelt Seefahrerbücher.

Eine Kategorie, da würde ich halt tatsächlich, also das, was man sich zuerst überlegen könnte, ist, man macht einfach ein Textfeld oder Charfield, das halt den Kategorienamen enthält.

Und dann hat man halt das Problem, okay, dann stellt man fest, oder am besten noch, okay, fangen wir so an.

Man schreibt halt, man nimmt Tags statt Kategorie und sagt jetzt, okay, alle Tags, also weiß ich nicht, Belletristik, Komma, Seefahrerroman oder Komma, schreibt man jetzt Komma separiert halt in eine Spalte rein.

Dann hat man damit die erste Normalform verletzt und man muss sich dann im nächsten Schritt, wenn man das halt weiter normalisiert, überlegen, okay, nee, das geht nicht, darf ich so nicht machen.

Also der eigentliche Grund, worum man das nicht machen sollte, ist halt, dass es diverse Anfragen halt schwierig macht und dass man das auch sehr schlecht ändern kann und dass wenn man was ändern kann man und Sachen kaputt machen, weil Inkonsistenzen entstehen können und so.

Dann zieht man erstmal diese Dinge auseinander und sagt halt, okay, nicht in einer Spalte mehrere Tags reinschreiben, sondern dann hätte man sozusagen eine N-2M-Relation, also nicht nur, wo ein Fremdschlüssel in einer Tabelle zu einem Fremdschlüssel in der anderen Tabelle passt, sondern man hat dazwischen eine Link-Tabelle.

Man hat jetzt einmal Tags als Relation und einmal halt die Bücher als Relation oder als Tabellen halt.

Und dazwischen hat man jetzt noch eine Link-Tabelle zwischen oder eine Link-Relation zwischen Büchern und Tags.

Sodass man mehrere, also für jedes Tag hätte man dann sozusagen einen Eintrag in der Link-Tabelle, wo da drin steht, ID von diesem Buch, IDs von diesem Tag.

Ja, und das ist dann halt sozusagen die Verbindung zwischen den beiden Tabellen.

Also man halt halt eine Tabelle mit allen Tags, das ist möglicherweise gar nicht so lang, es gibt vielleicht nur tausend Tags oder so.

Und vielleicht ein paar Millionen Bücher und jetzt hat man halt eine Link-Tabelle, die wahrscheinlich dann irgendwie ein paar zehn Millionen Bücher, ein paar zehn Millionen Zeilen oder so lang ist, wo halt jedem Buch ein paar Texts zugewiesen werden.

Und dann ist es alles wieder schön in einer Normalform und das kann man dann auch wieder nett abfragen.

Ja.

Wenn man dann aber quasi diesen Tags halt, wenn man diese Tags jetzt aber betrachtet als Blätter in einem Kategorienbaum oder so, dann wird es wieder so ein bisschen schwierig, weil dann versucht man etwas in einer relationalen Datenbank abzuspeichern, was gar nicht so gut geht, nämlich irgendwie so Baumstrukturen oder Graphenstrukturen.

Das kann man dann auch machen und wenn es nicht viele Tags oder Kategorien sind, dann würde man versuchen, das wahrscheinlich nested Sets nehmen.

Das ist, äh, kann man sich mal angucken, wenn das interessiert, wie das, dann kann man dann halt auch per SQL-Abfragen machen, wie, ja, welche Bücher liegen denn jetzt unterhalb von dieser Kategorie?

Was man macht, ist, man schreibt an jede, man hat so einen Kategorienbaum und man schreibt dann an jedes Element in dieser hierarchischen Struktur, den traversiert man einmal First Order, ich weiß gar nicht genau.

Also beim Durchlaufen nummeriert man jeden Knoten, an dem man vorbeiläuft, durch.

Und man hat eine Spalte links und eine Spalte rechts.

Und links, wenn man links an den Sachen vorbeiläuft im Baum, schreibt man halt die Nummern links rein und dann rechts, wenn man rechts dran vorbeiläuft und dann kann man so Sachen, Rangeabfragen dazwischen machen und magischerweise führt das dann dazu, dass man so Subbäume rausselecten kann und so.

Aber das ist dann halt schon so wirklich für Fortgeschrittene.

Und im Endeffekt, wenn man jetzt große Grafenstrukturen hat oder Bäume, dann wäre es wahrscheinlich besser, das gar nicht mehr in einer relationalen Datenbank zu machen, sondern das irgendwie in einen anderen Service zu packen.

Ja, und da sind wir schon, boah, das ging aber schnell, da sind wir schon an Grenzen, von denen man so mit den relationalen Datenbanken gut machen kann.

Ja, also das Dorsch aus der Garage sind mittlerweile rausgewachsen.

Also wir können die ganzen Bücher deine Garage nicht mehr lagern.

Nee, nee, nee, Moment, Moment, Moment, also was eigentlich auch, nee, wir sind auch nicht, ähm, wir sind auch mal bei der ganz normalen, einfachen Datenbank, würde ich sagen.

Ja, also das, wofür wir die nämlich auch brauchen, die Datenbank, sind halt so Transaktionenprozessen, wenn jemand was kauft zum Beispiel.

Oh, jemand hat bei uns eine E-Mail geschickt und hat gesagt, hey, habt ihr das Buch da und wir gucken nach, sagen ja, können wir dir schicken.

Dann wird er an die und die Adresse und so, dann machen wir so ein Paket, machen da so ein Stempel drauf und sagen, hey, hier bitte

dein Buch.

Ja, und dafür, dass das gut funktioniert, dann müssen halt auch einige Sachen für gewährleistet sein.

Und das ist halt zum Beispiel so etwas wie, naja, wenn ich halt ein Buch kaufe, dann muss ich irgendwie sicherstellen, dass es im Lager ist.

Das heißt, wenn jetzt ich ein Buch verschicke, dann sage ich in meiner Datenbank irgendwie so, okay, jetzt ist davon eins weniger da im Lager.

Aber wenn jetzt auf der Webseite jemand sagt, ich würde dieses Buch einkaufen, dann muss halt gewährleistet sein, dass das halt noch da ist.

Das heißt, ich brauche halt eine zentrale Stelle, in der die Wahrheit.

Hier fällt direkt wieder eins der Probleme ein.

Okay.

Ja, zwei Leute wollen das gleiche Buch haben, was auch noch einmal da ist und die wollen dann gleichzeitig eins kaufen.

Genau, das ist halt, das ist halt eine problematische Geschichte.

Aber wenn man jetzt eine Datenbank hat, die die sozusagen Wahrheit kennt und alle nur auf die zugreifen, dann kann im Grunde nichts passieren.

Also da können keine Konflikte auftreten, weil in dem Moment, wo jemand auf kaufen klickt auf der Webseite und es noch ein Buch da war,

also die Frage ist halt jetzt, was man macht, wenn viele Kunden sich immer so ein Buch angucken, das in ihren Warenkorb reintun, weil sie es kaufen wollen, aber 90 Prozent dieser Kunden einfach gar nicht am Ende kaufen, sondern irgendwie wieder abspringen, weil die dann sagen, naja, doch nicht.

Und dann hätten die es ja alle sich bei sich in den Warenkorb reingelegt und wenn nur noch eins da ist, vielleicht hätte der zweite direkt angezeigt bekommen, gibt gar nichts, der ihn wirklich gekauft hätte.

Also was natürlich passieren kann ist, dass dir angezeigt wird, es gibt noch ein Buch, obwohl es keins mehr gibt.

Weil du hast halt, du sitzt halt vor der Webseite und machst nichts, halt

in den Luft.

Oh, leider war jemand schneller und hat vor zwei Sekunden das Gedanken.

Sobald du drauf drückst, in dem Moment, wo sozusagen diese Bestelltransaktion gestartet wird und dann in der Datenbank aber die Bedingung, es muss mindestens eins im Lager sein, damit diese Beschaltung ausgeführt werden kann, nicht mehr erfüllt ist und dieser Constraint wird verletzt, dann sagt die Datenbank so, äh, geht nicht.

Und dann kann man dem User eine Fehlermeldung anzeigen und sagen so, oh ja, tut uns leid, das hat nicht geklappt.

Kein Buch mehr auf Lager.

Das ist ja im Grunde okay.

Ja, gerade so.

Ja, also was halt, was halt blöd wäre, ist, wenn man dem User sagt, okay, du hast das jetzt bestellt, aber sagt am Schluss, Edgy Badge, du kriegst doch kein Buch, weil war keins mehr da.

Das ist halt so ein bisschen blöder.

Ist aber eine Situation, die dann später, wenn wir halt nicht mehr auf einer Datenbank bleiben können, weil das einfach nicht mehr, nicht mehr von der Skalierung her nicht mehr klappen kann irgendwann, dann kommen wir in solche Situationen rein und da müssen wir uns dann überlegen, wie wir damit umgehen.

Aber solange das alles auf einer Datenbank läuft, ist das, ist da im Grunde kein Problem, kann man das sauber lösen.

Ich hatte ja so mal es war, ich hatte das vielleicht schon mal kurz erwähnt, bei einer Bank.

Ich habe eine Transaktion gemacht, da hat dann die Bank gesagt, ja, ist wunderbar, deine Überweisung wurde vernünftig ausgeführt.

Und dann zwei Wochen später kriegte ich dann so eine Mahnung und dann habe ich nochmal aufs Konto geguckt und die Transaktion war weg.

War nicht da.

Warum habe ich dann da angerufen und haben gesagt, oh, ja, also in irgendeiner Logfile stand das dann wohl noch drin, dass ich so eine Transaktion eigentlich gemacht hatte, die aber nicht ausgeführt worden war.

Das war ein bisschen blöd dann für mich, aber ja, scheint wohl auch mal so größeren Männern.

Ja, möglicherweise war das eben eine Bank und das ist tatsächlich bis, ich weiß nicht, vor gar nicht allzu langer Zeit tatsächlich üblich gewesen, wo dann die Transaktionen nicht in einer relationalen Datenbank direkt ausgeführt werden, sondern wo es dann Batch-Prozessing gibt nachts.

Also die Sparkassen haben das ihnen lange gemacht.

Schmeißt dann manuell die ausgedruckten Briefchen ins Überweisungs.

Lochkarten, ja.

Fährt jemand mit den Lochkarten dahin und dann kommen die in so einen Laser und dann werden die da durch.

Und vielleicht, wenn da eine Lochkarte rausfällt, dann ist halt eine Transaktion weg.

Nicht so gut.

Ja, aber kann, sowas kann tatsächlich passieren und das ist natürlich etwas, was er gerade bei der Bank eigentlich, wo man sich denkt, na, das sollte eigentlich nicht.

Aber ja, aber wenn man ein sauberes, relationales Datenbanksystem verwendet, dann kann das eigentlich nicht, oder sagen wir mal so, das bietet einem Lösungen für dieses Problem.

Und im Grunde, wenn das Ding sagt, ja, die Transaktion ist durch, dann hat das auch funktioniert.

Man kann sich auch drauf verlassen.

Engler und auch davon an, welche Daten man verwendet.

Es gibt halt welche, die nicht so richtig alle Features unterstützen, die man dafür braucht.

Also zum Beispiel, was man eigentlich dafür braucht, damit das ordentlich funktioniert, ist, man braucht halt Isolation zwischen unterschiedlichen Transaktionen.

Also Transaktionen heißt eigentlich nur, dass man mehrere Schritte, die man ausführt, irgendwie zusammenbündelt und dann halt entweder alle funktionieren oder keiner.

Ja, und das wäre halt genauso ein Fall wie, ich kaufe ein Buch, ist halt ein Ding in der Datenbank, müssen jetzt mehrere Sachen passieren.

Da muss halt irgendwie diese Bestellung erzeugt werden, dann muss irgendwie aus dem Lagerstand irgendwie rausgelöscht werden, muss halt der Lagerbestand um eins reduziert werden und so.

Und das sind halt mehrere Statements, die ausgeführt werden.

Und jetzt müsste halt, wenn jemand anders in der Zeit das gekauft hat und es keine Bücher mehr, keins dieser Bücher mehr auf Lager gibt, müsste halt dann, nachdem der eine Teil der Transaktion, nämlich das Reduzieren des Lagerbestandes von diesem Buch nicht mehr funktioniert, müsste halt auch das andere, nämlich das Erzeugen der Bestellung auch fehlschlagen und dann halt eine Fehlermeldung zurückkommen.

Dann ist es halt sauber.

Wenn ich jetzt ein System habe, das das nicht macht und ich erzeuge die Bestellung, habe jetzt in meiner Bestellung-Tabelle das Ding erzeugt, sag jetzt in der Lagerstandstabelle so dieses Buch eins weniger und dann sag das, hier habe ich ein Constraint auf, es darf nicht weniger als null werden, also minus eins Bücher ist schwer, das funktioniert irgendwie nicht so richtig, dann sollte, dann, und es dann knallt, dann kann das natürlich, wenn ich jetzt ein System habe, das ist nicht, das kann eine Transaktion kann, dann hätte ich jetzt die Bestellung zwar immer noch da und aber.

Was ist denn jetzt als Beispiel, wenn ich jetzt sowas habe wie minus ein Buch und ich möchte jetzt einfach, dass, wenn minus ein Buch ist, dass das nachbestellt wird von dem Händler um die Ecke.

Also der hat noch eine Garage und die Mann ist noch ein Händler, der hat auch so Bücher und vielleicht hat der eins da und dann sage ich einfach, ja, ich muss das irgendwo anders herbekommen.

Könnte ich ja auch vorstellen.

Kann man auch machen, müsste dann, ja, das hängt dann vom System ab, was die Logik dann macht.

Man könnte ja sagen, okay, die Bestellung wird trotzdem ausgeführt, dafür wird dann aber das.

Oder das

Buch wird gedruckt oder sowas.

Wann das, ja genau, nochmal produziert.

Aber dann verändert sich möglicherweise das Ziel dafür, wann das halt ausgeliefert wird.

Oder so, ne?

Und das halt dann, je nachdem, wie das System funktioniert, kann man das machen.

Okay, also

ich habe am Anfang mir so ein Schema ausgedacht, wo dann halt drin steht, was ich überhaupt alles machen will, machen kann.

Und wenn mir irgendwelche neuen Dinge einfallen oder so, dann muss ich kurz überlegen, was ich an meinem Schema ändere, aber das am besten mache ich das Schema am Anfang schon so fertig, vollständig, dass das unproblematischer geht.

Das ist halt, das ist ein bisschen ein Problem.

Man sollte ein Schema schon von Anfang an halbweg so designen, dass es halt passt.

Es ist später nicht mehr so ganz einfach, das zu ändern.

Oder kann das natürlich ändern, aber ist auf jeden Fall.

Nee, aber

es hängt auch ein bisschen vom Geschäftsmodell ab, ne?

Wenn euch jetzt auf einmal merke ich, so oh, ich verkaufe jetzt vielleicht gar keine Bücher mehr, sondern weiß nicht, komplizitere Produkte oder sowas, die noch einen anderen Aufwand haben, jetzt nicht nur getaggt werden sollen, sondern wo noch mehr Metainformationen drin sind, irgendwelche anderen Snippels, also der Buchtext vielleicht noch oder andere Informationen, die dazugehören oder so.

Ja.

Also ich kann ja nicht jedes Mal an einer neue Darkmann anfangen, sondern ich muss ja auch gucken, dass sie irgendwie mitskaliert.

Ja, aber das sind wirklich schwierige Probleme.

Das ist ein bisschen unintuitiv, dass das so knifflig ist, aber es ist leider so.

Ein wirklich lustiges Beispiel aus der Praxis.

Das zeigt, dass es halt nicht so einfach ist.

Möglicherweise finde ich iTunes oder der App Store.

Und der App Store war am Anfang, also man hat den nicht neu entwickelt, sondern das war, man hat den, also über iTunes konnte Apple ja schon immer irgendwie so Musik verkaufen.

Das hat auch recht gut funktioniert.

Oder halt deutlich früher, als es jetzt das iPhone gab und einen App Store.

Und dann sollte es halt dieses App Store-Feature geben.

Und dann haben sie halt einfach ihr iTunes-Song-Verkauf-Ding genommen und das halt einfach nur gesagt, okay, das sind jetzt keine Songs, sondern das sind Apps.

Was halt dazu führt, dass bis heute, und jetzt sind wir mehr als zehn Jahre später, ähm, bis heute haben halt irgendwie Apps einen Titel und eine Länge, äh, Songlänge oder sowas, ja.

Dass halt totaler Quatsch ist.

Also es passt ja überhaupt nicht zusammen.

Aber es ist halt sehr, sehr schwer, das zu ändern.

Weil, ja, das würde so viel Logik irgendwie brechen, dass in anderen Systemen, das ist halt extrem, also du kannst halt, ja, also eine solche Migration durchzuführen, ist halt hinterher sehr, sehr schwer.

Wenn du quasi die ganzen Daten einmal anfassen und abgleichen und bereinigen und schrubben und putzen.

Die Daten sind gar nicht so sehr das Problem.

Das Problem sind die anderen Systeme, die es auch alle drum herum gibt, die sich verlassen, dass die Datenbanken so aussehen, wie sie aussehen.

Okay.

Also wenn ich jetzt, also die Daten selber zu ändern, ist, glaube ich, wäre nicht so das Problem.

Aber ich muss jeden Prozess bei jedem Nutzer dieser Datenbank darüber informieren, dass er sich das Schema irgendwie hat.

Und der muss damit klarkommen.

Und das ist halt möglicherweise Legacy-Code, wo der Letzte, der sich damit auskennte, vor fünf Jahren gegangen ist.

Aber das System macht irgendwas Vitales, was irgendwie total wichtig ist für das Business.

Und tja, dann wird es halt richtig schwer.

Und wenn du dann nicht nur ein solches System hast, sondern zig, dann kann es sein, dass du halt zehn Jahre lang das nicht mehr ändern kannst.

Und dann manchmal sieht man dann so ein bisschen lächerlich aus, aber wie jetzt in dem Apple-Fall.

Wenn aber keine Songlänge hat, ja.

Ja, aber es ist halt, das zeigt halt so ein bisschen, wie knifflig das dann werden kann, wenn man Pech hat.

Ja, und das ist auch so ein Problem bei relationalen Datenbanken insgesamt möglicherweise, würde ich sagen.

Also gerade der E-Commerce-Fall oder der Amazon-Fall funktioniert eigentlich ganz gut.

Zunächst, also später wird das dann halt auch nochmal ein bisschen problematischer, aber weil physische Dinge halt relativ stabil sind, was irgendwie so ihre Eigenschaften angeht.

Also da funktionieren relationale Datenbanken halt besonders gut.

Unwahrscheinlich, dass so ein Buch noch ein anderes Cover enthält oder sowas.

Also dass ich Bücher jetzt irgendwie, dass die plötzlich ein Attribut bekommen, was es halt vorher nicht gab.

Die wachsen Flügel.

Die haben halt irgendwie Titel, Seitenanzahlen oder sowas, aber dass sie jetzt plötzlich irgendwie, keine Ahnung, ich weiß nicht, was man sich da vorstellen könnte.

Man müsste jetzt irgendwie Bücher.

Jedes Buch enthält einen Geist.

Bücher haben Flügel.

Ja, keine Ahnung.

Bücher kann man jetzt essen oder so, haben einen bestimmten Geschmack.

Haben einen bestimmten Geschmack, das ist sehr unwahrscheinlich, dass das passiert, weil das würde bedeuten, dass sich die physikalische Realität irgendwie ändert, was sie ja, was sie natürlich auch tut.

Wie du isst kein Buch für ein Frühstück.

Aber das tut sie relativ langsam.

Und das ist gut, weil das können man jetzt sozusagen diese physischen Dinge in der Datenbank beschrieben hat, die kann sich auch nur langsam ändern.

Und das passt dann so ein bisschen zueinander.

Also das ist halt, wenn man jetzt die Eigenschaften von einem Buch erstmal erfasst hat, dann ändert sich da wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig viel dran.

Und dann muss man auch in der Datenbank nicht so wahnsinnig viel ändern.

Wenn man jetzt ein anderes Problem hat und man jetzt zum Beispiel in der Datenbank nicht Daten über physikalische Objekte hält, sondern Daten über Daten.

Oh, Metadaten.

Metadaten.

Die können sich dummerweise unter Umständen, je nachdem, wie.

Daten über Daten über Daten.

Das kann sich dann, da kann plötzlich die Geschwindigkeit, mit der sich die Strukturen da ändern müssen, deutlich schneller werden.

Und dann wird es schwierig.

Dann sind relationale Datenbanken auch so, das ist dann ein Problem.

Das ist auch möglicherweise einer der Gründe dafür, warum jetzt in letzter Zeit halt immer mehr so NoSQL oder Dokumentdatenbanken oder wie man das, manche nennen das auch Schemaless, warum die halt populärer werden, weil man damit halt möglicherweise auf diese geänderten Anforderungen halt besser reagieren kann, dass man ja möglicherweise ad hoc das Schema irgendwie ändern muss und das halt in der relationalen Datenbank nicht so ganz einfach ist, weil so absolut kann man das auch nicht sagen.

Also es gibt da diverse Möglichkeiten, wie man die Geschichten miteinander verbinden kann.

Und ja, wenn Schema lässt, ist halt auch nicht schema lässt, sondern das bedeutet halt mehr oder weniger nur, dass die, dass das Schema jetzt implizit in deiner Applikation ist und du halt immer aufpassen musst, wenn du deine Applikation änderst, dass du da das Schema nicht kaputt machst oder änderst oder so und das überlegen sich viele Leute da nicht so richtig und dann ändern sich irgendwas und dann passieren furchtbare Dinge und also dann fällt ihnen auf, dass sie doch ein Schema haben.

Und ja, dass sie dieses Problem halt doch nicht losgeworden sind.

Also es ist leider alles nicht so einfach und das ist tatsächlich so, dass man bei Datenbanken halt im Design am Anfang ein bisschen mehr Arbeit hat, aber dafür hat man auch dann einen lustigen Vorteil, nämlich es ist immer so schön, irgendwie Daten altern wie Weinen.

Also wenn man halt viele gute Daten hat, das ist super.

Und wenn das mehr werden, das ist immer schön und das altert auch gut, ja, das wird immer besser mit der Zeit.

Man kann immer mehr Wissen daraus generieren, man kann immer mehr Fragen beantworten oder so.

Das ist eine sehr schöne Sache.

Und Applikationscode, Code, sagt man, Code altert wie Fisch.

Ja, also das ist nicht gut.

Wenn immer Features drankommen oder Sachen geändert werden, also das wird immer schlimmer mit der Zeit.

Das ist eigentlich selten so, dass man irgendwie jetzt mehrere Jahre irgendwie an einem Projekt entwickelt und die Codequalität wird immer besser.

Das ist irgendwie nicht so, sondern es wird immer, es wird irgendwie, und daher ist halt.

Noch ein Frickel da, noch ein Frickel dort.

Kleines Mödülchen an der Seite.

Und auch das Problem ist halt, die Anforderungen verschieben sich halt irgendwie.

Oder sagen wir so, die Realität ändert sich und dann ist halt der ursprüngliche Plan oder die ursprüngliche Architektur der Applikation ist halt nicht mehr darauf angepasst und so.

Und da hat man dann halt genau dieses Problem, dass wenn man jetzt das Schema verlagert in die Applikation und die Applikation aber altet wie Fisch, dann halt auch altern auch die Daten nicht gut.

Und deswegen ist es eigentlich schon sinnvoll, da eine Trennlinie zu haben und zu sagen, okay, selbst wenn wir die Applikationen irgendwann wegschmeißen müssen, neu schreiben müssen oder so, dann haben wir immer noch die Daten und die sind halt sauber strukturiert und das sieht alles gut aus.

Und das kann eine sehr wertvolle Sache sein, wenn man das richtig macht.

Und ja, genau, deswegen ist diese Trennung, wo man halt irgendwie ein striktes Schema hat und dass auch diverse Constraints, die halt irgendwie, also dass man halt solche Sachen drin hat wie, es kann nicht im Lager Sachen geben mit einem Lagerstand von Minus irgendwas.

Das darf halt nicht sein.

Da ist ein Fehler passiert und kann die Datenbank schon dafür sorgen, dass das halt nicht da reingeschrieben wird, weil die sagt halt so, nee, so nicht.

Man muss halt bloß dieses Constraint definieren und sagen, so auf dieser Spalte, da dürfen keine negativen Werte auftauchen.

Oder eben sowas wie ein Gehalt, das darf auch nicht negativ werden.

Oder dass halt bestimmte Datumsinformationen halt nicht so und so sein können.

Oder dass man halt tatsächlich auch ein, ähm was man mit Postgres machen kann.

Postgres ist halt wirklich eine schöne Wahl, für wenn man jetzt mit so einer Geschichte anfängt.

Das kann so tolle Sachen wie, wenn du jetzt eine Buchhandelsbeispiel zu bleiben, du hast jetzt eine Büchertabelle, da sind natürlich auch alle alte Bücher drin, weil die werden ja auch möglicherweise referenziert von Bestellungen, die lange zurückliegen oder so.

Du möchtest aber, wenn du jetzt eine Suche irgendwie auf der Website hast oder du hast halt irgendwie so eine Faceted Navigation, wo du nach Kategorien einschränken kannst, und da klickt jetzt einen User drauf und sagt, okay, ich hätte jetzt eine Romane oder Seefahrerromane, dann gibt es einen Index, der das halt schnell macht, diese Abfrage, und du willst jetzt aber Sachen von diesem Index ausschließen, zum Beispiel Bücher, die es gar nicht mehr gibt, die nicht mehr produziert werden, die vor Jahren irgendwie nicht mehr, seit Jahren nicht mehr gedruckt werden.

Und das kann man mit Postkreis tun.

Man kann sagen, also ich brauche diese Einträge in der Buchtabelle noch, um halt, damit die referenzielle Integrität, sondern das halt von alten Bestellungen nicht bricht, die er brechen würde, wenn ich das einfach löschen würde, dann hätte ich halt einen Pointer in der Bestellung-Tabelle, der halt auf etwas zeigt, was es nicht mehr gibt.

Das wäre schlecht, weil ich dann gar nicht mehr weiß, was es sein soll und so.

Aber trotzdem werden diese Dinger nicht mehr in den Index geschrieben.

Also ich kann halt einen Index so definieren, dass er nur Sachen, Bücher mit reinnimmt, die halt doch tatsächlich noch verkauft werden.

Und das heißt, es ist nicht so ein.

Und an solchen Stellen ist Postgres halt sehr schön, hat sehr viele Features, zum Beispiel jetzt im Unterschied zu MySQL, wo das halt so, solche Sachen gehen da gar nicht.

Also das ist halt, und da hast du dann halt ein Problem.

Bei Büchern ist es jetzt nicht so schlimm, also so viele Bücher gibt es nicht und so viele, die dann halt nicht mehr verkauft werden, auch nicht.

Aber man könnte sich vorstellen, es gibt durchaus Anwendungen, wo man dieses Problem ganz massiv bekommt, dass man halt eine Menge gelöschte Geschichten in der Tabelle hat, die man aber nicht wirklich löschen kann, sondern nur als gelöscht markiert.

Und dann der Index aber immer größer wird und langsamer wird, weil man halt nicht so einen partiellen Index über Sachen haben kann.

Ja, überhaupt Postgres kann halt auch noch diverse andere Geschichten, damit könnte man halt auch so Sachen lösen, wie welche Pakete kriege ich eigentlich in so einen Lieferwagen rein und so, weil der kann halt, das Ding kann halt nicht nur so B-Trees, die man jetzt für Textabfragen, Indexabfragen benutzt, also dass man sagt, welche Kategorie beginnt jetzt mit folgenden drei Buchstaben oder so.

Da nimmt man B-Tree, aber es kann halt auch solche Sachen wie Polygone, Abmessungen, überdeckt das eine das andere.

Es kann halt so R-Trees, die man halt für diese ganzen räumlichen Datengeschichten braucht, aber es kann nicht nur das, sondern es kann auch so Sachen wie welche Sachen liegen nah an anderen, so KD-Trees, Wall-Trees.

Es kann sogar Suffix-Trees, also Postgres kann da eine ganze Menge unterschiedlicher Abfragen und Indizes, die man also.

Aber ich glaube, die lohnen sich jetzt noch nicht bei unserem kleinen Laden.

Wir sind ja, glaube ich, noch herzlich.

Ja, doch, doch.

Ja, hier hat man.

Ja, ja, wenn wir die Schwert.

Wenn du deine Lagerhaltung, das möchtest du halt im gleichen System machen, damit eben du nicht das Problem kriegst, dass du den State zwischen unterschiedlichen Systemen synchronisieren musstützt.

Also wenn du jetzt deine Lagerhaltung in einem System machst und machst dann deine Webseite oder die Datenbank, die die Webseite treibt, sozusagen die, über die du Bücher verkaufst, wenn das unterschiedliche Systeme sind, dann musst du den State zwischen diesen Systemen ja irgendwie synchronisieren.

Was schlecht ist, würde ich zum Beispiel sagen, das ist halt am Anfang sehr, sehr hilfreich, wenn das alles ein System ist.

Weil man dann eben tatsächlich eben die referenzielle Integrität, Constraints, über alle Daten hinweg machen kann und dann von der Datenbank sicherstellen lassen kann schon, dass bestimmte Sachen nicht gehen und dass bestimmte Sachen immer erfüllt sein müssen.

Das heißt, unser Schema setzt das dann tatsächlich fest und das gibt da sonst recken Fehler aus der Datenbank, hey, dürfen wir nicht, geht nicht, und wir haben das Schema dabei arbeitet für unseren kleinen Laden und so weiter

können wir dann nur.

Kann dann eine Applikation oder die Programmierer, die jetzt vielleicht gar nicht, ja, der jetzt, die Leute, die die Webseite bauen, die haben jetzt vielleicht gar nicht so viel Ahnung von Lagerhaltung.

Die können aber, egal, was sie auf der Datenbank machen, sie können nichts kaputt machen.

Weil wenn sie etwas tun, was eigentlich nicht geht, wie zum Beispiel einen Lagerstand von einem Buch auf minus 1 setzen, dann sagt ihnen die Datenbank, nö, mach ich nicht.

Und dann kriegen sie halt einen Fehler.

Und das ist halt sauber, weil wenn du jetzt zwei Systeme hättest und musst jetzt da synchronisieren und jetzt ist aber schon irgendwie.

Ja, das blöd ist.

Aber eigentlich nicht, dann sagt die eine Datenbank, ja, habe ich aber.

Und dann, ja, okay.

Da kommst du halt in Teufelsküche.

Und man könnte sich vorstellen, dass das eine gute Idee wäre, wenn man das macht, dann wird man halt relativ schnell feststellen, ist keine gute Idee.

Ist doof.

Das ist auch vielleicht ein bisschen unintuitiv, aber ja.

Und natürlich, nachher muss Sachen funktional rausnehmen und man muss dann das in mehrere Systeme aufgleichen.

Man sollte so lange wie möglich versuchen zu verhindern, dass das passiert, weil das macht alles viel, viel schwerer.

Ja.

Genau, also wo sind wir jetzt eigentlich?

Genau, wir sind klein und niedlich, wir haben Postgres, machen alles über Postgres, wir haben ein bisschen JavaScript auf der Client-Seite.

Ansonsten nehmen wir, sagen wir mal, Django oder so als Webframework.

Aber genau, jetzt kommen wir erstmal zu, wie machen wir das mit Python.

Genau, Python, ja.

Genau, da brauchen wir halt irgendeine Art, wie wir auf die Datenbank zugreifen.

Üblicherweise, wie man Statements oder Abfragen an der Datenbank formuliert, ist halt SQL, heutzutage halt so der Standard für solche Systeme.

Aber ja, das ist halt immer ein bisschen Fremdkörper.

Wenn man jetzt einen Python-Code schreibt, dann hat man jetzt so ein SQL-Statement, das passt von der Syntax her überhaupt nicht in Python rein.

Da muss man einen langen String marrunnen, der irgendwie vernünftig aussieht und da muss dann alles stehen, was mit der Datenbank kriegen kann.

Genau, und das ist halt irgendwie nicht so schön.

Also das gibt dann unterschiedliche Methoden.

Wenn man jetzt tatsächlich mit den rohen Statements arbeitet, es gibt Leute, die packen halt alle Statements in ein Pfeil und packen dann Funktionen drum und dann ruft man halt diese Funktionen auf.

Das kann man machen, das hat so Vor- und Nachteile, dann kann man aber auch sagen, okay, das ist aber schlecht, eigentlich möchte ich in dem Moment, wo ich mit den Daten arbeite, das Statement auch sehen und auch ändern können.

Dann packt man halt sozusagen die Statements immer an die Stelle, wo man halt tatsächlich mit den Daten arbeitet.

Das hat auch wiederum Vor- und Nachteile, das hat den Vorteil, dass man halt Sachen leicht ändern kann, aber es hat halt einen Nachteil, dass man unter Umständen mehrere Statements, die sehr ähnlich oder gleich sind, an unterschiedlichen Stellen hat.

Alles nicht so total toll.

Es ist auch nicht so ein einfaches Problem.

Und eine ganz gute Lösung für dieses Problem sind so objektrelationale Mapper oder ORMs.

In Django ist einer eingebaut.

Der Django-ORM.

Ja, genau.

Wo man dann halt gar nicht wirklich mitkriegt, dass das SQL unten drunter ist, sondern man schreibt halt ganz normalen Python-Code.

Man definiert die Daten, die man in der Datenbank stehen haben möchte, einfach nur als Klassen.

Man schreibt halt irgendwie.

Das heißt, das Schema wird nochmal als Klasse eingebaut, oder?

Das Schema entsteht dadurch, dass man unterschiedliche Klassen hat, die irgendwie in Beziehung zueinander stehen.

Also was aufeinander map, ist halt Klasse und Tabelle.

Also ich hätte dann, wenn ich Bücher kaufen möchte, halt eine Klasse Book.

Und dann hätte ich halt vielleicht eine Klasse Tag.

Und wir hatten das ja eben mit dem Beispiel, ich habe eine N2M-Beziehung zwischen Tags und Büchern und dann würde man entweder in Tags oder in Büchern irgendwo definieren.

Also das hier ist dieses Feld Tags ist halt ein, wie heißt das in Django?

Weiß ich jetzt irgendwie, ne, irgendwas Foreign Key Field, irgendwas, aber man sagt halt, das ist halt Many-to-Many Relation, irgendwas, weiß ich nicht, muss ich nachgucken.

Aber auf jeden Fall definiert man das halt wie eine Spalte in einer Tabelle.

Also Attribute der Klasse sind halt Spalten in der Tabelle und sagt dann halt, das hier ist eine Many-to-Many-Beziehungen zu der Relation Tags.

Und dann hat man die Link-Tabelle wird automatisch erzeugt, man kriegt das gar nicht mit.

Und im Code hat man halt nur Bücher und Tags und halt dann diese Beziehung dazwischen.

Und dann ja, wenn man sich das halt so hindefiniert hat und dann halt alle Klassen, die man so braucht, beziehungsweise alle Tabellen, die man halt irgendwie in der Datenbank haben möchte, definiert hat mit den Spalten und den Typen der Spalten und den entsprechenden Constraints und den Indices und den ganzen Kladratarch, den man auch sonst noch so braucht, dann sagt man Migrate und dann werden die ganzen Tabellen in der Datenbank tatsächlich angelegt.

Oder make Migrations rufen wir halt zuerst auf und damit werden halt so Migrationskripte in Django angelegt.

Das sind auch einfach nur Python-Files, in denen drin steht, was diese Migration tun soll, nämlich zum Beispiel irgendwie Tabellen anlegen, Indizes anlegen oder sonst irgendwas.

In die kann man auch beliebige andere Dinge reinschreiben.

Also man kann halt auch selber Migrationen einfach so von Hand schreiben.

Wenn man zum Beispiel jetzt sowas wie, es gibt so Datenbank-Trigger.

Also man kann halt sowas.

Ja, man könnte halt, also wenn zum Beispiel

Nutzertaggen selber und erfinden eine neue Kategorie.

Ja, ich überlege gerade, ob mir fällt ehrlich gesagt jetzt gerade nicht so ein tolles Beispiel ein, aber im Grunde, was das tut, ist, wenn sich halt in einer bestimmten Spalte irgendwas ändert, dass dann automatisch andere Aktionen passieren innerhalb der Datenbank.

Und das kann man halt festlegen, haben auch in SQL-Syntax und man schreibt es halt einfach in eine Migration rein.

Oder man kann auch sogar Sort Procedures, die halt dann irgendwie eine komplizierte Geschichte, die dann irgendwie ausgeführt wird, wenn ein neuer Autor angelegt wird oder sonst irgendwas.

Dann müssen vielleicht noch diverse andere Geschichten gemacht werden.

Das kann man ganz normal in diese Django-Migration auch reinschreiben.

Man kann eine Big SQL reinschreiben und die werden dann mit ausgeführt und dann werden halt diese Sort Procedures oder Trigger in die Datenbank mit reingeschrieben und sind dann halt da.

Und was im Schema passiert oder was da drin ist, das wird halt dann von diesem Django-Migrationssystem verwaltet und alle Migrationen, die ausgeführt worden sind, werden halt auch wieder in derselben Datenbank halt gehalten von Django selbst.

Da gibt es dann halt auch Tabellen zu.

Und man kann jetzt Sachen auch wieder zurückrollen.

Also man kann zum Beispiel sagen, wenn es eine Änderung gemacht hat und feststellt, oh, die war nicht so toll, dann sagt man halt einfach so Migrate und dann gibt man die Nummer der Migration an davor und dann rollt sich die Datenbank in den Zustand davor zurück.

Und dann löscht man einfach die Migration und dann war es das.

Also das macht es halt sehr angenehm, damit zu arbeiten.

Und sowas braucht man auf jeden Fall.

Also selbst wenn man jetzt sowas nicht wie Django verwendet, sondern das alles von Hand macht, dann braucht man auch irgendeine Art, wie man damit umgeht.

Und das war teilweise früher ziemlich übel, als es keine so gute Unterstützung in den Frameworks für sowas gab, da hat man das halt irgendwie von Hand gemacht, aber da passieren dann immer wieder Unfälle, man hat halt irgendeine Datenbank vergessen oder wenn man jetzt halt mehrere Datenbanken hat oder es geht irgendwie sowas verloren, man weiß nicht genau, in welchem Zustand die Datenbank ist, weil irgendwie man meint, man hätte die ausgeführt, aber dann ist es irgendwie doch nicht passiert oder weil eben nirgendwo drinsteht, in welchem Zustand die Datenbank ist, sondern man nur Leute fra

gt, irgendwie so, also hast du die Migration jetzt eigentlich auf der Produktionsdatenbank schon ausgeführt oder nicht?

Ja, ja, hab ich gemacht.

Dann ändert, das ist vielleicht auch nicht passiert.

Also es ist sehr schön, wenn das halt irgendwie selbst auch in der Datenbank festgehalten wird, in welchem Zustand man ist.

Ja, und das jetzt so ein Framework wie Django bietet einem dafür halt so wirklich relativ vollständige.

Wir merken wieder, du bist ein Django-Fan, ja.

Ja, damit umzugehen.

Kann man Flask, wenn man jetzt das andere große Web-Framework kann man jetzt nicht da so wirklich zu sagen, aber das andere Paradigma, wie man Web-Anwendungen in Python entwickelt.

Wenn man das mit Flask macht, hat man das auch alles.

Da gibt es dann SQL Alchemy als ORM und halt, ich weiß jetzt nicht, das hat irgendeinen Namen, die Migrationslösung dafür, an denen ich mich jetzt gerade nicht erinnere.

Und da geht das alles auch.

SQL Alchemy ist sogar deutlich mächtiger als der Django-ORM, aber ist halt nicht integriert.

Und Flask ist auch super.

Der Trade-Off ist halt so ein bisschen, was einen Django so abnimmt, ist halt, dass man sich halt um viele Abhängigkeiten nicht kümmern muss, weil man installiert halt Django und dann hat man halt einen Großteil von dem, was man so braucht.

Und das wird halt dafür, dass das alles konsistent bleibt und man upraden kann und so, dafür wird gesorgt, da muss man selber an sich nicht drüber kümmern.

Wenn man jetzt Flask macht und dann halt ganz viele unterschiedliche Teile hat und die ihre Versionen ändern und so, dann muss man selber am Ball bleiben und auch Konflikte halt selber auflösen.

Das heißt, man hat so langfristig mehr zu tun damit.

Aber dafür ist man halt auch flexibler und kann halt, wenn einem eine bestimmte Art von ORM besser gefällt, den halt verwenden.

Es gibt halt auch zum Beispiel irgendwie neuere, also SQL Alchemy ist sehr alt, Django ORM ist relativ alt, es gibt PWE und Pony ORM oder so, das sind jetzt modernere Geschichten, sieht besser aus.

Macht unten drunter irgendwie was sehr ähnliches, aber ja.

Genau, also ein Teil davon ist halt immer, wie man die Relationen und Tabellen definieren kann.

Das sind meistens Klassen, die man dann halt aufschreibt.

Und dann erzeugt man daraus halt die Datenbankstruktur.

Und der andere Teil vom ORM ist halt, wie man Abfragen auf die Datenbank halt abfeuert.

Und das, was man eigentlich fast bei allen ORMs dann so macht, ist, man macht so Message Chaining.

Ich weiß nicht, sagt ihr das was?

Bis jetzt nicht.

Ja, gibt es auch so auf dem Data Science, also Pandas oder so, da macht man das auch.

Also man kann in Python, ja, man kann ja irgendwas sagen, so man hat ein Objekt, Punkt, Methodenaufruf oder Punkt Attribut, Punkt, wie noch was anderes, Punkt, wie noch was anderes.

Wenn zum Beispiel eine Methode ja ein Objekt zurückgibt, dann kann man nicht auf diesem Objekt wieder was anderes aufrufen.

Wenn ich das alles in eine Zeile schreibe, wird das irgendwann relativ lang.

Aber wenn ich jetzt ein Statement modellieren möchte, das halt viele Ware-Bedingungen hat, die Art in Django-ORM das hinzuschreiben, wäre halt zu sagen Filter irgendeine Spalte gleich irgendeinen Wert oder sowas.

Aber dann habe ich noch ein zweites, dann sage ich Punkt Filter, nächste Spalte, wieder ein anderer Wert oder so.

Und das wird halt relativ länglich, daraus wird dann halt ein Statement generiert, aber was ich halt tun kann, ist zu sagen, Klammer auf und dann halt Query Set Punkt Filter Punkt Annotate und dann Dinge gruppieren oder so oder neue Spalte hinzufügen.

Und ich mache hinten noch eine weitere Klammer drumherum, dann kann ich das halt auch einrücken.

Und dann rücke ich das so ein, dass alle Punkte untereinander stehen.

Und dann habe ich halt so ein mehrzeiliges Dings, was so ein bisschen eine Zwischenform ist zwischen SQL und Python-Code.

Ja, aber ich spare mir dadurch, sozusagen das jedes Mal irgendeiner Zwischenvariable zuweisen zu müssen.

Ansonsten könnte ich ja natürlich sagen, Queryset gleich, Queryset Punktfilter irgendwas und dann sage ich in der nächsten Zeile QuerySet gleich Queryset.filter noch irgendwie eine andere Spalte.

Ich kann das aber auch alles in ein einziges Dings reinschreiben.

Man nennt das Method-Chaining, genau.

Ja, und das ist halt irgendwie das.

Bei Pandas ist es halt genau so, dann hat man Data-Frames, auf denen man dann Sachen macht und dann, die geben dann auch immer wieder in Data-Frames zurück, die viele der Methoden.

Und die kann man halt auch so chain.

Und dann hat man da oft so mehrzeitige Dinge, wo halt die Punkte untereinander stehen.

Also wenn man nicht weiß, was es ist, das ist Method Chaining und das ist halt so eine Methode, um Dinge halt in eine Step zu machen.

Irgendwie schon mal so ein bisschen gesehen, aber so wirklich wissen, was das Message Chaining heißt, ist natürlich ja.

Ja, genau.

Und im Grunde ist es halt dann, wenn man ORMs, wenn man Queries in ORMs so macht, ist es halt so ein bisschen, ist es so ein Zwischending zwischen SQL und Python, aber das funktioniert dann halt so halbwegs gut und das ist dann halt sehr angenehm.

Und dann ist es nicht mehr ein Problem, wenn man jetzt sozusagen diese Art von Logik an unterschiedlichen Stellen im Code stehen hat, weil die Statements, die rausfallen, sind halt alle gleich.

Und wenn ich jetzt irgendwie, keine Ahnung, mir überlege, dass ich eine bestimmte Art von Optimierungen machen möchte an den Statements, dann wäre die halt ja auch immer gleich.

Das heißt, dann habe ich halt dieses Problem, das ich sonst hätte, wenn ich das alles in einen File schreiben würde oder wenn ich das in, wenn ich unterschiedliche, wenn ich fast gleiche Statements in unterschiedliche Files schreiben würde, wenn ich die Statements beim Code haben will, das habe ich damit dann nicht mehr.

Und das ist natürlich ein sehr schöner Effekt.

Und das ist halt, ja, so einer der Hauptnutzen von ORMC.

Also ein anderer schöner Nutzen ist halt, dass man halt diese ganze Migrationsgeschichte, wie ändern sich Sachen, halt auch automatisiert hat, beziehungsweise die ganzen Prozesse drumherum irgendwie zumindest mal abgebildet hat.

Ja, also sind wir klein und niedlich und das haben wir jetzt gemacht.

Genau, und da würde man so ein Framework verwenden, ein ORM und dann ist man eigentlich, ja, das geht alles ins Git, es gibt Versionskontrolle dafür.

Und dann, das ist eigentlich alles schon relativ komfortabel.

Ja.

Ja, was passiert jetzt?

Also wir sind klein und jetzt haben wir das Schwimm gebaut, aber ja, wann funktioniert das ja nicht mehr so?

Äh, ja.

Genau.

Wir haben als Online-Handel einen Riesenvorteil gegenüber stationären Buchhandel, weil das ist auch eine interessante Statistik.

Es kommt, glaube ich, aus diesem Buch Longtail irgendwie von Wired-Redakteuren.

Jedenfalls schreibt er da, dass Amazon macht die Hälfte des Umsatzes mit Büchern, die nicht in den Top 300.000 sind.

Weil eben Bücher verkaufen, so ein

ganz individuelles Bücher.

Da verkauft die Bücher halt so eine Longtail-Verteilung.

Also es gibt halt sehr, Leute wollen sehr unterschiedliche Bücher kaufen.

Es werden viele Bücher verkauft, aber von denen nur ganz wenige.

Und das ist halt blöd für einen Laden, der die Bücher halt physisch vorhalten muss.

Weil auch selbst wenn Bücher nicht so groß sind, ich kann halt in so einem Innenstadtbuchladen, kann ich halt irgendwie ein paar tausend Bücher haben.

Und dann ist halt irgendwie Schluss.

Und damit muss ich mir überlegen, welche das sind.

Aber wenn jetzt, also nehmen wir an.

Der hat überhaupt ein Zielpublikum, das heißt, ich weiß genau, hey, in mir kommen jetzt nur ganz viele alte, antiquarische, interessierte Menschen rein, dann sollte ich vielleicht dafür sorgen, dass in meinem Laden viele antiquarische Bücher sind.

Oder es kommen jetzt noch ganz viele Hippe-Leute rein, die wollen alle was über IT wissen, sollte ich vielleicht einen IT-Buchladen.

Ja, ja.

Aber selbst wenn du jetzt all diese Zielgruppen zusammensnimmst und da irgendwie den riesigsten, also das ist halt das Problem, wenn die Zielgruppe zu klein ist, dann lohnt sich das nicht.

Aber wenn sie, selbst wenn du jetzt einen riesigen Buchladen hast, in dem 300.000 Bücher passen, was ziemlich groß sein müsste, dann machst du immer nur trotzdem noch die Hälfte des Umsatzes von Amazon, weil Amazon macht halt nochmal so viel Umsatz mit dem ganzen Rest.

Das heißt, sie haben dann, sie können einfach viel besser skalieren, weil sie einfach viel mehr Bücher verkaufen.

Und ja, dagegen, ich wüsste nicht, dass es da irgendein Mittel gegen gibt.

Ich fürchte.

Was aber auch bedeuten würde, dass Amazon auch diese Minus 1 Bestellung annehmen müsste, weil das müssen sie auch irgendwo in einem riesigen Dager jedes Buch liegen haben.

Ja, müssen sie tatsächlich wahrscheinlich.

Oder sie müssen es halt on demand irgendwie drucken können oder so.

Gut, klar, sie müssen damit irgendwie umgehen.

Auch der stationäre Buchhandel geht ja da irgendwie dann damit um, so damit um, dass man dann halt Sachen da bestellt.

Zum Beispiel, hey Autor, schreib doch bitte noch meine neue Freunde.

Wir haben ja so ein paar Bestellungen, ja.

Aber ja, ich meine, du hast halt als stationäre Buchhandlung hast du ja keinen Vorteil mehr, wenn du dann auch wieder bestellst, weil dann machst du halt zwei Sachen und die eine, ja, und dann als Amazon hast du einfach einen strukturellen Vorteil fürchte ich.

Okay, dann kannst du.

Es ist cool, weil da können wir einfach mit einer Postgres-Lösung direkt so und dann ORM.

Genau.

Die interessante, also mit 300.000, also ein paar Millionen ist das überhaupt kein Problem.

Also da könnten wir auch, also ich würde sagen, so einen Markt wie Deutschland kannst du wahrscheinlich tatsächlich mit einer Datenbank und mit allen Büchern, die es überhaupt gibt, locker bedienen.

Das ist kein so großes Problem.

Wenn es jetzt nur darum geht, die Bücher zu verkaufen.

Aber wenn wir jetzt zum Beispiel eben sowas rauskriegen wollen wie, was sind denn eigentlich die Top 300.000 Bücher?

Wo kommt denn diese Zahl eigentlich her?

Ja, und überhaupt rauszukriegen, okay, wir machen die Hälfte unseres Umsatzes mit den nicht, mit Büchern, die nicht in den Top 300.000 sind, dann müssen wir nicht nur die Bücher speichern, sondern dann müssen wir halt auch speichern, zum Beispiel, welche Bücher gekauft worden sind und so, also eine Historie aller Bestellungen und so.

Und das ist dann halt unter Umständen viel, viel mehr.

Und dann wird es allmählich problematisch, weil dann haben wir unterschiedliche Use Cases oder unterschiedliche Abfragemuster.

Also wir haben zum Beispiel diese Transaktions.

Also das Lager, das einfach immer noch weiß, welche Bücher sind da und das schicken wir raus.

Oder dann haben wir immer jemanden, der macht Marketing.

Das System, das macht halt Bestellungen oder wir haben halt Anfragen, die Bestellungen machen oder solche Sachen wie, zeig mir alle Bücher in Seefacherromane oder so.

Aber diese Art von Anfragen wie, sag mir mal, wie viel Umsatz ich mit den nicht in Top 300.000 enthaltenen Büchern im letzten Jahr gemacht habe.

Das ist eine ganz andere Art von Anfrage.

Ja, während die Anfragen vorher, die machen immer nur auf kleinen Datenmengen in der Datenbank irgendwas, immer zeilenweise meistens.

Und oft ändern sie auch irgendwas oder schreiben irgendwas.

Gut, ein Großteil, immer noch die große Mehrheit wird Read-Anfragen sein, aber die beziehen sich normalerweise nicht auf wahnsinnig viele Zeilen, sondern immer nur relativ wenige oder wenige tausend Zeilen.

Und ja, eben operieren halt eure Zeilenweise während diese andere Anfrage, jetzt dieses wie viel Umsatz.

Ja, das ist halt dann nur noch eine Spalte aus den Bestellungen und dann auch geht es wahrscheinlich aber über lange Zeiträume, über ein Jahr, mehrere Jahre und dann halt über alle Bücher.

Das ist eine Anfrage, die geht halt über ganz, ganz, ganz, ganz, ganz viele Zeilen.

So, und jetzt beißen sich die, diese Abfragemuster beißen sich halt massiv.

Also weil das Problem ist, dass die Datenbank irgendwie gewährleisten muss, dass deine Sicht auf die Welt, also auf die Datenbank, konsistent bleibt, während die Anfrage läuft.

Die Anfrage läuft jetzt aber wahrscheinlich relativ lang.

Sie muss sich irgendwie alle Daten, die in der Datenbank liegen, oder Großteil davon muss sie sich angucken, wenn sie dir hinterher sowas sagen, eine Zahl geben will, wie viel Umsatz war das jetzt nur.

Und währenddessen werden aber Bestellungen abgearbeitet oder werden Dinge gemacht, Sachen an der Datenbank geändert, die jetzt aber nicht direkt durchschlagen können auf deine Anfrage, sondern da werden immer nur Kopien gemacht.

Und sozusagen, es wird dann halt ein Timestamp mit reingeschrieben, es wird halt, nein, das ist Multiversion Concurrency Control.

Multiversen!

Ja, Multiversion Control Concurrency Control, VCC.

Das heißt, die Datenbank ist halt in einem unterschiedlichen Zustand, je nachdem, wer gerade fragt.

Und für die Transaktionen, die eine Bestellung ausführen, ist jetzt in einem anderen Zustand als für dieses langlaufende Query.

Das Problem ist halt, je länger diese Query läuft, umso länger muss die Datenbank jetzt mehrere Versionen ihrer selbst aufrechterhalten, was dazu führt, dass du halt auch mehr Speicher brauchst und was halt eine komplizierte Geschichte ist.

Und das ist halt, ja, das Problem ist, wahrscheinlich wird man dann halt irgendwann sehen, man wird so mit einfachen Analysegeschichten anfangen und irgendwann wird man halt merken, so morgens um neun, wenn dann halt irgendwie die Business Intelligence-Abteilung irgendwie anfängt, wenn dann die Analysten sitzen und dann irgendwie, ja gut, ich weiß nicht, am Anfang wird man da sowas noch nicht haben, aber irgendwann hat man das vielleicht dann, wenn die halt ihre Analyse-Queries abschießen, dann wird plötzlich die Webseite langsam.

Ja, weil halt die Datenbank langsam wird, weil die Queries werden langsam, weil plötzlich muss die Datenbank irgendwie mit mehreren Zuständen irgendwie rumjonglieren.

Ja, das ist blöd.

Und dann muss man sich halt was überlegen.

Und das ist dann halt so der Moment, wo man dann sagen muss, okay, wir können das nicht mehr.

Es wäre schön, alles in einer Datenbank zu haben, aber es geht nicht.

Diese beiden Use Cases sind so unterschiedlich, dass man das leider nur dadurch ordentlich abgebildet kriegt, dass man das halt in unterschiedliche Systeme packt.

Und ja, also das eine nennt man auch irgendwie OHP, Online Transaction Processing.

Das ist halt sozusagen der Webseite, also Datenbank ist hinter einer Webseite, die irgendwie Bücher verkauft und prozessiert Transaktionen, Bestellungen.

Und der andere Teil nennt sich OLAP, Online Analytical Processing.

Und ist halt das so, wenn man das mal gehört hat, wenn Leute über Data Warehousing sprechen oder Data Warehouses oder so, das ist halt das.

Und genau, das sind beides meistens relationale Datenbanken, wenn man anfängt, jedenfalls.

Aber die sehen unterschiedlich aus.

Also die haben unterschiedliche Anfragen gestellt.

Analyseanfragen laufen länger, gucken sich viele Zeilen an.

Transaktionsanfragen sind oft kurz und ja, gucken sich wenige Zeilen an und da geht es auch darum, dass die Latenz relativ kurz ist.

Bei vielen Analyseanfragen ist es gar nicht so wichtig, dass die jetzt, ob sie jetzt eine Minute oder länger oder weniger lang laufen, ist gar nicht so entscheidend.

Und auch die Analysedatenbanken sind oft viel, viel größer, weil man halt historische Daten mit drin hat.

Was halt für eine Transaktionsdatenbank tödlich wäre, weil die bei der ist möglichst das komplette Working Set der Datenbank im Hauptspeicher, damit das halt alles schnell geht, damit die Latenz niedrig bleibt, damit halt die Webseite schön schön snappy irgendwie anfühlt.

Und bei den Analysedatenbanken ist aber unter Umständen wichtig, dass ich halt historische Daten da halt auch mit drin haben kann.

Und die werden dann halt vielleicht so groß, dass man das halt nicht mehr im Hauptspeicher halten kann.

Ja, aber

nichts für die Datenerfahrt.

Die Queries werden dann halt langsam, aber das ist halt möglicherweise wichtiger, historische Daten zu haben, als dass Querys halt schnell sind.

Und dann, äh, wenn sich eine Quary irgendwie ein paar Millionen oder ein paar zehn Millionen Zeilen anguckt, dann ist es eh nicht mehr schnell, selbst wenn es im Hauptspeicher ist.

Und ob es dann jetzt eine Minute oder zwei Minuten dauert, ist halt dann auch irgendwie wurscht.

Ja, genau.

Und dann hat man eben diese beiden unterschiedlichen Systeme und dann kriegt man halt aber auch genau diese Probleme, die man dann hat.

Wenn man mehrere Sichten auf die Welt hat oder den Status irgendwie eines, man hat jetzt keinen gemeinsamen Status mehr, sondern man hat jetzt den Status des Systems in unterschiedlicher Form in unterschiedlichen Datenbanken.

Das heißt, man muss jetzt zum Beispiel die Transaktionen, die irgendwie in einem einen System aufgelaufen sind, überführen in das Analysesystem.

Das macht man üblicherweise bei einem Prozess, der nennt sich ETL, Extract, Transform, Load.

Man halt die Daten, die einen interessieren, halt täglich oder so.

Also meistens fängt man sowas an wie, ja, das sind halt dann Jobs, die nachts laufen, wenn halt die Datenbanken sowieso nicht so unter Last sind, weil nicht so viele Leute einkaufen.

Liest man halt irgendwie alles, was einen so interessiert, dann aus der Transaktionsdatenbank aus.

Dann ist der Transformationsprozess halt sowas wie, ich muss die Daten in ein anderes Schema transformieren.

Und das ist halt sowieso Stern-Star-Schema oder Snowflake-Schema, je nachdem.

Das ist auch irgendwie gewisserweise normalisiert oder man kann auch sagen, die normalisiert, je nachdem.

Aber es ist halt auf jeden Fall anders.

Ist halt davon optimiert, dass ich bestimmte Arten von Analysen fahren kann.

Und lädt das Ganze halt in die Analyse-Datenbanksystem.

Für deine BI.

Genau.

Ja.

Und ja, das ist halt immer so ein bisschen, das ist halt ein bisschen fies alles.

Aber ja, bleibt dann halt nichts übrig, muss man irgendwie machen.

Wie würden wir das denn jetzt machen?

Wenn wir das in Python jetzt haben, jetzt haben wir ja irgendwie so ein neues System und jetzt haben wir eigentlich irgendwie, klasse, unser OLTP-Datenbank-System da aufgebaut mit den Transaktionen für unsere Webseite.

Was bauen wir denn da, damit wir jetzt so ein OLAP-Ding dran hängen können, weil wir die Analytics abteilen?

Ja, machen wir auch mit Postgres so ein Ding.

Also eine zweite Postgres-Datenbank, eben die erste packen.

Ja, genau.

Die halt ein bisschen anders aussieht, die hat dann vielleicht nicht ganz so viele Hauptspeicher, die hat dann aber dafür halt irgendwie mehr Plattenplatz und auch irgendwie Storage möglicherweise in unterschiedlicher Qualität.

Wenn man sagt, okay, vielleicht für die letzte Woche haben wir alle Daten noch im Hauptspeicher, ja, dann aber in den letzten Monaten oder die letzten sechs Monate haben wir die halt auf SSDs oder so, auf dem System, was halt noch schnell, weil der größte Teil der Queries geht natürlich auf Daten, die relativ aktuell sind.

Und dann ab einem Jahr oder so liegen die Daten dann vielleicht auf Platten, die halt dann eher langsam sind, aber da nur ein kleiner Teil der Querys halt so lange zurückgeht, ist es halt nicht so schlimm, wenn das ein bisschen langsamer ist.

Und diese Art von Queries muss dann halt ein bisschen warten.

Ja, und das ist halt ganz anders im Vergleich zu einem OLTP-System, wo man halt sagt, das muss alles mehr oder weniger im Hauptspeicher sein.

Und klar ist auch wichtig, dass es, dass Sachen schnell geschrieben werden.

Deswegen muss das, wo was hingeschrieben wird, muss halt auch sackschnell sein.

Also da würde man auch eher lieber dann schnelle SSTs nehmen, aber es ist halt nicht wichtig, viel mehr Plattenplatz zu haben, als man Hauptspeicher hat, weil das weniger ähnlich.

Ja.

Und genau, diese LTL-Prozesse sind dann halt irgendwelche Skripte, die dann halt irgendwie über irgendeine Task.

Das bedeutet natürlich dann, dass unser Intelligence-System also jetzt nicht sekundengenau funktioniert.

In dem Fall, weil wir halt immer wieder diese Jobs machen müssen.

Wenn wir das jetzt an was ganz anderes denke, weil ich nicht, Aktienkursanalyse oder so, wenn wir irgendwelche Portfolios, dann ist das natürlich dann doof, weil dann das nicht dem echten Stockmarket entspricht dann, sondern du müsstest halt dann jedes Mal neue Kopie machen, wenn man diese Analytics machen will.

Ja, genau.

Also natürlich, das ist tatsächlich ein Problem.

Und die Lösung dafür ist, dass man dann halt irgendwann nicht mehr so ETL in dem Sinne macht, dass man das halt irgendwie abends Batchprocessing macht, sondern dass man halt irgendwie so Streaming-Geschichten verwendet.

Halt, Apache Kafka und so ist halt etwas, was häufig verwendet wird.

Aber dann kommen wir später zu, weil das ist auch eine Geschichte, wo man dann, das wird halt eh erst dann relevant, wenn man dann nochmal ein gutes Stück größer geworden ist und man mit diesen traditionellen Data Warehouse-Geschichten auch nicht mehr klarkommt.

Unter Welt beherrschen müsst du die Card.

Ja, genau.

Dazu muss man dann schon mal noch ein bisschen, oder halt eine andere Art von Daten sammelt.

Also ich würde sagen, dieser klassische Bereich, ja, also selbst wenn man halt nur tagesaktuelle Daten hat, ist man damit wahrscheinlich viel besser aufgestellt, als jetzt wahrscheinlich viele stationäre Buchhändler oder so.

Selbst das wird einen schon da schon einen deutlichen Vorteil verschaffen.

Und ich denke mal, am Anfang ist es halt so, dass das ist halt das, was alle machen, wo man alle irgendwie anfangen, dass sie das halt tagesweise oder so batchmäßig erledigen.

Und genau, ja, da ist man halt irgendwie so bei diesem Data Warehousing-Thema.

Ich habe damit das mal irgendwann auch in den Shownotes verlinkt, gibt es einen schönen Essay, der heißt Data Warehousing for Caveman.

Aber das finde ich nach wie vor gut, ist auch relativ humorvoll.

Da geht es darum, der schreibt es aber auch so, ja, vielleicht interessiert es manche Leute irgendwie, wie man 300 Dollar die Stunde verdienen kann, indem man irgendwie die sensibelsten Daten von irgendwelchen Firmen massiert.

Muss ich sofort wissen, ja.

Genau, beim Freelance, das ist vielleicht gar nicht so interessant.

Ja, und also das ist auch ein Feld, das es schon lange gibt.

Ich habe das am Anfang aber auch nicht, ich habe zuerst nur diesen OTP-Use-Case gekannt und dann habe ich diesen, bin ich irgendwann auf diesen Essay gestoßen und dachte so, oh, das ist aber interessant.

Und daraufhin halt dann auch so angefangen, mich so ein bisschen mit der Tori-Hosyn-Kram zu beschäftigen.

Aber es ist auch ein sehr interessantes Thema.

Also der entscheidende Punkt ist im Grunde, dass man halt solche Abfragen machen können möchte, wie, also wie unterscheidet sich denn jetzt, keine Ahnung, das Volumen der verkauften Bücher in einer bestimmten Kategorie, nachdem ich irgendeine Werbeaktion gemacht habe, ja.

Oder A-B-Tests, ja.

Ich habe jetzt irgendwie manchen Usern eine bestimmte, ja, die haben halt ein Design gesehen, das ein bisschen anders aussah oder halt ein bisschen anders.

Oder alle Leute, die letzte Woche gekauft haben für ein bestimmtes Produkt, die bekommen jetzt einen besonderen Gutschein, der für drei Tage gültig ist oder sowas.

Ja, und genau, ich möchte hinterher gucken, was ist denn dann passiert, war das jetzt erfolgreich oder nicht?

Wie erfolgreich war denn das?

Und dafür muss ich halt bestimmte Arten von Anfragen, die ansonsten keine Rolle spielen können, gut machen können.

Und dafür habe ich halt so eine Struktur, ich habe eine Faktentabelle und dann drumherum Dimensionstabellen, in denen halt solche Sachen drin stehen wie, ja, das war jetzt ein User, für den ich diese Version der Webseite angezeigt habe oder das hier, also man hat zum Beispiel sowas wie, daran kann man es vielleicht ganz gut verstehen, Time ist halt eine Dimension.

Und in der Faktentabelle, also Fakten wären sowas wie Bestellungen, ist halt sozusagen Time nicht etwas, jetzt ein Zeitstempel oder so, der da reingeschrieben wird, sondern da ist halt, das ist halt eine ID, ein Fremdschlüssel.

Und der zeigt halt in eine Time-Dimension.

Da ist halt eine Dimensionstabelle, in der drin steht, was diese Zeit bedeutet.

Und dann stehen da eben solche Dinge dran wie, naja, also, auch da wiederum, kann sein, dass da noch, also da steht nicht direkt ein Zeitstempel, sondern da steht dann dran, also das war ein Werktag.

Das war ein Feiertag in folgenden Bundesländern.

Das war, keine Ahnung, das war Sommer, ja.

So dass ich dann halt solche Abfragen machen kann wie, wie ist denn der Verkauf der Bücher in dieser Kategorie im Sommervergleich zu Winter?

Und dadurch, da ich diese Information, das ist jetzt Sommer, halt direkt an dem Zeitdings dran habe, kann ich halt Abfragen machen, die sehr effizient alles rausfiltern, was halt irgendwie Sommer ist und so.

Aber solche Abfragen machen halt in dem OTP-Teil oder wenn ich jetzt eine Webseite machen überhaupt gar keinen Sinn.

Das heißt, ja, die Schemata sehen dann halt ganz anders aus.

Ja.

Wenn einen interessiert, wie das wirklich so Orneti funktioniert, finde ich, dieser Data Warehousing for Caveman Essay ist ein schöner Start.

Aber da gibt es auch jede Menge, kann man sich durchlesen, wie das so klappt.

Ja, genau.

Achso, richtig, genau.

Da haben wir jetzt schon mal ein bisschen über den Analyseteil gesprochen, aber wir haben natürlich auch ein Problem, wenn jetzt Leute immer mehr Zeugs kaufen, dass irgendwie halt unsere Datenbank halt vielleicht irgendwann ein bisschen langsamer wird, nicht mehr genug Transaktionen prozessen kann.

Ja, was macht man da?

Muss er halt optimieren, das ist halt auch oft ein wichtiger Teil und es ist auch nicht so einfach.

Die einzige Datenbank, für die ich das wirklich mal gemacht habe, so war ich MySQL.

Ich verwende heutzutage eher Postgres, aber da habe ich dann auch mal so einen Optimierungs-MiosQL-Porformance-Optimierungskurs besucht.

Und das ist ein schönes Zitat, also Chris Künthop hat den damals irgendwo in München durchgeführt, damals hat er bei MySQL gearbeitet.

Und ein Satz, der mir auch in Erinnerung geblieben ist, immer so, ja, wenn man Datenbank Performance optimieren will, ja, also OLTP, dann gibt es da eigentlich so im Wesentlichen drei Sachen, die man tun kann, um eine Datenbank schnell zu machen.

Das erste, was man eigentlich immer machen kann, das funktioniert auch fast immer, das ist super, man kann einfach mal ein bisschen mehr Hauptspeicher reinstecken in die Datenbank.

Das ist schon mal auf jeden Fall schneller, das ist immer gut.

Und wenn das irgendwie nicht mehr so richtig reicht, eine zweite Geschichte, die man auch immer tun kann, auch sehr gut hilft, ist, man kann einfach noch ein bisschen mehr Speicher reinstecken in die Datenbank.

Selbst wenn man dann an die Grenze gekommen ist, das letzte Mittel, zu dem man greifen kann, wenn das auch nicht hilft, ist halt, man könnte einfach ein bisschen mehr Hauptspeicher in die Datenbank reinsteigen.

Okay, okay.

Wie viel Hauptspeicher hat denn dann so eine große Datenbank?

Ja, so viel wie halt geht eigentlich.

Also es kommt aber darauf an, wie viel du benötigst.

Also wenn du jetzt irgendwie ein paar tausend Artikel hast, die du auf einer Webseite verkaufen willst, dann ist egal, ja.

Da kommst du halt mit einem, weiß ich nicht, mit der Beliebigkeit, kannst du auf dem Raspberry Pi kannst du das machen.

Das ist wurscht.

Aber wenn du jetzt, also sagen wir so, wenn ein Working Set der Datenbank, also die Menge der Daten, die halt auf der Platte liegen, wenn die Datenbank runtergefahren ist, wenn das halt 30 Gigabyte hat, dann sollte deine Datenbank mindestens mal 30 Gigabyte haben, ja so 64 vielleicht.

Hauptspeicher.

Weil es gibt halt auch noch diverse Strukturen, die im Hauptspeicher gehalten werden, die man halt auch braucht.

Ja.

Und dann ist halt das Limit eigentlich nur, und also sagen wir so, das ist halt viel, ja.

Also wenn man jetzt irgendwie, nehmen wir an, wir haben das, was heute so ein Sweet Spot ist, sind es halt vielleicht 256 Gigabyte oder so.

Hauptspeicher, da geht eine ganze Menge rein.

Also es ist halt für mich schwer vorstellbar, welche Systeme, die Transaction Processing machen, dann mehr Hauptspeicher benötigen.

Oder mehr Daten haben, die sie jetzt unbedingt im Hauptspeicher halten müssen.

Das gibt es kaum.

Also, ja gut, es gibt schon.

Also wenn man jetzt an sowas denkt wie Google, man indiziert das Web und möchte halt so eine Echtzeit Suchabfragen über alle Webseiten machen, das geht nicht mehr, das ist klar.

Aber so viele.

Also so groß muss man erstmal werden.

So groß müsste man werden.

Also Amazon fällt da bestimmt auch nicht rein.

Also Amazon hat, also na gut, Amazons Teil, der einen jetzt mit Produkten versorgt, ja, der diese Webseite, das wird nicht so groß sein.

Die haben andere Teile, die halt dann unter Beständen sehr groß geworden sind, aber ja, das kriegst du eigentlich alles locker in einer Datenbank unter.

Also die haben dann halt ein anderes Problem.

Amazon wird das Problem bekommen, dass sie halt mit der Schreiblast nicht mehr klarkommen, aber das könntest du alles irgendwie in den Hauptspeicher von so einer Datenbank packen.

Also ich würde sagen, für fast alle Anwendungsfälle heutzutage ist das halt groß genug.

Ab 256 Gigabyte wird es ein bisschen schwierig.

Also man kann auch einen Terabyte Hauptspeicher irgendwie in Rechner stecken, das kostet irgendwie weniger als 10.000 Euro heutzutage, ja, also das geht auch.

Es wird dann halt, wenn man so wirklich so wahnsinnig viel Hauptspeicher drin hat, dann kriegt man halt ein bisschen Probleme mit der Architektur von, das ist ja so ein bisschen PC-basiert und so viel Hauptspeicherbandbreite hat man da ja nicht.

Und das wird dann irgendwann, man muss halt die ganzen Prozessoren auch irgendwie mit Daten versorgen, ja, und dann, wenn man jetzt da irgendwie, weiß ich nicht,

da fährt dann kein Bus hin.

32 Prozessoren oder 64 oder sowas, so irgendwann ist dann halt, also der Sweetspot ist, würde ich sagen, heute eher so bei, weiß ich nicht, irgendwie 64 Prozessoren oder sowas und 256 Gigabyte Hauptspeicher und so.

Aber das, also egal, also vielleicht geht auch noch ein Terabyte, ich habe keine Ahnung.

Sagen wir mal so, für die meisten, aller, aller, allerdings alle reicht das alles vollkommen aus.

Und es ist ein sehr guter Tipp zu sagen, also jetzt, wenn du tatsächlich irgendwie ein Working Set von 30 GB halt hast, jetzt kaufen ich nicht eine Datenbank, die jetzt 8 Gigabyte hat, dann hast du ein Problem.

Dann bist du gleich mal irgendwie mehrere Größenordnungen langsamer, als wenn du das in den Hauptspeicher packen würdest, ja, und kriegst halt einen Haufen Probleme, die du sonst einfach nicht hättest.

Ja, das war früher alles noch viel schlimmer, als es einen riesigen Unterschied gab zwischen sozusagen permanentem Storage, also rotierendem Rost, ja, so Hardisks und Hauptspeicher, da war der Unterschied so 1 zu 10.000 oder so Geschwindigkeitsunterschied.

Das ist jetzt nicht mehr ganz so schlimm, wenn man SSDs hat, aber es ist immer noch ziemlich schlimm.

Also es ist immer noch ein Riesenunterschied.

Und daher, ja, das will eigentlich, dass die heißen Daten im Hauptspeicher sind.

Ja, genau.

Das ist halt ein Ansatz, um das zu optimieren.

Dann hat man oft das Problem, man hat halt so eine Asymmetrie zwischen Lese- und Schreibqueries.

Und selbst wenn man mit so einer Datenbank halt irgendwie ein paar tausend Queries pro Sekunde abfeiern kann, irgendwann gerät man in eine Konkurrenz zwischen Schreibqueries und Lesequeres, wenn man jetzt nur eine Datenbank verwendet und das ist halt irgendwie schlecht, weil man möchte eigentlich immer in der Lage sein, weil man braucht ja eine, man darf eigentlich nur eine Datenbank haben, auf die man schreibt.

Also wenn man mehrere Datenbanken hat, von denen man liest, ist nicht so schlimm, das geht.

Aber man kann halt nicht so richtig gut mehrere Datenbanken haben, auf die man schreibt, weil man ja diesen zentralen Punkt, an dem der Status gehalten wird, behalten möchte.

Also wenn wir scheinbar auf dieselbe Stelle schreiben

zum Beispiel.

Ja, genau.

Also was man jetzt machen könnte, wenn man zu viele Leseanfragen hat, man verteilt die dann halt auf sogenannte Slave-Datenbanken.

Das heißt, man hat halt so eine Master-Slave-Architektur, man hat eine Master-Datenbank, von der man lesen und schreiben kann, von der man lesen kann und auf die man schreiben kann.

Und es gibt halt eine Reihe von Slave-Datenbanken, von denen man nur lesen kann, auf die man nicht schreiben kann.

Wie oft wird denn da geslaved?

Also wie oft die da Slave denn aktualisiert auf den Master?

Ja, da gibt es dann Mechanismen für.

Also der Master schreibt halt irgendwie ein Log, das Log wird irgendwie an die Slaves übertragen und die vollziehen dann sozusagen die Transaktionen, die der Master gemacht hat, halt nach.

Das ist meistens wahrscheinlich instantan, mehr oder weniger.

Bei viel Last oder wenn er halt eine große geografische Differenz ist, also wenn es halt irgendwie über eine Atlantik oder Pazifik geht oder so, klar, dann hast du halt Zeitunterschiede oder halt auch wenn die Last so groß ist, dass die Slipes nicht mehr gut hinterherkommen, dann hast du natürlich, dann hast du eventuell so ein bisschen Leck von vielleicht ein paar Sekunden oder vielleicht auch mal eine Minute oder sowas.

Aber es gibt halt viele Anfragen, für die ist das egal.

Also viele Leseanfragen, oft cached man das ja auch dann nochmal irgendwie im Hauptspeicher.

Im Redis oder Memcache oder so und sagt halt, ja, also dieses Ding hier kannst du fünf Minuten lang cachen.

Da ist es ja dann auch egal.

Und bei den Anfragen, die auf Slaves gehen, ist es auch so oft so.

Es ist halt wurscht, also so oft ändern sich Dinge halt nicht, wenn irgendein Count nicht so richtig stimmt oder so.

Naja, nicht so schlimm.

Es gibt Dinge, bei denen das schlimm ist, aber kommen wir gleich noch zu.

Da muss man das halt anders machen.

Aber bei vielen Sachen ist es halt nicht so wirklich schlimm und daher kann man das gut aufteilen.

Man kann halt dann die Leselast auf die Slaves sozusagen transferieren.

Und dann gibt es halt bestimmte Abfragen, also gerade wenn man jetzt kurz davor ist, eine Bestellung zu machen oder so, wo man dann schon im Code weiß, so, okay, jetzt gibt es hier gleich eine Transaktion oder so.

Und dann macht man auch die Leseanfragen auf den Master, damit man da halt eben nicht das Problem hat, dass man eventuell Daten sieht, die eine Minute alt sind.

Aber da das die allermeisten Anfragen ja gar nicht sind, sondern die meisten Navigationsanfragen, wenn ich jetzt in Kategorien rumklicke oder irgendwelche Filter auswähle oder nach irgendwas suche oder so, diese ganzen Anfragen beziehen sich auf Daten, die sich jetzt gar nicht so häufig ändern.

Das kann alles auch eine Minute alt sein, das ist wurscht.

Und erst wenn ich halt eine Bestellung mache, dann muss ich halt zusehen, dass ich aktuelle Daten sehe, wie zum Beispiel ist das Buch noch auf Lager oder so.

Und diese wenigen Anfragen, die halt dann aktuell sein sollten, die gehen dann direkt an den Master.

Und das kann man halt im Code sagen.

Man kann halt sagen, okay, an dieser Stelle bitte eine Verbindung auf den Master und nicht auf den Slave.

Und die Schreibanfragen müssen dann halt auf den Master gehen.

Weil man ja nur an einer Stelle schreiben will.

Und mit dieser Architektur kommt man relativ weit.

Also das ist eine Geschichte, das ist auch so ein klassischer Lamp-Stack-Architektur, Wikipedia-Seite so aufgebaut.

Du hast jetzt gerade noch zwei Sachen gesagt, die vielleicht nochmal kurz vor anders.

Einmal so von Redis einmal eben gesprochen.

Und gerade vom Lamp-Stack.

Also einmal vielleicht kurz erklären, was das drin ist.

Ja, Redis ist auch so eine In-Memory-Datenbank, eher so ein Key-Value-Store, hat noch ein paar Zusatzfunktionen, es ist eine Message-Queue drin, es kann teilweise sortierte Listen und sowas auch halten, aber es ist ein bisschen, kann ein bisschen mehr als Memcache D.

Und Memcache D ist rein so, du hast ein Key und kriegst halt dann irgendwie Value zurück und wird im Hauptspeicher gehalten, deswegen ist es schön schnell.

Wurde popularisiert auch Memcache D, vor allen Dingen durch den Lamb-Stack.

Lamb ist einfach Linux-Apache, MySQL PHP.

Und einige der großen Webseiten, die das halt benutzt haben oder weiß nicht, ob sie das noch benutzen, keine Ahnung, ist halt Wikipedia.

Wir haben auch immer schöne Artikel darüber gehabt, wie sie ihre Systeme aufbauen.

Also es ist ja auch Wikipedia-Claubt, die sind auch mit Sicherheit immer noch in den Top 10 der weltweit trafficstärksten Seiten.

Und haben halt auch viel dazu veröffentlicht, wie ihre Architektur aussieht.

Und die haben ja halt auch genau das, die meisten Sachen sind Leseanfragen, aber manchmal wird halt auch was geändert oder geschrieben.

Und die machen das halt mit MySQL und vielen Slaves und ja, extensiver Verwendung von Memcache zum Cachen von irgendwelchen gerenderten Fragmenten und Daten, für die man jetzt nicht nochmal eine Query machen möchte.

Was wäre denn jetzt der neueste Stack, würdest du sagen, den man jetzt verwenden sollte, um das Anfänger?

Ja, das kommt halt darauf an, wenn man eben PHP mag.

Ja, kann man das auch immer noch machen, wobei ich jetzt nicht genau weiß, ob das alles immer noch so populär ist.

Memcash die, glaube ich, ist so ein bisschen auf dem Weg nach draußen.

Wahrscheinlich würde auch in dem Umfeld eher heutzutage Redis verwendet.

Aber jetzt im Python-Umfeld würde ich sagen, ja, da ist halt, hat man so grob die Wahl zwischen, also es gibt natürlich noch viel mehr und es gibt natürlich auch gute Gründe, andere Sachen zu verwenden, aber so die populärsten Geschichten sind halt Django und Flask.

Und eben als In-Memory-Cache ist bei beiden eigentlich Rede sozusagen das, was verwendet wird.

Datenbank, eigentlich würde ich auch sagen, Postgres wird bei beiden verwendet.

Man kann auch was anderes nehmen natürlich.

Es gibt auch Leute, die Django mit MongoDB verwenden.

Das geht.

Es gibt auch sogar valide Use Cases dafür.

Es gibt auch Leute, die Flask irgendwie mit, weiß ich nicht, CouchDB mit allen möglichen Dingen verheiraten.

Aber so als womit ich anfangen würde, ist auf jeden Fall Postgres und dann halt eben SQL Alchemy bzw.

Django ORM.

Und Rede ist genau als im Memory Cache und ja, wahrscheinlich braucht man auch noch ein Message Que-System.

Ist aber dann auch schon, also dann gibt es noch so ein paar Sachen, die man braucht.

Was ist denn die Message Queue, vielleicht erstmal?

Ja, also man hat oft so Dinge, wo man dem User möglicherweise etwas direkt, einen direkte Antwort geben will.

Aber es ist halt ein Job, der dann irgendwie länger dauert, wie

unser Buchstore wäre das.

Ein Buchstore, sowas wie, jemand fliegt ein neues Buch ein oder so.

Na gut, warte mal, lass mal überlegen, das ist kein gutes Beispiel.

End-User, was könnte der denn tun?

Ja, zum Beispiel du verfasst einen Kommentar jetzt oder eine Bewertung für irgendeinen Artikel.

Und du möchtest, wenn der jetzt auf Abschicken drückt, der User, dass er sofort seinen Kommentar unter dem Artikel sieht.

Aber in Wirklichkeit willst du den ja vielleicht noch prüfen, also wenn das jetzt irgendwas Populäres ist.

Wir wollen da sowas in der Weißbaut-Taste oder so.

Das könnte jetzt hässlich geworden sein.

Oh, das tut mir leid, muss ich mich entschuldigen.

Ein bisschen erkältet.

Ja, wenn, also eigentlich möchte man halt, wenn jetzt zum Beispiel ein Artikel ist, der häufig verkauft wird, ja, und wenn jemand schreibt, irgendwie, dieser Artikel ist voll scheiße, keine Ahnung.

Das hat ja dann unter Umständen direkt Konsequenzen.

Oder es macht am besten noch irgendwie einen Mitbewerber, macht irgendwas Fieses, ja, dann will man das möglicherweise nicht, dass das sofort allen sichtbar wird, sondern muss halt irgendwie erst irgendwie ja irgendeine Redaktion drauf gucken oder so.

Aber das ist halt nicht etwas, was man dem User anzeigen möchte.

Also man hat dann halt sozusagen etwas, so zwei Prozesse, die voneinander so ein bisschen entkoppelt sind.

Der User drückt auf Speichern, sieht seinen Kommentar oder seine Bewertung und im Hintergrund gehen aber dann auch so Tasks los wie, oh, das ist hier an der Stelle, wo jemand mal drauf gucken sollte.

Aber das geht halt dann auch nicht in Echtzeit, sondern das wird dann halt in irgendwie so eine Que, in eine Warteschlange eingereiht.

Dann gibt es eine Redaktion, die hat dann halt diese Jobs, muss sich halt irgendwelche Kommentare an sensitiven Stellen oder so angucken und die dann abarbeiten.

Aber das ist halt sozusagen der, dass diesen Job in die Warteschlange tun und dieser menschliche Prozess mit menschlicher Interaktion, das ist jetzt nicht mehr Teil von dem Web-Request.

Das heißt, der Teil muss irgendwie entkoppelt sein.

Das heißt, der Web-Request ist ja irgendwie vorbei.

Aber dieser Web-Request löst dann halt irgendwie, schreibt dann halt irgendwie diesen Job in die Que.

Solche Sachen hat man oft.

Auch wenn sich, auch genau, ha, das ist ein gutes Beispiel, das ist mir jetzt eingefallen.

Vielleicht möchtest du, dass, wenn du jetzt in der Suche nach irgendwas suchst, haben Produkte halt auch vielleicht Bewertungen finden, in denen jemand über das Produkt gesprochen hat oder so.

Das heißt, der Text deiner Bewertung muss indiziert werden von der Suchmaschine.

Aber das geht halt auch nicht in Echtzeit, sondern das macht die halt vielleicht nur alle tausend Bewertungen oder so wird neu indiziert oder so, weil ja.

Und dann wird halt auch so ein Task erzeugt, für so, das hier muss ja noch mit initiiert werden, aber es wird nicht sofort indiziert, weil das ist halt etwas, was lange, eine Operation, die lange dauern kann.

Und man möchte ja nicht, dass der Web-Request dann so lange dauert, wie die Operation dauert, sondern man sagt, okay, man gibt dem Web-Rest, so ist es okay, dein Kommentar wurde gespeichert und hat dann aber noch diesen zusätzlichen Task erzeugt, der dann irgendwann später ausgeführt werden muss.

Und dafür braucht man diese Task-Ques, die halt, wenn man ein komplexeres Web-System hat, dann braucht man sowas halt, weil solche Fälle halt immer wieder auftreten.

Ja, kann man aber Redis auch für verwenden.

Also was für Django ist halt, was häufig verwendet ist.

Salary kann ich nicht unbedingt empfehlen, ist irgendwie eher schmerzhaft.

Ja, die darunter liegenden Geschichten sind oft sowas wie RabbitMQ oder so ein allgemeines Protokoll wie AMQ, irgendwas, weiß ich nicht genau.

Ja, aber das ist nochmal ein ganz eigenes Feld mit diesen ganzen Message-Ques.

Ja, genau.

Master Slaves-Architektur hatten wir jetzt.

Irgendwann kann natürlich auch sein, dass das nicht mehr reicht.

Und dann müssen wir halt irgendwie die Datenbank auftrennen.

Also wenn zum Beispiel gerade die Schreibblast groß genug geworden ist, dann geht das halt alles nicht mehr.

Und dann kann man halt die Datenbank muss man dann auftrennen, das ist furchtbar, weil dann verliert man eine ganze Menge der Vorteile, die man halt hat, wenn man eine Datenbank hat, eben referenzielle Integrität, irgendwie, dass Transaktionen isoliert sind.

Diese ganzen Geschichten, das geht alles nicht mehr so wirklich und das muss man dann alles in der Applikation machen, in der Applikationslogik.

Und das macht alle Dinge unfassbar viel komplizierter.

Deswegen sollte man das möglichst nicht tun.

Also wenn einem mal verkauft, irgendwie.

Nicht so groß werden.

Unser System ist super, weil das schadet automatisch oder sowas.

Also das ist nicht etwas, was man haben will.

Also wenn man klein genug ist, dass man das nicht braucht, sollte man das nicht machen, weil das bedeutet halt, dass man diesen ganzen Dinge, die einem sonst die Datenbank quasi schenkt, selber machen muss in Applikationscode.

Und das ist halt sehr, sehr schwierig.

Aber manchmal geht es halt leider nicht anders, dann gibt es halt zwei Möglichkeiten.

Man schadet irgendwie horizontal.

Also man sollte solange, man nennt es Upscaling, solange wie möglich die Maschine größer machen und mehr Hauptspeicher reinstecken.

Wenn das halt dann irgendwann tatsächlich nicht mehr geht, dann muss man halt entweder horizontal oder vertikal schaden und das ist halt aufteilen.

Das heißt horizontal

mehrere Maschinen, die die gleiche Datenbank benutzen?

Nee, die gleiche Datenbank würde dir einem ja nicht helfen, wenn es zu viel muss die Datenbank halt irgendwo trennen.

Und die Frage ist, wo trennt man jetzt auf?

Man kann halt entweder innerhalb von Tabellen die Zeilen auseinandertrennen.

Das wäre eben horizontal skalieren, dass man sagt, okay, alle Bücher, die mit Buchstaben A anfangen, kommen jetzt auf die Datenbank.

Alle Bücher mit Buchstaben B bis F kommen auf die Datenbank.

Oder so regional Queries trennen, von wo kommt die denn jetzt oder sowas?

Ja, regional kann man natürlich auch trennen.

Das ist dann nochmal eine andere, wäre nochmal eine andere Geschichte, könnte man auch machen.

Das heißt aber, das wäre quasi horizontales Schaden auf den Usern.

Nach Regionen eben.

Das wird also, dass man, also meistens würde man auf Usern schaden irgendwie tatsächlich, ja.

Wenn man sagt, was ist das von User?

Und dann entweder regional oder halt irgendwie sonst irgendein Hash-Wert oder so.

Und vertikal wäre halt, man trennt nach Tabellen auf.

Das heißt, man sagt, okay, wir haben ja ein System, das kümmert sich um die Bücher, wir haben ja ein System, das kümmert sich um die User, wir haben ein System, das kümmert sich um Lagerhaltung.

Das wäre halt, man teilt dann nicht quasi in den Zeilen, sondern man teilt halt an den Tabellengrenzen.

Ja, man macht natürlich so vollständig Abfragen dann ein bisschen langsamer, oder so?

Ja, das Problem ist dann halt, dass man mehrere Systeme fragen muss, wenn man jetzt irgendwie was machen möchte.

Also wenn man jetzt die Amazon-Seite anzeigen möchte, dann muss man halt unter Umständen viele Systeme fragen.

Tatsächlich ist es etwas, was Amazon wirklich passiert ist.

Irgendwie, ich glaube 2008, 2009 gab es dann auch irgendwie, haben sie Artikel drüber geschrieben.

Damals nannte sich das nicht, also heute läuft das Ganze unter dem Stichwort irgendwie Microservices oder so, so nennt man das dann, dass man halt Teile eines Systems in kleinere Services auslagert.

Damals nannte sich das anders, war aber quasi eine gleiche Idee, nannte sich Service-Oriented Architecture.

Und Amazon hatte das Problem, dass sie auf der Hauptseite, also wenn du einfach nur Amazon.com eingegeben hast, dann wurde dir halt das Ding aus, die Seite ausgeliefert.

Aber damals war es halt schon so, dass da so viele Zeugs drin waren.

Also dann werden dir irgendwelche Empfehlungen angezeigt, da wird dir irgendwas angezeigt, wie viele Zeugs in deinem Warenkorb ist.

Und das ist einem zwar nicht so bewusst, aber das ist wirklich viel Zeug bei Amazon.

Und sie hatten das Problem, sie machen ungefähr 300 SQL-Statements, wenn du die Seite anguckst.

Oder ein paar hundert, ja.

Da das irgendwie, da die irgendwie nur sequentiell ausgeführt wurden, macht das halt die Latenz hoch, weil synchron sequentiell, das heißt, die ganzen Latenzen addieren sich auf.

Das heißt, allein bis die ganzen SQL-High-SQL-Statements abgearbeitet sind, vergehen ein paar hundert Millisekunden und die du einfach warten musst.

Und das ist halt scheiße.

Man weiß ungefähr so, weiß ich, pro 100 Millisekunden droppt deine Conversion 10% oder so, ich weiß nicht.

Nee, wahrscheinlich weniger, aber.

Also auf jeden Fall ist halt nicht so gut.

Das heißt, du kannst ja ausrechnen, wie viel mehr Umsatz du machen würdest, wenn du das irgendwie schneller ausliefern könntest.

Ja, und dann haben sie sich halt gesagt, okay, das müssen wir irgendwie anders machen.

Dann haben sie das halt in Services aufgeteilt und haben sie gesagt, okay, wir haben ja den Recommendation-Service, wo dann die, wo sich die Webseite per JavaScript irgendwie macht irgendwie einen XHTP-Request oder so und holt sich dann die Recommendations von diesem Service.

Und dann haben wir den irgendwie, keine Ahnung, Basket-Service für deine Einkaufskorb oder so.

Und da ist halt das Ding, holt sich halt, was für Dinge liegen da momentan gerade drin und ja.

Genau, und das, das haben die damals so gemacht.

Ja, und dann, das geht dann natürlich alles irgendwie mehr oder weniger, auch nicht so total parallel, aber mehr paralleler als vorher.

Und dann kann die Webseite insgesamt deutlich schneller sein.

Ja, genau.

Heute würde man sagen, Microservices, du hast halt ein Microservice pro irgendwie Ding, was du irgendwie da machst auf der Webseite.

Und die komplette Seite aggregiert nur noch irgendwie die Daten aus all diesen Services.

Ja, damit kriegt man das tatsächlich in den Griff, wenn man so ein riesiges Ding hat und viele unterschiedliche Sachen und das nicht mehr in einer Datenbank passt, dann kann man das so machen.

Es ist aber nicht so, dass man das machen sollte.

Also solange man das anders machen kann, solange man das mit einer Datenbank hinkriegt, sollte man das mit einer Datenbank machen, weil das ist viel, viel angenehmer.

Also Microservices sind halt dann, man schiebt dann halt einen Haufen der Komplexität in eine andere Richtung.

Man hat dann plötzlich Architekturkomplexität, man hat plötzlich im Ops-Teil von DevOps wird es plötzlich viel schwieriger, man muss halt das alles irgendwie maintain.

Man muss halt plötzlich, wenn man jetzt sagt, okay, ich update jetzt diesen Service, also dann hängen da halt andere Dinge von ab unter Umständen.

Dann habe ich halt, ich kann, ja, sag mal so, wenn man das halt irgendwie so schön hat, Master Slave-Architektur, Load Balancer davor, vor den Datenbanken, ein paar Frontends, dann, selbst da ist es schon kompliziert, wenn ich jetzt irgendwie zum Beispiel ein Schema ändern möchte oder so, was ich im Produktivbetrieb dann vielleicht nicht mehr tun kann, weil die Datenbank viel zu langsam liefe, weil wenn ich das Schema ändere, muss ich bei den Tabellen, die ich ändere, halt unter Umständen eine Kopie der Tabellen mehr oder weniger mache.

Das heißt, ich muss halt möglicherweise doppelt so viel Daten im Hauptspeicher halten, was halt vielleicht nicht geht.

Das heißt, ich muss vielleicht sowas machen wie, ich tausche die Datenbank aus.

Ich mache eine Kopie der Datenbank und die Datenbank mit dem neuen Schema, stelle ich einen ins neuen Master rein und so.

So oft hat man dann so Sachen wie, oder wenn man die Software updatet, man nimmt halt Sachen Rechner aus der Verteilung, einem Load Balancer, updatet den oder die Hälfte davon und die andere Hälfte läuft noch auf der alten Software und dann schaltet man halt um oder so.

Solche Sachen kann man machen.

Und das ist, das geht noch, das ist auch dann schon kompliziert, weil man muss sich dann halt Gedanken machen, wie man das tut.

Und man muss halt irgendein System haben, das das unterstützt, dass man das automatisch machen kann, sodass man halt nicht jedes Mal, wenn man irgendwie sowas wie eine Schemaänderung macht oder wenn man halt irgendwie eine komplexere Änderung im Applikationscode in den Frontends hat, dass man da halt dann irgendwie jemand setzen muss und das dann von Hand macht, das sollte nicht so sein, sondern man sollte halt auf den Knopf drücken und sagen, okay, jetzt rollen wir das mal aus und dann passieren diese Prozesse, die dafür nötig sind, automatisch.

Wenn man Microservices hat, wird das Ganze viel schlimmer.

Das ist halt da nicht so, dann hat man viel komplexere Abhängigkeiten zwischen den Geschichten und dann wird dieses ganze Obst-Thema halt richtig ätzend.

Auch Skalierung wird richtig ätzend, weil dann willst du halt, wenn du halt, ja, in so einer klassischen Architektur hast du nur wenige unterschiedliche Arten von Maschinen, die halt irgendwas machen.

Du hast halt Datenbanken, du hast halt irgendwie Redis oder sowas, du hast halt Frontends, vielleicht doch vorne irgendwie Webserver, die SSL-Terminierung machen oder so, aber das war's im Grunde.

Also du hast nicht so wahnsinnig viele unterschiedliche Dinge.

Beim Microservice hast du halt vielleicht hundert unterschiedliche Arten von Microservices, die du unterschiedlich skalieren musst, wo du aufbauen die Sachen aufpassen musst, das ist alles furchtbar.

Also geht.

Also man kriegt damit da halt Sachen in den Griff, die dann halt, wenn man mit diesem Muster eine Datenbank, in der die Wahrheit drin steht, nicht mehr, wenn das nicht mehr ausreicht, kann man das dann halt so in den Griff kriegen, aber es ist halt dann schon schlimm.

Ja.

Genau.

Okay, jetzt sind wir schon ganz schön groß.

Das heißt, wir müssen noch ziemlich viel beachtet haben.

Okay.

Genau.

Oh, das habe ich.

Ja, was haben wir denn?

Ja.

Also ich auch schon guck gerade in die Liste, was wir alles haben und was noch nicht.

Genau.

Das ist nämlich tatsächlich relativ viel.

Ja, ja, ja, ja.

Oh mein Gott, ich weiß nicht, wie lange, wie lange sind wir denn schon dran?

Ich glaube, wir sind über zwei Stunden schon, oder?

Oder ganz?

Nein, noch nicht ganz.

Na gut,

dann ist harmlos.

Naja.

Achso, genau.

Was ich hier noch ein Punkt war, es können aus dem Analysesystem auch Sachen wieder zurücklaufen.

Zum Beispiel gibt es halt diverse Sachen, die gelockt werden, die dann aber trotzdem für die Transaktionen wieder eine Rolle spielen.

Wieso etwas?

Das hatten wir noch gar nicht.

Jetzt auch die Suche, ja, am Anfang, man braucht ja auf jeden Fall, wenn man irgendwie so eine E-Commerce-Seite hatte, irgendwie eine Suchmaschine, wo man irgendwie nach Büchern suchen kann oder so.

Das geht auch tatsächlich mit Postgres direkt.

Voll gut.

Hat einen integrierten Volltexindex im man möchte halt auch so eine Facette in Navigation nennt man das haben, wo man, wenn man jetzt nach irgendwas gesucht hat, hat halt eine Ergebnisliste, dann möchte man einschränken nach Kategorien oder nach, weiß ich jetzt, wenn es nicht um Bücher geht, sondern um Elektronik oder so, kann man vielleicht noch Hauptspeicher oder Videorekorder VHS oder Betamax, ja, so möchte man vielleicht auswählen können.

Und genau, das geht mit Postgres alles sehr schön.

Auch da kann man irgendwie die Counts für die Facetten ganz gut rauskriegen.

Ansonsten, wenn man das halt über eine eigene Spezialdatenbank, sowas wie Elasticsearch macht oder Lucine, äh, also beides Lucine-basiert oder Solar oder so macht, dann hat man das Problem, da hat man auch wieder dieses wie bei ETL, das Synchronisationsproblem.

Du hast halt, wenn sich an der Datenbank was ändert, müssen die Änderungen in den Index rein.

Da hast du eine Latenz dazwischen.

Wenn du Sachen aus dem Index rausholst, ja, du hast jetzt eine Volltext-Suchanfrage, dann kriegst du jetzt IDs aus der Suchmaschine, dann möchtest du aber vielleicht noch was filtern, was nur in der Datenbank drin steht.

Dann musst du nochmal auf die Datenbank, da alle Daten rausziehen und dann nochmal Counts anders ausrechnen.

Ja, vielleicht ein paar der Facettencounts kommen aus der Suchmaschine, ein paar kommen aber aus der Datenbank.

Das heißt, du hast nicht nur einen Roundtrip über die Suchmaschine, du hast auch noch einen Roundtrip über die Datenbank, wo du halt irgendwie Select irgendwie diverse Sachen vom Datenbankware und dann kommt halt ID in und dann kommen tausend IDs und so.

Das ist alles kompliziert.

Wenn das halt ein Statement ist, was du halt abfeuerst oder halt vielleicht eins für die Daten selber und eins für die Counts oder so, dann ist das halt deutlich, ist alles irgendwie viel einfacher.

Und mit Postgres kriegt man auch das am Anfang alles hin.

Und ja, das ist eigentlich sehr nett.

Irgendwann geht das aber wahrscheinlich dann halt eben auch nicht mehr.

Da muss man halt nach und nach Funktionen in Spezialservices halt auslagern.

Einer der ersten, den man wahrscheinlich auslagern wird, ist halt Volltext suchen.

Möglicherweise, das macht dann halt irgendwann Elasticsearch oder Solar oder so.

Aber halt auch eben sowas wie, wenn man jetzt anfängt, eine Query zu schreiben, kennt man eben Google Surges, hatte ich eben schon erwähnt, kriegt man halt so Vorschläge.

Das ist im Grunde, man macht dann halt, man sucht auf den Queries von anderen Leuten.

Aber dann hat man halt genau das Problem, dass halt sozusagen die History der Querys muss halt irgendwie aus dem Analyse-Ding wieder zurück ins OTP-System oder in irgendeinen anderen Service, auf den man dann per Suffix-Tree irgendwie nach Queries, die möglichst ähnlich sind, zu den drei Buchstaben, die man jetzt schon eingegeben hat oder so raussuchen.

Natürlich schnell mal tippen kann, drei, vier, fünf, ja.

Ja, ja.

Und also man kann das am Anfang auch alles über Postgres machen, wenn es dann halt komplizierter wird, muss man das als in eigenen Services auslagern und so weiter und so.

Und dann wird es halt alles, dann wird das System größer und schwieriger.

Ja, genau.

Und ja, und immer die Datenbanken, die man nimmt, werden halt immer spezialisiert.

Also das würde ich auch empfehlen.

Also man fängt halt mit Postgres an, macht mit Postgres einfach alles.

Und wenn man dann halt irgendwann an Grenzen stößt, dann muss man halt Wodo oder Übel dann Sachen in halt Spezialdatenbanken auslagern.

Und ja, bezahlt dann halt mit Komplexität.

Genau.

Ja, wir müssen ja nochmal gucken, wie wir das weitermachen.

Genau.

Wir nehmen Redis zum Cachen einfach von langlaufenden Queries und von irgendwie gerenderten Fragmenten, die halt aufwendig zu rendern sind, also irgendwelche Listen von Dingen oder so, die sich aber jetzt nicht dauernd ändern.

Und genau.

Es werden so Daten immer größer.

Ja, die Daten werden noch immer größer und das Problem ist auch, wir sind mittlerweile weltweit unterwegs.

Wir verkaufen nicht nur Bücher, wir kaufen alles von A bis Z.

Amazon.

Ich weiß nicht, ob ihr das schon gesehen habt, es gibt diesen Pfeil von A bis zum Z oder Amazon.

Ja, dann stellt sich ja die Frage, wenn wir das global machen, wo stellen wir dann den Master eigentlich hin?

Das ist halt auch schwierig.

Ja.

Wo wird denn stehen?

Also in einem sicheren Land?

Ja.

Oder klauen wir mit denen.

Wir müssen an alle Stellen irgendwie so einen kleinen Master stellen, wo halt viel Traffic ist.

Kann man den Master mirroren, dass man dann tatsächlich sagt, dass überall derselbe irgendwie.

Ja, also es gibt natürlich auch irgendwie für diese Geschichten so Lösungen, dass man halt, dass die Master sich miteinander synchronisieren, das gibt es für Postgres auch, aber das ist alles irgendwie, ich weiß nicht so genau.

Richtig.

Alles nicht so richtig, das funktioniert alles nicht so richtig.

Und ja, da gibt es, es gibt auf jeden Fall keine nette Es ist halt auch ein mehr oder weniger unlösbares Problem.

Also das ist auch theoretisch quasi nicht wirklich in den Griff zu kriegen.

Man kann aber Dinge tun, indem man halt auf andere Architekturen umstellt.

Man kann halt, ja, also ich habe jetzt mal hier als Beispiel genommen, diese, du willst halt, dass manche Sachen immer funktionieren.

Ja, eigentlich sollte immer alle möglichen Sachen funktionieren, ja, ja.

Und manchmal ist die dann halt irgendwie Konsistenz und so egal.

Also zum Beispiel für Amazon super wichtig, ist halt der Einkaufswagen.

Du musst halt immer weiter, das Spice muss fließen, jetzt wird es immer weiter einkaufen können.

Auch wenn jetzt, daher haben sie das halt, ich glaube, das war auch, also das Amazon Dynamo basiert auf einem System, das sie für sich selbst gebaut haben, eben für genau diesen Shopping-Basket, und der halt genau darauf ausgelegt ist, dass dieses Ding halt einfach immer funktioniert.

Und das ist mehr oder weniger einfach nur so ein total simpler Key-Value-Store.

Und du lebst halt dann damit, dass das nicht konsistent ist.

Oder dass halt, wenn du was kaufst, das halt vielleicht nicht mehr im Lager ist.

Das kann dann durchaus passieren, weil dieses Ding ist halt ein eigener Service, das hat keine Verbindung zu einer zentralen, das hat schon keine Verbindung außen, aber man kann halt nicht den echten Status abfragen, weil wo ist der?

Das ist halt schwer zu sagen.

Und das, was Amazon dann macht, tatsächlich, habe ich auch gehört, dass solche Sachen können dann ja auftreten.

Du kaufst ein Buch, das ist nicht mehr lieferbar.

Ja, und jetzt?

Also das heißt, es fällt erst so fünf Minuten später, fällt bei Amazon auf, geht nicht.

Wir haben jetzt zwar hat jemand was bestellt, wir haben die Entscheidung zugesagt, du hast da eine Bestätigungsmail bekommen irgendwie und jetzt fällt aber auf so, ah fuck, im Lager ist das nicht mehr drin.

Wir können es dir nicht schicken.

Was macht Amazon dann?

Ja, also höchstens entweder nachordern von irgendeinem Service, wie wir eben das Problem hatten, oder die sagen dann irgendwann so, wir schicken dir einen Gutschein raus, irgendwas gibt es nicht, aber.

Genau, es kommt eine Entschuldigungsmail und sie geben dir einen Gutschein.

Was da das nicht so super häufig passiert, ist das halt nicht schlimm.

Das ist halt viel einfacher, das über Gutschein zu lösen, als über ein Datenbanksystem, was das irgendwie handeln kann, weil das gibt es eben einfach nicht.

Und ja.

Wenn man kurz den 3D-Drucker anschmeißen, wird schnell nachproduziert, ja.

Ja, genau.

Das ist halt das auch, was dann halt gebrochen wird, in relationalen Daten, man nehmen wir das oft Asset.

Also Atomicity, Consistency, Isolation und Durability.

Atomicity ist eigentlich quasi das, was Transaktionen betrifft, dass halt entweder alles gut geht oder alles fehlschlägt, aber nicht irgendwie Teile einer Transaktion oder Teile von einer Menge von Dingen, die man tun will, halt gehen und dann mancher Sachen nicht gehen, das sollte halt nicht passieren.

Consistency heißt halt, dass die ganzen Foreign Key, dass es halt die referenzielle Integrität halt gewahrt bleibt, dass da Sachen nicht zerbrechen, was halt dann auch nicht mehr geht, wenn du Sachen über mehrere Datenbanken verteilst, weil dann hast du halt teilweise eben keine direkten Verbindungen, sondern du hast halt bloß wie A-Pies dazwischen.

Isolation ist halt die Geschichte, dass du nicht Sachen, die andere Transaktionen machen, in deinen Daten siehst.

Also das halt, man nennt das Dirty Read, wenn du halt in deiner Transaktion Dinge aus anderen Transaktionen siehst, die noch nicht abgeschlossen sind.

So dass du halt, dass du immer, dass deine Sicht auf die Datenbank komplett isoliert ist von den anderen.

Es gibt unterschiedliche Isolationslevel.

Postgres hat per Default den höchsten, glaube ich, Serializable, ist der höchste.

Dann gibt es noch Repeatable Read.

Repeatable Read war lang, glaube ich, lange.

Aber mittlerweile ist es serializable.

Kann man auch nachgucken, was das bedeutet.

Es gibt da feine Unterschiede.

Und genau, Isolation und Durability ist halt einfach nur das, wenn eine Transaktion gesagt hat, okay, ich bin durchgeführt, dass dann halt auch nichts mehr schief gehen kann.

Was extrem schwierig ist zu implementieren.

Und ja.

Stromaus.

Genau, Strom aus muss trotzdem, wenn die Datenbank wieder hochkommt, alles im richtigen Zustand sein.

Aber das kann man ja oft dann nicht so wirklich gewährleisten.

Also man kann ja nicht, das ist halt.

Der Hauptspeicher, dann ist ja flüchtig und nicht.

Der Hauptspeicher ist flüchtig, das heißt, man darf es nicht in den Hauptspeicher einfach nur schreiben, sondern die Transaktion darf erst als dann durchgegangen, wert zurückgeben, wenn das im Write-Ahead-Lock gelandet ist und das mit F-Sync irgendwie auf die Platte geschrieben ist.

Ja, und F-Sync ist halt teurer, teurer Syscall, das macht das sehr langsam.

Auch diese Isolation macht es halt langsam, aber das sind auch alle Sachen, die man halt weiter runterfahren kann.

Du kannst halt zum Beispiel auch, das machen Leute halt auch für Postgres zum Beispiel.

Du kannst unterschiedlichen Usern unterschiedliche Isolationslevel geben.

Und dann kannst du sagen, wenn jemand Analyse-Queries macht, dann oder bestimmte Arten von Queries, bei denen es völlig egal ist, ob die super isoliert sind oder nicht, dann kannst du sagen, wenn dieser User, also dieser User hat halt ein viel niedrigeres Isolationslevel, der macht dann halt Dirt-Reads, aber das ist halt egal für dessen Anwendungsfall.

So kann man Sachen deutlich beschleunigen.

Dann, was man auch machen kann, das sollte man halt jetzt nicht tun, wenn man Bestellungen, äh, Bestellungstransaktionen prozessiert, aber zum Beispiel, wenn man testet, oft hat man ja viele Tests für eine Applikation und es dauert lange, bis sie durchlaufen, wenn es irgendeine Änderung macht und man führt die Tests aus und das dauert ein paar Minuten, das ist halt schlecht, weil es halt diesen, man ändert was, führt die Tests aus und hat dann sofort Feedback-Cycle irgendwie kaputt macht, wenn man dann h

alt irgendwie Kaffee trinken gehen muss.

Und es macht auch so irgendwie ein bisschen die Konzentration kaputt.

Daher wäre es schön, wenn die Tests irgendwie schnell laufen würden.

Und da man aber auch für die Tests, jetzt wenn man jetzt ein Django-Projekt hat, auch die echte Daten, auch ein Postgres verwenden will, was viele Leute früher gemacht haben, ist dann halt ein SQLite zu verwenden, das nur in Memory ist.

Das geht dann viel schneller, aber das Problem ist halt, dass SQLite sich anders verhält als Postgres und dann laufen die Tests durch und man denkt, das ist alles gut und dann geht es auf die Datenbank und dann geht's schief.

Nicht so gut.

Aber was man tatsächlich machen kann, ist, Postgres zu sagen, ja, irgendwie nicht F-sinken, mach mal nicht.

Und man kann auch die Postgres dann auf eine In-Memory-Partition legen quasi.

Das geht auch.

Kann man auch irgendwie per Docker-Argumenten kann man das irgendwie sagen und dann sind die Tests halt viel, viel schneller.

Weil für Tests ist es mir egal, ob das jetzt, wenn der Strom ausgeht, dann ist es mir wurscht.

Die Testdatenbank schmeißt sich sowieso nach jedem Testlauf wieder weg quasi.

Also ja, aber für die echte Produktionsdatenbank, die muss halt bei Transaktionen tatsächlich dafür sorgen, dass das nicht mehr verschwinden kann.

Und das heißt, sie muss Apps aufrufen und dann ist das halt einfach langsam.

Da kann man auch nichts machen.

Okay, einmal ein bisschen Asset, ne?

Ja, genau, haben wir Asset.

Und dann, ja, also was wir, was wir dann heutzutage oft haben, sehen bei Datenbanken, die das halt, also Dokumentdatenbanken, genau, ist halt ein anderes Paradigmat, das nennt sie Base, also Basic Availability, Soft State, Eventual Consistency, also wo man halt versucht, die Sachen so aufzulockern, um halt es möglich zu machen, dass man zum Beispiel mehrere mehrere Datenbanken schreiben kann.

Ja.

Ja.

Sind jetzt schon ziemlich groß geworden, oder?

Ja, genau, wir sind jetzt ziemlich groß und was wir jetzt haben, wenn wir auf mehrere Sachen schreiben wollen, ist halt, genau, das Asset ist halt weg.

Pech gehabt.

Wir haben ja noch ein anderes Ding, das dann noch, das Cap-Theorem, Consistency, Availability und Partition Tolerance.

Das ist halt auch diese, wenn man immer, wenn man so Sachen, pick two out of three Sachen sieht, also das Cup-Theorem ist halt so das ursprüngliche Ding dafür.

Du kannst halt zwei davon hinkriegen, aber drei nicht.

Und Partition Tolerance ist leider nicht optional.

Das musst du halt haben.

Weil anders.

Partition Tolerance, also was ist, wenn Netzwerkverbindungen zwischen zwei deiner Datenbank-Dinger irgendwie wegfällt oder so.

Das muss halt leider, das ist halt mandatory sozusagen.

Das heißt, du kannst nur noch zwischen Consistency und Availability halt irgendwie wählen.

Und du hast halt, ja, dann gibt es halt Datenbanken, die dann halt unterschiedliche Trade-offs realisieren.

Ja, äh, genau.

Das ist zum Beispiel ein interessanter Fall ist halt sowas wie CouchDB.

Die halt, äh, wo du sogar, wenn du halt offline bist, immer noch immer noch eine Datenbankverbindung hast oder immer noch deine Applikation benutzen kannst und die schreibt dann halt das in eine lokale CouchDB-Instanz, auch interessant, weil es ist halt so ein JavaScript-Ding, das ist dann natürlich.

Aber früher hatte man so jQuery als Abstraktionslevel für alles, was irgendwie auf diesem DOM-Modell im Browser irgendwie Dinge tut.

Man möchte es ja vereinheitlichen, alle Browser haben das unterschiedliche, haben da unterschiedlichen Funktionen gehabt.

Also hatte man jQuery und wenn man jQuery konnte, dann war es einem halt quasi egal, welcher Browser da drunter lag.

Und bei CouchDB ist es so, das abstrahiert so ein bisschen diese Storage-APIs, die Browser haben.

Also es ist halt quasi dafür gedacht, wenn du jetzt eine lokale, wenn du eine Webseite auf einer Smartphone hast oder so, und du hast halt nicht immer Verbindungen, du möchtest aber trotzdem, dass sich deine Webseite so anfühlt, als hättest du irgendwie eine Verbindung.

So man ist so Offline First oder so, jetzt mit einem Shopping-Kontext ist das halt nicht so richtig gut vorstellbar, warum das irgendwie sinnvoll ist.

Aber nehmen wir an, du hast jetzt irgendwie sowas wie Trello, also irgendwie so Tasks oder so, wo du Sachen machen kannst.

Dann möchtest du nicht, dass wenn jetzt du durch den Tunnel fährst, dann nichts mehr geht, sondern das geht halt mit CouchDB, das ist halt sozusagen wie JackQuery ein Layer über dem Storage-API von deinem Browser, weil die können das ja auch alle mittlerweile, die haben meistens SQL Lite oder sonst irgendwas drunter und dann halt APIs, mit denen du da irgendwie Dinge drauf tun kannst.

Und was CouchDB jetzt letztendlich macht, ist da nochmal ein Layer drüber zu legen und so ein Replikationsfeature zu haben in alle möglichen Richtungen.

Also es sind halt Master, Master oder Datenbank zu Datenbank in alle Richtungen.

Es ist halt nur so, dass ab und zu können halt Konflikte auftreten und die müssen dann vom User gelöst werden.

Das heißt, du bist halt manchmal gefragt, ist das oder das richtig.

Aber das passiert jetzt auch nicht so super häufig und das ist halt schon sehr, sehr nett.

Also das ist halt, also du kannst halt, auch wenn du offline bist, halt deine Web-Anwendungen weiter so benutzen, als wärst du online und das synchronisiert sich halt in dem Moment, wo du halt wieder Verbindung hast.

Und ja, das ist halt dann sehr auf der Availability-Seite und halt dann auf der Konsistenzseite halt nicht.

Und deswegen musst du halt dann Sachen auch Konflikte manuell unter Umständen lösen.

Genau.

Ja.

So, jetzt haben wir, okay.

Jetzt sind wir, glaube ich, im Grunde mit dem ganzen traditionellen Kram mehr oder weniger durch.

Ja, wahrscheinlich nicht so wirklich.

Wahrscheinlich haben wir so ein bisschen.

Ja, hat es schon ganz so lange geschafft, den sie bis hierhin geschafft hat, aber.

Aber und jetzt kommt eigentlich nur noch ein Teil und das ist halt irgendwie so Big Data oder Urlaub-Geschichten für wirklich große Dinge.

Really, really, really big things.

Ja.

Also ich meine, Big Data ist ja so ein bisschen, ich weiß nicht, was sagt, was würdest du sagen, ist Big Data oder warum wollen Leute das haben?

Ja, also erstmal hört sich cool an und also jede Exit-Tabelle mit mehr als tausend Teilen kann man schon quick machen oder sowas.

Also es kommt halt, glaube ich, ein bisschen auf den Anwendungsverfall an und jeder hat natürlich gerne Big Data, weil es natürlich super ist, man ganz viel machen kann, man kann Analysen mitfahren und sowas.

Alles, was halt irgendwie anfällt an Dingen, die man durch die ganzen modernen Daten irgendwie so jederzeit bekommt, ist dann irgendwann sehr big.

Fühlt sich einfach groß an, wenn man ganz viele Sensordaten von verschiedenen Punkten bekommt, was soll man damit machen?

Man schreibt hier irgendwelche Excel-Tabellen rein.

Also Firma, die liegen dann halt auf irgendwelchen Servern oder halt auch einfach nur Rechnern rum und dann hat halt ganz viele große Informationen, oh dass man damit was anfangen kann bisher.

Das ist vielleicht schon Big Data, ich weiß nicht.

Also ich glaube, dass überall Daten vorhanden sind, ist vielleicht das eigentliche Big Data.

Aber ob jetzt so im Einzelfall das wirklich big ist, was

hast du?

Ja, also genau, ich habe auch, es gibt dann sehr unterschiedliche Auffassungen davon.

Es gibt halt Leute, die sagen so, ja, was nicht mehr in der Excel-Tabelle passt, das ist schon so.

Also ich würde sagen, vielleicht etwas halbwegs vernünftigere ist halt, was nicht mehr auf einen Computer passt.

Aber auch das greift eigentlich zu kurz.

Ich habe dann letztens nochmal irgendwie Spielesammlung.

Ja, das war irgendein Talk von Michael Stonebreaker, das ist auch ein, das sind immer die gleichen Namen, auf die man irgendwie in dieser Datenbankwelt stößt.

Das sind halt so Michael Stonebreaker, Jim Gray, Takott, weiß ich nicht, Duck Hutting, das ist auch, ähm, der, der hat auch zum Postgres mitbegründet oder Ingress vorher und dann Postgres.

Und auch viele der noch moderner, der heute jetzt ganz modernen Geschichten wie Column Stores, also C-Store, Paper ist von ihm, Woltybi für so In-Memory-Datenbanken, Geschichten.

Ja, der, der definiert das so, der sagt halt so, naja, es gibt eigentlich drei Arten, wie Data Big sein kann, nämlich irgendwie, ja, es ist einfach zu viel.

Und der sagt halt nicht irgendwas Konkretes, sondern sagt halt, du hast halt Probleme mit der Datenmenge.

Also es ist halt, wenn du wirklich Schwierigkeiten damit hast und damit nicht fertig wirst, dann hast du halt ein Problem mit der Datenmenge und dann hast du halt Big Data, weil es halt für dich schwierig ist, mit dieser Menge klarzukommen.

Aber was halt auch sein kann, ist, und dann hast du halt auch ein Big Data-Problem, auch wenn es jetzt nicht unbedingt eins ist, das mit der Datenmenge zu tun hat, wenn die Daten zu schnell kommen.

Also du könntest mit der Datenmenge vielleicht klarkommen, aber sie kommen so schnell, dass du irgendwie nicht fertig wirst.

Du hast so ein RESPI oder sowas und der ist ja immer begrenzt und dann.

Ja, dann hast du auch ein Big Data-Problem, aber halt eine andere Art von Big Data-Problemen.

Und es gibt dann noch eins, das ist halt, wenn Daten aus ganz vielen sehr unterschiedlichen Quellen und sehr unterschiedlicher Art kommen, sind es vielleicht gar nicht so viele und sie kommen auch nicht so schnell, aber du kriegst sie nicht schnell genug integriert oder kriegst du halt nicht in den Griff.

Dann hast du auch wie ein Big Data-Problem, was auch wieder leicht anders ist.

Und diese drei Dinger sind halt eigentlich alle irgendwie so ein bisschen unterschiedlich.

Und ja, oft wird es nicht so richtig klar.

Und oft ist es, also ich würde sagen, so ein Big Data ist so ein gehyptes Ding.

Und ja, irgendwie werden ganz viele Hadoop-Cluster verkauft.

Was ist ein Hadoop-Cluster?

Ja, es ist Hadoop ist irgendwie so ein Apache-Projekt, das irgendwie mal gestartet ist als so Implementierung eines Konzepts, nennt sich MapReduce.

Das hat so ein Paper, das hat Google mal veröffentlicht, oder irgendwie Jeff Dean und noch ein paar andere haben das veröffentlicht, 2004 glaube ich.

Und das ist halt eine Art, mit großen Datenmengen umzugehen und die halt so horizontals irgendwie auf ganz viele Maschinen zu skalieren.

Das funktioniert im Grunde so, dass es halt auch genau dafür gedacht ist, wenn man jetzt einen großen Suchendex, wie man bei Google zum Beispiel hat, wie bauen möchte über das gesamte Web, dann kann man das halt eben nicht auf einer Maschine tun.

Das ist halt völlig ausgeschlossen.

Und man möchte das halt irgendwie auf möglichst viele Maschinen, so eine halbe Million, eine Million oder so, skalieren.

Wie macht man das?

Und das Konzept, das sich dafür überlegt haben, nennt sich halt MapReduce und ist auch eigentlich nicht wirklich was Neues.

Früher hieß es gab es auch schon ähnliche Konzepte, die nennt sich Scatter Gather oder sowas.

Und im Distributed Computing Teil gibt es auch diverse Geschichten, die so ähnlich sind.

Aber so auf der Skala und so und die Art, wie sie das konkret machen, ist halt schon irgendwie was Neues und auch ein sehr, sehr, sehr cooler Ansatz.

Und zwar machen sie das halt so, dass, also im Grunde kann man sich so vorstellen, jetzt wenn man eine Webseite hat, man hält viele Rechner, die halt Webseiten crawlen, dann nimmt man den Text, zerlegt den halt in Worte und man spuckt jetzt sozusagen für jedes Wort einmal das Wort oder für die Webseite, die Worte aus, aus denen die Webseite besteht, plus die Anzahl, wie oft es vorkommt.

Das ist halt sozusagen die Map-Phase.

Und das machst du jetzt auf allen Maschinen.

Und dann führst du das halt irgendwann wieder zusammen in einem Reducer.

Und also was du bauen möchtest, ist sozusagen so ein etwas, also ein Index, das ist halt wie ein Index in einem Buch, wo halt steht, welches Wort kommt auf welcher Seite vor.

Und du musst du musst halt für so eine Webseiteinterseite musst halt sagen, welches Wort kommt auf welcher Webseite vor.

Das ist halt das, was du hinterher haben willst.

Und die sortiert man dann nach der Reihenfolge, wie oft das immer vorkommt oder so ungefähr.

Genau, aber man muss halt auch wissen, wie oft es vorkommt, weil man halt bestimmte Geschichten, also man nennt, ja.

Wir stehen am Anfang von der Liste, wie oft das vorkommt.

Ja, man rechnen so TF, EDF-Scores aus und dafür braucht man halt die Term-Frequenzen.

Das ist so bitte was, ein TF, IT, SPD.

Ja, Term-Frequence mal Inverse Document Frequency ist halt sozusagen ein wichtiger Wert dafür, wie wichtig jetzt ein Wort ist in einer Webseite oder in einem Dokument.

Und dafür muss man halt zählen, wie oft ein Wort vorkommt.

Ja, aber man muss halt auch zählen, wie oft das Wort überhaupt vorkommt.

Und dann generell das noch mit dem Kontext und der Wichtigkeit und so im Zusammenhang setzen.

Naja, also in dieser Mapphase imitiert man im Grunde nur, welche Webseite war das, wie oft ist das Wort da vorgekommen und dann werden diese Ströme dann zusammen reduced und dann sozusagen hat man halt irgendwie dann diesen Index, wo dann zu jedem Wort steht, auf welchen Webseiten es vorkam und ja, wie oft und wie oft es insgesamt vorkam und so.

Und dann kann man irgendwie so Abfragen machen.

Und das kann man halt komplett voneinander trennen, da halt bestimmte, da man, da sich diese Sachen komplett voneinander, du kannst halt nach Worten auftrennen.

Also du musst halt nur dafür sorgen, dass das gleiche Wort immer auf, dass alle Sachen, die zum gleichen Wort gehören, zusammengeführt werden.

Aber du kannst halt ja für unterschiedliche Worte unterschiedliche Maschinen benutzen.

Das ist halt gar kein Problem.

Und damit kannst du es quasi beliebig horizontal skalieren.

Auch da wiederum ist es schwer zu erklären, dann kann sich das einfach mal angucken, aber es gibt auch noch.

Dann bietet sich einfach so ein Rechenzentrum, das schaltet einfach noch eine Maschine ein, wenn du welche brauchst oder so.

Genau, du kannst dann halt einfach immer mehr Maschinen dazustellen.

Und ja, viele Leute haben sich gedacht, oh, das ist mal eine coole, coole Idee.

Und dann, ja, derjenige, einer von denen, der Name man immer hört, irgendwie Doug Hutting, der hat damals schon bei Excite irgendwie die Suchmaschine gebaut, hat dann später eine sehr populäre, oder immer noch die populärste Volltext-Suchmaschine, die es so gibt, Lucinen oder The Engine darunter jedenfalls geschrieben, auch ein Buch darüber, das ja und irgendwann hat er sich halt diesen, ist er eher so in diesen Big Data Hadoop Bereich gegangen und der hat halt ursprünglich auch irgendwie dieses Hadoop-Projekt dann

losgetreten und dabei ging es halt darum, ein System wie das, was Google halt zum Bauen der NDCs verwendet hat, in Open Source nachzubauen.

Unter diesem Apache-Projektschirm.

Und ja, das hat auch gut funktioniert alles.

Es ist ein Riesenprojekt geworden.

Es ist auch für manche Sachen halt total super.

Ich würde jetzt nur sagen, also es wird heute viele Dinge verwendet, für die es vielleicht nicht so gut geeignet ist eigentlich.

Zum Beispiel.

Ja, also es ist, glaube ich, für viele Firmen heute so die generische Data-Warehouse-Lösung geworden.

Obwohl es dafür weiß ich nicht.

Also ich würde ja sagen zum Beispiel, viele Firmen haben eben keinen Big Data.

Die haben nicht das, die haben keines dieser drei Big Data-Probleme, sondern

wissen eigentlich noch nicht, wie die es machen sollen.

Ja, die haben einfach nur Daten und eigentlich passt das an den Hauptspeicher und die brauchen nichts davon.

Das ist, die können einfach die

mit einem Postgres-Server.

Ja, oder nicht mal das, äh.

SQLite Memory.

Ja, ja.

Also ein Freund von mir sagte immer so, oder nee, wer hat das?

Ach, ich habe das, und ich glaube, ich habe es auf Twitter gelesen, Unsinn.

Man sollte irgendwie, ich weiß aber nicht mehr, wer es war, ich sollte eigentlich mal einen Consulting-Service gründen, der irgendwie den man engagieren kann, wenn man vor der Frage steht, ob man sich jetzt ein Hadoop-Cluster irgendwie kaufen möchte oder nicht.

Die Antwort ist immer nein.

Gehe ich da hin und sage, lass mich überlegen.

Nein.

Deine Daten fit in RAM, ja, ich würde ja fit in RAM, no.

Und da einfach jedes Mal 10.000 Dollar für verlangen.

Ja, das würde, hätte ich hätte ich irgendwie ein nettes Einkommen durch und würde den Unternehmen ein Vielfaches davon sparen, von dem, was sie dann ausgeben, wenn sie das nicht haben.

Das hatten ja das Frühante.

Und da ist leider viel Wahres dran.

Also es gibt wenige, die das wirklich brauchen.

Viele schaffen es sich trotzdem an und haben dann ein kompliziertes, eine komplizierte Lösung für ein Problem, das sie nicht haben.

Die Rattenfanzter, ich meine das natürlich für die Leute, die dann Geld verdienen.

Genau, für das Problem, was sie haben, ist das einfach total kompliziert zu benutzen.

Also Dinge wären viel einfacher, wenn sie das nicht machen würden, aber naja, so ist es halt nun mal.

Und von diesem Map-Reduce-Ding ist auch diese ganze Hadoop-Welt auch schon so ein bisschen wieder weg.

Auch Google macht nicht mehr wirklich Map-Reduce, also manche Sachen machen sie möglicherweise noch Map-Reduce, aber es sind ja auch andere Systeme gegangen, Pregels und Graph-Processing-Ding, was sie da machen, was halt relativ viel tut von dem, was früher Map-Reduce gemacht hat.

Und auch bei Hadoop ist es halt so, dass das, was geblieben ist, ist irgendwie so ein verteilter Dateisystem-Layer, so auch ein Management von diesen Nodes irgendwie in diesem Cluster.

Aber die Engines, die jetzt irgendwie Querys darauf prozessen, dafür gibt es halt, das nennt sich Hive, irgendwie da schreibt man Quarys in so einem SQL-ähnlichen, oder das ist schon SQL, man schreibt halt das so SQL und das wird dann halt in MapReduce-Jobs verwandelt und wird dann halt auf den, ja, also im Grunde die Idee bei der ganzen Geschichte ist, dass man halt nicht mehr die Daten zu einer Stelle bringt, wo sie dann prozessed werden, sondern man bringt den Algorithmus zu den Daten.

Die liegen halt, man kann die Daten nicht mehr an einer Stelle zusammenführen, weil es sind einfach zu viele.

Die liegen halt auf den lokalen Nodes und man trägt jetzt den Algorithmus zu diesen Daten und der läuft dann halt lokal auf den Cluster-Nodes darüber und dann am Schluss wird das alles wieder zusammengeführt, äh, zusammenreduced und dann kriegt man halt das Ergebnis.

Und für einen selber sieht das so aus, man schreibt halt ein SQL-Statement und kriegt halt ein Ergebnis.

Und in Wirklichkeit hat man dann halt irgendwie einen Job gebaut, der dann halt 100 Mapper, 100 Reducer angestoßen hat und das lief halt über 200 Maschinen.

Oh, that's big.

Ja, ja, ja.

Vielleicht das Problem nur Big Data dann.

Also Big.

Aber es wäre halt irgendwie, und das hat dann vielleicht eine halbe Stunde gedauert, aber es ist halt auch möglich, dass wenn man das halt anders gemacht hätte, hätte diese ganze Geschichte auch in der Minute durchlaufen können.

Ja, es gibt dann auch andere Geschichten, die jetzt auf solchen Clustern laufen, zum Beispiel rein in Memory-Geschichten, sowas wie Impala.

Einer von den PhD-Studenten von Michael Stonebreaker, die damals Postkreis mitgeschrieben haben, ist da irgendwie CTO von der Firma, die da.

Ich habe jetzt aber auch wieder vergessen, welche das ist.

Das macht das halt in Memory, das sind C geschrieben, das ist alles schneller, das ist viel angenehmer, wenn man damit arbeitet, aber es ist auch so ein bisschen komisch und es ist halt auch nicht so richtig, es ist halt nur ein bisschen instabil.

Es gibt diverse andere Geschichten, jetzt gut zu.

Ach, das war auch noch ein eigenes Thema eigentlich, Spark, Spy Spark.

Was ganz interessant ist, ist, was man vielleicht, lass mich überlegen.

Also was sehr interessant ist, ist, dass wir heute etwas sehen, was wir früher eigentlich auch schon gedacht hätten, dass wir das im relationalen Bereich bekommen, nämlich, oder MySQL hat er mit mal angefangen.

Die hatten irgendwie, also eines der coolen Features bei MySQL am Anfang war, dass die Storage Engines pluggable waren.

Das heißt, du konntest deine eigene Storage Engine da reinbauen.

Hat er auch kaum im Endeffemacht.

Es gab eigentlich nur zwei relevante.

Wie die Daten tatsächlich auf der Platte liegen.

Ah, okay.

Letztlich.

Und das ist halt, es gab MyESAM, es gab auch eine CSV-Engine für MySQL, da hast du einfach CSV ausgenommen.

Aber MyESam war so populär.

MyESOM hat er aber Probleme, hat er das Problem, dass du, wenn du geschrieben hast, da wurde mir die komplette Table gelockt.

Das heißt, also da lieber nur lesen, nichts reinschreiben.

So reinschreiben, eher doof.

Hat trotzdem irgendwie haben das viele lange verwendet.

Transaktionen so, das geht alles nicht.

Asset war nicht so richtig bei MySQL am Anfang.

Und dann hatten sie eine Storage Engine, die das dann aber schon konnte, die auch so wirklich Multiversion Concurrency Control halt richtig konnte.

Und das war InnoDB.

Und ja, aber eigentlich, so nachdem InnoDB sich durchgesetzt hatte oder irgendwie gut genug war, dann hat sich dieser Pluggable Storage Engine Geschichte von MySQL hat sich dann auch wieder erledigt.

Aber Postgres bekommt jetzt, glaube ich, mit der Version 12, also ist es noch nicht sicher, aber es sieht ein bisschen danach aus, als ob sie Pluggable Storage Engines wieder zurückbekommen.

Was interessant ist, da es dann zum ersten Mal, aber das Konzept nochmal irgendwie doch nochmal angefasst wird.

Und interessant ist auch in diesem ganzen Analytics, Big Data Bereich, dass wir da auch sowas sehen.

Wir sehen halt, es gibt nicht mehr so ein Datenbanksystem, wo halt die Represent, also wie die Daten gespeichert werden, tatsächlich an die anderen Teile, also im Grunde besteht ja so ein Datenbanksystem aus vielen unterschiedlichen Geschichten.

Es besteht halt aus so einem System, das irgendwie einfach nur die Daten managt irgendwie und Zugriffsrechte verwaltet und irgendwie, und dann gibt es halt so Dinge, wie speichert man das auf der Platte, es gibt Indizes, es gibt so viele unterschiedliche Teile.

Und ja, wir sehen jetzt so ein bisschen, dass das halt auch alles wieder so ein bisschen pluggable wird, gerade auch in diesem Big Data-Bereich.

Also, auch wichtig, wenn man diese Analysegeschichten macht, hat man im Grunde ist die Art, wie Daten in relationalen Datenbanken speichert werden, ist zeilenweise, ja.

Weil man oft, weil die Art von Queries, die man da macht, oft nur wenige Zeilen betreffen.

Ein paar tausend oder so, was sind immer noch sehr wenige.

Daher macht es Sinn, irgendwie zeilenweise zu arbeiten, sozusagen.

Aber für diese Analysegeschichten, dieses ganze Data-Warehousing-Zeugs, ist das überhaupt nicht sinnvoll.

Dieses Muster, dass man halt eher Millionen von Zeilen anguckt, aber nur wenige Spalten, weil man sich nur für einen bestimmten Aspekt interessiert.

Man interessiert sich oft eben nur für Umsatz oder Preis oder sowas, aber man interessiert sich gar nicht für den Namen des Autors oder so.

Daher möchte man eigentlich nicht irgendwie alle die Zeilen immer komplett angucken, weil dann guckt man sich ganz viel Zeug an.

Also der Flaschenhals ist oft wie oft die Bandbreite zwischen Platte und Hauptspeicher.

Man muss das halt dann irgendwie durch den Prozessor ziehen.

Und je weniger Daten man da durchziehen muss, umso besser.

Und bei einem zeilenorientierten Format muss ich, wenn ich die Datei lese und die Datensätze halt zeilenweise drinstehen, muss ich halt da sequentiell durch die Zeilen durchgehen.

Da hilft es, geht nicht anders.

Und das ist halt total ineffizient, weil ich, wenn ich halt nur einen kleinen Teil von diesen Zeilen, nämlich nur eine Spalte, irgendwie überhaupt lesen möchte.

Das heißt, wenn ich so Analysequeries auf Datenbanken mache, die zeilenbasiert ihre Daten speichern, dann ist das super ineffizient.

Und ich habe halt so einen Verlust von circa, man sagt so immer, ein Faktor 50 ungefähr, sind die halt einfach aufgrund dieser Architekturgeschichte langsamer und zwar unoptimierbar langsamer als sogenannte Column Stores, die halt Daten spaltenweise speichern.

Und die ersten Dateisystemformate oder Formate, in denen die Daten zum Beispiel in Hadoop gespeichert wurden, Avo ist, glaube ich, so das erste, ich weiß nicht genau, sind auch alle zeilenbasiert, weil das war halt so.

Man hat halt irgendwie zeilenbasiert Sachen gespeichert.

Aber das ist halt eben total ineffizient, wenn man halt nur bestimmte Spalten von Datensätzen haben möchte.

Und dann gibt es halt neuere Fallformate, wie zum Beispiel oder Serialisierungsformate, Parquet-Dateien zum Beispiel, das ist halt das, was heute eigentlich immer so verwendet wird.

Das ist halt dann spaltenbasiert.

Und dann liest man eben nur die Dateien oder die Spalten.

Es ist halt in einer Datei nur eine Spalte sozusagen.

Man liest halt nur die Dateien, die man halt braucht.

Und das ist komprimierbar, es ist chunkbar, sodass ich es auf mehrere Rechner verteilen kann und so und hat halt all diese hübschen Eigenschaften.

Und ich habe jetzt diese Paket-Files, aber das Format der Daten auf der Platte, das Serialisierungsformat, ist nicht mehr gebunden an die Datenbank, sondern als Layer darüber, mit dem ich jetzt Abfragen mache, habe ich jetzt sowas wie Hive, das macht er MapReduce-Drops draus irgendwie.

Ich habe aber auch sowas wie Fala, ich habe vielleicht andere Geschichten, ich habe Spark.

Spark hast du eben noch vergessen, übrigens.

Ja, Spark, genau, gut, Spark hat auch irgendwie mit was anderem gestartet, diesen DD, hat auch ein eigenes Dataframe-Format, was jetzt nicht Parket war.

Aber also worauf es hinausläuft, ist im Grunde, dass ich jetzt so ein Format habe wie Parquet, in dem die Daten auf der Platte liegen.

Und jetzt habe ich halt unterschiedliche Engines, die jetzt irgendwie, mit denen ich jetzt Queries verarbeite drauf.

Ja, also quasi eine Trennung zwischen dem System, das jetzt meine Quaries irgendwie beantwortet und dem Speicherformat.

Also quasi sowas ähnliches wie eine Pluggable Storage Engine.

So nur das halt das Storage Format ist halt für alle unterschiedlichen Engines irgendwie gleich, nämlich Paket.

Aber das, was halt die Dinge darauf machen, ist halt unterschiedlich.

Und das ist eine ganz interessante Entwicklung, finde ich.

Also, das ist halt, das ist schon faszinierend.

Und ja, die Column Stores sind halt sozusagen das, sind für so Data Warehousing eigentlich das Coole.

Es gibt halt so im C-Store Paper, ist halt auch eine Firma, entstanden, Vertica, glaube ich.

Die machen halt, wenn man, wenn man irgendwie ein großes Data Warehouse haben möchte, dann ist es wahrscheinlich irgendwie so das Beste, wenn man irgendwie zu einer Firma geht und das macht.

Keine Ahnung.

Oder gibt es auch wahrscheinlich auch noch andere, die sowas ähnliches machen, aber was halt nicht gut wäre, ist halt, wenn man, wenn man mit so einem Problem zu Oracle geht, weil Oracle ist halt nicht column-orientiert, sondern die sind halt zeilenbasiert, egal was sie dazu sagen.

Sie versuchen das mit ihrem Marketing immer zu verschleiern, aber es ist halt, ja, genau wie MSSQL-Server und die ganzen klassischen relationalen Datenbanken, die sind alle zeilenbasiert und da gibt es auch nichts, was man tun könnte.

Ja, es sei denn, man tauscht die Storage-Engine aus.

Das ist halt, bei Postgres wird das nochmal interessant.

Also Postgres, da hat man das Problem halt, wenn man Data Warehouse auf Postgres aufbaut, dann ist man immer dann an die zeilenweise Verarbeitung gebunden, kann halt auch nichts machen.

Wenn man das demnächst dann halt mit Packet machen könnte, dann.

Ja, wenn man irgendwie Packet und Postgres irgendwie verheiten könnte, das wäre natürlich schon ziemlich cool dann irgendwie.

Ja, genau.

Und das sind halt so die, ja, das sind halt so diese Geschichten beim Data Warehousing.

Genau, so Hadoop, man nennt das auch so nicht Data Warehouse, sondern weil man auch alles mögliche andere drin speichern kann, Data Lake, weiß ich gar nicht, ob man da so ins Detail gehen muss, weil man auch noch Bilder und sonst wie andere Unterschied.

Man kann halt alle möglichen Arten von unterschiedlichen Daten.

Man kann auch so ein bisschen umkippen, wenn man das dann Data Swamp.

Ja, und ja, also ich bin ehrlich gesagt nicht so ein Riesenfan von YouTube, muss ich sagen.

So, aber auch, ich habe da auch schon ein bisschen so schmerzhafte Erfahrungen mit gemacht.

Weil so Daten rein und rauskriegen, ist irgendwann so ein bisschen hässlich.

Und das ist auch noch alles nicht so weit.

Also bei so klassischen Datenbanken ist halt, da merkt man, also beim Postgres-Grad verwendet zum Beispiel, merkt man halt so, da ist halt schon Jahrzehnte Erfahrungen drin und viele der Use Cases, die man so hat, also wenn man da auf blöde Probleme stößt, dann ist man wahrscheinlich selber schuld.

Also das ist halt sehr selten, würde ich jetzt mal so.

Dass man auf etwas stößt und man hat wirklich ein Problem mit der Datenbank, sondern man hat ein Problem mit, man hat die Dokumentation nicht genau genug gelesen oder man weiß, man hat irgendwie ein Verständnisproblem oder so.

Und das sind ja alles Sachen, die sich gleich fixen lassen.

Also es wäre halt schlecht.

Man sollte nichts damit auskennen.

Ja, wenn man tatsächlich ein Problem mit der Datenbank hat, ist natürlich schlecht, weil da kann man nichts machen.

Außer Datenbank wechseln oder irgendwie selber neu schreiben oder sowas nicht gut wäre.

Und bei Hadoop habe ich so das Gefühl, da kann natürlich auch was sein, dass ich einfach zu blöd war, es zu bedienen, aber ich habe so das Gefühl, viele Dinge, die man da macht, sind nicht dadurch begrenzt, dass man irgendwie nicht genug weiß oder nicht genug, die es nicht richtig verwendet, oder es falsch rumhält irgendwie, sondern bestimmte Sachen gehen einfach noch nicht oder gehen nicht richtig.

Oder man hat Use Cases und dann stellt man so fest, so ja, hat niemand drüber nachgedacht, ist nicht so richtig abgebildet, hm, blöd.

Und das wird wahrscheinlich alles irgendwie viel besser, aber momentan ist es noch nicht so, es ist noch ein bisschen scharf, fühlt sich alles ein wenig scharfkantig an.

Kann sich überall schneiden und wir tun, ist auer.

Ja, und außerdem, dass es halt alles auf dieser Java-Geschichte aufsetzt, ist auch sowas, muss ich auch sagen.

Sind wir wieder bei dem Ding, was wir eigentlich als Running Gag nehmen wollten, haben wir es doch dazu.

Ja, Java verlassen, aber wieder.

Das ist.

Ja, also ungefähr nach zweieinhalb Stunden sind wir doch viel drauf gekommen, ja.

Aber da ist halt möglicherweise der Ausweg, irgendwie sowas wie Pi Spark zu verwenden.

Spark auch nochmal, eigentlich müssen wir dann mal ein eigenes Thema zu machen.

Aber sehr schön, das Ding ist so, dass man halt quasi Sachen automatisch verteilen kann.

Man hat sie lokal, man kann damit anfangen, dass man es auf einer Maschine hat und dann führt man Sachen auf dem Cluster aus und das ist wirklich mehr oder weniger seamless.

Das Einzige, man hat sogar einen vollständigen Python-Interpreter, das ist irgendwie nicht so eine verkrüppelte Version.

Man kann halt tatsächlich irgendwie Seitensachen damit machen.

Das heißt, man kriegt Sachen auch wirklich, wirklich schnell.

Ja, im Gegensatz zu Java.

Java geht vielleicht auch, ich weiß es nicht genau, aber ich glaube, es ist ziemlich schwer, Sachen wirklich optimiert hinzukriegen.

Während in Python ist es halt relativ leicht, irgendwie mit Seiten halt ein Dialekt von Python zu schreiben, wo man dann einen Typ Annotationen dazu schreibt.

Wo die dann halt zu C kompiliert werden, dann wird das als C-Modul und dann wird es wieder reimportiert und das kann man halt auch auf den Cluster irgendwie ausrollen, irgendwie über PySpark.

Und dass man jetzt irgendwie C-Code irgendwie in Java reinbastelt und das dann halt über Hadoop, über die MapReduce-Service verteilt, weiß ich nicht.

Kann auch sein, dass das geht, keine Ahnung, aber das klingt irgendwie nicht so leicht.

Ja, wie auch immer.

Also Spark ist auf jeden Fall auch noch eine super interessante Geschichte, vor allen Dingen, wenn es jetzt darum geht, wenn man jetzt sowas hat wie so ein Data Lake und so, und wie kommen denn Informationen rein?

Man möchte eigentlich nicht da so ITL-Jobs machen, das funktioniert alles nicht mehr, möchte auch Echtzeit, Dashboards haben irgendwie.

Und dann muss man halt auf so eine, oder sollte man, dann wechselt man halt irgendwann auf so eine Streaming-Architektur, wo halt Dinge auf der Webseite, also auch gerade wenn man jetzt sowas hat wie, also auch Amazon wird, selbst wenn man die Bestellungen nimmt oder so, das ist alles noch nicht Big Data, aber wenn jetzt zum Beispiel Amazon, und das tun sie bestimmt, irgendwie jeden Klick, den User macht auf der Webseite, auch irgendwo irgendwo eine Faktentabelle, ihr Data Warehouse, Data Lake, Ding reinspeichern möchte.

Data Swamp.

Ja, dann wird das Big.

Weil das ist halt schon viel.

Dann ist so ein Verhältnis von Bestellungen zu, Leute machen irgendwie Web-Requests oder klicken auf der Seite rum, ist halt wahrscheinlich nochmal so irgendwie Faktor 100 oder mehr.

Und ja, dann wird es tatsächlich sehr, sehr groß und man möchte das aber trotzdem alles in Echtzeit haben.

Das heißt, man macht es nicht so, dass man diese Geschichten wieder in die Prozessdaten, in diese OTP-Datenbank reinschreibt und dann halt hinter extrahiert und batchmäßig jeden Tag irgendwie ein Analysesystem schreibt, sondern dann generiert man halt so Events, die dann halt über irgendein Streaming-Zeugs halt Service laufen, der das dann halt an unterschiedliche Consumer irgendwie ausliefert.

Und das ist meistens Kafka.

AWS hat noch eine eigene Lösung, normalerweise auch wieder den Namen vergessen.

Meinst du aber nicht die Lambda-Service, ist das was anderes?

Nee, nee, das ist was anderes.

Nächstes eine eigene, ja, aber sagen wir mal, Kafka als Beispiel, ist auch ein Apache-Projekt, das das halt sehr schön macht.

Und dann serialisiert man halt irgendwie die Daten, die man im Event hat, als irgendwie als Protokollbuffers oder sowas.

Und dann gehen die Dinger halt auch da wiederum Serialisierungsformate sehr, also es gibt halt sehr unterschiedliche Protokollbuffers, sind super, wenn man Daten übertragen möchte oder auch diese Schrift von Facebook.

Super scheiße, wenn man das halt auf die Platte schreibt.

Also es wäre halt dann auch wieder Zeilenbasiert, kann man hinterher nicht mehr gut analysieren.

Also man kann halt nicht einfach irgendwie die Events, die man generiert, als Protokollbuffers irgendwie in Kafka kippen und dann das irgendwo auf eine Platte schreiben lassen.