Ja, hallo liebe Hörerinnen und Hörer. Willkommen beim Python-Podcast in der mittlerweile fünften Episode.
Heute geht es ein bisschen um Datenmanken.
Ja, wir haben wieder diesen schönen Wintergarten vor uns.
Ich bin der Dominik und natürlich dabei ist wie immer der Jochen.
Jo, hallo. Genau, Datenmanken. Ja, voll gut. Da freue ich mich schon drauf.
Das ist irgendwie ein Thema, mit dem ich schon viel zu tun hatte.
Das wird wahrscheinlich eine ein bisschen längere Episode.
Wir versuchen wieder ein bisschen Struktur reinzubekommen.
Wir wissen noch nicht ganz, ob 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ätzliche Infos der Sendung in den Shownotes.
Ja, wollen wir das eigentlich vielleicht noch erwähnen, welches Datum wir haben?
Heute ist der 24.02.2019.
Oh, wir machen jetzt mit Daten. Ja, finde ich gut.
Genau, wir haben das glaube ich schon mal gemacht.
Ja, haben wir das schon mal gemacht?
Ja, ich glaube in der ersten. Und dann haben wir es irgendwie nicht mehr gemacht.
Aber ich glaube, es ist wahrscheinlich eigentlich ganz interessant, wenn man das hört,
von 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 irgendwie 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 wir so ein bisschen länger auf die letzte Folge warten mussten.
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 mal 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äher bringen kann.
Ja, wobei 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 drumherum kommen, 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, ja.
Ja, wir werden noch ein bisschen darauf eingehen, was ist das überhaupt, ne?
Datenbanken, Unterschiede in 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 haben 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.
Und genau, Amazon hat bestimmt die da 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 daran 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 jetzt Python 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 eine Struktur, die man sich ausdenken muss.
Das ist gar nicht so trivial.
Das ist recht wichtig, dass man da so ein bisschen mehr Gedanken dazu macht.
Wie sieht denn meine Struktur der Daten überhaupt aus?
Und was soll ich denn damit machen?
Wie würdest du da direkt vorgehen?
Ja, also das ist halt, das kommt tatsächlich.
Auf den Anwendungsfall an und was ich halt in der Praxis im letzten Jahrzehnten so durchgesetzt
hat, sind relationale Datenbanken.
Aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre
Berechtigung.
Alle, die das noch nicht drauf haben, also so SQL oder NoSQL.
Ja, genannt 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 Steine.
In der Bibliothek das Pickle-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 Byte-Folgen oder Strings nehmen und die String-Folgen
halt zahlenweise 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 Pfeilen, schreibt
das Ganze in einen Pfeil.
Genau so habe ich das auch bei meiner ersten versuchten Datenbank-Operation 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 einem Spiel.
Und dann habe ich das Ganze in einem Spiel.
Und dann habe ich das Ganze in eine Zeile gepackt und die zahlenweise 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 das 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 CSV schreibt oder sowas halt.
Dann wäre es halt noch menschenlesbar.
Da muss man sich halt überlegen, wie man die CSV.
in Objekte verwandelt oder Objekte wieder in CSV-Zeilen.
Ich habe einfach den Dictionary-Code in eine Teile reingeschrieben, habe das dann ausgelesen und evaluiert.
Das 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 Web-Entwicklung auch häufig gemacht.
Das nannte sich dann Flat-Files, Datenbank mit Flat-Files.
Man hat einfach den State da irgendwie rein.
Und natürlich ist auch das File-System ja schon irgendwie eine Art Datenbank.
Das ist halt eine hierarchische Datenbank, die halt so eine Baumstruktur hat.
Und deren Blätter halt Files sind, Wurzel ist halt Root/ bei Unix-Systemen oder 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 Verzeichnis-Lese, die es da gibt, auch schon so Metadaten definiert, dass man halt weiß, so bestimmte Sachen sind halt in bestimmten Verzeichnissen so.
Und das Ganze gibt es halt auch über Netzwerk-Geschichten, indem man das so hierarchisch, die bekannteste hierarchische Datenbank im Netz.
Das ist halt so was wie LDAP, Windows nennt das irgendwie Active Directory oder ist auch vielleicht noch ein bisschen komplizierter.
Und ja, das ist halt schon mal eine grundsätzliche Art, wie man wie man Datenbanken betreiben kann.
Aber vielleicht etwas, was ich mich ganz gerne auch noch mal einsetzen 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?
Und wenn das halt eigentlich auch gut in den Datenbank-Kontext 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, meisten ausgerollte Datenbank-Lösung der Welt, dann 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, ganz, ja.
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 ist denn eigentlich Daten, was sind eigentlich Informationen, was sind eigentlich Wissen, da hört man umgangssprachliche Definitionen, die halt, wo man dann weiß, was das ungefähr sein soll, aber wenn man das jetzt aus dem Datenbank-Kontext her 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 ja kein Bezug dafür ist, minus 3,5, was denn?
Ja, genau, richtig.
Grad Fahrenheit, ne?
Und, ja, 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 Temperatur, das heißt, man weiß halt, das steht jetzt in der Temperaturspeise,
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 Positionen hat,
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 hat halt Wissen über, wie das Wetter 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, so und so, oder irgendwie sowas.
Ja, genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.
Oh, 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.
Die werden wir heute, glaube ich, nicht machen.
Doch, doch, doch.
Ja, doch, doch, doch, alle.
Okay, ihr müsst heute lange, lange Geduld mitbringen, oder eine große Runde durch den Park, oder ihr könnt gerne zur Wohnung putzen, heute.
Ja, ich bin mal gespannt, wie schnell wir da durchkommen.
Aber ja, ich denke, das ist eigentlich vielleicht ganz interessant, mal so einen groben Ü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.
Ja, ich halte ich so ungern davon ab, so ins Detail zu gehen, weil ich finde das unheimlich interessant, was da alles noch so drinter steckt.
Ich bin ja sehr curious, was man noch alles so findet und die Details sind halt auch irgendwie wichtig, ja.
Ja, stimmt. Wir schauen einfach mal. Ich hoffe mal, dass es nicht allzu lang wird, aber.
Okay, ja, dann fangen wir doch direkt mal mit dem Beispiel an, oder wolltest du noch so ein paar grundsätzliche Dinge über Daten?
Einmal grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken, auch um halt dann, ja,
ja, 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, gab es schon ganz lange und ja, Sachen in Flatfiles oder irgendwie strukturierten Dateien hat man auch schon lange.
Und dann irgendwann 1971, glaube ich, ist ein Paper rausgekommen von Ted Kott und der hat sich halt Gedanken darüber gemacht, wie man eigentlich dieses Problem, ich möchte wissen, irgendwie speichern und dann irgendwie
Dinge damit später machen, wie man das so grundsätzlich angehen 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 kältesten war in Deutschland oder so, dann fingen Leute an, dann Algorithmen zu schreiben, die für die Art, wie sie die Daten gespeichert hatten, halt, ja, das Problem gelöst haben, genau.
Und jeder, der halt die Daten irgendwie anders speichert, muss sich halt einen neuen Algorithmus überlegen, wie er das macht.
Und das ist ja eigentlich ziemlich blöde, also das 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-Management-System, das dann halt weiß, wie man irgendwie diverse Arten von Indizes baut oder so, dem diese formalisierte Anfrage vorzulegen und das Ding sucht sich dann die beste Art, wie man das dann löst raus und macht das dann für einen.
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 Zahlen irgendwie unterschiedliche Dinge drinstehen, die dann nicht zu suchen haben, oder?
Ja, weil sie halt nicht normalisiert sind, weil es nicht so wirkliche...
Oh, jetzt kommen wir direkt mit den Normalisierungen, ja.
Weil es nicht wirkliche Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es halt alles schon.
Und da gibt es dann auch bestimmte Regeln und Constraints irgendwie überprüft und so.
Tabellen, die auf Tabellen zeigen oder sowas.
Genau, genau.
Ja, und das wird in Excel halt alles nicht gemacht.
Und ja, das ist halt, das ist in der Praxis ein relativ großes Problem, denke ich.
Das ist halt, ich habe das, auf den kommen wir später noch zurück vielleicht.
Der heißt Simon Willison, der hat für den Guardian...
Vor zehn Jahren ungefähr irgendwie so im Bereich Datenjournalismus irgendwie, da gab es das schon.
Heute ist das 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 ein 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 er nach diesen Daten fragen konnte.
Wusste, wo man die bekommt und so, super.
Aber das Problem ist jetzt, also der Simon Willison, also er 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, in welchen Daten, in welchen Files.
Da ist so ein Ordner im Schrank, da kann ich mal blättern.
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 Domänen.
Die Menschen aus dem Archiv.
Ja, die aber dann nicht unbedingt jetzt so Datenmarktspezialisten sind.
Und die machen dann halt Excel-Files und tun das irgendwo hin.
Aber das funktioniert halt nicht gut, weil...
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 man hat das dann irgendwie auf einem Netzwerk-Share.
Und dann muss man sich irgendwie Bescheid sagen, wenn man das ändert.
Oder man macht das irgendwie über komisch benannte Dateinamen oder sowas.
Und das ist natürlich alles total furchtbar.
Also man benutzt dann im Grunde zwei Datenbanken, die nicht wirklich dafür geeignet sind,
was man dann macht.
Nämlich einmal das Filesystem, 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 aus meiner Perspektive auch so die beiden Dinge, wo man...
Wenn man Daten organisieren möchte.
Wenn man in Firmen so leichte Gewinne, die man machen könnte.
Also die beiden Themen, die halt vollkommen unter...
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.
Immer bitte den Git-Flow.
Ja.
Aber in den meisten anderen Abteilungen, wo es nicht um Programmieren geht,
die haben von solchen Dingen noch nie irgendwas gehört.
Da nimmt man Tipp-X und mal da kurz die Buchstaben, die falsch sind, raus und malt dann da drüber.
Und wenn man wüsste, was da vorher stand, dann muss man das Tipp-X abkasten.
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 Git oder...
Tabelle 1, Tabelle 1 neu, Tabelle 1 neu, neu, neu, final.
Und ja, jetzt jetzt wirklich.
Also da könnte man mit wenig Aufwand...
Reichen.
Und eben auch da irgendwie, 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...
Ich habe das gerade gehört, das war gerade ein super kurzer kleiner Nebensatz.
Wenn man kurz irgendwelche Daten erzeugt, so für den Management-Layer.
Ja, das ist, denke ich, in Grundform viel.
Wenn die Leute da so Excel mit irgendwelchen Makros drin oder irgendwelche Skript-Schnipseln drin haben, warum die das verwenden.
Ja, 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.
Und dann geht was an der 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.
Und 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.
Das geht man dann mit Stunden, um Stunden, um Stunden, um Stunden.
Genau, aus Programmierersicht ist es 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 VBAs natürlich noch so ein...
Extra-Problem.
Das soll übrigens bei 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 man halt wahrscheinlich...
eigentlich nicht machen können wird, ist sowas wie mit PIP irgendwie Dinge nachinstallieren oder so.
Selbst wenn es mit Python jetzt die VBA ersetzen würde.
Gut, man hätte schon den Vorteil natürlich, dass die Standard-Bibliothek von Python sehr viel mächtiger ist,
als das, was VBA kann.
Aber es ist halt immer noch nicht...
Also es gibt diverse Probleme, die noch gelöst werden müssten, damit das alles wirklich 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 eigentlich wäre das, was viele Leute damit machen,
die wären 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 da mehrere Leute drauf zugreifen und Dinge ändern,
dann sorgt die Datenbank dafür, oder das Datenbank-Management-System,
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 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 sich andere Paradigmen durchgesetzt haben.
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.
Ja, der Vollständigkeit halber, um mal zu sagen, was es sonst noch alles gibt.
Es gibt halt Dokumentendatenbanken.
Ja, gibt es auch schon ganz lange.
LotusNotes ist ja so ein Beispiel für...
Populär.
CouchDB, MongoDB, die fallen auch in diesen Dokumentendatenbank-Bereich rein.
Lösen halt so ein bisschen unterschiedliche Probleme.
CouchDB löst so ein bisschen das Problem, dass ich nicht unbedingt 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 LotusNotes-Dings-Projekt kommt.
Es gibt Key-Value-Stores, wo man einfach nur irgendeinen Hash irgendwie...
Also man kann sich das vorstellen wie ein Python-Dict.
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 Memcached.
Oder so oft zum Cache.
Aber manchmal können sie auch kompliziertere Sachen oder weiter strukturierte Daten.
Berkeley-DB war lange ganz groß.
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 Bigtable, 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, dass man da so ein bisschen mehr Daten hat.
Die Dinger sind halt dafür gedacht, gigantische Datenmengen irgendwie zu speichern.
Und das halt machen sie dann irgendwie eher so spaltbasiert.
Cassandra, Apache Cassandra ist auch so ein Projekt, das das genauso macht.
Dann ein komplett anderes Paradigma sind Grafendatenbanken.
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.
Und dadurch, dass man halt beliebige Beziehungen im Grunde zwischen Knoten irgendwie hat,
das ist jetzt ein bisschen abstrakt.
Weiß ich auch gar nicht genau, wie ich das erklären kann.
Vielleicht kann man das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.
Vielleicht kann ich das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.
Genau.
Aber das ist halt so eine ganz andere Art von Datenbanken.
Da würde ich sagen, das hätte auch sich anstelle von relationalen Datenbanken durchsetzen können.
Ja.
Und genau, auch das, was mit dem Semantik-Web vielleicht haben manche Leute,
davon schon gehört, so RDF, Tuppel-Stores, das ist auch alles im Grunde Grafendatenbanken.
Okay, Semantik-Web, ja, machen wir später.
Genau.
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 spezielle Art, das zu indizieren, das ist Suffix-Trees.
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 jetzt in solcher Funktion
in so verbreiteteren 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 ja, okay.
So, keine Ahnung, MySQL oder Postgres.
Ach so, 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, Sybase, das wären so die kommerziellen.
Ja, Geschichten, DB2 von IBM, ja.
Oder zur Historie, im Grunde die, nachdem dieses Paper irgendwie, das ist übrigens sehr,
das sollte man nicht schon uns packen, das ist sehr empfehlenswert, das sich mal anzulesen von Headcourt.
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 DB2,
auch von IBM entstanden irgendwann, aber halt Oracle bezieht sich auch da drauf, 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 das war für Bilder irgendwie.
Und dann ist das Ganze zu Postgres geworden.
Und wurde dann zu einer normalen, relationalen Datenbank sozusagen.
Und das ist auch faszinierend, also dieses ganze Postgres-Projekt ist der Wahnsinn eigentlich.
Das hat halt irgendwie Mitte der 80er ist das gestartet oder halt, wenn man Ingress dazu zählt, noch früher.
Und ist jetzt über 30 Jahre wahrscheinlich, hat das auch einen Buckel und ist immer noch top.
State of the Art.
State of the Art immer noch dabei.
Das kommt 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,
die Advanteste, die fortschrittlichste Open-Source-Datenbank.
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 bei, als Backend für Webseiten verwendet man normalerweise 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.
Ja, 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 das letzte Mal, gut, das ist jetzt auch schon lange her,
dass ich da irgendwie Artikel zu gelesen habe, aber das letzte Mal, dass ich das gelesen habe,
war Stack Overflow tatsächlich unter den Top Ten der traffic-stärksten Webseiten weltweit.
Und die haben dafür, Hardware war irgendwie so ein halbes Rack oder so.
Und das ist natürlich schon extrem beeindruckend.
Das ist überhaupt sowas, was halt wahrscheinlich viele Leute nicht wissen,
die jetzt wieder nicht so viel Erfahrung haben mit Datenbanken.
Die können echt wahnsinnig viel Dinge tun gleichzeitig und so.
Also man kriegt aus so einer ordentlich konfigurierten und getunten relationalen Datenbank
schon so mindestens ein paar tausend, vielleicht auch ein paar zehntausend Requests oder Statements pro Sekunde raus,
die die halt verarbeiten können.
Und dann kann man natürlich eine Menge machen.
Also vorausgesetzt der ganze Kram passt in den Hauptspeicher.
Aber man macht keine Dinge, die das irgendwie langsam machen.
Also es ist halt auch nicht so einfach, das zu optimieren.
Aber ja, genau.
Und das ist halt auch dieser Bereich der relationalen Datenbank.
Das ist halt der größte Datenbankbereich eigentlich.
Ja, vielleicht kommen wir dann, wollen wir zu dem praktischen Beispiel.
Ja, mit dem Beispiel, genau.
Das wäre 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...
Nehmen wir doch mal an, wir wollen jetzt Amazon nachbauen.
Wir haben einen kleinen Buchhandel in der Garage.
Ja, und wir überlegen uns jetzt so...
Da liegen jetzt ganz viele Bücher auf dem Boden.
Und dann will irgendjemand bestellen.
Dann muss dann irgendjemand in die Garage laufen, gucken, wie ist denn jetzt der Titel?
Habe ich den?
Dann liegt ein Buch unter dem anderen.
Das wäre natürlich doof, wenn man erstmal alleine 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 Mitteilinformationen über diese Bücher,
also sowas wie Titel, ISBN-Preis und so...
Autor.
Genau, 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...
Wenn man jetzt 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 umbenimmt, 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 Ersetze machen und dann machen wir sowas,
dann machen wir für jedes Jahr,
das wir für Bestellung haben 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 Ersetze ausführen und dann den Namen ändern.
Ist doch super, oder nicht?
Ich könnte sagen, 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 Autotabelle ändern
und dann wäre das
automatisch in allen Zeilen
in allen Bücher
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
drinstehen.
Ja, wäre auch eine Möglichkeit, genau.
Und
ich überlege gerade,
das ist jetzt natürlich
also Autoren, ein Beispiel,
ein 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 Datenbank
Normalisierung, 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 fräst es halt an der anderen,
dann hat man halt
ja, einmal ist es dann inkonsistent
das Verhalten und ja,
man hat halt auch die Gefahr, dass
dass man Dinge, die man einmal gefixt hat, halt dann
nochmal auftauchen.
Das ist doch bestimmt schon ein, zwei Mal passiert, oder? Also mir hat das früher ständig passiert
und dann ist mir irgendwann aufgefallen, oh, ich mach
eine Funktion und dann macht man die Funktion und dann macht man einen Test
und dann ist es halt erledigt
sozusagen. Also
sollte man halt möglichst versuchen, Dinge, die man
so 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 weist sich so ein bisschen mit 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 nennt das halt
Join, ja, das heißt, man kann halt anhand von
diesen Verzweigungs-,
also Fremdschlüssel-Dingsies
kann man halt Tabellen aneinander
ketten.
Ja, verketten.
Man kann sich das vorstellen, man legt die halt sozusagen
nebeneinander, sodass halt die
Spalte mit dem Schlüssel übereinander liegt, ja,
sozusagen, und wenn man das mit vielen macht, dann werden die Abfragen
langsam. So ein bisschen wie an so einen Spielautomaten,
wenn ihr so einen einahmigen Banditen
habt, dann zieht ihr einmal dran, da sind ja so drei verschiedene,
und wenn ihr dann parallel so ein Alles-Zeit-Gewinn,
dann habt ihr den Schlüssel, den ihr braucht.
Dann hat man
die Zeile anhand von dem Schlüssel irgendwie
zusammengeführt, ja, genau.
Und, äh,
ja, ähm,
also, ähm, also das ist halt auch, wie man
ein Schema designt und so, das ist halt so ein bisschen
Kunst, und man braucht Erfahrung dafür,
ähm,
ähm, aber man kann halt sagen, ja,
man sollte das so ein bisschen normalisieren, also
meistens gibt es dann ganz viele unterschiedliche Normalformen,
und meistens die Formen,
die man dann so hat, ist so irgendwas zwischen dritter
und vierter Normalform, oder so,
zwischen dritter und Boy-Scout-Normalform, oder sowas,
aber ich möchte gar nicht so sehr im Detail darauf eingehen,
was jetzt die Unterschiede zwischen den Normalformen sind,
also 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 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
einen 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?
Bastel ich da einfach irgendwo rein, ergänze ich dann dieses Schema
einfach, oder? Ja,
das kommt darauf an, was das dann für eine Änderung ist,
also das ist ja auch so ein Problem,
man kann
Datenbanken
nicht so richtig super ändern,
also, relationelle 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 alte Datenbanken noch kompatibel sind, oder sowas?
Ja, dass
man das so ändert, dass nicht
irgendwelche Inkonsistenzen entstehen, und auch
das halt... Wie wäre das jetzt bei unserem
Beispiel, beispielsweise?
Also, wenn ich mir jetzt überlege, ich brauche
jetzt eine neue Spalte in dieser Büchertabelle,
ja, weiß ich nicht, es gibt jetzt nicht nur
die ESPN...
Jemand, oder das Genre, oder sowas,
jemand 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 Text
statt Kategorie
und sagt jetzt,
okay, alle Texts, also weiß ich nicht,
Politistik,
Seephara-Roman, oder
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,
warum man das nicht so machen sollte, ist halt, dass es die
Anfragen halt schwierig macht und dass man
es auch sehr schlecht ändern kann und dass, wenn man
was ändert, kann man Sachen kaputt machen,
weil
Inkonsistenzen entstehen können und so.
Dann zieht man erst mal diese Dinge
auseinander und sagt halt, okay, nicht in
einer Spalte
mehrere Texts reinschreiben, sondern
dann hätte man sozusagen eine
N-zu-M-Relation, also nicht nur, wo ein
Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel in der anderen Tabelle
passt, sondern man hat dazwischen den Link,
man hat jetzt einmal Text als Relation
und einmal halt die Bücher als Relation
oder als Tabellen halt und
dazwischen hat man jetzt noch eine Link-Tabelle
oder eine Link-Relation zwischen
Büchern und Text, sodass man
mehrere, also für jedes Tag hätte man dann sozusagen
einen Eintrag in der Link-Tabelle,
wo dann drin steht,
ID von diesem Buch, ID von
diesem Tag, ja, und das ist dann halt sozusagen
die Verbindung
zwischen den beiden Tabellen, sondern halt
eine Tabelle mit allen Texten, die ist möglicherweise gar nicht
so lang, es gibt vielleicht nur 1000 Texte oder so,
und
vielleicht ein paar Millionen Bücher und
jetzt hat man halt eine Link-Tabelle, die
wahrscheinlich dann irgendwie ein paar 10 Millionen Bücher
oder ein paar 10 Millionen
Zeilen oder so lang ist, wo halt
jedem Buch ein paar Texte
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 Text halt,
wenn man diese Texte 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
Grafenstrukturen.
Das kann man dann auch machen, und wenn es
nicht viele Texte oder Kategorien sind,
dann würde man versuchen, das wahrscheinlich in erste Z
nehmen.
Das ist, kann man sich mal angucken,
wenn einen 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 dann jede,
man hat so eine Kategorie in Baum und man schreibt
dann an jede, jedes
Element in dieser hierarchischen
Struktur, den travisiert man einmal
First Order, ich weiß
gar nicht genau.
Und 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
in den Baum, schreibt man halt die
Nummern links rein und dann rechts, wenn man
rechts dran vorbeiläuft und dann kann man so Sachen
Range-Abfragen dazwischen machen
und magischerweise führt das dann dazu, dass man
so Subbäume rausselekten kann und so.
Aber das ist dann halt schon so wirklich fortgeschritten.
Und im Endeffekt,
wenn man jetzt große
Grafenstrukturen hat oder Bäume,
dann wäre es wahrscheinlich besser, das gar nicht mehr in der
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,
wenn man das in der Relationalen Datenbank gut machen kann.
Ja, also das Dorfschachtrekarat ist mittlerweile
rausgewachsen, also wir können die ganzen Bücher dann
in der Garage nicht mehr lagern.
Nee, nee, nee, Moment, Moment, wir sind noch nicht, also was eigentlich auch,
nee, wir sind noch nicht
so weit, wir sind noch immer bei der ganz normalen, einfachen
Datenbank, würde ich sagen.
Ja, also das,
wofür wir die nämlich auch brauchen, die Datenbank,
ist halt so Transaktionen-Prozessen,
wenn jemand was kauft zum Beispiel. Oh, jemand hat bei uns
eine E-Mail geschickt, hat gesagt, hey, habt ihr das Buch da?
Und wir gucken nach, sagen ja,
können wir dir schicken. Dann, ja,
bitte 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 das im Lager ist. Das heißt, wenn
jetzt ich ein
Buch verschicke, dann sage ich 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... Ihr fällt direkt
wieder eines der Probleme ein.
Zwei Leute wollen das gleiche Buch haben,
was nur noch einmal da ist und die wollen gleichzeitig eins
kaufen. Genau, das ist halt
eine problematische Geschichte.
Aber wenn man jetzt eine Datenbank hat,
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...
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%
dieser Kunden einfach gar nicht am Ende kaufen,
sondern irgendwie wieder abspringen, weil die dann sagen, naja, doch nicht.
Und dann hätten
jetzt 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 sitzt
halt vor der Webseite und
machst nichts.
Oh, leider war jemand schneller und hat vor zwei Sekunden...
Genau, du kannst, sobald du draufdrückst, in dem Moment,
wo sozusagen diese
Bestelltransaktion gestartet wird und dann
in der Datenbank aber die Bedingungen,
es muss mindestens eins im Lager sein, damit
die Bestellung ausgeführt werden kann, nicht mehr erfüllt ist
und diese Constraint wird verletzt,
dann sagt die Datenbank so, geht
nicht. Und dann kann man ihm so eine
Fehlanwendung 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
blöd wäre, ist, wenn man dem User sagt,
okay, du hast das jetzt bestellt,
und dann sagt er am Schluss so,
äh, du kriegst doch kein Buch, weil
war keins mehr da. Das ist dann 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
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
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, dein Überweisung wurde
vernünftig ausgeführt, und dann
zwei Wochen später
kriegte ich dann so eine Mahnung, und dann habe ich noch mal
aufs Konto geguckt, und die Transaktion war weg.
War nicht da. Was war, habe ich dann da angerufen,
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
ein, ja, also
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-Prozessen gibt,
nachts. Also die Sparkassen haben das
lange gemacht.
Man schmeißt dann manuell die ausgedruckten
Briefchen ins Überweisungs...
Lochkarten. Fährt jemand mit den
Lochkarten dahin, und dann kommen die in so einen Laser, und dann werden
die da durch, und vielleicht, wenn dann 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 ja gerade bei der Bank eigentlich, wenn man sich
denkt, na, sollte eigentlich nicht. Aber, ja,
aber wenn man
ein sauberes, relationales Datenbanksystem
verwendet, dann
kann das
eigentlich nicht, oder sagen wir 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 darauf verlassen.
Ja, 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, Transaktion 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 muss erzeugt werden, dann muss
irgendwie aus dem Lagerstand
irgendwie
rausgelöscht, 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
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. Und 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
eine Tabelle, das Ding erzeugt,
sag jetzt in der
Lagerstandstabelle
dieses Buch eins weniger, und dann sagt das,
hier habe ich eigentlich von Strand auf, es darf nicht
weniger als null werden, also minus eins Bücher
ist schwer, das funktioniert irgendwie
nicht so richtig, dann sollte
und es dann knallt,
dann kann das natürlich,
wenn ich jetzt ein System habe, das keine Transaktion kann,
dann hätte ich jetzt die Bestellung zwar immer noch da,
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 nebenan, 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 wollen.
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, ne?
Ziel, wann das... Ja, genau,
wenn normal produziert,
aber dann verändert sich möglicherweise das Ziel dafür, wann es halt
ausgeliefert wird, oder so, ne?
Und das ist 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 drinsteht,
was ich überhaupt alles machen will, machen kann,
und wenn mir irgendwelche neuen Dinge einfallen,
oder so, dann muss ich kurz
überlegen, was
nicht an meinem Schema endet, aber
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 halbwegs so designen,
dass es halt passt, das ist
später nicht mehr so ganz einfach, das zu ändern,
man kann das natürlich ändern, aber
das ist auf jeden Fall...
Ja, aber das hängt ja ein bisschen vom Geschäftsmodell ab, ne?
Wenn ich jetzt auf einmal merke, so, oh, ich verkaufe
jetzt vielleicht gar keine Bücher mehr, sondern,
weiß nicht, kompliziertere Produkte, oder so was,
die noch einen anderen Aufwand haben, die jetzt nicht nur getaggt
werden sollen, sondern wo noch mehr
Metainformationen drin sind, irgendwelche
anderen Snippets, also der Buchtext vielleicht
noch, oder andere
Informationen, die dazugehören, oder so,
dann wäre das ja notwendig.
Ich kann ja nicht jedes Mal einen Neudankmann anfangen, sondern ich muss ja auch
gucken, dass die irgendwie mit skaliert.
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
ist, finde ich, iTunes,
der App Store,
und der App Store war am Anfang,
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
den 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 10 Jahre später,
bis heute
haben halt irgendwie Apps einen Titel
und eine Länge, Songlänge oder sowas,
was halt totaler Quatsch ist, das 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, und
also 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 drumherum gibt, die sich verlassen,
dass die Datenbanken so aussehen, wie sie aussehen.
Also wenn ich jetzt, also die Daten selber zu ändern,
ist, glaube ich, wäre nicht so das Problem,
weil ich muss jeden Prozess bei jedem Nutzer dieser Datenbank
darüber informieren, dass er sich das Schema...
Und der muss damit klarkommen, und das
ist halt möglicherweise Legacy-Code,
der letzte, der sich damit auskannte,
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.
Manchmal
sieht man dann so ein bisschen lächerlich aus, aber
wie jetzt in dem Apple-Fall,
wenn man keine Songlänge hat,
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
Kappa enthält, oder sowas.
Also, dass sich 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 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.
Das ist sehr unwahrscheinlich, dass das passiert, weil
das würde bedeuten, dass sich die physikalische
Realität irgendwie ändert, was sie ja
natürlich auch tut.
Aber das tut sie relativ langsam.
Und das ist gut,
weil das können relativ,
wenn 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 nichts.
Da ist wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig viel dran.
Und da 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.
Ja, 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
wenn man das, manche nennen das auch
Schema-less, 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.
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-less ist, halt auch nicht
Schema-less, sondern das bedeutet halt mehr oder
weniger nur, 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
dann nicht so richtig und dann ändern sie irgendwas. Dann passieren
furchtbare Dinge und
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, ja, es ist immer so schön, irgendwie
Daten
altern wie Wein, ja, 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,
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 ein 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 Modülchen an der Seite,
und auch das Problem ist halt, die Anforderungen
verschieben sich halt irgendwie
oder, sagen wir mal 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, ja, genau
dieses Problem,
dass, wenn man jetzt das Schema verlagert
in die Applikation und die Applikation aber
altert wie Fisch, dann halt man halt auch, ja,
dann altern auch die Daten nicht gut und
deswegen ist es eigentlich schon sinnvoll, eine Trennlinie zu haben,
um zu sagen, okay, selbst wenn wir die
Applikation 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 strikte,
ein striktes Schema hat und das
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
das halt
bestimmte Datumsinformationen halt nicht
so und so sein können,
ja,
oder
dass man halt,
tatsächlich, auch
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 wir jetzt,
um in diesem Buchhandelsbeispiel zu bleiben,
du hast jetzt eine Büchertabelle,
da sind natürlich auch 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 Facette Navigation, wo
du nach Kategorien einschränken kannst
und da klickt jetzt ein User drauf
und sagt, okay, ich hätte jetzt da gerne
Romane oder Seefahrer-Romane,
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 Postgres tun, man kann
dann sagen so, also
ich brauche diese Einträge,
in der Buchtabelle noch, um halt,
damit die referenzielle Integrität, so nennt man das
halt, von alten Bestellungen nicht bricht,
die ja brechen würde, wenn ich
zu einfach löschen würde, dann hätte ich
halt einen Pointer in der Bestellungstabelle,
der halt auch 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 den Index so definieren, dass er nur
Sachen,
Bücher mit reinnimmt,
die halt auch tatsächlich noch verkauft werden,
und das heißt, das ist nicht so,
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
halt, und da hast du dann halt ein Problem, wenn du ganz,
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
ja, 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
A-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, Brawl-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,
Doch, doch,
Ja, ja, wenn du
deine Lagerhaltung,
das möchtest du im gleichen System machen, damit
du nicht das Problem kriegst,
dass du den Start-State zwischen
unterschiedlichen Systemen synchronisieren musst, also wenn du
jetzt deine Lagerhaltung in einem System machst und
machst dann deine Webseite
oder die Datenbank, die die Webseite
betreibt,
sozusagen, ü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
kommt dann sonst direkt ein Fehler aus der Datenbank, hey,
nur dürfen wir nicht, geht nicht und wir haben das Schema
dabei erarbeitet in unseren kleinen Laden und so sollten wir dann
Und dann kann dann die Applikation oder die Programmierer
die jetzt vielleicht gar nicht,
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 hoch auf minus eins setzen,
dann sagt ihnen die Datenbank, ne, 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 was Blödes passiert.
Der Datenbank steht jetzt minus zwei Bücher und dann
sagt die eine Datenbank, du sagst aber eigentlich nicht, dann sagt die
eine Datenbank, ja, hab ich aber. Und dann, ja, okay.
Da kommst du halt in Teufels Küche.
Also man könnte sich vorstellen, dass das eine gute Idee wäre,
weil 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 man Sachen funktionierender
rausnehmen und man muss dann das
in mehrere Systeme aufkleinern. 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?
Klein und niedlich, wir haben
Postgres, machen alles
über Postgres, wir haben noch ein bisschen JavaScript
auf der Client-Seite, ansonsten
nehmen wir, sagen wir mal, Django oder so
als Web-Framework.
Also genau, jetzt kommen wir erstmal zu
wie machen wir jetzt Python?
Genau, da brauchen
wir halt irgendeine Art, wie wir auf die Datenbank
zugreifen.
Üblicherweise, wie man
Statements oder Abfragen an eine Datenbank formuliert, ist halt
SQL, heutzutage halt so der Standard
für solche Systeme.
Aber das ist halt immer ein bisschen Fremdkörper.
Code schreiben und 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
machen, der irgendwie vernünftig aussieht und
da muss dann alles stehen, was mit der Datenbank reden 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 File 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. Das hat den Nachteil,
dass man unter Umständen mehrere Statements,
die sehr ähnlich oder gleich sind, an
unterschiedlichen Stellen hat.
Alles nicht so total toll.
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 normale
Python-Code.
Man definiert
die Daten, die man in der Datenbank stehen haben
möchte, einfach nur als Klassen.
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 neppt,
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
N-zu-M-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ß jetzt irgendwie
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 der
Tabelle. Also, Attribute
der Klasse sind halt Spalten in der Tabelle.
Und sagt man halt, das hier ist ein Many-to-Many-Beziehung
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 Beziehungen 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
Kladderadatsch, die 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
ruft man halt zuerst auf und damit
werden halt so Migrationsskripte in Django
angelegt. Das sind auch einfach
nur Python-Files, in denen drinsteht, was
diese Migrationen tun sollen. 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
Nutzer taggen selber
und erfinden eine neue Kategorie.
Ja.
Ich überlege gerade,
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 einen SQL-Syntax
und man schreibt das halt einfach in eine Migration rein.
Ja, 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 da die
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 man 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's 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. Also
keine so gute Unterstützung in den Frameworks für sowas
gab. Da hat man das halt irgendwie von Hand gemacht
und 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 fragt
irgendwie so, also hast du die Migration jetzt eigentlich auf der
Produktionsdatenbank schon ausgeführt oder nicht?
Ja, ja, hab ich gemacht.
Das ist vielleicht auch nicht passiert.
Also es wäre 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
kommen so wirklich relativ vollständige
Wir merken wieder, du bist ein Django-Fan.
Ja, ja, Art damit umzugehen.
Ja, kann man Flask, wenn man jetzt das andere
große Web
ja, Framework kann man jetzt
nicht da so wirklich zu sagen, aber die andere Paradigmen,
wie man Web-Anwendungen
in Python entwickelt,
wenn man das in Flask macht, hat man das
auch alles, ja, da gibt es dann SQL-Alchemy
als ORM
und halt, ich weiß jetzt nicht, das hat
einen Namen, die Migrationslösung
dafür, den entdecke ich mir jetzt gerade
nicht erinnern, und da geht das
alles auch. SQL-Alchemy ist sogar deutlich mächtiger
als der Django-ORM,
aber ist halt nicht integriert.
Und, ja, also
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 upgraden kann
und so, dafür wird gesorgt, da muss man selber sich nicht drum 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 Peewee,
und Pony-ORM oder so
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 Method-Chaining.
Ich weiß nicht, sagt dir das was?
Bis jetzt nicht.
Ja, gibt's auch so oft in
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,
wieder noch was anderes, Punkt, wieder noch was anderes.
Wenn zum Beispiel eine Methode
ja ein Objekt zurückgibt, dann kann man auf diesem
Objekt wieder was anderes aufrufen.
Wenn ich das alles in eine Teile schreibe, wird das irgendwann relativ
lang. Aber wenn ich jetzt ein Statement
modellieren möchte, das halt viele Where-Bedingungen
hat, die Art, in Django
ORM das hinzuschreiben, wäre halt zu sagen, Filter
irgendeine Spalte
gleich
irgendeinen Wert oder sowas.
Aber dann hab ich noch ein zweites, dann sag 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 mach hinten noch eine weitere Klammer drumrum,
dann kann ich das halt auch einrücken. Und dann
rück ich das so ein, dass alle Punkte untereinander stehen.
Und dann hab 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, dass
jedes Mal irgendeine Zwischenvariable zuweisen zu müssen.
Ansonsten könnte ich ja
natürlich sagen, Query-Set gleich, Query-Set, Punkt, Filter,
irgendwas. Und dann sag ich in der nächsten Zeile,
Query-Set gleich, Query-Set, Punkt,
Filter, noch irgendwie eine andere Spalte,
where, irgendwas.
Ich kann das aber auch alles in
ein einziges Dings reinschreiben.
Und man nennt das
Message-Chaining.
Ja, und das ist halt irgendwie
das, bei
Pandas ist es halt genauso, da hat man Data-Frames, auf denen man
Sachen macht, und die geben dann auch immer
wieder ein Data-Frame zurück, die Fehler der Methoden.
Und die kann man halt auch so chainen. Und dann hat man da oft
so mehrzeitige Dinge, wo halt die Punkte untereinander stehen.
Also wenn man nicht weiß, was das ist, das ist Message-Chaining.
Und das ist halt so eine Methode, um
Dinge halt in eine
State zu... Irgendwie schon mal ein bisschen gesehen, aber so wirklich
wissen, was das Message-Chaining heißt, ist natürlich...
Ja, genau. Und
im Grunde ist es halt dann, wenn man
OEMs, wenn man Queries in OEMs 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 Optimierung
machen möchte an den Statements,
dann wäre die halt
auch immer gleich.
Das heißt, dann habe ich halt dieses Problem,
dass ich sonst hätte, wenn ich das alles in einen
File schreiben würde, oder 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,
das ist einer der Hauptnutzen von OEMs, 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 jetzt klein und niedlich,
und das haben wir jetzt gemacht.
Genau, und dann würde man so ein Framework verwenden, OEM,
und dann ist man eigentlich,
ja, das geht alles ins Git,
gibt Versionskontrolle dafür, und dann
das ist eigentlich alles schon relativ komfortabel.
Ähm,
ja.
Ähm,
Ja, was passiert jetzt? Also wir sind klein,
und jetzt haben wir das schon gebaut, aber
ja, wann funktioniert das denn nicht mehr so?
Äh, ja.
Ähm,
genau.
Wir haben als Onlinehandel einen
riesen Vorteil gegenüber
stationärem Buchhandel, weil
das ist auch eine interessante Statistik.
Das kommt, glaube ich, aus diesem,
ähm, Buch-Longtail, irgendwie,
äh, von, wie soll ich sagen, von
Wired-Redaktion, ah, weiß ich, hab den Namen vergessen.
Äh, jedenfalls, ähm,
schreibt er da, dass Amazon
macht die Hälfte des Umsatzes mit
Büchern, die nicht in den Top 300.000 sind.
Mhm.
So, äh, weil eben
Bücher verkaufen, äh,
so ein, so ein,
oder verkaufte Bücher hat so eine Longtail-Verteilung.
Also es gibt halt
äh, sehr, Leute wollen sehr
unterschiedliche Bücher kaufen. Also 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 Innenstadt-
Buchladen kann ich halt
irgendwie ein paar tausend Bücher haben.
Äh, und dann ist halt irgendwie Schluss.
Und dann muss ich mir überlegen, welche das sind. Aber wenn jetzt,
also, nehmen wir an, ich hab...
Das hat aber auch ein Zielpublikum. Das heißt, ich weiß genau, hey,
in mir kommen jetzt nur ganz wieder alte, antiquarische,
ähm, 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 sie bei IT wissen, sollte ich vielleicht in ein IT-Buchladen.
Ja, ja. Aber selbst, selbst wenn du
jetzt, äh, all diese Zielgruppen zusammennimmst
und dann irgendwie das riesige, den riesigsten,
äh, also, das ist halt das Problem. Wenn die
Zielgruppe zu klein ist, dann lohnt sich das
nicht. Äh, aber wenn sie, äh, selbst
wenn du jetzt einen riesigen Buchladen hast, in dem 300.000
Bücher passen, was äh, ziemlich groß sein müsste,
dann machst du
immer nur, äh, trotzdem noch die Hälfte des
Umsatzes von Amazon, weil
Amazon macht halt nochmal so viel Umsatz mit den
ganzen Rest. Das heißt, sie haben dann, sie können
einfach viel besser skalieren,
weil sie einfach viel mehr Bücher verkaufen.
Und, ähm, ja, dagegen,
ich wüsste nicht, dass es da irgendein Mittel gegeben gibt.
Ich fürchte... Was aber auch bedeuten würde, dass Amazon
auch diese Minus-Eins-Bestellung annehmen müsste, weil das
müssen sie auch irgendwo in einem riesigen Lager 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. Äh, auch der
stationäre Buchhandel geht ja irgendwie dann damit um,
so damit um, dass man dann halt Sachen da bestellt.
Zum Beispiel, äh... Hey, Autor, schreib doch
bitte nochmal eine neue Vorstellung.
So ein paar Bestellungen, ja.
Aber, äh,
ja, ich meine, du hast halt als, äh,
als stationärer 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. Äh, und dann kannst du...
Okay, und dann ist es cool, weil dann können wir einfach mit unserer
Postgres-Lösung direkt so unter dem ORM...
Genau. Die interessante...
Also mit 3.000 Millionen, also mit 3.000 Millionen ist das überhaupt kein Problem,
äh, also da könnten wir auch, also ich würde sagen,
so ein 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.
Äh, wenn es jetzt
nur darum geht, die Bücher zu verkaufen.
Aber, äh, wenn wir
jetzt, äh, zum Beispiel eben sowas rauskriegen
wollen, wie, äh,
was sind eigentlich die Top 300.000 Bücher?
Wo kommt denn diese Zahl eigentlich her?
Ja, und, äh,
ü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, äh, müssen wir, äh, nicht nur
die Bücher speichern, sondern dann müssen wir halt
auch, äh, speichern
zum Beispiel, welche Bücher gekauft worden sind und so
und die, also die Historie aller Bestellungen und so.
Und das ist dann halt unter Umständen
viel, viel mehr.
Und, äh, dann, äh,
wird es allmählich problematisch, weil dann haben wir
unterschiedliche, äh, Use Cases,
äh, oder unterschiedliche Abfragemuster.
Also wir haben zum Beispiel diese
Transaktions, ähm,
äh... Also das Lager, das einfach immer noch
weiß, wie viele Bücher sind da und das schicken wir raus.
Oder wir haben jemanden, der macht Marketing oder sowas.
Das System, das macht halt Bestellungen, oder wir haben halt Anfragen, die
Bestellungen machen oder solche Sachen wie
zeig mir alle Bücher in, äh, Seefacher-Romane
oder so. Äh,
aber die, diese Art von
Anfragen wie, sag mir mal, wie viel Umsatz
ich mit den, äh,
äh, äh, nicht in Top 300.000
enthaltenen Bücher im letzten Jahr gemacht habe.
Das ist eine ganz andere Art
von Anfrage.
Ja, während die, die Anfragen vorher, die machen
immer nur auf kleinen Datenmengen in der Datenbank,
irgendwas, immer zeilenweise meistens.
Und, ähm,
oft ändern sie auch irgendwas oder schreiben
irgendwas. Aber gut, Großteil, wenn man noch die
große Mehrheit wird Read-Anfragen
sein, aber die, äh, beziehen
sich normalerweise nicht auf wahnsinnig viele
Daten, äh, Teilen, sondern immer nur relativ
wenige oder wenige tausend Zeilen.
Und, ähm, ja, eben operieren halt
auch ja 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, äh, 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, diese
Abfrage-Muster beißen sich halt massiv.
Mhm, mhm. Äh, wer, also,
weil, äh, das Problem ist, dass die
Datenbank irgendwie gewährleisten muss, dass die,
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.
Du musst hier irgendwie alle Daten, die in der Datenbank
liegen, oder einen Großteil davon, musst du dir sicher angucken,
wenn sie dir hinterher so was sagen,
eine Zahl geben will, wie viel Umsatz waren das jetzt so.
Ähm,
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, oder es,
ja, und sozusagen, es wird dann halt ein Timestamp
mit reingeschrieben, es wird halt, nein, das ist Multiversion
Concurrency Control. Äh,
Multiversen! Ja,
Multiversion Concurrency Control,
das heißt, die Datenbank
ist halt in einem unterschiedlichen Zustand,
je nachdem, wer sie, wer gerade fragt.
Und für die Transaktionen, die eine Bestellung ausführen, ist sie jetzt
in einem anderen Zustand als für dieses langlaufende
Query. Und 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,
wenn das Problem ist, wahrscheinlich wird man dann halt
irgendwann sehen, man wird so mit einfachen Analysegeschichten
anfragen und irgendwann wird man halt merken, so morgens um neun
wenn dann halt irgendwie die, die, äh,
äh, Business Intelligence
Abteilung irgendwie anfängt, äh, wenn
da die Analysten sitzen und dann irgendwie, ja gut,
ich weiß nicht, am Anfang wird man sowas noch nicht haben, aber
irgendwann wird man das gleich dann, wenn die halt ihre
Analysequeries abschießen, dann
wird plötzlich die Webseite langsam.
Ja, weil halt die Datenbank langsam wird,
weil die Queries werden langsam, weil, äh, plötzlich
äh, muss die, äh, muss die Datenbank
irgendwie mit mehreren, äh,
Zuständen irgendwie rum
jonglieren. Ja.
Das ist blöd. Und dann muss man sich halt, äh,
sowas überlegen. Und, äh,
das ist dann halt so der Moment, äh,
wo man dann sagen muss, okay, wir, 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, ähm,
ja, also das eine nennt man,
äh, auch, äh, irgendwie OTP,
ja, Online Transaction Processing.
Das ist halt sozusagen der
Webseite, also Datenbank ist hinter
einer Webseite, die irgendwie Bücher verkauft und, und Prozess
hier Transaktionen, Bestellungen.
Und der andere Teil nennt sich, äh,
OLAP, äh, Online Analytical, äh,
Analytical Processing.
Und, äh, ist halt das so, wenn
man das mal gehört hat, irgendwie, wenn Leute über Data Warehousing
sprechen oder Data Warehouses oder so, das ist halt
das. Ähm,
und, äh,
genau, äh, das sind beides
meistens relationale Datenbanken,
wenn man anfängt jedenfalls.
Äh, aber die sehen
unterschiedlich aus. Äh, also wir haben
unterschiedliche Anfragen werden gestellt.
Ja, Analyseanfragen sind oft, laufen
länger, gucken sich viele,
viele Zeilen an.
Äh, Transaktionsanfragen sind oft
kurz und, ähm, ja, gucken
sich wenige Zeilen an. Und da geht's auch darum,
dass die Latenz relativ kurz ist. Bei vielen Analyseanfragen
ist das gar nicht so wichtig. Äh,
dass die jetzt, ob die jetzt eine Minute oder länger
oder weniger lang laufen, ist gar nicht so, gar nicht so
entscheidend. Und auch die Analyse-Datenbanken
sind oft viel, viel größer, weil man halt historische
Daten mit drin hat. Äh, was
halt für eine Transaktionsdatenbank tödlich wäre, weil
die, bei der es möglichst das
komplette, äh,
Working-Set der Datenbank im Hauptspeicher,
damit das halt alles schnell geht, damit die Latenz
äh, niedrig bleibt,
damit halt die Webseite schön, äh,
sich schön snappy irgendwie anfühlt.
Äh, und
bei, äh, bei den, den Analyse-Datenbanken
ist dabei unter Umständen wichtig, dass ich
halt historische Daten da halt auch mit drin haben kann.
Und die sind, werden dann halt vielleicht so groß,
dass man das halt nicht mehr im Hauptspeicher halten kann.
Ja, aber, äh,
die Queries werden dann halt langsam,
aber das ist halt möglicherweise,
wichtiger, historische Daten zu haben, als dass
Queries halt schnell sind. Und dann, äh,
wenn, wenn sich eine, eine Query
irgendwie ein paar Millionen oder 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,
das hat dann auch irgendwie wurscht.
Ja, äh, genau. Und dann, äh,
hat man eben diese beiden unterschiedlichen Systeme
und dann kriegt man halt aber auch genau diese Probleme,
die man dann hat, wenn man mehrere,
mehrere Sichten auf die Welt,
äh, hat oder einen Status, äh,
irgendwie eines, man hat jetzt keinen gemeinsamen Status
mehr, sondern man hat jetzt, äh,
äh, den Status
des Systems in
unterschiedlicher Form in unterschiedlichen Datenmanken.
Äh, das heißt,
man muss jetzt zum Beispiel die Transaktionen, die irgendwie
in dem einen System aufgelaufen sind, überführen
in das Analyse-System.
Äh, das macht man
üblicherweise bei einem Prozess, der nennt sich, äh,
ETL, äh, Extract, Transform,
Load. Und man halt die, äh,
Daten, die einen interessieren, halt täglich oder so.
Also meistens fängt man so, so was an wie,
ja, das sind halt dann Jobs, die nachts laufen,
äh, wenn halt die Datenmangel sowieso nicht so
unterlasst sind, weil nicht so viele Leute, äh,
äh, einkaufen, äh,
liest man halt irgendwie alles, was einen so
interessiert, dann aus der Transaktionsdatenbank aus.
Dann, ähm, ist der, der
Transformationsprozess halt sowas wie,
ich muss die Daten in ein anderes Schema transformieren.
Und das ist halt so wie so Stern
ist da, äh, Schema, äh, Schema oder
Snowflake-Schema, je nachdem.
Ähm, das ist auch
irgendwie gewisserweise normalisiert oder, man kann auch
sagen, denormalisiert, je nachdem.
Ähm, aber es ist halt auf jeden Fall anders.
Äh, es ist halt davon optimiert, dass ich bestimmte
Daten von Analysen fahren kann.
Und lädt das dann ganz,
lädt das Ganze halt in die, äh,
in, in, in, in, in das
Analyse-Datenbank-System.
Für deine BI. Genau.
Äh, ja.
Und, äh, äh,
ja, das ist,
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 es denn
jetzt machen? Wenn wir Python jetzt haben, jetzt haben wir ja irgendwie so
ein neues System und jetzt haben wir eigentlich irgendwie,
das ist unser, äh, OLTP-Datenbank
System, war aufgebaut mit den Transaktionen für unsere
Webseite. Was bauen wir denn da, damit wir
jetzt so ein OLAP-Ding dranhängen können, weil wir
die analytische Abteilung einstellen? Ja, machen wir auch mit, mit
Postgres, äh, so ein Ding, äh,
da. Also eine zweite Postgres-Datenbank, eben die erste
Packung. 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.
Äh, wenn man sagt, okay, äh, vielleicht
für die letzten, für die letzte Woche haben wir alle Daten
noch im Hauptspeicher, ja, dann aber für den letzten
Monat oder für die letzten sechs Monate haben wir die halt
auf SSDs oder so, auf ein System, was halt
noch schnell, weil, weil der größte
Teil wird, äh, der Queries geht natürlich
auf Daten, die relativ aktuell sind.
Und dann ab einem Jahr oder so, so liegen die Daten
dann vielleicht auf Platten,
äh, die halt dann eher
langsam sind, aber da nur ein kleiner Teil der
Queries 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, äh,
und das ist halt ganz anders beim, äh,
im Vergleich zum OLTP-System,
wo man halt sagt, das muss alles
mehr oder weniger im Hauptspeicher sein. Und, äh,
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 SSDs nehmen,
aber es ist halt nicht wichtig,
viel mehr Plattenplatz zu haben,
als man Hauptspeicher hat, weil das will man ja eh nicht.
Mhm, mhm. Ähm,
ja, äh,
und, ähm, genau,
diese LTE, diese LTE-Prozesse sind dann halt
irgendwelche Skripte, die dann halt irgendwie
über irgendeine Task, äh,
ja, Skandalik lösen. Ja, das läuft natürlich dann,
das ist unser Business Intelligence-System, also
jetzt nicht sekundengenau funktioniert.
Ja, genau. Weil wir halt immer wieder diese Jobs
machen müssen. Wenn wir uns jetzt an was
ganz anderes denken, weiß ich nicht, Aktienkursanalyse
oder sowas, wir haben irgendwelche Portfolios, dann
ist das natürlich dann doof, ne, weil
dann das nicht dem echten Stock-Market
entspricht dann, sondern wir müssen das halt
dann jedes Mal eine neue Kopie machen, wenn man diese
Analytics fahren will. Ja, ja, genau.
Also, äh, natürlich, das ist, das ist tatsächlich
ein Problem. Und, ähm,
die, die Lösung
dafür ist, dass man dann halt, äh, irgendwann nicht
mehr so ETL in dem Sinne
macht, dass man das halt irgendwie abends Batch-Processing macht,
äh, sondern dass man halt
irgendwie so Streaming-Geschichten, äh,
verwendet, halt, äh, Apache Kafka
und so ist halt etwas, was häufig verwendet wird.
Aber da kommen wir später zu, weil das ist auch eine
Geschichte, wo man, dann, das wird
halt eh, äh, erst dann relevant,
wenn man, wenn man dann
nochmal ein gutes Stück größer geworden ist und
man, äh, mit den traditionellen Data-Warehouse-Geschichten
auch nicht mehr klarkommt. Und der Weltbeherrschung
ist unikat. Ja, genau,
dazu muss man dann schon mal noch ein bisschen, oder halt
eine andere Art von Daten sammelt, ne.
Ähm, also ich würde sagen, dieser klassische,
äh, Bereich, ja, selbst wenn man halt, äh,
nur tagesaktuelle Daten hat, ist man damit
wahrscheinlich viel besser aufgestellt
als jetzt wahrscheinlich viele stationäre,
äh, Buchhändler oder so, ne. Selbst das, äh,
wird einen schon, äh,
wird einem da schon einen deutlichen Vorteil verschaffen. Und ich denke
mal, am Anfang ist es halt so, dass, das ist halt das, was alle
machen, womit alle irgendwie anfangen, dass sie das halt
tagesweise oder so, äh,
Batch-mäßig, äh, äh, erledigen.
Und, äh,
genau, ja, da ist man halt, äh,
irgendwie so bei diesem Data-Warehousing-Thema. Ich hab da
das mal irgendwann, ähm,
äh,
das ist auch in den Shownotes verlinkt, gibt's einen, äh,
schönen Essay, äh,
äh, der heißt, äh,
Data-Warehousing for Cavemen. Ah, ja, genau.
Das ist von 1997 oder so.
Aber, äh,
das finde ich nach wie vor gut, ist auch relativ humorvoll.
Äh, da geht's darum, äh,
der, der schreibt auch so,
ja, vielleicht interessiert es manche Leute irgendwie, wie man
da einer Dollar die Stunde, äh, verdienen kann, indem
man irgendwie die sensibelsten Daten von irgendwelchen Firmen
massiert. Muss ich sofort wissen, ja.
Genau, weil beim Freelance ist das vielleicht gar nicht
so uninteressant. Ja, und, äh,
also, das ist auch ein Feld, das es schon lange
gibt. Äh, ich hab das am Anfang aber auch nicht,
ähm, ich hab zuerst nur diesen
OTP-Use-Case gekannt und dann hab 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 Data-Warehousing-Kram
zu beschäftigen. Aber es ist auch ein sehr interessantes Thema.
Also, der, der, der entscheidende Punkt ist im Grunde,
dass man halt solche Abfragen machen
können möchte, wie,
äh, also, wie unterscheidet sich
denn jetzt, äh, keine Ahnung,
das Volumen der verkauften Bücher in einer bestimmten Kategorie,
nachdem ich irgendeine Werbeaktion gemacht habe, ja.
Oder, äh, B-Tests,
ja, ich hab jetzt irgendwie manchen Usern,
mh, bestimmter, äh,
ja, die haben halt ein Design gesehen, das ein bisschen
anders aussah oder halt, äh,
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,
und, genau, ich möchte hinterher gucken, was ist denn dann
passiert, ja. War das jetzt erfolgreich oder nicht? Oder wie erfolgreich
war denn das? Und, ähm,
ähm,
ähm, dafür muss ich halt, äh,
ja, äh, bestimmte
Arten von Anfragen, die ansonsten
keine Rolle spielen können, gut machen können.
Und dafür hab ich halt so eine Struktur. Ich hab eine
Fakten-Tabelle und dann drumherum Dimensionstabellen,
in denen halt solche Sachen drinstehen, wie,
ja, das war jetzt ein User, äh,
für den ich, dem ich diese Version
der Webseite angezeigt habe. Oder das
hier, äh, äh, also man hat zum Beispiel sowas wie,
daran kann man's vielleicht ganz gut
verstehen, ähm,
Time ist halt eine Dimension. Und in der Fakten-Tabelle,
also Fakten wären sowas wie Bestellungen,
äh, ist halt, äh,
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,
und das ist halt eine,
ähm, Dimensionstabelle, in der drinsteht,
was diese Zeit bedeutet, und dann
stehen da eben solche Dinge dran, wie,
naja, also, auch da wiederum,
kann sein, dass dann, also, da steht nicht
weg der Zeitstempel, sondern da steht dann dran, also,
das war ein Werktag. Das war ein
Feiertag in folgenden Bundesländern.
Äh, das war, äh,
keine Ahnung, ähm, das war Sommer.
Ja, sodass ich dann halt solche Abfragen machen kann, wie,
äh, wie ist denn der Verkauf der Bücher
in dieser Kategorie im Sommervergleich
zu Winter? Ja, 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, und so.
Äh,
aber solche Abfragen machen halt in, in dem OTP-Teil,
oder wenn ich jetzt eine Webseite, machen überhaupt
keinen Sinn. Das heißt, ja,
die Schemata sehen dann halt ganz anders aus.
Äh, ja, äh, genau.
Wenn einen interessiert, wie das, wie das wirklich so
ordentlich funktioniert, also ich finde, dieser, dieser
Data Warehousing for Kaverman-Essay ist ein schöner Start.
Äh, aber da gibt's auch jede Menge,
kann man sich, kann man sich durchlesen, wie, wie das so
klappt. Ähm,
ja, äh,
genau.
Ach so.
Äh, richtig, genau. Da haben wir jetzt
schon mal ein bisschen über den Analyse-Teil gesprochen,
aber wir haben natürlich auch ein Problem, wenn
jetzt Leute immer mehr Zeugs kaufen,
ähm, dass irgendwie, äh,
halt unsere, äh, unsere Datenbank
halt vielleicht irgendwann ein bisschen langsamer wird,
nicht mehr, nicht mehr genug Transaktionen prozessen kann.
Ja, was macht man da? Man muss halt optimieren,
das ist auch oft ein wichtiger Teil,
und es ist auch nicht so einfach, ähm,
weil mal so ein, äh,
die einzige Datenbank,
für die ich das wirklich mal gemacht habe,
so, äh, war, war jetzt eigentlich MySQL,
ich verwende heutzutage eher Postgres, aber,
äh, äh, da hab ich dann auch mal so ein, so ein
Optimierungs-, äh, MySQL
Performance-Optimierungskurs besucht,
äh, und,
äh, das, äh, schönes Zitat, also,
äh, Chris Köntrop hat den, den damals
irgendwo in München, äh,
äh, durchgeführt, äh, der damals
hat da bei MySQL gearbeitet, und,
ähm, der, äh,
der Einsatz, der mir auch in Erinnerung
geblieben ist, der meinte so, ja, wenn man Datenbank
Performance optimieren will, ja, so,
OLTP, ähm,
dann gibt es da eigentlich, äh, so im Wesentlichen
drei Sachen, die man tun kann, um eine Datenbank
schnell zu machen, ja, also, das Erste,
was man eigentlich immer machen kann, äh,
das ist, das funktioniert auch fast immer,
äh, das ist, äh,
das ist super, kann einfach mal ein bisschen mehr
Hauptspeicher reinstecken in die Datenbank, ne, das ist schon mal
auf jeden Fall schneller, das, das ist immer gut.
Und das, wenn das
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.
Und das dritte Ding ist...
Das dritte Ding ist, wenn man
an eine Grenze gekommen ist,
die dann auch...
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 reinstecken.
Okay. Wie viel Hauptspeicher
hat denn dann so eine große Datenbank?
Ja, so viel, wie halt geht eigentlich.
Also es kommt 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 es egal.
Da kommst du halt
mit einem, weiß ich nicht,
mit der Beliebigkeit,
mit einem Raspberry Pi kannst du das machen.
Das ist wurscht. Aber
wenn du jetzt,
sagen wir mal so, wenn dein
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, eher so 64 vielleicht.
Hauptspeicher.
Weil es gibt halt auch noch diverse Strukturen, die im Hauptspeicher
gehalten werden, die man halt auch
braucht.
Und dann ist halt
das Limit eigentlich nur, also sagen wir so,
das ist halt viel.
Nehmen wir an, wir haben das, was heute
so ein Sweetspot ist, sind es halt
vielleicht 256 Gigabyte oder so.
Hauptspeicher.
Da geht eine ganze Menge rein.
Also es ist halt,
ist 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, wenn man jetzt an sowas denkt, wie
Google, man indiziert das Web und möchte
halt so ein Echtzeit-Suchabfragen
über alle Webseiten machen, das geht nicht mehr.
Das ist klar.
Aber so
viele...
So groß müsste man werden. Also Amazon,
fällt da bestimmt auch nicht rein. Also Amazon
hat...
Na gut,
Amazons Teil, der einen jetzt mit Produkten
versorgt,
diese Webseite, das wird nicht so groß sein.
Die haben andere Teile, die halt
dann unter Umständen sehr groß geworden sind, aber
ja, das kriegst du eigentlich alles locker
in einer Datenbank unter.
Die haben dann halt ein anderes Problem. Amazon wird das Problem bekommen,
dass die 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 die
fast alle Anwendungsfälle heutzutage
ist das halt groß genug.
Ja, ab
256 Gigabyte wird es ein bisschen schwierig.
Also man
kann auch einen Terabyte Hauptspeicher irgendwie
in den 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, das ist ja so
ein bisschen PC-basiert und
so viel Hauptspeicher-Wandbreite hat man da ja nicht.
Und das wird dann irgendwann,
man muss ja die ganzen Prozessoren auch irgendwie mit Daten
versorgen, ja, und wenn man jetzt da irgendwie,
weiß ich nicht,
da fährt ja kein Bus hin.
32 Prozessoren oder 64 oder sowas.
So irgendwann ist dann halt, also der Sweet Spot 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 ein Terabyte,
ich hab keine Ahnung.
Für die meisten, aller, aller, aller
Anwendungsfälle 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 Gigabyte
hättest, nimm 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 alles.
Und Hauptspeicher, ja, 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 riesen Unterschied, 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 Schreibquerys,
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 Schreibquerys und Lesequerys,
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.
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,
und 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 wird dieser Slave denn aktualisiert auf den Master?
Ja, da gibt es dann Mechanismen für,
also der Master schreibt halt irgendwie
einen 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 halt eine große geografische
Differenz ist, also wenn es halt irgendwie über
den Atlantik oder den Pazifik geht oder so, klar, dann hast du halt
Zeitunterschiede, oder halt auch wenn die Last so groß ist,
dass die Slaves nicht mehr
gut hinterherkommen,
dann hast du natürlich,
dann hast du eventuell so ein bisschen Lack 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
ist auch, oft cached man das ja auch
dann nochmal irgendwie im Hauptspeicher
in Redis oder Memcache
oder so, und sagt halt ja,
also dieses Ding hier kannst du fünf Minuten lang
cachen.
Das ist ja dann auch egal, und
bei den Anfragen, die auf Slaves gehen, ist auch so
oft so, es ist halt wurscht, also so oft
ändern sich Dinge halt nicht, wenn irgendein Account nicht so richtig
stimmt oder so. Naja, nicht so
schlimm. Es gibt Dinge, bei denen das schlimm
ist, aber kommen 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's
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 halt
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 ja 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 klassischer
Lampstack-Architektur, Wikipedia-Seite,
so aufgebaut.
Du hast jetzt gerade noch zwei Sachen gesagt, die vielleicht noch mal kurz von uns
von Redis einmal eben gesprochen und
gerade vom Lampstack. 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, ist eine Message-Queue drin,
kann teilweise sortierte
Listen und sowas auch halten,
aber kann ein bisschen
mehr als Memcached.
Memcached 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 Memcached, vor allen Dingen durch den
Lampstack. Lamp ist einfach Linux, Apache,
MySQL, PHP
und einige
der größten Webseiten, die das halt
benutzt haben
oder ich 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 ist ja auch Wikipedia
eine der, ich glaube, die sind auch mit Sicherheit immer noch
in den Top 10 der weltweit
teufelstärksten Seiten und
haben halt auch viel dazu veröffentlicht, wie
ihre Architektur aussieht.
Und die haben halt auch genau das, die meisten Sachen sind
Leseranfragen, 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 Memcached, die 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?
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. Memcached, 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
einmal so grob die Wahl zwischen,
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
Redis sozusagen, dass das verwendet wird.
Datenbank, eigentlich würde ich auch sagen,
Postgres wird bei beiden verwendet.
Man kann auch was anderes nehmen natürlich. Ja, 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 beziehungsweise
Django ORM
und Redis, genau, als
in Memory Cache und
ja, wahrscheinlich braucht man auch noch ein Message
Queue-System.
Ist aber
dann auch schon, also dann gibt es noch so ein paar Sachen, die man
braucht. Was ist denn die Message Queue?
Also man hat oft so Dinge,
wo man dem User möglicherweise
etwas direkt
eine Antwort
geben will, aber
es ist halt ein Job, der dann irgendwie länger
dauert, wie
in unserem 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 so 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
wenn wir den ja vielleicht noch prüfen,
also wenn das jetzt irgendwas Populäres ist.
Sag mal so, du
oder
das könnte jetzt
hässlich geworden sein.
Das tut mir leid, da muss ich mich entschuldigen.
Bisschen erkältet.
Ja,
ähm
wenn
also eigentlich möchte man halt
wenn jetzt zum Beispiel ein Artikel ist, der häufig
verkauft wird, ja, und dann jemand schreibt irgendwie
der Artikel ist voll scheiße, keine Ahnung
ähm, das hat ja dann unter Umständen direkt
äh, äh, Konsequenzen
oder es macht am besten noch irgendwie ein Mitbewerber
äh, macht irgendwas fieses, äh, irgendwie
ähm, ähm
ja, dann will man das möglicherweise nicht, dass das sofort
allen sichtbar wird, sondern man muss halt
irgendwie erst irgendwie, ja
irgendeine Redaktion drauf gucken oder so
äh, aber das ist halt nicht
etwas, was man dem User anzeigen möchte, also
ähm, man hat dann halt sozusagen etwas
so zwei Prozesse, die voneinander so ein bisschen entkoppelt
sind, so man, man, der User drückt auf Speichern, sieht
seinen Kommentar oder seine Bewertung und
ähm, im Hintergrund gehen aber dann noch
so Tasks los wie, oh, das ist hier
an der Stelle, wo jemand mal drauf gucken sollte
äh, aber das geht halt dann auch nicht in Echtzeit
sondern das wird dann halt irgendwie in so eine
ja, in so eine Queue, in eine Warteschlange
eingereiht, ja, dann gibt's 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, äh,
das, diesen, diesen Job, äh,
in die Warteschlange tun und dieses, dieser, 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, äh,
irgendwie, schreibt dann halt irgendwie diesen
Job in die Queue, genau, solche Sachen
hat man oft, auch wenn sich, äh, auch
genau, ha, das ist ein gutes Beispiel
das ist mir jetzt eingefallen
äh, vielleicht möchtest du, dass
wenn du jetzt in der Suche, äh,
nach irgendwas suchst, dann
Produkte halt auch vielleicht Bewertungen finden, in denen
jemand über das Produkt gesprochen hat oder so
das heißt, der Text, äh, deiner
Bewertungen muss indiziert werden von der Suchmaschine
äh, 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, äh,
für, äh, so, das hier muss
ja noch mitindiziert werden, aber es wird nicht sofort
indiziert, weil das, ähm,
ist halt etwas, was lange, eine Operation
lange dauern kann und man möchte ja nicht, dass der
äh, Web-Request dann
so lange dauert, wie die Operation dauert, sondern
man sagt, okay, man gibt dem Web-Request,
es ist 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, Task-Queues
die halt, wenn man ein komplexeres, äh,
Web-System hat, dann braucht man sowas halt,
weil solche Fälle halt immer wieder auftreten
ja, äh, kann man
aber Redis auch für verwenden, äh,
also was für Django ist halt, was häufig
verwendet ist, Salary, kann ich nicht unbedingt
empfehlen, ist irgendwie eher schmerzhaft, ähm,
ja, äh,
die unter, drunter liegenden Geschichten
sind oft sowas wie RabbitMQ oder so
im Allgemeinen ist das Protokoll irgendwie AMQ
psch, irgendwas, weiß nicht genau
ja, aber das ist nochmal ein ganz eigenes, ähm,
äh, Feld mit diesen ganzen Message-Queues
ähm,
ja, äh,
genau
Master-Slaves-Architektur
hatten wir jetzt, äh, ja,
genau, ähm, irgendwann
kann natürlich auch sein, dass das nicht mehr, äh,
dass das nicht mehr reicht
und dann müssen wir halt, äh,
irgendwie die Datenbank auftrennen
also wenn zum Beispiel grad die, äh,
das wird sich, das wird sich nach einem Böden
die Schreiblast groß genug geworden ist
dann, äh, geht das halt alles nicht mehr
äh, und dann kann man halt
äh, die Datenbank muss man dann auftrennen
das ist furchtbar, weil dann verliert man eine ganze
Menge der Vorteile, die man halt, äh,
hat, wenn man eine Datenbank hat, eben referenzielle
Integrität, äh, 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 alles Dinge unfassbar
viel komplizierter, deswegen sollte man das möglichst nicht
tun, ja, also, wenn man die mal verkauft, äh,
irgendwie, ja, also,
unser System ist super, weil das schadet
automatisch oder sowas, also das ist nicht etwas, was
man haben will, ja, also wenn das, wenn man
klein genug ist, dass man das nicht braucht
sollte man das nicht machen, weil das bedeutet halt, dass man
diese ganzen Dinge, die einem sonst die Datenbank
quasi schenkt, selber machen muss
in den Applikationscode und das ist halt, äh,
sehr, sehr schwierig
äh, aber manchmal geht's halt leider nicht anders
dann gibt's halt zwei Möglichkeiten, man schadet irgendwie
äh, horizontal, also man sollte
so lange, man nennt das Upscaling
äh, so lange wie möglich die Maschine
größer machen und mehr Hauptspeicher reinstecken
äh, wenn das halt dann irgendwann tatsächlich nicht mehr geht
dann, äh, muss man halt, äh,
entweder horizontal oder vertikal
schaden, äh, und das ist halt
aufzahlen, das heißt, horizontal
äh, man...
Mehrere Maschinen, die die gleiche Datenbank benutzen?
Nee, das, äh, äh, nee, die gleiche
Datenbank würde einem ja nicht helfen, wenn es zu viele
Ja. Ähm, dann muss
die Daten, Datenbank halt irgendwo trennen
und die Frage ist, wo trennt man jetzt auf?
Man kann halt entweder... In Tabellen oder...
Innerhalb von Tabellen die Zeilen auseinander trennen
das wäre eben horizontal skalieren, dass man dann 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
Mhm.
Ähm... Oder so regional halt Queries trennen
von wo kommt die denn jetzt oder sowas?
Ja, regional kann man natürlich auch trennen
äh, das ist dann nochmal, nochmal eine andere
äh, wäre nochmal eine andere Geschichte, könnte man auch
machen, das heißt aber, das wäre quasi horizontales
Schaden auf den Usern
Mhm. Ja, nach Region eben
Äh, das wird, also, dass man
also meistens würde man auf Usern
schaden irgendwie tatsächlich, ja
Man halt sagt, wo, was ist das für ein User
und dann, ja, entweder regional
oder halt irgendwie
so sonst irgendein Hashwert
oder so, ähm
äh, und vertikal
wäre halt, man trennt
äh, nach Tabellen auf, das heißt
man sagt, okay, wir haben hier ein System, das kümmert
sich um die Bücher, wir haben ein System, das kümmert sich um die User
wir haben ein System, das kümmert sich um
Lagerhaltung, das, das wäre halt
äh, man teilt dann nicht quasi in den Zeilen
sondern man teilt halt an den
Tabellengrenzen
Mhm. Ähm... Ja, macht
natürlich so vollständig, abfragen dann ein bisschen langsamer, oder so
Ja, das Problem ist dann halt, dass man mehrere
äh, Systeme fragen muss, wenn man jetzt
irgendwie was machen, also wenn man jetzt die
Amazon-Seite anzeigen möchte, dann
äh, 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, äh,
irgendwie haben sie Artikel darüber geschrieben
äh, damals nannte sich
das nicht, also heute läuft das Ganze unter dem Stichwort
irgendwie, Microservices oder so
nennt man das dann, dass man halt, äh
äh, Teile eines Systems
äh, in kleinere Services auslagert
ähm,
damals, äh, nannte sich das
anders, war aber quasi eine gleiche Idee
äh, nannte sich, äh, äh
äh, Service-Oriented
Architecture
äh, und Amazon hatte das Problem, dass sie
auf der Hauptseite, also wenn du einfach nur Amazon.com
eingegeben hast, äh, dann
wurde dir halt das Ding aus, die Seite ausgeliefert
aber damals war es halt
schon so, dass da so viel Zeugs
drin war, also dann werden dir irgendwelche Empfehlungen angezeigt
dann wird dir irgendwas
angezeigt, wo wie viel 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
äh, die Seite
anguckst, oder so ein paar hundert, ja
ähm, da das
irgendwie, ähm
da die irgendwie nur sequentiell ausgeführt
wurden, äh, macht das halt die Latenz hoch, weil
äh, ja, synchron
äh, sequentiell, das heißt
die ganzen Latenzen addieren sich auf
das heißt, allein bis die ganzen
äh, SQL-Statements abgearbeitet sind
vergehen ein paar hundert Millisekunden, äh
und die du einfach warten musst
und das ist halt scheiße, ne, man weiß ungefähr so
weiß ich, pro hundert Millisekunden droppt
dein Conversion 10%
oder so, ich weiß nicht, ne, wahrscheinlich weniger, aber
also, 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
joa, äh, und dann haben sie
halt gesagt, okay, das müssen wir irgendwie anders machen
äh, dann haben sie das halt in Services
aufgeteilt, dann haben sie gesagt, okay, wir haben hier den
Recommendation-Service, wo dann die, wo sich die
Webseite per JavaScript irgendwie
macht irgendwie ein XHTTP-Request oder so und holt sich
dann die Recommendations von diesem Service
und dann haben wir den, äh, irgendwie
keine Ahnung, Basket, äh,
Service für deinen Einkaufs, äh,
Korb oder so, äh,
und da ist halt, das Ding holt sich halt, was
für Dinge liegen da momentan grad drin und
äh, ja, ähm
genau, äh, und das
das, äh, das haben die damals so
gemacht, äh, 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
ähm, ja
genau, heute, heute würde man sagen, Microservices
du hast halt ein Microservice pro
irgendwie Ding, was du irgendwie da machst
auf der Webseite
und, äh, die komplette Seite
aggregiert nur noch, äh, irgendwie die Daten aus all
diesen Services
äh, ja, das, 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 eine Datenbank passt
dann kann man das so machen, das ist aber nicht so, dass man das machen sollte
also solange das, 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, äh, Microservices
sind halt dann, man schiebt dann halt einen Haufen
der, äh, äh
der, der, der Komplexität in eine andere
Richtung, man hat dann plötzlich Architekturkomplexität
man hat plötzlich, äh, äh
ja, sozusagen im Ops
äh, Teil von DevOps wird es plötzlich viel schwieriger
man muss halt das alles irgendwie maintainen
man muss halt plötzlich, wenn man jetzt sagt, okay, ich
ähm
äh, ich update jetzt diesen
Service, äh, also dann hängen da halt andere Dinge von
ab unter Umständen
äh, dann
hab ich halt, ich kann, ich kann
ja, sagen wir mal so, wenn man das halt irgendwie so schön
hat, Master-Slave-Architektur, Loadbalancer
davor, vor den Datenbanken, ein paar Frontends
dann, äh, selbst da
ist es schon kompliziert, wenn ich jetzt, äh, irgendwie
äh, äh, 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, ne, ich mach eine Kopie der Datenbank und
äh, die Datenbank mit dem neuen Schema
stell ich dann ins neue Master rein und so
so oft hat man dann so Sachen wie, oder
wenn man die Software updatet, man nimmt halt Sachen
äh, ja
Rechner aus der, aus der Verteilung im Loadbalancer
updatet den, oder die Hälfte
davon, und äh
äh, die andere Hälfte läuft noch auf der alten Software
und dann schaltet man halt um, oder so
ne, solche Sachen kann man machen, und das ist
das geht noch, das ist auch dann schon kompliziert, weil
man muss sich dann halt, äh, Gedanken machen
wie man das tut
und man muss halt irgendein System haben, 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
äh, 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 dann auf den Knopf drücken und sagen, okay
jetzt räumen 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, dann hat man eine viel komplexere Abhängigkeit
zwischen den Geschichten, und dann wird dieses ganze
Ops-Thema halt, äh, richtig, richtig
ätzend, ähm, auch
Skalierung wird richtig ätzend, weil
dann willst du halt, wenn du halt, ja, so
in so einer klassischen Architektur hast du nur
wenige unterschiedliche Arten von
äh, ähm
Maschinen, die halt irgendwas machen, du hast halt Datenbanken, du hast halt
irgendwie Redis oder sowas
äh, du hast halt Frontends, äh, vielleicht
doch vorne irgendwie, äh
äh, Webserver, die SSL
äh, ähm, Terminierung machen
oder so, aber, aber das war's im Grunde, also du hast nicht so
wahnsinnig viele unterschiedliche Dinge, beim Microservice
hast du halt, ja, vielleicht
hundert unterschiedliche Arten von Microservices, die du
unterschiedlich skalieren musst, wo du auch unterschiedliche Sachen
aufpassen musst, das ist alles furchtbar, also
geht, also man kriegt damit halt Sachen
in den Griff, die, äh, dann halt, wenn man
mit, äh, diesem Muster, man hat halt
eine Datenbank, in der die Wahrheit drinsteht, nicht mehr
äh, wenn das nicht mehr ausreicht, kann man
das dann halt so in den Griff kriegen, aber es ist halt
dann schon schlimm, ja
äh, genau
ähm, okay, sind wir schon ganz
groß, das heißt, wir müssen noch ziemlich viel, äh,
Bachtes haben, okay, genau
oh, das hab ich, äh, ja, was haben wir denn
äh
ja
ähm
ich guck gerade in die Liste, was wir jetzt noch
alles haben und was noch nicht, genau
äh
das ist nämlich tatsächlich relativ viel, 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 nicht ganz, nein, noch nicht ganz, na gut
dann, das ist harmlos, naja
achso, genau
was ich hier noch, ein Punkt war, es können auch
im Analyse-System auch Sachen wieder
zurücklaufen, äh, zum Beispiel gibt es halt diverse
Sachen, die gelockt werden, die dann aber trotzdem für die
Transaktionen wieder eine Rolle spielen
äh, wie so etwas, das hatten wir noch gar nicht
ist auch, äh, die Suche, ja, am Anfang
äh, man braucht ja auf jeden Fall, wenn man irgendwie so
eine E-Commerce-Seite hat, irgendwie eine, eine Suchmaschine
wo man irgendwie nach Büchern suchen kann, oder so
äh, das geht
auch tatsächlich mit Postgres direkt, voll gut
äh, hat eine integrierte, äh
integrierten Volltext-Index, ähm, ja
ja, und
äh, man möchte halt auch so eine Facetten-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
wenn es nicht um Bücher geht, sondern um
Elektronik oder so, kann man vielleicht noch Hauptspeicher
oder, äh,
VHS
oder Betamax, ja, so möchte man vielleicht
auswählen können
und, äh, genau
ähm, das geht mit Postgres
alles sehr schön, auch da kann man
äh, äh, irgendwie
die Counts für die Facetten ganz gut rauskriegen
ansonsten, wenn man das halt über eine eigene
äh, äh, ja,
Spezial-Datenbank sowas wie, äh, Elasticsearch
macht oder Lucille, äh, äh,
beides Lucille-basiert oder, 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, äh,
wenn du Sachen aus dem Index rausholst, ja,
du, äh, suchen, hast jetzt eine Volltext-Suchanfrage
und kriegst jetzt IDs aus der
Suchmaschine, dann
möchtest du aber vielleicht nach was filtern, was nur in der
Datenbank drinsteht, dann musst du nochmal auf die Datenbank
äh, da alle Daten raus,
äh, ziehen und dann nochmal Counts anders
ausrechnen, ja, vielleicht ein paar der Facetten-Counts
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, äh,
irgendwie diverse Sachen vom Datenbank,
äh, where und dann kommt halt ID in
und dann kommen tausend IDs und so,
äh, 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, ähm,
dann ist das halt deutlich
ist alles irgendwie viel einfacher
und, äh, mit Postgres kriegt man auch das am Anfang
äh, alles hin und, ähm,
ja, das ist eigentlich, äh, eigentlich sehr nett
äh, irgendwann geht das aber wahrscheinlich dann halt
eben auch nicht mehr, dann muss man halt nach und nach
Funktionen in Spezial, äh,
Services halt auslagern, ne, eine der ersten, die man
wahrscheinlich auslagern wird, ist halt Volltext-Suche
möglicherweise, das macht dann halt irgendwann
ein Listing-Search oder, oder
Solar oder so, äh,
aber halt auch, ähm, eben
sowas wie, wenn man jetzt
anfängt eine Query zu schreiben
äh, kennt man eben
Google Suggest, hatte ich eben schon erwähnt, äh
ähm, kriegt man halt so Vorschläge
das, das ist im Grunde, man
macht dann halt, äh, man sucht auf den, auf den
Query, Queries von anderen
Leuten, äh, aber dann hat man halt genau das
Problem, dass halt sozusagen
die History der Queries muss halt
irgendwie aus dem Analyse-Ding wieder zurück ins
OLTP-System oder in irgendeinen anderen Service, der
äh, auf dem 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
äh, äh, raussuchen
Ja, natürlich, wenn man tippen kann, drei, vier, fünf
Ja, ja, ja, und, äh, also man kann das am Anfang
äh, auch alles über Postgres machen, wenn's dann halt komplizierter
wird, muss man das als ein eigenes Service auslagern
und so weiter und so, dann wird's halt alles, dann wird
das System größer und schwieriger und
ja, äh, genau
und, ähm, 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, äh
äh, ja
wo du dir übel, äh, dann Sachen in halt Spezialdatenbanken
auslagern, wo du
äh, und, äh, ja
äh, bezahlt dann halt mit Komplexität
ähm
genau, äh
Ja, jetzt müssen wir nochmal, wie wir das weitermachen
genau, wir nehmen, wir nehmen Redis
zum Cachen, einfach
äh, von, von langlaufenden Queries und von
irgendwie gerenderten Fragmenten, die halt aufwendig
zu rendern sind, äh, also irgendwelche Listen von
von Dingen oder so, die sich aber jetzt nicht
äh, dauernd ändern
äh
ähm
und
genau, ähm
Ja, die Daten werden noch immer
größer und das Problem ist auch, wir sind mittlerweile weltweit
unterwegs, äh, wir verkaufen
nicht nur Bücher, wir verkaufen
alles von A bis Z
die Amazon, das habt ihr ja schon gesehen, habt ihr
den Pfeil von A bis Z
Amazon und, ähm
ja
äh, dann stellt sich ja die Frage, wenn
wir das global machen, wo stellen wir dann die Maßnahmen eigentlich hin?
Das ist halt auch schwierig
ja, äh
Wo wird der entstehen? Also in einem sicheren Land?
Ja
Wir müssen an alle Stellen irgendwie so einen kleinen
Master stellen, wo halt viel, äh, Traffic ist
Kann man den Master mirern, dass man dann tatsächlich
sagt, dass überall derselbe, äh
Ja, es gibt natürlich auch irgendwie für diese, diese Geschichten so Lösungen, dass man halt
dass die Master sich miteinander synchronisieren
das gibt's für Postgres auch, aber das ist alles irgendwie
ich weiß nicht so genau
alles nicht so richtig, das funktioniert alles nicht so richtig
und, äh, ja
da gibt's, es gibt auf jeden Fall keine nette
äh, äh, das ist halt auch ein
mehr oder weniger unlösbares Problem, also
äh, das ist auch theoretisch quasi nicht wirklich in den Griff
zu kriegen. Man kann aber
ähm, Dinge tun, indem man halt auf andere
Architekturen umstellt, man kann halt
äh, ja, also
ich hab jetzt mal hier als Beispiel genommen
diese, du willst halt, dass
manche Sachen immer funktionieren
Ja, eigentlich sollte immer
alle Sachen, möglichen Sachen funktionieren, ja
und manchmal ist dir dann halt irgendwie
die Konsistenz und so egal, ja, also
äh, zum Beispiel für Amazon super wichtig, äh
äh, ist halt der Einkaufswagen, ja
du musst halt immer weiter, das Preis muss fließen
jetzt musst du immer weiter einkaufen können
äh, auch wenn jetzt, äh, daher haben
sie das halt, ich glaub das war auch
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,
aber es 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. Und jetzt?
Also das heißt, es fällt erst so fünf Minuten später
bei Amazon auf.
Geht nicht. Wir haben jetzt zwar, hat jemand
was bestellt, wir haben die Bestellung zugesagt, du hast
eine Bestätigungs-Mail bekommen irgendwie
und jetzt fällt aber auf so, 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.
Genau, es kommt eine Entschuldigungs-Mail und sie geben dir
einen Gutschein. 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,
einfach kurz den 3D-Drucker anschmeißen,
wird schnell nachproduziert.
Ja, genau, das ist halt
das auch, was dann halt gebrochen wird
in relationalen Datenbanknehmern, das ist 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 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 APIs dazwischen.
Isolation
ist halt die Geschichte, dass du
nicht
Sachen, die andere Transaktionen machen,
in deinen Daten siehst, also das ist halt, man nennt das
Dirty Read, wenn du halt
in deiner Transaktion Dinge
aus anderen Transaktionen siehst, die noch nicht abgeschlossen sind,
sodass du halt, dass du immer,
dass deine Sicht auf die Daten
mal komplett isoliert ist. 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
lange, war es 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.
Strom aus.
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 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
zurück,
ist durchgegangen, wird zurückgegeben,
wenn das im Ride-Ahead-Log 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-Querries macht,
oder bestimmte Arten von Queries,
bei denen es völlig egal ist, ob die
super isoliert sind oder nicht, dann kannst du sagen,
dieser User hat halt
ein viel niedrigeres Isolationslevel,
der macht dann halt Dirt-Reads, aber das ist halt
egal für dessen.
So kann man Sachen deutlich beschleunigen.
Dann, was man auch machen kann,
das sollte man halt jetzt nicht tun, wenn man
Bestellungstransaktionen
prozessiert, aber
zum Beispiel, wenn man testet.
Oft hat man ja
viele Tests für eine Applikation
und es dauert lange, bis die durchlaufen,
wenn man jetzt 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,
der Cycle irgendwie
kaputt macht, wenn man dann halt
Kaffee trinken gehen muss, und das macht
auch so 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, wenn man jetzt
ein Django-Projekt hat, auch die echten Daten, auch
Postgres verwenden will, was viele Leute machen,
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 es schief.
Nicht so gut.
Aber was man tatsächlich machen kann, ist
Postgres zu sagen, ja, irgendwie nicht
absinken, macht man 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.
Ich meine, die Testdatenbank schmeißt
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 Absinthe aufrufen, und dann
ist das halt einfach langsam, da kann man auch nichts machen.
Okay, einmal ein bisschen Acid, ne?
Ja, genau, haben wir Acid.
Und dann, ja, also was wir
dann heutzutage oft haben, sehen
bei
Datenbanken,
die das halt, oder Dokumentdatenbanken,
genau, ist halt ein anderes
Party-Management, das nennt sich 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
Datenbanken
schreiben kann.
Ja.
Wir sind jetzt dann 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 Acid ist halt weg,
Pech gehabt.
Nein, wir haben noch ein anderes Ding,
das ist dann noch
das Cap Theorem,
Consistency, Availability
und Partition Tolerance,
das ist halt auch dieses, wenn man immer, wenn man so Sachen
Pick-Two-out-of-Three-Sachen sieht,
also das Cap 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 dann noch Partition Tolerance,
also was ist, wenn,
wenn Netzwerkverbindung zwischen
zwei deiner Datenbank-Dinger
irgendwie wegfällt, oder so,
das musst du halt leider,
das ist halt mandatory,
sozusagen, und
das heißt, du kannst nur noch zwischen
Consistency und Availability
halt irgendwie wählen.
Und du hast halt, ja,
dann gibt's halt Datenbanken, die dann halt
unterschiedliche Trade-Offs realisieren.
Ja.
Genau.
Das ist zum Beispiel, ein interessanter
Fall ist halt sowas wie CouchDB,
die halt,
wo du sogar, wenn du halt offline bist,
immer noch,
wo du 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,
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
unterschiedlich, die haben da unterschiedliche 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.
Das ist halt quasi dafür gedacht,
wenn du jetzt eine lokale,
wenn du eine Webseite
auf einem Smartphone
hast, oder so, und du hast halt nicht immer
Verbindungen, du möchtest
aber trotzdem, dass dich deine Webseite
so anfühlt, als hättest du irgendwie
eine Verbindung, so offline
first, oder so, jetzt
im 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,
da möchtest du nicht, dass wenn du jetzt durch einen Tunnel fährst,
dann nichts mehr geht, sondern
das geht halt mit CouchDB,
das ist halt sozusagen wie Jackfairy Lea
über dem Storage-API von deinem Browser,
weil die können das ja auch alle mittlerweile, die haben meistens
SQLite 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 liegen, 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 wirst 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-Anwendung weiter so benutzen,
als wärst du
online, und das synchronisiert sich halt
in dem Moment, wo du halt wieder Verbindungen hast,
und
ja, das ist halt dann sehr auf der
Availability-Seite, und halt dann auf der Konsistenz-Seite
halt nicht, 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,
wahrscheinlich nicht so wirklich,
wahrscheinlich haben wir es schon ganz lange geschafft,
aber, und jetzt kommt eigentlich nur noch
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, oder?
Ja, also, erstmal hört sich cool an, und also
jede echte Tablette mit mehr als, weiß nicht, tausend Teilen
kann man schon dann irgendwie fick machen, oder sowas.
Also, das kommt halt, glaube ich, ein bisschen auf den Anwendungsfall
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 treibt hier irgendwelche
Excel-Tabellen rein, also
die liegen dann halt auf irgendwelchen
Servern, oder halt auch einfach nur
Rechnern rum, und dann hat man ganz viele
große Informationen, ohne 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 sagst du?
Ja, also, genau, ich habe auch,
es gibt dann sehr unterschiedliche
Auffassungen davon,
es gibt dann Leute, die sagen so, ja, was ist nicht mehr in der Excel-Tabelle,
was ist schon so, also, ich würde sagen,
vielleicht etwas halbwegs Vernünftigeres ist halt, was nicht mehr
auf einen Computer passt, aber auch das
greift eigentlich zu kurz, ich habe dann letztens
nochmal irgendwie,
Feines Spiel ist er nun.
Ja, das war irgendein Talk von
Michael Stonebreaker, das ist auch, es gibt so,
das sind immer die gleichen Namen, auf die man irgendwie in dieser Datenmark-Welt
stößt, das sind halt so, Michael Stonebreaker,
Jim Ray,
Taccott, weiß ich nicht,
Ducatting,
das ist auch
der, der hat auch so einen
ja, der hat Postgres mitgegründet
oder Ingress vorher und dann Postgres
und auch
viele der noch moderne, der heute
jetzt ganz modernen Geschichten, wie
Column Stores, also C-Store, Papers von
ihm, Volt, wie für so
In-Memory-Datenbanken-Geschichten,
ja, der definiert
das so, der sagt halt, naja, es gibt eigentlich nur noch drei
Arten, wie Data-Big sein kann, nämlich
irgendwie, ja, es ist einfach
zu viel, ja, du hast, und der sagt halt
nicht irgendwas Konkretes, sondern halt,
du hast halt Probleme mit der Datenmenge, ja, also
es ist halt, wenn du wirklich Schwierigkeiten damit hast
und damit nicht fertig wärst, 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
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.
Ja, dann hast du auch ein Big Data-Problem,
aber halt eine andere Art von Big Data-Problem,
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 es halt nicht in den Griff. Da hast du auch wieder
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,
ich würde auch sagen, Big Data ist so ein gehyptes Ding,
und
ja, irgendwie, es gibt
ganz viele Hadoop-Cluster verkauft.
Was ist ein Hadoop-Cluster?
Ja, es ist,
Hadoop ist irgendwie so ein,
das Start ist ein
Apache-Projekt,
das irgendwie mal gestartet ist als so
Implementierung eines
Konzepts, nennt sich MapReduce,
das ist ein Paper, das hat Google mal veröffentlicht,
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
horizontal 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 Suchindex, wie man
bei Google zum Beispiel hat, irgendwie 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
ja, 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 gab es da
auch schon ein ähnliches Konzept, wie nennt man sich
ScalaGather 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, war 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 das vorstellen,
wenn man jetzt eine Webseite hat,
viele Rechner, die halt Webseiten
crawlen, 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 das
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 Index,
das ist halt
wie ein Index in einem
Buch,
wo halt steht, welches Wort kommt auf welcher
Seite vor, ja, und du musst,
musst halt für so ein Webseiten-Internet, musst du 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, man muss halt auch wissen, wie oft das
vorkommt, weil man halt bestimmte
Geschichten nutzt, man, ja.
Wir stehen am Anfang von der Liste, wie oft das
vorkommt. Ja, man rechnet so
TF-IDF-Scores aus, und dafür brauchen wir halt die
Term-Frequenz. So, bitte, was? TF-IDF-Scores?
Ja, Term-Frequenz mal
Inverse Document Frequency.
Das ist halt sozusagen ein wichtiger Wert dafür, wie
wichtig jetzt
ein Wort
ist in einem, 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.
Ja, also in dieser Webphase imitiert man im Grunde
nur, welche Webseite war das, wie
oft ist das Wort da vorgekommen, und dann werden
diese Ströme dann zusammenreduced,
und dann sozusagen
hat man halt irgendwie dann diesen Index,
wo dann zu jedem Wort steht, auf welchen Webseiten es vorkam,
ja, wie oft,
und wie oft es insgesamt vorkam und so.
Und dann kann man irgendwie so Anfragen 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,
man kann sich das einfach mal angucken, aber gibt's auch...
Rechenzentrum, da schalte einfach noch eine Maschine ein, wenn du welche brauchst.
Genau, du kannst halt einfach immer mehr
Maschinen dazustellen und
viele Leute haben sich gedacht, oh, das war eine coole
Idee und dann
ja,
einer von denen,
der Namen man immer hört, irgendwie,
der hat damals schon bei Excite
die Suchmaschine gebaut, hat dann später
eine sehr populäre oder immer noch die
populärste Volltext-Suchmaschine, die es
so gibt, Lucine, oder ist die 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, 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-Projekt
Schirm und
ja, das hat auch gut funktioniert,
alles
ist ein Riesenprojekt geworden,
es ist auch für manche Sachen halt
total super, ich würde jetzt nur sagen,
es wird heute viele Dinge verwendet, für die es
vielleicht nicht so gut geeignet ist eigentlich
und
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 keines dieser drei Big Data-Probleme,
sondern
du bist 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, also
Ja, oder
irgendwie, nicht mal das,
ja, ja,
also
ein Freund von mir sagt dann immer so,
ach, ich hab das,
und ich glaube, ich hab das Twitter gelesen,
Unsinn, also 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, äh, nein.
Deine Daten
fit in den RAM, ja,
no.
Und da einfach jedes Mal
10.000 Dollar für verlangen,
das würde, 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
Hadoop-Beratung, das hat der Frühjahrsagent,
ja,
äh, und das ist,
da ist leider vielmehr was dran, also es gibt
wenige, die das wirklich brauchen, äh, viele, äh,
schaffen es sich trotzdem an und haben
dann ein kompliziertes, eine, äh,
komplizierte Lösung für ein Problem, das sie nicht haben.
Ich meine, das ist natürlich für die Leute, die
Geld verdienen. Genau, das Problem, was sie haben,
ist das einfach total kompliziert, äh,
zu benutzen, also Dinge wären
viel einfacher, wenn sie das nicht machen würden, aber,
naja, so ist es halt nun mal,
äh,
und von diesem MapReduce-Ding ist auch,
äh, diese ganze Hadoop-Welt auch schon so ein,
so ein bisschen wieder weg, auch Google macht
nicht mehr wirklich, äh,
äh, MapReduce, also vielleicht, manche Sachen
machen sie möglicherweise noch MapReduce, aber es sind
auch andere Systeme, äh, gegangen, äh,
Pregel, so ein Graph-Processing-Ding,
was sie da machen, was halt relativ viel
tut von dem, was früher MapReduce gemacht hat,
ähm,
und, ähm, auch bei Hadoop ist es
halt so, dass, äh, das, was geblieben
ist, ist irgendwie so ein verteilter Dateisystem-Layer,
so auch Management
von diesen, äh,
Nodes, äh, irgendwie in diesem, in diesem
Pflaster,
ähm, aber, äh,
die, äh, Engines,
die jetzt irgendwie Queries darauf prozessen,
dafür gibt's halt, äh, das nennt sich Hive,
irgendwie, da schreibt man Queries in so einem SQL-ähnlichen,
äh, oder, das ist schon SQL,
man schreibt halt so SQL,
und das wird dann halt in MapReduce-Jobs
verwandelt und wird dann halt auf den,
äh, ja, also im Grunde die Idee
bei dem ganzen, bei der ganzen Geschichte ist, dass man halt
nicht mehr die Daten zu einer Stelle bringt,
wo sie dann processed 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, äh,
trägt jetzt den Algorithmus zu diesen Daten,
und der läuft dann halt lokal
auf den, auf den Clusternodes da drüber, und dann
am Schluss wird das alles wieder zusammengeführt, äh,
zusammenreduced, und dann kriegt man halt das
Ergebnis, ja, und für einen selber sieht das so aus,
man schreibt halt ein SQL-Statement und kriegt halt
ein Ergebnis, äh, und in Wirklichkeit
hat man dann halt irgendwie einen Job gebaut, der
dann halt, äh, 100 Mapper,
100 Reducer angestoßen hat,
und das lief halt über 200 Maschinen, und, ähm,
ja.
Big. Ja, ja, ja.
Hatte vielleicht das Problem nur Big Data dann, also
Big, nicht Data. Ja.
Haha. Aber, ja,
aber es wäre halt, das hat dann vielleicht
eine halbe Stunde gedauert, aber es ist halt auch möglich, dass
wenn man das anders gemacht hätte, hätte
diese ganze Geschichte auch in der Minute durchlaufen können,
ja, und, ja,
es gibt dann auch andere Geschichten, die jetzt auf solchen
Clustern laufen, äh, zum Beispiel
rein in Memory-Geschichten, so was wie Impala,
äh, einer
von, ähm,
äh, den, den PhD,
äh, Studenten von Michael Stonewrecker,
die, äh, damals Postgres mitgeschrieben
haben, äh, ist da irgendwie CTO von
der Firma, die da, ich hab jetzt auch wieder vergessen, welche das ist,
äh, das
macht das halt in Memory, das ist in C geschrieben,
das ist alles schneller, das, äh,
das ist viel angenehmer, wenn man damit arbeitet, aber es ist
auch so ein bisschen komisch, und es ist halt auch nicht so
richtig,
äh, es ist halt nur ein bisschen instabil, ähm,
äh, es gibt,
äh, diverse andere
Geschichten, jetzt gibt's, ach, das war noch ein eigenes Thema,
eigentlich Spark, Spice Spark,
ähm,
äh, was ganz interessant ist, ist,
äh, ja, was man vielleicht,
lass mich überlegen,
also, was, was sehr interessant ist, ist, dass wir
heute, äh, etwas sehen,
äh,
was wir früher eigentlich auch schon gedacht hätten,
dass wir das im relationalen Bereich bekommen, nämlich, äh,
oder MySQL hat damit mal angefangen, so, ähm,
die hatten irgendwie so ein, eines der
coolen Features bei MySQL am Anfang war, dass
die, die Storage Engines pluggable
waren, das heißt, du konntest deine eigene Storage Engine
da reinbauen, hat auch kaum Änder gemacht,
es gab eigentlich nur zwei Relevante,
wie, wie, wie die Daten
tatsächlich auf der Platte liegen, äh, okay, letztlich,
äh, und das ist halt, äh,
es gab MyISAM, äh,
es gab auch eine CSV-Engine für MySQL, da hast du einfach
CSV ausgebaut, aber MyISAM
war so populär, äh, MySQL
hatte aber Probleme, hatte das Problem, dass du, wenn du
geschrieben hast, wurde immer die komplette Table gelockt,
das heißt, also, da lieber nur lesen, nichts reinschreiben, so
reinschreiben, eher doof, ähm,
hat trotzdem, irgendwie haben das
viele lang verwendete Transaktionen, so, das geht alles nicht,
Asset war nicht so richtig bei MySQL am Anfang, und dann,
äh, dann hatten sie eine Storage-Engine, die das dann einfach schon konnte,
die auch so wirklich Multiversion
Concurrency-Control halt richtig konnte, und das war
InnoDB, und, äh,
ja, aber, äh, eigentlich
so, nachdem InnoDB sich durchgesetzt hatte,
oder irgendwie gut genug war,
dann, äh, hat sich dieser
Plugable-Storage-Engine-Geschichte von,
von, äh, MySQL hat sich dann auch wieder
erledigt,
aber, äh, äh, Postgres bekommt
jetzt, glaube ich, mit der Version 12, also, naja, das ist noch nicht sicher,
aber es sieht ein bisschen danach aus, als ob sie die Plugable-Storage-Engines
wieder zurückbekommen,
was interessant, äh,
da ist es dann zum ersten Mal, aber
das Konzept nochmal, äh, irgendwie
doch nochmal angefasst wird, äh,
und interessant ist auch in diesem ganzen, äh,
Analytics-Big-Data-Bereich,
dass wir da auch sowas sehen, wir sehen
halt, äh, es gibt nicht mehr so ein Datenbank-System,
wo halt die Repre, also
wie die Daten gespeichert werden, tatsächlich
an die anderen Teile,
also im Grunde besteht ja so ein Datenbank-System
aus vielen unterschiedlichen Geschichten, es besteht halt aus
so ein, äh, äh, ähm,
System, das irgendwie einfach nur
die Daten managt, äh, irgendwie
und, und Zugriffsrechte verwaltet
und irgendwie, und dann gibt's halt so Dinge,
wie speichert man das auf der Platte, es gibt Indizes,
es gibt so viele unterschiedliche Teile
und, äh,
ja, wir sehen jetzt so ein bisschen, dass das halt, äh,
auch alles wieder so ein bisschen
Plugable wird, gerade auch in diesem Big-Data-Bereich, also,
ah, auch wichtig, äh,
wenn man diese Analyse-Geschichten macht, hat man
im Grunde, äh,
äh, ist die Art, wie, also,
die Daten in relationalen Datenbanken
gespeichert werden, ist, äh,
äh, ist teilenweise, ja, weil,
äh, man oft, weil, weil die
Art von Queries, die man da macht,
oft nur wenige Zeilen betreffen.
Ein paar tausend oder so, aber es sind immer noch sehr wenige.
Daher macht es Sinn, äh,
irgendwie, zeilenweise zu arbeiten,
äh, sozusagen.
Ähm, aber für diese Analyse-Geschichten,
dieses ganze Data-Warehousing-Zeugs, äh, ist das
überhaupt nicht sinnvoll. Dieses
Muster, dass man halt, ähm,
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, oder,
äh, aber man interessiert sich gar nicht
für den Namen des Autors oder so, aber
daher möchte man eigentlich nicht irgendwie
alle Zeilen immer komplett angucken,
weil dann guckt man sich ganz viel Zeugs an,
so die, das, der, das, der
Flaschenhals ist oft, wie,
äh, ist oft die, die
Bandbreite zwischen
Platte und Hauptspeicher, so, man muss das halt
dann irgendwie durch den Prozessor ziehen
und je weniger Daten man dadurch ziehen muss, umso besser.
Und bei einem Zeilen
orientierten Format muss ich, wenn ich die Datei lese
und die Datei, äh, die Datensätze halt zeilenweise
drinstehen, muss ich halt da sequenziell durch die Zeilen
durchgehen. Da hilft's, 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, äh,
so Analyse-Querys auf, äh,
Datenbanken mache, die zeilenbasiert
ihre Daten speichern, dann ist
das super ineffizient und ich hab halt so einen Verlust
von circa, so, man sagt so immer so 5,
Faktor 50 ungefähr, sind die halt
einfach aufgrund dieser Architekturgeschichte
langsamer, und zwar
unoptimierbar langsamer
als, äh, äh, sogenannte Column-Stores,
die halt Daten, äh,
spaltenweise speichern, ne.
Und, ähm,
die, äh, die ersten, äh,
Dateisystem-Formate oder Formate,
in denen die Daten zum Beispiel in Hadoop gespeichert wurden,
äh, Abo ist, glaub ich, so das erste, ich weiß nicht genau,
äh, sind auch alle zeilenbasiert,
weil das war halt so, ne, 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's halt
neuere File-Formate wie zum Beispiel, äh,
oder Serialisierungsformate,
Parquet, äh, äh,
Dateien zum Beispiel, das ist halt das, was heute
eigentlich immer so verwendet wird, das ist halt dann
spaltenbasiert,
äh, und dann, dann liest man eben
nur die Dateien, oder du, du,
die Spalten, das ist halt in einer Datei
nur eine Spalte, sozusagen,
man liest halt nur die Dateien, die man halt braucht,
ähm,
und das ist komprimierbar, es ist chunk,
sodass ich es auf mehrere Rechner verteilen kann, und so,
und hat halt all diese hübschen Eigenschaften,
ähm,
und ich hab jetzt
diese, diese Parquet-Files, aber das, also das
Format der, der Daten, äh, auf der Platte,
das Serialisierungsformat ist nicht mehr gebunden an die Datenbank,
sondern, äh, als
Layer da drüber, mit dem ich jetzt Abfragen mache,
hab ich jetzt sowas wie Hive, das macht dann MapReduce
Drops draus irgendwie, äh,
ich hab, äh, aber auch sowas
wie Impala, ich hab vielleicht andere
Geschichten, ich hab Spark, und, äh,
das hast du eben noch vergessen, übrigens, äh,
Spark, genau, gut, Spark hat auch irgendwie mit,
ist was mit anderen, was anderen gestartet, die, die,
äh,
äh, hat auch ein eigenes DataFrame-Format,
äh, was, was jetzt nicht Parquet war,
aber, also, worauf es hinausläuft,
ist, äh, im Grunde,
dass ich jetzt, äh, so ein Format
habe wie Parquet, ähm,
in dem die Daten auf der Platte liegen,
und jetzt hab ich halt unterschiedliche
Engines, die jetzt irgendwie, mit denen ich jetzt
Queries verarbeite drauf, ja,
so quasi eine Trennung zwischen,
ähm, dem System, das jetzt
meine Queries irgendwie beantwortet, und dem
Speicherformat, also quasi sowas ähnliches wie
ein Plugable Storage Engine, so, nur
dass halt, der Storage-Format ist halt für alle
unterschiedlichen Engines irgendwie gleich, nämlich Parquet,
aber das, was halt die, äh, Dinge
darauf machen, ist halt unterschiedlich.
Äh, und das ist eine ganz interessante Entwicklung, finde ich, also
das ist halt, äh, das ist schon faszinierend,
und, ähm,
äh,
ja, die, äh,
äh, ja, Column Stores
sind halt sozusagen, das, äh, sind für so Data Warehousing
eigentlich das, das Coole, es gibt all, es sind,
es ist, es hieß da,
Paper ist halt auch eine, äh,
Firma entstanden, Vertica, glaube ich,
äh, äh, 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 so einer Firma geht und das macht,
keine Ahnung, oder es gibt es auch wahrscheinlich
auch noch andere, die sowas ähnliches machen, ne,
aber was halt nicht gut wäre, ist halt, wenn man,
äh, wenn man, wenn man mit so einem Problem zu
Oracle geht, ne, weil Oracle ist halt nicht Column,
äh, ist halt nicht Column-Oriented, sondern die sind halt
zahlenbasiert, egal, was sie dazu sagen, sie versuchen das
mit ihrem Marketing immer zu verschleiern, aber es ist halt,
ja, genau wie MSSQL zwar war und
die ganzen klassischen relationalen
Datenbanken, die sind alle zahlenbasiert und da
gibt es auch nichts, was man tun könnte.
Ja, es sei denn, man tauscht
die Storage-Editen aus, und so, und das ist halt, äh,
bei Postgres wird das nochmal interessant.
So Postgres, da hat man das Problem halt,
wenn man ein Data Warehouse auf Postgres aufbaut, dann
ist man immer dann an die zahlenweise,
äh, äh, Verarbeitung
gebunden, kann halt auch nichts machen.
Ähm. Wenn man das zunächst dann halt mit Parquet
machen könnte, dann... Ja, wenn man irgendwie
Parquet und Postgres irgendwie verheiraten könnte, das
wäre natürlich schon ziemlich cool dann irgendwie.
Ja, äh,
genau. Und das
sind halt so die, ähm,
ja, das sind halt so diese Geschichten beim,
beim, beim Data Warehousing,
äh, genau, so Hadoop, man nennt das auch so,
nicht Data Warehouse, sondern weil man auch alles mögliche andere
darin speichern kann, Data Lake, äh, weiß ich gar nicht,
ob man da so ins Detail gehen muss, aber man hat auch noch Bilder und
sonst wie andere, man kann halt alle möglichen
Arten von unterschiedlichen Daten...
Ja, man kann auch so ein bisschen umkippen,
wenn man das dann Data Swamp...
Äh, ja, ähm,
und, äh, äh,
ja, also,
ich bin nicht, ich bin nicht, ehrlich gesagt, nicht so ein
Riesenfan von Hadoop, muss ich sagen.
So, aber, äh,
auch, ich hab da auch schon, äh,
ein bisschen so schmerzhafte Erfahrungen, äh,
mit, mitgemacht, äh,
weil so Daten rein und rauskriegen ist
irgendwann so ein bisschen hässlich und, ähm,
ja, das ist auch noch alles nicht so weit, also bei, bei so
klassischen Datenbanken ist halt, da merkt man,
so wenn man Postgres gerade verwendet zum Beispiel, merkt man halt so,
das ist halt schon Jahrzehnte, äh,
äh, 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,
das ist halt sehr selten, würde ich
jetzt mal so...
Ja, 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, da muss man, also es wäre halt
vielleicht schon mal...
Ja, äh, wenn man tatsächlich ein Problem
mit der Datenbank hat, ist natürlich, äh, wäre
natürlich schlecht, weil da kann man nichts machen, ne, außer
Datenbank wechseln oder irgendwie,
äh, selber neu schreiben oder sowas,
nicht gut, ja, äh, und, ähm,
bei Hadoop habe ich so das Gefühl,
es kann auch durchaus sein, dass ich einfach
so blöd weiß, 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, das nicht richtig verwendet
oder es falsch rum hält irgendwie, sondern,
äh, bestimmte Sachen
gehen einfach noch nicht oder gehen nicht richtig oder
man hat Use Cases und dann schleppt man so fest so,
ja, hat niemand drüber nachgedacht,
äh, ist nicht so richtig abgebildet, hm,
blöd, und, ähm,
das wird wahrscheinlich alles irgendwie viel besser,
aber momentan ist es noch nicht so,
ne, es ist noch ein bisschen scharf, fühlt sich alles ein wenig scharfkantig an.
Man kann sich überschneiden und wehtun
und aua. Ja, und außerdem, dass es halt alles
auf dieser Java-Geschichte aufsetzt, ist auch sowas,
muss ich auch sagen. Ah,
sind wir wieder bei dem Ding, was wir eigentlich als Running-Gag nehmen wollten,
haben wir es doch dazu verlassen. Ja, Java,
mal wieder, das ist, äh...
Ja, so, nach zweieinhalb Stunden sind wir doch wieder drauf gekommen,
ja. Ja, ähm, und, aber,
aber da ist dann möglicherweise der Ausweg, irgendwie sowas wie
PySpark zu verwenden, das mag auch nochmal,
eigentlich müssen wir da nochmal ein eigenes Thema zu machen,
äh, auch, aber sehr schön, das Ding ist so,
dass man halt, äh, quasi,
äh, Sachen automatisch
verteilen kann, man hat sie lokal,
man kann das mit anfangen, dass man es auf einer Maschine hat
und dann, äh, äh, führt man Sachen
auf einen Cluster aus und das ist wirklich
mehr oder weniger seamless, äh,
äh, das Einzige,
ähm, man hat
sogar einen vollständigen Python-Interpreter, ne, das ist
irgendwie nicht so eine verkrüppelte Version, man kann halt
tatsächlich irgendwie Saiten, äh,
Sachen damit machen, das heißt, man kriegt Sachen auch wirklich,
wirklich schnell, ähm,
ja, im Gegensatz
von, zu Java, Java geht vielleicht auch, ich weiß
es nicht genau, aber ich glaube, es ist ziemlich schwer, äh, Sachen
wirklich optimiert hinzukriegen,
äh, während in Python ist es halt
relativ leicht, äh, irgendwie
mit, mit Saiten halt ein Dialekt von
Python zu schreiben, wo man dann Typ-Annotationen dazu schreibt,
äh, wo dann, die dann halt
zu C kompiliert werden, dann wird das als C-Modul, dann wird's
wieder reimportiert und, äh, 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-Shows
verteilt, weiß ich nicht, kann auch sein, dass das geht, keine Ahnung,
aber das klingt irgendwie nicht so leicht.
Ja, wie auch immer, also,
ähm, 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, wie kommen da die Informationen rein,
man möchte eigentlich nicht, ähm,
äh, da so ETL-Jobs
machen, das funktioniert alles nicht mehr, man möchte ja auch echt
Zeit-Dashboards haben, irgendwie.
Äh, und
dann muss man halt auf so eine, oder
sollte man, dann wechselt man halt irgendwann
auf so eine Streaming-Architektur, wo halt, äh,
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, äh, irgendwie jeden Klick den User
macht auf der Webseite, auch, äh,
irgendwo, irgendwo eine, äh,
Fakten-Tabelle, äh,
in ihr Data Warehouse, Data Lake,
Ding reinspeichern möchte,
ja, dann
wird das Big, weil das ist halt schon
viel, dann ist so, so Verhältnis von Bestellungen
zu, Leute machen irgendwie Web-Requests
oder klicken auf der Seite rum, ist halt wahrscheinlich nochmal so
100, 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
OTP-Datenbank reinschreibt
und dann extrahiert und batchmäßig
jeden Tag ein Analysesystem schreibt,
sondern dann generiert man
halt so Events,
die dann halt über irgendeinen
Streaming
Zeugs halt
Service laufen,
der das dann halt
an unterschiedliche Consumer
irgendwie ausliefert. Und das sind meistens Kafka,
AWS hat noch eine eigene Lösung,
normalerweise auch wieder den Namen vergessen.
Meint aber nicht die Lambda-Service, ist das was anderes?
Nee, nee, das ist was anderes.
Nee, das ist 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 Protokoll-Buffers oder sowas.
Und
dann gehen die Dinger halt
auch da wiederum Serialisierungsformate sehr, also
es gibt halt sehr unterschiedliche Protokoll-Buffers
sind super, wenn man Daten übertragen möchte oder auch dieses
Thrift 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
Protokoll-Buffers irgendwie
in Kafka kippen und dann das
irgendwo auf eine Platte schreiben lassen.
Das reicht halt nicht, sondern man muss
es halt dann doch auch irgendwie wieder
irgendwie so Zwischendinge kippen.
Aber man kann halt auch, man kann halt etwas haben,
was halt teilweise aus
diesen Parquet-Files liest.
Und dann halt die aktuellsten Daten liest es halt aus
einem Log der
der Protokoll-Buffer-Events.
Weil das muss ja dann vielleicht nur für die letzte
halbe Stunde sein oder so. Kommt halt mal drauf an.
Ja, und dann kann man
halt tatsächlich Echtzeit-Daten sehen.
Dann könnte man halt ein Dashboard machen, wo man halt
in Echtzeit sieht, wie sich
die Zugriffsmuster ändern, wenn man jetzt zum Beispiel
für einen bestimmten Teil der User irgendwie die Webseite
ändert oder so. Und das ist natürlich
schon sehr nett. Und wenn man halt irgendwie Preise
erhöht, dann sieht man halt irgendwie in Echtzeit, wie
die Conversion runtergeht.
Ja, und dann kann man halt so
als Manager
vor diesem Dashboard sitzen
und den Köpfen drehen.
Die kommen auch vor die Wand fahren.
Ja, und dann irgendwie Profit
maximieren.
Das ist schon
sehr nett. Ist aber auch halt sehr aufwendig.
Das macht alles nochmal
viel komplizierter.
Ja, und
diese Serialisierungsformat-Geschichte
ist halt sehr wichtig.
Etwas, was mir bei dem
Hadoop-Erfahrung
dann geholfen hat, war
ein Projekt namens
Apache Arrow,
wo es darum geht,
das ist von dem
ursprünglichen Autor von
Pandas, also dieser DataFrame
Library für Python,
und der hat das gestartet,
weil der da halt ein...
Und das ist auch tatsächlich...
Während ich mich halt mit Hadoop gestellt habe,
mich hat es an den gleichen Stellen gejuckt,
sozusagen.
Das hat er zuerst gemacht.
Also ihn hat das wohl auch irgendwie
genervt. Der hat bei Cloudera gearbeitet.
Das ist halt auch so eine von diesen
Firmen, die halt so in diesem
Big Data, Hadoop-Bereich viel unterwegs sind.
Auch da, glaube ich, einer von den
Chefs oder Gründern ist halt einer von den...
Auch ein PhD-Student von
Michael Stonebraker.
Das sind also irgendwie immer die
leitenden Leute.
Und...
Genau. Da ging es darum,
sozusagen ein
Interface zu haben, das genauso ist
wie Pandas, also
DataFrame-API quasi zu haben,
sodass man halt Dinge...
Man hat so das Gefühl, man hat ein DataFrame-Objekt,
macht da irgendwelche Sachen drauf, so als wäre es ein Pandas-DataFrame.
Aber in Wirklichkeit passieren
im Hintergrund Sachen
auf deinem Cluster. Das war eine Bibliothek,
nannte sich Ibis, und das ist halt genauso auch
mein Problem damit, dass halt
ich mache ja eigentlich eher so Machine-Learning
Dinge und
benutze Pandas
eigentlich so zum Daten
aufräumen, Daten transformieren,
bevor ich das dann halt in irgendwie
Machine-Learning-Aggregate und so und Modelle reinfüttere,
die dann aber
selber wieder nur Arrays, NumPy-Arrays
normalerweise nehmen und keine DataFrames.
Aber DataFrames ist halt so ein
Zwischenschritt und man kann halt sehr leicht aus einem DataFrame
irgendwie ein Array machen, indem man einfach sagt
DataFrame.Values, dann hat man die...
Das Array.
Und ich hatte halt immer das Problem,
wenn ich jetzt da mit so Systemen wie
Hive oder Impala draufgegangen bin, dann kriege ich halt
irgendwie eher so ein CSV
oder so ein Result-Set und dann kriege ich
das nicht schnell da raus.
Das ist halt alles ultra langsam.
Ich brauche aber für meine Modelle
doch durchaus große Daten oft.
Das geht alles nicht.
Dann wäre das natürlich viel besser gewesen,
wenn ich einfach nur...
Das, was diese Systeme machen,
ist, man schreibt SQL-Statements und die machen
dann halt irgendwie automatisch...
Machen die halt irgendwelche Aktionen auf dem Cluster.
Wenn das jetzt so gewesen wäre, dass ich das
einfach nur in DataFrame-Syntax, was ich mit den Daten
machen wollte, hätte hinschreiben können,
dann wäre mir ja schon viel geholfen gewesen.
Und genau das hat halt IBIS,
diese Bibliothek, die dann Wes McKenney bei
Cloudera gebaut hat, gemacht.
Man hatte ein Ding, das war wie ein
Pandas-DataFrame, wo man da halt irgendwie
GroupBy gesagt hat und dann hat das
halt nicht
das im Hauptspeicher gemacht wie Pandas, sondern das hat
dann halt SQL-Statements erzeugt,
automatisch, die man aber nicht gesehen hat, und die dann
auf den
Cluster irgendwie losgelassen
und dann
magisch irgendwie mit Ergebnissen
irgendwas gemacht.
Ja, aber das hat halt auch nicht gereicht, weil
auch da wieder das Problem war, wie kriegt man die Daten wieder
raus, wenn man jetzt, man kann eben sowas
nicht sagen, wie wenn man es jetzt richtig transformiert
hat, also da war das schon eine Hilfe, aber
jetzt hätte man gerne die Werte, um sie tatsächlich in
Machine Learning-Algorithmus reinzupumpen,
damit er möchte irgendwie ein Modell
drauf trainieren. Und man kann eben jetzt bei diesem
DataFrame eben nicht sagen,
df.values, das geht halt nicht, weil
die Daten sind halt im Cluster, weil
sie da irgendwie rauskriegen und man kriegt die nicht raus,
das geht nicht. Also der Weg von
ja,
ja, und das war halt dann auch
irgendwie ein Problem, wo dann das IBIS-Projekt
so ein bisschen dann vorbei war
und, weißt du, Kenny hat dann auch
von Cloudera irgendwie weg und hat
dann Apache Arrow gestartet und Apache Arrow
macht halt genau
da weiter und das hat mir dann auch wieder
weitergeholfen, weil
okay, das geht
nicht anders, man muss tatsächlich auf die rohen
Parquet-Files im Cluster irgendwie zugreifen
und
wenn man jetzt irgendwie da drauf was machen möchte,
man braucht irgendwie ein Array-mäßiges
Interface auf diese
Files. Wenn man das hat, dann ist man
eigentlich im Grunde, dann funktioniert alles.
Und das macht Arrow. Arrow
ist halt sozusagen ein In-Memory
Datenstruktur, Array-Datenstruktur,
die halt von
unterschiedlichen, das ist auch das Ziel dabei, ist auch eine
Kollaboration mit irgendwie einem der
wichtigeren Leute, die hinter R,
oder R-Studio
zusammen,
die haben das beide zusammen gemacht, dieses Projekt
und
genau, die Idee
ist sozusagen, du hast halt eine
Abstraktionsschicht, die halt
irgendwie so ein Arrays-Thor im Hauptspeicher hält,
das macht Apache Arrow,
deswegen ist ein C++ geschrieben, aber du kannst
halt von Python aus zugreifen, von R drauf
zugreifen, von Java aus
und du musst es halt nur einmal
im Hauptspeicher halten und du hast
es dann halt in dem Format, in dem du es brauchst, um es
halt in Machine Learning-Modelle reinzupumpen.
Ja, was du halt
diese ganze Loop-Welt,
kannst du dein Machine Learning-Algorithmus ja nicht als
MapReduce, das geht halt nicht, schreiben, weil
wenn du ein neuronales Netz hast, das hat Verbindungen
überall hin, da kannst du es halt nicht
klar horizontal auftreiben in
Mapper und Reducer, das funktioniert einfach nicht, das ist halt Quatsch.
Viele, oder auch
viele Machine Learning-Algorithmen lassen sich nicht
einfach so verteilen. Oder
ja, sie brauchen halt irgendwie
ihre Daten in einem bestimmten Format und das ist halt so ein Array-Format,
weil das ist alles lineare Algebra,
und lineare Algebra funktioniert
mit Vektoren, Matrizen, oder
halt, man nennt die Dinger allgemein
Arrays halt, also
beliebig dimensionale Arrays.
Ja,
und das
geht halt so einfach eigentlich irgendwie nicht.
Und
ja, mit Apache Arrow halt
schon. Und außerdem macht Apache
Arrow dann halt so ein paar Sachen wieder, zieht es wieder gerade,
die halt bei NumPy so ein bisschen kaputt sind.
Unter anderem,
was halt total blöd ist, ist halt, aber das habe ich
auch schon mal erwähnt, dass es halt kein
Kanal für Integer gibt und so,
also mit Missing Values ist halt schwer
bei NumPy Arrays.
Und
ja, es gibt ja noch diverse andere Probleme.
Und ja,
das klingt eigentlich super interessant und ich glaube,
das ist halt auch so ein bisschen der Weg in die Zukunft, weil
dieser ganze
Business Intelligence-Bereich, also ich habe oft irgendwie mit
so Business Intelligence-Abteilungen
auch zu tun gehabt, in denen
dann so, an die wurde dann immer so
Datasites und Machine Learning irgendwie so angedockt. Ja, also das
ist halt, Business Intelligence ist etwas, was halt
große Firmen halt schon lange haben.
Aber die machen
halt sowas wie, ja, also einmal
die Leute, die dann Dinge da machen, sind da so
Analysten.
Oft super schlaue Leute.
Aber
ich überlege gerade, wie man
da hinfühlen kann.
Sagen wir mal so, was die halt tun können.
Nehmen wir an, du bist Walmart und du
interessierst dich jetzt dafür, keine Ahnung,
weißt jetzt, es kommt eine Flut,
die irgendwie deine Stadt
überschwemmen wird und dann
was werden die Leute
dann kaufen oder so.
Für was musst du
irgendwie vorsorgen? Und
bei einem klassischen BI-Ansatz
wäre halt, du guckst dir halt die Icons da an, wo
Städte überflutet worden sind, da gibt es nicht so viele.
Substrahierst
da halt irgendwie so, guckst dir das halt
eine Woche später an
und überlegst dir dann halt irgendwas.
Und das,
und das machst du dann. Und dann machst du
irgendwie gewisse Voraussagen und sagst so,
das könnte ungefähr so und so aussehen.
Das ist halt das, was passiert. Und das ist halt auch das, was
heute noch in BI-Abteilungen hauptsächlich passiert,
dass die Leute halt irgendwie so historische Daten angucken und dann so
überlegen so.
Und ich denke,
das wird alles
so in Zukunft eher Richtung Data Science
laufen.
Damit meine ich, dass
solche Antworten kommen halt dann eher von Systemen,
die Vorhersagen machen.
Und
die werden das deutlich besser können.
Und die werden das halt auch,
also ein Großteil dieser Analysegeschichte
wird man halt automatisieren können.
Und das Problem momentan ist halt so ein bisschen,
dass die Tools,
die man hat, nicht zueinander passen.
Zu dem, die
so Hadoop-Welt
passt eigentlich eher so zu dem klassischen
BI-Ansatz.
Und was auch bei diesem
BI-Ansatz ein Problem ist, ist halt, dass man das nicht wirklich
wieder zurück in Produkte übersetzen kann.
Also das sind auch,
Leute nicht, nicht unbedingt Leute, die halt
dann Produkte bauen können, die halt entwickeln können oder
Services bauen können. Auch mit
diesem ganzen, wie baut man Dinge,
wie macht man Produktentwicklung?
Nicht so, das ist nicht so was, was natürlich
für die ist, sondern das ist halt eher so etwas, was sie dann
halt auch machen müssen vielleicht,
aber wo sie sich halt auch nicht so gut bei fühlen.
Das aber halt
absolut erforderlich ist, weil viele von den Sachen sollen
ja dann automatisch auch Dinge tatsächlich tun.
Ja, so viele Ergebnisse, die dann
halt automatisch generiert werden, sollen halt nicht dazu führen,
dass es halt irgendwie eine nette Präsentation irgendwie
an einen Management-Layer gibt oder so.
Sondern du willst halt, dass dann
da tatsächlich
Entscheidungen auch rausfallen, die irgendwas auf deiner
Webseite verändern oder die irgendwelche Dinge tun.
Und dann musst
du halt Software entwickeln eigentlich. Dann bist du halt
so Teil der Produktentwicklung.
Und ja, das
geht halt auch nicht so richtig gut. Und was
da ein bisschen fehlt, ist halt so ein
ist halt etwas, was halt
Daten in Array-Form im Hauptspeicher hält.
Und das
macht Apache Arrow. Und deswegen finde ich das Projekt so
superinteressant. Es gibt da noch
SciDB oder sowas.
Ob ich die auch sowas ähnliches machen?
Aber da geht's irgendwie hin.
Und ja, es geht Richtung
Streaming. Spark macht ja auch ganz viel mit Streaming.
Wobei mich natürlich besonders
interessiert PySpark, weil Python und so.
Ja.
Haben wir da noch
Irgendwann. Ich wollte schon fragen. Wir haben jetzt
ganz lange schon, also fast drei
Stunden schon über die ganzen Daten gesagt.
Wir merken, der Jochen ist ja sehr tief drin.
Das ist auch ein super breites Thema.
Haben wir tatsächlich die
meisten Sachen schon jetzt durch? Oder hast du noch was,
was du unbedingt da zu dem Thema gespeichert hast?
Genau, genau, genau.
Ach so, ah, genau. Wenn wir jetzt nochmal zurückkommen zu dem
E-Commerce-Ding. Das war jetzt so eine Exkurs Richtung
Big Data. Also wenn wir ganz froh sind.
Das neue Thema. Immer so
Mars oder so. Ja, also das hatten wir
auch vorher schon mal kurz angekündigt.
Relationale Datenbanken oder so. Diese Art
Daten umzugehen ist halt besonders gut.
Und dann, wenn es Daten über
Sachen sind, die nicht Daten sind. Also
physikalische Sachen, die sich nicht so schnell ändern,
bei denen es Sinn macht,
ein festes Schema zu definieren, das dann halt auch über längere
Zeit mehr oder weniger gleich bleiben kann. Man kann natürlich
Sachen ändern, aber Dinge grundsätzlich
ändern, ist dann schwierig.
Und
aber
das ist jetzt tatsächlich Zukunft.
Es ist auch nicht so richtig sinnvoll, diese Amazon
Geschichte, also heute Amazon zu bauen,
ist viel, viel einfacher natürlich. Also ich meine,
das hört sich so an, als wäre es total einfach, Amazon zu
werden. Das ist es
nicht.
Es war auch zu der Zeit, als Amazon
Amazon geworden ist, war es viel schwieriger, weil da
gab es halt keine Tools. So was wie Postgres
gab es, aber es war
nicht in dem
Zustand, wie heute.
Es wäre nicht nutzbar gewesen.
Also es gab damals, als
ich weiß nicht wann die angefangen haben, Anfang der 90er oder
also Amazon hat sehr, sehr früh angefangen,
Mitte der 90er, ich weiß nicht genau.
Da gab es halt nichts. Die mussten
alle selber bauen. Das war, ist natürlich
nochmal ein ganz anderes Problem.
Während heute man wahrscheinlich mit Postgres,
Django, Redis, irgendwie
und ein paar Rechnern wahrscheinlich einen Markt wie
Deutschland mit so einer ähnlichen Seite
wie Amazon versorgen könnte.
Das
ging halt damals nicht und das
macht es heute einem natürlich viel leichter.
Aber heute ist halt das Problem, es gibt Amazon schon.
Man muss mit Amazon konkurrieren und
leider hat man da keine Chance.
Deswegen funktioniert das auch nicht.
Aber was natürlich interessant möglicherweise ist,
ist sich zu überlegen,
okay, was kann Amazon denn mit dem, was sie tun,
nicht machen und wo entwickelt sich das halt in Zukunft hin?
Ich habe
das auch schon wieder zehn Jahre her, unglaublich,
oder noch mehr als zehn Jahre sogar.
Mein Vortrag gehört
von David Weinberger, der ist
ein Philosoph,
auf Internetgeschichten
beschäftigt in Harvard.
Kann man mal gucken, packe ich auch noch in die Shownotes.
Der Vortrag heißt Everything is Miscellaneous.
Da gibt es auch ein Buch zu.
Der Talk bei Google
ist halt eine Vorstellung
von dem Buchinhalt, mehr oder weniger,
wo er darüber spricht,
dass wir
jetzt so
in der Zeit von Internet
und Computern
sich ja Dinge komplett verschieben
im Grunde, oder wir das aber noch
gar nicht so richtig antizipiert haben.
Sein Beispiel
ist halt auch E-Commerce und halt auch
so Faceted Navigation.
Er sagt halt, naja, also in so einem klassischen
Laden, wenn du da reingehst,
muss man sich überlegen, wo man
welche Dinge hinpackt.
Da physikalische Objekte
nur an einem Ort gleichzeitig sein können,
oder überhaupt irgendwo sein müssen,
muss man halt irgendwie das so strukturieren,
dass das der Fall ist, und dann muss man sich überlegen,
okay, wie macht das für die meisten Leute Sinn,
wenn sie reinkommen, ist immer der Salat irgendwie vorne rechts,
oder keine Ahnung.
Und das muss man eigentlich, wenn man jetzt
Daten über Daten hat,
gar nicht mehr so machen.
Das Slicen und Dicen, wie man wollte.
Also man könnte halt sagen, okay, ich bin jemand, der nur
schwarze T-Shirts anzieht, also
alles andere interessiert mich nicht.
Ich brauche jetzt eine Navigation innerhalb
dieser schwarzen T-Shirts, aber alle anderen Sachen kann ich
schon mal so irgendwie wegschneiden.
Das würde für alle anderen vielleicht keinen Sinn machen,
oder für andere Leute, jeder hat vielleicht andere Arten,
was er, aber ich kann
jetzt eine Seite bauen, die
auf die Bedürfnisse von jedem im Grunde zugeschnitten ist,
oder sich leicht so an...
Die eigene Filterbubble immer erzeugt für den jeweiligen...
Elektronisch habe ich das Problem nicht, oder
ich kann für jeden eine eigene
Art von Laden
erzeugen,
oder eine eigene Art von Navigation bauen.
Nur wenn ich denjenigen kenne, natürlich.
Natürlich, oder
wenn er es mir halt irgendwie sagt, indem ich ein Interface habe,
wo man das halt irgendwie einstellen könnte.
Aber das wird kaum
gemacht. Es gibt halt meistens doch wieder einen
Kategorienbaum, der halt
irgendwie... Kategorienbaum
auf einer Seite ist ja im Grunde irgendwie sowas wie
ein Weg durch
einen Laden, der halt vorgegeben ist.
Warum muss das denn so sein?
Das muss ja eigentlich... Also wir adaptieren da
eine Sichtweise aus der
physischen Welt, die
vielleicht insofern hilfreich ist, weil
die Leute kennen das so.
Insofern macht das auch durchaus Sinn, das so zu tun,
aber es müsste eigentlich nicht so sein. Und vielleicht
wäre es, wenn man das anders machen würde, halt viel effizienter.
Genau.
Das ist das Raum für ein Startup da übrigens gerade.
Ja, das Problem ist halt nur,
also ich fand das ja schon vor über 10 Jahren
interessant, aber
in der Richtung hat sich noch nicht so wirklich wahnsinnig viel
getan. Insofern bin ich mir nicht sicher,
ob das eine gute... Also damals war es auch, wenn wir zurückblicken,
kann man jetzt sagen, damals ein Startup in die Richtung
zu starten, wäre keine gute Idee gewesen.
Vielleicht wäre es jetzt eine gute Idee.
Vielleicht ist es aber erst in 5 Jahren eine gute Idee.
Keine Ahnung.
Wenn der Zeitpunkt richtig ist, keine Ahnung.
Man braucht ein Gespür für. Und wenn man das Gespür hat
und dann an der richtigen Stelle ist, dann...
Ja, brauchen wir noch ein bisschen Geld und Geduld.
Ja, aber genau der Punkt, auf den ich eigentlich hinaus will, ist,
was ist eigentlich, Amazon hat das gleiche Interface für alle Arten von Dingen, die sie verkaufen.
Sie haben am Anfang mit Büchern angefangen, weil bei Büchern das Problem,
weil sie da einen ganz klaren Vorteil gegenüber den anderen
Ja, du möchtest ein Framing bauen für den jeweiligen Kunden.
Ja, ich möchte halt zum Beispiel einfach nur so in die Richtung gehen,
warum muss die Navigation immer gleich aussehen.
Das eigene Holodeck, also manchmal geht man im Mittelalterladen einkaufen, mal im Cyberstore.
Genau, je nachdem, was man verkaufen möchte.
Amazon macht jetzt nicht nur Bücher, sondern mittlerweile machen sie,
Bücher ist jetzt wahrscheinlich gar kein großer Anteil mehr an ihrem Geschäft.
Sie verkaufen viel Elektronik und das sieht man der Seite halt auch an.
Also vieles von der Navigation ist darauf optimiert, dass ich halt irgendwie so Elektronik, weiße Ware irgendwie kaufen kann.
So ein bisschen wie Ambilight beim Fernseher.
Ja, aber halt inhaltlich.
Ja, ja.
Und das liegt halt vor allen Dingen, dass die Navigation so aussieht, wie sie aussieht, liegt halt an Datenbankschema.
Weil das lässt halt gar nicht zu, dass ich irgendwie was großartig anderes baue, weil das ist halt mehr oder weniger fix.
Jetzt ist es natürlich schon so, dass unterschiedliche Dinge, also Fahrräder haben halt bestimmte,
das kann ich schon irgendwie, da kann ich ein Schema bauen, das das irgendwie modelliert.
Oder Bücher oder Waschmaschinen.
Aber die Daten über die Daten, die kann ich natürlich irgendwie beliebig modellieren.
Da könnte ich auch beliebige Navigationen drauf bauen.
Und ich könnte auch, also wenn ich jetzt, also der Witz ist, was ich eigentlich eventuell gerne hätte,
dass jetzt, wenn jetzt ein Produktmanager, der für die Kategorie Fahrräder oder sowas zuständig ist,
auf eine irgendwie super Idee kommt, wie man das Navigieren mal macht und die Leute zufriedener zu den Fahrrädern, die sie haben wollen, führen kann,
dann müsste er ja die Navigation umstellen können.
Dafür müsste er das Schema ändern können.
Das heißt, er müsste das Schema live irgendwie ändern.
Was in relationalen Daten, das kannst du vergessen.
Also du kannst, ich meine, du musst eine Migration machen, du musst halt irgendwie, das kannst du alles, das kannst du komplett.
Also sagen wir mal so, es geht technisch, aber das ist auf jeden Fall Entwicklerarbeit.
Das ist halt nicht etwas, was irgendjemand, der auf einer Webseite irgendwas einstellt, irgendwie.
Das geht halt eher nicht.
Aber wenn man jetzt von diesem, sich von diesem relationalen Paradigmen so ein bisschen löst und sagt, okay, ja, dann ginge das eventuell schon.
Also im Grunde, wenn man jetzt nicht.
Daten über physikalische Effekte hat, sondern Daten über Daten und eine Datenbank, die halt nicht mehr so fixe Schema, nicht so ein fixes Schema hat,
dann könnte man eventuell so machen, dass man die Seite live so ändert, wie sie halt eventuell mehr Sinn macht.
Und vielleicht könnten das auch die User tun.
Keine Ahnung.
Es ist halt nur so, es ist halt so eine Idee.
Es ist halt einfach so eine Idee, wie geht es jetzt eigentlich weiter.
Ich meine, Amazon ist im Grunde mehr oder weniger fertig.
Wir haben Amazon nachgebaut und wir hatten auch das Problem, dass unsere Navigation,
egal ob das jetzt Fahrräder, Waschmaschinen oder sonst irgendwas ist, würde halt genau gleich aussehen oder Mode.
Und da könnten wir ja im Grunde nichts machen, weil das Schema halt für Angebote halt immer gleich sein muss, weil die sind ja alle in einem Datenbankschirm.
So, genau.
Aber das könnte halt irgendwie wie etwas anders aussehen.
Und was halt da sehr interessant sein könnte, sind halt Grafen-Datenbanken zum Beispiel, wo man halt eben nicht.
Also ich hatte das ja auch am Anfang schon mal erwähnt.
Es hätten sich auch Grafen-Datenbanken durchsetzen können.
Das ist überhaupt nicht so klar, warum das relational geworden sind.
Gut, die Grafen-Datenbanken waren ein bisschen später dran.
Aber ja, und da gibt es zum Beispiel auch ein super interessantes Projekt, nennt sich D-Graph.
D-Graph.
Ja.
Das ist ein Ex-Mitarbeiter von Google.
Und der hat sich irgendwie getroffen.
Da hat man Google geschaut.
Da hat man halt auch überlegt, was sind denn jetzt die Sachen, die man heutzutage hat, die Probleme, die man hat.
Also es muss halt irgendwie so.
Brides müssen halt auch.
Man darf nicht nur einen Master haben.
Es muss halt irgendwie skalierbar sein.
Es muss halt irgendwie schnell sein.
Und der hat, das hat letztes Mal, als wir über Skalierbarkeit und so, ich glaube, das war in der ersten Folge oder so geredet haben,
habe ich auch gesagt, so Go wäre eventuell ein guter Kandidat, um da drin einen Datenbank zu schreiben.
Also Python halt nicht so.
Das ist halt eines der wenigen Anwendungsfälle, wo ich sagen würde, gut, dafür ist Python.
Python ist gut geeignet, wenn man I.O. multiplexen muss.
Also man macht einfach nur viel Netzwerk in alle möglichen Richtungen.
Das geht.
Da braucht man gar nicht unter Umständen viel CPU für.
Also solange man nicht viel CPU dafür braucht.
Oder es ist gut dafür geeignet, wenn man viel CPU braucht, aber nicht so viel Concurrency hat.
Wenn man beides hat, man hat viel Concurrency und viel CPU, die das braucht, dann ist es halt eher scheiße.
Weil dann erwischt einen halt dieser Global Interpreter-Log.
Und da stößt man an so prinzipielle Grenzen.
Was Kalierbarkeit angeht bei Python.
Aber ich würde sagen, naja, nicht so schlimm.
Ist eigentlich ganz gut, weil diesen Anwendungsfall haben die wenigsten Programmierer.
Und ein Beispiel war halt Datenbanken.
Eventuell so etwas, was halt genau diese Anforderungen hat.
Und was man dann in Python vielleicht doch nicht so gut schreiben könnte.
Und ja, tatsächlich, Ggraph ist in Go geschrieben.
Und mit Graphen-Datenbanken könnte man das halt tun.
Da kann man halt das Schema ändern, live, ohne dass man irgendwie da so...
Weil man kann halt beliebige Beziehungen ziehen, beliebige Kanten.
Man muss nicht unbedingt sozusagen alles in dieser Tabellen...
Man hat ja nicht mehr unbedingt diese Tabellenstruktur.
Und ja, das ist halt schon ziemlich interessant.
Auch wenn man...
Also es gibt ja nochmal bei den Graphen-Datenbanken sowieso Unterschiede.
Es gibt auch diese ganzen ADF-Geschichten.
Da ist es aber so, dass die das nicht...
So optimiert irgendwie auf der Platte speichern.
Das ist halt eher so ein Textformat.
Es gibt ja auch Mikroformate auf Webseiten, wo man das benutzen kann.
Wo man irgendwelche Metadaten über die Seite hinterlegen kann.
Das ist bei uns auch eine vielleicht nicht so doofe Geschichte.
Gerade was Google angeht, Mikroformate.
Dann kann halt Google automatisch eine ganze Menge Informationen aus der Seite ziehen.
Ohne dass sie das halt irgendwie raten müssen.
Das geht auch schon alles so ein bisschen in Richtung Semantik-Web.
Aber das Problem dabei ist, es ist halt nicht optimiert.
Und für Graphenabfragen auch nicht optimiert.
Daher wird es halt immer ziemlich langsam sein.
Und es gibt halt Graphen-Datenbanken, die das halt so optimiert speichern.
Dazu gehört D-Graph auf jeden Fall.
Die älteste und weitestverweitete Datenbank Neo4j macht das auch so.
Aber Neo4j ist halt auch...
Das ist halt Java.
Kann ja schon mal nicht gut sein.
Aber es ist halt auch viel langsamer, muss man sagen, als D-Graph.
Und es ist halt auch...
Es hat eine komische Abfragesprache.
Also Cypher heißt die irgendwie.
Und naja.
Und ob das alles so...
Ist auch Acid und so.
Das ist alles nicht so...
Also es geht in die Richtung, aber es ist nicht so toll.
Irgendwie.
Und bei D-Graph sieht das alles viel besser aus.
Und was auch super cool ist bei D-Graph, ist die Abfragesprache.
Die nehmen einfach GraphQL.
Oder ein Dialekt davon.
Und das ist natürlich auch nochmal sehr interessant.
Weil GraphQL ist natürlich auch momentan ein sehr heißes Thema.
Und möglicherweise, wenn man jetzt ein neues Amazon bauen würde...
Würde man damit anfangen.
Würde man jetzt das vielleicht nicht auf einer relationalen Datenbank aufsetzen,
sondern auf sowas wie D-Graph.
Und dann könnte man das so bauen,
dass sich die Navigation je nachdem, was man da einkauft,
halt ändern lässt.
Auch live.
Und ist ja trotzdem schnell.
Und...
Ja.
Und das wäre so ein bisschen...
Dann könnte die Reise irgendwie gehen.
Ich habe keine Ahnung, ob das passieren wird, aber...
Ja, let's go.
Ja, genau.
Und dann auch, was auch interessant ist,
ist halt noch, dass man irgendwie durchaus
so hybride Formen haben kann
zwischen Dokument-basiert
oder Schema-less
oder nur SQL,
nur NoSQL.
Das steht halt entweder für Not-Only-SQL
oder eben
kein SQL.
Ähm...
Naja...
Äh...
In Toastgres hat man zum Beispiel die Möglichkeit,
das ein bisschen zu kombinieren.
Da gibt es halt ein sehr schönes...
Ähm...
Sehr schönen Spalten-Typ.
Nennt sich...
Äh...
Binary-Jason.
Ja, so muss es auch passen.
Jason gibt es auch.
Ist aber nur so aus Legacy-Gründen noch dabei.
Den nicht nehmen.
Der ist...
Äh...
Der ist alt.
Und nicht so gut.
Aber Binary-Jason ist super,
weil...
Weil, äh...
Da kann man auch Indizes auf Felder
innerhalb von dem Jason machen.
Das heißt, man kann halt die Teile, bei denen man sich nicht sicher ist,
wie das Schema dafür eigentlich aussehen wird,
oder die man, wo man sozusagen die Definition des Schemas
in die Applikation verlagern möchte,
also wo dann ein Applikationsentwickler sagen kann,
okay, an der Stelle speichere ich die Daten jetzt so und so.
Ja, ich möchte aber gar nicht die Datenbank verändern.
Dann kann er das,
wenn er das in eine Spalte schreibt, die halt Binary-Jason ist,
einfach so reinschreiben.
Er kann sogar Sachen da drin indizieren und so.
Und, ähm...
Und das ist halt...
Zack, schnell.
Das ist ähnlich schnell wie MongoDB.
MongoDB macht ja...
MongoDB ist mehr oder weniger nur diese B-Jason-Spalte
aus Postgres.
Das ist halt mehr oder weniger das Gleiche.
Das heißt, wenn ich jetzt...
Ich kann das, was ich mit MongoDB mache,
auch in einer solchen Spalte in Postgres machen.
Ja, gut.
MongoDB ist vielleicht noch ein bisschen schneller,
hat noch ein paar andere Funktionen, aber...
Ja...
Das...
Also...
Ich glaube nicht, dass viele Leute
tatsächlich was anderes brauchen würden.
Ich kann aber auf der anderen Seite bei den Sachen,
bei denen ich...
Wenn ich weiß...
Also, es gibt ja so etablierte Geschichten,
da ist schon klar, wie das funktioniert.
User-Verwaltung,
wenn ich eine Webseite habe,
so, wenn sich User anmelden...
Das ist alles relational,
das ist auch etabliert,
da wird sich jetzt auch nicht so viel dran ändern.
Und dann für die Teile der Applikation,
wo ich mir halt nicht sicher bin,
wo ich nicht weiß, in welche Richtung das geht,
mache ich dann halt...
Schreibe ich das halt als JSON,
irgendwelche Spalten da.
Und wenn das dann halt klar geworden ist,
wie das Schema da aussieht,
dann ziehe ich das dann auch Stück für Stück
in ein relationales Schema.
Sodass ich halt dann Vorteile aus beiden Welten habe.
Und ich würde sagen,
das ist halt momentan auch so ein relativ unschlagbares Feature
von Postgres gegenüber den meisten anderen Datenbanken,
dass man das halt so flexibel miteinander kombinieren kann.
Weil, wenn ich MongoDB habe,
habe ich ja das Problem,
okay, also relational und konsistent und sicher und so,
das geht halt alles nicht so richtig gut.
Ich habe halt nur dieses Ding,
wo ich halt meine...
Ich kann zwar auch ein Schema definieren oder so,
aber...
Ja, das ist alles nicht so weit wie bei Postgres.
Ja.
Ja, also genau,
das wollte ich auch noch erwähnt haben,
dass das halt eine schöne Geschichte ist an Postgres.
Ja, ich glaube, langsam haben wir es, ne?
Ja, und so langsam sind wir dann eigentlich im Grunde...
Ich habe ja wirklich viel durchgehalten heute,
also über drei Stunden,
das war schon die Mammut-Folge hier jetzt, also...
Okay, ja, aber ich bin mal auch gespannt,
wie das so ankommt,
weil das ist ja jetzt immer so ein bisschen...
Das ist ja jetzt nicht so ein Einsteiger oder so,
sondern das ist einfach mal so komplett durch...
Ich habe möglicherweise auch eine Menge Unsinn erzählt,
das kann leider auch sein, weil das ist halt auch so...
Ja, aber man kann sich irgendwann die Folge nochmal anhören,
wenn man so ein bisschen weiter ist in dem Thema,
und dann vielleicht merkt man so,
hey, wow, ja, das waren einige interessante Gedankengründe,
wie sich das so verändert im Laufe der Zeit.
Ja, ach so, PIX, genau.
Ja.
Hast du...
Du machst...
Was machst du mit Datenbanken oder welche Sachen?
Ich bin ja noch gerade am Anfang.
Ich nehme erst mal so ein bisschen SQLite oder sowas,
das ist ganz super, das ist ja direkt dabei,
und dann kann man direkt loslegen
und seine ersten Datenbanken ein bisschen füttern.
Für den Einstieg auch gar nicht so schlecht,
dann kann man erst mal ein paar SQL-Skaten sehen
und vielleicht mit SQL-Alchemy das machen und dann...
Das ist auch interessant.
Ich glaube, SQLite ist eine der Softwaren,
die mit am weitesten...
Die weiteste Deploy-Basis hat irgendwie so.
Ich glaube, das konkurriert noch mit Curl oder so.
Das wird auch fast überall SQL mit drin.
Aber ich glaube, SQLite ist auch ein Kandidat für das.
Das ist fast überall drin.
Das ist auch Core Data,
das ist der Datenabstraktionslayer von iOS.
Da ist auch SQLite drunter.
Das ist in fast allen Browsern drin.
Das heißt, wenn man einen Browser hat, hat man SQLite.
Das ist auf einer Apple Watch.
Das ist eine SQLite-Datenbank und zählt die Schritte.
Das ist ein echter Teil.
Also es skaliert von einer kleinen Uhr
zu, ich glaube, momentan das theoretische Limit für SQLite
sind irgendwie 144 Terabyte oder sowas.
Kriegt man schwer voll.
Ja, und es gibt, glaube ich, große SQLite-Datenbanken
tatsächlich da draußen.
Das ist ein super interessantes Projekt.
Ich glaube, es wurde mal vorgeschlagen,
für Langzeitarchivierung das SQLite-Format zu nehmen,
weil es halt so...
Von irgendeiner Bibliothek.
Weil es halt auch sich seit Jahren nicht mehr geändert hat.
Das ist relativ schnell.
Und ja, SQLite, super cooles Projekt.
Und im Zusammenhang ist auch einer von meinen Pics,
was man sich vielleicht mal angucken kann,
ist ein Projekt namens Datasette.
Datasette.
Die Kassette, also zum Aufrollen noch.
So wie, genau.
Und zwar geht es darum, dass halt für so Datenjournalismus,
es geht darum, dass man...
Datensätze, die irgendwo veröffentlicht wurden,
wie man die jetzt navigierbar macht,
für Leute, die jetzt nicht das in eine Datenbank importieren wollen
und dann selber Statements schreiben.
Und das macht das halt.
Und man kann ja CSV ausnehmen, die da reinwerfen.
Und dann kriegt man halt so auch ein Interface
mit Facetten Navigation, mit Volltextsuche,
weil halt auch SQLite kann halt Volltextsuche.
Und man kann sogar SQL Statements reinschreiben.
Man kann aber auch das irgendwie über eine Webseite navigieren.
Das ist ziemlich cool.
Und ja, das wollte ich auf jeden Fall mal erwähnt haben.
Das kann man sich mal anschauen.
Es gibt dann da so Teile von,
wo man auch CSVs automatisch in SQLite-Datenbanken umwandeln kann.
Auch interessant, dass man da so frei SQL-Statements irgendwie eingeben kann.
Das geht ja auch kaum.
Aber das geht halt deswegen, weil man bei SQLite auch sagen kann,
oh, das ist jetzt ein Read-Only-Datenbank.
Und dann kann man halt mit Statements nichts mehr kaputt machen.
Ja, das ist halt ein sehr schönes Projekt.
Ja.
Dann, genau.
Also, auch wie man auf Datenbank...
Von Python aus zugreift.
Es gibt so Async-PG als asynchroner Datenbank-Client für Python.
Das wird noch sehr interessant.
Also, das ist notar noch ein Problem.
Also, Psycho-PG ist halt so der Standard-Postgres-Datenbank-Client für Python.
Und der kann aber nur Textprotokoll und nicht Binary.
Ist halt schon relativ schnell.
Aber es geht halt mit dem Binärprotokoll halt noch schneller.
Und er ist halt nicht asynchron.
Also, was halt ein Problem ist,
wenn man jetzt zum Beispiel bei Postgres,
macht man jetzt Volltext-Suche und Navigation auf einer Webseite.
Dann hat man, wenn man das mit Django macht,
Django ist auch synchron.
Dann macht man halt einmal,
hat jetzt Facet-Navigation.
Das heißt, man muss halt an den Facetten,
das heißt Text oder Kategorien
oder irgendwelchen anderen Monaten
oder was auch immer man halt navigierbar halten will,
schreibt man halt so Counts dran.
Oder man muss halt überhaupt wissen,
was hat ein Count von größer Null,
damit man diese Facette anzeigt oder nicht anzeigt.
Das sind halt zwei unterschiedliche Statements.
Man kriegt einmal die Suchergebnisse
und dann macht man nochmal ein Statement,
um die Counts zu holen.
Und meistens hat man aber nicht nur diese zwei,
sondern noch ein paar mehr.
Und das ist halt jedes Mal ein Datenbank-Roundtrip.
Das ist jedes Mal, dauert das irgendwie ein paar Millisekunden.
Also bei den Suchanfragen, bei den Counts,
dauert es sogar so irgendwie 30, 40 Millisekunden.
Sodass man halt bei so einer normalen Navigation auf einer Seite
wahrscheinlich schon so 150 Millisekunden nur SQL-Anfragen hat.
Und dann ist man schon bei,
wenn dann das Template gerendert wird,
ist man leicht bei 400, 500 Millisekunden.
Und das ist halt dann schon relativ lang.
Das ist schon viel für eine Webseite.
Eigentlich ein bisschen zu viel.
Und man könnte es leicht deutlich drücken,
wenn jetzt diese Statements,
die ja nicht voneinander abhängen,
sondern die man auch parallel abfeuern könnte,
tatsächlich parallel an die Datenbank gestellt würden.
Und dann hat man nur noch,
ist die Latenz oder die Zeit, die man braucht,
um SQL-Abfragen zu machen in dem Webfrontend,
dauert nur noch so lange wie das längste Statement.
Und alle anderen Sachen,
die sind halt vorher da.
Und das würde halt wahrscheinlich bedeuten,
dass dann ist man runter auf 50 Millisekunden oder so.
Dann hat man 100 Millisekunden gespart.
Das wäre ziemlich cool.
Aber dafür müsste halt Django asynchron sein.
Dafür müsste man halt irgendwie Async-PG verwenden
statt Psycho-PG.
Und das wird alles noch ein bisschen dauern.
Wahrscheinlich Jahre, fürchte ich.
Ist auch so, dass der Autor von Django Channels,
das ist diese Geschichte mit den Web-Sockets,
dass man halt bidirektionale Kommunikation
zwischen Client und Server hat bei Web-Anwendungen.
Der hat jetzt dieses Projekt so ein bisschen aufgegeben
oder ist nicht mehr Maintainer davon.
Und das, was man jetzt macht,
ist jetzt der Versuch, Django Async fähig zu machen.
Ich bin mal gespannt, wie das wird.
Das war ja auch in der Django-Folge,
hatten wir das ja irgendwie kurz,
ob das vielleicht eventuell eine Richtung wäre,
in die sich Django entwickeln könnte.
Und ja, es sieht danach aus,
so ein bisschen als ob es kommen würde.
Und damit sind wir im Grunde durch.
Sind wir durch mit einer Mammut-Folge.
Wenn ihr es bis hierhin geschafft habt, also gut ab.
Es wird jetzt einiges mehr über Datenbanken,
dass man damit alles anstrengen kann.
Ja, schöne Sache.
Super, dass ihr dabei wart.
Und ja, wo ihr auch immer hier seid,
schönen Tag und so weiter.
Wenn ihr Fragen habt, hallo.at.peisenpodcast.de
Ja, dann bis zum nächsten Mal.
Auf Wiedersehen. Tschüss.