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 den 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.
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.
Wollen wir das eigentlich 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?
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.
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 Modules 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 drum herum
kommen, irgendwann etwas mit Datenbanken zu machen.
und
ja, dafür muss man sich halt dann auch
nicht nur mit Python auskennen, sondern man 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.
Wir werden noch ein bisschen darauf eingehen, was ist das überhaupt,
eine Datenbank, unterschiedete einzelne 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.
Da hat man uns gedacht, nehmen wir einfach 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 jeder schon mal benutzt und weiß halt, wie das funktioniert und das ist halt eigentlich, denke ich, ein ganz gutes Beispiel für, wofür braucht man eigentlich Datenbanken, weil die haben wahrscheinlich auch für fast alle Datenbanktypen irgendwie eine Anwendung und darin kann man das vielleicht ganz gut erklären.
Ja, dann 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 gedanklich dazu macht. Wie sieht denn meine Struktur der Daten überhaupt aus? Was will ich denn damit machen? Wie würdest du da direkt vorgehen?
Ja, also das kommt tatsächlich auf den Anwendungsfall an und was sich halt in der Praxis in den letzten Jahrzehnten so durchgesetzt hat, sind relationale Datenbanken, aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre Berechtigungen.
Für alle, die das noch nicht drauf haben, ist es so SQL oder NoSQL, genannt oft.
Ja, es hängt halt davon ab. Also man kann natürlich auch einfach Python-Objekte nehmen, die irgendwie serialisieren, nennt man das. Also zum Beispiel gibt es in der Standardbibliothek 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 Datenmarken eine sehr wichtige Geschichte. Und man könnte jetzt zum Beispiel diese Byte-Folgen oder Strings nehmen und die halt teilenweise in einen Pfeil reinschreiben und dann hinterher auch wieder auslesen.
Also man nimmt einfach zum Beispiel, wenn man jetzt den State von irgendeinem Programm speichern möchte, nimmt man einfach alle Objekte, die man jetzt so findet oder die man sich irgendwo gemerkt hat, dass man sie hat und serialisiert die halt in Zeilen, schreibt das Ganze in ein File.
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 Spieler-Daten aus dem Sport, habe ich einfach alle Informationen über einen Spieler in eine Teile gepackt und die teilenweise in eine Datei reingeschrieben.
Genau, und dann, wenn man jetzt den Status wiederherstellen will des Programms, wenn man das startet, dann nimmt das einfach die Datei, liest alles wieder ein und dann ist 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-Zeilen 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. Ist wahrscheinlich nicht die beste Methode, das zu tun, aber funktioniert hat es trotzdem.
Genau, und wenn man sowas macht, das wurde am Anfang irgendwie bei Webentwicklung auch häufig gemacht, das nannte sich dann Flat Files, Datenbank mit Flat Files, man nimmt einfach Files und schreibt den State da irgendwie rein und natürlich ist auch das Filesystem ja schon irgendwie eine Art Datenbank, das ist halt eine hierarchische Datenbank, die halt so eine Baumstruktur hat und deren Blätter halt Files sind, Wurzel ist halt Root, Slash bei Unix-Systemen oder was weiß ich, bei Windows ist es irgendwie was komisches mit dem Laufwerksbuchstaben.
Und ja, das ist natürlich auch
eine Struktur. Man hat halt irgendwie darüber
die Verzeichnisse, die es da gibt, auch schon
so Metadaten definiert, dass man halt weiß,
so bestimmte Sachen sind halt in einem bestimmten Verzeichnis und so.
Und
das Ganze gibt es halt auch über
Netzwerkgeschichten.
Die bekannteste hierarchische Datenbank
im Netz ist halt sowas wie LDAP.
Windows nennt
das irgendwie Active Directory oder ist auch vielleicht noch
ein bisschen komplizierter.
Und ja, das ist halt schon mal eine
grundsätzliche Art, wie man Datenbanken
betreiben kann.
Aber vielleicht, was ich
ganz gerne auch nochmal
ansetzen würde, ist,
wie Leute, also wenn man jetzt sich
überlegt, wo könnten Leute
etwas, das man
sonst vielleicht mit Datenbanken tun
könnte, irgendwie schon mal gesehen haben? Oder was
machen viele Leute, was halt eigentlich auch
gut in den 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
Datenbanklösung
der Welt,
könnte man auch sagen, das ist halt Excel, weil
viele Leute halt Excel quasi als
Datenbank benutzen. Allen möglichen
Quatschen, irgendwelche Spalten und Teilen reinschreiben und
ganz, ganz, ganz, ja.
Und
das ist, genau, das ist halt
eigentlich, ach so, und vielleicht sollte man sich
erstmal grundsätzlich überlegen,
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.
Dafür hat man umgangssprachliche
Definitionen,
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 hat, minus 3,5, was denn?
Ja, genau, richtig.
Grad Fahrenheit.
Und 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 Temperaturspalte.
Und damit weiß man schon mal so ein bisschen, worum es da überhaupt geht.
Und dann nimmt man das Informationen.
Und das, was man aber eigentlich in Datenmarken 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.
Und das halt in einer Struktur, die halt bestimmte Anfragen leichter macht, halt gespeichert hätte, dann kann man damit möglicherweise das Wetter vorhersagen oder sowas.
Das heißt, man 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 als so und so oder irgendwie sowas.
Genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.
Da kann man auch Analysen irgendwann machen.
Das ist aber dann, glaube ich, wieder ein neues Thema,
wie man Analysen dann mit Daten fährt.
Das werden wir heute, glaube ich, nicht machen.
Doch, doch, doch.
Ja, doch, doch, doch, alles.
Ihr müsst heute lange, lange Geduld mitbringen
oder eine große Runde durch den Park
oder 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 hätte
so ungern davon ab, so ins Detail zu gehen, weil ich finde das
unheimlich interessant, was da alles noch so drinter steckt.
Ich bin da sehr curious, was man 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 mit dem Beispiel an oder wolltest du noch so ein paar
grundsätzliche Dinge über Daten? Genau, ich würde einmal
grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken,
auch um halt dann,
ja, um
darauf dann wieder Bezug nehmen zu können in dem Beispiel
und vielleicht auch das, was halt
jetzt durchgesetzt hat, jedenfalls
das ist halt, eben
hierarchische Datenbanken gibt es schon
ganz lange und
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 irgendwelche Dinge damit später
machen, wie man das so grundsätzlich
eingehen sollte und dessen
Idee war halt, also
ein Problem, was er gesehen hat, mit den bisherigen
Ansätzen war,
dass viele Leute
Zeit damit verbracht haben,
die Daten, die sie
halt schon auch irgendwie strukturiert, aber halt in
eigenem 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.
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 nichts zu suchen haben, oder?
Ja, weil sie halt nicht normalisiert sind, weil es nicht so wirkliche...
Oh, jetzt kommen wir direkt mit den Normalisierungen.
Weil es nicht wirklich Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es halt alles schon und da gibt es, wenn 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, relativ großes Problem, denke ich, dass 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 irgendwie vor zehn Jahren ungefähr irgendwie so einen 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 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 der 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 der aus der Programmiererecke, wollte halt die Daten auch anders noch zugänglich machen und wollte halt gucken, ob man da nicht übergreifend irgendwelche Anfragen stellen kann und fragte den dann so, wo denn die Daten wären oder wie er die denn speichern würde.
Und der sagte so, oh ja, ich habe da hier irgendwie ein paar tausend Excel-Files auf meinem Desktop und da sind die halt drin. Und ich weiß halt, in welchen Daten, in welchen Files.
da 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
Domain, aber... 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 hat halt,
man kann darüber jetzt keine übergreifenden
Anfragen stellen, dann hat man auch so ein Problem, wenn man
mit Leuten zusammenarbeitet.
Ja, wie
ist das eigentlich, wenn mehrere Leute das jetzt ändern?
Dann gibt es auch wieder so komische Strategien,
wie, naja, man hat das dann irgendwie auf einem 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 da machen möchte, 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 also aus meiner
Perspektive auch so die beiden
Dinge, wo man...
Wenn man in Firmen
so leichte Gewinne,
die man machen könnte, also die
beiden Themen, die halt vollkommen
unterschätzt
sind, aus meiner Perspektive,
sind einmal Versionskontrolle.
Also das sehe ich ganz oft,
dass halt jetzt, also bei Programmierern,
die wissen inzwischen, wie das
funktioniert und machen das halt auch.
Bei denen ist halt Verständnis, was jetzt
Git ist und wie man das verwendet, irgendwie
durchaus angekommen.
Mal bitte den Git-Flow.
Aber
in den meisten anderen Abteilungen,
wo es nicht um Programmieren geht,
die haben von solchen Dingen noch nie
irgendwas gehört. Dann nimmt man Tippex und
malt da kurz die Buchstaben, die falsch sind, raus
und fahrt dann da drüber. Und wenn man
wissen will, was da vorher stand, dann muss man das Tipp-Eck abkratzen.
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 geht.
Tabelle 1, Tabelle 1 neu, Tabelle 1
neu, neu, neu, final und
ja, jetzt erst wirklich und
allerneueste Version. Also da
könnte man mit wenig Aufwand viel erreichen
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
Habt ihr jetzt 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, viele Leute da so
Excel mit irgendwelchen Makros drin oder
irgendwelche Skript-Schnipseln drin haben,
warum die das verwenden.
Das Problem ist halt, das funktioniert
meistens und dann funktioniert es irgendwann nicht mehr oder
die Daten ändern sich und dann muss man halt irgendwie
einen Teil von einem VBA-Skript
oder so irgendwie so ein bisschen anpassen 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.
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 Programmierer-Sicht
nicht so das, was man tun sollte.
Man kann damit Stunden um Stunden um Stunden um Stunden
Genau, aus Programmierer-Sicht 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 bald mit Python
gehen, habe ich gehört. Ja, ich weiß, dass
bei Microsoft gibt es irgendwie so ein,
die haben da auch so ein Priorisierungstool
sozusagen, ich weiß nicht genau, was das ist
und ich glaube, das meiste nach
Requested Feature ist es, VBA durch Python
zu ersetzen, irgendwie 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
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
einen Vorteil dadurch, 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 so richtig
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
genau, also eigentlich wäre das, was
viele Leute damit machen, die werden
viel besser bedient, wenn sie halt Python
nehmen würden und eine relationale Datenbank
und
weil die eben diese ganzen
Geschichten auch löst. Da gibt es dann halt, wenn
mehrere Leute drauf zugreifen und Dinge ändern,
dann sorgt die Datenbank dafür,
oder das Datenbankmanagementsystem,
dass da nichts schief geht,
dass alle Leute immer die gleichen
Daten sehen, jedenfalls innerhalb von einer Transaktion
und so und
da gibt es
auch die ganze Zugriffskontrolle und all das
ist alles schon fertig implementiert
und
ja, das ist halt so das, was Leute
im Grunde verstehen, wenn sie
wenn man von Datenbanken spricht
denke ich
aber es gibt halt auch noch eine ganze Menge
anderer Datenbanken und dass sich
relationale Datenbanken so durchgesetzt haben, ist auch
aus meiner Perspektive ein Stück weit
Glück oder hängt halt an der
Geschichte von einzelnen Firmen, also man
hätte sich auch durchaus vorstellen können, dass sie andere Paradigmen
durchgesetzt hätten, haben sie
aber irgendwie nicht.
Und jetzt sind halt so
relationelle 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,
um mal zu sagen, was es sonst noch alles gibt.
Es gibt halt
Dokumentendatenbanken, ja, gibt es auch schon
ganz lange. Lotus Notes
ist ja so ein Beispiel für
ist ja früher Microsoft
auch ganz populär.
CouchDB,
MongoDB, die
fallen auch in diesen
Dokument-Datenbank-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
Lotus Notes-Dings-Projekt kommt.
Es gibt Key-Value-Stores,
wo man einfach nur
irgendeinen Hash irgendwie, also man kann
sich das vorstellen wie ein Python-Dict,
wo man halt irgendwelche Keys hat
und dann hat man irgendwelche Werte, die man dann zurückbekommt,
wenn man den Key dahin schickt.
Darunter fallen so Sachen wie Redis
oder Memcached oder so
oft zum Cachen verwendet, aber manchmal können sie auch
kompliziertere Sachen oder weiter
strukturierte Daten. BerkeleyDB war
lange ganz groß, wird heute gar nicht mehr so sehr verwendet.
Ja, aber auch sowas
wie Amazon Dynamo
oder so fällt da auch drunter.
Und dann gibt es halt noch so spaltenorientierte
Datenbanken, wobei ich auch da sagen würde, es gibt
zwei unterschiedliche Arten, aber
halt sowas wie Bigtable, wo Google
einen Index drin speichert oder das
entsprechende Hadoop-Äquivalent
oder das Äquivalent aus dem Hadoop-Ökosystem,
HBase.
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, sondern
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,
vielleicht kann man das nachher nochmal
im praktischen Beispiel ein bisschen besser erläutern.
Ja, genau, aber das ist halt
so eine ganz andere Art von
Datenbanken, die aber auch, also da würde
ich sagen, das hätte auch sich anstelle von relationalen
Datenbanken durchsetzen können.
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 ein Grafendaten-Button.
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-DV oder.
TimescaleDB
oder halt sowieso
für, du hast halt ein bestimmtes Problem
wie, du möchtest dieses
bei Google sieht man, 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, und manchmal
sind solche Funktionen auch in
so verbreiterten
Datenbanken enthalten, aber es gibt halt
auch mal spezialisierte Geschichten dafür.
Ja.
Vielleicht die ganzen Basissachen werden noch komplett
nicht kurz erwähnt.
Keine Ahnung, MySQL
oder Postgres. Achso, das sind, ja genau,
das sind Beispiele für relationale Datenbanken.
Ja, MySQL,
Postgres, das wären jetzt die Open-Source-Vertreter.
Oracle und
MSSQL-Server,
Sybase, das wären so die kommerziellen
Geschichten.
DB2 von IBM.
Oder zur Historie,
im Grunde die,
nachdem dieses Paper
irgendwie, das sollte man
in die Schonungs packen, das ist sehr empfehlenswert, das nicht mal
zu lesen von Headquart. Der hat damals bei
IBM gearbeitet
und da ist
ein System daraus entstanden, das nennt sich System R.
Das haben irgendwie so ein paar Leute bei IBM geschrieben und daraus ist halt die B2 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.
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 und set of the art
immer noch dabei, es kommen immer noch tolle Sachen dazu.
Ist
wahrscheinlich auch so die,
sie nennen sich selber irgendwie die
ich weiß gar nicht,
wie ich das übersetzen soll, Advanteste,
Die fortschrittlichste Open-Source-Datenbank,
ja. Gut, Oracle und so
hat wahrscheinlich noch ein bisschen mehr Funktionen, aber
ja,
tatsächlich wird meistens
aber, wahrscheinlich aus Kostengründen,
tatsächlich jetzt so
im Internetumfeld irgendwie dann meistens werden so
Open-Source-Datenbanken verwendet.
Ja,
ich habe schon mal gesehen, dass Leute Oracle verwenden,
aber das ist eher selten.
Jetzt so als
Backend für Webseiten
verwendet man normalerweise nicht. Oracle ist halt auch
viel zu teuer. Oder
MSSQL-Server, doch, das gibt es tatsächlich
Leute, die das als Backend für
Webseiten verwenden.
Ein Beispiel
einer populären Seite, die halt auf
MSSQL-Server läuft, ist
Stack Overflow. Das ist auch
faszinierend.
Ich meine, einer der
ich weiß nicht, ob es
der Gründer selber war, der war auch
Produktmanager bei Microsoft, glaube ich, insofern
die machen viel auf dem Microsoft-Stack
und holen da unglaubliche Sachen raus.
Also die haben irgendwie ein halbes Rack oder
das ist jetzt auch schon lange her, dass ich
da irgendwie Artikel zu gelesen habe, aber
das letzte Mal, dass ich das gesehen habe, war
Stack Overflow tatsächlich unter den Top Ten
der trafficstä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. Und das ist überhaupt so was,
was halt wahrscheinlich viele Leute nicht wissen,
die jetzt 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 Hauptsprecher.
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, ist halt
der größte Datenbankbereich eigentlich.
Ja, vielleicht
können wir dann, wollen wir zu dem praktischen
Beispiel. Ja, 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 jetzt uns jetzt so, ah, da liegen jetzt ganz viele Bücher auf dem Boden und dann will irgendjemand bestellen, dann muss dann irgendjemand in die Garate 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 lange suchen muss, deswegen haben wir jetzt überlegt, ja, pass auf, wir schreiben das Ganze jetzt in eine Datenbank.
Wie fangen wir jetzt mal an, vielleicht reden wir kurz über das Schema, wie man sowas aufbaut nochmal kurz.
Genau, also man würde jetzt zum Beispiel eben die Mitteilinformationen über diese Bücher, also sowas wie Titel, ISBN-Preis und so, würde man halt in eine Datenbank schreiben.
Durchschnittliche Anzahl von Buchstaben pro Seite.
Vielleicht, ja, was auch immer man da, man würde das halt in eine Tabelle schreiben, aber man würde jetzt möglicherweise schon nicht den Autor, wenn man jetzt den Autor, 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.
Wir könnten Suche und Ersetze machen und dann machen wir sowas, dann machen wir für jedes Jahr, das wir 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 das 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 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, anderes Beispiel wäre User,
die jetzt auf der Webseite irgendwas einkaufen wollen oder so.
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, es 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
vergisst 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 Dinge, die man einmal gefixt hat, dann nochmal auftauchen.
Das ist doch bestimmt schon einmal passiert, oder?
Also mir hat das früher ständig passiert und dann ist mir irgendwann aufgefallen,
oh, ich mache eine Funktion und dann mache ich die Funktion auch.
Dann macht man eine 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 ist bei Datenbanken halt auch nicht,
weil das beißt sich so ein bisschen mit anderen Anforderungen, die man hat.
Wenn es halt schnell sein soll, dann ist das manchmal etwas schwierig, weil relativ nahe Datenbanken, dann wenn man halt viele Tabellen miteinander verknüpft, man nennt das halt Join, das heißt man kann halt anhand von diesen Verzweigungs-, also Fremdschlüssel-Dingsies kann man halt Tabellen aneinander verketten.
Man kann sich das vorstellen, man legt die halt sozusagen nebeneinander, sodass halt die Spalte mit dem Schlüssel übereinander liegt und wenn man das mit vielen macht, dann werden die Abfragen langsam.
So ein bisschen wie an so einem Spielautomaten.
Wenn ihr so einen einarmigen Banditen habt,
dann zieht ihr einmal dran, da sind ja so drei verschiedene
und wenn ihr dann parallel sind und alles zeigt, gewinnen,
dann habt ihr den Schlüssel, den ihr braucht.
Dann hat man die Zeile
von dem Schlüssel irgendwie zusammengeführt.
Ja, genau.
Ja.
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.
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 der Unterschied zwischen den Normalformen sind.
Irgendwie kann man sich auch durchlesen auf Wikipedia oder so.
Braucht man auch im Alltag eigentlich gar nicht zu
wissen, sondern da hat man dann halt irgendwann
ein Gefühl dafür, wenn
ein Datenbankschema okay aussieht.
Und dann macht man das halt so.
Das heißt, ich gehe jetzt tatsächlich erstmal hin
und nimm ein Whiteboard, einen Zettel
und schreib mir auf, wie die Daten aussehen
sollen. Ja, ja, tatsächlich. Also wenn ich
irgendwie eine 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?
Ja,
das kommt darauf an, was das dann für eine Änderung ist.
Das ist 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 das alte Datenbanken noch kompatibel sind oder sowas, oder?
Ja, dass man das so ändert,
dass nicht irgendwelche Inkonsistenzen entstehen.
Und auch, dass halt...
Wie wäre das jetzt bei unserem Beispielbeispiel?
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.
Aber vom Cover, jemand, oder das
Genre oder sowas, jemand sammelt Seefahrerbücher.
Ja, 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,
Militristik,
Komba, Seefahrer Roman oder
Komba, schreibt man jetzt Komba 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 machen sollte, ist halt, dass es
diverse Anfragen halt schwierig macht
und dass man es auch sehr schlecht ändern kann
und dass wenn man was ändern kann, man Sachen kaputt machen,
weil
Inkonsistenzen entstehen können und so.
Dann zieht man erst mal
diese Dinger auseinander und sagt halt,
okay, nicht in einer Spalte
mehrere Tags reinschreiben,
sondern dann hätte man sozusagen
eine End-to-End-Relation, also nicht nur,
wo ein Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel
in eine andere Tabelle passt, sondern man hat
dazwischen eine Link-Tabelle. Man hat jetzt einmal Tags
als Relation und einmal halt die Bücher
als Relation oder als Tabellen halt
und dazwischen hat man jetzt noch eine Link-Tabelle
zwischen oder Link-Relation zwischen
Büchern und Tags, sodass
man mehrere, also für jedes Tag hätte man
dann sozusagen einen Eintrag in der Link-Tabelle,
wo dann drin steht
ID von diesem Buch,
ID von diesem Tag. Ja, und das ist dann halt
sozusagen der, 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 1.000 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,
ein paar 10 Millionen Zeilen oder so lang ist,
wo halt jedem Buch ein paar Texte zugewiesen werden.
Und dann ist alles wieder schön in der 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 Texts oder Kategorien sind,
dann würde man versuchen,
wahrscheinlich Nested Sets nehmen.
Das ist, kann man sich mal angucken,
das interessiert, wie das, dann kann man dann halt auch
per SQL Abfragen machen, wie
ja, welche Bücher liegen denn jetzt
unterhalb von dieser Kategorie.
Was man macht ist, man schreibt an jede,
man hat so eine Kategorie einen Baum und man schreibt dann an
jedes Element
in dieser hierarchischen Struktur,
den traversiert 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
rausselecten kann und so. Aber das ist dann
halt schon so wirklich für Fortgeschrittene.
Und im Endeffekt,
wenn man jetzt große
Grafenstrukturen hat oder Bäume,
dann wäre es wahrscheinlich besser, das gar nicht mehr in einer relationalen Datenbank
zu machen, sondern das irgendwie in einen anderen Service
zu packen.
Ja, und da sind wir schon,
boah, das ging aber schnell, da sind wir schon an Grenzen,
wenn man so eine Relation an Datenbanken machen kann.
Ja, also das Dorsch nach der Garage ist mittlerweile rausgewachsen,
also 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,
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 Datenbanken,
sind halt so Transaktionen-Prozessen,
So 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 einen 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...
Mir fällt direkt wieder eines der Probleme ein.
Okay.
Ja, 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 die 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 Prozent dieser Kunden einfach gar nicht am Ende kaufen,
sondern irgendwie wieder abspringen, weil die dann sagen,
na ja, doch nicht oder so.
Und dann hätten jetzt ja alle sich bei sich einen Warenkorb reingedickt
und wenn nur noch eins da ist,
vielleicht hätte der zweite direkt angezeigt bekommen,
geht 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.
Du kopfst in die Luft.
Oh, leider war jemand schneller und hat vor zwei Sekunden das Buch gemacht.
Genau, du kannst, sobald du draufdrückst,
in dem Moment, wo sozusagen diese Bestelltransaktion gestartet wird
und dann in der Datenbank aber
die Bedingung, es muss mindestens eins im Lager
sein, damit 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 dem User eine Fehlermeldung anzeigen und sagen so,
oh ja, tut uns leid, das hat nicht geklappt.
Kein Buch mehr auf Lager.
Das ist ja im Grunde okay.
Ja, gerade so.
Ja, also was halt
blöd wäre, ist, wenn man dem User sagt,
okay, du hast das jetzt bestellt.
Und dann sagt er am Schluss, ätsch, ätsch, du kriegst doch kein Buch, weil war keins mehr da. Das ist halt so ein bisschen blöder. Ist aber eine Situation, die dann später, wenn wir halt nicht mehr auf einer Datenbank bleiben können, weil das einfach nicht mehr, also 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 da im Grunde kein Problem, kann man das sauber lösen.
Ich hatte ja so etwas, ich hatte das vielleicht schon mal kurz erwähnt, bei einer Bank. Ich habe eine Transaktion gemacht, da hat dann die Bank gesagt, ja, ist wunderbar, deine Überweisung wurde vernünftig ausgeführt. Und dann zwei Wochen später kriegte ich dann so eine Mahnung und dann habe ich nochmal aufs Konto geguckt und die Transaktion war weg. War nicht da.
Was habe ich dann da angerufen? Da haben die gesagt, oh ja, also in irgendeiner Logfile stand das dann wohl noch drin, dass ich so eine Transaktion eigentlich gemacht hatte, die aber nicht ausgeführt worden war. Das war ein bisschen blöd dann für mich, aber ja, scheint wohl auch mal so größeren Menschen.
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-Processing gibt, nachts. Also die Sparkassen haben das lange gemacht.
Man schmeißt dann manuell die ausgedruckten Briefchen ins Überweisungs...
Lochkarten.
Fällt 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, 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, wo 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 mal so, das bietet einem Lösungen für dieses Problem und im Grunde, wenn das Ding sagt, ja, die Transaktion ist durch, dann hat das auch funktioniert.
Man kann sich auch darauf verlassen. 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 genau so ein Fall wie, ich kaufe ein Buch, ist halt ein Ding, in der Daten 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 keine 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 ein System habe, das das nicht macht und ich erzeuge die Bestellung, habe jetzt in meiner Bestellungstabelle das Ding erzeugt, sage jetzt in der Lagerstandstabelle dieses Buch 1 weniger und dann sagt das, hier habe ich ein Constraint auf, es darf nicht weniger als 0 werden, also minus 1 Bücher ist schwer, das funktioniert irgendwie nicht so richtig 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 und die Mann ist noch ein Händler,
der hat auch so Bücher und vielleicht hat der
eins da und dann sage ich einfach, ja, ich muss das irgendwo anders herbekommen.
Könnte ich ja auch wollen.
Kann man auch machen.
Müsste dann, ja, das hängt dann vom System
ab, was die Logik dann macht. Man könnte dann sagen,
okay, die Bestellung wird trotzdem ausgeführt, dafür wird dann
aber das... Oder das Buch wird gedruckt oder sowas.
Ja genau, einfach normal produziert. Aber dann verändert sich möglicherweise das Ziel dafür, wann es halt ausgeliefert wird oder so. 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 drin steht, was ich überhaupt alles machen will, machen kann. Und wenn mir irgendwelche neuen Dinge einfallen oder so, dann muss ich kurz überlegen, was, nicht an meinem Schemaende, aber am besten mache ich das Schema am Anfang schon so fertig, vollständig, dass das unproblematischer geht.
Das ist ein bisschen ein Problem. Man sollte ein Schema schon von Anfang an halbwegs so designen, dass es halt passt. Es ist später nicht mehr so ganz einfach, das zu ändern. Man kann das natürlich ändern, aber es ist auf jeden Fall…
Aber das fängt ja ein bisschen vom Geschäftsmodell ab. Wenn ich jetzt auf einmal merke, oh, ich verkaufe jetzt vielleicht gar keine Bücher mehr, sondern, weiß nicht, kompliziertere Produkte oder sowas, 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 wird das ja notwendig. Also ich kann ja nicht jedes Mal eine neue Darkman anfangen, sondern ich muss ja auch gucken, dass sie irgendwie mit skaliert.
Ja, aber das sind wirklich schwierige
Probleme. Das ist ein bisschen
unintuitiv, dass das
so knifflig ist, aber es ist leider so.
Ein wirklich lustiges Beispiel aus der Praxis.
Das zeigt,
dass das halt nicht so einfach ist.
Möglicherweise finde ich es immer iTunes
oder 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 App Store. Und dann
sollte es halt dieses App Store Feature
geben. Und dann haben sie halt einfach
ihr iTunes Song Verkauf Ding
genommen. Und das halt
einfach nur gesagt, okay, das sind jetzt keine Songs, sondern das sind Apps.
Was halt dazu
führt, dass bis heute, und jetzt sind wir mehr als
zehn Jahre später,
bis heute haben
halt irgendwie Apps einen Titel und eine Länge,
Songlänge oder sowas, ja, 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. Okay. Also wenn ich jetzt
also die Daten selber zu ändern, ist glaube ich
nicht so das Problem. Aber 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 wo
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's 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 deine App eine Songlänge
hat, ja.
Ja, aber es ist halt, das zeigt halt
so ein bisschen, wie knifflig das dann
werden kann, wenn man
Pech hat.
Ja, und das ist auch so
ein Problem bei relationalen Datenbanken
insgesamt möglicherweise, würde ich
sagen. Also gerade der E-Commerce-Fall
oder der Amazon-Fall funktioniert
eigentlich ganz gut. Zunächst, also
später wird das dann auch nochmal ein bisschen problematischer, aber
weil
physische Dinge halt
relativ stabil sind, was irgendwie so
ihre Eigenschaften angeht. Also da funktionieren
relationale Datenbanken halt besonders gut.
Unwahrscheinlich, dass so ein Buch noch
ein anderes Cover enthält oder sowas.
Also, dass 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
man jetzt sozusagen
diese physischen Dinge in der Datenbank beschrieben hat,
die kann sich auch nur langsam ändern. Und das passt dann so ein bisschen
zueinander. Also das ist halt,
wenn man jetzt die Eigenschaften von einem Buch erstmal erfasst hat,
dann ändert sich da wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig
viel dran. Und dann muss man auch in der Datenbank nicht so wahnsinnig
viel ändern.
Wenn man jetzt ein anderes Problem hat und
man jetzt zum Beispiel in der Datenbank
nicht Daten über physikalische Objekte
hält, sondern Daten über
Daten.
Oh, Metadaten.
Die können sich
dummerweise unter Umständen, je nachdem
wie... Daten über Daten
über Daten. Ja, das kann sich dann,
da kann plötzlich die Geschwindigkeit, mit der sich die
Strukturen da ändern müssen,
deutlich schneller werden. Und dann wird es schwierig.
Dann sind relationale Datenbanken auch so, das ist dann
ein Problem. Das ist auch möglicherweise
einer der Gründe dafür, warum jetzt in letzter Zeit halt
immer mehr so NoSQL
oder Dokumentdatenbanken
oder
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, weil so absolut kann man das auch nicht
sagen, also es gibt da diverse Möglichkeiten,
wie man die Geschichten miteinander verbinden
kann und
ja, wenn
Schema lässt, ist halt auch nicht Schema lässt, sondern
das bedeutet halt mehr oder weniger nur, dass
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 und dann passieren furchtbare Dinge
und also dann fällt ihnen auf,
dass sie doch ein Schema haben.
Und ja,
dass sie dieses Problem halt doch nicht losgeworden sind.
Also es ist
leider alles nicht so einfach und
das ist tatsächlich
so, dass man bei Datenbanken
halt im Design am Anfang ein bisschen
mehr Arbeit hat, aber dafür hat man auch dann
einen lustigen Vorteil, nämlich
es ist immer so schön, irgendwie
Daten altern wie Wein,
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, 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
Sachen und
Applikationscode erörtert
wie Fisch.
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
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
altern auch die Daten
nicht gut und deswegen ist es eigentlich schon sinnvoll
eine Trennlinie zu haben und 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 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 Lagersachen geben
mit einem Lagerstand von
Minus irgendwas. Das darf halt nicht sein.
Da ist ein Fehler passiert, dann 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 so was
wie ein Gehalt, das darf auch nicht negativ werden.
Oder dass halt
bestimmte Datumsinformationen
halt nicht so und so sein können.
Ja.
Oder dass man halt tatsächlich auch was mit Postgres machen kann. Postgres ist halt wirklich eine schöne Wahl, wenn man jetzt mit so einer Geschichte anfängt. Das kann so tolle Sachen wie, 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 Webseite 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 also 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
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
das einfach löschen würde, dann hätte ich halt
einen Pointer in der Bestellungstabelle, der
halt auf etwas zeigt, was es nicht mehr gibt, das wäre
schlecht, weil ich dann gar nicht mehr weiß,
was es sein soll und so.
Aber trotzdem werden diese Dinger nicht
mehr in den Index geschrieben, also ich kann
halt einen Index so definieren, dass er nur
Sachen, Bücher
mit reinnimmt, die halt
auch tatsächlich noch verkauft werden.
Und das heißt, es ist nicht so,
an solchen Stellen ist Postgres halt sehr schön, hat
sehr viele Features, zum Beispiel
jetzt im Unterschied zu MySQL, wo das halt,
wo 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, 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
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, Ball-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 jetzt. Ja, doch, doch.
Ja, jetzt dann. Ja, ja.
Wie viele Bücher passen in der Garage? Wenn du deine Lagerhaltung,
und das möchtest du halt im gleichen System machen, damit
eben du nicht das Problem kriegst, dass
du den Start-Estate 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
über die du Bücher verkaufst,
wenn das unterschiedliche Systeme sind,
dann musst du den State-Zwischendienstensystem
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
die referenzielle Integrität, Constraints,
über alle Daten hinweg machen kann
und dann von der Datenbank sicherstellen lassen kann schon,
dass bestimmte Sachen nicht gehen
und dass bestimmte Sachen immer erfüllt sein müssen.
Das heißt, unser Schema setzt das dann tatsächlich fest
und das gibt dann sonst direkt einen Fehler aus der Datenbank.
Hey, nur dürfen wir nicht, geht nicht.
Und wir haben das Schema dabei erarbeitet für unseren kleinen Laden
und so sollten wir dann los.
Und dann kann deine 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, nur mache 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.
Du hast minus zwei Bücher und dann
sagt die eine Datenbank, du darfst aber eigentlich nicht.
Dann sagt die eine Datenbank, ja, hab ich aber.
Da kommst du halt in Teufels Küche.
Man könnte sich vorstellen, dass das eine gute Idee wäre.
Wenn man das macht, dann wird man halt relativ schnell feststellen,
das ist keine gute Idee. Das ist doof.
Das ist auch vielleicht ein bisschen unintuitiv.
Und natürlich,
nachher muss man Sachen funktionierender
rausnehmen und man muss dann das
in mehrere Systeme aufkleiden. Man sollte so lange wie möglich
versuchen zu verhindern, dass das passiert, weil
das macht alles viel, viel schwerer.
Ja.
Genau.
Also wo sind wir jetzt eigentlich genau?
Wir sind klein und niedlich. Wir haben
Postgres, machen alles
über Postgres. Wir haben ein bisschen JavaScript
auf der Client-Seite. Ansonsten
nehmen wir, sagen wir mal, Django oder so
als Web-Framework.
Also genau, jetzt kommen wir
erstmal zu, wie machen wir das?
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 ja, das ist halt immer ein bisschen Fremdkörper.
Wenn man jetzt einen Python-Code schreibt,
dann hat man jetzt so ein SQL-Statement.
Das passt von der Syntaxe ja überhaupt nicht in Python rein.
Da muss man einen langen String machen, der irgendwie vernünftig aussieht.
Und da muss dann alles stehen, was man mit der Datenbank reden kann.
Genau, 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 einen Vor- und Nachteil. Das hat den Vorteil, dass man halt
Sachen leicht ändern kann, aber es 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, wo man dann halt gar nicht wirklich mitkriegt, dass das SQL unten drunter ist, sondern man schreibt halt ganz normalen Python-Code.
Man definiert die Daten, die man in der Datenbank stehen haben möchte, einfach nur als Klassen.
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 mappt, 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, nee, irgendwas
foreign-key-field irgendwas, aber man sagt halt,
das ist halt many-to-many-relation
irgendwas, weiß 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 dann 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 Inzides und den ganzen Kladderadatschen,
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 ...
Was ist das?
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.
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 jetzt 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,
braucht man auch irgendeine Art, wie man damit umgeht
und das war teilweise früher ziemlich übel,
als es keine so gute Unterstützung
in den Frameworks für sowas gab, 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, ja, 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 noch nicht passiert.
Also es ist sehr schön, wenn das halt irgendwie
selbst auch in der Datenbank
festgehalten wird, in welchem Zustand man ist.
Ja, und das, jetzt so ein Framework
wie Django bietet einem dafür halt
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 das andere Paradigma,
wie man Web-Anwendungen
in Python entwickelt,
wenn man das mit Flask macht, hat man das
auch alles, ja, da gibt es dann SQL-Alchemy
als ORM
und halt, ich weiß jetzt nicht, das hat
irgendeinen Namen, die Migrationslösung
dafür, an den ich mich jetzt
gerade nicht erinnere. Und da geht
das alles auch. SQL Alchemy ist sogar deutlich
mächtiger als der Django OAM,
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 und 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 PV
und PonyORM oder so, das sind jetzt
modernere Geschichten, sieht besser aus
macht unten drunter irgendwie was
sehr ähnliches, aber ja
genau, also
ein Teil davon ist halt immer, wie man die Relationen
und Tabellen definieren kann, das sind meistens
Klassen, die man dann halt aufschreibt
und dann erzeugt man daraus halt die Datenbankstruktur
und der andere Teil vom ORM ist halt, wie man
Abfragen auf die Datenbank halt abfeuert
und
das, was man eigentlich fast bei
allen ORMs dann so macht, ist
man
macht so Method Chaining.
Ich weiß nicht, sagt dir das was?
Bis jetzt nicht.
Ja, gibt's auch so oft in Data Science
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
ein Objekt zurückgibt, dann kann man auf diesem Objekt
wieder was anderes aufrufen.
Wenn ich das alles in eine Zeile schreibe, wird das irgendwann relativ lang.
Aber wenn ich jetzt ein Statement modellieren
möchte, das halt viele Where-Bedingungen hat,
die Art, in Django-Organs
das hinzuschreiben, wäre halt zu sagen, Filter
irgendeine Spalte
gleich
irgendeinen Wert oder sowas.
Aber dann habe ich noch ein zweites, dann sage ich Punkt, Filter, nächste Spalte
wieder irgendeinen anderen 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 QuerySet.Filter
Punkt
Annotate
und dann Dinge gruppieren
oder so oder neue Spalte hinzufügen
und ich mache
noch eine weitere Klammer drumrum, dann kann ich das halt auch
einrücken und dann rücke ich das so ein, dass
alle Punkte untereinander stehen und dann habe ich halt so
ein mehrzeiliges Dings,
was so ein bisschen eine Zwischenform ist
zwischen SQL und Python-Code.
Ja.
Aber ich spare
mir dadurch sozusagen, dass jedes Mal
irgendeine Zwischenvariable zuweisen zu müssen.
Ansonsten könnte ich ja natürlich sagen
QuerySet gleich QuerySet.Filter irgendwas
und dann sage ich in der nächsten Zeile QuerySet gleich
QuerySet.Filter
noch irgendwie eine andere Spalte.
Where irgendwas.
Ich kann das aber auch alles in ein
einziges Ding reinschreiben.
Man nennt das Method Chaining.
Ja, und das ist halt irgendwie das
bei Pandas ist es halt
genauso. Dann hat man Data Frames, auf denen man dann Sachen macht und
die geben dann auch immer wieder ein Data Frame
zurück, die viele der Methoden. Und die kann man
halt auch so chainen. Und dann hat man da oft so mehrzahlige
Dinge, wo halt die Punkte untereinander stehen. Also wenn man
nicht weiß, was es ist, ist es Message Chaining. Und das ist halt
so eine Methode, um
Dinge halt in eine...
Irgendwie schon mal so ein bisschen gesehen, aber so wirklich wissen, was das
Message Chaining heißt, ist natürlich...
Genau. Und im Grunde
ist es halt dann, wenn man
Queries in ORMs so macht,
ist es halt so ein bisschen 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,
das 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.
Das ist halt 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, die sind wieder klein und niedlich
und das haben wir jetzt gemacht.
Genau, und da würde so ein Framework werden in OEM
Und dann ist man eigentlich, das geht alles ins Git, es gibt Versionskontrolle dafür und das ist eigentlich alles schon relativ komfortabel.
Ja, was passiert jetzt? Also wir sind klein und jetzt haben wir das schon gebaut, aber wann funktioniert das denn nicht mehr so?
Ja, genau. Wir haben als Online-Handel einen riesen Vorteil gegenüber stationärem Buchhandel, weil, das ist auch eine interessante Statistik, es kommt glaube ich aus diesem Buch Longtail von Wired-Redakteuren, weiß ich jetzt den Namen vergessen.
schreibt er da, dass Amazon
macht die Hälfte des Umsatzes
mit Büchern, die nicht in den Top 300.000
sind.
Weil
eben Bücher verkaufen
so ein
oder verkaufen die Bücher halt so
eine Longtail-Verteilung. Also es gibt
halt sehr, Leute
wollen sehr unterschiedliche Bücher kaufen.
Es werden viele Bücher verkauft, aber von
denen nur ganz wenige.
Und das ist halt blöd für einen
Laden, der die Bücher halt physisch
vorhalten muss, weil auch selbst wenn Bücher nicht so groß
sind, ich kann halt in so einem
Innenstadtbuchladen
kann ich halt irgendwie ein paar tausend Bücher haben
und dann ist halt irgendwie Schluss
und ich muss mir überlegen, welche das sind, aber wenn
jetzt, also nehmen wir an
Das hat aber auch ein Zielpublikum, das heißt ich weiß genau, hey
in mir kommen jetzt nur ganz viele alte
antiquarische interessierte Menschen
rein, dann sollte ich vielleicht dafür sorgen,
dass in meinem Laden viele antiquarische Bücher
sind oder es kommen jetzt noch ganz viele hippe Leute
rein, die wollen alle was über IT wissen, sollte ich vielleicht ein IT-Buch laden.
Ja, aber selbst
wenn du jetzt all diese Zielgruppen
zusammennimmst und dann irgendwie den riesigsten
also das ist halt das Problem,
wenn die Zielgruppe zu klein ist, dann lohnt
sich das nicht, aber wenn sie
selbst, wenn du jetzt einen riesigen Buchladen hast, in den
300.000 Bücher passen, was ziemlich groß sein
müsste, dann
machst du immer nur trotzdem noch
die Hälfte des Umsatzes von Amazon, weil
Amazon macht halt nochmal so viel
Umsatz mit dem ganzen Rest. Das heißt, sie haben dann
sie können einfach viel besser skalieren
weil sie einfach viel mehr Bücher verkaufen
und ja, 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 1 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, auch der
stationäre Buchhandel geht ja irgendwie dann damit um
so damit um, dass man dann halt Sachen da bestellt
zum Beispiel, hey Autor, schreib doch bitte
nochmal eine neue Folge, wir haben ja so ein paar
Bestellung, ja.
Aber, ja,
ich meine, du hast halt 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.
Okay, und dann kannst du...
Es ist 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 ist das überhaupt kein Problem. 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.
Wenn es jetzt nur darum geht,
die Bücher zu verkaufen. Aber
wenn wir jetzt
zum Beispiel eben sowas rauskriegen wollen,
wie, was sind eigentlich
die Top 300.000 Bücher?
Wo kommt denn diese Zahl eigentlich her?
Ja, und
überhaupt rauszukriegen, okay, wir machen die Hälfte unseres Umsatzes
mit Büchern, die nicht in den Top 300.000
ziehen, dann müssen
wir nicht nur die Bücher
speichern, sondern dann müssen wir halt auch
speichern zum Beispiel, welche
Bücher gekauft worden sind und so, also
die Historie aller Bestellungen und so.
Und das ist dann halt unter Umständen viel, viel
mehr.
Und dann wird es allmählich
problematisch, weil dann haben wir
unterschiedliche Use Cases
oder unterschiedliche Abfragemuster.
Also wir haben zum Beispiel diese
Transaktions...
Also das Lager, das einfach immer noch weiß, welche Bücher
Wir sind da und das finden wir raus.
Das System, das macht halt Bestellungen
oder wir haben halt Anfragen, die Bestellungen machen
oder solche Sachen wie, zeig mir alle Bücher
in Seefacher Romane oder so.
Aber
diese Art von Anfragen,
wie, sag mir mal, wie viel Umsatz ich mit
den
nicht in Top 300.000 enthaltenen
Bücher im letzten Jahr gemacht habe.
Das ist eine ganz andere Art von Anfrage.
Die Anfragen vorher, die machen immer nur
auf kleinen Datenmengen in der Datenbank irgendwas.
immer zeilenweise meistens.
Und oft ändern sie auch irgendwas oder schreiben irgendwas.
Aber gut, die große Mehrheit wird Read-Anfragen sein.
Aber die beziehen sich normalerweise nicht auf wahnsinnig viele Zeilen,
sondern immer nur relativ wenige oder wenige tausend Zeilen.
Und 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, 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
Abfrage-Muster beißen sich halt massiv.
Also, weil
das Problem ist, dass die Datenbank
irgendwie gewährleisten muss, dass deine Sicht
auf die Welt, also auf die Datenbank,
konsistent bleibt, während die Anfrage läuft.
Die Anfrage läuft jetzt aber wahrscheinlich relativ lang.
muss ich irgendwie alle Daten, die in der Datenbank liegen
oder einen Großteil davon muss sie sich angucken,
wenn sie dir hinterher so was sagen,
eine Zahl geben will, wie viel Umsatz waren das jetzt so.
Und währenddessen werden aber Bestellungen
abgearbeitet oder werden Dinge gemacht, Sachen an der
Datenbank geändert,
die jetzt aber nicht direkt
durchschlagen können auf deine Anfrage, sondern da werden
immer nur Kopien gemacht.
Und es wird dann halt ein Timestamp
reingeschrieben, es wird halt das Multiversion
Concurrency Control.
Multiversen!
Das heißt, die Datenbank
ist halt in einem unterschiedlichen Zustand,
je nachdem, wer gerade fragt.
Und für die Transaktionen, die eine Bestellung ausführen, ist 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
Business Intelligence
Abteilung irgendwie anfängt,
wenn da die Analysten sitzen und dann irgendwie, ja gut,
ich weiß nicht, am Anfang wird man sowas noch nicht haben, aber
irgendwann hat man das vielleicht dann, wenn die halt ihre
Analyse-Querys abschießen,
dann wird plötzlich die Webseite langsam.
Ja, weil halt die Datenbank langsam
wird, weil die Queries werden langsam, weil plötzlich
muss die Datenbank
irgendwie mit mehreren
Zuständen irgendwie
rumjonglieren.
Ja, das ist blöd. Und dann muss man sich halt
was überlegen. Und
das ist dann halt so der Moment,
wo man dann sagen muss, okay,
wir können das nicht mehr. Es wäre schön, alles in einer Datenbank
zu haben, aber das geht nicht. Diese beiden Use Cases
sind so unterschiedlich, dass man das leider
nur dadurch ordentlich abgebildet kriegt,
dass man das halt in unterschiedliche Systeme packt.
Und
ja, also das eine nennt man
auch irgendwie OLP,
Online Transaction Processing,
Das ist halt sozusagen der
Webseite, also Datenbank ist hinter einer Webseite,
die irgendwie Bücher verkauft und prozessiert
Transaktionen, Bestellungen. Und der andere
Teil nennt sich OLAP,
Online Analytical
Processing. Und
ist halt das so, wenn man das mal
gehört hat, wenn Leute über Data Warehousing
sprechen oder Data Warehouses oder so, das ist halt das.
Und
genau, das sind beides
meistens relationale Datenbanken, wenn man
anfängt jedenfalls.
Aber die sehen unterschiedlich aus.
Also die haben unterschiedliche Anfragen werden gestellt.
Analyseanfragen laufen oft länger, gucken sich viele Zeilen an.
Transaktionsanfragen sind oft kurz und gucken sich wenige Zeilen an.
Und da geht es auch darum, dass die Latenz relativ kurz ist.
Bei vielen Analyseanfragen ist es gar nicht so wichtig,
dass sie jetzt eine Minute länger oder weniger lang laufen.
Das ist gar nicht so entscheidend.
Und auch die Analyse-Datenbanken sind oft viel, viel größer,
weil man halt historische Daten mit drin hat,
was halt für eine Transaktionsdatenbank
tödlich wäre, weil bei der ist
möglichst das komplette
Working Set der Datenbank
im Hauptspeicher, damit das halt alles schnell geht,
damit die Latenz
niedrig bleibt, damit halt die Webseite
sich schön snappy
irgendwie anfühlt.
Und bei
den Analyse-Datenbanken ist aber
unter Umständen wichtig, dass ich halt historische Daten
da halt auch mit drin haben kann. Und die
werden dann halt vielleicht so groß, dass man das halt nicht mehr im Hauptspeicher
halten kann.
Ja, aber...
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, wenn
sich eine Query irgendwie ein paar Millionen
oder paar Zehn Millionen Zeilen anguckt, dann ist es eh nicht mehr schnell,
selbst wenn es ein Hauptspeicher ist. Und ob es dann jetzt eine Minute
oder zwei Minuten dauert, das hat dann auch irgendwie wurscht.
Ja, genau.
Und dann hat man eben diese beiden
unterschiedlichen Systeme und dann kriegt man halt aber auch
genau diese Probleme, die man dann hat,
Wenn man mehrere Sichten auf die Welt hat oder einen Status, man hat jetzt keinen gemeinsamen Status mehr, sondern man hat jetzt den Status des Systems in unterschiedlicher Form in unterschiedlichen Datenbanken.
Das heißt, man muss jetzt zum Beispiel die Transaktionen, die irgendwie in dem einen System aufgelaufen sind, überführen in das Analysesystem.
Das macht man üblicherweise bei einem Prozess, der nennt sich ETL, Extract, Transform, Load.
Und man halt die Daten, die einen interessieren, halt täglich oder so, also meistens fängt man sowas an wie, ja, das sind halt dann Jobs, die nachts laufen, wenn halt die Datenbanken sowieso nicht so unterlasst sind, weil nicht so viele Leute einkaufen, liest man halt irgendwie alles, was einen so interessiert, dann aus der Transaktionsdatenbank aus.
dann ist der Transformationsprozess halt sowas wie,
ich muss die Daten in ein anderes Schema transformieren.
Und das ist halt so wie so Stern-Star-Schema
oder Snowflake-Schema, je nachdem.
Das ist auch irgendwie gewisserweise normalisiert
oder man kann auch sagen, denormalisiert, je nachdem.
Aber es ist halt auf jeden Fall anders.
Es ist halt davon optimiert,
dass ich bestimmte Arten von Analysen fahren kann
und lädt das Ganze halt in die Analyse,
Datenbanksystem. Für deine BI.
Genau.
Ja.
Und ja,
das ist halt
immer so ein bisschen fies
alles. Aber ja, bleibt einem halt nichts übrig,
muss man irgendwie machen. Wie würden wir das 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
OLTP-Datenbanksystem,
das haben wir 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
Analytics-Abteilung einstellen. Ja, machen wir auch mit
Postgres so ein Ding.
Also eine zweite Postgres-Datenbank, die eben die erste packen.
Ja, genau. Die halt ein bisschen anders aussieht.
Die hat dann vielleicht nicht ganz so viele Hauptspeicher,
aber dafür halt irgendwie mehr Plattenplatz
und auch irgendwie Storage
möglicherweise in unterschiedlicher Qualität.
Wenn man sagt, okay, vielleicht
für die letzte Woche haben wir alle Daten
noch im Hauptspeicher, ja, dann aber 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
der größte Teil 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, 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, und das ist halt ganz anders im Vergleich zum OLTP-System, wo man halt sagt, das muss alles mehr oder weniger im Hauptspeicher sein.
Und klar ist auch wichtig, 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.
Ja.
Und
genau, diese LTE-Prozesse
sind dann halt irgendwelche Skripte, die dann halt
irgendwie über irgendeine Task
ja
Das bedeutet natürlich dann, dass unser
Intelligent System also jetzt nicht sekundengenau
funktioniert, in dem Fall.
Weil wir halt immer wieder diese Jobs machen müssen.
wenn ich jetzt an was ganz anderes denke,
weiß ich nicht, Aktienkursanalyse oder sowas,
wir haben irgendwelche Portfolios,
dann ist das natürlich dann doof,
weil dann das nicht dem echten Stockmarket entspricht,
sondern man müsste es halt dann jedes Mal
eine neue Kopie machen,
wenn man diese Analytics fahren will.
Ja, genau.
Also natürlich, das ist tatsächlich ein Problem.
Und die Lösung dafür ist,
dass man dann halt irgendwann nicht mehr so ETL
in dem Sinne macht,
dass man das halt irgendwie abends Batch-Processing macht,
sondern dass man halt irgendwie so Streaming
Geschichten verwendet, halt
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
erst dann relevant,
wenn man dann nochmal ein gutes Stück größer
geworden ist und man mit diesen traditionellen
Data-Warehouse-Geschichten auch nicht mehr klarkommt.
Und der Weltbeherrschung ist unikat.
Ja, genau. Dazu muss man dann schon mal
noch ein bisschen, oder halt eine andere Art von Daten sammelt.
Also ich würde sagen,
dieser klassische Bereich,
Ja, selbst wenn man halt nur tagesaktuelle Daten hat, ist man damit wahrscheinlich viel besser aufgestellt als jetzt wahrscheinlich viele stationäre Buchhändler oder so.
Selbst das wird einem da schon einen deutlichen Vorteil verschaffen.
Und ich denke mal, am Anfang ist es halt so, das ist halt das, was alle machen und mit allen irgendwie anfangen, dass sie das halt tagesweise oder so batchmäßig erledigen.
Und genau, ja, da ist man halt irgendwie so bei diesem Data Warehousing Thema.
Ich habe das mal irgendwann
das ist auch in den Shownotes verlinkt,
gibt es einen schönen Essay,
der heißt
Data Warehousing for Cavemen.
Das ist von 1997 oder so.
Aber
das finde ich nach wie vor gut, ist auch relativ
humorvoll. Da geht es darum,
der schreibt
auch so, vielleicht interessiert es manche Leute irgendwie, wie man
300 Dollar die Stunde verdienen kann,
indem man die sensibelsten Daten von irgendwelchen
Firmen massiert. Muss ich sofort wissen, ja.
Genau, beim Freelance ist das vielleicht gar nicht so uninteressant.
Ja, und
also das ist auch ein Feld, das es schon lange gibt.
Ich habe das am Anfang aber auch nicht,
ich habe zuerst nur diesen OTP-Use-Case
gekannt und dann bin ich irgendwann
auf diesen Essay gestoßen und dachte so, oh, das ist aber interessant.
Und daraufhin halt dann auch
so angefangen, mich so ein bisschen mit der Terrarism-Kram zu beschäftigen.
Aber es ist auch ein sehr interessantes Thema.
Der entscheidende Punkt ist im Grunde,
dass man halt solche Abfragen machen
können möchte, wie
also wie unterscheidet sich denn
jetzt, keine Ahnung, das
Volumen der verkauften Bücher in einer bestimmten Kategorie,
nachdem ich irgendeine Werbeaktion gemacht habe.
Oder A-B-Tests.
Ich habe jetzt irgendwie manchen Usern
eine bestimmte...
Die haben halt ein Design gesehen, das ein bisschen anders
aussah oder halt ein bisschen
anders... Oder alle Leute, die letzte Woche gekauft haben
für ein bestimmtes Produkt, die bekommen jetzt
einen besonderen Gutschein, der für
drei Tage gültig ist oder sowas.
Ja, und genau, ich möchte hinterher gucken,
was ist denn dann passiert? War das jetzt erfolgreich oder nicht?
Oder wie erfolgreich war denn das?
Und dafür
muss ich halt
bestimmte Arten von Anfragen,
die ansonsten keine Rolle
spielen können, gut machen können. Und dafür habe ich halt
so eine Struktur. Ich habe eine Faktentabelle
und dann drumherum Dimensionstabellen, in denen halt
solche Sachen drinstehen, wie
das war jetzt ein User, für den ich
diese Version der Webseite angezeigt
habe. Oder das hier,
also man hat zum Beispiel sowas wie,
daran kann man es vielleicht ganz gut
verstehen, Time ist halt eine Dimension.
Und in der Faktentabelle, also Fakten
wären sowas wie Bestellungen.
Ist halt
sozusagen Time nicht etwas
jetzt ein Zeitstempel oder so, der da reingeschrieben
wird, sondern das ist halt eine ID,
ein Fremdschlüssel und der zeigt
halt in eine Timedimension
und das ist halt eine
Dimensionstabelle, in der drinsteht, was diese
Zeit bedeutet und dann stehen da eben
solche Dinge dran wie,
naja, also, auch da wiederum, kann sein,
also, da steht nicht direkt ein
Zeitstempel, sondern da steht dann dran, also, das war ein Werktag.
Das war ein Feiertag
in folgenden Bundesländern.
Das war, keine Ahnung,
das war Sommer.
Sodass ich dann halt solche Abfragen machen kann wie,
wie ist denn der Verkauf der Bücher in dieser Kategorie
im Sommervergleich zum Winter?
Und dadurch, da ich diese Informationen,
das ist jetzt Sommer, halt direkt an dem
Zeitdings dran habe, kann ich halt Abfragen machen,
die sehr effizient alles rausfiltern, was halt
irgendwie Sommer ist und so.
Aber solche Abfragen
machen halt in dem OTP-Teil
oder wenn ich jetzt eine Webseite, machen überhaupt keinen Sinn.
Das heißt, ja, die Schemata
sehen dann halt ganz anders aus.
Ja, genau.
Wenn einen interessiert, wie das wirklich so
funktioniert, finde ich, dieser Data Warehousing
for Caveman-Essay ist ein schöner Start.
Aber da gibt es auch jede Menge.
Da kann man sich durchlesen, wie das so klappt.
Ja,
genau.
Ach so.
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,
dass irgendwie halt unsere Datenbank
halt vielleicht irgendwann ein bisschen langsamer wird,
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.
Die einzige Datenbank,
für die ich das wirklich mal gemacht habe,
ist eigentlich MySQL.
Ich verwende heutzutage eher Postgres,
aber da habe ich dann auch mal
so einen MySQL-Performance-Optimierungskurs besucht.
und das
schöne Zitat, also Chris Künthopp hat
den damals irgendwo in München
durchgeführt,
damals hat er bei MySQL gearbeitet
und
ein Satz,
der mir in Erinnerung geblieben ist, der meinte so, ja,
wenn man Datenbank-Performance
optimieren will, ja, so OLTP,
dann gibt es da eigentlich
so im Wesentlichen drei Sachen, die man tun
kann, um eine Datenbank schnell zu machen.
Das Erste, was man eigentlich immer machen kann,
das funktioniert auch fast immer,
das ist super, man kann einfach mal ein bisschen
mehr Hauptspeicher reinstecken in die Datenbank.
Das ist schon mal auf jeden Fall schneller, das ist immer
gut.
Wenn das irgendwie nicht mehr so richtig reicht,
eine zweite Geschichte, die man auch immer tun kann, auch
sehr gut hilft, ist, man kann einfach
noch ein bisschen mehr Speicher reinstecken in die Datenbank.
Und das hilft eigentlich fast auch
mit der dritten Geschichte,
selbst wenn man an eine Grenze gekommen ist,
die dann auch eher so
das letzte Mittel, zu dem man greifen kann,
wenn das auch nicht hilft, ist halt, man könnte einfach
ein bisschen mehr Hauptspeicher in die Datenbank reinsteigen.
Okay, okay.
Wie viel Hauptspeicher hat denn dann so eine große Datenbank?
Ja, so viel, wie halt geht
eigentlich. Also es kommt 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 einer beliebigen,
mit einem Raspberry Pi kannst du das machen, das ist wurscht.
Aber wenn du
jetzt, also sagen wir mal so,
wenn ein Working Set der Datenbank,
also die Menge der Daten, die halt auf der
Platte liegen, wenn die Datenbank runtergefahren ist,
wenn das halt 30 Gigabyte
hat, dann sollte deine Datenbank
mindestens mal 30 Gigabyte haben, eher so
64 vielleicht. Hauptspeicher.
Weil es gibt halt auch noch diverse
Strukturen, die im Hauptspeicher gehalten werden,
die man halt auch braucht.
Ja.
Und dann ist halt das Limit eigentlich nur
und sagen wir mal so, das ist halt viel.
Also wenn man jetzt irgendwie, nehmen wir an,
Wir haben das, was heute so ein Sweet-Spot ist,
sind es halt vielleicht 256 Gigabyte oder so.
Hauptspeicher, da geht eine ganze Menge rein.
Also es ist halt für mich schwer vorstellbar,
welche Systeme, die Transaction-Processing machen,
denn mehr Hauptspeicher benötigen.
Oder mehr Daten haben,
die sie jetzt unbedingt im Hauptspeicher halten müssen.
Das gibt es kaum.
Also, ja gut, es gibt schon.
Also wenn man jetzt an sowas denkt wie Google,
man indiziert das Web und möchte halt
so eine Echtzeit Suchabfragen über alle Webseiten
machen, das geht nicht mehr, das ist klar.
Aber
so viele...
Also so groß muss man erstmal werden.
Also Amazon fällt da bestimmt auch nicht rein.
Also Amazon hat
also, 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. Also die haben dann halt
ein anderes Problem. Amazon wird das Problem bekommen, dass sie halt mit der
Schreiblast nicht mehr klarkommen, aber
also das könntest du alles
irgendwie in den Hauptspeicher
von so einer Datenbank packen.
Also ich würde sagen, für die, für 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.
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 Hauptspeicherbandbreite hat man da ja nicht
und das wird dann irgendwann,
man muss ja die ganzen Prozessoren auch irgendwie mit
Daten versorgen und wenn man jetzt da
irgendwie, weiß ich nicht.
Da fährt dann kein Bus hin.
32 Prozessoren oder 64 oder sowas.
So irgendwann ist dann halt, also der
Sweetspot ist, würde ich sagen, heute eher so
bei, weiß ich nicht, irgendwie 64 Prozessoren oder so
und 256 GB Hauptspeicher und so.
Aber das, also egal, also vielleicht
geht auch noch ein Terabyte, ich hab keine Ahnung.
Für die meisten, aller, aller, aller
meisten Anfä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 GB
hattest, nimm nicht eine Datenbank,
die jetzt 8 GB 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 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 Harddisks
und Hauptsprecher, da war der
Unterschied
so
1 zu 10.000 oder so
Geschwindigkeitsunterschied.
Das ist jetzt nicht mehr ganz so schlimm,
wenn man SSDs hat,
aber es ist immer noch ziemlich schlimm.
Also es ist immer noch ein Riesenunterschied.
Und daher, ja,
das will eigentlich, dass die heißen Daten
im Hauptspeicher sind.
Ja, genau.
Das ist halt ein Ansatz, um das zu optimieren.
Dann hat man oft das Problem, man hat halt so eine Asymmetrie
zwischen Lese- und Schreibquerys.
Und selbst wenn man mit so einer Datenbank halt
irgendwie ein paar tausend Querys 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 zweimal 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
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
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 der Slave denn aktualisiert auf den Master?
Ja, da gibt es dann Mechanismen für, dass
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
der 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 Lag 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 casht 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 es auch so oft
so, es ist halt wurscht, also so oft
ändern sich Dinge halt nicht, wenn irgendwo ein Count 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ß, okay, jetzt gibt es hier gleich
eine Transaktion oder so und dann macht man
auch die Leseanfragen auf den Master, damit man
eben nicht das Problem hat, dass man eventuell
Daten sieht, die eine Minute alt sind.
Aber da das die allermeisten Anfragen
ja gar nicht sind, sondern die
meisten Navigationsanfragen, wenn ich jetzt in Kategorien
rumklicke oder irgendwelche Filter
auswähle oder nach irgendwas suche oder so,
diese ganzen Anfragen beziehen sich auf Daten,
die sich jetzt gar nicht so häufig ändern. Das kann
alles auch eine Minute alt sein, das ist wurscht.
Und erst wenn ich halt
eine Bestellung mache, dann
muss ich halt zusehen, dass ich
aktuelle Daten sehe, wie zum Beispiel
ist das Buch noch auf Lager oder so.
Und diese wenigen
Anfragen, die halt dann
aktuell sein sollten,
die gehen dann direkt an den Master. Und das kann man halt im Code
sagen. Man kann halt sagen, okay, an dieser
Stelle bitte eine Verbindung auf den Master und nicht
auf den Slave.
Und die Schreibanfragen müssen dann halt
auf den Master gehen, weil man ja nur
an einer Stelle schreiben will.
Und mit dieser Architektur kommt man relativ
weit. Also das ist
eine Geschichte, das ist auch so
klassischer Lampstack-Architektur, Wikipedia-Seite
so aufgebaut.
Du hast jetzt gerade noch zwei Sachen gesagt, die vielleicht noch mal kurz
von Redis einmal eben gesprochen und
gerade von 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
es ist ein bisschen, 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
LAMP-Stack, LAMP ist einfach Linux, Apache,
MySQL, PHP
und einige
der größten Webseiten, die das halt
benutzt haben
oder weiß nicht, ob sie das noch benutzen, keine Ahnung,
ist halt Wikipedia.
Wir haben auch immer schöne Artikel darüber gehabt,
wie sie ihre Systeme aufbauen.
Also ist ja auch Wikipedia eine der,
ich glaube, die sind auch mit Sicherheit immer noch
in den Top 10 der weltweit trafficstärksten Seiten
und haben halt auch viel dazu veröffentlicht,
wie ihre Architektur aussieht.
Und die haben halt auch genau das,
die meisten Sachen sind Leseanfragen,
aber manchmal wird halt auch was geändert oder geschrieben
und die machen das halt mit MySQL und vielen Slaves
und extensiver Verwendung von Memcached,
zum Cachen von irgendwelchen geretteten 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 drauf an, wenn man
eben PHP mag.
Kann man das auch
immer noch machen, wobei ich jetzt nicht genau weiß, ob das
alles immer noch so populär ist. Wemcached.de, glaube ich, ist
so ein bisschen auf dem Weg nach draußen.
Wahrscheinlich würde auch in dem Umfeld eher
heutzutage Redis verwendet.
Aber jetzt im Python-Umfeld würde ich sagen, ja, da ist halt, hat man so grob die Wahl zwischen, also es gibt natürlich noch viel mehr und es gibt natürlich auch gute Gründe, andere Sachen zu verwenden, aber so die populärsten Geschichten sind halt Django und Flask.
Und eben als In-Memory-Cache ist bei beiden eigentlich jedes sozusagen das, was verwendet wird. Datenbank, eigentlich würde ich auch sagen Postgres wird bei beiden verwendet. Man kann auch was anderes nehmen natürlich. Es gibt auch Leute, die Django mit MongoDB verwenden. Das geht. Es gibt auch sogar valide Use Cases dafür. Es gibt auch Leute, die Flask irgendwie mit, weiß ich nicht, CouchDB, mit allen möglichen Dingen verheiraten.
Aber so als
womit ich anfangen würde, ist auf jeden Fall Postgres
und dann halt eben SQL Alchemy
beziehungsweise Django OAM.
Und Redis, genau,
als Memory Cache und
ja, wahrscheinlich braucht man auch noch ein
Message-Queue-System.
Ist aber dann auch schon, also dann gibt's noch
so ein paar Sachen, die man braucht.
Was ist denn die Message-Queue vielleicht?
Also man hat oft so Dinge, wo man dem User
möglicherweise etwas direkt
direkt eine Antwort geben will,
aber es ist halt ein Job, der dann irgendwie
länger dauert.
In unserem Buchstore wäre das was?
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.
Was könnte der denn tun?
Ja, zum Beispiel
du verfasst einen Kommentar jetzt
oder eine Bewertung für irgendeinen Artikel
und du möchtest,
wenn der jetzt auf Abschicken drückt,
der User, dass er sofort seinen Kommentar
unter dem Artikel sieht.
Aber
in Wirklichkeit
willst du den ja vielleicht noch prüfen.
Also wenn das jetzt irgendwas Populäres ist.
Sag mal so, du...
Oh, danke.
Wahrscheinlich bräuchte ich
bevor oder sowas eine Räuspertaste, oder?
Das könnte jetzt hässlich geworden sein.
Das tut mir leid, da muss ich mich entschuldigen.
ein bisschen erkältet.
Ja,
wenn,
also eigentlich möchte man halt, wenn jetzt zum Beispiel ein Artikel
ist, der häufig verkauft wird, ja, und dann jemand
schreibt irgendwie, dieser Artikel ist voll scheiße
und keine Ahnung,
das hat ja dann unter Umständen direkt
Konsequenzen, oder es
macht dann am besten noch irgendwie ein Mitbewerber,
macht irgendwas Fieses, irgendwie,
ja, dann will man das möglicherweise nicht,
dass das sofort allen sichtbar wird, sondern man muss
irgendwie erst
eine Redaktion draufgucken oder so,
aber das ist halt nicht
etwas, was man dem User anzeigen möchte.
Man hat dann halt sozusagen etwas,
zwei Prozesse, die voneinander so ein bisschen entkoppelt
sind. Der User drückt auf Speichern, sieht
seinen Kommentar oder seine Bewertung und
im Hintergrund gehen aber dann noch
so Tasks los wie, oh, das ist hier
an der Stelle, wo jemand mal draufgucken sollte,
aber das geht dann auch nicht in Echtzeit,
sondern das wird dann halt irgendwie in so eine
Queue, in eine Warteschlange eingereiht.
dann gibt es eine Redaktion, die hat dann halt diese Jobs,
muss sich halt irgendwelche Kommentare an sensitiven Stellen
oder so angucken und die dann abarbeiten.
Aber das ist
halt sozusagen der, dass
diesen Job in die Warteschlange
tun und dieser
Prozess mit menschlicher Interaktion,
das ist jetzt nicht mehr Teil von dem Web-Request.
Das heißt, der
Teil muss irgendwie entkoppelt sein.
Das heißt, der Web-Request ist ja irgendwie vorbei.
Aber dieser Web-Request
löst dann halt irgendwie,
schreibt dann halt irgendwie diesen Job
in die Queue, genau. Solche Sachen hat man
oft, auch wenn sich auch
genau, das ist ein gutes Beispiel,
das ist mir jetzt eingefallen.
Vielleicht möchtest du, dass
wenn du jetzt in der Suche 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 deiner
Bewertung muss indiziert werden von der Suchmaschine.
Aber das geht halt auch nicht
in Echtzeit, sondern das macht die halt vielleicht nur alle
tausend Bewertungen oder so, wird neu indiziert oder so,
weil, ja.
Und dann wird halt auch so ein Task erzeugt für,
das hier muss ja noch mitindiziert werden,
aber es wird nicht sofort indiziert,
weil das ist halt etwas, was eine Operation lange dauern kann
und man möchte ja nicht, dass der Web-Request dann so lange dauert,
wie die Operation dauert, sondern man sagt,
okay, man gibt dem Web-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-Queues,
die halt ein komplexeres Web-System hat,
dann braucht man sowas halt, weil solche Fälle
halt immer wieder auftreten.
Ja, kann man aber Redis auch
für verwenden, also was für
Django ist halt, was häufig verwendet ist, Celery
kann ich nicht unbedingt empfehlen, ist irgendwie
eher schmerzhaft.
Ja, die
drunter liegenden Geschichten sind oft sowas wie
RabbitMQ oder so, im Allgemeinen
ist das Protokoll wie AMQ
irgendwas, weiß nicht genau.
Ja, aber das ist nochmal ein ganz eigenes
Feld mit diesen ganzen Message-Queues.
Ja, genau. Master-Slaves-Architektur hatten wir jetzt. Irgendwann kann natürlich auch sein, dass das nicht mehr reicht und dann müssen wir halt irgendwie die Datenbank auftrennen.
Also wenn zum Beispiel gerade die Schreiblast groß genug geworden ist, dann geht das halt alles nicht mehr und dann kann man halt, die Datenbank muss man dann auftrennen, das ist furchtbar, weil dann verliert man eine ganze Menge der Vorteile, die man halt hat, wenn man eine Datenbank hat, eben referenzielle Integrität, irgendwie, dass Transaktionen isoliert sind, diese ganzen Geschichten, das geht alles nicht mehr so wirklich und das muss man dann alles in der Applikation machen, in der Applikationslogik und das macht alles Dinge unfassbar viel komplizierter, deswegen sollte man das möglichst nicht tun.
Also wenn man ihn mal verkauft, irgendwie.
Er wird nicht so groß werden.
Und das System ist super, weil das schadet automatisch oder sowas.
Das ist nicht etwas, was man haben will.
Also wenn man klein genug ist, dass man das nicht braucht, sollte man das nicht machen,
weil das bedeutet halt, dass man diese ganzen Dinge, die einem sonst die Datenbank quasi schenkt,
selber machen muss in den Applikationscode.
Und das ist halt sehr, sehr schwierig.
Aber manchmal geht es halt leider nicht anders.
Dann gibt es halt zwei Möglichkeiten.
Man schadet irgendwie horizontal.
Also man sollte so lange, man nennt es Upscaling.
solange wie möglich die Maschine größer
machen und mehr Hauptspeicher reinstecken.
Wenn das halt dann irgendwann tatsächlich nicht mehr geht,
dann muss man halt entweder
horizontal oder vertikal
schaden und das halt
aufteilen. Das heißt, horizontal
Mehrere Maschinen,
die die gleiche Datenbank benutzen?
Nee, die gleiche
Datenbank würde einem ja nicht helfen, wenn es zu viel
da muss die
Datenbank halt irgendwo trennen.
Und die Frage ist, wo trennt man jetzt auf?
Man kann halt entweder innerhalb von
Tabellen die Zeilen auseinander trennen.
Das wäre eben horizontal skalierend.
Okay, alle Bücher, die mit Buchstaben A anfangen,
kommen jetzt auf die Datenbank. Alle Bücher mit Buchstaben
B bis F kommen auf die Datenbank.
Oder so regional Queries trennen.
Von wo kommt die denn jetzt oder sowas?
Ja, regional kann man natürlich auch trennen.
Das ist dann nochmal eine andere
Geschichte. Könnte man auch machen.
Das heißt aber, das wäre quasi horizontales
Schaden auf den Usern.
Nach Region eben.
das wird, also meistens
würde man auf Usern schaden, irgendwie
tatsächlich, ja. Man sagt,
was ist das für ein User? Und dann
entweder regional oder halt
irgendwie
sonst irgendein Hash-Wert oder so.
Und vertikal wäre halt,
man trennt
nach Tabellen auf. Das heißt, man sagt,
okay, wir haben hier ein System, das kümmert sich um die Bücher.
Wir haben hier ein System, das kümmert sich um die User.
Wir haben ein System, das kümmert sich um Lagerhaltung.
Das wäre halt, man teilt dann
nicht quasi in den Zeilen,
sondern man teilt halt an den Tabellengrenzen.
Ja, macht natürlich so vollständig
Abfragen dann ein bisschen langsamer, oder?
Ja, das Problem ist dann halt, dass man mehrere
Systeme fragen muss, wenn man jetzt irgendwie
was machen, also wenn man jetzt die Amazon-Seite
anzeigen möchte, dann
muss man halt unter Umständen viele Systeme
fragen. Tatsächlich
ist es etwas, was Amazon wirklich
passiert ist, irgendwie, ich glaube 2008, 2009
gab es dann auch irgendwie, haben sie
Artikel darüber geschrieben,
damals nannte sich das nicht, also heute läuft das Ganze
unter dem Stichwort irgendwie
Microservices oder so, so nennt man das dann, dass man halt
Teile eines
Systems in kleinere
Services auslagert.
Damals
nannte sich das anders, war aber quasi
eine gleiche Idee, nannte sich
Service-Oriented Architecture.
Und Amazon
hatte das Problem, dass sie auf der Hauptseite,
also wenn du einfach nur Amazon.com
eingegeben hast, dann
wurde dir halt das Ding, 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,
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
die Seite anguckst.
Oder ein paar hundert, ja.
Da das
irgendwie,
da die irgendwie nur sequentiell ausgeführt
wurden, macht das halt die Latenz hoch, weil
ja, synchron
sequentiell, das heißt, die ganzen
Latenzen addieren sich auf.
Das heißt, allein bis die ganzen
SQL-Statements abgearbeitet sind,
vergehen ein paar hundert Millisekunden,
die du einfach warten musst. Und das ist halt
scheiße. Man weiß ungefähr so,
pro hundert Millisekunden droppt dein
Conversion 10% oder so.
Ich weiß nicht, wahrscheinlich weniger, aber
ist halt nicht so gut.
Das heißt, du kannst ja ausrechnen, wie viel mehr Umsatz
du machen würdest, wenn du das irgendwie schneller ausliefern
könntest.
Ja, und dann haben sie sich halt gesagt,
okay, das müssen wir irgendwie anders machen.
Dann haben sie das halt in Services aufgeteilt.
Dann haben sie gesagt, okay, wir haben hier den Recommendation Service,
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, keine Ahnung,
Basket-Service für deine
Einkaufskorb oder so
und da ist halt, das Ding
holt sich halt, was für Dinge liegen da momentan
gerade drin und ja.
Genau.
Und das
haben die damals so gemacht.
Ja und dann, das geht dann natürlich alles
irgendwie mehr oder weniger, auch nicht so total parallel,
aber mehr paralleler als vorher
und dann kann die Webseite insgesamt deutlich
schneller sein.
Ja, genau. Heute
würde man sagen, Microservices, du hast halt ein
Microservice pro irgendwie Ding,
was du irgendwie da machst auf der Webseite.
Und die
komplette Seite aggregiert nur noch
irgendwie die Daten aus all diesen Services.
Ja,
damit kriegt man das tatsächlich in den Griff, wenn man
so ein riesiges Ding hat und viele unterschiedliche Sachen und das
nicht mehr in einer Datenbank passt, dann kann man das so machen.
Es ist aber nicht so, dass man das machen sollte.
Solange man das anders machen kann,
solange man das mit einer Datenbank hinkriegt,
sollte man das mit einer Datenbank machen, weil das ist viel
viel angenehmer.
Also Microservices sind halt
Man schiebt dann halt einen Haufen der Komplexität in eine andere Richtung.
Man hat dann plötzlich Architekturkomplexität,
man hat plötzlich im Ops-Teil von DevOps wird es plötzlich viel schwieriger,
man muss halt das alles irgendwie maintainen.
Man muss halt plötzlich, wenn man jetzt sagt,
okay, ich update jetzt diesen Service,
dann hängen da halt andere Dinge von ab unter Umständen.
dann habe ich halt,
ich kann, ja,
wenn man das halt irgendwie so schön hat,
Master-Slave-Architektur, Loadbalancer davor,
vor den Datenbanken, ein paar Frontends,
dann, selbst da ist es schon kompliziert,
wenn ich jetzt irgendwie
zum Beispiel ein Schema ändern möchte oder so,
was ich im Produktivbetrieb dann vielleicht nicht mehr tun kann,
weil die Datenbank viel zu langsam liefe,
weil wenn ich das Schema ändere, muss ich
bei den Tabellen, die ich ändere,
halt unter Umständen eine Kopie der Tabellen mehr oder weniger mache,
das heißt, ich muss halt möglicherweise doppelt so viel
Daten im Hauptspeicher halten, was halt vielleicht nicht geht.
das heißt, ich muss vielleicht sowas machen wie
ich tausche die Datenbank aus, ich mache eine Kopie der Datenbank
und die Datenbank mit dem neuen Schema
stelle ich dann ins neuen Master rein
und so, so oft hat man dann so Sachen wie
oder wenn man die Software updatet, man nimmt
halt Sachen
Rechner aus der Verteilung
im Loadbalancer, updatet den
oder die Hälfte davon
und die andere Hälfte läuft noch
auf der alten Software und dann schaltet man halt
um oder so, solche Sachen kann man machen
und das geht noch, das ist auch dann schon
kompliziert, weil man muss sich dann halt Gedanken
machen, wie man das tut
und man muss halt irgendein System haben, das das
unterstützt, dass man das automatisch machen kann, sodass man halt
nicht jedes Mal, wenn man
irgendwie sowas wie eine Schemaänderung macht oder wenn man
halt irgendwie eine
komplexere Änderung im Applikationscode
in den Frontends hat, dass man da halt dann irgendwie
jemand setzen muss und das dann von Hand macht, das sollte nicht so sein,
sondern man sollte halt auf den Knopf drücken und sagen, okay,
jetzt 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 hat man viel komplexere Abhängigkeiten
zwischen den Geschichten und dann wird dieses ganze
Ops-Thema halt richtig
ätzend. Auch
Skalierung wird richtig ätzend, weil
dann willst du halt, wenn du halt
in so einer klassischen Architektur hast du nur
wenige unterschiedliche Arten von
Maschinen, die halt irgendwas machen. Du hast halt Datenbanken,
du hast halt irgendwie Redis oder sowas,
du hast halt Frontends,
vielleicht auch vorne irgendwie
Web-Server, die SSL
Terminierung machen oder so, aber
das war es im Grunde. Also du hast nicht so wahnsinnig viele unterschiedliche
Dinge. Beim Microservice hast du halt
vielleicht hunderte unterschiedlicher
Arten von Microservices, die du unterschiedlich skalieren musst,
wo du auf unterschiedliche Sachen aufpassen musst. Das ist alles
furchtbar. Also geht. Also man
kriegt damit halt Sachen in den Griff, die
dann halt, wenn man mit
diesem Muster, man hat halt eine Datenbank, in der
die Wahrheit drin steht, nicht mehr, wenn das
nicht mehr ausreicht, kann man das dann halt so
in den Griff kriegen, aber es ist halt dann schon schlimm.
Ja, genau.
Okay, sind wir schon ganz schön groß,
das heißt, wir müssen noch ziemlich viel beachtet haben.
Genau, oh, das habe ich, ja, was haben wir denn?
Ja, vertikalisch noch.
Ich gucke gerade in die Liste, was wir schon alles haben und was noch nicht.
Genau.
Das ist nämlich tatsächlich relativ viel.
Ja, ja, ja, ja.
Oh mein Gott, ich weiß nicht, wie lange sind wir denn schon dran?
Ich glaube, wir sind über zwei Stunden schon, oder?
Oh nein.
Nein, noch nicht ganz.
Na gut, dann ist es harmlos.
Achso, genau.
Was ich hier noch an einem Punkt war, es können auch
im Analyse-System auch Sachen wieder zurücklaufen.
Zum Beispiel gibt es halt diverse Sachen,
die gelockt werden, die dann aber trotzdem für die Transaktionen
wieder eine Rolle spielen.
Wie so etwas, das hatten wir noch gar nicht.
Auch die Suche. Am Anfang
braucht man ja auf jeden Fall, wenn man so eine E-Commerce-Seite
hat, irgendwie eine Suchmaschine, wo man
nach Büchern suchen kann oder so.
Das geht
auch tatsächlich mit Postgres direkt voll gut.
Hat integriert
integrierten Volltext-Index.
Yay!
Und man möchte halt auch so eine Facette
Navigation, nennt man das, haben, wo man,
wenn man jetzt nach irgendwas gesucht hat,
hat halt eine Ergebnisliste, dann möchte man
einschränken nach Kategorien oder nach, weiß ich jetzt,
wenn es nicht um Bücher geht, sondern um
Elektronik oder so, kann man vielleicht noch
Hauptspeicher oder
Videorekorder, genau,
VHS oder Betamax, ja,
das möchte man vielleicht auswählen können.
Und,
genau, das geht
Postgres alles sehr schön. Auch da
kann man
irgendwie die Counts für die Facetten ganz gut
rauskriegen. Ansonsten, wenn man das halt über eine eigene
Spezial-Datenbank, sowas wie
Elasticsearch macht oder
beides Lucene-basiert oder
Solr oder so macht, dann hat man das Problem,
da hat man auch wieder dieses, wie bei ETL, das Synchronisationsproblem.
Du hast halt, wenn sich an der Datenbank was ändert, müssen
die Änderungen in den Index rein.
Da hast du eine Latenz dazwischen.
Wenn du Sachen aus dem Index rausholst,
du hast jetzt eine Volltext-Suchanfrage,
du kriegst jetzt IDs aus der
Suchmaschine, dann
möchtest du aber vielleicht nach was filtern, was nur in der Datenbank
drin steht, dann musst du nochmal auf die Datenbank
da alle Daten rausziehen
und dann nochmal Counts anders ausrechnen.
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
diverse Sachen vom Datenbank-Ware
und dann kommt halt ID in und dann
kommen tausend IDs und so.
das ist alles kompliziert. Wenn das halt
ein Statement ist, was du halt abfeuerst,
oder halt vielleicht eins für
die Daten selber und eins für die Counts oder so,
dann ist das halt
deutlich, ist alles irgendwie viel
einfacher. Und mit Postgres kriegt
man auch das am Anfang alles hin.
Und ja, das ist eigentlich
sehr nett. Irgendwann geht
das aber wahrscheinlich dann halt eben auch nicht mehr. Dann muss man halt
nach und nach Funktionen in Spezial
Services halt auslagern.
Einer der ersten, den man wahrscheinlich auslagern wird, ist
halt Volltext suchen möglicherweise. Das macht
dann halt irgendwann ein Listing Search oder
Solar oder so.
Aber halt auch
eben sowas wie, wenn man
jetzt anfängt, eine Query
zu schreiben, dann kann man
eben Google Suggest, hatte ich eben schon erwähnt,
kriegt man halt so Vorschläge.
Das ist im Grunde,
man macht dann halt, man sucht auf
den Queries
von anderen Leuten. Aber dann hat man halt
genau das Problem, dass halt
sozusagen die History der Queries
es muss halt irgendwie aus dem Analyse-Ding wieder zurück
ins OLTP-System oder in irgendeinen anderen
Service, 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, raussuchen.
Wie man die schneller tippen kann,
drei, vier, fünf, ja.
Man kann das am Anfang auch alles über Postgres machen,
wenn es dann halt komplizierter wird, muss man das in eigene Services
auslagern und so weiter.
Dann wird das System größer und schwieriger
und ja.
Genau. Und
ja, und immer die Datenbanken,
die man nimmt, werden halt immer spezialisiert.
Also das würde ich auch empfehlen. Also man fängt halt mit Postgres an,
macht mit Postgres einfach alles.
Und wenn man dann halt irgendwann an Grenzen stößt, dann muss man
halt, ja,
wo du dir übel, dann Sachen in
halt Spezialdatenbanken auslagern. Wo du?
Und ja,
bezahlt dann halt
mit Komplexität.
Genau.
Ja, jetzt müssen wir nochmal
gucken, wie wir das weitermachen. Genau.
Wir nehmen Redes zum Cachen einfach
von langlaufenden
Queries und von irgendwie gerenderten Fragmenten,
die halt aufwendig zu rendern sind, also
irgendwelche Listen von Dingen oder so, die
sich aber jetzt nicht dauernd
ändern.
Und
genau.
Jetzt werden unsere Daten immer größer.
Ja, die Daten werden noch immer größer
und das Problem ist auch, wir sind mittlerweile weltweit unterwegs.
Wir verkaufen nicht nur
Bücher, wir verkaufen
alles von A bis Z
wie Amazon. Ich weiß nicht, ob ihr das schon gesehen habt,
es gibt diesen Pfeil von A bis zum Z
von Amazon.
Und
ja, dann stellt sich
ja die Frage, wenn wir das global machen, wo stellen wir dann den Master
eigentlich hin? Das ist halt auch schwierig.
Ja.
Wo wird der entstehen? Also in einem sicheren Land?
Ja.
Wir müssen an alle Stellen
irgendwie so einen kleinen Master stellen, wo halt viel
Traffic ist. Kann man den Master mürren,
dass man ja tatsächlich sagt, dass überall derselbe...
Ja, es gibt natürlich auch irgendwie für diese
Geschichten so Lösungen, dass man halt, dass die Master sich
miteinander synchronisieren, das gibt es für Postgres auch,
aber das ist alles irgendwie, ich weiß nicht so genau.
Alles nicht so richtig.
Das funktioniert alles nicht so richtig.
Und ja, es gibt auf jeden Fall
keine nette...
Es ist halt auch ein mehr oder weniger unlösbares Problem.
Also das ist auch theoretisch quasi
nicht wirklich in den Griff zu kriegen.
Man kann aber Dinge tun,
indem man halt auf andere Architekturen umstellt.
Man kann halt
ja, also
ich habe jetzt mal hier als Beispiel genommen
diese, du willst halt, dass manche
Sachen immer funktionieren.
Ja, eigentlich sollte immer
alle möglichen Sachen funktionieren.
Und manchmal ist dir dann halt irgendwie die Konsistenz
und so egal. Also
zum Beispiel für Amazon super wichtig
ist halt der Einkaufswagen. Du musst halt immer
weiter, das Spice muss fließen.
Du musst immer weiter einkaufen können.
Auch wenn jetzt, daher haben sie das
halt, ich glaube das war auch, also das
Amazon Dynamo basiert
auf einem System, das sie für sich selbst gebaut
haben, eben für genau diesen
Shopping Basket und
der halt genau darauf ausgelegt ist, dass dieses Ding halt
einfach immer funktioniert. Und das ist mehr
oder weniger einfach nur so ein total simpler Key-Value-Store
und
du lebst halt dann damit, dass das
nicht konsistent ist. Oder dass halt
wenn du was kaufst,
das halt vielleicht nicht mehr im Lager ist. Das kann dann durchaus
passieren, weil dieses Ding ist halt ein eigener Service, das
hat keine Verbindung zu einer
zentral, 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, fällt bei Amazon
auf, geht nicht. Wir haben
jetzt zwar, hat jemand was bestellt, wir haben
die Bestellung zugesagt, du hast eine Bestätigungsmail
bekommen irgendwie und jetzt fällt aber auf
so, im Lager ist das nicht mehr drin.
Wir können es dir nicht schicken.
Was macht Amazon dann?
Entweder nachordern von irgendeinem Service,
wie wir eben das Problem hatten, oder die sagen dann irgendwann
so, wir schicken dir
einen Gutschein raus,
gibt es nicht.
Entschuldigungsmail 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
Rendit-Drucker anschmeißen, wird schnell nachproduziert.
Ja.
Ja, genau.
Das ist halt das auch, was dann halt
gebrochen wird, in relationalen
Antenmanagements oft Acid.
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. Konsistenz,
die heißt halt,
dass
die ganzen Foreign Key, also es ist 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
hast du halt teilweise eben keine
direkten Verbindungen, sondern du hast halt bloß
VR-Pies dazwischen.
Isolation ist halt
die Geschichte, dass du
nicht Sachen,
die andere Transaktionen machen, in deinen Daten
siehst, also das halt, man nennt das Dirty Read,
wenn du halt
in deiner Transaktion Dinge aus anderen
Transaktionen siehst, die noch nicht abgeschlossen sind,
sodass du halt, dass du immer,
dass deine Sicht auf die Datenbank komplett
isoliert ist von den anderen. Es gibt unterschiedliche Isolationslevel,
Postgres hat
per Default den höchsten,
glaube ich,
Serializable ist der höchste, dann gibt es noch Repeatable Read,
Und repeatable read war es, glaube ich, lange.
Aber mittlerweile ist es serializable.
Da 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 schiefgehen 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 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 Write-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-Queries macht oder bestimmte Arten von Queries, bei denen es völlig egal ist, ob die super isoliert sind oder nicht,
dann kannst du sagen, wenn dieser User, also dieser User hat halt ein viel niedrigeres Isolationslevel, der macht dann halt Dirt Reads, aber das ist halt egal für dessen Anwendungsfall. So kann man Sachen deutlich beschleunigen. Dann, was man auch machen kann, das sollte man halt jetzt nicht tun, wenn man Bestellungstransaktionen prozessiert, aber zum Beispiel, wenn man testet.
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-Cycle
irgendwie kaputt
macht, wenn man dann halt irgendwie 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, jetzt wenn man jetzt ein Django-Projekt
hat, auch die echte 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's
auf die Datenbank und dann geht's schief.
Nicht so gut. Aber was man
tatsächlich machen kann, ist
Postgres zu sagen, ja, irgendwie nicht F-Synchen.
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.
Ja, 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 sich sowieso
nach jedem Testlauf wieder weg quasi.
Also, ja, aber
für die echte Produktionsdatenbank, die muss
halt bei Transaktionen tatsächlich dafür sorgen,
dass das nicht mehr verschwinden kann und das heißt,
sie muss Epsilon aufrufen und dann, ja, ist das
halt einfach langsam, da kann man auch nichts machen.
Okay, einmal ein bisschen Acid.
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
Paradigmen, 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...
mehrere Datenbanken schreiben kann.
Ja, wir sind jetzt ziemlich groß geworden, oder?
Ja, genau, wir sind jetzt ziemlich groß
und was wir jetzt haben, wenn wir auf mehrere Sachen
schreiben wollen, ist halt, genau,
das Asset ist halt weg, Pech gehabt.
Nein, wir haben noch ein anderes Ding,
das ist dann noch das Cap Theorem Consistency Availability
und Partition Tolerance,
das ist halt auch diese, 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.
Partition was? Partition Tolerance.
Also was ist, wenn Netzwerkverbindungen
zwischen zwei deiner Datenbank-Dinger
irgendwie wegfällt oder so?
Das musst du halt leider,
das ist halt mandatory
sozusagen.
Das heißt, du kannst nur noch zwischen
Consistency und Availability
halt irgendwie wählen.
Und du hast halt, ja,
dann gibt es halt Datenbanken, die dann halt
unterschiedliche Trade-Offs realisieren.
Ja,
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
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 unterschiedliche, 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 sich 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
vorstelle, 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 jetzt du durch einen Tunnel fährst,
dann nichts mehr geht, sondern
das geht halt mit CouchDB, das ist halt
sozusagen wie Jackfairy ein Layer ü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 ist halt Master, Master
oder Datenbank zu Datenbank
in alle Richtungen. Es ist halt nur so, dass ab und zu
Konflikte auftreten und die müssen dann vom User
gelöst werden. Das heißt, du wirst dann
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 du kannst
halt, auch wenn du offline bist, deine
Web-Anwendung weiter so benutzen als
als wärst du online
und das synchronisiert sich halt in dem Moment,
wo du halt wieder Verbindung hast.
Und
ja, das ist halt dann sehr auf der Availability-Seite
und halt dann auf der 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. Ja, wahrscheinlich nicht so wirklich.
Er hat es schon ganz lange geschafft,
bis er es hier geschafft hat.
Ja, aber und jetzt kommt
eigentlich nur noch ein Teil und das ist halt
irgendwie so Big Data oder
Urlaub-Geschichten für
wirklich große Systeme. Really, really, really
big things. Ja, also
ich meine, Big Data ist ja so ein bisschen, ich weiß nicht, was
ein Passwort.
Was würdest du sagen, ist Big Data oder
warum wollen Leute das haben?
Ja, also erstmal hört sich cool an und also jede Excel-Tablette
mit mehr als, weiß nicht, tausend Teilen kann man schon
einen Trick 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.
Die liegen dann halt auf irgendwelchen
Servern oder halt auch
einfach nur Rechnern rum und haben halt 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 das schon so?
Also ich würde sagen, vielleicht etwas halbwegs
Vernünftigere ist halt, was nicht mehr auf einen Computer passt.
Aber auch das greift eigentlich zu kurz.
Ich habe dann letztens nochmal irgendwie
Meine Spiele dann nur.
Das war irgendein Talk von Michael Stonebreaker.
Das sind immer die gleichen Namen,
auf die man irgendwie in dieser Datenmark-Welt stößt.
Das sind halt so Michael Stonebreaker,
Jim Ray, Ted Kord,
weiß ich nicht,
Ducatting.
Das ist auch
der, der hat auch
der hat Postgres mitbegründet
oder Ingress vorher und dann Postgres
und auch viele
der noch moderne, der heute
ganz modernen Geschichten wie
Column Stores, also C-Store, Paper ist von ihm
VaultDB 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 du hast halt
Probleme mit der Datenmenge. 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
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.
Dann hast du so ein Respy oder sowas und das ist dann mal begrenzt
und dann... 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,
es sind 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,
also ich würde sagen, Big Data ist so ein gehyptes
Ding und
ja, irgendwie
es werden 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
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 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,
bauen möchte über das gesamte Web,
dann kann man das halt eben nicht auf einer Maschine tun.
Das ist halt völlig ausgeschlossen.
Und man möchte das halt irgendwie
auf möglichst
viele Maschinen, so eine halbe Million oder eine Million oder so
skalieren. Wie macht man das?
Und das Konzept, das sie sich dafür überlegt haben,
nennt sich halt MapReduce und
ist auch eigentlich nicht wirklich was Neues.
Früher gab es auch schon ähnliche Konzepte,
wie sich ScatterGather 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,
war schon irgendwie was Neues
und auch ein sehr, sehr cooler Ansatz.
Und zwar machen sie das halt so,
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.
Und du 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.
Aber man muss halt auch wissen, wie oft das vorkommt, weil
man halt bestimmte Geschichten
nennt.
Wir stehen am Anfang von der Liste, wie oft das vorkommt.
Ja, man rechnet so TF-EDF-Scores
aus und dafür braucht man halt die Termfrequenz.
So bitte was? TF-EDS?
Ja, Termfrequenz mal
Inverse Document Frequency ist halt sozusagen
ein wichtiger Wert dafür, wie
wichtig jetzt
ein Wort ist
in der 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 und zusammensetzen.
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 zusammen reduced und dann
sozusagen
hat man halt irgendwie dann diesen Index, wo dann zu jedem
Wort steht, auf welchen Webseiten es vorkam und
ja, wie oft und wie oft
es insgesamt vorkam und so und dann kann man
irgendwie so 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.
Dann bietet sich einfach so ein Rechenzentrum,
da schaltet einfach noch eine Maschine ein, wenn du welche brauchst.
Genau, kannst dann halt immer, einfach immer mehr
Maschinen dazustellen. Und ja,
viele Leute haben sich gedacht, oh, das war eine coole, coole
Idee. Und dann
ja, derjenige,
einer von denen, der Namen
man immer hört, irgendwie, Duck Cutting,
der hat damals schon bei Excite irgendwie
die Suchmaschine gebaut, hat dann später eine sehr
populäre, oder immer noch die populärste
Volltext-Suchmaschine, die es so gibt,
Lucine, oder ist die Engine darunter,
jedenfalls geschrieben, auch
ein Buch darüber, das
ja, und
Irgendwann ist er eher in diesen Big-Data-Hadoop-Bereich gegangen.
Der hat ursprünglich auch dieses Hadoop-Projekt losgetreten.
Und dabei ging es halt darum, ein System wie das, was Google 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, also es wird heute viele
Dinge verwendet, für die es vielleicht nicht so gut geeignet
ist eigentlich.
Zum Beispiel? Ja, also es ist
glaube ich für viele Firmen heute so die generische
Data Warehouse-Lösung
geworden. Obwohl es
dafür, weiß ich nicht.
Also ich würde ja sagen, zum Beispiel viele Firmen haben
eben keinen Big Data. Die haben
keines dieser drei Big Data-Probleme,
sondern
Besser 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
Einrichtung mit einem
Postgres-Server. Ja, oder
irgendwie nicht mal das.
Sikulat Errori.
Jaja, also da
ein Freund von mir sagt dann immer so, oder
ich weiß nicht mehr, das, ach, ich hab das
und ich glaube, ich hab es auf Twitter gelesen, Unsinn.
Man sollte irgendwie,
ich weiß aber nicht mehr, wer es war, ich sollte
eigentlich mal einen Consulting-Service gründen,
der irgendwie,
den man engagieren kann,
wenn man vor der Frage steht, ob man sich jetzt
ein Hadoop-Cluster irgendwie kaufen möchte
oder nicht. Die Antwort ist immer nein.
Gehe ich da hin und sage,
lass mich überlegen,
nein.
Deine Daten
finden in RAM.
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
das nicht will.
und da ist
leider viel Wahres dran, also es gibt wenige, die das
wirklich brauchen, viele
schaffen es sich trotzdem an und haben dann ein
kompliziertes, eine
komplizierte Lösung für ein Problem, das sie nicht haben
Ich meine, das ist natürlich für die Leute, die
Geld verdienen. Genau, für das Problem, was sie haben, ist das
einfach total kompliziert zu benutzen
also Dinge wären viel einfacher, wenn sie
das nicht machen würden, aber naja, so ist es halt
nun mal
und von diesem
MapReduce-Ding ist auch
diese ganze Hadoop-Welt auch schon so ein bisschen
wieder weg. Auch Google macht nicht mehr wirklich
MapReduce, also für manche Sachen machen sie möglicherweise
noch MapReduce, aber es sind ja auch andere
Systeme gegangen, Prägel,
so ein Graph-Processing-Ding, was
sie da machen, was halt relativ viel
tut von dem, was früher MapReduce gemacht hat.
Und
auch bei Hadoop ist es halt so,
dass das, was geblieben ist, ist
irgendwie so ein verteilter Dateisystem-Layer,
so auch Management von
diesen Nodes
irgendwie in diesem Cluster.
Aber
die Engines, die
jetzt irgendwie Queries darauf prozessen,
davon gibt es halt, das nennt sich Hive,
da schreibt man Queries in so einem SQL-ähnlichen
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
ja, also im Grunde die Idee
bei der ganzen Geschichte ist, dass man halt
nicht mehr die Daten zu einer Stelle bringt,
wo sie dann prozessed werden, sondern man bringt
den Algorithmus zu den Daten.
Man kann die Daten nicht mehr an einer Stelle zusammenführen,
weil es sind einfach zu viele. Die liegen halt auf den lokalen
Nodes und man trägt
jetzt den Algorithmus zu diesen Daten
und der läuft dann halt lokal auf den
Cluster-Nodes darüber und dann am Schluss wird das
alles wieder zusammengeführt, zusammenreduced
und dann kriegt man halt das Ergebnis.
Und für einen selber sieht das so aus, man schreibt halt ein
SQL-Statement und kriegt halt ein Ergebnis
und in Wirklichkeit hat man
dann halt irgendwie einen Job gebaut, der dann halt
100 Mapper, 100 Reducer
angestoßen hat und das lief halt über 200 Maschinen
und
Wow, that's big.
Hatte vielleicht das Problem nur Big Data
dann, also Big,
nicht Data.
Aber es wäre
und das hat dann vielleicht eine halbe Stunde gedauert
aber es ist halt auch möglich, wenn man das anders gemacht hätte
hätte diese ganze Geschichte
auch in der Minute durchlaufen können.
Ja, es gibt dann auch
andere Geschichten, die jetzt auf solchen Clustern
laufen, zum Beispiel rein in Memory-Geschichten
so was wie Impala
einer von
den
PhD-Studenten von Michael
Stonebraker, die damals
Postgres mitgeschrieben haben, ist da
irgendwie CTO von der Firma, die da, ich habe jetzt aber auch wieder vergessen,
welche das ist.
Das macht das halt in Memory, das ist
in C geschrieben, das ist alles schneller,
das ist viel angenehmer, wenn man damit arbeitet,
aber es ist auch so ein bisschen komisch und
es ist halt auch nicht so richtig,
es ist halt nur ein bisschen instabil.
Ist
gibt diverse
andere Geschichten. Ach, das war noch ein eigenes
Thema eigentlich. Spark, SpySpark.
Was ganz interessant ist,
ist, was man vielleicht
lasst mich überlegen.
Also was sehr interessant ist,
ist, dass wir heute etwas
sehen,
was wir früher eigentlich auch schon
gedacht hätten, dass wir das im relationalen Bereich bekommen,
nämlich, oder MySQL hat damit mal angefangen,
so, die hatten irgendwie
so eines der coolen Features bei MySQL
am Anfang war, dass die Storage-Engines
pluggable waren. Das heißt, du konntest deine eigene
Storage-Engine da reinbauen. Hat auch kaum
einer gemacht. Es gab eigentlich nur zwei
relevante. Was ist eine Storage-Engine?
Wie die Daten tatsächlich auf der Platte liegen.
Ah, okay. Letztlich.
Und das ist halt, es gab MyISAM,
es gab auch eine CSV-Engine für MySQL,
da hast du einfach CSVs genommen.
Aber MyISAM war so populär.
MySQL hatte aber Probleme. Hatte das Problem,
dass du, wenn du geschrieben hast, wurde mir die komplette Table
gelockt. Das heißt, also da lieber nur lesen, nichts
reinschreiben. So reinschreiben, eher doof.
hat trotzdem irgendwie, haben das
viel lange verwendet, Transaktionen und so, das geht alles nicht.
Asset war nicht so richtig bei MySQL am Anfang und dann
hatten sie eine Storage-Engine, die das dann aber schon konnte,
die auch so wirklich Multiversion
Concurrency-Kontrolle halt richtig konnte und das war
InnoDB und
ja, aber eigentlich
so nachdem InnoDB sich durchgesetzt hatte
oder irgendwie gut genug war,
dann hat sich dieser
Pluggable-Storage-Engine-Geschichte von
MySQL hat sich dann auch wieder erledigt.
Aber Postgres
bekommt jetzt, glaube ich, mit der Version 12, also
das ist noch nicht sicher, aber es sieht ein bisschen danach aus, als ob sie
Plugable Storage Engines wieder zurückbekommen.
Was interessant,
da ist es dann zum ersten Mal, aber
das Konzept nochmal irgendwie
doch nochmal angefasst wird.
Und interessant ist auch in diesem ganzen
Analytics-Big-Data-Bereich,
dass wir da auch sowas sehen. Wir sehen
halt, es gibt nicht mehr so ein Datenbank-
System, wo halt die
wie die Daten gespeichert werden, tatsächlich
an die anderen Teile,
Also im Grunde besteht ja so ein Datenbanksystem aus vielen unterschiedlichen Geschichten. Es besteht halt aus so einem System, das irgendwie einfach nur die Daten managt irgendwie und Zugriffsrechte verwaltet und irgendwie. Und dann gibt es halt so Dinge, wie speichert man das auf der Platte? Es gibt Indizes, es gibt so viele unterschiedliche Teile.
Und ja, wir sehen jetzt so ein bisschen, dass das halt auch alles wieder so ein bisschen pluggable wird, gerade auch in diesem Big Data Bereich. Also auch wichtig, wenn man diese Analysegeschichten macht, hat man im Grunde, ist die Art, wie Daten in relationalen Datenbanken gespeichert werden, ist zeilenweise.
weil die Art von Curries, 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,
irgendwie zeilenweise zu arbeiten.
Sozusagen.
Aber für diese
Analysegeschichten, dieses ganze Data Warehousing Zeugs,
ist das überhaupt nicht sinnvoll.
Dieses Muster, dass man halt
eher Millionen
von Zeilen anguckt, aber nur wenige Spalten,
weil man sich nur für einen bestimmten Aspekt interessiert.
Man interessiert sich oft eben nur für
Umsatz oder Preis
oder sowas. Aber man
interessiert sich gar nicht für den Namen des Autors
oder so. Daher möchte man eigentlich nicht
irgendwie alle Zeilen
immer komplett angucken, weil dann guckt man sich
ganz viel Zeug an.
Der Flaschenhals ist oft
wie
die Wandbreite
zwischen Platte und Hauptspeicher.
Man muss das halt dann irgendwie durch den Prozessor
ziehen. Und je weniger Daten man dadurch
ziehen muss, umso besser. Und bei
einem zeilenorientierten Format muss ich,
ich die Datei lese und die Datensätze
halt zeilenweise drinstehen, muss ich halt da
sequenziell durch die Zeilen durchgehen.
Das geht nicht anders.
Das ist halt total ineffizient, weil wenn ich halt nur
einen kleinen Teil von diesen Zeilen, nämlich nur
eine Spalte, irgendwie überhaupt lesen möchte, das heißt,
wenn ich
so Analyse-Querys
auf Datenbanken mache,
die zeilenbasiert ihre Daten speichern,
dann ist das super ineffizient und ich habe halt
so einen Verlust von circa, man sagt
immer so einen Faktor 50 ungefähr,
sind die halt einfach aufgrund
dieser Architekturgeschichte langsamer
und zwar unoptimierbar
langsamer als sogenannte
Column Stores, die halt Daten
spaltenweise speichern.
Und
die ersten
Dateisystemformate
oder Formate, in denen die Daten zum Beispiel in Hadoop
gespeichert wurden, Avro ist glaube ich
das erste, ich weiß nicht genau,
sind auch alle zeilenbasiert, weil das war halt so.
Man hat halt irgendwie zeilenbasiert Sachen gespeichert,
aber das ist halt eben total
ineffizient, wenn man halt nur
bestimmte Spalten von Datensätzen haben
möchte und dann gibt es halt neuere File-Formate
wie zum Beispiel, oder
Serialisierungsformate,
Parquet-Dateien zum Beispiel,
das ist halt das, was heute eigentlich immer so verwendet wird,
das ist halt dann
spaltenbasiert
und dann liest man eben nur die Dateien
oder die Spalten,
es ist halt in einer Datei nur eine Spalte
sozusagen, man liest halt nur die Dateien,
die man halt braucht
und das ist komprimierbar,
Es ist chunkbar, sodass ich es auf mehrere Rechner verteilen
kann und so und hat halt all diese hübschen
Eigenschaften.
Und
ich habe jetzt diese Paket-Files, aber
das Format der Daten
auf der Platte, das Serialisierungsformat, ist nicht mehr
gebunden an die Datenbank, sondern
als Layer darüber, mit dem ich jetzt
Abfragen mache, habe ich jetzt sowas wie Hive,
das macht dann MapReduce-Jobs draus irgendwie.
Ich habe
aber auch sowas wie Impala, ich habe
vielleicht andere Geschichten, ich habe Spark.
Spark hast du eben noch vergessen, übrigens.
Ja, Spark, genau, gut, Spark
hat auch irgendwie, ist was mit anderen
gestartet, die
hat auch
ein eigenes DataFrame-Format, was
jetzt nicht Parquet war, aber
also worauf es hinausläuft, ist
im Grunde, dass ich jetzt
so ein Format habe wie Parquet,
in dem die Daten auf der
Platte liegen und jetzt
habe ich halt unterschiedliche Engines, die
jetzt irgendwie, mit denen ich jetzt Queries verarbeite,
drauf. Ja, also quasi eine
Trennung zwischen
dem System, das jetzt meine
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 Paket,
aber das, was halt die Dinge
darauf machen, ist halt unterschiedlich.
Das ist eine ganz interessante Entwicklung, finde ich. Also das
ist halt, das ist schon faszinierend
und
ja,
die
ja, Column Stores
sind halt sozusagen, das sind für so Data-Warehousing
eigentlich das Coole. Es gibt
C-Store,
Paper ist halt auch eine
Firma entstanden, Vertica, glaube ich.
Die machen halt,
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 gibt es auch wahrscheinlich
auch noch andere, die sowas ähnliches machen.
Aber was halt nicht gut wäre, ist halt, wenn man
mit so einem Problem zu Oracle
geht. Weil Oracle ist halt nicht
Column-Oriented, sondern die sind halt
zeilenbasiert, egal was sie dazu sagen. Sie versuchen das
in ihrem Marketing immer zu verschleiern, aber es ist halt
genau wie MSSQL zwar war
und die ganzen klassischen relationalen
Datenbanken, die sind alle zeilenbasiert und da
gibt es auch nichts, was man tun könnte.
Ja, es sei denn, man tauscht
die Storage-Engine aus.
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 Zeilenweise
Verarbeitung
gebunden, kann halt auch nichts machen.
Wenn man das demnächst dann 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,
genau. Und das sind halt so die
ja,
das sind halt so diese Geschichten beim
Data Warehousing.
Genauso Hadoop, man nennt das auch so, nicht Data Warehouse,
sondern weil man auch alles mögliche andere drin speichern kann.
Data Lake, weiß ich gar nicht, ob man da so ins Detail gehen muss,
aber man hat auch noch Bilder und sonst wie andere
man kann halt alle möglichen Arten von unterschiedlichen
Ein Datensee, wie bei der FNES, ganz, ganz tief.
Ja, das kann auch so ein bisschen umkippen,
wenn man das dann, Data Swamp.
Ja,
und
ja,
also, ich bin
nicht, ehrlich gesagt, nicht so ein Riesenfan von
Hadoop, muss ich sagen. So, aber
auch, ich hab da
auch schon ein bisschen so schmerzhafte
Erfahrungen mit gemacht.
Weil so Daten
rein und raus kriegen, ist irgendwann so ein bisschen hässlich
und das ist auch immer noch alles
nicht so weit, also bei so klassischen Datenbanken
ist halt, da merkt man, also wenn man Postgres-Rat
verwendet zum Beispiel, merkt man halt so, da ist halt schon
Jahrzehnte
Erfahrung drin
und viele der Use-Cases, die man so hat,
also wenn man da auf blöde
Probleme stößt, dann ist man wahrscheinlich selber schuld.
Also das ist halt
sehr selten, würde ich jetzt mal so
90 Prozent der
Probleme sitzen vor der Tastatur.
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 leicht fixen lassen.
Also es wäre halt
wenn man tatsächlich ein Problem mit der Datenbank
hat, wäre es natürlich schlecht,
weil da kann man nichts machen, außer Datenbank wechseln
oder irgendwie
selber neu schreiben oder sowas, nicht gut wäre.
Und
bei Hadoop habe ich so das Gefühl,
es kann natürlich auch was sein, dass ich einfach zu blöd
war, es nicht 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
nicht richtig verwendet, so das falsch rum hält
irgendwie, sondern
bestimmte Sachen gehen einfach noch nicht
oder gehen nicht richtig. Man hat Use Cases
und dann stellt man so fest, so ja,
hat niemand drüber nachgedacht, ist nicht so richtig
abgebildet, blöd.
Und
das wird wahrscheinlich alles irgendwie viel besser, aber momentan
ist es noch nicht so, ist noch ein bisschen
scharf, fühlt sich alles ein wenig scharfkantig an.
Man kann sich überall schneiden 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, jetzt sind wir wieder bei dem
Ding, was wir eigentlich als Running-Gag nehmen wollten, da haben wir es doch
dazu verlassen. Ja, Java, Java, mal wieder.
Das ist...
Nach zweieinhalb Stunden sind wir doch wieder drauf gekommen, ja.
Ja, aber da ist dann
möglicherweise der Ausweg, irgendwie sowas wie PySpark
zu verwenden. Spark, auch nochmal, eigentlich müssen wir
dann mal ein eigenes Thema zu machen,
aber sehr schön, das Ding ist so, dass man halt
quasi
Sachen automatisch verteilen kann,
man hat sie lokal, man kann
damit anfangen, dass man es auf einer Maschine hat und dann
führt man Sachen auf einen Cluster
aus und das ist wirklich mehr oder weniger
seamless.
Das Einzige,
man hat sogar einen vollständigen
Python-Interpreter, das ist irgendwie nicht so
eine verkrüppelte Version. Man kann halt tatsächlich
irgendwie Sighten-Sachen
damit machen. Das heißt, man kriegt Sachen auch wirklich, wirklich
schnell.
Im Gegensatz zu
Java. Java geht vielleicht auch, ich weiß es nicht genau,
aber ich glaube, es ist ziemlich schwer, Sachen wirklich
optimiert hinzukriegen.
Während in Python ist es halt relativ
leicht, irgendwie mit
Seiten halt ein Dialekt von Python
zuschreiben, wo man dann Typ-Annotationen dazu schreibt,
wo die dann halt zu C
kompiliert werden, dann wird das als C-Modul, dann wird es wieder
reimportiert und das kann man halt auch
auf den Cluster irgendwie ausrollen
irgendwie über PySpark
und dass man jetzt irgendwie C-Code irgendwie
in Java reinbastelt und das
dann halt über Hadoop, über die MapReduce-Service verteilt,
weiß ich nicht. Kann auch sein, dass das geht, keine Ahnung, aber das
klingt irgendwie nicht so leicht.
Ja, wie auch immer. Also
Spark ist auf jeden Fall auch noch eine super
interessante Geschichte, vor allen Dingen, wenn es jetzt darum geht,
Wenn man jetzt sowas hat wie so ein Data Lake und so,
wie kommen da die Informationen rein?
Man möchte eigentlich nicht da so ETL-Jobs machen.
Das funktioniert alles nicht mehr.
Man möchte ja auch Echtzeit-Dashboards haben irgendwie.
Und dann wechselt man halt irgendwann auf so eine Streaming-Architektur,
wo halt Dinge auf der Webseite,
also auch gerade wenn man jetzt sowas hat wie,
also auch Amazon wird, selbst wenn man die Bestellungen nimmt oder so,
das ist alles noch nicht Big Data,
aber wenn jetzt zum Beispiel Amazon, und das tun sie bestimmt,
irgendwie jeden Klick den User
macht auf der Webseite, auch
irgendwo eine
Fakten-Tabelle
in ihr Data Warehouse, Data Lake
Ding reinspeichern möchte,
dann wird das big.
Weil das ist halt schon viel.
Dann ist so ein Verhältnis von Bestellungen zu
Leute machen irgendwie Web-Requests oder klicken
auf der Seite rum, ist halt wahrscheinlich nochmal so
ein Faktor 100 oder mehr.
Und
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 Analyse-System
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.
Meinst du aber nicht die Lambda-Service?
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,
also irgendwie als Protokoll-Buffers
oder sowas.
Und dann gehen die Dinger halt
auch da wiederum Serialisierungsformate
sehr, also es gibt halt sehr unterschiedliche
Protokoll-Buffers und super, wenn man Daten übertragen möchte
oder auch dieses Rift 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 Protokoll-Buffer-Events.
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 in Echtzeit, wie die Conversion runtergeht.
Ah, der Preis war gut.
Und dann kann man halt so als
Manager vor diesem Dashboard sitzen
und den Knöpfen drehen.
Die Firma vor die Wand fahren.
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,
der hat das gestartet,
weil der da halt ein,
und das ist auch tatsächlich,
also ich, während ich mich halt mit
Hadoop-Geschäfte, aber mich hat es an den
gleichen Stellen gejuckt sozusagen, also ich
das war so zuerst gemacht, also ihn hat es wohl
auch irgendwie genervt, der hat bei
Cloudera gearbeitet irgendwie, das ist halt auch so eine von diesen
Firmen,
die halt so in diesem Big Data, Hadoop-Bereich
viel unterwegs sind, auch da irgendwie glaube ich
einer von den Chefs oder Gründern ist halt
einer von den, ist auch ein PhD-Student
von Michael Stonebaker, so sind
alles irgendwie immer die gleichen Leute und
der, genau,
da geht es darum, 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 in der 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, die dann 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 das Array
und ich
hatte halt immer das Problem, wenn ich jetzt
damit so Systemen wie Hive oder Impala draufgegangen
bin, dann kriege ich halt irgendwie so
eher so ein CSV oder
so ein Result-Set und dann kriege ich das nicht schnell da raus.
Das ist halt alles
ultra langsam und
ich brauche aber für meine Modelle doch durchaus große Daten
oft. Das geht alles nicht
und dann
wäre es natürlich viel besser gewesen, wenn ich
einfach nur, wenn jetzt, also
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 es 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
Westmorekenny bei Cloudera gebaut hat,
gemacht. Man hatte ein Ding, das war
wie ein Pandas-Data-Frame,
wo man da halt irgendwie Group-By 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
mit den Ergebnissen irgendwas gemacht.
Ja, aber
das hat auch nicht gereicht, weil auch da wieder das Problem war,
wie kriegt man die Daten wieder, 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 den Machine Learning
Algorithmus reinzupumpen, damit er
möchte irgendwie ein Modell drauf trainieren.
Man kann eben jetzt bei diesem Data Frame eben nicht sagen
df.values. Das geht
halt nicht, weil die Daten sind halt im Cluster.
weil sie da irgendwie rauskriegen und man kriegt sie nicht raus.
Es 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 Westman Kinney hat dann auch
ist dann 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, es 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 RStudio
zusammen.
Die haben das
beide zusammen gemacht, dieses Projekt.
Genau.
Die Idee ist sozusagen, du hast halt
eine Abstraktionsschicht,
die halt irgendwie so ein Array-Store
im Hauptspeicher hält.
Das macht Apache Vero. Das Ding ist in C++
geschrieben, aber du kannst halt von Python aus zugreifen
oder von AdRof 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, du kannst 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,
dann kannst du es halt nicht klar auf horizontal
auftreiben in Mapper und Reducer, das funktioniert
einfach nicht, das ist halt Quatsch.
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
linearer Algebra. Und linearer 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.
Jetzt sieht es wieder gerade, die halt bei NumPy so ein bisschen kaputt sind.
Unter anderem
Was halt total blöd ist, aber das habe ich auch schon mal erwähnt, dass es halt keinen Null für Integer gibt und so. Also mit Missing Values ist halt schwer bei NumPy Arrays. Und ja, es gibt dann auch 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 Data Science und Machine Learning irgendwie so angedockt.
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 halt so Analysten, oft super schlaue Leute, aber ich überlege gerade, wie man ein Beispiel nehmen 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?
Okay.
Für was musst du irgendwie vorsorgen?
Und bei einem klassischen BI-Ansatz
wäre halt, du guckst dir halt die Icons an,
wo Städte überflutet worden sind, da gibt es nicht so viele.
Substrahierst
da halt irgendwie so, kriegst dir das halt eine Woche
vorher, später an
und überlegst dir dann halt irgendwas 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.
Äh, und auch, 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 oft 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, wie, wie macht man Produktentwicklung, ja, 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 super interessant
es gibt dann noch SideDB
oder sowas
glaube 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 gerade sagen, wir haben jetzt ganz, ganz
lange schon, also fast drei Stunden
schon über die ganzen Daten gesagt. Man merkt ja,
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 beteiligst? Genau, genau, genau.
Ja, ach so, ah, und genau,
wenn man jetzt nochmal zurückkommt zu dem E-Commerce-Ding,
das war jetzt so eine Exkurs Richtung Big Data.
Ja, also wenn wir ganz groß sind,
immer so ein Maß oder so.
Ja, also das hatten wir auch vorher schon mal
kurz angeklärt, also
relationeller Datenbanken oder so, diese Art,
Daten umzugehen, ist halt besonders gut 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, dass 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.
Aber
das ist jetzt tatsächlich die 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
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,
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 alles selber bauen. Das ist natürlich
nochmal ein ganz anderes Problem.
Während heute man wahrscheinlich mit Postgres,
Django, Redis
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
vielleicht, 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 10 Jahre her,
unglaublich, oder noch mehr als 10 Jahre sogar.
Mein Vortrag gehört
von David Weinberger,
der ist ein Philosoph,
hat sich auch viel mit Internetgeschichten
beschäftigt in Harvard.
Kann man mal gucken, ich packe ja auch noch
in die Shownotes.
Der Vortrag heißt
Everything's Miscellaneous.
Da gibt es auch ein Buch zu.
Der Talk bei Google ist halt
eine Vorstellung von dem Buchinhalt,
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.
Und wir das aber noch gar nicht so richtig antizipiert haben.
Sein Beispiel ist halt auch E-Commerce und halt auch so Faceted Navigation.
Und er sagt halt, naja, also in so einem klassischen Laden, wenn du da reingehst, muss man sich überlegen.
wo man welche Dinge hinpackt, ja, also
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, man könnte das irgendwie so slicing und
dicing, 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.
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 Filter-Bubble immer erzeugt für den jeweiligen...
Genau, weil elektronisch habe ich das Problem nicht.
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
sowas wie ein
Weg durch den 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. Ja genau, die kennen das so, ja.
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
und
genau. Das ist 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 Idee ist. 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 fünf Jahren eine gute Idee.
Keine Ahnung, wann 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.
Braucht man nur noch ein bisschen Geld
und Geduld.
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
Verkäufern... Du möchtest ein Framing bauen
für den jeweiligen Kunden.
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.
Das liegt halt vor allen Dingen, dass die Navigation so aussieht, wie sie
aussieht, liegt halt am 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 draufbauen.
Und ich könnte auch, also wenn ich jetzt,
also der Witz ist, was ich
eigentlich eventuell gerne hätte,
Und wenn jetzt ein Produktmanager, der für die Kategorie Fahrräder oder sowas zuständig ist, auf eine super Idee kommt, wie man das Navigieren 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 können. 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
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
Objekte hat, sondern Daten über Daten und
eine Datenbank, die halt
nicht mehr so
Fixschema, nicht so ein Fixschema
hat, dann könnte man eventuell das 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 im Grunde nichts machen, weil das Schema halt für Angebote halt immer gleich sein muss, weil die sind ja alle in einem Datenbankschirm.
Genau, aber das könnte halt irgendwie wie etwas anders aussehen.
Und was halt da sehr interessant sein könnte,
sind halt Grafendatenbanken zum Beispiel.
Wo man halt eben nicht,
ich hatte das ja auch am Anfang schon mal erwähnt,
es hätten sich auch Grafendatenbanken durchsetzen können.
Das ist überhaupt nicht so klar, warum das relational geworden sind.
Gut, die Grafendatenbanken 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
ja, der hat sich
der hat sich irgendwie getroffen
Google-Beschäftige und dann halt auch
überlegt, was sind denn jetzt die Sachen, die man
heutzutage, die Probleme, die man hat, also es muss halt irgendwie so
es muss halt, 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,
Go wäre eventuell ein guter Kandidat, um
da drin eine 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 nicht so gut geeignet,
weil, also Python ist gut geeignet, wenn
man IOMultiplexen 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
Skalierbarkeit 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, ja, Datenmarken sind eventuell
so etwas, was halt genau
diese Anforderungen hat und was man dann in Python vielleicht
dann doch nicht so gut schreiben könnte.
Und ja, tatsächlich,
dgraph ist in Go
geschrieben und
ja, mit Grafen
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
es gibt ja nochmal bei den grafischen Datenmarken
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, also das ist halt eher so
ein Textformat
es gibt ja auch Mikroformate auf Webseiten, wo man das benutzen kann
wo man irgendwelche
halt Metadaten
über die Seite irgendwie hinterlegen kann
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 alles immer ziemlich langsam
sein. Und es gibt halt Graphendatenbanken,
die das halt so optimiert speichern.
Dazu gehört Dgraph auf jeden Fall,
die älteste und weitestverwaltete
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 die gemacht, und es ist halt auch, es hat
eine komische Abfragesprache,
Cypher heißt die irgendwie,
ja, und
naja, und ob das alles
so, also ist auch Asset und so,
das ist alles nicht so,
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, das ist die Abfragesprache, die nehmen einfach
GraphQL oder
Dialekt davon und das ist natürlich auch nochmal sehr
interessant, weil GraphQL ist natürlich auch momentan
ein sehr heißes Thema.
Ja, 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 es 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
und nur NoSQL, das heißt entweder
steht für Not-Only-SQL
oder eben
kein SQL.
Naja,
in Postgres hat man zum Beispiel die Möglichkeit, das
ein bisschen zu kombinieren. Da gibt es halt
ein sehr schönes
sehr schönen Spalten-Typ
nennt sich
BinaryJSON.
Also man muss aufpassen, JSON gibt es auch,
ist aber nur so aus Legacy-Gründen noch dabei.
Den nicht nehmen,
der ist alt
und nicht so gut.
Aber BinaryJSON ist super,
weil
da kann man auch Indizes auf
Felder innerhalb von dem JSON 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 JSON ist,
einfach so reinschreiben, er kann sogar Sachen
darin indizieren und so, und
das ist halt sackschnell,
das ist ähnlich schnell wie MongoDB,
MongoDB macht ja, MongoDB ist
mehr oder weniger nur diese
B-JSON-Spalte
aus Postgres.
Das ist halt mehr oder weniger das Gleiche.
Das heißt, 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 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 weiß,
also es gibt ja so etablierte Geschichten,
da ist schon klar, wie das funktioniert.
Userverwaltung, 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,
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,
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?
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...
Ist ja jetzt nicht so 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...
Man kann sich ja 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, da sind einige interessante Gedanken drin, 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 da gerade am Anfang, ich nehme erstmal so ein bisschen SQLite oder sowas, das ist ganz super, das ist ja direkt dabei und da kann man direkt loslegen und seine ersten Datenbanken ein bisschen füttern.
Wird für den Einstieg auch gar nicht so schlecht, dann kann man erstmal ein paar SQL-Skates mit sehen und vielleicht mit SQL-Alchemy das machen und dann.
Das ist auch interessant, ich glaube SQLite ist eine der Software, die mit am weitesten, die weiteste Deploy-Basis hat irgendwie so.
Ich glaube, es konkurriert noch mit Curl oder so.
Das wird auch fast überall
mit drin. Aber ich glaube, SQLite
ist auch ein Kandidat für das. Das ist fast überall drin.
Das ist auch
CoreData, 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.
Wenn man irgendwie, das ist auf einer
Apple Watch, ist eine SQLite-Datenbank
und zählt die Schritte. Das ist echt total krass.
Also 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. Also
das ist ein super interessantes Projekt und
ja, auch ich glaube, es wurde
mal vorgeschlagen, für Langzeitarchivierung
das SQLite-Format zu nehmen, weil es halt so
von
irgendeiner Bibliothek
ach, 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 habe ich, 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
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 halt CSVs nehmen, die da reinwerfen
und dann kriegt man halt so auch ein Interface mit
Faceted Navigation, mit Volltextsuche, weil
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.
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.
Genau. Auch wie man
auf Datenbanken von Patent aus zugreift.
Es gibt so
Async
PG als
asynchroner Datenbank
Client für Python.
Das wird noch sehr interessant, also das ist momentan
noch ein Problem. Also PsychoPG
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
und hat jetzt Facet Navigation,
das heißt, man muss halt an den Facetten,
das heißt Tags oder Kategorien oder
irgendwelchen anderen
Monaten oder was auch immer man halt
navigierbar halten will,
schreibt man jetzt noch so Counts dran oder man muss halt
überhaupt wissen, was hat ein Count von größer 0, 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
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, ist halt
dauert nur noch so lange wie das längste Statement
und alle anderen Sachen sind halt vorher da und das würde halt
wahrscheinlich bedeuten, dass dann ist man runter auf 50
Millisekunden oder so, dann haben wir 100 Millisekunden gespart.
Das wäre ziemlich cool. Aber dafür
müsste halt Django asynchron sein, dafür müsste
man halt irgendwie
AsyncPG verwenden statt
PsychoPG 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
WebSockets,
dass man halt bidirektionale
Kommunikation zwischen Client und Server hat
bei Web-Anwendungen.
Und der hat jetzt dieses Projekt so ein bisschen aufgegeben oder ist nicht mehr Maintainer davon.
Und das, was man jetzt macht, ist jetzt, der versucht Django Async fähig zu machen.
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, sieht danach aus, so ein bisschen, als ob das 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.
Ich würde jetzt einiges mehr über Daten backen,
dass man damit alles anstrengen kann.
Ja, schöne Sache.
Ja, und dann...
Super, dass ihr dabei wart.
Genau.
Und ja, wo ihr immer hier seid,
schönen Tag und so weiter.
Wenn ihr Fragen habt,
hallo.at.peisenpodcast.de
Ja, super.
Ja, dann bis zur nächsten Folge.
Ja, bis dahin.
Tschüss.
Ciao.