WEBVTT

00:00:00.640 --> 00:00:05.180
Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der mittlerweile fünften Episode.

00:00:06.200 --> 00:00:08.120
Heute geht es ein bisschen um Datenmanken.

00:00:09.280 --> 00:00:13.000
Ja, wir haben wieder den schönen Wintergarten vor uns.

00:00:13.100 --> 00:00:15.300
Ich bin der Dominik und natürlich dabei ist wie immer der Jochen.

00:00:15.880 --> 00:00:18.700
Jo, hallo. Genau, Datenmanken, ja, voll gut.

00:00:18.820 --> 00:00:21.900
Da freue ich mich schon drauf. Das ist irgendwie ein Thema, mit dem ich schon viel zu tun hatte.

00:00:22.240 --> 00:00:23.420
Wird wahrscheinlich eine ein bisschen längere Episode.

00:00:24.260 --> 00:00:26.140
Wir versuchen wieder ein bisschen Struktur reinzubekommen.

00:00:26.660 --> 00:00:27.960
Wir wissen noch nicht ganz, ob das gelingt.

00:00:27.960 --> 00:00:29.580
Wir werden wieder hemmungslos abschweifen.

00:00:30.000 --> 00:00:31.880
Wenn ihr Fragen, Anmerkungen dazu habt,

00:00:31.960 --> 00:00:34.180
Kommentare, Lob, alles, was ihr uns mitteilen wollt,

00:00:34.240 --> 00:00:36.800
schickt eine E-Mail an hallo at python-podcast.de

00:00:36.800 --> 00:00:38.040
und wie immer

00:00:38.040 --> 00:00:39.780
findet ihr die Links und zusätzliche Infos der Sendung

00:00:39.780 --> 00:00:40.680
in den Shownotes.

00:00:41.860 --> 00:00:43.160
Wollen wir das eigentlich noch erwähnen,

00:00:43.300 --> 00:00:45.220
welches Datum wir haben? Heute ist der

00:00:45.220 --> 00:00:47.320
24.02.2019.

00:00:47.320 --> 00:00:49.520
Oh, wir machen jetzt mit Daten. Ja, finde ich gut.

00:00:50.120 --> 00:00:51.580
Genau, wir haben das glaube ich schon mal gemacht.

00:00:51.920 --> 00:00:52.620
Ja, haben wir das schon mal gemacht?

00:00:53.220 --> 00:00:55.000
Dann haben wir es irgendwie nicht mehr gemacht, aber ich glaube,

00:00:55.040 --> 00:00:56.540
es ist wahrscheinlich eigentlich ganz interessant,

00:00:57.160 --> 00:00:58.880
wenn man das hört, von wann das

00:00:58.880 --> 00:01:01.100
aufgenommen wurde. Ja, stimmt. Ende Februar

00:01:01.100 --> 00:01:03.060
19. Und es ist gerade

00:01:03.060 --> 00:01:04.500
ganz gutes Wetter und es ist ein Sonntag.

00:01:05.520 --> 00:01:06.800
Normalerweise nehmen wir immer abends auf.

00:01:07.140 --> 00:01:08.940
Heute ausnahmsweise mal nach dem

00:01:08.940 --> 00:01:10.780
Brunchen. War irgendwie super lecker.

00:01:12.100 --> 00:01:14.860
Ja, ich würde sagen, wir steigen fast direkt

00:01:14.860 --> 00:01:16.920
ins Thema ein und es geht halt so

00:01:16.920 --> 00:01:18.820
ein bisschen darum, ja, das ist glaube ich nicht

00:01:18.820 --> 00:01:20.920
das erste Mal, dass wir versuchen, so eine Folge mit Datenbanken

00:01:20.920 --> 00:01:22.820
zu strukturieren. Das war auch der Grund, warum

00:01:22.820 --> 00:01:24.880
wir so ein bisschen länger auf die letzte Folge warten

00:01:24.880 --> 00:01:27.080
mussten. Hatten wir ja kurz erwähnt.

00:01:28.280 --> 00:01:28.760
Ja, was ist

00:01:28.760 --> 00:01:30.200
überhaupt so eine Datenbank jochen und

00:01:30.200 --> 00:01:32.700
wir versuchen halt immer wieder euch vielleicht kurz

00:01:32.700 --> 00:01:34.660
zu erklären, was man damit noch mit Python machen kann

00:01:34.660 --> 00:01:35.920
oder welche Modules es dafür gibt, aber

00:01:35.920 --> 00:01:38.640
das vielleicht mal als Warnung. Python kommt in dieser

00:01:38.640 --> 00:01:40.620
Folge nicht nur vor und nicht ganz so viel, sondern

00:01:40.620 --> 00:01:42.580
es geht halt tatsächlich darum, wie man das, was man mit Python

00:01:42.580 --> 00:01:44.280
macht, also die Datenbanknutzung

00:01:44.280 --> 00:01:46.800
so ein bisschen euch erklären, näher bringen kann.

00:01:47.120 --> 00:01:48.600
Ja, wobei ich denke, dass das halt

00:01:48.600 --> 00:01:50.280
eigentlich für alle, die Python

00:01:50.280 --> 00:01:52.500
entwickeln wollen, ein interessantes Thema ist,

00:01:52.580 --> 00:01:54.600
weil da wird man, egal in welchem Bereich man sich

00:01:54.600 --> 00:01:56.740
da tummelt, nicht drum herum

00:01:56.740 --> 00:01:58.680
kommen, irgendwann etwas mit Datenbanken zu machen.

00:01:58.760 --> 00:01:59.800
und

00:01:59.800 --> 00:02:02.740
ja, dafür muss man sich halt dann auch

00:02:02.740 --> 00:02:04.660
nicht nur mit Python auskennen, sondern man muss halt auch so ein bisschen verstehen,

00:02:04.800 --> 00:02:06.180
wie das mit den Datenbanken funktioniert

00:02:06.180 --> 00:02:08.660
und man kann halt nicht viel interessante Dinge machen, wenn man

00:02:08.660 --> 00:02:10.740
halt von Datenbanken da gar nichts versteht

00:02:10.740 --> 00:02:12.740
und insofern, ja.

00:02:13.000 --> 00:02:14.520
Wir werden noch ein bisschen darauf eingehen, was ist das überhaupt,

00:02:14.620 --> 00:02:17.080
eine Datenbank, unterschiedete einzelne Datenbanktypen

00:02:17.080 --> 00:02:18.680
ein bisschen darstellen und wir wollen

00:02:18.680 --> 00:02:20.560
anhand eines kleinen Beispiels euch so ein bisschen so

00:02:20.560 --> 00:02:22.760
die Problematiken beim Skalieren und bei dem

00:02:22.760 --> 00:02:24.660
Arbeiten mit der Datenbank erklären.

00:02:25.280 --> 00:02:25.560
Genau.

00:02:26.460 --> 00:02:32.600
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.

00:02:32.860 --> 00:02:35.080
So ein Buchladen, habe ich gehört, können wir als Beispiel nehmen.

00:02:35.140 --> 00:02:50.080
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.

00:02:50.420 --> 00:03:04.580
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.

00:03:04.580 --> 00:03:26.600
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?

00:03:27.400 --> 00:03:42.460
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.

00:03:43.760 --> 00:03:48.400
Für alle, die das noch nicht drauf haben, ist es so SQL oder NoSQL, genannt oft.

00:03:48.400 --> 00:04:08.780
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.

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

00:04:18.220 --> 00:04:33.860
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.

00:04:33.860 --> 00:04:49.140
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.

00:04:49.140 --> 00:05:02.120
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.

00:05:02.620 --> 00:05:13.080
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.

00:05:14.540 --> 00:05:33.280
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.

00:05:33.300 --> 00:05:40.540
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.

00:05:40.860 --> 00:06:08.840
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.

00:06:10.700 --> 00:06:12.540
Und ja, das ist natürlich auch

00:06:12.540 --> 00:06:14.320
eine Struktur. Man hat halt irgendwie darüber

00:06:14.320 --> 00:06:16.420
die Verzeichnisse, die es da gibt, auch schon

00:06:16.420 --> 00:06:18.460
so Metadaten definiert, dass man halt weiß,

00:06:18.560 --> 00:06:20.500
so bestimmte Sachen sind halt in einem bestimmten Verzeichnis und so.

00:06:21.780 --> 00:06:22.140
Und

00:06:22.140 --> 00:06:24.180
das Ganze gibt es halt auch über

00:06:24.180 --> 00:06:25.960
Netzwerkgeschichten.

00:06:26.500 --> 00:06:28.520
Die bekannteste hierarchische Datenbank

00:06:28.520 --> 00:06:30.120
im Netz ist halt sowas wie LDAP.

00:06:31.700 --> 00:06:32.500
Windows nennt

00:06:32.500 --> 00:06:34.440
das irgendwie Active Directory oder ist auch vielleicht noch

00:06:34.440 --> 00:06:35.120
ein bisschen komplizierter.

00:06:36.280 --> 00:06:38.280
Und ja, das ist halt schon mal eine

00:06:38.280 --> 00:06:40.300
grundsätzliche Art, wie man Datenbanken

00:06:40.300 --> 00:06:40.940
betreiben kann.

00:06:42.320 --> 00:06:44.200
Aber vielleicht, was ich

00:06:44.200 --> 00:06:46.140
ganz gerne auch nochmal

00:06:46.140 --> 00:06:47.000
ansetzen würde, ist,

00:06:48.540 --> 00:06:50.120
wie Leute, also wenn man jetzt sich

00:06:50.120 --> 00:06:51.920
überlegt, wo könnten Leute

00:06:51.920 --> 00:06:54.200
etwas, das man

00:06:54.200 --> 00:06:56.140
sonst vielleicht mit Datenbanken tun

00:06:56.140 --> 00:06:58.000
könnte, irgendwie schon mal gesehen haben? Oder was

00:06:58.000 --> 00:07:00.100
machen viele Leute, was halt eigentlich auch

00:07:00.100 --> 00:07:01.480
gut in den Datenbank-Kontext passt?

00:07:02.020 --> 00:07:04.020
Dann würde ich vielleicht sogar eher mit sowas wie

00:07:04.020 --> 00:07:06.240
Excel oder so anfangen, weil

00:07:06.240 --> 00:07:08.200
das wird dann

00:07:08.200 --> 00:07:09.680
oft so scherzhaft auch erwähnt,

00:07:10.220 --> 00:07:11.780
Wenn man sich überlegt, was ist die

00:07:11.780 --> 00:07:13.940
meisten verwendete, meisten ausgerollte

00:07:13.940 --> 00:07:15.720
Datenbanklösung

00:07:15.720 --> 00:07:16.600
der Welt,

00:07:17.280 --> 00:07:19.800
könnte man auch sagen, das ist halt Excel, weil

00:07:19.800 --> 00:07:21.780
viele Leute halt Excel quasi als

00:07:21.780 --> 00:07:24.020
Datenbank benutzen. Allen möglichen

00:07:24.020 --> 00:07:25.780
Quatschen, irgendwelche Spalten und Teilen reinschreiben und

00:07:25.780 --> 00:07:27.000
ganz, ganz, ganz, ja.

00:07:27.340 --> 00:07:27.640
Und

00:07:27.640 --> 00:07:31.600
das ist, genau, das ist halt

00:07:31.600 --> 00:07:33.740
eigentlich, ach so, und vielleicht sollte man sich

00:07:33.740 --> 00:07:34.740
erstmal grundsätzlich überlegen,

00:07:35.460 --> 00:07:37.900
wenn man schon so anfängt zu erklären, was Datenbanken

00:07:37.900 --> 00:07:39.740
sind, was ist denn eigentlich Daten,

00:07:39.900 --> 00:07:42.020
was sind eigentlich Informationen, was sind eigentlich Wissen.

00:07:42.580 --> 00:07:43.920
Dafür hat man umgangssprachliche

00:07:43.920 --> 00:07:46.240
Definitionen,

00:07:46.300 --> 00:07:47.900
wo man dann weiß, was das ungefähr

00:07:47.900 --> 00:07:48.600
sein soll, aber

00:07:48.600 --> 00:07:51.960
wenn man das jetzt aus dem Datenbank-Kontext her

00:07:51.960 --> 00:07:53.900
präzisieren möchte, dann geht das eigentlich

00:07:53.900 --> 00:07:55.780
auch relativ schmerzlos. Also Daten sind

00:07:55.780 --> 00:07:57.880
halt sowas wie, also ein Datum wäre

00:07:57.880 --> 00:08:00.340
irgendwas mit minus 3,5

00:08:00.340 --> 00:08:01.740
wäre jetzt ein

00:08:01.740 --> 00:08:02.300
Datum.

00:08:03.980 --> 00:08:05.340
Einfach nur ein Zahlenwert oder so.

00:08:06.600 --> 00:08:08.020
Und das sagt einem halt

00:08:08.020 --> 00:08:08.880
natürlich noch nichts.

00:08:09.740 --> 00:08:11.820
Weil es ja kein Bezug dafür hat, minus 3,5, was denn?

00:08:12.060 --> 00:08:12.660
Ja, genau, richtig.

00:08:12.680 --> 00:08:13.400
Grad Fahrenheit.

00:08:15.100 --> 00:08:19.080
Und wenn man jetzt von Informationen spricht,

00:08:19.200 --> 00:08:21.660
dann spricht man von Daten, die halt schon so ein bisschen Kontext haben.

00:08:21.800 --> 00:08:26.380
Also sowas wie minus 3,5 Grad Temperatur.

00:08:26.680 --> 00:08:29.020
Das heißt, man weiß halt, das steht jetzt in der Temperaturspalte.

00:08:29.780 --> 00:08:33.240
Und damit weiß man schon mal so ein bisschen, worum es da überhaupt geht.

00:08:33.240 --> 00:08:35.120
Und dann nimmt man das Informationen.

00:08:36.460 --> 00:08:39.420
Und das, was man aber eigentlich in Datenmarken speichern möchte,

00:08:39.720 --> 00:08:56.840
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.

00:08:57.820 --> 00:09:06.680
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.

00:09:07.020 --> 00:09:10.520
Das heißt, man hat halt Wissen über, wie das Wetter gerade ist oder wie es war.

00:09:10.540 --> 00:09:12.400
Oder man weiß zum Beispiel, dass es im Winter kälter wird als im Sommer.

00:09:12.560 --> 00:09:15.460
Ja, genau. Und dann kann man halt, wenn man Abfragen daran stellt,

00:09:15.560 --> 00:09:18.280
dann halt Schlussfolgerungen daraus ziehen und dann vielleicht Dinge vorhersagen

00:09:18.280 --> 00:09:24.100
oder halt auch einfach bestimmte Fragen beantwortet bekommen, die einen interessieren.

00:09:24.100 --> 00:09:28.500
Also alle Städte, in denen es letztes Jahr kälter war als so und so oder irgendwie sowas.

00:09:31.140 --> 00:09:33.820
Genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.

00:09:34.000 --> 00:09:35.020
Da kann man auch Analysen irgendwann machen.

00:09:35.100 --> 00:09:36.520
Das ist aber dann, glaube ich, wieder ein neues Thema,

00:09:36.660 --> 00:09:38.060
wie man Analysen dann mit Daten fährt.

00:09:38.340 --> 00:09:39.220
Das werden wir heute, glaube ich, nicht machen.

00:09:39.500 --> 00:09:40.600
Doch, doch, doch.

00:09:40.600 --> 00:09:42.120
Ja, doch, doch, doch, alles.

00:09:43.040 --> 00:09:44.920
Ihr müsst heute lange, lange Geduld mitbringen

00:09:44.920 --> 00:09:46.740
oder eine große Runde durch den Park

00:09:46.740 --> 00:09:48.800
oder könnt gerne zur Wohnung putzen heute.

00:09:49.460 --> 00:09:51.580
Ja, ich bin mal gespannt, wie schnell wir da durchkommen.

00:09:53.200 --> 00:09:56.080
Aber ja, ich denke, das ist eigentlich vielleicht ganz interessant,

00:09:56.180 --> 00:09:56.860
mal so einen groben Überblick.

00:09:56.980 --> 00:09:59.460
Also ich versuche dann zu verhindern, zu sehr ins Detail zu gehen.

00:09:59.460 --> 00:10:03.740
Aber wenn man einfach mal so das Gesamtthema Datenbanken

00:10:03.740 --> 00:10:05.560
mal überblickt hat. Ja, ich hätte

00:10:05.560 --> 00:10:07.500
so ungern davon ab, so ins Detail zu gehen, weil ich finde das

00:10:07.500 --> 00:10:09.240
unheimlich interessant, was da alles noch so drinter steckt.

00:10:09.380 --> 00:10:11.580
Ich bin da sehr curious, was man noch alles

00:10:11.580 --> 00:10:13.620
so findet und die Details sind halt auch irgendwie

00:10:13.620 --> 00:10:15.720
wichtig, ja. Ja, stimmt.

00:10:16.180 --> 00:10:17.620
Wir schauen einfach mal. Ich hoffe mal,

00:10:17.640 --> 00:10:19.240
dass es nicht allzu lang wird, aber. Okay, ja, dann

00:10:19.240 --> 00:10:21.520
fangen wir doch direkt mit dem Beispiel an oder wolltest du noch so ein paar

00:10:21.520 --> 00:10:23.120
grundsätzliche Dinge über Daten? Genau, ich würde einmal

00:10:23.120 --> 00:10:25.700
grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken,

00:10:26.320 --> 00:10:27.300
auch um halt dann,

00:10:28.020 --> 00:10:29.580
ja, um

00:10:29.580 --> 00:10:31.560
darauf dann wieder Bezug nehmen zu können in dem Beispiel

00:10:31.560 --> 00:10:33.460
und vielleicht auch das, was halt

00:10:33.460 --> 00:10:35.780
jetzt durchgesetzt hat, jedenfalls

00:10:35.780 --> 00:10:37.420
das ist halt, eben

00:10:37.420 --> 00:10:39.260
hierarchische Datenbanken gibt es schon

00:10:39.260 --> 00:10:40.640
ganz lange und

00:10:40.640 --> 00:10:43.680
Sachen in Flatfiles oder irgendwie strukturierten Dateien

00:10:43.680 --> 00:10:44.320
hat man auch schon lange

00:10:44.320 --> 00:10:47.780
und dann irgendwann 1971, glaube ich, ist ein Paper rausgekommen

00:10:47.780 --> 00:10:49.300
von Ted Kott

00:10:49.300 --> 00:10:50.440
und

00:10:50.440 --> 00:10:53.660
der hat sich halt

00:10:53.660 --> 00:10:55.080
Gedanken darüber gemacht, wie man

00:10:55.080 --> 00:10:57.400
eigentlich dieses Problem, ich möchte wissen, irgendwie

00:10:57.400 --> 00:10:59.480
speichern und dann irgendwelche Dinge damit später

00:10:59.480 --> 00:11:01.500
machen, wie man das so grundsätzlich

00:11:01.500 --> 00:11:03.360
eingehen sollte und dessen

00:11:03.360 --> 00:11:05.160
Idee war halt, also

00:11:05.160 --> 00:11:07.260
ein Problem, was er gesehen hat, mit den bisherigen

00:11:07.260 --> 00:11:08.380
Ansätzen war,

00:11:09.540 --> 00:11:10.780
dass viele Leute

00:11:10.780 --> 00:11:12.400
Zeit damit verbracht haben,

00:11:14.020 --> 00:11:15.340
die Daten, die sie

00:11:15.340 --> 00:11:17.040
halt schon auch irgendwie strukturiert, aber halt in

00:11:17.040 --> 00:11:19.380
eigenem Format in Dateien gespeichert haben,

00:11:20.220 --> 00:11:21.420
da

00:11:21.420 --> 00:11:23.140
Algorithmen für zu schreiben, wie die jetzt

00:11:23.140 --> 00:11:25.160
abzufragen sind. Also, wenn man jetzt

00:11:25.160 --> 00:11:26.940
eben so eine Frage beantwortet haben möchte, wie

00:11:26.940 --> 00:11:28.500
keine Ahnung,

00:11:29.220 --> 00:11:31.320
wie viel, was war denn jetzt die Stadt,

00:11:31.560 --> 00:11:33.160
in der es letztes Jahr am kältesten war

00:11:33.160 --> 00:11:34.840
in Deutschland oder so, dann

00:11:34.840 --> 00:11:37.120
fingen Leute an, dann Algorithmen zu schreiben,

00:11:37.300 --> 00:11:38.860
die für die Art, wie sie die Daten

00:11:38.860 --> 00:11:39.800
gespeichert hatten, halt

00:11:39.800 --> 00:11:43.060
ja, das Problem gelöst

00:11:43.060 --> 00:11:43.560
haben, genau.

00:11:45.400 --> 00:11:46.960
Und jeder, der halt die Daten

00:11:46.960 --> 00:11:48.880
irgendwie anders speichert, muss sich halt einen neuen Algorithmus

00:11:48.880 --> 00:11:50.840
überlegen, wie er das macht. Und

00:11:50.840 --> 00:11:52.600
das ist ja eigentlich ziemlich blöde, also das wäre

00:11:52.600 --> 00:11:54.440
irgendwie schlauer, wenn man

00:11:54.440 --> 00:11:56.700
das standardisieren könnte.

00:11:56.700 --> 00:11:58.340
Das standardisieren könnte und also nicht

00:11:58.340 --> 00:12:00.820
sich überlegt, welchen Algorithmus

00:12:00.820 --> 00:12:02.620
oder einen Algorithmus zu schreiben, der halt das irgendwie

00:12:02.620 --> 00:12:04.780
abfragt, sondern zu beschreiben,

00:12:04.860 --> 00:12:06.960
was man haben möchte und dann irgendeine

00:12:06.960 --> 00:12:08.420
Art von Datenbank

00:12:08.420 --> 00:12:10.660
Management System, das dann

00:12:10.660 --> 00:12:12.660
halt weiß, wie man irgendwie diverse Arten von

00:12:12.660 --> 00:12:14.260
Indizes baut oder so, dem diese

00:12:14.260 --> 00:12:17.560
formalisierte

00:12:17.560 --> 00:12:18.900
Anfrage

00:12:18.900 --> 00:12:20.640
vorzulegen und das Ding sucht sich dann die beste

00:12:20.640 --> 00:12:22.640
Art, wie man das dann löst, raus und macht das

00:12:22.640 --> 00:12:23.080
dann für einen.

00:12:24.440 --> 00:12:26.480
Und damit das alles gut geht, muss man halt

00:12:26.480 --> 00:12:28.940
die Daten auch in einem bestimmten Format speichern

00:12:28.940 --> 00:12:30.780
und man sollte die halt in Form von Relationen

00:12:30.780 --> 00:12:31.220
speichern.

00:12:32.420 --> 00:12:41.320
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.

00:12:41.480 --> 00:12:45.440
Weil in unterschiedlichen Spalten oder Zahlen irgendwie unterschiedliche Dinge drinstehen, die dann nichts zu suchen haben, oder?

00:12:45.880 --> 00:12:49.040
Ja, weil sie halt nicht normalisiert sind, weil es nicht so wirkliche...

00:12:49.040 --> 00:12:51.240
Oh, jetzt kommen wir direkt mit den Normalisierungen.

00:12:51.980 --> 00:13:06.080
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.

00:13:06.400 --> 00:13:08.020
Tabellen, die auf Tabellen zeigen oder sowas.

00:13:08.020 --> 00:13:36.660
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.

00:13:37.840 --> 00:13:43.100
Und der hat was mit Datenbanken da zu tun.

00:13:44.220 --> 00:13:47.940
Und da gab es schon jemanden, der sich damit beschäftigt hat,

00:13:48.200 --> 00:13:49.160
also von der Zeitung her,

00:13:50.080 --> 00:13:52.420
wenn es ein Artikel über irgendein Thema Arbeitslosigkeit

00:13:52.420 --> 00:13:55.440
oder keine Ahnung, irgendwas wirtschaftliche Themen irgendwie ging,

00:13:55.860 --> 00:13:58.400
wenn man da Schaubilder und Diagramme reinmachen wollte,

00:13:58.660 --> 00:14:00.200
wo kommen denn die Daten dafür eigentlich her?

00:14:00.300 --> 00:14:02.400
Und der kannte irgendwie in allen Institutionen Leute,

00:14:02.520 --> 00:14:03.920
die er nach diesen Daten fragen konnte,

00:14:04.680 --> 00:14:06.000
wusste, wo man die bekommt und so, super.

00:14:06.940 --> 00:14:25.640
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.

00:14:25.640 --> 00:14:34.120
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.

00:14:34.140 --> 00:14:36.140
da so ein Ordner im Schrank, da kann ich mal blättern.

00:14:37.240 --> 00:14:38.240
Und ich glaube, das ist

00:14:38.240 --> 00:14:39.780
tatsächlich eine Situation, die

00:14:39.780 --> 00:14:41.720
in vielen Unternehmen so ist oder so.

00:14:42.060 --> 00:14:44.040
Dass man halt dann Experten hat

00:14:44.040 --> 00:14:46.020
dafür, für diese

00:14:46.020 --> 00:14:47.820
Domain, aber... Die Menschen aus dem Archiv.

00:14:48.180 --> 00:14:49.600
Ja, die aber dann

00:14:49.600 --> 00:14:51.980
nicht unbedingt jetzt so Datenmarktspezialisten sind

00:14:51.980 --> 00:14:54.180
und die machen dann halt Excel-Files und tun das irgendwo hin.

00:14:55.680 --> 00:14:55.980
Aber das

00:14:55.980 --> 00:14:57.320
funktioniert halt nicht gut, weil

00:14:57.320 --> 00:15:00.240
man hat halt,

00:15:00.720 --> 00:15:02.180
man kann darüber jetzt keine übergreifenden

00:15:02.180 --> 00:15:03.860
Anfragen stellen, dann hat man auch so ein Problem, wenn man

00:15:03.860 --> 00:15:04.940
mit Leuten zusammenarbeitet.

00:15:06.920 --> 00:15:07.940
Ja, wie

00:15:07.940 --> 00:15:09.800
ist das eigentlich, wenn mehrere Leute das jetzt ändern?

00:15:10.000 --> 00:15:11.840
Dann gibt es auch wieder so komische Strategien,

00:15:11.980 --> 00:15:13.860
wie, naja, man hat das dann irgendwie auf einem Netzwerk

00:15:13.860 --> 00:15:15.820
share und dann muss man sich irgendwie Bescheid sagen,

00:15:15.900 --> 00:15:17.900
wenn man das ändert oder man macht das irgendwie

00:15:17.900 --> 00:15:19.800
über komisch benannte Dateinamen oder

00:15:19.800 --> 00:15:21.880
sowas. Und das

00:15:21.880 --> 00:15:23.820
ist natürlich alles total furchtbar. Also man

00:15:23.820 --> 00:15:25.400
benutzt dann im Grunde zwei

00:15:25.400 --> 00:15:27.900
Datenbanken, die nicht wirklich dafür geeignet

00:15:27.900 --> 00:15:29.840
sind, was man da machen möchte, nämlich einmal das Filesystem,

00:15:29.980 --> 00:15:31.660
um halt so eine Art Versionskontrolle zu machen

00:15:31.660 --> 00:15:34.340
und dann Excel als Datenbank, was halt

00:15:34.340 --> 00:15:35.760
auch nicht dafür geeignet ist und dann

00:15:35.760 --> 00:15:37.060
macht man sich das Leben

00:15:37.060 --> 00:15:39.140
sehr, sehr schwer,

00:15:39.760 --> 00:15:41.540
obwohl es deutlich einfacher sein könnte.

00:15:42.860 --> 00:15:44.100
Und ja,

00:15:45.280 --> 00:15:46.340
das sind also aus meiner

00:15:46.340 --> 00:15:47.360
Perspektive auch so die beiden

00:15:47.360 --> 00:15:50.440
Dinge, wo man...

00:15:50.440 --> 00:15:51.860
Wenn man in Firmen

00:15:51.860 --> 00:15:53.600
so leichte Gewinne,

00:15:53.600 --> 00:15:55.480
die man machen könnte, also die

00:15:55.480 --> 00:15:57.740
beiden Themen, die halt vollkommen

00:15:57.740 --> 00:16:00.100
unterschätzt

00:16:00.100 --> 00:16:01.420
sind, aus meiner Perspektive,

00:16:01.660 --> 00:16:03.400
sind einmal Versionskontrolle.

00:16:04.180 --> 00:16:06.060
Also das sehe ich ganz oft,

00:16:06.460 --> 00:16:08.240
dass halt jetzt, also bei Programmierern,

00:16:08.400 --> 00:16:09.480
die wissen inzwischen, wie das

00:16:09.480 --> 00:16:11.340
funktioniert und machen das halt auch.

00:16:11.460 --> 00:16:13.820
Bei denen ist halt Verständnis, was jetzt

00:16:13.820 --> 00:16:15.280
Git ist und wie man das verwendet, irgendwie

00:16:15.280 --> 00:16:16.760
durchaus angekommen.

00:16:17.600 --> 00:16:18.580
Mal bitte den Git-Flow.

00:16:20.200 --> 00:16:20.640
Aber

00:16:20.640 --> 00:16:23.700
in den meisten anderen Abteilungen,

00:16:23.700 --> 00:16:26.180
wo es nicht um Programmieren geht,

00:16:26.440 --> 00:16:27.660
die haben von solchen Dingen noch nie

00:16:27.660 --> 00:16:29.280
irgendwas gehört. Dann nimmt man Tippex und

00:16:29.280 --> 00:16:31.460
malt da kurz die Buchstaben, die falsch sind, raus

00:16:31.460 --> 00:16:33.200
und fahrt dann da drüber. Und wenn man

00:16:33.200 --> 00:16:35.140
wissen will, was da vorher stand, dann muss man das Tipp-Eck abkratzen.

00:16:35.800 --> 00:16:37.200
Ja, die wissen halt vielleicht,

00:16:37.260 --> 00:16:38.520
wie sie ihre Programme bedienen oder so, aber die

00:16:38.520 --> 00:16:41.040
wissen gar nicht, dass sowas geht und wissen

00:16:41.040 --> 00:16:43.160
gar nicht, wie das geht und machen dann

00:16:43.160 --> 00:16:45.200
sehr umständlich das, was

00:16:45.200 --> 00:16:47.080
ihnen arbeitet, sehr

00:16:47.080 --> 00:16:48.440
fehleranfällig, die ihnen geht.

00:16:48.840 --> 00:16:51.240
Tabelle 1, Tabelle 1 neu, Tabelle 1

00:16:51.240 --> 00:16:52.920
neu, neu, neu, final und

00:16:52.920 --> 00:16:54.500
ja, jetzt erst wirklich und

00:16:54.500 --> 00:16:57.080
allerneueste Version. Also da

00:16:57.080 --> 00:16:58.600
könnte man mit wenig Aufwand viel erreichen

00:16:58.600 --> 00:17:00.600
und eben auch da

00:17:00.600 --> 00:17:02.860
irgendwie, wenn man Daten speichert

00:17:02.860 --> 00:17:04.680
und halt auch, man hat ja in

00:17:04.680 --> 00:17:05.700
Excel dann oft nicht nur

00:17:05.700 --> 00:17:08.600
Daten, sondern man hat dann Daten und

00:17:08.600 --> 00:17:10.660
Logik, weil man jetzt irgendwelche Reports erzeugt

00:17:10.660 --> 00:17:12.660
für irgendwie ein Management-Layer oder

00:17:12.660 --> 00:17:14.280
so und dann

00:17:14.280 --> 00:17:16.500
ist das viel Handarbeit, wo

00:17:16.500 --> 00:17:18.660
im Grunde man, wenn man jetzt ein bisschen

00:17:18.660 --> 00:17:20.440
Habt ihr jetzt gerade gehört, das war gerade ein super

00:17:20.440 --> 00:17:22.600
kurzer kleiner Nebensatz, wenn man kurz

00:17:22.600 --> 00:17:24.560
irgendwelche Daten erzeugt, so für den Management-Layer

00:17:24.560 --> 00:17:26.800
Ja, das

00:17:26.800 --> 00:17:28.600
ist denke ich in Grundform, viele Leute da so

00:17:28.600 --> 00:17:30.180
Excel mit irgendwelchen Makros drin oder

00:17:30.180 --> 00:17:32.580
irgendwelche Skript-Schnipseln drin haben,

00:17:33.040 --> 00:17:33.960
warum die das verwenden.

00:17:34.520 --> 00:17:36.400
Das Problem ist halt, das funktioniert

00:17:36.400 --> 00:17:38.340
meistens und dann funktioniert es irgendwann nicht mehr oder

00:17:38.340 --> 00:17:40.120
die Daten ändern sich und dann muss man halt irgendwie

00:17:40.120 --> 00:17:42.300
einen Teil von einem VBA-Skript

00:17:42.300 --> 00:17:44.320
oder so irgendwie so ein bisschen anpassen und dann geht

00:17:44.320 --> 00:17:45.420
was an der anderen Stelle kaputt

00:17:45.420 --> 00:17:48.120
und dann ist es auch so, dass man oft

00:17:48.120 --> 00:17:50.520
Sachen von Hand gefixt hat, also irgendwelche

00:17:50.520 --> 00:17:52.340
Werte sind halt nicht so, wie sie sein sollen und bei Excel klickt man

00:17:52.340 --> 00:17:53.760
dann da rein und dann ändert man den Wert halt

00:17:53.760 --> 00:17:56.560
und dann weiß man aber nicht, dass man das gemacht hat.

00:17:56.840 --> 00:17:58.400
Dann kommen jetzt neue Daten rein, die sind

00:17:58.400 --> 00:18:00.400
wieder falsch und dann muss man es wieder ändern oder

00:18:00.400 --> 00:18:02.520
es geht halt kaputt oder so und

00:18:02.520 --> 00:18:04.460
das ist einfach so aus einer Programmierer-Sicht

00:18:04.460 --> 00:18:05.940
nicht so das, was man tun sollte.

00:18:06.440 --> 00:18:08.520
Man kann damit Stunden um Stunden um Stunden um Stunden

00:18:08.520 --> 00:18:10.360
Genau, aus Programmierer-Sicht ist es so, wenn ich da

00:18:10.360 --> 00:18:12.180
irgendwie was ändere, dann ist das halt

00:18:12.180 --> 00:18:14.360
irgendwie Programmlogik und wenn

00:18:14.360 --> 00:18:16.020
dann neue Daten reinkommen, dann wird die halt genauso

00:18:16.020 --> 00:18:18.120
angewendet und dann muss ich das halt nur einmal hinschreiben

00:18:18.120 --> 00:18:20.320
und dann ist es sozusagen für immer irgendwie gelöst

00:18:20.320 --> 00:18:22.300
und

00:18:22.300 --> 00:18:23.200
ja

00:18:23.200 --> 00:18:25.800
es gibt auch ganz

00:18:25.800 --> 00:18:28.060
in VBAs natürlich noch so ein

00:18:28.060 --> 00:18:30.200
extra Problem. Das soll übrigens bald mit Python

00:18:30.200 --> 00:18:32.200
gehen, habe ich gehört. Ja, ich weiß, dass

00:18:32.200 --> 00:18:34.100
bei Microsoft gibt es irgendwie so ein,

00:18:34.220 --> 00:18:36.200
die haben da auch so ein Priorisierungstool

00:18:36.840 --> 00:18:38.180
sozusagen, ich weiß nicht genau, was das ist

00:18:38.180 --> 00:18:40.140
und ich glaube, das meiste nach

00:18:40.140 --> 00:18:42.160
Requested Feature ist es, VBA durch Python

00:18:42.160 --> 00:18:43.960
zu ersetzen, irgendwie mit irgendwie

00:18:43.960 --> 00:18:44.940
tausenden Upvotes,

00:18:45.420 --> 00:18:48.000
aber ich glaube, definitiv dazu geäußert,

00:18:48.060 --> 00:18:50.100
ob das irgendwie dann kommt, hat sich da auch noch

00:18:50.100 --> 00:18:52.080
niemand, aber das wäre

00:18:52.080 --> 00:18:54.080
natürlich auch eine interessante Geschichte, aber man hat

00:18:54.080 --> 00:18:55.480
auch bei Python dann immer noch das Problem,

00:18:56.120 --> 00:18:57.820
was man halt wahrscheinlich

00:18:57.820 --> 00:18:59.680
nicht machen können wird, ist sowas wie mit PIP

00:18:59.680 --> 00:19:01.560
irgendwie Dinge nachinstallieren oder so, selbst wenn es

00:19:01.560 --> 00:19:03.620
mit Python jetzt die VBA

00:19:03.620 --> 00:19:05.760
ersetzen würde. Gut, man hätte schon

00:19:05.760 --> 00:19:07.500
einen Vorteil dadurch, dass die Standard-Bibliothek von Python

00:19:07.500 --> 00:19:08.540
sehr viel mächtiger ist als das, was

00:19:08.540 --> 00:19:11.840
VBA kann,

00:19:12.000 --> 00:19:13.180
aber es ist halt immer noch nicht,

00:19:13.980 --> 00:19:15.900
also es gibt diverse Probleme, die noch gelöst werden

00:19:15.900 --> 00:19:17.440
müssten, damit das alles so richtig

00:19:17.440 --> 00:19:19.880
smooth ist und das Grundproblem

00:19:19.880 --> 00:19:21.760
ist natürlich, dass Excel das vollkommen ungeeignete Tool

00:19:21.760 --> 00:19:23.340
ist für vieles, was da in dem Bereich gemacht wird.

00:19:24.680 --> 00:19:25.240
Ja, aber

00:19:25.240 --> 00:19:26.680
genau, also

00:19:26.680 --> 00:19:31.480
genau, also eigentlich wäre das, was

00:19:31.480 --> 00:19:33.380
viele Leute damit machen, die werden

00:19:33.380 --> 00:19:35.220
viel besser bedient, wenn sie halt Python

00:19:35.220 --> 00:19:36.760
nehmen würden und eine relationale Datenbank

00:19:36.760 --> 00:19:38.220
und

00:19:38.220 --> 00:19:41.140
weil die eben diese ganzen

00:19:41.140 --> 00:19:43.120
Geschichten auch löst. Da gibt es dann halt, wenn

00:19:43.120 --> 00:19:45.040
mehrere Leute drauf zugreifen und Dinge ändern,

00:19:45.360 --> 00:19:47.140
dann sorgt die Datenbank dafür,

00:19:47.320 --> 00:19:48.580
oder das Datenbankmanagementsystem,

00:19:49.300 --> 00:19:50.140
dass da nichts schief geht,

00:19:51.160 --> 00:19:52.320
dass alle Leute immer die gleichen

00:19:52.320 --> 00:19:55.020
Daten sehen, jedenfalls innerhalb von einer Transaktion

00:19:55.020 --> 00:19:56.400
und so und

00:19:56.400 --> 00:19:59.160
da gibt es

00:19:59.160 --> 00:20:01.100
auch die ganze Zugriffskontrolle und all das

00:20:01.100 --> 00:20:02.960
ist alles schon fertig implementiert

00:20:02.960 --> 00:20:04.520
und

00:20:04.520 --> 00:20:06.960
ja, das ist halt so das, was Leute

00:20:06.960 --> 00:20:08.220
im Grunde verstehen, wenn sie

00:20:08.220 --> 00:20:10.960
wenn man von Datenbanken spricht

00:20:10.960 --> 00:20:11.920
denke ich

00:20:11.920 --> 00:20:15.000
aber es gibt halt auch noch eine ganze Menge

00:20:15.000 --> 00:20:16.700
anderer Datenbanken und dass sich

00:20:16.700 --> 00:20:18.960
relationale Datenbanken so durchgesetzt haben, ist auch

00:20:18.960 --> 00:20:20.980
aus meiner Perspektive ein Stück weit

00:20:20.980 --> 00:20:23.000
Glück oder hängt halt an der

00:20:23.000 --> 00:20:25.000
Geschichte von einzelnen Firmen, also man

00:20:25.000 --> 00:20:26.860
hätte sich auch durchaus vorstellen können, dass sie andere Paradigmen

00:20:26.860 --> 00:20:28.940
durchgesetzt hätten, haben sie

00:20:28.940 --> 00:20:29.680
aber irgendwie nicht.

00:20:31.020 --> 00:20:32.520
Und jetzt sind halt so

00:20:32.520 --> 00:20:34.820
relationelle Datenbanken das, was alle irgendwie

00:20:34.820 --> 00:20:36.960
verwenden. Aber es ist auch

00:20:36.960 --> 00:20:38.400
gar nicht so ein schlechter Ansatz. Insofern

00:20:38.400 --> 00:20:40.820
kann man damit eigentlich ganz gut leben.

00:20:41.320 --> 00:20:42.080
Aber nur mal so um

00:20:42.080 --> 00:20:44.320
der Vollständigkeit halber,

00:20:44.360 --> 00:20:46.800
um mal zu sagen, was es sonst noch alles gibt.

00:20:47.340 --> 00:20:47.820
Es gibt halt

00:20:47.820 --> 00:20:50.820
Dokumentendatenbanken, ja, gibt es auch schon

00:20:50.820 --> 00:20:52.920
ganz lange. Lotus Notes

00:20:52.920 --> 00:20:54.080
ist ja so ein Beispiel für

00:20:54.080 --> 00:20:56.220
ist ja früher Microsoft

00:20:56.220 --> 00:20:57.760
auch ganz populär.

00:20:59.760 --> 00:21:00.280
CouchDB,

00:21:00.800 --> 00:21:01.700
MongoDB, die

00:21:01.700 --> 00:21:03.900
fallen auch in diesen

00:21:03.900 --> 00:21:06.320
Dokument-Datenbank-Bereich rein,

00:21:06.440 --> 00:21:07.840
lösen halt so ein bisschen unterschiedliche Probleme.

00:21:08.380 --> 00:21:09.560
CouchDB löst so ein bisschen

00:21:09.560 --> 00:21:11.720
das Problem, dass ich

00:21:11.720 --> 00:21:14.360
nicht unbedingt

00:21:14.360 --> 00:21:16.240
in einen zentralen Master

00:21:16.240 --> 00:21:18.120
immer reinschreiben will,

00:21:18.300 --> 00:21:20.000
weil der halt auch weg sein kann, wenn ich zum Beispiel

00:21:20.000 --> 00:21:21.680
offline bin oder so, dann kann ich halt nicht

00:21:21.680 --> 00:21:23.940
da reinschreiben.

00:21:24.080 --> 00:21:26.540
sondern muss dann halt eventuell erst lokal schreiben

00:21:26.540 --> 00:21:27.760
und dann irgendwie die

00:21:27.760 --> 00:21:30.420
Daten synchronisieren hinterher

00:21:30.420 --> 00:21:32.120
und das macht CouchDB sehr schlau.

00:21:32.640 --> 00:21:34.540
Verwendet tatsächlich auch einen Algorithmus, der aus dem

00:21:34.540 --> 00:21:36.600
Lotus Notes-Dings-Projekt kommt.

00:21:38.560 --> 00:21:40.680
Es gibt Key-Value-Stores,

00:21:40.780 --> 00:21:41.520
wo man einfach nur

00:21:41.520 --> 00:21:44.420
irgendeinen Hash irgendwie, also man kann

00:21:44.420 --> 00:21:45.620
sich das vorstellen wie ein Python-Dict,

00:21:46.620 --> 00:21:48.340
wo man halt irgendwelche Keys hat

00:21:48.340 --> 00:21:50.280
und dann hat man irgendwelche Werte, die man dann zurückbekommt,

00:21:50.320 --> 00:21:51.180
wenn man den Key dahin schickt.

00:21:52.320 --> 00:21:53.880
Darunter fallen so Sachen wie Redis

00:21:53.880 --> 00:21:56.000
oder Memcached oder so

00:21:56.000 --> 00:21:57.840
oft zum Cachen verwendet, aber manchmal können sie auch

00:21:57.840 --> 00:21:59.720
kompliziertere Sachen oder weiter

00:21:59.720 --> 00:22:01.880
strukturierte Daten. BerkeleyDB war

00:22:01.880 --> 00:22:04.120
lange ganz groß, wird heute gar nicht mehr so sehr verwendet.

00:22:05.300 --> 00:22:06.040
Ja, aber auch sowas

00:22:06.040 --> 00:22:08.080
wie Amazon Dynamo

00:22:08.080 --> 00:22:09.480
oder so fällt da auch drunter.

00:22:10.140 --> 00:22:11.780
Und dann gibt es halt noch so spaltenorientierte

00:22:11.780 --> 00:22:13.720
Datenbanken, wobei ich auch da sagen würde, es gibt

00:22:13.720 --> 00:22:14.940
zwei unterschiedliche Arten, aber

00:22:14.940 --> 00:22:17.680
halt sowas wie Bigtable, wo Google

00:22:17.680 --> 00:22:19.580
einen Index drin speichert oder das

00:22:19.580 --> 00:22:21.200
entsprechende Hadoop-Äquivalent

00:22:21.200 --> 00:22:23.080
oder das Äquivalent aus dem Hadoop-Ökosystem,

00:22:23.220 --> 00:22:23.640
HBase.

00:22:25.440 --> 00:22:26.740
Die Dinger sind halt dafür gedacht,

00:22:26.920 --> 00:22:28.580
gigantische Datenmengen irgendwie

00:22:28.580 --> 00:22:31.140
zu speichern und

00:22:31.140 --> 00:22:33.080
das halt machen sie

00:22:33.080 --> 00:22:34.740
dann irgendwie eher so spaltbasiert.

00:22:35.120 --> 00:22:36.880
Cassandra, Apache Cassandra ist auch so ein Projekt, das das

00:22:36.880 --> 00:22:39.320
genauso macht. Dann ein komplett

00:22:39.320 --> 00:22:41.660
anderes Paradigma sind Grafendatenbanken,

00:22:42.940 --> 00:22:43.660
wo man

00:22:43.660 --> 00:22:45.500
Daten eben nicht in Tabellen speichert,

00:22:45.540 --> 00:22:47.000
sondern man speichert eher

00:22:47.000 --> 00:22:49.500
Knoten und Kanten und

00:22:49.500 --> 00:22:50.840
die Relationen zwischen den

00:22:50.840 --> 00:22:53.220
Daten sind halt nicht dadurch dargestellt, dass man

00:22:53.220 --> 00:22:54.980
jetzt halt irgendwie Zeilen in einer

00:22:54.980 --> 00:22:55.900
Tabelle hat, sondern

00:22:55.900 --> 00:22:59.040
dadurch, dass man halt beliebige

00:22:59.040 --> 00:23:01.260
Beziehungen im Grunde zwischen

00:23:01.260 --> 00:23:03.280
Knoten irgendwie hat, das ist jetzt ein bisschen

00:23:03.280 --> 00:23:05.320
abstrakt, weiß ich auch gar nicht genau, wie ich das erklären,

00:23:05.580 --> 00:23:06.880
vielleicht kann man das nachher nochmal

00:23:06.880 --> 00:23:08.580
im praktischen Beispiel ein bisschen besser erläutern.

00:23:08.580 --> 00:23:12.720
Ja, genau, aber das ist halt

00:23:12.720 --> 00:23:14.620
so eine ganz andere Art von

00:23:14.620 --> 00:23:16.700
Datenbanken, die aber auch, also da würde

00:23:16.700 --> 00:23:18.560
ich sagen, das hätte auch sich anstelle von relationalen

00:23:18.560 --> 00:23:19.780
Datenbanken durchsetzen können.

00:23:20.600 --> 00:23:33.500
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.

00:23:34.960 --> 00:23:36.880
Okay, Semantik-Web, ja, machen wir später.

00:23:36.880 --> 00:23:50.580
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.

00:23:50.600 --> 00:23:51.900
TimescaleDB

00:23:51.900 --> 00:23:54.620
oder halt sowieso

00:23:54.620 --> 00:23:56.580
für, du hast halt ein bestimmtes Problem

00:23:56.580 --> 00:23:57.740
wie, du möchtest dieses

00:23:57.740 --> 00:24:00.480
bei Google sieht man, Google Suggest hieß das

00:24:00.480 --> 00:24:02.460
Feature, wenn man Google Query

00:24:02.460 --> 00:24:04.300
eingibt, dann werden einem so Vorschläge gemacht.

00:24:05.140 --> 00:24:05.880
Dafür braucht man halt

00:24:05.880 --> 00:24:07.700
spezielle Art

00:24:07.700 --> 00:24:10.360
das zu indizieren, das ist Suffix Trees

00:24:10.360 --> 00:24:11.620
und

00:24:11.620 --> 00:24:14.240
das kann ja, ja

00:24:14.240 --> 00:24:16.500
dafür gibt es dann auch wieder spezielle Server

00:24:16.500 --> 00:24:17.600
mit denen man das machen kann und so.

00:24:18.280 --> 00:24:20.160
Und das wäre jetzt etwas, was man sonst halt nicht so braucht.

00:24:20.260 --> 00:24:21.540
Es gibt halt für bestimmte Anwendungsfälle

00:24:21.540 --> 00:24:22.880
gibt es sowas halt, aber

00:24:22.880 --> 00:24:25.320
ja, ist jetzt, und manchmal

00:24:25.320 --> 00:24:26.860
sind solche Funktionen auch in

00:24:26.860 --> 00:24:29.580
so verbreiterten

00:24:29.580 --> 00:24:31.400
Datenbanken enthalten, aber es gibt halt

00:24:31.400 --> 00:24:32.700
auch mal spezialisierte Geschichten dafür.

00:24:34.920 --> 00:24:35.080
Ja.

00:24:35.600 --> 00:24:37.300
Vielleicht die ganzen Basissachen werden noch komplett

00:24:37.300 --> 00:24:38.560
nicht kurz erwähnt.

00:24:39.480 --> 00:24:41.020
Keine Ahnung, MySQL

00:24:41.020 --> 00:24:43.180
oder Postgres. Achso, das sind, ja genau,

00:24:43.220 --> 00:24:45.180
das sind Beispiele für relationale Datenbanken.

00:24:46.560 --> 00:24:47.420
Ja, MySQL,

00:24:47.860 --> 00:24:49.620
Postgres, das wären jetzt die Open-Source-Vertreter.

00:24:50.260 --> 00:24:52.480
Oracle und

00:24:52.480 --> 00:24:54.160
MSSQL-Server,

00:24:54.280 --> 00:24:55.800
Sybase, das wären so die kommerziellen

00:24:55.800 --> 00:24:57.100
Geschichten.

00:24:57.920 --> 00:24:59.640
DB2 von IBM.

00:25:01.220 --> 00:25:02.240
Oder zur Historie,

00:25:02.520 --> 00:25:03.400
im Grunde die,

00:25:04.860 --> 00:25:06.260
nachdem dieses Paper

00:25:06.260 --> 00:25:08.260
irgendwie, das sollte man

00:25:08.260 --> 00:25:09.940
in die Schonungs packen, das ist sehr empfehlenswert, das nicht mal

00:25:09.940 --> 00:25:12.100
zu lesen von Headquart. Der hat damals bei

00:25:12.100 --> 00:25:13.600
IBM gearbeitet

00:25:13.600 --> 00:25:16.160
und da ist

00:25:16.160 --> 00:25:18.140
ein System daraus entstanden, das nennt sich System R.

00:25:19.600 --> 00:25:31.860
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.

00:25:31.860 --> 00:25:40.680
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.

00:25:41.020 --> 00:25:43.560
Und dabei ist was rausgekommen namens Ingress.

00:25:44.660 --> 00:25:46.820
Michael Stonebreaker war das damals.

00:25:47.100 --> 00:25:51.740
Und das war am Anfang noch gar keine Datenbank für beliebige Daten,

00:25:51.820 --> 00:25:52.880
sondern das war für Bilder irgendwie.

00:25:53.800 --> 00:25:56.420
Und dann ist das Ganze zu Postgres geworden

00:25:56.420 --> 00:26:01.300
und wurde dann zu einer normalen, relationalen Datenbank sozusagen.

00:26:04.860 --> 00:26:06.540
Und das ist auch faszinierend.

00:26:06.660 --> 00:26:09.020
Also dieses ganze Postgres-Projekt ist der Wahnsinn eigentlich.

00:26:09.280 --> 00:26:11.220
hat halt irgendwie Mitte der 80er

00:26:11.220 --> 00:26:13.080
ist das gestartet oder

00:26:13.080 --> 00:26:15.040
halt, wenn man Ingress dazu zählt, noch früher

00:26:15.040 --> 00:26:16.980
und

00:26:16.980 --> 00:26:18.840
ist jetzt über 30 Jahre wahrscheinlich

00:26:18.840 --> 00:26:21.280
hat das auch einen Buckel

00:26:21.280 --> 00:26:22.560
und ist immer noch

00:26:22.560 --> 00:26:25.420
top und set of the art

00:26:25.420 --> 00:26:27.020
immer noch dabei, es kommen immer noch tolle Sachen dazu.

00:26:28.200 --> 00:26:28.300
Ist

00:26:28.300 --> 00:26:31.120
wahrscheinlich auch so die,

00:26:31.540 --> 00:26:33.540
sie nennen sich selber irgendwie die

00:26:33.540 --> 00:26:35.660
ich weiß gar nicht,

00:26:35.660 --> 00:26:37.020
wie ich das übersetzen soll, Advanteste,

00:26:37.980 --> 00:26:40.640
Die fortschrittlichste Open-Source-Datenbank,

00:26:40.740 --> 00:26:42.300
ja. Gut, Oracle und so

00:26:42.300 --> 00:26:44.300
hat wahrscheinlich noch ein bisschen mehr Funktionen, aber

00:26:44.300 --> 00:26:45.780
ja,

00:26:46.140 --> 00:26:48.500
tatsächlich wird meistens

00:26:48.500 --> 00:26:50.620
aber, wahrscheinlich aus Kostengründen,

00:26:51.400 --> 00:26:52.500
tatsächlich jetzt so

00:26:52.500 --> 00:26:54.400
im Internetumfeld irgendwie dann meistens werden so

00:26:54.400 --> 00:26:55.500
Open-Source-Datenbanken verwendet.

00:26:57.560 --> 00:26:58.000
Ja,

00:26:58.080 --> 00:27:00.340
ich habe schon mal gesehen, dass Leute Oracle verwenden,

00:27:00.340 --> 00:27:01.520
aber das ist eher selten.

00:27:02.880 --> 00:27:03.500
Jetzt so als

00:27:03.500 --> 00:27:06.020
Backend für Webseiten

00:27:06.020 --> 00:27:07.800
verwendet man normalerweise nicht. Oracle ist halt auch

00:27:07.800 --> 00:27:09.780
viel zu teuer. Oder

00:27:09.780 --> 00:27:11.800
MSSQL-Server, doch, das gibt es tatsächlich

00:27:11.800 --> 00:27:13.520
Leute, die das als Backend für

00:27:13.520 --> 00:27:14.780
Webseiten verwenden.

00:27:16.180 --> 00:27:17.960
Ein Beispiel

00:27:17.960 --> 00:27:19.480
einer populären Seite, die halt auf

00:27:19.480 --> 00:27:21.400
MSSQL-Server läuft, ist

00:27:21.400 --> 00:27:23.700
Stack Overflow. Das ist auch

00:27:23.700 --> 00:27:24.560
faszinierend.

00:27:26.000 --> 00:27:26.620
Ich meine, einer der

00:27:26.620 --> 00:27:29.300
ich weiß nicht, ob es

00:27:29.300 --> 00:27:31.860
der Gründer selber war, der war auch

00:27:31.860 --> 00:27:33.340
Produktmanager bei Microsoft, glaube ich, insofern

00:27:33.340 --> 00:27:35.240
die machen viel auf dem Microsoft-Stack

00:27:35.240 --> 00:27:37.300
und holen da unglaubliche Sachen raus.

00:27:37.480 --> 00:27:38.980
Also die haben irgendwie ein halbes Rack oder

00:27:38.980 --> 00:27:41.200
das ist jetzt auch schon lange her, dass ich

00:27:41.200 --> 00:27:42.740
da irgendwie Artikel zu gelesen habe, aber

00:27:42.740 --> 00:27:44.780
das letzte Mal, dass ich das gesehen habe, war

00:27:44.780 --> 00:27:46.780
Stack Overflow tatsächlich unter den Top Ten

00:27:46.780 --> 00:27:49.360
der trafficstärksten Webseiten

00:27:49.360 --> 00:27:51.140
weltweit und die haben

00:27:51.140 --> 00:27:53.140
dafür, Hardware war irgendwie so ein halbes Rack

00:27:53.140 --> 00:27:55.140
oder so. Und das ist natürlich schon

00:27:55.140 --> 00:27:57.060
extrem beeindruckend. Und das ist überhaupt so was,

00:27:57.140 --> 00:27:59.020
was halt wahrscheinlich viele Leute nicht wissen,

00:27:59.540 --> 00:28:01.200
die jetzt nicht so viel Erfahrung haben mit Datenbanken,

00:28:01.300 --> 00:28:03.080
die können echt wahnsinnig

00:28:03.080 --> 00:28:03.380
viel

00:28:03.380 --> 00:28:05.840
Dinge tun

00:28:05.840 --> 00:28:08.260
gleichzeitig und so. Also man kriegt aus so einer

00:28:08.260 --> 00:28:10.640
ordentlich konfigurierten und getunten

00:28:10.640 --> 00:28:12.380
relationalen Datenbank

00:28:12.380 --> 00:28:14.080
schon so mindestens ein paar tausend,

00:28:14.200 --> 00:28:16.000
vielleicht auch ein paar zehntausend Requests

00:28:16.000 --> 00:28:18.280
oder Statements pro Sekunde raus, die die halt verarbeiten

00:28:18.280 --> 00:28:20.000
können. Und dann kann man natürlich eine Menge

00:28:20.000 --> 00:28:20.560
machen.

00:28:21.120 --> 00:28:28.400
Also vorausgesetzt der ganze Kram passt in den Hauptsprecher.

00:28:30.980 --> 00:28:32.200
Aber man macht keine Dinge, die

00:28:32.200 --> 00:28:34.220
das irgendwie langsam machen. Also es ist halt auch nicht so einfach,

00:28:34.300 --> 00:28:34.900
das zu optimieren, aber

00:28:34.900 --> 00:28:38.380
ja, genau. Und das ist halt

00:28:38.380 --> 00:28:40.080
auch dieser Bereich der relationalen Datenbank, ist halt

00:28:40.080 --> 00:28:42.240
der größte Datenbankbereich eigentlich.

00:28:43.880 --> 00:28:44.460
Ja, vielleicht

00:28:44.460 --> 00:28:46.340
können wir dann, wollen wir zu dem praktischen

00:28:46.340 --> 00:28:48.320
Beispiel. Ja, super. Wie macht man das jetzt alles

00:28:48.320 --> 00:28:50.460
und wie baut man das auf und warum und

00:28:50.460 --> 00:28:52.260
was kann man damit so schönes machen und

00:28:52.260 --> 00:28:54.580
was für Probleme könnten wir darüber stolpern und sowas.

00:28:55.420 --> 00:28:56.040
Ja, dann

00:28:56.040 --> 00:28:58.020
nehmen wir doch mal an, wir wollen jetzt

00:28:58.020 --> 00:29:00.260
Amazon nachbauen. Wir haben einen

00:29:00.260 --> 00:29:01.600
kleinen Buchhandel in der Garage.

00:29:02.200 --> 00:29:20.160
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.

00:29:21.020 --> 00:29:24.760
Wie fangen wir jetzt mal an, vielleicht reden wir kurz über das Schema, wie man sowas aufbaut nochmal kurz.

00:29:25.000 --> 00:29:42.660
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.

00:29:42.820 --> 00:29:45.140
Durchschnittliche Anzahl von Buchstaben pro Seite.

00:29:45.860 --> 00:30:01.320
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 …

00:30:01.320 --> 00:30:02.980
Der Autor sich umbenimmt, weil er heiratet oder so?

00:30:02.980 --> 00:30:24.640
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.

00:30:24.640 --> 00:30:38.760
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?

00:30:39.100 --> 00:31:08.900
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.

00:31:09.100 --> 00:31:11.520
Und dann brauchen wir ja noch eine andere Tabelle Autorix,

00:31:11.620 --> 00:31:13.560
wo dann alle Autorinnen drinstehen.

00:31:14.060 --> 00:31:14.260
Ja,

00:31:14.960 --> 00:31:17.540
wäre auch eine Möglichkeit, genau.

00:31:19.420 --> 00:31:19.740
Und

00:31:19.740 --> 00:31:21.800
ich

00:31:21.800 --> 00:31:22.400
überlege gerade,

00:31:23.800 --> 00:31:25.360
das ist jetzt natürlich, also

00:31:25.360 --> 00:31:27.620
Autoren, ein Beispiel, anderes Beispiel wäre User,

00:31:27.720 --> 00:31:29.700
die jetzt auf der Webseite irgendwas einkaufen wollen oder so.

00:31:30.260 --> 00:31:31.720
Da würde man in der Bestellung halt

00:31:31.720 --> 00:31:33.540
auch nicht den User selber irgendwie

00:31:33.540 --> 00:31:35.640
in jede Bestellung schreiben, sondern halt

00:31:35.640 --> 00:31:37.660
irgendwie die ID von dem User, der

00:31:37.660 --> 00:31:39.840
irgendwas eingekauft hat und

00:31:39.840 --> 00:31:43.980
im Grunde, also ja, das heißt

00:31:43.980 --> 00:31:45.720
Datenbank-Normalisierung, wenn man jetzt

00:31:45.720 --> 00:31:47.880
dafür sorgt, es erinnert so ein bisschen

00:31:47.880 --> 00:31:49.960
an, wenn man Software schreibt, nennt sich das

00:31:49.960 --> 00:31:52.020
DRY, so Don't Repeat Yourself,

00:31:52.140 --> 00:31:53.420
also wenn man Software schreibt, sollte man auch

00:31:53.420 --> 00:31:55.820
Funktionalität, die man an mehreren Stellen verwendet, halt

00:31:55.820 --> 00:31:57.760
nicht an mehreren Stellen implementiert haben, weil

00:31:57.760 --> 00:31:59.480
wenn man das an einer Stelle ändert und

00:31:59.480 --> 00:32:00.900
vergisst es halt an der anderen, dann hat man halt

00:32:00.900 --> 00:32:03.940
ja, einmal ist es

00:32:03.940 --> 00:32:04.800
dann inkonsistent, das Verhalten,

00:32:05.820 --> 00:32:11.200
Und ja, man hat halt auch die Gefahr, dass Dinge, die man einmal gefixt hat, dann nochmal auftauchen.

00:32:11.620 --> 00:32:13.060
Das ist doch bestimmt schon einmal passiert, oder?

00:32:13.120 --> 00:32:15.660
Also mir hat das früher ständig passiert und dann ist mir irgendwann aufgefallen,

00:32:15.720 --> 00:32:17.820
oh, ich mache eine Funktion und dann mache ich die Funktion auch.

00:32:17.840 --> 00:32:20.900
Dann macht man eine Funktion und dann macht man einen Test und dann ist es halt erledigt, sozusagen.

00:32:21.560 --> 00:32:25.660
Also sollte man halt möglichst versuchen, Dinge, die man, so Logik, die irgendwo ist,

00:32:25.720 --> 00:32:27.080
halt immer nur einmal irgendwo stehen zu haben.

00:32:27.140 --> 00:32:30.060
Ist natürlich manchmal nicht so ganz einfach und ist bei Datenbanken halt auch nicht,

00:32:30.180 --> 00:32:32.880
weil das beißt sich so ein bisschen mit anderen Anforderungen, die man hat.

00:32:32.880 --> 00:32:51.140
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.

00:32:52.140 --> 00:33:00.680
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.

00:33:01.140 --> 00:33:02.560
So ein bisschen wie an so einem Spielautomaten.

00:33:02.660 --> 00:33:04.380
Wenn ihr so einen einarmigen Banditen habt,

00:33:04.440 --> 00:33:06.180
dann zieht ihr einmal dran, da sind ja so drei verschiedene

00:33:06.180 --> 00:33:08.220
und wenn ihr dann parallel sind und alles zeigt, gewinnen,

00:33:08.800 --> 00:33:09.920
dann habt ihr den Schlüssel, den ihr braucht.

00:33:11.320 --> 00:33:12.980
Dann hat man die Zeile

00:33:12.980 --> 00:33:14.740
von dem Schlüssel irgendwie zusammengeführt.

00:33:14.880 --> 00:33:15.000
Ja, genau.

00:33:17.940 --> 00:33:18.260
Ja.

00:33:20.140 --> 00:33:20.460
Also

00:33:20.460 --> 00:33:22.440
das ist halt auch, wie man ein Schema

00:33:22.440 --> 00:33:23.600
designt und so, das ist halt so ein bisschen

00:33:23.600 --> 00:33:26.220
Kunst und man braucht Erfahrung dafür.

00:33:28.720 --> 00:33:29.040
Aber

00:33:29.040 --> 00:33:30.200
man kann halt sagen, ja,

00:33:30.480 --> 00:33:32.300
man sollte das so ein bisschen normalisieren. Also meistens

00:33:32.300 --> 00:33:34.140
gibt es dann ganz viele unterschiedliche Normalformen

00:33:34.140 --> 00:33:36.400
und meistens die Formen,

00:33:36.400 --> 00:33:38.140
die man dann so hat, ist so irgendwas zwischen dritter

00:33:38.140 --> 00:33:39.660
und vierter Normalform oder so,

00:33:39.980 --> 00:33:42.280
zwischen dritter und Boy-Scout-Normalform oder sowas. Aber ich möchte

00:33:42.280 --> 00:33:44.180
gar nicht so sehr im Detail darauf eingehen, was

00:33:44.180 --> 00:33:45.640
jetzt der Unterschied zwischen den Normalformen sind.

00:33:46.480 --> 00:33:48.400
Irgendwie kann man sich auch durchlesen auf Wikipedia oder so.

00:33:48.580 --> 00:33:50.260
Braucht man auch im Alltag eigentlich gar nicht zu

00:33:50.260 --> 00:33:52.200
wissen, sondern da hat man dann halt irgendwann

00:33:52.200 --> 00:33:54.160
ein Gefühl dafür, wenn

00:33:54.160 --> 00:33:55.760
ein Datenbankschema okay aussieht.

00:33:57.360 --> 00:33:58.260
Und dann macht man das halt so.

00:33:58.880 --> 00:34:00.360
Das heißt, ich gehe jetzt tatsächlich erstmal hin

00:34:00.360 --> 00:34:02.420
und nimm ein Whiteboard, einen Zettel

00:34:02.420 --> 00:34:04.400
und schreib mir auf, wie die Daten aussehen

00:34:04.400 --> 00:34:06.720
sollen. Ja, ja, tatsächlich. Also wenn ich

00:34:06.720 --> 00:34:08.500
irgendwie eine Datenbank

00:34:08.500 --> 00:34:09.960
designe für irgendein Projekt, dann

00:34:09.960 --> 00:34:12.480
nehme ich mir einen Zettel und fange an

00:34:12.480 --> 00:34:14.540
Entity Relationship

00:34:14.540 --> 00:34:16.140
Diagramme zu malen. So nennt man die.

00:34:16.460 --> 00:34:18.360
Was passiert denn später, wenn ich während dem Projekt

00:34:18.360 --> 00:34:20.280
merke, hey, ich habe aber die und die Daten

00:34:20.280 --> 00:34:22.340
vergessen? Bastel ich da einfach

00:34:22.340 --> 00:34:24.500
irgendwo rein? Ergänze ich dann dieses Schema einfach?

00:34:25.100 --> 00:34:25.500
Ja,

00:34:25.820 --> 00:34:28.040
das kommt darauf an, was das dann für eine Änderung ist.

00:34:28.040 --> 00:34:29.220
Das ist auch so ein Problem.

00:34:29.800 --> 00:34:35.520
Man kann Datenbanken nicht so richtig super ändern.

00:34:36.260 --> 00:34:37.740
Also relationelle Datenbanken.

00:34:38.460 --> 00:34:39.740
Das Schema lässt sich schon ändern,

00:34:39.960 --> 00:34:42.180
aber das ist halt so ein bisschen knifflig.

00:34:42.180 --> 00:34:45.180
Und wenn man das tut, muss man halt irgendwie aufpassen.

00:34:45.420 --> 00:34:48.000
Dass das alte Datenbanken noch kompatibel sind oder sowas, oder?

00:34:48.980 --> 00:34:50.760
Ja, dass man das so ändert,

00:34:51.140 --> 00:34:53.320
dass nicht irgendwelche Inkonsistenzen entstehen.

00:34:53.480 --> 00:34:54.780
Und auch, dass halt...

00:34:54.780 --> 00:34:56.240
Wie wäre das jetzt bei unserem Beispielbeispiel?

00:34:58.340 --> 00:34:59.520
Also wenn ich mir jetzt überlege,

00:34:59.600 --> 00:35:01.620
ich brauche jetzt eine neue Spalte in dieser

00:35:01.620 --> 00:35:02.900
Büchertabelle, ja, weiß ich nicht,

00:35:03.560 --> 00:35:05.160
es gibt jetzt nicht nur die ESPN.

00:35:05.280 --> 00:35:07.480
Aber vom Cover, jemand, oder das

00:35:07.480 --> 00:35:09.660
Genre oder sowas, jemand sammelt Seefahrerbücher.

00:35:10.120 --> 00:35:11.480
Ja, eine Kategorie, da würde ich halt

00:35:11.480 --> 00:35:13.520
tatsächlich, also das, was man sich zuerst überlegen könnte,

00:35:13.640 --> 00:35:14.340
ist, man macht einfach

00:35:14.340 --> 00:35:17.160
ein Textfeld oder

00:35:17.160 --> 00:35:18.980
Charfield, das halt

00:35:18.980 --> 00:35:20.980
den Kategorienamen enthält

00:35:20.980 --> 00:35:23.500
und dann hat man halt

00:35:23.500 --> 00:35:25.000
das Problem, okay, dann stellt man fest,

00:35:25.300 --> 00:35:27.300
oder am besten noch,

00:35:27.400 --> 00:35:28.320
okay, fangen wir so an,

00:35:28.960 --> 00:35:31.740
man schreibt halt, man nimmt Text

00:35:31.740 --> 00:35:33.640
statt Kategorie

00:35:33.640 --> 00:35:34.980
und sagt jetzt,

00:35:35.760 --> 00:35:38.160
okay, alle Texts, also weiß ich nicht,

00:35:38.840 --> 00:35:39.880
Militristik,

00:35:40.040 --> 00:35:41.440
Komba, Seefahrer Roman oder

00:35:41.440 --> 00:35:44.080
Komba, schreibt man jetzt Komba separiert

00:35:44.080 --> 00:35:45.860
halt in eine Spalte rein,

00:35:46.280 --> 00:35:47.940
dann hat man damit die erste Normalform verletzt

00:35:47.940 --> 00:35:50.040
und man muss sich dann im nächsten

00:35:50.040 --> 00:35:51.840
Schritt, wenn man das halt weiter normalisiert, überlegen,

00:35:51.940 --> 00:35:54.120
okay, nee, das geht nicht, darf ich so nicht machen?

00:35:55.360 --> 00:35:56.100
Also der eigentliche Grund,

00:35:56.160 --> 00:35:57.440
warum man das nicht machen sollte, ist halt, dass es

00:35:57.440 --> 00:35:59.600
diverse Anfragen halt schwierig macht

00:35:59.600 --> 00:36:01.460
und dass man es auch sehr schlecht ändern kann

00:36:01.460 --> 00:36:03.220
und dass wenn man was ändern kann, man Sachen kaputt machen,

00:36:04.180 --> 00:36:04.860
weil

00:36:04.860 --> 00:36:07.180
Inkonsistenzen entstehen können und so.

00:36:09.820 --> 00:36:11.160
Dann zieht man erst mal

00:36:11.160 --> 00:36:13.400
diese Dinger auseinander und sagt halt,

00:36:13.480 --> 00:36:15.460
okay, nicht in einer Spalte

00:36:15.460 --> 00:36:19.640
mehrere Tags reinschreiben,

00:36:19.760 --> 00:36:21.240
sondern dann hätte man sozusagen

00:36:21.240 --> 00:36:23.340
eine End-to-End-Relation, also nicht nur,

00:36:23.520 --> 00:36:25.420
wo ein Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel

00:36:25.420 --> 00:36:27.440
in eine andere Tabelle passt, sondern man hat

00:36:27.440 --> 00:36:29.400
dazwischen eine Link-Tabelle. Man hat jetzt einmal Tags

00:36:29.400 --> 00:36:31.480
als Relation und einmal halt die Bücher

00:36:31.480 --> 00:36:33.700
als Relation oder als Tabellen halt

00:36:33.700 --> 00:36:35.700
und dazwischen hat man jetzt noch eine Link-Tabelle

00:36:35.700 --> 00:36:37.320
zwischen oder Link-Relation zwischen

00:36:37.320 --> 00:36:39.560
Büchern und Tags, sodass

00:36:39.560 --> 00:36:41.600
man mehrere, also für jedes Tag hätte man

00:36:41.600 --> 00:36:43.480
dann sozusagen einen Eintrag in der Link-Tabelle,

00:36:43.960 --> 00:36:44.800
wo dann drin steht

00:36:44.800 --> 00:36:46.640
ID von diesem Buch,

00:36:47.400 --> 00:36:49.680
ID von diesem Tag. Ja, und das ist dann halt

00:36:49.680 --> 00:36:51.500
sozusagen der, die

00:36:51.500 --> 00:36:53.080
Verbindung zwischen den beiden Tabellen,

00:36:53.360 --> 00:36:54.900
sondern halt eine Tabelle mit allen Texten.

00:36:55.020 --> 00:36:56.080
Die ist möglicherweise gar nicht so lang.

00:36:56.160 --> 00:36:57.520
Es gibt vielleicht nur 1.000 Texte oder so.

00:36:59.040 --> 00:37:00.960
Und vielleicht ein paar Millionen Bücher.

00:37:01.500 --> 00:37:03.460
Und jetzt hat man halt eine Link-Tabelle,

00:37:03.580 --> 00:37:05.980
die wahrscheinlich dann irgendwie ein paar 10 Millionen Bücher,

00:37:06.820 --> 00:37:08.920
ein paar 10 Millionen Zeilen oder so lang ist,

00:37:08.920 --> 00:37:12.400
wo halt jedem Buch ein paar Texte zugewiesen werden.

00:37:13.200 --> 00:37:15.380
Und dann ist alles wieder schön in der Normalform.

00:37:15.640 --> 00:37:17.120
Und das kann man dann auch wieder nett abfragen.

00:37:19.160 --> 00:37:23.840
Ja, wenn man dann aber quasi diesen Text halt,

00:37:24.080 --> 00:37:25.820
wenn man diese Texte jetzt aber betrachtet

00:37:25.820 --> 00:37:28.020
als Blätter in einem Kategorienbaum oder so,

00:37:28.740 --> 00:37:29.940
dann wird es wieder so ein bisschen schwierig,

00:37:30.060 --> 00:37:30.860
weil dann versucht man etwas

00:37:30.860 --> 00:37:32.400
in einer relationalen Datenbank abzuspeichern,

00:37:32.460 --> 00:37:33.140
was gar nicht so gut geht,

00:37:33.240 --> 00:37:35.040
nämlich irgendwie so Baumstrukturen

00:37:35.040 --> 00:37:36.780
oder Grafenstrukturen.

00:37:38.460 --> 00:37:39.540
Das kann man dann auch machen

00:37:39.540 --> 00:37:41.880
und wenn es nicht viele Texts oder Kategorien sind,

00:37:42.020 --> 00:37:42.820
dann würde man versuchen,

00:37:42.920 --> 00:37:44.100
wahrscheinlich Nested Sets nehmen.

00:37:45.320 --> 00:37:47.500
Das ist, kann man sich mal angucken,

00:37:48.040 --> 00:37:50.040
das interessiert, wie das, dann kann man dann halt auch

00:37:50.040 --> 00:37:51.640
per SQL Abfragen machen, wie

00:37:51.640 --> 00:37:53.540
ja, welche Bücher liegen denn jetzt

00:37:53.540 --> 00:37:55.420
unterhalb von dieser Kategorie.

00:37:55.980 --> 00:37:57.520
Was man macht ist, man schreibt an jede,

00:37:57.700 --> 00:37:59.960
man hat so eine Kategorie einen Baum und man schreibt dann an

00:37:59.960 --> 00:38:02.220
jedes Element

00:38:02.220 --> 00:38:03.940
in dieser hierarchischen Struktur,

00:38:04.080 --> 00:38:05.400
den traversiert man einmal

00:38:05.400 --> 00:38:08.300
First Order, ich weiß gar nicht genau.

00:38:10.600 --> 00:38:10.760
Und

00:38:10.760 --> 00:38:12.240
also beim Durchlaufen

00:38:12.240 --> 00:38:14.160
nummeriert man jeden Knoten, an dem man

00:38:14.160 --> 00:38:16.020
vorbeiläuft, durch und

00:38:16.020 --> 00:38:18.040
man hat eine Spalte links und eine Spalte

00:38:18.040 --> 00:38:20.020
rechts und links, wenn man

00:38:20.020 --> 00:38:22.040
links an den Sachen vorbeiläuft in den Baum,

00:38:22.320 --> 00:38:24.080
schreibt man halt die Nummern links

00:38:24.080 --> 00:38:25.980
rein und dann rechts, wenn man rechts dran

00:38:25.980 --> 00:38:27.680
vorbeiläuft und dann kann man so Sachen

00:38:27.680 --> 00:38:29.940
Range-Abfragen dazwischen machen und

00:38:29.940 --> 00:38:32.060
magischerweise führt das dann dazu, dass man so Subbäume

00:38:32.060 --> 00:38:34.080
rausselecten kann und so. Aber das ist dann

00:38:34.080 --> 00:38:35.360
halt schon so wirklich für Fortgeschrittene.

00:38:36.140 --> 00:38:37.560
Und im Endeffekt,

00:38:38.120 --> 00:38:39.500
wenn man jetzt große

00:38:39.500 --> 00:38:41.600
Grafenstrukturen hat oder Bäume,

00:38:41.880 --> 00:38:44.040
dann wäre es wahrscheinlich besser, das gar nicht mehr in einer relationalen Datenbank

00:38:44.040 --> 00:38:46.100
zu machen, sondern das irgendwie in einen anderen Service

00:38:46.100 --> 00:38:46.560
zu packen.

00:38:48.260 --> 00:38:49.480
Ja, und da sind wir schon,

00:38:49.680 --> 00:38:51.380
boah, das ging aber schnell, da sind wir schon an Grenzen,

00:38:51.460 --> 00:38:53.500
wenn man so eine Relation an Datenbanken machen kann.

00:38:54.100 --> 00:38:56.160
Ja, also das Dorsch nach der Garage ist mittlerweile rausgewachsen,

00:38:56.360 --> 00:38:57.880
also können die ganzen Bücher dann in der Garage

00:38:57.880 --> 00:38:58.420
nicht mehr lagern.

00:38:58.460 --> 00:38:59.920
Nee, nee, nee, Moment, Moment, wir sind noch nicht,

00:38:59.960 --> 00:39:02.400
also was eigentlich auch, nee, wir sind noch nicht,

00:39:02.600 --> 00:39:04.880
wir sind noch nicht so weit, wir sind noch immer bei der ganz normalen,

00:39:05.020 --> 00:39:06.560
einfachen Datenbank, würde ich sagen.

00:39:08.260 --> 00:39:09.400
Ja, also das,

00:39:09.580 --> 00:39:11.240
wofür wir die nämlich auch brauchen, die Datenbanken,

00:39:11.320 --> 00:39:12.940
sind halt so Transaktionen-Prozessen,

00:39:13.120 --> 00:39:14.420
So wenn jemand was kauft zum Beispiel.

00:39:14.640 --> 00:39:17.460
Oh, jemand hat bei uns eine E-Mail geschickt, hat gesagt, hey, habt ihr das Buch da?

00:39:17.540 --> 00:39:19.860
Und wir gucken nach, sagen ja, können wir dir schicken.

00:39:20.280 --> 00:39:22.280
Dann ja, bitte an die und die Adresse und so.

00:39:22.360 --> 00:39:27.520
Dann machen wir so ein Paket, machen da so einen Stempel drauf und sagen, hey, hier bitte dein Buch.

00:39:27.520 --> 00:39:33.260
Ja, und dafür, dass das gut funktioniert, dann müssen halt auch einige Sachen für gewährleistet sein.

00:39:33.500 --> 00:39:38.600
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.

00:39:38.920 --> 00:39:42.080
Das heißt, wenn jetzt ich ein Buch verschicke,

00:39:42.200 --> 00:39:44.220
dann sage ich meiner Datenbank irgendwie so,

00:39:44.300 --> 00:39:46.760
okay, jetzt ist davon eins weniger da im Lager.

00:39:47.740 --> 00:39:49.060
Aber wenn jetzt auf der Webseite jemand sagt,

00:39:49.120 --> 00:39:50.180
ich würde dieses Buch einkaufen,

00:39:50.460 --> 00:39:52.640
dann muss halt gewährleistet sein, dass das halt noch da ist.

00:39:52.640 --> 00:39:55.920
Das heißt, ich brauche halt eine zentrale Stelle,

00:39:56.080 --> 00:39:56.740
in der die Wahrheit...

00:39:56.740 --> 00:39:58.560
Mir fällt direkt wieder eines der Probleme ein.

00:39:59.100 --> 00:39:59.280
Okay.

00:40:00.100 --> 00:40:01.480
Ja, zwei Leute wollen das gleiche Buch haben,

00:40:01.520 --> 00:40:02.260
was nur noch einmal da ist,

00:40:02.320 --> 00:40:03.600
und die wollen gleichzeitig eins kaufen.

00:40:04.240 --> 00:40:04.440
Genau.

00:40:04.720 --> 00:40:06.960
Das ist halt eine problematische Geschichte.

00:40:07.260 --> 00:40:09.460
Aber wenn man jetzt eine Datenbank hat,

00:40:10.880 --> 00:40:14.240
die die Wahrheit kennt und alle nur auf die zugreifen,

00:40:15.040 --> 00:40:16.780
dann kann im Grunde nichts passieren.

00:40:17.040 --> 00:40:18.560
Also da können keine Konflikte auftreten,

00:40:19.320 --> 00:40:22.380
weil in dem Moment, wo jemand auf Kaufen klickt auf der Webseite

00:40:22.380 --> 00:40:25.240
und es noch ein Buch da war ...

00:40:26.060 --> 00:40:27.780
Die Frage ist halt jetzt, was man macht,

00:40:27.880 --> 00:40:29.820
wenn viele Kunden sich immer so ein Buch angucken,

00:40:30.400 --> 00:40:32.240
das in ihren Warenkorb reintun, weil sie es kaufen wollen,

00:40:32.480 --> 00:40:35.460
aber 90 Prozent dieser Kunden einfach gar nicht am Ende kaufen,

00:40:35.560 --> 00:40:36.820
sondern irgendwie wieder abspringen, weil die dann sagen,

00:40:36.900 --> 00:40:38.280
na ja, doch nicht oder so.

00:40:38.580 --> 00:40:40.920
Und dann hätten jetzt ja alle sich bei sich einen Warenkorb reingedickt

00:40:40.920 --> 00:40:43.200
und wenn nur noch eins da ist,

00:40:43.260 --> 00:40:44.560
vielleicht hätte der zweite direkt angezeigt bekommen,

00:40:44.640 --> 00:40:45.800
geht gar nichts, der ihn wirklich gekauft hätte.

00:40:46.000 --> 00:40:49.260
Also was natürlich passieren kann, ist, dass dir angezeigt wird,

00:40:49.480 --> 00:40:51.000
es gibt noch ein Buch, obwohl es keins mehr gibt.

00:40:52.080 --> 00:40:56.460
Weil du sitzt halt vor der Webseite und machst nichts.

00:40:56.660 --> 00:40:57.420
Du kopfst in die Luft.

00:40:57.460 --> 00:40:59.420
Oh, leider war jemand schneller und hat vor zwei Sekunden das Buch gemacht.

00:40:59.420 --> 00:41:01.040
Genau, du kannst, sobald du draufdrückst,

00:41:01.120 --> 00:41:04.900
in dem Moment, wo sozusagen diese Bestelltransaktion gestartet wird

00:41:04.900 --> 00:41:06.320
und dann in der Datenbank aber

00:41:06.320 --> 00:41:09.000
die Bedingung, es muss mindestens eins im Lager

00:41:09.000 --> 00:41:11.000
sein, damit die Bestellung ausgeführt werden kann, nicht mehr erfüllt

00:41:11.000 --> 00:41:12.840
ist und diese Constraint

00:41:12.840 --> 00:41:14.980
wird verletzt, dann sagt die Datenbank so,

00:41:15.060 --> 00:41:16.900
geht nicht. Und dann

00:41:16.900 --> 00:41:18.680
kann man dem User eine Fehlermeldung anzeigen und sagen so,

00:41:18.740 --> 00:41:20.760
oh ja, tut uns leid, das hat nicht geklappt.

00:41:21.080 --> 00:41:21.960
Kein Buch mehr auf Lager.

00:41:23.080 --> 00:41:24.120
Das ist ja im Grunde okay.

00:41:25.060 --> 00:41:26.260
Ja, gerade so.

00:41:27.280 --> 00:41:28.340
Ja, also was halt

00:41:28.340 --> 00:41:30.840
blöd wäre, ist, wenn man dem User sagt,

00:41:30.980 --> 00:41:32.140
okay, du hast das jetzt bestellt.

00:41:33.880 --> 00:41:59.640
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.

00:41:59.800 --> 00:42:15.560
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.

00:42:15.760 --> 00:42:28.440
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.

00:42:28.440 --> 00:42:48.060
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.

00:42:48.580 --> 00:42:52.800
Man schmeißt dann manuell die ausgedruckten Briefchen ins Überweisungs...

00:42:52.800 --> 00:42:53.360
Lochkarten.

00:42:54.560 --> 00:42:59.940
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.

00:43:00.260 --> 00:43:00.680
Nicht so gut.

00:43:01.220 --> 00:43:08.000
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.

00:43:08.240 --> 00:43:25.800
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.

00:43:25.860 --> 00:43:44.660
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.

00:43:44.660 --> 00:43:57.120
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.

00:43:58.380 --> 00:44:04.680
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.

00:44:04.680 --> 00:44:20.840
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.

00:44:21.080 --> 00:44:47.640
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.

00:44:47.640 --> 00:45:17.060
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,

00:45:17.060 --> 00:45:18.940
dann hätte ich jetzt die Bestellung zwar immer noch da,

00:45:19.260 --> 00:45:21.260
aber... Was ist denn jetzt als Beispiel,

00:45:21.340 --> 00:45:23.120
wenn ich jetzt sowas habe wie minus ein Buch

00:45:23.120 --> 00:45:25.020
und ich möchte jetzt einfach, dass wenn

00:45:25.020 --> 00:45:26.900
minus ein Buch ist, dass das nachbestellt wird

00:45:26.900 --> 00:45:28.760
von dem Händler um die Ecke.

00:45:28.940 --> 00:45:30.540
Also der hat noch eine Garage und die Mann ist noch ein Händler,

00:45:30.980 --> 00:45:32.880
der hat auch so Bücher und vielleicht hat der

00:45:32.880 --> 00:45:35.020
eins da und dann sage ich einfach, ja, ich muss das irgendwo anders herbekommen.

00:45:35.900 --> 00:45:37.000
Könnte ich ja auch wollen.

00:45:37.020 --> 00:45:38.180
Kann man auch machen.

00:45:39.040 --> 00:45:40.920
Müsste dann, ja, das hängt dann vom System

00:45:40.920 --> 00:45:42.920
ab, was die Logik dann macht. Man könnte dann sagen,

00:45:43.000 --> 00:45:44.780
okay, die Bestellung wird trotzdem ausgeführt, dafür wird dann

00:45:44.780 --> 00:45:46.920
aber das... Oder das Buch wird gedruckt oder sowas.

00:45:47.060 --> 00:45:58.160
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.

00:45:58.160 --> 00:46:16.180
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.

00:46:16.180 --> 00:46:29.180
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…

00:46:29.180 --> 00:46:56.060
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.

00:46:56.480 --> 00:46:58.480
Ja, aber das sind wirklich schwierige

00:46:58.480 --> 00:46:59.980
Probleme. Das ist ein bisschen

00:46:59.980 --> 00:47:01.800
unintuitiv, dass das

00:47:01.800 --> 00:47:03.900
so knifflig ist, aber es ist leider so.

00:47:04.360 --> 00:47:06.580
Ein wirklich lustiges Beispiel aus der Praxis.

00:47:08.040 --> 00:47:08.660
Das zeigt,

00:47:08.860 --> 00:47:10.240
dass das halt nicht so einfach ist.

00:47:10.320 --> 00:47:12.480
Möglicherweise finde ich es immer iTunes

00:47:12.480 --> 00:47:13.600
oder der App Store.

00:47:14.780 --> 00:47:16.180
Und der App Store war am Anfang,

00:47:16.520 --> 00:47:18.500
man hat den nicht neu entwickelt, sondern das war,

00:47:18.700 --> 00:47:20.520
man hat den, also über iTunes

00:47:20.520 --> 00:47:22.580
konnte Apple ja schon immer irgendwie so Musik verkaufen.

00:47:22.840 --> 00:47:24.120
Das hat auch recht gut funktioniert.

00:47:25.780 --> 00:47:26.360
Oder halt

00:47:26.360 --> 00:47:28.300
deutlich früher, als es jetzt das iPhone

00:47:28.300 --> 00:47:30.140
gab und App Store. Und dann

00:47:30.140 --> 00:47:32.340
sollte es halt dieses App Store Feature

00:47:32.340 --> 00:47:34.200
geben. Und dann haben sie halt einfach

00:47:34.200 --> 00:47:36.080
ihr iTunes Song Verkauf Ding

00:47:36.080 --> 00:47:38.160
genommen. Und das halt

00:47:38.160 --> 00:47:40.240
einfach nur gesagt, okay, das sind jetzt keine Songs, sondern das sind Apps.

00:47:41.120 --> 00:47:41.600
Was halt dazu

00:47:41.600 --> 00:47:43.480
führt, dass bis heute, und jetzt sind wir mehr als

00:47:43.480 --> 00:47:44.740
zehn Jahre später,

00:47:45.500 --> 00:47:47.600
bis heute haben

00:47:47.600 --> 00:47:49.520
halt irgendwie Apps einen Titel und eine Länge,

00:47:49.760 --> 00:47:51.340
Songlänge oder sowas, ja, was halt

00:47:51.340 --> 00:47:53.200
totaler Quatsch ist, das passt ja überhaupt nicht zusammen,

00:47:53.680 --> 00:47:55.460
aber es ist halt sehr, sehr schwer, das zu ändern,

00:47:55.940 --> 00:47:57.280
weil, ja,

00:47:57.720 --> 00:47:59.220
das würde so viel Logik irgendwie

00:47:59.220 --> 00:48:01.220
brechen,

00:48:01.420 --> 00:48:03.300
dass in anderen Systemen, das ist halt

00:48:03.300 --> 00:48:05.580
extrem, also du kannst halt, ja,

00:48:06.560 --> 00:48:07.660
also eine solche Migration

00:48:07.660 --> 00:48:09.260
durchzuführen, ist halt hinterher sehr, sehr schwer

00:48:09.260 --> 00:48:11.380
und also quasi die ganzen

00:48:11.380 --> 00:48:13.500
Daten einmal anfassen und abgleichen und bereinigen

00:48:13.500 --> 00:48:14.580
und schrubben und putzen.

00:48:15.160 --> 00:48:17.280
Die Daten sind gar nicht so sehr das Problem. Das Problem sind

00:48:17.280 --> 00:48:19.240
die anderen Systeme, die es auch

00:48:19.240 --> 00:48:21.240
alle drumherum gibt, die sich verlassen, dass die Datenbanken so

00:48:21.240 --> 00:48:23.380
aussehen, wie sie aussehen. Okay. Also wenn ich jetzt

00:48:23.380 --> 00:48:25.080
also die Daten selber zu ändern, ist glaube ich

00:48:25.080 --> 00:48:27.260
nicht so das Problem. Aber ich muss jeden

00:48:27.260 --> 00:48:29.500
Prozess bei jedem Nutzer dieser Datenbank darüber informieren,

00:48:29.620 --> 00:48:31.500
dass er sich das Schema... Und der muss damit klarkommen.

00:48:32.020 --> 00:48:33.480
Und das ist halt möglicherweise

00:48:33.480 --> 00:48:35.000
Legacy-Code, der wo

00:48:35.000 --> 00:48:37.280
der Letzte, der sich damit auskannte, vor fünf Jahren gegangen

00:48:37.280 --> 00:48:39.160
ist, aber das System

00:48:39.160 --> 00:48:41.140
macht irgendwas Vitales, was irgendwie total wichtig ist

00:48:41.140 --> 00:48:42.880
für das Business

00:48:42.880 --> 00:48:45.020
und tja, dann wird's halt

00:48:45.020 --> 00:48:47.100
richtig schwer. Und wenn du dann nicht nur ein solches System

00:48:47.100 --> 00:48:49.020
hast, sondern zig, dann kann es sein,

00:48:49.120 --> 00:48:50.780
dass du halt zehn Jahre lang das nicht mehr ändern kannst.

00:48:52.360 --> 00:48:53.040
Manchmal sieht man

00:48:53.040 --> 00:48:54.840
dann so ein bisschen lächerlich aus, aber wie jetzt

00:48:54.840 --> 00:48:56.140
in dem Apple-Fall.

00:48:57.720 --> 00:48:59.140
Wenn deine App eine Songlänge

00:48:59.140 --> 00:48:59.620
hat, ja.

00:49:00.840 --> 00:49:02.980
Ja, aber es ist halt, das zeigt halt

00:49:02.980 --> 00:49:04.760
so ein bisschen, wie knifflig das dann

00:49:04.760 --> 00:49:06.300
werden kann, wenn man

00:49:06.300 --> 00:49:07.480
Pech hat.

00:49:08.920 --> 00:49:10.600
Ja, und das ist auch so

00:49:10.600 --> 00:49:12.560
ein Problem bei relationalen Datenbanken

00:49:12.560 --> 00:49:14.680
insgesamt möglicherweise, würde ich

00:49:14.680 --> 00:49:16.820
sagen. Also gerade der E-Commerce-Fall

00:49:16.820 --> 00:49:18.540
oder der Amazon-Fall funktioniert

00:49:18.540 --> 00:49:20.380
eigentlich ganz gut. Zunächst, also

00:49:20.380 --> 00:49:22.520
später wird das dann auch nochmal ein bisschen problematischer, aber

00:49:22.520 --> 00:49:23.480
weil

00:49:23.480 --> 00:49:26.340
physische Dinge halt

00:49:26.340 --> 00:49:28.500
relativ stabil sind, was irgendwie so

00:49:28.500 --> 00:49:30.640
ihre Eigenschaften angeht. Also da funktionieren

00:49:30.640 --> 00:49:32.300
relationale Datenbanken halt besonders gut.

00:49:32.800 --> 00:49:34.240
Unwahrscheinlich, dass so ein Buch noch

00:49:34.240 --> 00:49:36.620
ein anderes Cover enthält oder sowas.

00:49:36.660 --> 00:49:38.460
Also, dass sich Bücher jetzt irgendwie,

00:49:38.580 --> 00:49:40.320
dass die plötzlich ein Attribut bekommen,

00:49:40.440 --> 00:49:42.180
was es halt vorher nicht gab. Die wachsen Flügel.

00:49:42.300 --> 00:49:44.540
Die haben halt irgendwie Titel, Seitenanzahlen oder sowas,

00:49:44.580 --> 00:49:46.140
aber dass jetzt plötzlich irgendwie, keine Ahnung,

00:49:47.900 --> 00:49:48.620
ich weiß nicht, was man sich

00:49:48.620 --> 00:49:50.560
da vorstellen könnte. Man müsste jetzt irgendwie

00:49:50.560 --> 00:49:52.680
Bücher...

00:49:52.680 --> 00:49:54.420
Jedes Buch enthält einen Geist.

00:49:55.440 --> 00:49:56.460
Bücher haben Flügel.

00:49:58.960 --> 00:50:00.120
Ja, keine Ahnung.

00:50:00.360 --> 00:50:02.100
Bücher kann man jetzt essen oder so, haben einen bestimmten Geschmack.

00:50:02.440 --> 00:50:04.060
Das ist sehr unwahrscheinlich, dass das passiert.

00:50:04.240 --> 00:50:06.400
Weil das würde bedeuten, dass sich die physikalische

00:50:06.400 --> 00:50:07.960
Realität irgendwie ändert, was sie ja

00:50:07.960 --> 00:50:08.960
natürlich auch tut.

00:50:09.420 --> 00:50:12.480
Aber das tut sie relativ langsam.

00:50:13.240 --> 00:50:14.240
Und das ist

00:50:14.240 --> 00:50:15.000
gut, weil

00:50:15.000 --> 00:50:17.460
man jetzt sozusagen

00:50:17.460 --> 00:50:20.100
diese physischen Dinge in der Datenbank beschrieben hat,

00:50:20.120 --> 00:50:22.280
die kann sich auch nur langsam ändern. Und das passt dann so ein bisschen

00:50:22.280 --> 00:50:23.380
zueinander. Also das ist halt,

00:50:23.900 --> 00:50:25.920
wenn man jetzt die Eigenschaften von einem Buch erstmal erfasst hat,

00:50:25.980 --> 00:50:28.280
dann ändert sich da wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig

00:50:28.280 --> 00:50:30.400
viel dran. Und dann muss man auch in der Datenbank nicht so wahnsinnig

00:50:30.400 --> 00:50:30.740
viel ändern.

00:50:32.020 --> 00:50:34.080
Wenn man jetzt ein anderes Problem hat und

00:50:34.080 --> 00:50:35.860
man jetzt zum Beispiel in der Datenbank

00:50:35.860 --> 00:50:38.040
nicht Daten über physikalische Objekte

00:50:38.040 --> 00:50:40.020
hält, sondern Daten über

00:50:40.020 --> 00:50:40.280
Daten.

00:50:41.740 --> 00:50:43.660
Oh, Metadaten.

00:50:45.000 --> 00:50:45.980
Die können sich

00:50:45.980 --> 00:50:47.880
dummerweise unter Umständen, je nachdem

00:50:47.880 --> 00:50:50.020
wie... Daten über Daten

00:50:50.020 --> 00:50:51.680
über Daten. Ja, das kann sich dann,

00:50:51.740 --> 00:50:53.760
da kann plötzlich die Geschwindigkeit, mit der sich die

00:50:53.760 --> 00:50:54.940
Strukturen da ändern müssen,

00:50:56.140 --> 00:50:57.580
deutlich schneller werden. Und dann wird es schwierig.

00:50:57.680 --> 00:50:59.740
Dann sind relationale Datenbanken auch so, das ist dann

00:50:59.740 --> 00:51:01.900
ein Problem. Das ist auch möglicherweise

00:51:01.900 --> 00:51:03.680
einer der Gründe dafür, warum jetzt in letzter Zeit halt

00:51:03.680 --> 00:51:05.360
immer mehr so NoSQL

00:51:05.360 --> 00:51:08.200
oder Dokumentdatenbanken

00:51:08.200 --> 00:51:10.040
oder

00:51:10.040 --> 00:51:11.760
wenn man das, manche nennen

00:51:11.760 --> 00:51:13.740
das auch Schema-less, warum die

00:51:13.740 --> 00:51:15.820
halt populärer werden, weil

00:51:15.820 --> 00:51:17.860
man damit halt möglicherweise auf diese geänderten

00:51:17.860 --> 00:51:19.620
Anforderungen halt besser reagieren kann,

00:51:19.760 --> 00:51:21.760
dass man ja möglicherweise

00:51:21.760 --> 00:51:23.740
ad hoc das Schema irgendwie ändern

00:51:23.740 --> 00:51:25.740
muss und das halt in der relationalen Datenbank nicht so ganz

00:51:25.740 --> 00:51:27.720
einfach ist, weil so absolut kann man das auch nicht

00:51:27.720 --> 00:51:29.660
sagen, also es gibt da diverse Möglichkeiten,

00:51:29.820 --> 00:51:31.700
wie man die Geschichten miteinander verbinden

00:51:31.700 --> 00:51:32.520
kann und

00:51:32.520 --> 00:51:34.840
ja, wenn

00:51:34.840 --> 00:51:37.200
Schema lässt, ist halt auch nicht Schema lässt, sondern

00:51:37.200 --> 00:51:39.000
das bedeutet halt mehr oder weniger nur, dass

00:51:39.000 --> 00:51:41.320
das Schema jetzt implizit in deiner Applikation

00:51:41.320 --> 00:51:43.260
ist und du halt immer aufpassen musst, wenn

00:51:43.260 --> 00:51:45.240
du deine Applikation änderst, dass du da das Schema nicht

00:51:45.240 --> 00:51:46.840
kaputt machst oder änderst oder so und das

00:51:46.840 --> 00:51:49.240
überlegen sich viele Leute dann nicht so richtig und

00:51:49.240 --> 00:51:51.100
dann ändern sie irgendwas und dann passieren furchtbare Dinge

00:51:51.100 --> 00:51:53.220
und also dann fällt ihnen auf,

00:51:53.300 --> 00:51:54.020
dass sie doch ein Schema haben.

00:51:56.340 --> 00:51:57.140
Und ja,

00:51:57.340 --> 00:51:59.180
dass sie dieses Problem halt doch nicht losgeworden sind.

00:52:00.060 --> 00:52:00.880
Also es ist

00:52:00.880 --> 00:52:02.540
leider alles nicht so einfach und

00:52:02.540 --> 00:52:05.300
das ist tatsächlich

00:52:05.300 --> 00:52:07.300
so, dass man bei Datenbanken

00:52:07.300 --> 00:52:09.300
halt im Design am Anfang ein bisschen

00:52:09.300 --> 00:52:11.080
mehr Arbeit hat, aber dafür hat man auch dann

00:52:11.080 --> 00:52:12.820
einen lustigen Vorteil, nämlich

00:52:12.820 --> 00:52:14.560
es ist immer so schön, irgendwie

00:52:14.560 --> 00:52:17.300
Daten altern wie Wein,

00:52:17.460 --> 00:52:19.340
also wenn man halt viele gute Daten

00:52:19.340 --> 00:52:21.280
hat, das ist super und wenn das mehr werden, das ist immer

00:52:21.280 --> 00:52:23.240
schön und das altert auch gut, das wird immer

00:52:23.240 --> 00:52:25.080
besser mit der Zeit, man kann immer mehr

00:52:25.080 --> 00:52:27.440
Wissen daraus generieren, man kann immer mehr

00:52:27.440 --> 00:52:29.200
Fragen beantworten oder so, das ist eine sehr schöne

00:52:29.200 --> 00:52:30.100
Sachen und

00:52:30.100 --> 00:52:33.520
Applikationscode erörtert

00:52:33.520 --> 00:52:33.860
wie Fisch.

00:52:34.580 --> 00:52:36.960
Das ist nicht gut,

00:52:37.140 --> 00:52:39.200
wenn immer Features drankommen oder Sachen

00:52:39.200 --> 00:52:41.140
geändert werden, also das wird immer schlimmer mit der Zeit.

00:52:41.240 --> 00:52:43.160
Das ist eigentlich selten so, dass man

00:52:43.160 --> 00:52:45.240
irgendwie jetzt mehrere Jahre irgendwie ein Projekt

00:52:45.240 --> 00:52:47.140
entwickelt und die Codequalität wird immer besser.

00:52:47.400 --> 00:52:49.220
Das ist irgendwie nicht so, sondern es wird

00:52:49.220 --> 00:52:51.100
immer, es wird irgendwie

00:52:51.100 --> 00:52:53.260
und daher ist halt... Noch ein Frickel da, noch

00:52:53.260 --> 00:52:55.380
ein Frickel dort, kleines Modülchen

00:52:55.380 --> 00:52:56.860
an der Seite. Und auch

00:52:56.860 --> 00:52:59.420
das Problem ist halt, die Anforderungen verschieben sich halt

00:52:59.420 --> 00:53:01.060
irgendwie oder

00:53:01.060 --> 00:53:03.540
die Realität ändert sich und

00:53:03.540 --> 00:53:05.160
dann ist halt der ursprüngliche

00:53:05.160 --> 00:53:07.300
Plan oder die ursprüngliche Architektur

00:53:07.300 --> 00:53:09.300
der Applikation ist halt nicht mehr darauf angepasst

00:53:09.300 --> 00:53:10.780
und so und

00:53:10.780 --> 00:53:12.880
da hat man dann halt

00:53:12.880 --> 00:53:14.780
ja, genau dieses

00:53:14.780 --> 00:53:17.360
Problem, dass wenn man

00:53:17.360 --> 00:53:19.140
jetzt das Schema verlagert in die Applikation

00:53:19.140 --> 00:53:20.960
und die Applikation aber altert wie Fisch, dann

00:53:20.960 --> 00:53:23.080
altern auch die Daten

00:53:23.080 --> 00:53:25.380
nicht gut und deswegen ist es eigentlich schon sinnvoll

00:53:25.380 --> 00:53:26.880
eine Trennlinie zu haben und zu sagen,

00:53:27.360 --> 00:53:29.060
okay, selbst wenn wir die Applikation

00:53:29.060 --> 00:53:31.520
irgendwann wegschmeißen müssen, neu schreiben müssen oder so,

00:53:31.920 --> 00:53:33.460
dann haben wir immer noch die Daten und die

00:53:33.460 --> 00:53:35.240
sind halt sauber strukturiert und

00:53:35.240 --> 00:53:36.360
das sieht alles gut aus.

00:53:37.620 --> 00:53:39.460
Und das kann eine sehr wertvolle Sache sein,

00:53:39.460 --> 00:53:40.260
wenn man das richtig macht.

00:53:41.300 --> 00:53:42.240
Und ja,

00:53:43.420 --> 00:53:45.180
genau, deswegen ist

00:53:45.180 --> 00:53:47.320
diese Trennung, wo man halt

00:53:47.320 --> 00:53:49.480
irgendwie ein striktes Schema

00:53:49.480 --> 00:53:51.220
hat und das auch

00:53:51.220 --> 00:53:53.200
diverse Constraints, die halt irgendwie,

00:53:53.400 --> 00:53:55.360
also dass man halt solche Sachen drin hat, wie es kann nicht

00:53:55.360 --> 00:53:57.000
im Lagersachen geben

00:53:57.000 --> 00:53:59.800
mit einem Lagerstand von

00:53:59.800 --> 00:54:01.240
Minus irgendwas. Das darf halt nicht sein.

00:54:01.600 --> 00:54:03.680
Da ist ein Fehler passiert, dann kann die Datenbank schon

00:54:03.680 --> 00:54:05.360
dafür sorgen, dass das halt

00:54:05.360 --> 00:54:07.400
nicht da reingeschrieben wird, weil die sagt halt so,

00:54:07.480 --> 00:54:09.740
nee, so nicht. Man muss halt bloß dieses Constraint definieren

00:54:09.740 --> 00:54:11.780
und sagen, so auf dieser Spalte, da dürfen keine

00:54:11.780 --> 00:54:13.740
negativen Werte auftauchen. Oder eben so was

00:54:13.740 --> 00:54:15.300
wie ein Gehalt, das darf auch nicht negativ werden.

00:54:15.800 --> 00:54:16.920
Oder dass halt

00:54:16.920 --> 00:54:19.840
bestimmte Datumsinformationen

00:54:19.840 --> 00:54:21.520
halt nicht so und so sein können.

00:54:22.640 --> 00:54:22.720
Ja.

00:54:24.380 --> 00:54:51.420
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.

00:54:51.600 --> 00:55:20.460
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.

00:55:20.460 --> 00:55:22.060
und das kann man mit Postgres tun, man kann

00:55:22.060 --> 00:55:23.160
sagen so, also

00:55:23.160 --> 00:55:26.200
ich brauche diese Einträge

00:55:26.200 --> 00:55:28.140
in der Buchtabelle noch, um halt

00:55:28.140 --> 00:55:30.180
damit die referenzielle Integrität, so nennt man das

00:55:30.180 --> 00:55:31.900
halt, von alten Bestellungen nicht bricht,

00:55:32.360 --> 00:55:33.440
die ja brechen würde, wenn ich

00:55:33.440 --> 00:55:36.200
das einfach löschen würde, dann hätte ich halt

00:55:36.200 --> 00:55:38.140
einen Pointer in der Bestellungstabelle, der

00:55:38.140 --> 00:55:39.940
halt auf etwas zeigt, was es nicht mehr gibt, das wäre

00:55:39.940 --> 00:55:42.180
schlecht, weil ich dann gar nicht mehr weiß,

00:55:42.220 --> 00:55:42.800
was es sein soll und so.

00:55:44.280 --> 00:55:46.160
Aber trotzdem werden diese Dinger nicht

00:55:46.160 --> 00:55:48.180
mehr in den Index geschrieben, also ich kann

00:55:48.180 --> 00:55:49.680
halt einen Index so definieren, dass er nur

00:55:49.680 --> 00:55:52.360
Sachen, Bücher

00:55:52.360 --> 00:55:54.660
mit reinnimmt, die halt

00:55:54.660 --> 00:55:55.840
auch tatsächlich noch verkauft werden.

00:55:56.800 --> 00:55:57.840
Und das heißt, es ist nicht so,

00:55:58.060 --> 00:56:00.320
an solchen Stellen ist Postgres halt sehr schön, hat

00:56:00.320 --> 00:56:02.520
sehr viele Features, zum Beispiel

00:56:02.520 --> 00:56:04.220
jetzt im Unterschied zu MySQL, wo das halt,

00:56:04.300 --> 00:56:05.480
wo solche Sachen gehen da gar nicht.

00:56:05.480 --> 00:56:07.440
Also das halt, und da hast du dann halt

00:56:07.440 --> 00:56:09.380
ein Problem, wenn du ganz, bei Büchern ist es jetzt nicht

00:56:09.380 --> 00:56:11.200
so schlimm, so viele Bücher gibt es nicht und

00:56:11.200 --> 00:56:13.360
so viele, die dann halt

00:56:13.360 --> 00:56:15.340
nicht mehr verkauft werden, auch nicht, aber

00:56:15.340 --> 00:56:17.080
man könnte sich vorstellen, es gibt durchaus Anwendungen,

00:56:17.400 --> 00:56:19.300
wo man dieses Problem ganz massiv bekommt,

00:56:19.640 --> 00:56:21.800
dass man halt eine Menge gelöschte Geschichten in der Tabelle

00:56:21.800 --> 00:56:23.740
hat, die man aber nicht wirklich löschen kann, sondern nur als gelöscht

00:56:23.740 --> 00:56:25.660
markiert. Und dann der Index

00:56:25.660 --> 00:56:27.560
aber immer größer wird und langsamer wird, weil

00:56:27.560 --> 00:56:29.700
ja, man halt nicht so einen

00:56:29.700 --> 00:56:31.180
partiellen Index über Sachen haben kann.

00:56:32.480 --> 00:56:33.660
Ja, überhaupt Postgres

00:56:33.660 --> 00:56:35.720
kann halt auch noch diverse andere Geschichten, damit könnte man halt

00:56:35.720 --> 00:56:37.820
auch so Sachen lösen, wie welche Pakete

00:56:37.820 --> 00:56:39.480
kriege ich eigentlich in so einen Lieferwagen rein und so,

00:56:39.860 --> 00:56:41.380
weil der kann halt, das Ding kann halt nicht nur

00:56:41.380 --> 00:56:43.480
so B-Trees,

00:56:43.720 --> 00:56:44.760
die man jetzt für

00:56:44.760 --> 00:56:48.020
Textabfragen,

00:56:48.200 --> 00:56:49.420
Indexabfragen benutzt, also

00:56:49.420 --> 00:56:54.280
Also dass man sagt, welche Kategorie beginnt jetzt mit folgenden drei Buchstaben oder so.

00:56:54.600 --> 00:57:01.660
Da nimmt man B-Tree, aber es kann halt auch solche Sachen wie Polygone, Abmessungen, überdeckt das eine, das andere.

00:57:03.180 --> 00:57:07.920
Es kann halt so A-Trees, die man halt für diese ganzen räumlichen Datengeschichten braucht.

00:57:07.920 --> 00:57:13.180
Aber es kann nicht nur das, sondern es kann auch so Sachen wie, welche Sachen liegen nah an anderen, so KD-Trees, Ball-Trees.

00:57:14.100 --> 00:57:16.040
Es kann sogar Suffix-Trees, also Postgres

00:57:16.040 --> 00:57:18.000
kann da eine ganze Menge unterschiedlicher Abfragen

00:57:18.000 --> 00:57:19.160
und Indizes,

00:57:19.440 --> 00:57:21.600
die man, also

00:57:21.600 --> 00:57:24.320
Aber ich glaube, die lohnen sich jetzt noch nicht bei unserem kleinen Laden.

00:57:24.460 --> 00:57:26.040
Wir sind ja, glaube ich, noch jetzt. Ja, doch, doch.

00:57:26.200 --> 00:57:27.300
Ja, jetzt dann. Ja, ja.

00:57:27.560 --> 00:57:29.920
Wie viele Bücher passen in der Garage? Wenn du deine Lagerhaltung,

00:57:30.020 --> 00:57:31.780
und das möchtest du halt im gleichen System machen, damit

00:57:31.780 --> 00:57:33.920
eben du nicht das Problem kriegst, dass

00:57:33.920 --> 00:57:36.160
du den Start-Estate zwischen unterschiedlichen

00:57:36.160 --> 00:57:37.940
Systemen synchronisieren musst, also wenn du jetzt

00:57:37.940 --> 00:57:39.900
deine Lagerhaltung in einem System machst und machst

00:57:39.900 --> 00:57:41.780
dann deine Webseite

00:57:41.780 --> 00:57:43.200
oder die Datenbank, die die Webseite

00:57:43.200 --> 00:57:48.300
über die du Bücher verkaufst,

00:57:48.320 --> 00:57:49.400
wenn das unterschiedliche Systeme sind,

00:57:49.820 --> 00:57:51.360
dann musst du den State-Zwischendienstensystem

00:57:51.360 --> 00:57:53.660
ja irgendwie synchronisieren.

00:57:54.740 --> 00:57:57.660
Was schlecht ist, würde ich zum Beispiel sagen,

00:57:57.660 --> 00:58:00.680
das ist halt am Anfang sehr, sehr hilfreich,

00:58:00.780 --> 00:58:01.880
wenn das alles ein System ist.

00:58:02.540 --> 00:58:04.300
Weil man dann eben tatsächlich

00:58:04.300 --> 00:58:06.560
die referenzielle Integrität, Constraints,

00:58:06.840 --> 00:58:08.420
über alle Daten hinweg machen kann

00:58:08.420 --> 00:58:11.360
und dann von der Datenbank sicherstellen lassen kann schon,

00:58:11.480 --> 00:58:12.500
dass bestimmte Sachen nicht gehen

00:58:12.500 --> 00:58:14.640
und dass bestimmte Sachen immer erfüllt sein müssen.

00:58:14.920 --> 00:58:17.260
Das heißt, unser Schema setzt das dann tatsächlich fest

00:58:17.260 --> 00:58:18.880
und das gibt dann sonst direkt einen Fehler aus der Datenbank.

00:58:19.120 --> 00:58:20.540
Hey, nur dürfen wir nicht, geht nicht.

00:58:20.660 --> 00:58:22.720
Und wir haben das Schema dabei erarbeitet für unseren kleinen Laden

00:58:22.720 --> 00:58:23.720
und so sollten wir dann los.

00:58:23.720 --> 00:58:25.960
Und dann kann deine Applikation oder die Programmierer,

00:58:26.080 --> 00:58:26.800
die jetzt vielleicht gar nicht,

00:58:27.220 --> 00:58:29.140
die Leute, die die Webseite bauen,

00:58:29.200 --> 00:58:30.940
die haben jetzt vielleicht gar nicht so viel Ahnung von Lagerhaltung.

00:58:31.420 --> 00:58:33.100
Die können aber, egal was sie auf der Datenbank machen,

00:58:33.180 --> 00:58:33.980
sie können nichts kaputt machen.

00:58:34.060 --> 00:58:36.620
Weil wenn sie etwas tun, was eigentlich nicht geht,

00:58:36.680 --> 00:58:39.080
wie zum Beispiel einen Lagerstand von hoch auf minus eins setzen,

00:58:39.580 --> 00:58:40.880
dann sagt ihnen die Datenbank, nur mache ich nicht.

00:58:41.640 --> 00:58:42.480
Und dann kriegen sie halt einen Fehler.

00:58:43.160 --> 00:58:44.580
Und das ist halt sauber, weil

00:58:44.580 --> 00:58:46.080
wenn du jetzt zwei Systeme hättest und

00:58:46.080 --> 00:58:48.480
musst jetzt da synchronisieren und jetzt ist aber schon

00:58:48.480 --> 00:58:49.780
irgendwie was Blödes passiert.

00:58:49.780 --> 00:58:50.780
Du hast minus zwei Bücher und dann

00:58:50.780 --> 00:58:53.120
sagt die eine Datenbank, du darfst aber eigentlich nicht.

00:58:53.180 --> 00:58:54.440
Dann sagt die eine Datenbank, ja, hab ich aber.

00:58:55.000 --> 00:58:57.180
Da kommst du halt in Teufels Küche.

00:58:57.540 --> 00:58:59.380
Man könnte sich vorstellen, dass das eine gute Idee wäre.

00:58:59.940 --> 00:59:01.700
Wenn man das macht, dann wird man halt relativ schnell feststellen,

00:59:01.720 --> 00:59:03.160
das ist keine gute Idee. Das ist doof.

00:59:06.220 --> 00:59:07.900
Das ist auch vielleicht ein bisschen unintuitiv.

00:59:08.740 --> 00:59:09.700
Und natürlich,

00:59:09.820 --> 00:59:11.600
nachher muss man Sachen funktionierender

00:59:11.600 --> 00:59:13.540
rausnehmen und man muss dann das

00:59:13.540 --> 00:59:15.580
in mehrere Systeme aufkleiden. Man sollte so lange wie möglich

00:59:15.580 --> 00:59:17.180
versuchen zu verhindern, dass das passiert, weil

00:59:17.180 --> 00:59:19.500
das macht alles viel, viel schwerer.

00:59:21.240 --> 00:59:21.340
Ja.

00:59:23.220 --> 00:59:23.620
Genau.

00:59:23.820 --> 00:59:25.400
Also wo sind wir jetzt eigentlich genau?

00:59:25.460 --> 00:59:27.320
Wir sind klein und niedlich. Wir haben

00:59:27.320 --> 00:59:29.440
Postgres, machen alles

00:59:29.440 --> 00:59:31.340
über Postgres. Wir haben ein bisschen JavaScript

00:59:31.340 --> 00:59:33.360
auf der Client-Seite. Ansonsten

00:59:33.360 --> 00:59:35.280
nehmen wir, sagen wir mal, Django oder so

00:59:35.280 --> 00:59:36.460
als Web-Framework.

00:59:38.720 --> 00:59:39.420
Also genau, jetzt kommen wir

00:59:39.420 --> 00:59:40.060
erstmal zu, wie machen wir das?

00:59:40.060 --> 00:59:44.360
Genau, da brauchen wir halt irgendeine Art,

00:59:44.440 --> 00:59:46.360
wie wir auf die Datenbank zugreifen.

00:59:47.460 --> 00:59:51.020
Üblicherweise, wie man Statements oder Abfragen an eine Datenbank formuliert,

00:59:51.080 --> 00:59:54.720
ist halt SQL heutzutage halt so der Standard für solche Systeme.

00:59:55.780 --> 00:59:58.920
Aber ja, das ist halt immer ein bisschen Fremdkörper.

00:59:59.040 --> 01:00:00.620
Wenn man jetzt einen Python-Code schreibt,

01:00:00.900 --> 01:00:02.360
dann hat man jetzt so ein SQL-Statement.

01:00:02.760 --> 01:00:04.780
Das passt von der Syntaxe ja überhaupt nicht in Python rein.

01:00:04.800 --> 01:00:07.560
Da muss man einen langen String machen, der irgendwie vernünftig aussieht.

01:00:07.560 --> 01:00:09.700
Und da muss dann alles stehen, was man mit der Datenbank reden kann.

01:00:10.060 --> 01:00:23.740
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.

01:00:24.780 --> 01:00:33.560
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.

01:00:33.640 --> 01:00:35.900
dann packt man halt sozusagen die Statements

01:00:35.900 --> 01:00:37.720
immer an die Stelle, wo man halt

01:00:37.720 --> 01:00:39.320
tatsächlich mit den Daten arbeitet. Das hat

01:00:39.320 --> 01:00:41.840
auch wiederum einen Vor- und Nachteil. Das hat den Vorteil, dass man halt

01:00:41.840 --> 01:00:43.440
Sachen leicht ändern kann, aber es hat den Nachteil,

01:00:43.700 --> 01:00:45.920
dass man unter Umständen mehrere Statements,

01:00:46.020 --> 01:00:47.060
die sehr ähnlich oder gleich sind,

01:00:47.520 --> 01:00:48.600
an unterschiedlichen Stellen hat.

01:00:49.640 --> 01:00:51.340
Alles nicht so total toll.

01:00:52.600 --> 01:00:53.820
Auch nicht so ein einfaches Problem.

01:00:54.880 --> 01:00:55.540
Und eine

01:00:55.540 --> 01:00:57.480
ganz gute Lösung für dieses Problem

01:00:57.480 --> 01:01:00.040
sind so objektrelationale

01:01:00.040 --> 01:01:00.980
Mapper oder ORMs.

01:01:03.220 --> 01:01:15.600
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.

01:01:17.740 --> 01:01:21.920
Man definiert die Daten, die man in der Datenbank stehen haben möchte, einfach nur als Klassen.

01:01:23.360 --> 01:01:25.520
Das heißt, das Schema wird nochmal als Klasse eingebaut, oder?

01:01:25.920 --> 01:01:32.440
Das Schema entsteht dadurch, dass man unterschiedliche Klassen hat, die irgendwie in Beziehung zueinander stehen.

01:01:32.980 --> 01:01:34.860
also was aufeinander mappt, ist halt

01:01:34.860 --> 01:01:36.900
Klasse und Tabelle. Also ich hätte dann,

01:01:37.100 --> 01:01:38.940
wenn ich Bücher kaufen möchte, halt eine Klasse Book

01:01:38.940 --> 01:01:40.900
und

01:01:40.900 --> 01:01:42.800
dann hätte ich halt vielleicht eine Klasse Tag

01:01:42.800 --> 01:01:45.140
und wir hatten das ja eben

01:01:45.140 --> 01:01:47.040
mit dem Beispiel, ich habe eine N zu M

01:01:47.040 --> 01:01:49.220
Beziehung zwischen Tags und Büchern

01:01:49.220 --> 01:01:50.920
und dann würde man entweder

01:01:50.920 --> 01:01:52.540
in Tags oder in Büchern irgendwo

01:01:52.540 --> 01:01:54.260
definieren, also das hier ist

01:01:54.260 --> 01:01:55.520
dieses Feld

01:01:55.520 --> 01:01:58.980
Tags ist halt

01:01:58.980 --> 01:01:59.520
ein

01:01:59.520 --> 01:02:01.960
wie heißt das

01:02:01.960 --> 01:02:04.360
in Django, weiß jetzt

01:02:04.360 --> 01:02:05.820
irgendwie, nee, irgendwas

01:02:05.820 --> 01:02:08.380
foreign-key-field irgendwas, aber man sagt halt,

01:02:08.440 --> 01:02:10.140
das ist halt many-to-many-relation

01:02:10.140 --> 01:02:11.820
irgendwas, weiß nicht, muss ich nachgucken.

01:02:12.560 --> 01:02:13.820
Aber auf jeden Fall definiert man das halt wie

01:02:13.820 --> 01:02:16.340
eine Spalte in der Tabelle.

01:02:16.760 --> 01:02:18.260
Also Attribute der Klasse sind halt

01:02:18.260 --> 01:02:20.180
Spalten in der Tabelle. Und sagt dann halt, das hier ist

01:02:20.180 --> 01:02:21.740
ein many-to-many-Beziehung zu

01:02:21.740 --> 01:02:24.020
der Relation Tags.

01:02:24.340 --> 01:02:26.320
Und dann hat man, die Link-Tabelle

01:02:26.320 --> 01:02:28.040
wird automatisch erzeugt, man kriegt das gar nicht mit.

01:02:30.500 --> 01:02:31.880
Und im Code hat man halt

01:02:31.880 --> 01:02:33.700
nur Bücher und Tags und halt dann diese

01:02:33.700 --> 01:02:35.120
Beziehungen dazwischen und dann

01:02:35.120 --> 01:02:37.800
ja,

01:02:38.060 --> 01:02:39.700
wenn man sich das halt so

01:02:39.700 --> 01:02:41.680
hindefiniert hat und dann halt

01:02:41.680 --> 01:02:43.680
alle Klassen, die man so braucht, beziehungsweise alle Tabellen, die man

01:02:43.680 --> 01:02:45.000
halt irgendwie in der Datenbank haben möchte,

01:02:45.900 --> 01:02:47.460
definiert hat mit den Spalten

01:02:47.460 --> 01:02:49.840
und den Typen der Spalten und den entsprechenden Constraints

01:02:49.840 --> 01:02:51.880
und den Inzides und den ganzen Kladderadatschen,

01:02:51.960 --> 01:02:53.720
die man auch sonst noch so braucht, dann

01:02:53.720 --> 01:02:54.440
sagt man

01:02:54.440 --> 01:02:57.840
Migrate und dann

01:02:57.840 --> 01:02:59.220
werden die ganzen

01:02:59.220 --> 01:03:01.860
Tabellen in der Datenbank tatsächlich angelegt

01:03:01.860 --> 01:03:04.340
oder

01:03:04.340 --> 01:03:06.820
Make Migrations

01:03:06.820 --> 01:03:09.100
ruft man halt zuerst auf und damit

01:03:09.100 --> 01:03:11.060
werden halt so Migrationsskripte in Django

01:03:11.060 --> 01:03:13.140
angelegt. Das sind auch einfach

01:03:13.140 --> 01:03:14.900
nur Python-Files, in denen drinsteht, was

01:03:14.900 --> 01:03:16.840
diese Migrationen tun sollen, nämlich zum Beispiel irgendwie

01:03:16.840 --> 01:03:17.740
Tabellen anlegen,

01:03:19.580 --> 01:03:20.960
Indizes anlegen oder sonst irgendwas.

01:03:21.800 --> 01:03:22.940
In die kann man auch beliebige andere Dinge

01:03:22.940 --> 01:03:25.100
reinschreiben. Also man kann halt auch selber Migrationen

01:03:25.620 --> 01:03:29.140
einfach so von Hand schreiben, wenn man zum Beispiel

01:03:29.140 --> 01:03:31.080
jetzt sowas wie, es gibt so Datenbank-Trigger,

01:03:31.740 --> 01:03:33.300
Also man kann halt sowas ...

01:03:33.300 --> 01:03:33.520
Was ist das?

01:03:34.520 --> 01:03:39.580
Ja, man könnte halt, also wenn zum Beispiel ...

01:03:39.580 --> 01:03:41.740
Nutzer taggen selber und erfinden eine neue Kategorie.

01:03:43.740 --> 01:03:46.580
Ja, ich überlege gerade,

01:03:46.680 --> 01:03:49.120
mir fällt ehrlich gesagt jetzt gerade nicht so ein tolles Beispiel ein,

01:03:49.120 --> 01:03:50.580
aber im Grunde, was das tut, ist,

01:03:50.860 --> 01:03:54.380
wenn sich halt in einer bestimmten Spalte irgendwas ändert,

01:03:54.740 --> 01:03:56.540
dass dann automatisch andere Aktionen passieren

01:03:56.540 --> 01:03:58.020
innerhalb der Datenbank.

01:03:59.000 --> 01:04:01.060
Und das kann man halt festlegen,

01:04:01.160 --> 01:04:03.080
haben auch einen SQL-Syntax und man schreibt

01:04:03.080 --> 01:04:04.620
das halt einfach in eine Migration rein.

01:04:05.160 --> 01:04:07.000
Oder man kann auch sogar Sort Procedures, die halt dann

01:04:07.000 --> 01:04:09.000
irgendwie eine komplizierte Geschichte, die dann irgendwie ausgeführt

01:04:09.000 --> 01:04:10.960
wird, wenn ein neuer Autor angelegt

01:04:10.960 --> 01:04:12.860
wird oder sonst irgendwas. Dann müssen

01:04:12.860 --> 01:04:14.520
vielleicht noch diverse andere Geschichten gemacht werden.

01:04:16.240 --> 01:04:16.940
Das kann man

01:04:16.940 --> 01:04:18.820
ganz normal in diese Django-Migration

01:04:18.820 --> 01:04:21.060
auch reinschreiben. Man kann da die SQL reinschreiben

01:04:21.060 --> 01:04:22.940
und die werden dann mit

01:04:22.940 --> 01:04:24.840
ausgeführt und dann werden halt diese Sort Procedures

01:04:24.840 --> 01:04:26.520
oder Trigger in die Datenbank mit reingeschrieben

01:04:26.520 --> 01:04:28.060
und sind dann halt da.

01:04:29.160 --> 01:04:29.360
Und

01:04:29.360 --> 01:04:32.340
was im Schema

01:04:32.340 --> 01:04:34.100
passiert oder was da drin ist, das wird halt dann von

01:04:34.100 --> 01:04:36.240
diesem Django-Migrationssystem verwaltet

01:04:36.240 --> 01:04:38.280
und alle Migrationen, die ausgeführt

01:04:38.280 --> 01:04:40.240
worden sind, werden halt auch wieder

01:04:40.240 --> 01:04:42.220
in derselben Datenbank halt

01:04:42.220 --> 01:04:44.320
gehalten von Django selbst, da gibt es dann halt auch Tabellen zu

01:04:44.320 --> 01:04:46.080
und man kann jetzt Sachen auch wieder zurückrollen.

01:04:46.160 --> 01:04:47.980
Also man kann zum Beispiel sagen, wenn man jetzt eine Änderung gemacht hat

01:04:47.980 --> 01:04:50.120
und feststellt, oh, die war nicht so toll,

01:04:50.240 --> 01:04:52.100
dann sagt man halt einfach so migrate und dann

01:04:52.100 --> 01:04:54.100
gibt man die Nummer der Migration

01:04:54.100 --> 01:04:56.240
an davor und dann rollt sich die Datenbank

01:04:56.240 --> 01:04:57.700
in den Zustand davor zurück.

01:04:59.360 --> 01:05:01.300
und dann löscht man einfach die Migration

01:05:01.300 --> 01:05:03.560
und dann war's das. Also das macht es halt

01:05:03.560 --> 01:05:05.720
sehr angenehm, damit zu arbeiten und sowas braucht man

01:05:05.720 --> 01:05:07.660
auf jeden Fall. Also selbst wenn man jetzt sowas nicht wie Django

01:05:07.660 --> 01:05:09.520
verwendet, sondern das alles von Hand macht,

01:05:09.900 --> 01:05:11.960
braucht man auch irgendeine Art, wie man damit umgeht

01:05:11.960 --> 01:05:13.680
und das war teilweise früher ziemlich übel,

01:05:13.820 --> 01:05:15.600
als es keine so gute Unterstützung

01:05:15.600 --> 01:05:17.600
in den Frameworks für sowas gab, hat man das halt

01:05:17.600 --> 01:05:19.540
irgendwie von Hand gemacht und da passieren

01:05:19.540 --> 01:05:20.520
dann immer wieder Unfälle,

01:05:21.420 --> 01:05:23.560
man hat halt irgendeine Datenbank vergessen oder

01:05:23.560 --> 01:05:25.800
wenn man jetzt halt mehrere Datenbanken

01:05:25.800 --> 01:05:27.140
hat oder

01:05:27.140 --> 01:05:30.100
es geht irgendwie sowas verloren, man weiß

01:05:30.100 --> 01:05:31.820
nicht genau, in welchem Zustand die Datenbank ist, weil

01:05:31.820 --> 01:05:34.020
irgendwie man meint, man hätte die ausgeführt,

01:05:34.160 --> 01:05:35.860
aber dann ist es irgendwie doch nicht

01:05:35.860 --> 01:05:37.900
passiert oder, ja, weil

01:05:37.900 --> 01:05:39.860
eben nirgendwo drinsteht, in welchem Zustand

01:05:39.860 --> 01:05:41.980
die Datenbank ist, sondern man nur Leute

01:05:41.980 --> 01:05:43.840
fragt irgendwie so, also hast du die Migration

01:05:43.840 --> 01:05:45.820
jetzt eigentlich auf der Produktionsdatenbank schon ausgeführt oder nicht?

01:05:45.900 --> 01:05:46.920
Ja, ja, hab ich gemacht.

01:05:48.220 --> 01:05:49.340
Das ist vielleicht noch nicht passiert.

01:05:50.000 --> 01:05:51.760
Also es ist sehr schön, wenn das halt irgendwie

01:05:51.760 --> 01:05:53.740
selbst auch in der Datenbank

01:05:53.740 --> 01:05:55.080
festgehalten wird, in welchem Zustand man ist.

01:05:56.260 --> 01:05:58.280
Ja, und das, jetzt so ein Framework

01:05:58.280 --> 01:05:59.920
wie Django bietet einem dafür halt

01:05:59.920 --> 01:06:02.260
kommen so wirklich relativ vollständige

01:06:02.260 --> 01:06:04.260
Wir merken wieder, du bist ein Django-Fan.

01:06:04.580 --> 01:06:05.600
Ja, ja, Art damit umzugehen.

01:06:06.060 --> 01:06:07.940
Ja, kann man Flask, wenn man jetzt das andere

01:06:07.940 --> 01:06:09.720
große Web

01:06:09.720 --> 01:06:12.180
ja, Framework kann man jetzt nicht

01:06:12.180 --> 01:06:14.200
da so wirklich zu sagen, aber das andere Paradigma,

01:06:14.320 --> 01:06:15.720
wie man Web-Anwendungen

01:06:15.720 --> 01:06:17.160
in Python entwickelt,

01:06:18.120 --> 01:06:19.680
wenn man das mit Flask macht, hat man das

01:06:19.680 --> 01:06:22.260
auch alles, ja, da gibt es dann SQL-Alchemy

01:06:22.260 --> 01:06:23.880
als ORM

01:06:23.880 --> 01:06:25.880
und halt, ich weiß jetzt nicht, das hat

01:06:25.880 --> 01:06:28.240
irgendeinen Namen, die Migrationslösung

01:06:28.240 --> 01:06:29.920
dafür, an den ich mich jetzt

01:06:29.920 --> 01:06:31.900
gerade nicht erinnere. Und da geht

01:06:31.900 --> 01:06:33.700
das alles auch. SQL Alchemy ist sogar deutlich

01:06:33.700 --> 01:06:35.800
mächtiger als der Django OAM,

01:06:36.120 --> 01:06:37.140
aber ist halt nicht integriert.

01:06:38.400 --> 01:06:39.720
Und, ja, also

01:06:39.720 --> 01:06:40.640
Flask ist auch super.

01:06:41.740 --> 01:06:43.200
Der Trade-Off ist halt so ein bisschen,

01:06:44.320 --> 01:06:45.680
was einen Django so

01:06:45.680 --> 01:06:46.940
abnimmt, ist halt, dass man

01:06:46.940 --> 01:06:49.760
sich halt um viele Abhängigkeiten nicht kümmern muss,

01:06:49.800 --> 01:06:51.860
weil man installiert halt Django und dann hat man halt einen Großteil

01:06:51.860 --> 01:06:52.660
von dem, was man so braucht.

01:06:53.580 --> 01:06:55.120
Und das wird halt dafür

01:06:55.120 --> 01:06:57.440
dass das alles konsistent bleibt und man

01:06:57.440 --> 01:06:59.480
upgraden kann und so, dafür wird gesorgt, da muss man selber

01:06:59.480 --> 01:07:01.340
sich nicht drum kümmern, wenn man jetzt Flask macht

01:07:01.340 --> 01:07:02.680
und dann halt ganz viele unterschiedliche

01:07:02.680 --> 01:07:04.420
Teile hat

01:07:04.420 --> 01:07:07.220
und die ihre Versionen ändern und so, dann muss man selber

01:07:07.220 --> 01:07:09.220
am Ball bleiben und auch Konflikte halt selber

01:07:09.220 --> 01:07:11.080
auflösen und das heißt, man hat so langfristig

01:07:11.080 --> 01:07:12.220
mehr zu tun damit

01:07:12.220 --> 01:07:15.340
aber dafür ist man halt auch flexibler und kann halt

01:07:15.340 --> 01:07:17.340
wenn einem eine bestimmte Art von ORM besser

01:07:17.340 --> 01:07:18.980
gefällt, den halt verwenden, es gibt halt auch

01:07:18.980 --> 01:07:21.460
zum Beispiel irgendwie neuere, also SQL Alchemy

01:07:21.460 --> 01:07:23.080
ist sehr alt, Django ORM ist relativ alt

01:07:23.080 --> 01:07:25.140
es gibt PV

01:07:25.140 --> 01:07:27.940
und PonyORM oder so, das sind jetzt

01:07:27.940 --> 01:07:30.360
modernere Geschichten, sieht besser aus

01:07:30.360 --> 01:07:32.120
macht unten drunter irgendwie was

01:07:32.120 --> 01:07:33.860
sehr ähnliches, aber ja

01:07:33.860 --> 01:07:35.960
genau, also

01:07:35.960 --> 01:07:38.240
ein Teil davon ist halt immer, wie man die Relationen

01:07:38.240 --> 01:07:40.000
und Tabellen definieren kann, das sind meistens

01:07:40.000 --> 01:07:41.060
Klassen, die man dann halt aufschreibt

01:07:41.060 --> 01:07:43.740
und dann erzeugt man daraus halt die Datenbankstruktur

01:07:43.740 --> 01:07:46.120
und der andere Teil vom ORM ist halt, wie man

01:07:46.120 --> 01:07:48.040
Abfragen auf die Datenbank halt abfeuert

01:07:48.040 --> 01:07:49.320
und

01:07:49.320 --> 01:07:51.860
das, was man eigentlich fast bei

01:07:51.860 --> 01:07:53.440
allen ORMs dann so macht, ist

01:07:53.440 --> 01:07:55.400
man

01:07:55.400 --> 01:07:57.620
macht so Method Chaining.

01:07:57.820 --> 01:07:59.120
Ich weiß nicht, sagt dir das was?

01:08:00.120 --> 01:08:01.260
Bis jetzt nicht.

01:08:01.920 --> 01:08:03.900
Ja, gibt's auch so oft in Data Science

01:08:03.900 --> 01:08:05.480
Pandas oder so, da macht man das auch.

01:08:07.520 --> 01:08:07.980
Also man

01:08:07.980 --> 01:08:09.900
kann in Python, ja man

01:08:09.900 --> 01:08:11.600
kann ja irgendwas sagen, so man hat ein Objekt, Punkt

01:08:11.600 --> 01:08:13.800
Methodenaufruf oder

01:08:13.800 --> 01:08:15.480
Punkt Attribut, Punkt

01:08:15.480 --> 01:08:17.340
wieder noch was anderes, Punkt wieder noch was anderes.

01:08:18.520 --> 01:08:19.740
Wenn zum Beispiel eine Methode

01:08:19.740 --> 01:08:21.700
ein Objekt zurückgibt, dann kann man auf diesem Objekt

01:08:21.700 --> 01:08:22.580
wieder was anderes aufrufen.

01:08:23.160 --> 01:08:25.520
Wenn ich das alles in eine Zeile schreibe, wird das irgendwann relativ lang.

01:08:25.760 --> 01:08:27.820
Aber wenn ich jetzt ein Statement modellieren

01:08:27.820 --> 01:08:29.600
möchte, das halt viele Where-Bedingungen hat,

01:08:30.500 --> 01:08:31.780
die Art, in Django-Organs

01:08:31.780 --> 01:08:33.420
das hinzuschreiben, wäre halt zu sagen, Filter

01:08:33.420 --> 01:08:35.340
irgendeine Spalte

01:08:35.340 --> 01:08:37.660
gleich

01:08:37.660 --> 01:08:39.120
irgendeinen Wert oder sowas.

01:08:39.640 --> 01:08:41.980
Aber dann habe ich noch ein zweites, dann sage ich Punkt, Filter, nächste Spalte

01:08:41.980 --> 01:08:43.060
wieder irgendeinen anderen Wert oder so.

01:08:45.000 --> 01:08:45.720
Und das wird halt

01:08:45.720 --> 01:08:47.580
relativ länglich. Daraus wird dann halt ein Statement

01:08:47.580 --> 01:08:49.680
generiert, aber was ich halt tun

01:08:49.680 --> 01:08:51.760
kann, ist zu sagen, Klammer auf

01:08:51.760 --> 01:08:53.860
und dann halt QuerySet.Filter

01:08:53.860 --> 01:08:55.760
Punkt

01:08:55.760 --> 01:08:56.980
Annotate

01:08:56.980 --> 01:08:59.560
und dann Dinge gruppieren

01:08:59.560 --> 01:09:01.280
oder so oder neue Spalte hinzufügen

01:09:01.280 --> 01:09:03.180
und ich mache

01:09:03.180 --> 01:09:05.520
noch eine weitere Klammer drumrum, dann kann ich das halt auch

01:09:05.520 --> 01:09:07.580
einrücken und dann rücke ich das so ein, dass

01:09:07.580 --> 01:09:09.520
alle Punkte untereinander stehen und dann habe ich halt so

01:09:09.520 --> 01:09:10.960
ein mehrzeiliges Dings,

01:09:11.760 --> 01:09:13.500
was so ein bisschen eine Zwischenform ist

01:09:13.500 --> 01:09:15.780
zwischen SQL und Python-Code.

01:09:18.500 --> 01:09:18.940
Ja.

01:09:19.680 --> 01:09:21.220
Aber ich spare

01:09:21.220 --> 01:09:23.000
mir dadurch sozusagen, dass jedes Mal

01:09:23.000 --> 01:09:24.660
irgendeine Zwischenvariable zuweisen zu müssen.

01:09:25.880 --> 01:09:27.040
Ansonsten könnte ich ja natürlich sagen

01:09:27.040 --> 01:09:29.000
QuerySet gleich QuerySet.Filter irgendwas

01:09:29.000 --> 01:09:31.120
und dann sage ich in der nächsten Zeile QuerySet gleich

01:09:31.120 --> 01:09:33.100
QuerySet.Filter

01:09:33.100 --> 01:09:34.560
noch irgendwie eine andere Spalte.

01:09:35.180 --> 01:09:36.080
Where irgendwas.

01:09:37.400 --> 01:09:38.840
Ich kann das aber auch alles in ein

01:09:38.840 --> 01:09:40.480
einziges Ding reinschreiben.

01:09:40.800 --> 01:09:43.460
Man nennt das Method Chaining.

01:09:45.020 --> 01:09:46.840
Ja, und das ist halt irgendwie das

01:09:46.840 --> 01:09:49.060
bei Pandas ist es halt

01:09:49.060 --> 01:09:51.040
genauso. Dann hat man Data Frames, auf denen man dann Sachen macht und

01:09:51.040 --> 01:09:53.100
die geben dann auch immer wieder ein Data Frame

01:09:53.100 --> 01:09:55.080
zurück, die viele der Methoden. Und die kann man

01:09:55.080 --> 01:09:57.140
halt auch so chainen. Und dann hat man da oft so mehrzahlige

01:09:57.140 --> 01:09:59.120
Dinge, wo halt die Punkte untereinander stehen. Also wenn man

01:09:59.120 --> 01:10:01.080
nicht weiß, was es ist, ist es Message Chaining. Und das ist halt

01:10:01.080 --> 01:10:02.400
so eine Methode, um

01:10:02.400 --> 01:10:05.000
Dinge halt in eine...

01:10:05.000 --> 01:10:06.740
Irgendwie schon mal so ein bisschen gesehen, aber so wirklich wissen, was das

01:10:06.740 --> 01:10:08.620
Message Chaining heißt, ist natürlich...

01:10:08.620 --> 01:10:11.200
Genau. Und im Grunde

01:10:11.200 --> 01:10:12.200
ist es halt dann, wenn man

01:10:12.200 --> 01:10:14.140
Queries in ORMs so macht,

01:10:15.140 --> 01:10:16.980
ist es halt so ein bisschen ein Zwischending zwischen

01:10:16.980 --> 01:10:20.460
SQL und Python, aber das funktioniert

01:10:20.460 --> 01:10:21.820
dann halt so halbwegs gut und das

01:10:21.820 --> 01:10:24.540
ist dann halt sehr angenehm.

01:10:24.620 --> 01:10:26.340
Und dann ist es nicht mehr ein Problem, wenn man jetzt

01:10:26.340 --> 01:10:28.580
sozusagen diese Art von Logik an unterschiedlichen Stellen

01:10:28.580 --> 01:10:30.460
im Code stehen hat, weil

01:10:30.460 --> 01:10:32.240
die Statements, die rausfallen, sind halt alle gleich.

01:10:32.660 --> 01:10:34.400
Und wenn ich jetzt irgendwie, keine Ahnung,

01:10:35.020 --> 01:10:35.960
mir überlege, dass

01:10:35.960 --> 01:10:38.640
ich eine bestimmte Art von Optimierung

01:10:38.640 --> 01:10:39.700
machen möchte an den Statements,

01:10:40.420 --> 01:10:41.360
dann wäre die halt

01:10:41.360 --> 01:10:43.140
auch immer gleich.

01:10:44.400 --> 01:10:46.460
Das heißt, dann habe ich halt dieses Problem,

01:10:46.800 --> 01:10:48.980
das ich sonst hätte, wenn ich das alles in einen File schreiben würde

01:10:48.980 --> 01:10:51.860
oder wenn ich fast gleiche Statements

01:10:51.860 --> 01:10:54.100
in unterschiedliche Files schreiben würde,

01:10:54.160 --> 01:10:55.620
wenn ich die Statements beim Code haben will,

01:10:56.040 --> 01:10:57.160
das habe ich damit dann nicht mehr.

01:10:57.260 --> 01:10:58.460
Und das ist natürlich ein sehr schöner Effekt.

01:10:59.000 --> 01:11:01.680
Das ist halt einer der Hauptnutzen von OEMs.

01:11:01.940 --> 01:11:03.660
Also ein anderer schöner Nutzen ist halt,

01:11:03.720 --> 01:11:05.160
dass man halt diese ganze Migrationsgeschichte,

01:11:05.240 --> 01:11:07.000
wie ändern sich Sachen, halt auch automatisiert hat

01:11:07.000 --> 01:11:08.460
beziehungsweise die ganzen Prozesse drumherum

01:11:08.460 --> 01:11:10.380
irgendwie zumindest mal abgebildet hat.

01:11:11.580 --> 01:11:12.640
Ja, die sind wieder klein und niedlich

01:11:12.640 --> 01:11:13.340
und das haben wir jetzt gemacht.

01:11:13.340 --> 01:11:16.100
Genau, und da würde so ein Framework werden in OEM

01:11:16.100 --> 01:11:24.280
Und dann ist man eigentlich, das geht alles ins Git, es gibt Versionskontrolle dafür und das ist eigentlich alles schon relativ komfortabel.

01:11:30.400 --> 01:11:35.980
Ja, was passiert jetzt? Also wir sind klein und jetzt haben wir das schon gebaut, aber wann funktioniert das denn nicht mehr so?

01:11:36.760 --> 01:11:59.340
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.

01:12:01.100 --> 01:12:03.520
schreibt er da, dass Amazon

01:12:03.520 --> 01:12:05.400
macht die Hälfte des Umsatzes

01:12:05.400 --> 01:12:07.500
mit Büchern, die nicht in den Top 300.000

01:12:07.500 --> 01:12:07.760
sind.

01:12:10.960 --> 01:12:11.480
Weil

01:12:11.480 --> 01:12:13.220
eben Bücher verkaufen

01:12:13.220 --> 01:12:14.600
so ein

01:12:14.600 --> 01:12:16.940
oder verkaufen die Bücher halt so

01:12:16.940 --> 01:12:19.480
eine Longtail-Verteilung. Also es gibt

01:12:19.480 --> 01:12:21.400
halt sehr, Leute

01:12:21.400 --> 01:12:23.200
wollen sehr unterschiedliche Bücher kaufen.

01:12:23.320 --> 01:12:25.420
Es werden viele Bücher verkauft, aber von

01:12:25.420 --> 01:12:26.080
denen nur ganz wenige.

01:12:27.420 --> 01:12:29.360
Und das ist halt blöd für einen

01:12:29.360 --> 01:12:31.500
Laden, der die Bücher halt physisch

01:12:31.500 --> 01:12:33.580
vorhalten muss, weil auch selbst wenn Bücher nicht so groß

01:12:33.580 --> 01:12:35.300
sind, ich kann halt in so einem

01:12:35.300 --> 01:12:37.360
Innenstadtbuchladen

01:12:37.360 --> 01:12:38.920
kann ich halt irgendwie ein paar tausend Bücher haben

01:12:38.920 --> 01:12:41.340
und dann ist halt irgendwie Schluss

01:12:41.340 --> 01:12:43.380
und ich muss mir überlegen, welche das sind, aber wenn

01:12:43.380 --> 01:12:45.020
jetzt, also nehmen wir an

01:12:45.020 --> 01:12:47.140
Das hat aber auch ein Zielpublikum, das heißt ich weiß genau, hey

01:12:47.140 --> 01:12:49.040
in mir kommen jetzt nur ganz viele alte

01:12:49.040 --> 01:12:51.320
antiquarische interessierte Menschen

01:12:51.320 --> 01:12:53.340
rein, dann sollte ich vielleicht dafür sorgen,

01:12:53.340 --> 01:12:55.320
dass in meinem Laden viele antiquarische Bücher

01:12:55.320 --> 01:12:57.320
sind oder es kommen jetzt noch ganz viele hippe Leute

01:12:57.320 --> 01:12:59.580
rein, die wollen alle was über IT wissen, sollte ich vielleicht ein IT-Buch laden.

01:12:59.600 --> 01:13:00.960
Ja, aber selbst

01:13:00.960 --> 01:13:03.040
wenn du jetzt all diese Zielgruppen

01:13:03.040 --> 01:13:05.120
zusammennimmst und dann irgendwie den riesigsten

01:13:05.120 --> 01:13:07.060
also das ist halt das Problem,

01:13:07.280 --> 01:13:09.220
wenn die Zielgruppe zu klein ist, dann lohnt

01:13:09.220 --> 01:13:10.700
sich das nicht, aber wenn sie

01:13:10.700 --> 01:13:13.100
selbst, wenn du jetzt einen riesigen Buchladen hast, in den

01:13:13.100 --> 01:13:15.120
300.000 Bücher passen, was ziemlich groß sein

01:13:15.120 --> 01:13:16.760
müsste, dann

01:13:16.760 --> 01:13:18.960
machst du immer nur trotzdem noch

01:13:18.960 --> 01:13:20.920
die Hälfte des Umsatzes von Amazon, weil

01:13:20.920 --> 01:13:23.100
Amazon macht halt nochmal so viel

01:13:23.100 --> 01:13:24.920
Umsatz mit dem ganzen Rest. Das heißt, sie haben dann

01:13:24.920 --> 01:13:26.860
sie können einfach viel besser skalieren

01:13:26.860 --> 01:13:29.220
weil sie einfach viel mehr Bücher verkaufen

01:13:29.220 --> 01:13:31.860
und ja, ich wüsste

01:13:31.860 --> 01:13:33.460
nicht, dass es da irgendein Mittel gegeben gibt

01:13:33.460 --> 01:13:35.620
ich fürchte, was aber auch bedeuten würde, dass Amazon

01:13:35.620 --> 01:13:37.660
auch diese Minus 1 Bestellung annehmen müsste, weil das müssen

01:13:37.660 --> 01:13:39.740
sie auch irgendwo in einem riesigen Lager jedes Buch liegen

01:13:39.740 --> 01:13:41.460
haben, ja, müssen sie tatsächlich wahrscheinlich

01:13:41.460 --> 01:13:43.620
oder sie müssen es halt on demand irgendwie drucken können

01:13:43.620 --> 01:13:45.660
oder so, gut klar, sie müssen

01:13:45.660 --> 01:13:47.460
damit irgendwie umgehen, auch der

01:13:47.460 --> 01:13:49.680
stationäre Buchhandel geht ja irgendwie dann damit um

01:13:49.680 --> 01:13:51.440
so damit um, dass man dann halt Sachen da bestellt

01:13:51.440 --> 01:13:53.600
zum Beispiel, hey Autor, schreib doch bitte

01:13:53.600 --> 01:13:55.660
nochmal eine neue Folge, wir haben ja so ein paar

01:13:55.660 --> 01:13:56.240
Bestellung, ja.

01:13:57.760 --> 01:13:59.720
Aber, ja,

01:13:59.940 --> 01:14:01.560
ich meine, du hast halt als

01:14:01.560 --> 01:14:04.260
stationärer Buchhandlung

01:14:04.260 --> 01:14:05.980
hast du ja keinen Vorteil mehr, wenn du dann auch wieder

01:14:05.980 --> 01:14:08.180
bestellst, weil dann machst du halt zwei Sachen

01:14:08.180 --> 01:14:09.780
und die eine, ja, und dann

01:14:09.780 --> 01:14:11.220
als Amazon hast du einfach

01:14:11.220 --> 01:14:14.060
einen strukturellen Vorteil, fürchte ich.

01:14:14.740 --> 01:14:15.900
Okay, und dann kannst du...

01:14:15.900 --> 01:14:18.280
Es ist cool, weil dann können wir einfach mit unserer Postgres-Lösung direkt so

01:14:18.280 --> 01:14:19.880
unter dem ORM... Genau.

01:14:20.160 --> 01:14:21.980
Die interessante... Also mit 3.000

01:14:21.980 --> 01:14:24.140
Millionen ist das überhaupt kein Problem. Also da

01:14:24.140 --> 01:14:26.060
könnten wir auch, also ich würde sagen, so ein Markt wie

01:14:26.060 --> 01:14:27.900
Deutschland kannst du wahrscheinlich tatsächlich mit einer Datenbank

01:14:27.900 --> 01:14:29.580
und mit allen Büchern, die es überhaupt gibt,

01:14:30.140 --> 01:14:31.900
locker bedienen. Das ist kein so

01:14:31.900 --> 01:14:32.540
großes Problem.

01:14:34.440 --> 01:14:35.840
Wenn es jetzt nur darum geht,

01:14:35.900 --> 01:14:37.600
die Bücher zu verkaufen. Aber

01:14:37.600 --> 01:14:39.700
wenn wir jetzt

01:14:39.700 --> 01:14:41.820
zum Beispiel eben sowas rauskriegen wollen,

01:14:41.980 --> 01:14:43.900
wie, was sind eigentlich

01:14:43.900 --> 01:14:44.880
die Top 300.000 Bücher?

01:14:46.040 --> 01:14:47.420
Wo kommt denn diese Zahl eigentlich her?

01:14:48.400 --> 01:14:48.820
Ja, und

01:14:48.820 --> 01:14:51.820
überhaupt rauszukriegen, okay, wir machen die Hälfte unseres Umsatzes

01:14:51.820 --> 01:14:53.980
mit Büchern, die nicht in den Top 300.000

01:14:53.980 --> 01:14:55.980
ziehen, dann müssen

01:14:55.980 --> 01:14:57.640
wir nicht nur die Bücher

01:14:57.640 --> 01:14:59.760
speichern, sondern dann müssen wir halt auch

01:14:59.760 --> 01:15:01.860
speichern zum Beispiel, welche

01:15:01.860 --> 01:15:03.680
Bücher gekauft worden sind und so, also

01:15:03.680 --> 01:15:05.040
die Historie aller Bestellungen und so.

01:15:05.980 --> 01:15:07.780
Und das ist dann halt unter Umständen viel, viel

01:15:07.780 --> 01:15:07.960
mehr.

01:15:09.740 --> 01:15:11.960
Und dann wird es allmählich

01:15:11.960 --> 01:15:13.080
problematisch, weil dann haben wir

01:15:13.080 --> 01:15:15.460
unterschiedliche Use Cases

01:15:15.460 --> 01:15:17.440
oder unterschiedliche Abfragemuster.

01:15:18.000 --> 01:15:19.020
Also wir haben zum Beispiel diese

01:15:19.020 --> 01:15:21.440
Transaktions...

01:15:21.440 --> 01:15:23.660
Also das Lager, das einfach immer noch weiß, welche Bücher

01:15:23.660 --> 01:15:24.520
Wir sind da und das finden wir raus.

01:15:24.660 --> 01:15:27.800
Das System, das macht halt Bestellungen

01:15:27.800 --> 01:15:29.540
oder wir haben halt Anfragen, die Bestellungen machen

01:15:29.540 --> 01:15:31.580
oder solche Sachen wie, zeig mir alle Bücher

01:15:31.580 --> 01:15:33.380
in Seefacher Romane oder so.

01:15:35.200 --> 01:15:35.600
Aber

01:15:35.600 --> 01:15:37.480
diese Art von Anfragen,

01:15:37.660 --> 01:15:39.760
wie, sag mir mal, wie viel Umsatz ich mit

01:15:39.760 --> 01:15:40.120
den

01:15:40.120 --> 01:15:43.660
nicht in Top 300.000 enthaltenen

01:15:43.660 --> 01:15:45.000
Bücher im letzten Jahr gemacht habe.

01:15:45.620 --> 01:15:47.640
Das ist eine ganz andere Art von Anfrage.

01:15:49.480 --> 01:15:51.440
Die Anfragen vorher, die machen immer nur

01:15:51.440 --> 01:15:53.440
auf kleinen Datenmengen in der Datenbank irgendwas.

01:15:53.600 --> 01:15:54.820
immer zeilenweise meistens.

01:15:55.780 --> 01:15:59.300
Und oft ändern sie auch irgendwas oder schreiben irgendwas.

01:15:59.600 --> 01:16:03.380
Aber gut, die große Mehrheit wird Read-Anfragen sein.

01:16:03.600 --> 01:16:07.760
Aber die beziehen sich normalerweise nicht auf wahnsinnig viele Zeilen,

01:16:07.860 --> 01:16:10.360
sondern immer nur relativ wenige oder wenige tausend Zeilen.

01:16:11.240 --> 01:16:13.640
Und eben operieren halt auch ja zeilenweise.

01:16:13.640 --> 01:16:16.780
Während diese andere Anfrage jetzt dieses, wie viel Umsatz,

01:16:18.340 --> 01:16:20.700
ja, das ist halt dann nur noch eine Spalte aus den Bestellungen.

01:16:21.100 --> 01:16:23.220
Und dann auch, geht es wahrscheinlich

01:16:23.220 --> 01:16:25.080
aber über lange Zeiträume,

01:16:25.200 --> 01:16:26.860
über ein Jahr, mehrere Jahre

01:16:26.860 --> 01:16:28.760
und dann halt über alle Bücher.

01:16:30.120 --> 01:16:30.980
Das ist eine Anfrage,

01:16:31.120 --> 01:16:32.980
die geht halt über ganz, ganz, ganz, ganz,

01:16:32.980 --> 01:16:33.740
ganz viele Zeilen.

01:16:35.020 --> 01:16:36.560
So, und jetzt beißen sich die, diese

01:16:36.560 --> 01:16:38.700
Abfrage-Muster beißen sich halt massiv.

01:16:40.140 --> 01:16:41.140
Also, weil

01:16:41.140 --> 01:16:43.240
das Problem ist, dass die Datenbank

01:16:43.240 --> 01:16:45.300
irgendwie gewährleisten muss, dass deine Sicht

01:16:45.300 --> 01:16:46.780
auf die Welt, also auf die Datenbank,

01:16:47.260 --> 01:16:48.940
konsistent bleibt, während die Anfrage läuft.

01:16:49.080 --> 01:16:50.680
Die Anfrage läuft jetzt aber wahrscheinlich relativ lang.

01:16:50.680 --> 01:16:53.160
muss ich irgendwie alle Daten, die in der Datenbank liegen

01:16:53.160 --> 01:16:54.700
oder einen Großteil davon muss sie sich angucken,

01:16:55.020 --> 01:16:56.260
wenn sie dir hinterher so was sagen,

01:16:56.600 --> 01:16:58.640
eine Zahl geben will, wie viel Umsatz waren das jetzt so.

01:17:01.100 --> 01:17:03.100
Und währenddessen werden aber Bestellungen

01:17:03.100 --> 01:17:05.000
abgearbeitet oder werden Dinge gemacht, Sachen an der

01:17:05.000 --> 01:17:05.640
Datenbank geändert,

01:17:06.280 --> 01:17:08.200
die jetzt aber nicht direkt

01:17:08.200 --> 01:17:10.800
durchschlagen können auf deine Anfrage, sondern da werden

01:17:10.800 --> 01:17:11.680
immer nur Kopien gemacht.

01:17:12.880 --> 01:17:14.820
Und es wird dann halt ein Timestamp

01:17:14.820 --> 01:17:16.660
reingeschrieben, es wird halt das Multiversion

01:17:16.660 --> 01:17:17.580
Concurrency Control.

01:17:19.240 --> 01:17:19.640
Multiversen!

01:17:20.220 --> 01:17:26.080
Das heißt, die Datenbank

01:17:26.080 --> 01:17:28.900
ist halt in einem unterschiedlichen Zustand,

01:17:29.000 --> 01:17:30.920
je nachdem, wer gerade fragt.

01:17:30.980 --> 01:17:32.740
Und für die Transaktionen, die eine Bestellung ausführen, ist sie jetzt

01:17:32.740 --> 01:17:34.720
in einem anderen Zustand als für dieses langlaufende

01:17:34.720 --> 01:17:36.860
Query. Und das Problem ist halt, je länger

01:17:36.860 --> 01:17:38.960
diese Query läuft, umso länger muss die Datenbank

01:17:38.960 --> 01:17:41.140
jetzt mehrere Versionen ihrer selbst aufrechterhalten.

01:17:41.320 --> 01:17:42.780
Was dazu führt, dass du halt auch

01:17:42.780 --> 01:17:44.860
mehr Speicher brauchst und was halt eine komplizierte

01:17:44.860 --> 01:17:46.540
Geschichte ist. Und das ist halt, ja,

01:17:46.680 --> 01:17:48.760
wenn das Problem ist, wahrscheinlich wird man dann halt

01:17:48.760 --> 01:17:50.600
irgendwann sehen, man wird so mit einfachen Analysegeschichten

01:17:50.600 --> 01:17:52.600
anfragen und irgendwann wird man halt merken, so morgens

01:17:52.600 --> 01:17:54.320
um neun, wenn dann halt irgendwie die

01:17:54.320 --> 01:17:56.640
Business Intelligence

01:17:56.640 --> 01:17:57.680
Abteilung irgendwie anfängt,

01:17:58.560 --> 01:18:00.600
wenn da die Analysten sitzen und dann irgendwie, ja gut,

01:18:00.820 --> 01:18:02.580
ich weiß nicht, am Anfang wird man sowas noch nicht haben, aber

01:18:02.580 --> 01:18:04.460
irgendwann hat man das vielleicht dann, wenn die halt ihre

01:18:04.460 --> 01:18:05.600
Analyse-Querys abschießen,

01:18:06.500 --> 01:18:08.340
dann wird plötzlich die Webseite langsam.

01:18:09.220 --> 01:18:10.520
Ja, weil halt die Datenbank langsam

01:18:10.520 --> 01:18:12.640
wird, weil die Queries werden langsam, weil plötzlich

01:18:12.640 --> 01:18:14.720
muss die Datenbank

01:18:14.720 --> 01:18:16.300
irgendwie mit mehreren

01:18:16.300 --> 01:18:18.320
Zuständen irgendwie

01:18:18.320 --> 01:18:19.280
rumjonglieren.

01:18:20.400 --> 01:18:22.560
Ja, das ist blöd. Und dann muss man sich halt

01:18:22.560 --> 01:18:24.420
was überlegen. Und

01:18:24.420 --> 01:18:25.920
das ist dann halt so der Moment,

01:18:26.380 --> 01:18:28.400
wo man dann sagen muss, okay,

01:18:28.520 --> 01:18:30.680
wir können das nicht mehr. Es wäre schön, alles in einer Datenbank

01:18:30.680 --> 01:18:32.500
zu haben, aber das geht nicht. Diese beiden Use Cases

01:18:32.500 --> 01:18:34.480
sind so unterschiedlich, dass man das leider

01:18:34.480 --> 01:18:36.600
nur dadurch ordentlich abgebildet kriegt,

01:18:36.660 --> 01:18:38.460
dass man das halt in unterschiedliche Systeme packt.

01:18:40.100 --> 01:18:40.460
Und

01:18:40.460 --> 01:18:42.500
ja, also das eine nennt man

01:18:42.500 --> 01:18:44.320
auch irgendwie OLP,

01:18:44.880 --> 01:18:46.700
Online Transaction Processing,

01:18:47.080 --> 01:18:48.540
Das ist halt sozusagen der

01:18:48.540 --> 01:18:51.080
Webseite, also Datenbank ist hinter einer Webseite,

01:18:51.180 --> 01:18:52.900
die irgendwie Bücher verkauft und prozessiert

01:18:52.900 --> 01:18:55.040
Transaktionen, Bestellungen. Und der andere

01:18:55.040 --> 01:18:56.980
Teil nennt sich OLAP,

01:18:57.480 --> 01:18:59.220
Online Analytical

01:18:59.220 --> 01:19:01.140
Processing. Und

01:19:01.140 --> 01:19:03.100
ist halt das so, wenn man das mal

01:19:03.100 --> 01:19:04.880
gehört hat, wenn Leute über Data Warehousing

01:19:04.880 --> 01:19:07.000
sprechen oder Data Warehouses oder so, das ist halt das.

01:19:09.520 --> 01:19:09.960
Und

01:19:09.960 --> 01:19:12.880
genau, das sind beides

01:19:12.880 --> 01:19:14.940
meistens relationale Datenbanken, wenn man

01:19:14.940 --> 01:19:15.640
anfängt jedenfalls.

01:19:17.080 --> 01:19:19.500
Aber die sehen unterschiedlich aus.

01:19:20.420 --> 01:19:22.740
Also die haben unterschiedliche Anfragen werden gestellt.

01:19:23.200 --> 01:19:28.420
Analyseanfragen laufen oft länger, gucken sich viele Zeilen an.

01:19:29.840 --> 01:19:33.960
Transaktionsanfragen sind oft kurz und gucken sich wenige Zeilen an.

01:19:34.160 --> 01:19:35.740
Und da geht es auch darum, dass die Latenz relativ kurz ist.

01:19:35.740 --> 01:19:37.680
Bei vielen Analyseanfragen ist es gar nicht so wichtig,

01:19:38.860 --> 01:19:41.560
dass sie jetzt eine Minute länger oder weniger lang laufen.

01:19:41.660 --> 01:19:43.140
Das ist gar nicht so entscheidend.

01:19:43.400 --> 01:19:45.880
Und auch die Analyse-Datenbanken sind oft viel, viel größer,

01:19:45.960 --> 01:19:47.400
weil man halt historische Daten mit drin hat,

01:19:48.360 --> 01:19:49.900
was halt für eine Transaktionsdatenbank

01:19:49.900 --> 01:19:51.520
tödlich wäre, weil bei der ist

01:19:51.520 --> 01:19:53.280
möglichst das komplette

01:19:53.280 --> 01:19:56.100
Working Set der Datenbank

01:19:56.100 --> 01:19:57.900
im Hauptspeicher, damit das halt alles schnell geht,

01:19:58.000 --> 01:19:59.280
damit die Latenz

01:19:59.280 --> 01:20:01.680
niedrig bleibt, damit halt die Webseite

01:20:01.680 --> 01:20:03.860
sich schön snappy

01:20:03.860 --> 01:20:04.520
irgendwie anfühlt.

01:20:06.660 --> 01:20:07.140
Und bei

01:20:07.140 --> 01:20:09.260
den Analyse-Datenbanken ist aber

01:20:09.260 --> 01:20:11.760
unter Umständen wichtig, dass ich halt historische Daten

01:20:11.760 --> 01:20:13.580
da halt auch mit drin haben kann. Und die

01:20:13.580 --> 01:20:15.640
werden dann halt vielleicht so groß, dass man das halt nicht mehr im Hauptspeicher

01:20:15.640 --> 01:20:16.080
halten kann.

01:20:17.400 --> 01:20:18.460
Ja, aber...

01:20:18.460 --> 01:20:21.460
Die Queries werden dann halt langsam, aber das

01:20:21.460 --> 01:20:23.760
ist halt möglicherweise wichtiger, historische Daten

01:20:23.760 --> 01:20:25.260
zu haben, als dass Queries halt schnell sind.

01:20:25.900 --> 01:20:27.640
Und dann, wenn

01:20:27.640 --> 01:20:29.480
sich eine Query irgendwie ein paar Millionen

01:20:29.480 --> 01:20:31.340
oder paar Zehn Millionen Zeilen anguckt, dann ist es eh nicht mehr schnell,

01:20:31.420 --> 01:20:33.520
selbst wenn es ein Hauptspeicher ist. Und ob es dann jetzt eine Minute

01:20:33.520 --> 01:20:35.340
oder zwei Minuten dauert, das hat dann auch irgendwie wurscht.

01:20:36.400 --> 01:20:37.700
Ja, genau.

01:20:37.700 --> 01:20:39.600
Und dann hat man eben diese beiden

01:20:39.600 --> 01:20:41.660
unterschiedlichen Systeme und dann kriegt man halt aber auch

01:20:41.660 --> 01:20:43.120
genau diese Probleme, die man dann hat,

01:20:43.480 --> 01:20:58.580
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.

01:20:59.920 --> 01:21:06.940
Das heißt, man muss jetzt zum Beispiel die Transaktionen, die irgendwie in dem einen System aufgelaufen sind, überführen in das Analysesystem.

01:21:07.660 --> 01:21:12.860
Das macht man üblicherweise bei einem Prozess, der nennt sich ETL, Extract, Transform, Load.

01:21:13.480 --> 01:21:30.660
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.

01:21:30.660 --> 01:21:34.900
dann ist der Transformationsprozess halt sowas wie,

01:21:34.980 --> 01:21:36.560
ich muss die Daten in ein anderes Schema transformieren.

01:21:37.180 --> 01:21:40.160
Und das ist halt so wie so Stern-Star-Schema

01:21:40.160 --> 01:21:41.880
oder Snowflake-Schema, je nachdem.

01:21:43.300 --> 01:21:45.920
Das ist auch irgendwie gewisserweise normalisiert

01:21:45.920 --> 01:21:47.740
oder man kann auch sagen, denormalisiert, je nachdem.

01:21:49.100 --> 01:21:50.240
Aber es ist halt auf jeden Fall anders.

01:21:50.780 --> 01:21:51.800
Es ist halt davon optimiert,

01:21:51.840 --> 01:21:53.660
dass ich bestimmte Arten von Analysen fahren kann

01:21:53.660 --> 01:21:59.660
und lädt das Ganze halt in die Analyse,

01:22:00.660 --> 01:22:02.740
Datenbanksystem. Für deine BI.

01:22:03.540 --> 01:22:03.780
Genau.

01:22:05.100 --> 01:22:05.220
Ja.

01:22:06.420 --> 01:22:08.440
Und ja,

01:22:09.300 --> 01:22:10.740
das ist halt

01:22:10.740 --> 01:22:12.620
immer so ein bisschen fies

01:22:12.620 --> 01:22:14.560
alles. Aber ja, bleibt einem halt nichts übrig,

01:22:14.640 --> 01:22:16.480
muss man irgendwie machen. Wie würden wir das denn jetzt machen?

01:22:16.560 --> 01:22:18.540
Wenn wir Python jetzt haben, jetzt haben wir ja irgendwie so ein neues System

01:22:18.540 --> 01:22:20.580
und jetzt haben wir eigentlich irgendwie, das ist unser

01:22:20.580 --> 01:22:22.640
OLTP-Datenbanksystem,

01:22:22.640 --> 01:22:24.540
das haben wir aufgebaut mit den Transaktionen für unsere Webseite.

01:22:24.900 --> 01:22:26.440
Was bauen wir denn da, damit wir jetzt so ein

01:22:26.440 --> 01:22:28.220
OLAP-Ding dranhängen können, weil wir die

01:22:28.220 --> 01:22:29.900
Analytics-Abteilung einstellen. Ja, machen wir auch mit

01:22:29.900 --> 01:22:31.500
Postgres so ein Ding.

01:22:32.420 --> 01:22:34.360
Also eine zweite Postgres-Datenbank, die eben die erste packen.

01:22:34.520 --> 01:22:36.140
Ja, genau. Die halt ein bisschen anders aussieht.

01:22:36.180 --> 01:22:37.460
Die hat dann vielleicht nicht ganz so viele Hauptspeicher,

01:22:37.560 --> 01:22:40.120
aber dafür halt irgendwie mehr Plattenplatz

01:22:40.120 --> 01:22:42.120
und auch irgendwie Storage

01:22:42.120 --> 01:22:43.720
möglicherweise in unterschiedlicher Qualität.

01:22:44.440 --> 01:22:46.180
Wenn man sagt, okay, vielleicht

01:22:46.180 --> 01:22:48.100
für die letzte Woche haben wir alle Daten

01:22:48.100 --> 01:22:50.080
noch im Hauptspeicher, ja, dann aber für den letzten

01:22:50.080 --> 01:22:52.060
Monat oder für die letzten sechs Monate haben wir

01:22:52.060 --> 01:22:53.960
die halt auf SSDs oder so, auf ein System,

01:22:54.060 --> 01:22:55.520
was halt noch schnell, weil

01:22:55.520 --> 01:22:57.880
der größte Teil der Queries geht

01:22:57.880 --> 01:22:59.600
natürlich auf Daten, die relativ aktuell sind.

01:22:59.900 --> 01:23:12.000
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.

01:23:12.380 --> 01:23:14.480
Und diese Art von Queries muss dann halt ein bisschen warten.

01:23:15.940 --> 01:23:23.400
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.

01:23:23.400 --> 01:23:28.880
Und klar ist auch wichtig, dass Sachen schnell geschrieben werden, deswegen muss das, wo was hingeschrieben wird, muss halt auch sackschnell sein.

01:23:29.740 --> 01:23:30.920
Also da würde man auch eher lieber dann

01:23:30.920 --> 01:23:32.520
schnelle SSDs nehmen, aber

01:23:32.520 --> 01:23:34.880
es ist halt nicht wichtig, viel mehr

01:23:34.880 --> 01:23:36.900
Plattenplatz zu haben, als man Hauptspeicher hat, weil

01:23:36.900 --> 01:23:37.580
das will man ja eh nicht.

01:23:39.860 --> 01:23:40.220
Ja.

01:23:42.860 --> 01:23:43.220
Und

01:23:43.220 --> 01:23:45.380
genau, diese LTE-Prozesse

01:23:45.380 --> 01:23:46.840
sind dann halt irgendwelche Skripte, die dann halt

01:23:46.840 --> 01:23:48.880
irgendwie über irgendeine Task

01:23:48.880 --> 01:23:50.200
ja

01:23:50.200 --> 01:23:52.720
Das bedeutet natürlich dann, dass unser

01:23:52.720 --> 01:23:55.080
Intelligent System also jetzt nicht sekundengenau

01:23:55.080 --> 01:23:56.780
funktioniert, in dem Fall.

01:23:56.880 --> 01:23:58.660
Weil wir halt immer wieder diese Jobs machen müssen.

01:23:59.080 --> 01:24:00.780
wenn ich jetzt an was ganz anderes denke,

01:24:00.880 --> 01:24:02.360
weiß ich nicht, Aktienkursanalyse oder sowas,

01:24:02.420 --> 01:24:03.280
wir haben irgendwelche Portfolios,

01:24:03.440 --> 01:24:05.080
dann ist das natürlich dann doof,

01:24:05.320 --> 01:24:09.040
weil dann das nicht dem echten Stockmarket entspricht,

01:24:09.380 --> 01:24:10.700
sondern man müsste es halt dann jedes Mal

01:24:10.700 --> 01:24:11.680
eine neue Kopie machen,

01:24:11.720 --> 01:24:12.700
wenn man diese Analytics fahren will.

01:24:12.980 --> 01:24:14.080
Ja, genau.

01:24:14.240 --> 01:24:16.560
Also natürlich, das ist tatsächlich ein Problem.

01:24:17.460 --> 01:24:20.520
Und die Lösung dafür ist,

01:24:20.580 --> 01:24:23.260
dass man dann halt irgendwann nicht mehr so ETL

01:24:23.260 --> 01:24:24.280
in dem Sinne macht,

01:24:24.280 --> 01:24:25.920
dass man das halt irgendwie abends Batch-Processing macht,

01:24:26.720 --> 01:24:29.060
sondern dass man halt irgendwie so Streaming

01:24:29.060 --> 01:24:31.160
Geschichten verwendet, halt

01:24:31.160 --> 01:24:33.440
Apache Kafka und so ist halt etwas, was häufig

01:24:33.440 --> 01:24:35.400
verwendet wird. Aber da kommen wir später zu, weil

01:24:35.400 --> 01:24:36.860
das ist auch eine Geschichte, wo man

01:24:36.860 --> 01:24:38.560
dann, das wird halt eh

01:24:38.560 --> 01:24:39.980
erst dann relevant,

01:24:41.180 --> 01:24:43.300
wenn man dann nochmal ein gutes Stück größer

01:24:43.300 --> 01:24:45.140
geworden ist und man mit diesen traditionellen

01:24:45.140 --> 01:24:46.700
Data-Warehouse-Geschichten auch nicht mehr klarkommt.

01:24:47.080 --> 01:24:48.580
Und der Weltbeherrschung ist unikat.

01:24:49.100 --> 01:24:50.980
Ja, genau. Dazu muss man dann schon mal

01:24:50.980 --> 01:24:53.320
noch ein bisschen, oder halt eine andere Art von Daten sammelt.

01:24:54.220 --> 01:24:55.000
Also ich würde sagen,

01:24:55.060 --> 01:24:57.040
dieser klassische Bereich,

01:24:57.380 --> 01:25:05.320
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.

01:25:05.480 --> 01:25:09.520
Selbst das wird einem da schon einen deutlichen Vorteil verschaffen.

01:25:09.520 --> 01:25:18.140
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.

01:25:19.460 --> 01:25:23.420
Und genau, ja, da ist man halt irgendwie so bei diesem Data Warehousing Thema.

01:25:23.540 --> 01:25:24.540
Ich habe das mal irgendwann

01:25:24.540 --> 01:25:29.440
das ist auch in den Shownotes verlinkt,

01:25:29.500 --> 01:25:30.720
gibt es einen schönen Essay,

01:25:32.600 --> 01:25:33.720
der heißt

01:25:33.720 --> 01:25:35.060
Data Warehousing for Cavemen.

01:25:35.600 --> 01:25:37.300
Das ist von 1997 oder so.

01:25:38.820 --> 01:25:39.220
Aber

01:25:39.220 --> 01:25:41.700
das finde ich nach wie vor gut, ist auch relativ

01:25:41.700 --> 01:25:43.860
humorvoll. Da geht es darum,

01:25:45.320 --> 01:25:45.620
der schreibt

01:25:45.620 --> 01:25:47.740
auch so, vielleicht interessiert es manche Leute irgendwie, wie man

01:25:47.740 --> 01:25:49.760
300 Dollar die Stunde verdienen kann,

01:25:49.760 --> 01:25:51.700
indem man die sensibelsten Daten von irgendwelchen

01:25:51.700 --> 01:25:53.300
Firmen massiert. Muss ich sofort wissen, ja.

01:25:53.540 --> 01:25:56.520
Genau, beim Freelance ist das vielleicht gar nicht so uninteressant.

01:25:57.380 --> 01:25:58.100
Ja, und

01:25:58.100 --> 01:26:00.180
also das ist auch ein Feld, das es schon lange gibt.

01:26:00.700 --> 01:26:02.060
Ich habe das am Anfang aber auch nicht,

01:26:02.720 --> 01:26:04.500
ich habe zuerst nur diesen OTP-Use-Case

01:26:04.500 --> 01:26:06.120
gekannt und dann bin ich irgendwann

01:26:06.120 --> 01:26:07.880
auf diesen Essay gestoßen und dachte so, oh, das ist aber interessant.

01:26:09.000 --> 01:26:10.200
Und daraufhin halt dann auch

01:26:10.200 --> 01:26:12.400
so angefangen, mich so ein bisschen mit der Terrarism-Kram zu beschäftigen.

01:26:12.500 --> 01:26:13.860
Aber es ist auch ein sehr interessantes Thema.

01:26:14.060 --> 01:26:16.060
Der entscheidende Punkt ist im Grunde,

01:26:16.060 --> 01:26:17.940
dass man halt solche Abfragen machen

01:26:17.940 --> 01:26:18.980
können möchte, wie

01:26:18.980 --> 01:26:22.100
also wie unterscheidet sich denn

01:26:22.100 --> 01:26:24.100
jetzt, keine Ahnung, das

01:26:24.100 --> 01:26:26.140
Volumen der verkauften Bücher in einer bestimmten Kategorie,

01:26:26.400 --> 01:26:27.880
nachdem ich irgendeine Werbeaktion gemacht habe.

01:26:28.140 --> 01:26:30.140
Oder A-B-Tests.

01:26:30.360 --> 01:26:31.700
Ich habe jetzt irgendwie manchen Usern

01:26:31.700 --> 01:26:34.120
eine bestimmte...

01:26:34.120 --> 01:26:36.140
Die haben halt ein Design gesehen, das ein bisschen anders

01:26:36.140 --> 01:26:38.140
aussah oder halt ein bisschen

01:26:38.140 --> 01:26:40.120
anders... Oder alle Leute, die letzte Woche gekauft haben

01:26:40.120 --> 01:26:42.140
für ein bestimmtes Produkt, die bekommen jetzt

01:26:42.140 --> 01:26:43.980
einen besonderen Gutschein, der für

01:26:43.980 --> 01:26:45.320
drei Tage gültig ist oder sowas.

01:26:45.320 --> 01:26:47.120
Ja, und genau, ich möchte hinterher gucken,

01:26:47.200 --> 01:26:49.160
was ist denn dann passiert? War das jetzt erfolgreich oder nicht?

01:26:49.240 --> 01:26:50.220
Oder wie erfolgreich war denn das?

01:26:51.180 --> 01:26:52.660
Und dafür

01:26:52.660 --> 01:26:53.460
muss ich halt

01:26:53.460 --> 01:26:56.740
bestimmte Arten von Anfragen,

01:26:57.280 --> 01:26:58.760
die ansonsten keine Rolle

01:26:58.760 --> 01:27:00.500
spielen können, gut machen können. Und dafür habe ich halt

01:27:00.500 --> 01:27:02.340
so eine Struktur. Ich habe eine Faktentabelle

01:27:02.340 --> 01:27:04.500
und dann drumherum Dimensionstabellen, in denen halt

01:27:04.500 --> 01:27:05.680
solche Sachen drinstehen, wie

01:27:05.680 --> 01:27:08.760
das war jetzt ein User, für den ich

01:27:08.760 --> 01:27:10.560
diese Version der Webseite angezeigt

01:27:10.560 --> 01:27:11.960
habe. Oder das hier,

01:27:12.880 --> 01:27:13.880
also man hat zum Beispiel sowas wie,

01:27:14.020 --> 01:27:15.220
daran kann man es vielleicht ganz gut

01:27:15.220 --> 01:27:18.640
verstehen, Time ist halt eine Dimension.

01:27:19.240 --> 01:27:20.600
Und in der Faktentabelle, also Fakten

01:27:20.600 --> 01:27:21.560
wären sowas wie Bestellungen.

01:27:23.220 --> 01:27:23.960
Ist halt

01:27:23.960 --> 01:27:26.740
sozusagen Time nicht etwas

01:27:26.740 --> 01:27:28.620
jetzt ein Zeitstempel oder so, der da reingeschrieben

01:27:28.620 --> 01:27:30.700
wird, sondern das ist halt eine ID,

01:27:31.020 --> 01:27:32.600
ein Fremdschlüssel und der zeigt

01:27:32.600 --> 01:27:34.460
halt in eine Timedimension

01:27:34.460 --> 01:27:36.160
und das ist halt eine

01:27:36.160 --> 01:27:38.560
Dimensionstabelle, in der drinsteht, was diese

01:27:38.560 --> 01:27:40.660
Zeit bedeutet und dann stehen da eben

01:27:40.660 --> 01:27:41.760
solche Dinge dran wie,

01:27:42.400 --> 01:27:44.500
naja, also, auch da wiederum, kann sein,

01:27:44.920 --> 01:27:46.160
also, da steht nicht direkt ein

01:27:46.160 --> 01:27:48.720
Zeitstempel, sondern da steht dann dran, also, das war ein Werktag.

01:27:49.260 --> 01:27:50.380
Das war ein Feiertag

01:27:50.380 --> 01:27:51.420
in folgenden Bundesländern.

01:27:51.960 --> 01:27:54.120
Das war, keine Ahnung,

01:27:54.720 --> 01:27:55.200
das war Sommer.

01:27:55.680 --> 01:27:57.420
Sodass ich dann halt solche Abfragen machen kann wie,

01:27:57.900 --> 01:28:00.340
wie ist denn der Verkauf der Bücher in dieser Kategorie

01:28:00.340 --> 01:28:01.820
im Sommervergleich zum Winter?

01:28:02.460 --> 01:28:04.060
Und dadurch, da ich diese Informationen,

01:28:04.200 --> 01:28:05.980
das ist jetzt Sommer, halt direkt an dem

01:28:05.980 --> 01:28:08.000
Zeitdings dran habe, kann ich halt Abfragen machen,

01:28:08.060 --> 01:28:10.080
die sehr effizient alles rausfiltern, was halt

01:28:10.080 --> 01:28:11.420
irgendwie Sommer ist und so.

01:28:13.400 --> 01:28:14.020
Aber solche Abfragen

01:28:14.020 --> 01:28:15.900
machen halt in dem OTP-Teil

01:28:15.900 --> 01:28:17.840
oder wenn ich jetzt eine Webseite, machen überhaupt keinen Sinn.

01:28:18.040 --> 01:28:19.880
Das heißt, ja, die Schemata

01:28:19.880 --> 01:28:21.040
sehen dann halt ganz anders aus.

01:28:22.200 --> 01:28:23.500
Ja, genau.

01:28:23.580 --> 01:28:25.340
Wenn einen interessiert, wie das wirklich so

01:28:25.340 --> 01:28:27.700
funktioniert, finde ich, dieser Data Warehousing

01:28:27.700 --> 01:28:29.420
for Caveman-Essay ist ein schöner Start.

01:28:30.320 --> 01:28:31.660
Aber da gibt es auch jede Menge.

01:28:31.800 --> 01:28:33.580
Da kann man sich durchlesen, wie das so klappt.

01:28:36.580 --> 01:28:36.900
Ja,

01:28:37.260 --> 01:28:38.840
genau.

01:28:40.800 --> 01:28:41.120
Ach so.

01:28:42.420 --> 01:28:43.480
Richtig, genau. Da haben wir jetzt

01:28:43.480 --> 01:28:45.540
schon mal ein bisschen über den Analyse-Teil gesprochen, aber

01:28:45.540 --> 01:28:47.660
wir haben natürlich auch ein Problem, wenn jetzt Leute

01:28:47.660 --> 01:28:48.720
immer mehr Zeugs kaufen,

01:28:49.760 --> 01:28:54.040
dass irgendwie halt unsere Datenbank

01:28:54.040 --> 01:28:55.460
halt vielleicht irgendwann ein bisschen langsamer wird,

01:28:55.560 --> 01:28:57.620
nicht mehr genug Transaktionen prozessen kann.

01:28:58.360 --> 01:28:59.000
Ja, was macht man da?

01:28:59.060 --> 01:28:59.740
Man muss halt optimieren.

01:28:59.820 --> 01:29:01.480
Das ist auch oft ein wichtiger Teil

01:29:01.480 --> 01:29:02.460
und es ist auch nicht so einfach.

01:29:04.840 --> 01:29:08.160
Die einzige Datenbank,

01:29:08.260 --> 01:29:09.760
für die ich das wirklich mal gemacht habe,

01:29:10.120 --> 01:29:11.440
ist eigentlich MySQL.

01:29:11.580 --> 01:29:12.760
Ich verwende heutzutage eher Postgres,

01:29:12.760 --> 01:29:15.000
aber da habe ich dann auch mal

01:29:15.000 --> 01:29:19.220
so einen MySQL-Performance-Optimierungskurs besucht.

01:29:19.760 --> 01:29:22.140
und das

01:29:22.140 --> 01:29:24.640
schöne Zitat, also Chris Künthopp hat

01:29:24.640 --> 01:29:26.300
den damals irgendwo in München

01:29:26.300 --> 01:29:28.740
durchgeführt,

01:29:29.420 --> 01:29:30.740
damals hat er bei MySQL gearbeitet

01:29:30.740 --> 01:29:32.280
und

01:29:32.280 --> 01:29:34.860
ein Satz,

01:29:34.940 --> 01:29:36.500
der mir in Erinnerung geblieben ist, der meinte so, ja,

01:29:36.540 --> 01:29:38.560
wenn man Datenbank-Performance

01:29:38.560 --> 01:29:40.240
optimieren will, ja, so OLTP,

01:29:41.320 --> 01:29:42.800
dann gibt es da eigentlich

01:29:42.800 --> 01:29:44.660
so im Wesentlichen drei Sachen, die man tun

01:29:44.660 --> 01:29:46.080
kann, um eine Datenbank schnell zu machen.

01:29:47.040 --> 01:29:48.720
Das Erste, was man eigentlich immer machen kann,

01:29:49.300 --> 01:29:51.440
das funktioniert auch fast immer,

01:29:51.600 --> 01:29:53.480
das ist super, man kann einfach mal ein bisschen

01:29:53.480 --> 01:29:54.960
mehr Hauptspeicher reinstecken in die Datenbank.

01:29:55.240 --> 01:29:57.500
Das ist schon mal auf jeden Fall schneller, das ist immer

01:29:57.500 --> 01:29:57.700
gut.

01:29:58.580 --> 01:30:00.980
Wenn das irgendwie nicht mehr so richtig reicht,

01:30:01.280 --> 01:30:03.280
eine zweite Geschichte, die man auch immer tun kann, auch

01:30:03.280 --> 01:30:05.220
sehr gut hilft, ist, man kann einfach

01:30:05.220 --> 01:30:07.280
noch ein bisschen mehr Speicher reinstecken in die Datenbank.

01:30:08.340 --> 01:30:09.620
Und das hilft eigentlich fast auch

01:30:09.620 --> 01:30:11.420
mit der dritten Geschichte,

01:30:11.740 --> 01:30:13.400
selbst wenn man an eine Grenze gekommen ist,

01:30:13.860 --> 01:30:15.200
die dann auch eher so

01:30:15.200 --> 01:30:17.240
das letzte Mittel, zu dem man greifen kann,

01:30:17.300 --> 01:30:18.800
wenn das auch nicht hilft, ist halt, man könnte einfach

01:30:18.800 --> 01:30:20.920
ein bisschen mehr Hauptspeicher in die Datenbank reinsteigen.

01:30:22.080 --> 01:30:22.760
Okay, okay.

01:30:23.160 --> 01:30:25.080
Wie viel Hauptspeicher hat denn dann so eine große Datenbank?

01:30:25.840 --> 01:30:27.020
Ja, so viel, wie halt geht

01:30:27.020 --> 01:30:29.180
eigentlich. Also es kommt darauf an, wie viel du benötigst.

01:30:29.260 --> 01:30:30.200
Also wenn du jetzt irgendwie

01:30:30.200 --> 01:30:33.160
ein paar tausend Artikel hast,

01:30:33.240 --> 01:30:34.560
die du auf einer Webseite verkaufen willst,

01:30:35.140 --> 01:30:36.040
dann ist es egal.

01:30:37.980 --> 01:30:40.240
Da kommst du halt mit einem,

01:30:40.640 --> 01:30:41.240
weiß ich nicht,

01:30:42.980 --> 01:30:43.760
mit einer beliebigen,

01:30:43.900 --> 01:30:46.180
mit einem Raspberry Pi kannst du das machen, das ist wurscht.

01:30:46.640 --> 01:30:48.440
Aber wenn du

01:30:48.440 --> 01:30:50.260
jetzt, also sagen wir mal so,

01:30:50.360 --> 01:30:52.600
wenn ein Working Set der Datenbank,

01:30:52.700 --> 01:30:54.420
also die Menge der Daten, die halt auf der

01:30:54.420 --> 01:30:56.140
Platte liegen, wenn die Datenbank runtergefahren ist,

01:30:56.780 --> 01:30:58.400
wenn das halt 30 Gigabyte

01:30:58.400 --> 01:30:59.920
hat, dann sollte deine Datenbank

01:30:59.920 --> 01:31:02.280
mindestens mal 30 Gigabyte haben, eher so

01:31:02.280 --> 01:31:04.440
64 vielleicht. Hauptspeicher.

01:31:04.840 --> 01:31:06.220
Weil es gibt halt auch noch diverse

01:31:06.220 --> 01:31:07.860
Strukturen, die im Hauptspeicher gehalten werden,

01:31:08.560 --> 01:31:09.560
die man halt auch braucht.

01:31:10.760 --> 01:31:10.860
Ja.

01:31:12.560 --> 01:31:14.480
Und dann ist halt das Limit eigentlich nur

01:31:14.480 --> 01:31:16.000
und sagen wir mal so, das ist halt viel.

01:31:16.000 --> 01:31:17.940
Also wenn man jetzt irgendwie, nehmen wir an,

01:31:18.000 --> 01:31:20.700
Wir haben das, was heute so ein Sweet-Spot ist,

01:31:20.760 --> 01:31:22.780
sind es halt vielleicht 256 Gigabyte oder so.

01:31:23.860 --> 01:31:27.140
Hauptspeicher, da geht eine ganze Menge rein.

01:31:27.440 --> 01:31:30.380
Also es ist halt für mich schwer vorstellbar,

01:31:31.200 --> 01:31:34.320
welche Systeme, die Transaction-Processing machen,

01:31:34.400 --> 01:31:35.340
denn mehr Hauptspeicher benötigen.

01:31:35.520 --> 01:31:36.840
Oder mehr Daten haben,

01:31:37.560 --> 01:31:39.040
die sie jetzt unbedingt im Hauptspeicher halten müssen.

01:31:39.120 --> 01:31:39.760
Das gibt es kaum.

01:31:40.380 --> 01:31:42.400
Also, ja gut, es gibt schon.

01:31:42.400 --> 01:31:44.460
Also wenn man jetzt an sowas denkt wie Google,

01:31:44.680 --> 01:31:46.200
man indiziert das Web und möchte halt

01:31:46.200 --> 01:31:48.620
so eine Echtzeit Suchabfragen über alle Webseiten

01:31:48.620 --> 01:31:50.300
machen, das geht nicht mehr, das ist klar.

01:31:52.420 --> 01:31:52.820
Aber

01:31:52.820 --> 01:31:55.160
so viele...

01:31:55.160 --> 01:31:56.140
Also so groß muss man erstmal werden.

01:31:56.980 --> 01:31:58.640
Also Amazon fällt da bestimmt auch nicht rein.

01:31:58.820 --> 01:31:59.960
Also Amazon hat

01:31:59.960 --> 01:32:02.300
also, na gut,

01:32:03.520 --> 01:32:04.560
Amazons Teil, der

01:32:04.560 --> 01:32:06.100
einen jetzt mit Produkten versorgt,

01:32:06.380 --> 01:32:08.600
diese Webseite, das

01:32:08.600 --> 01:32:09.500
wird nicht so groß sein.

01:32:10.560 --> 01:32:12.460
Die haben andere Teile, die halt dann unter Umständen

01:32:12.460 --> 01:32:13.460
sehr groß geworden sind, aber

01:32:13.460 --> 01:32:15.740
ja, das kriegst du eigentlich alles locker

01:32:15.740 --> 01:32:18.080
in einer Datenbank unter. Also die haben dann halt

01:32:18.080 --> 01:32:20.220
ein anderes Problem. Amazon wird das Problem bekommen, dass sie halt mit der

01:32:20.220 --> 01:32:21.800
Schreiblast nicht mehr klarkommen, aber

01:32:21.800 --> 01:32:24.040
also das könntest du alles

01:32:24.040 --> 01:32:25.900
irgendwie in den Hauptspeicher

01:32:25.900 --> 01:32:27.140
von so einer Datenbank packen.

01:32:28.380 --> 01:32:30.160
Also ich würde sagen, für die, für fast alle

01:32:30.160 --> 01:32:32.320
Anwendungsfälle heutzutage ist das halt groß genug.

01:32:34.940 --> 01:32:36.200
Ja, ab 256

01:32:36.200 --> 01:32:37.420
Gigabyte wird es ein bisschen schwierig.

01:32:39.400 --> 01:32:40.180
Also man kann auch

01:32:40.180 --> 01:32:41.700
einen Terabyte Hauptspeicher irgendwie

01:32:41.700 --> 01:32:43.860
in den Rechner stecken. Das kostet

01:32:43.860 --> 01:32:45.720
irgendwie weniger als 10.000 Euro heutzutage.

01:32:45.960 --> 01:32:47.620
Also das geht auch. Es wird dann halt,

01:32:47.720 --> 01:32:49.600
wenn man so wirklich so wahnsinnig viel Hauptspeicher drin hat,

01:32:49.920 --> 01:32:52.060
dann kriegt man halt ein bisschen Probleme mit der Architektur.

01:32:52.940 --> 01:32:53.860
Das ist ja so ein bisschen

01:32:53.860 --> 01:32:55.540
PC-basiert und

01:32:55.540 --> 01:32:57.720
so viel Hauptspeicherbandbreite hat man da ja nicht

01:32:57.720 --> 01:32:58.860
und das wird dann irgendwann,

01:32:59.640 --> 01:33:01.660
man muss ja die ganzen Prozessoren auch irgendwie mit

01:33:01.660 --> 01:33:03.620
Daten versorgen und wenn man jetzt da

01:33:03.620 --> 01:33:04.400
irgendwie, weiß ich nicht.

01:33:05.600 --> 01:33:06.480
Da fährt dann kein Bus hin.

01:33:07.540 --> 01:33:09.440
32 Prozessoren oder 64 oder sowas.

01:33:09.840 --> 01:33:11.360
So irgendwann ist dann halt, also der

01:33:11.360 --> 01:33:13.300
Sweetspot ist, würde ich sagen, heute eher so

01:33:13.300 --> 01:33:15.300
bei, weiß ich nicht, irgendwie 64 Prozessoren oder so

01:33:15.300 --> 01:33:17.200
und 256 GB Hauptspeicher und so.

01:33:17.640 --> 01:33:19.380
Aber das, also egal, also vielleicht

01:33:19.380 --> 01:33:20.520
geht auch noch ein Terabyte, ich hab keine Ahnung.

01:33:21.320 --> 01:33:23.560
Für die meisten, aller, aller, aller

01:33:23.560 --> 01:33:25.580
meisten Anfälle reicht das alles vollkommen aus.

01:33:26.220 --> 01:33:27.560
Und es ist ein sehr guter

01:33:27.560 --> 01:33:29.260
Tipp zu sagen, also jetzt,

01:33:29.380 --> 01:33:31.480
wenn du tatsächlich irgendwie ein Working Set von 30 GB

01:33:31.480 --> 01:33:33.380
hattest, nimm nicht eine Datenbank,

01:33:33.380 --> 01:33:34.980
die jetzt 8 GB hat, dann hast du ein Problem.

01:33:35.100 --> 01:33:36.080
Dann bist du gleich mal irgendwie

01:33:36.080 --> 01:33:39.160
mehrere Größenordnungen langsamer, als wenn du das

01:33:39.160 --> 01:33:41.300
in den Hauptspeicher packen würdest und kriegst halt einen Haufen Probleme,

01:33:41.360 --> 01:33:42.360
die du sonst einfach nicht hättest.

01:33:44.100 --> 01:33:45.300
Ja, das war früher alles noch viel schlimmer,

01:33:45.380 --> 01:33:47.160
als es einen riesigen Unterschied gab zwischen

01:33:47.160 --> 01:33:49.420
sozusagen permanentem Storage,

01:33:50.080 --> 01:33:50.440
also

01:33:50.440 --> 01:33:53.460
rotierendem Rost,

01:33:53.600 --> 01:33:54.940
ja, so Harddisks

01:33:54.940 --> 01:33:57.220
und Hauptsprecher, da war der

01:33:57.220 --> 01:33:59.380
Unterschied

01:33:59.380 --> 01:33:59.760
so

01:33:59.760 --> 01:34:03.540
1 zu 10.000 oder so

01:34:03.540 --> 01:34:04.660
Geschwindigkeitsunterschied.

01:34:05.260 --> 01:34:06.620
Das ist jetzt nicht mehr ganz so schlimm,

01:34:07.400 --> 01:34:09.000
wenn man SSDs hat,

01:34:09.000 --> 01:34:10.480
aber es ist immer noch ziemlich schlimm.

01:34:10.780 --> 01:34:12.200
Also es ist immer noch ein Riesenunterschied.

01:34:13.180 --> 01:34:14.200
Und daher, ja,

01:34:15.220 --> 01:34:16.740
das will eigentlich, dass die heißen Daten

01:34:16.740 --> 01:34:17.520
im Hauptspeicher sind.

01:34:18.220 --> 01:34:20.580
Ja, genau.

01:34:21.200 --> 01:34:22.960
Das ist halt ein Ansatz, um das zu optimieren.

01:34:23.040 --> 01:34:24.920
Dann hat man oft das Problem, man hat halt so eine Asymmetrie

01:34:24.920 --> 01:34:27.360
zwischen Lese- und Schreibquerys.

01:34:28.740 --> 01:34:30.540
Und selbst wenn man mit so einer Datenbank halt

01:34:30.540 --> 01:34:32.840
irgendwie ein paar tausend Querys pro Sekunde

01:34:32.840 --> 01:34:33.900
abfeiern kann,

01:34:34.480 --> 01:34:37.040
irgendwann gerät man

01:34:37.040 --> 01:34:39.260
in eine Konkurrenz zwischen Schreibquerys und Lesequerys.

01:34:39.840 --> 01:34:41.700
wenn man jetzt nur eine Datenbank verwendet und

01:34:41.700 --> 01:34:43.900
das ist halt irgendwie schlecht, weil man möchte eigentlich

01:34:43.900 --> 01:34:45.820
immer in der Lage sein, weil man braucht ja eine,

01:34:46.240 --> 01:34:47.820
man darf eigentlich nur eine Datenbank haben, auf die man

01:34:47.820 --> 01:34:50.040
schreibt. Also wenn man mehrere Datenbanken

01:34:50.040 --> 01:34:51.920
hat, von denen man liest, ist nicht so schlimm, das geht.

01:34:52.460 --> 01:34:54.020
Aber man kann halt nicht so richtig gut

01:34:54.020 --> 01:34:55.680
mehrere Datenbanken haben, auf die man schreibt,

01:34:56.380 --> 01:34:58.160
weil man ja diesen zentralen

01:34:58.160 --> 01:34:59.780
Punkt, an dem der Status

01:34:59.780 --> 01:35:01.040
gehalten wird, behalten möchte.

01:35:01.420 --> 01:35:03.300
Wenn wir zweimal auf dieselbe Stelle schreiben zum Beispiel.

01:35:03.440 --> 01:35:05.960
Ja, genau. Also was

01:35:05.960 --> 01:35:07.960
man jetzt machen könnte, wenn man zu viele Leseanfragen

01:35:07.960 --> 01:35:09.720
hat, man verteilt die dann halt auf

01:35:09.720 --> 01:35:11.560
sogenannte Slave-Datenbanken. Das heißt, man hat halt

01:35:11.560 --> 01:35:13.540
eine Master-Slave-Architektur und

01:35:13.540 --> 01:35:15.220
eine Master-Datenbank,

01:35:15.560 --> 01:35:17.420
von der man lesen und schreiben kann.

01:35:17.520 --> 01:35:19.400
Von der man lesen kann und auf die man schreiben kann.

01:35:21.160 --> 01:35:21.600
Und

01:35:21.600 --> 01:35:23.160
es gibt

01:35:23.160 --> 01:35:25.000
gibt halt eine Reihe von

01:35:25.000 --> 01:35:27.060
Slave-Datenbanken, von denen man nur lesen kann, auf die man nicht

01:35:27.060 --> 01:35:29.000
schreiben kann. Wie oft wird denn da geslaved? Also wie oft

01:35:29.000 --> 01:35:30.780
wird der Slave denn aktualisiert auf den Master?

01:35:30.880 --> 01:35:32.800
Ja, da gibt es dann Mechanismen für, dass

01:35:32.800 --> 01:35:36.880
der Master schreibt halt irgendwie einen Log, das Log

01:35:36.880 --> 01:35:38.820
wird irgendwie an die Slaves übertragen und die

01:35:38.820 --> 01:35:40.840
vollziehen dann sozusagen die Transaktionen, die der Master

01:35:40.840 --> 01:35:41.660
gemacht hat, halt nach.

01:35:43.100 --> 01:35:44.900
Das ist meistens

01:35:44.900 --> 01:35:46.360
wahrscheinlich instantan, mehr oder weniger.

01:35:47.960 --> 01:35:48.920
Bei viel Last oder wenn

01:35:48.920 --> 01:35:50.740
halt eine große geografische

01:35:50.740 --> 01:35:52.680
Differenz ist, also wenn es halt irgendwie über den Atlantik oder

01:35:52.680 --> 01:35:55.060
der Pazifik geht oder so, klar, dann hast du halt Zeitunterschiede

01:35:55.060 --> 01:35:56.540
oder halt auch wenn die Last so groß ist,

01:35:56.980 --> 01:35:58.700
dass die Slaves nicht mehr gut

01:35:58.700 --> 01:36:00.700
hinterherkommen, dann

01:36:00.700 --> 01:36:02.900
hast du natürlich, dann hast du

01:36:02.900 --> 01:36:04.940
eventuell so ein bisschen Lag von vielleicht ein paar Sekunden

01:36:04.940 --> 01:36:06.280
oder vielleicht auch mal eine Minute oder sowas.

01:36:07.100 --> 01:36:08.920
Aber es gibt halt viele Anfragen, für die ist das egal.

01:36:09.280 --> 01:36:10.920
Also viele Leseanfragen ist auch

01:36:10.920 --> 01:36:12.900
oft casht man das ja auch dann nochmal

01:36:12.900 --> 01:36:14.040
irgendwie im Hauptspeicher

01:36:14.040 --> 01:36:16.480
in Redis oder Memcache

01:36:16.480 --> 01:36:18.780
oder so und sagt halt ja, also dieses

01:36:18.780 --> 01:36:20.420
Ding hier kannst du fünf Minuten lang

01:36:20.420 --> 01:36:21.020
cachen.

01:36:22.520 --> 01:36:24.360
Das ist ja dann auch egal und

01:36:24.360 --> 01:36:26.640
bei den Anfragen, die auf Slaves gehen, ist es auch so oft

01:36:26.640 --> 01:36:28.520
so, es ist halt wurscht, also so oft

01:36:28.520 --> 01:36:30.520
ändern sich Dinge halt nicht, wenn irgendwo ein Count nicht so richtig stimmt

01:36:30.520 --> 01:36:32.600
oder so. Naja, nicht so schlimm.

01:36:33.240 --> 01:36:34.540
Es gibt Dinge, bei denen das schlimm ist,

01:36:34.660 --> 01:36:36.600
aber kommen gleich noch zu, da muss man das halt anders

01:36:36.600 --> 01:36:38.540
machen, aber bei vielen Sachen

01:36:38.540 --> 01:36:40.400
ist es halt nicht so wirklich schlimm

01:36:40.400 --> 01:36:42.440
und daher kann man das gut aufteilen.

01:36:42.520 --> 01:36:44.380
Man kann halt dann die Leselast auf die

01:36:44.380 --> 01:36:46.360
Slaves sozusagen transferieren

01:36:46.360 --> 01:36:48.500
und dann gibt es halt bestimmte Abfragen, also

01:36:48.500 --> 01:36:50.620
gerade, wenn man jetzt kurz davor ist, eine Bestellung

01:36:50.620 --> 01:36:52.340
zu machen oder so, wo man dann schon

01:36:52.340 --> 01:36:54.700
im Code weiß, okay, jetzt gibt es hier gleich

01:36:54.700 --> 01:36:56.660
eine Transaktion oder so und dann macht man

01:36:56.660 --> 01:36:58.480
auch die Leseanfragen auf den Master, damit man

01:36:58.480 --> 01:37:00.620
eben nicht das Problem hat, dass man eventuell

01:37:00.620 --> 01:37:02.500
Daten sieht, die eine Minute alt sind.

01:37:03.120 --> 01:37:04.640
Aber da das die allermeisten Anfragen

01:37:04.640 --> 01:37:06.580
ja gar nicht sind, sondern die

01:37:06.580 --> 01:37:08.540
meisten Navigationsanfragen, wenn ich jetzt in Kategorien

01:37:08.540 --> 01:37:10.500
rumklicke oder irgendwelche Filter

01:37:10.500 --> 01:37:12.240
auswähle oder nach irgendwas suche oder so,

01:37:12.680 --> 01:37:14.480
diese ganzen Anfragen beziehen sich auf Daten,

01:37:14.520 --> 01:37:16.400
die sich jetzt gar nicht so häufig ändern. Das kann

01:37:16.400 --> 01:37:18.500
alles auch eine Minute alt sein, das ist wurscht.

01:37:19.660 --> 01:37:20.340
Und erst wenn ich halt

01:37:20.340 --> 01:37:21.420
eine Bestellung mache, dann

01:37:21.420 --> 01:37:24.160
muss ich halt zusehen, dass ich

01:37:24.160 --> 01:37:25.540
aktuelle Daten sehe, wie zum Beispiel

01:37:25.540 --> 01:37:27.920
ist das Buch noch auf Lager oder so.

01:37:28.700 --> 01:37:30.200
Und diese wenigen

01:37:30.200 --> 01:37:31.380
Anfragen, die halt dann

01:37:31.380 --> 01:37:34.040
aktuell sein sollten,

01:37:34.320 --> 01:37:36.080
die gehen dann direkt an den Master. Und das kann man halt im Code

01:37:36.080 --> 01:37:38.120
sagen. Man kann halt sagen, okay, an dieser

01:37:38.120 --> 01:37:40.100
Stelle bitte eine Verbindung auf den Master und nicht

01:37:40.100 --> 01:37:40.580
auf den Slave.

01:37:41.940 --> 01:37:43.980
Und die Schreibanfragen müssen dann halt

01:37:43.980 --> 01:37:46.060
auf den Master gehen, weil man ja nur

01:37:46.060 --> 01:37:47.280
an einer Stelle schreiben will.

01:37:48.420 --> 01:37:50.100
Und mit dieser Architektur kommt man relativ

01:37:50.100 --> 01:37:50.940
weit. Also das ist

01:37:50.940 --> 01:37:53.860
eine Geschichte, das ist auch so

01:37:53.860 --> 01:37:56.320
klassischer Lampstack-Architektur, Wikipedia-Seite

01:37:56.320 --> 01:37:57.000
so aufgebaut.

01:37:58.000 --> 01:37:59.720
Du hast jetzt gerade noch zwei Sachen gesagt, die vielleicht noch mal kurz

01:37:59.720 --> 01:38:02.140
von Redis einmal eben gesprochen und

01:38:02.140 --> 01:38:04.020
gerade von Lampstack, also einmal vielleicht kurz erklären, was das

01:38:04.020 --> 01:38:05.960
drin ist. Ja, Redis ist auch so eine

01:38:05.960 --> 01:38:08.200
In-Memory-Datenbank,

01:38:08.360 --> 01:38:10.140
eher so ein Key-Value-Store, hat noch ein paar

01:38:10.140 --> 01:38:12.140
Zusatzfunktionen, ist eine Message-Queue drin,

01:38:12.320 --> 01:38:13.700
kann teilweise sortierte

01:38:13.700 --> 01:38:16.380
Listen und sowas auch halten, aber

01:38:16.380 --> 01:38:18.500
es ist ein bisschen, kann ein bisschen mehr

01:38:18.500 --> 01:38:20.420
als Memcached, Memcached

01:38:20.420 --> 01:38:22.420
ist rein so, du hast ein Key und kriegst

01:38:22.420 --> 01:38:24.420
halt dann irgendwie Value zurück und wird im Hauptspeicher

01:38:24.420 --> 01:38:25.580
gehalten, deswegen ist es schön schnell.

01:38:27.420 --> 01:38:28.500
Wurde popularisiert

01:38:28.500 --> 01:38:30.020
auch Memcached, vor allen Dingen durch den

01:38:30.020 --> 01:38:32.120
LAMP-Stack, LAMP ist einfach Linux, Apache,

01:38:32.220 --> 01:38:33.500
MySQL, PHP

01:38:33.500 --> 01:38:36.240
und einige

01:38:36.240 --> 01:38:38.200
der größten Webseiten, die das halt

01:38:38.200 --> 01:38:40.380
benutzt haben

01:38:40.380 --> 01:38:42.120
oder weiß nicht, ob sie das noch benutzen, keine Ahnung,

01:38:42.200 --> 01:38:43.060
ist halt Wikipedia.

01:38:43.840 --> 01:38:47.400
Wir haben auch immer schöne Artikel darüber gehabt,

01:38:47.620 --> 01:38:49.200
wie sie ihre Systeme aufbauen.

01:38:49.340 --> 01:38:50.580
Also ist ja auch Wikipedia eine der,

01:38:50.840 --> 01:38:52.340
ich glaube, die sind auch mit Sicherheit immer noch

01:38:52.340 --> 01:38:54.640
in den Top 10 der weltweit trafficstärksten Seiten

01:38:54.640 --> 01:38:57.600
und haben halt auch viel dazu veröffentlicht,

01:38:57.720 --> 01:38:59.200
wie ihre Architektur aussieht.

01:38:59.940 --> 01:39:01.080
Und die haben halt auch genau das,

01:39:01.160 --> 01:39:02.440
die meisten Sachen sind Leseanfragen,

01:39:02.600 --> 01:39:04.580
aber manchmal wird halt auch was geändert oder geschrieben

01:39:04.580 --> 01:39:07.500
und die machen das halt mit MySQL und vielen Slaves

01:39:07.500 --> 01:39:11.080
und extensiver Verwendung von Memcached,

01:39:11.240 --> 01:39:13.640
zum Cachen von irgendwelchen geretteten Fragmenten

01:39:13.640 --> 01:39:14.980
und Daten,

01:39:15.520 --> 01:39:17.240
für die man jetzt nicht nochmal eine Query machen möchte.

01:39:17.620 --> 01:39:19.480
Was wäre denn jetzt der neueste Stack, würdest du

01:39:19.480 --> 01:39:20.600
sagen, den man jetzt verwenden sollte?

01:39:21.600 --> 01:39:23.640
Ja, das kommt halt drauf an, wenn man

01:39:23.640 --> 01:39:24.680
eben PHP mag.

01:39:27.480 --> 01:39:29.520
Kann man das auch

01:39:29.520 --> 01:39:31.420
immer noch machen, wobei ich jetzt nicht genau weiß, ob das

01:39:31.420 --> 01:39:33.360
alles immer noch so populär ist. Wemcached.de, glaube ich, ist

01:39:33.360 --> 01:39:34.380
so ein bisschen auf dem Weg nach draußen.

01:39:35.540 --> 01:39:37.160
Wahrscheinlich würde auch in dem Umfeld eher

01:39:37.160 --> 01:39:38.500
heutzutage Redis verwendet.

01:39:40.920 --> 01:39:54.020
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.

01:39:54.020 --> 01:40:23.240
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.

01:40:24.020 --> 01:40:25.360
Aber so als

01:40:25.360 --> 01:40:27.400
womit ich anfangen würde, ist auf jeden Fall Postgres

01:40:27.400 --> 01:40:29.140
und dann halt eben SQL Alchemy

01:40:29.140 --> 01:40:30.140
beziehungsweise Django OAM.

01:40:31.760 --> 01:40:33.200
Und Redis, genau,

01:40:33.380 --> 01:40:34.860
als Memory Cache und

01:40:34.860 --> 01:40:36.760
ja, wahrscheinlich braucht man auch noch ein

01:40:36.760 --> 01:40:38.460
Message-Queue-System.

01:40:41.200 --> 01:40:43.140
Ist aber dann auch schon, also dann gibt's noch

01:40:43.140 --> 01:40:43.980
so ein paar Sachen, die man braucht.

01:40:44.140 --> 01:40:45.400
Was ist denn die Message-Queue vielleicht?

01:40:45.700 --> 01:40:49.060
Also man hat oft so Dinge, wo man dem User

01:40:49.060 --> 01:40:51.080
möglicherweise etwas direkt

01:40:51.080 --> 01:40:54.620
direkt eine Antwort geben will,

01:40:55.020 --> 01:40:56.920
aber es ist halt ein Job, der dann irgendwie

01:40:56.920 --> 01:40:57.860
länger dauert.

01:41:00.300 --> 01:41:01.700
In unserem Buchstore wäre das was?

01:41:01.700 --> 01:41:03.440
Ein Buchstore, sowas wie

01:41:03.440 --> 01:41:05.180
jemand fliegt ein neues Buch ein oder so.

01:41:05.640 --> 01:41:07.080
Na gut, warte mal, lass mal überlegen.

01:41:07.360 --> 01:41:08.400
Das ist kein so gutes Beispiel.

01:41:08.500 --> 01:41:10.400
Was könnte der denn tun?

01:41:13.140 --> 01:41:14.700
Ja, zum Beispiel

01:41:14.700 --> 01:41:19.060
du verfasst einen Kommentar jetzt

01:41:19.060 --> 01:41:21.200
oder eine Bewertung für irgendeinen Artikel

01:41:21.200 --> 01:41:22.800
und du möchtest,

01:41:23.060 --> 01:41:24.800
wenn der jetzt auf Abschicken drückt,

01:41:24.900 --> 01:41:26.900
der User, dass er sofort seinen Kommentar

01:41:26.900 --> 01:41:27.920
unter dem Artikel sieht.

01:41:29.420 --> 01:41:29.820
Aber

01:41:29.820 --> 01:41:31.600
in Wirklichkeit

01:41:31.600 --> 01:41:35.160
willst du den ja vielleicht noch prüfen.

01:41:35.260 --> 01:41:36.580
Also wenn das jetzt irgendwas Populäres ist.

01:41:36.580 --> 01:41:38.160
Sag mal so, du...

01:41:38.160 --> 01:41:38.560
Oh, danke.

01:41:41.800 --> 01:41:42.520
Wahrscheinlich bräuchte ich

01:41:42.520 --> 01:41:44.060
bevor oder sowas eine Räuspertaste, oder?

01:41:44.760 --> 01:41:46.120
Das könnte jetzt hässlich geworden sein.

01:41:46.560 --> 01:41:48.120
Das tut mir leid, da muss ich mich entschuldigen.

01:41:49.060 --> 01:41:50.540
ein bisschen erkältet.

01:41:52.540 --> 01:41:52.900
Ja,

01:41:53.300 --> 01:41:55.860
wenn,

01:41:56.940 --> 01:41:58.940
also eigentlich möchte man halt, wenn jetzt zum Beispiel ein Artikel

01:41:58.940 --> 01:42:00.980
ist, der häufig verkauft wird, ja, und dann jemand

01:42:00.980 --> 01:42:03.100
schreibt irgendwie, dieser Artikel ist voll scheiße

01:42:03.100 --> 01:42:04.180
und keine Ahnung,

01:42:05.020 --> 01:42:06.940
das hat ja dann unter Umständen direkt

01:42:06.940 --> 01:42:08.980
Konsequenzen, oder es

01:42:08.980 --> 01:42:10.700
macht dann am besten noch irgendwie ein Mitbewerber,

01:42:10.940 --> 01:42:12.480
macht irgendwas Fieses, irgendwie,

01:42:13.480 --> 01:42:16.880
ja, dann will man das möglicherweise nicht,

01:42:16.880 --> 01:42:18.700
dass das sofort allen sichtbar wird, sondern man muss

01:42:18.700 --> 01:42:19.640
irgendwie erst

01:42:19.640 --> 01:42:23.120
eine Redaktion draufgucken oder so,

01:42:23.780 --> 01:42:25.120
aber das ist halt nicht

01:42:25.120 --> 01:42:26.800
etwas, was man dem User anzeigen möchte.

01:42:27.660 --> 01:42:29.020
Man hat dann halt sozusagen etwas,

01:42:29.360 --> 01:42:31.100
zwei Prozesse, die voneinander so ein bisschen entkoppelt

01:42:31.100 --> 01:42:32.980
sind. Der User drückt auf Speichern, sieht

01:42:32.980 --> 01:42:35.160
seinen Kommentar oder seine Bewertung und

01:42:35.160 --> 01:42:37.060
im Hintergrund gehen aber dann noch

01:42:37.060 --> 01:42:38.960
so Tasks los wie, oh, das ist hier

01:42:38.960 --> 01:42:40.480
an der Stelle, wo jemand mal draufgucken sollte,

01:42:41.260 --> 01:42:43.360
aber das geht dann auch nicht in Echtzeit,

01:42:43.360 --> 01:42:45.040
sondern das wird dann halt irgendwie in so eine

01:42:45.040 --> 01:42:47.480
Queue, in eine Warteschlange eingereiht.

01:42:47.680 --> 01:42:49.380
dann gibt es eine Redaktion, die hat dann halt diese Jobs,

01:42:49.740 --> 01:42:51.580
muss sich halt irgendwelche Kommentare an sensitiven Stellen

01:42:51.580 --> 01:42:53.680
oder so angucken und die dann abarbeiten.

01:42:54.840 --> 01:42:55.760
Aber das ist

01:42:55.760 --> 01:42:57.240
halt sozusagen der, dass

01:42:57.240 --> 01:42:59.540
diesen Job in die Warteschlange

01:42:59.540 --> 01:43:00.620
tun und dieser

01:43:00.620 --> 01:43:03.020
Prozess mit menschlicher Interaktion,

01:43:03.420 --> 01:43:05.020
das ist jetzt nicht mehr Teil von dem Web-Request.

01:43:06.140 --> 01:43:07.380
Das heißt, der

01:43:07.380 --> 01:43:09.000
Teil muss irgendwie entkoppelt sein.

01:43:09.900 --> 01:43:11.620
Das heißt, der Web-Request ist ja irgendwie vorbei.

01:43:12.860 --> 01:43:13.840
Aber dieser Web-Request

01:43:13.840 --> 01:43:15.220
löst dann halt irgendwie,

01:43:15.440 --> 01:43:17.280
schreibt dann halt irgendwie diesen Job

01:43:17.280 --> 01:43:19.180
in die Queue, genau. Solche Sachen hat man

01:43:19.180 --> 01:43:20.960
oft, auch wenn sich auch

01:43:20.960 --> 01:43:23.140
genau, das ist ein gutes Beispiel,

01:43:23.240 --> 01:43:23.860
das ist mir jetzt eingefallen.

01:43:25.360 --> 01:43:27.000
Vielleicht möchtest du, dass

01:43:27.000 --> 01:43:29.140
wenn du jetzt in der Suche nach

01:43:29.140 --> 01:43:31.140
irgendwas suchst, dann Produkte

01:43:31.140 --> 01:43:33.180
halt auch vielleicht Bewertungen finden, in denen

01:43:33.180 --> 01:43:35.200
jemand über das Produkt gesprochen hat oder so.

01:43:35.820 --> 01:43:37.080
Das heißt, der Text deiner

01:43:37.080 --> 01:43:38.920
Bewertung muss indiziert werden von der Suchmaschine.

01:43:40.180 --> 01:43:41.080
Aber das geht halt auch nicht

01:43:41.080 --> 01:43:42.940
in Echtzeit, sondern das macht die halt vielleicht nur alle

01:43:42.940 --> 01:43:45.040
tausend Bewertungen oder so, wird neu indiziert oder so,

01:43:45.040 --> 01:43:46.060
weil, ja.

01:43:46.820 --> 01:43:49.580
Und dann wird halt auch so ein Task erzeugt für,

01:43:50.220 --> 01:43:51.940
das hier muss ja noch mitindiziert werden,

01:43:52.240 --> 01:43:53.360
aber es wird nicht sofort indiziert,

01:43:53.560 --> 01:43:57.680
weil das ist halt etwas, was eine Operation lange dauern kann

01:43:57.680 --> 01:44:01.500
und man möchte ja nicht, dass der Web-Request dann so lange dauert,

01:44:01.560 --> 01:44:03.520
wie die Operation dauert, sondern man sagt,

01:44:03.620 --> 01:44:05.160
okay, man gibt dem Web-Request, es ist okay,

01:44:05.220 --> 01:44:08.380
dein Kommentar wurde gespeichert und hat dann aber noch diesen zusätzlichen Task erzeugt,

01:44:08.480 --> 01:44:10.360
der dann irgendwann später ausgeführt werden muss.

01:44:10.900 --> 01:44:13.220
Und dafür braucht man diese Task-Queues,

01:44:13.340 --> 01:44:15.540
die halt ein komplexeres Web-System hat,

01:44:15.600 --> 01:44:17.540
dann braucht man sowas halt, weil solche Fälle

01:44:17.540 --> 01:44:18.380
halt immer wieder auftreten.

01:44:19.640 --> 01:44:21.540
Ja, kann man aber Redis auch

01:44:21.540 --> 01:44:23.600
für verwenden, also was für

01:44:23.600 --> 01:44:25.500
Django ist halt, was häufig verwendet ist, Celery

01:44:25.500 --> 01:44:27.480
kann ich nicht unbedingt empfehlen, ist irgendwie

01:44:27.480 --> 01:44:28.680
eher schmerzhaft.

01:44:30.260 --> 01:44:31.320
Ja, die

01:44:31.320 --> 01:44:33.480
drunter liegenden Geschichten sind oft sowas wie

01:44:33.480 --> 01:44:35.480
RabbitMQ oder so, im Allgemeinen

01:44:35.480 --> 01:44:36.800
ist das Protokoll wie AMQ

01:44:36.800 --> 01:44:38.880
irgendwas, weiß nicht genau.

01:44:39.640 --> 01:44:40.940
Ja, aber das ist nochmal ein ganz eigenes

01:44:40.940 --> 01:44:43.120
Feld mit diesen ganzen Message-Queues.

01:44:45.600 --> 01:45:03.140
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.

01:45:03.140 --> 01:45:33.060
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.

01:45:33.140 --> 01:45:35.160
Also wenn man ihn mal verkauft, irgendwie.

01:45:35.320 --> 01:45:36.460
Er wird nicht so groß werden.

01:45:37.480 --> 01:45:39.860
Und das System ist super, weil das schadet automatisch oder sowas.

01:45:39.980 --> 01:45:41.540
Das ist nicht etwas, was man haben will.

01:45:41.700 --> 01:45:45.600
Also wenn man klein genug ist, dass man das nicht braucht, sollte man das nicht machen,

01:45:45.680 --> 01:45:49.280
weil das bedeutet halt, dass man diese ganzen Dinge, die einem sonst die Datenbank quasi schenkt,

01:45:50.080 --> 01:45:51.640
selber machen muss in den Applikationscode.

01:45:51.740 --> 01:45:53.720
Und das ist halt sehr, sehr schwierig.

01:45:54.800 --> 01:45:56.340
Aber manchmal geht es halt leider nicht anders.

01:45:56.440 --> 01:45:57.180
Dann gibt es halt zwei Möglichkeiten.

01:45:57.340 --> 01:45:59.300
Man schadet irgendwie horizontal.

01:46:00.020 --> 01:46:01.940
Also man sollte so lange, man nennt es Upscaling.

01:46:02.760 --> 01:46:04.780
solange wie möglich die Maschine größer

01:46:04.780 --> 01:46:06.020
machen und mehr Hauptspeicher reinstecken.

01:46:06.540 --> 01:46:08.360
Wenn das halt dann irgendwann tatsächlich nicht mehr geht,

01:46:08.600 --> 01:46:10.580
dann muss man halt entweder

01:46:10.580 --> 01:46:11.840
horizontal oder vertikal

01:46:11.840 --> 01:46:14.580
schaden und das halt

01:46:14.580 --> 01:46:16.300
aufteilen. Das heißt, horizontal

01:46:16.300 --> 01:46:18.640
Mehrere Maschinen,

01:46:18.740 --> 01:46:19.740
die die gleiche Datenbank benutzen?

01:46:20.040 --> 01:46:22.700
Nee, die gleiche

01:46:22.700 --> 01:46:24.440
Datenbank würde einem ja nicht helfen, wenn es zu viel

01:46:24.440 --> 01:46:26.560
da muss die

01:46:26.560 --> 01:46:28.480
Datenbank halt irgendwo trennen.

01:46:28.580 --> 01:46:29.840
Und die Frage ist, wo trennt man jetzt auf?

01:46:30.300 --> 01:46:32.520
Man kann halt entweder innerhalb von

01:46:32.520 --> 01:46:34.160
Tabellen die Zeilen auseinander trennen.

01:46:34.400 --> 01:46:35.740
Das wäre eben horizontal skalierend.

01:46:36.300 --> 01:46:38.440
Okay, alle Bücher, die mit Buchstaben A anfangen,

01:46:38.520 --> 01:46:40.740
kommen jetzt auf die Datenbank. Alle Bücher mit Buchstaben

01:46:40.740 --> 01:46:42.720
B bis F kommen auf die Datenbank.

01:46:44.760 --> 01:46:46.620
Oder so regional Queries trennen.

01:46:46.720 --> 01:46:48.040
Von wo kommt die denn jetzt oder sowas?

01:46:48.260 --> 01:46:49.700
Ja, regional kann man natürlich auch trennen.

01:46:50.940 --> 01:46:52.540
Das ist dann nochmal eine andere

01:46:52.540 --> 01:46:54.580
Geschichte. Könnte man auch machen.

01:46:54.660 --> 01:46:56.820
Das heißt aber, das wäre quasi horizontales

01:46:56.820 --> 01:46:58.740
Schaden auf den Usern.

01:46:58.740 --> 01:47:00.160
Nach Region eben.

01:47:01.240 --> 01:47:02.960
das wird, also meistens

01:47:02.960 --> 01:47:04.980
würde man auf Usern schaden, irgendwie

01:47:04.980 --> 01:47:06.560
tatsächlich, ja. Man sagt,

01:47:06.980 --> 01:47:08.640
was ist das für ein User? Und dann

01:47:08.640 --> 01:47:10.960
entweder regional oder halt

01:47:10.960 --> 01:47:11.500
irgendwie

01:47:11.500 --> 01:47:14.500
sonst irgendein Hash-Wert oder so.

01:47:17.400 --> 01:47:18.940
Und vertikal wäre halt,

01:47:19.060 --> 01:47:19.860
man trennt

01:47:19.860 --> 01:47:22.620
nach Tabellen auf. Das heißt, man sagt,

01:47:23.140 --> 01:47:24.880
okay, wir haben hier ein System, das kümmert sich um die Bücher.

01:47:25.040 --> 01:47:26.380
Wir haben hier ein System, das kümmert sich um die User.

01:47:26.880 --> 01:47:28.700
Wir haben ein System, das kümmert sich um Lagerhaltung.

01:47:29.400 --> 01:47:30.980
Das wäre halt, man teilt dann

01:47:30.980 --> 01:47:32.240
nicht quasi in den Zeilen,

01:47:32.940 --> 01:47:35.220
sondern man teilt halt an den Tabellengrenzen.

01:47:37.680 --> 01:47:38.880
Ja, macht natürlich so vollständig

01:47:38.880 --> 01:47:40.040
Abfragen dann ein bisschen langsamer, oder?

01:47:40.280 --> 01:47:42.080
Ja, das Problem ist dann halt, dass man mehrere

01:47:42.080 --> 01:47:44.500
Systeme fragen muss, wenn man jetzt irgendwie

01:47:44.500 --> 01:47:46.740
was machen, also wenn man jetzt die Amazon-Seite

01:47:46.740 --> 01:47:48.080
anzeigen möchte, dann

01:47:48.080 --> 01:47:51.060
muss man halt unter Umständen viele Systeme

01:47:51.060 --> 01:47:52.880
fragen. Tatsächlich

01:47:52.880 --> 01:47:54.260
ist es etwas, was Amazon wirklich

01:47:54.260 --> 01:47:57.140
passiert ist, irgendwie, ich glaube 2008, 2009

01:47:57.140 --> 01:47:58.740
gab es dann auch irgendwie, haben sie

01:47:58.740 --> 01:47:59.560
Artikel darüber geschrieben,

01:48:00.680 --> 01:48:03.400
damals nannte sich das nicht, also heute läuft das Ganze

01:48:03.400 --> 01:48:04.460
unter dem Stichwort irgendwie

01:48:04.460 --> 01:48:07.260
Microservices oder so, so nennt man das dann, dass man halt

01:48:07.260 --> 01:48:09.360
Teile eines

01:48:09.360 --> 01:48:11.200
Systems in kleinere

01:48:11.200 --> 01:48:12.180
Services auslagert.

01:48:14.840 --> 01:48:15.240
Damals

01:48:15.240 --> 01:48:16.980
nannte sich das anders, war aber quasi

01:48:16.980 --> 01:48:19.000
eine gleiche Idee, nannte sich

01:48:19.000 --> 01:48:22.540
Service-Oriented Architecture.

01:48:24.600 --> 01:48:25.240
Und Amazon

01:48:25.240 --> 01:48:27.080
hatte das Problem, dass sie auf der Hauptseite,

01:48:27.080 --> 01:48:28.860
also wenn du einfach nur Amazon.com

01:48:28.860 --> 01:48:30.620
eingegeben hast, dann

01:48:30.620 --> 01:48:32.880
wurde dir halt das Ding, die Seite ausgeliefert.

01:48:33.860 --> 01:48:34.820
Aber damals war es

01:48:34.820 --> 01:48:36.720
halt schon so, dass da so viel Zeugs

01:48:36.720 --> 01:48:38.960
drin war. Also dann werden dir irgendwelche Empfehlungen angezeigt,

01:48:39.100 --> 01:48:41.000
dann wird dir irgendwas angezeigt,

01:48:41.180 --> 01:48:42.600
wie viel Zeugs in deinem

01:48:42.600 --> 01:48:44.720
Warenkorb ist. Und das

01:48:44.720 --> 01:48:46.820
ist einem zwar nicht so bewusst, aber das ist wirklich viel

01:48:46.820 --> 01:48:48.220
Zeug bei Amazon. Und

01:48:48.220 --> 01:48:50.780
sie hatten das Problem, sie machen ungefähr 300 SQL

01:48:50.780 --> 01:48:52.580
Statements, wenn du

01:48:52.580 --> 01:48:54.900
die Seite anguckst.

01:48:55.020 --> 01:48:55.960
Oder ein paar hundert, ja.

01:48:57.420 --> 01:48:58.160
Da das

01:48:58.160 --> 01:48:58.660
irgendwie,

01:49:00.200 --> 01:49:02.140
da die irgendwie nur sequentiell ausgeführt

01:49:02.140 --> 01:49:04.200
wurden, macht das halt die Latenz hoch, weil

01:49:04.200 --> 01:49:05.940
ja, synchron

01:49:05.940 --> 01:49:08.280
sequentiell, das heißt, die ganzen

01:49:08.280 --> 01:49:09.400
Latenzen addieren sich auf.

01:49:10.380 --> 01:49:11.660
Das heißt, allein bis die ganzen

01:49:11.660 --> 01:49:13.980
SQL-Statements abgearbeitet sind,

01:49:14.040 --> 01:49:15.080
vergehen ein paar hundert Millisekunden,

01:49:15.720 --> 01:49:18.120
die du einfach warten musst. Und das ist halt

01:49:18.120 --> 01:49:19.560
scheiße. Man weiß ungefähr so,

01:49:20.260 --> 01:49:22.080
pro hundert Millisekunden droppt dein

01:49:22.080 --> 01:49:24.240
Conversion 10% oder so.

01:49:24.240 --> 01:49:25.660
Ich weiß nicht, wahrscheinlich weniger, aber

01:49:25.660 --> 01:49:28.820
ist halt nicht so gut.

01:49:29.280 --> 01:49:30.980
Das heißt, du kannst ja ausrechnen, wie viel mehr Umsatz

01:49:30.980 --> 01:49:32.980
du machen würdest, wenn du das irgendwie schneller ausliefern

01:49:32.980 --> 01:49:33.320
könntest.

01:49:35.040 --> 01:49:36.740
Ja, und dann haben sie sich halt gesagt,

01:49:36.840 --> 01:49:38.020
okay, das müssen wir irgendwie anders machen.

01:49:39.160 --> 01:49:40.940
Dann haben sie das halt in Services aufgeteilt.

01:49:41.040 --> 01:49:42.780
Dann haben sie gesagt, okay, wir haben hier den Recommendation Service,

01:49:42.980 --> 01:49:44.880
wo sich die Webseite per

01:49:44.880 --> 01:49:46.700
JavaScript irgendwie macht, irgendwie ein

01:49:46.700 --> 01:49:48.540
XHTTP-Request oder so und holt sich dann die

01:49:48.540 --> 01:49:49.960
Recommendations von diesem Service.

01:49:50.620 --> 01:49:52.580
Und dann haben wir den, keine Ahnung,

01:49:52.740 --> 01:49:54.800
Basket-Service für deine

01:49:54.800 --> 01:49:57.320
Einkaufskorb oder so

01:49:57.320 --> 01:49:58.980
und da ist halt, das Ding

01:49:58.980 --> 01:50:00.920
holt sich halt, was für Dinge liegen da momentan

01:50:00.920 --> 01:50:02.320
gerade drin und ja.

01:50:04.360 --> 01:50:04.760
Genau.

01:50:05.480 --> 01:50:05.780
Und das

01:50:05.780 --> 01:50:08.200
haben die damals so gemacht.

01:50:09.540 --> 01:50:11.000
Ja und dann, das geht dann natürlich alles

01:50:11.000 --> 01:50:12.900
irgendwie mehr oder weniger, auch nicht so total parallel,

01:50:13.020 --> 01:50:14.560
aber mehr paralleler als vorher

01:50:14.560 --> 01:50:17.000
und dann kann die Webseite insgesamt deutlich

01:50:17.000 --> 01:50:17.460
schneller sein.

01:50:19.540 --> 01:50:20.820
Ja, genau. Heute

01:50:20.820 --> 01:50:22.660
würde man sagen, Microservices, du hast halt ein

01:50:22.660 --> 01:50:24.780
Microservice pro irgendwie Ding,

01:50:24.880 --> 01:50:26.300
was du irgendwie da machst auf der Webseite.

01:50:27.400 --> 01:50:28.740
Und die

01:50:28.740 --> 01:50:30.640
komplette Seite aggregiert nur noch

01:50:30.640 --> 01:50:32.640
irgendwie die Daten aus all diesen Services.

01:50:34.360 --> 01:50:34.680
Ja,

01:50:34.900 --> 01:50:36.760
damit kriegt man das tatsächlich in den Griff, wenn man

01:50:36.760 --> 01:50:38.760
so ein riesiges Ding hat und viele unterschiedliche Sachen und das

01:50:38.760 --> 01:50:40.580
nicht mehr in einer Datenbank passt, dann kann man das so machen.

01:50:40.680 --> 01:50:42.020
Es ist aber nicht so, dass man das machen sollte.

01:50:42.640 --> 01:50:44.260
Solange man das anders machen kann,

01:50:44.260 --> 01:50:46.200
solange man das mit einer Datenbank hinkriegt,

01:50:46.260 --> 01:50:48.300
sollte man das mit einer Datenbank machen, weil das ist viel

01:50:48.300 --> 01:50:49.820
viel angenehmer.

01:50:50.240 --> 01:50:52.240
Also Microservices sind halt

01:50:52.240 --> 01:50:57.940
Man schiebt dann halt einen Haufen der Komplexität in eine andere Richtung.

01:50:58.180 --> 01:50:59.800
Man hat dann plötzlich Architekturkomplexität,

01:50:59.920 --> 01:51:05.740
man hat plötzlich im Ops-Teil von DevOps wird es plötzlich viel schwieriger,

01:51:05.840 --> 01:51:07.680
man muss halt das alles irgendwie maintainen.

01:51:07.800 --> 01:51:08.780
Man muss halt plötzlich, wenn man jetzt sagt,

01:51:08.780 --> 01:51:13.920
okay, ich update jetzt diesen Service,

01:51:14.320 --> 01:51:16.780
dann hängen da halt andere Dinge von ab unter Umständen.

01:51:18.240 --> 01:51:20.440
dann habe ich halt,

01:51:20.980 --> 01:51:22.000
ich kann, ja,

01:51:22.120 --> 01:51:23.720
wenn man das halt irgendwie so schön hat,

01:51:23.800 --> 01:51:25.860
Master-Slave-Architektur, Loadbalancer davor,

01:51:25.960 --> 01:51:27.640
vor den Datenbanken, ein paar Frontends,

01:51:28.220 --> 01:51:30.180
dann, selbst da ist es schon kompliziert,

01:51:30.240 --> 01:51:31.380
wenn ich jetzt irgendwie

01:51:31.380 --> 01:51:34.020
zum Beispiel ein Schema ändern möchte oder so,

01:51:34.040 --> 01:51:36.180
was ich im Produktivbetrieb dann vielleicht nicht mehr tun kann,

01:51:36.240 --> 01:51:38.220
weil die Datenbank viel zu langsam liefe,

01:51:38.280 --> 01:51:39.960
weil wenn ich das Schema ändere, muss ich

01:51:39.960 --> 01:51:42.300
bei den Tabellen, die ich ändere,

01:51:42.300 --> 01:51:44.280
halt unter Umständen eine Kopie der Tabellen mehr oder weniger mache,

01:51:44.380 --> 01:51:46.200
das heißt, ich muss halt möglicherweise doppelt so viel

01:51:46.200 --> 01:51:48.000
Daten im Hauptspeicher halten, was halt vielleicht nicht geht.

01:51:48.180 --> 01:51:50.740
das heißt, ich muss vielleicht sowas machen wie

01:51:50.740 --> 01:51:53.000
ich tausche die Datenbank aus, ich mache eine Kopie der Datenbank

01:51:53.000 --> 01:51:55.020
und die Datenbank mit dem neuen Schema

01:51:55.020 --> 01:51:56.940
stelle ich dann ins neuen Master rein

01:51:56.940 --> 01:51:58.780
und so, so oft hat man dann so Sachen wie

01:51:58.780 --> 01:52:00.880
oder wenn man die Software updatet, man nimmt

01:52:00.880 --> 01:52:01.320
halt Sachen

01:52:01.320 --> 01:52:04.780
Rechner aus der Verteilung

01:52:04.780 --> 01:52:06.580
im Loadbalancer, updatet den

01:52:06.580 --> 01:52:07.860
oder die Hälfte davon

01:52:07.860 --> 01:52:10.760
und die andere Hälfte läuft noch

01:52:10.760 --> 01:52:12.760
auf der alten Software und dann schaltet man halt

01:52:12.760 --> 01:52:14.580
um oder so, solche Sachen kann man machen

01:52:14.580 --> 01:52:16.660
und das geht noch, das ist auch dann schon

01:52:16.660 --> 01:52:18.740
kompliziert, weil man muss sich dann halt Gedanken

01:52:18.740 --> 01:52:20.120
machen, wie man das tut

01:52:20.120 --> 01:52:22.640
und man muss halt irgendein System haben, das das

01:52:22.640 --> 01:52:24.740
unterstützt, dass man das automatisch machen kann, sodass man halt

01:52:24.740 --> 01:52:26.580
nicht jedes Mal, wenn man

01:52:26.580 --> 01:52:28.720
irgendwie sowas wie eine Schemaänderung macht oder wenn man

01:52:28.720 --> 01:52:29.660
halt irgendwie eine

01:52:29.660 --> 01:52:32.780
komplexere Änderung im Applikationscode

01:52:32.780 --> 01:52:34.580
in den Frontends hat, dass man da halt dann irgendwie

01:52:34.580 --> 01:52:36.720
jemand setzen muss und das dann von Hand macht, das sollte nicht so sein,

01:52:36.800 --> 01:52:38.640
sondern man sollte halt auf den Knopf drücken und sagen, okay,

01:52:38.720 --> 01:52:40.640
jetzt räumen wir das mal aus und dann passieren diese

01:52:40.640 --> 01:52:42.260
Prozesse, die dafür nötig sind, automatisch.

01:52:43.260 --> 01:52:44.640
Wenn man Microservices hat, wird

01:52:44.640 --> 01:52:46.720
das Ganze viel schlimmer. Das ist halt da nicht so,

01:52:46.840 --> 01:52:48.800
dann hat man viel komplexere Abhängigkeiten

01:52:48.800 --> 01:52:50.720
zwischen den Geschichten und dann wird dieses ganze

01:52:50.720 --> 01:52:52.340
Ops-Thema halt richtig

01:52:52.340 --> 01:52:54.580
ätzend. Auch

01:52:54.580 --> 01:52:56.180
Skalierung wird richtig ätzend, weil

01:52:56.180 --> 01:52:58.180
dann willst du halt, wenn du halt

01:52:58.180 --> 01:53:00.280
in so einer klassischen Architektur hast du nur

01:53:00.280 --> 01:53:03.180
wenige unterschiedliche Arten von

01:53:03.180 --> 01:53:06.520
Maschinen, die halt irgendwas machen. Du hast halt Datenbanken,

01:53:06.680 --> 01:53:08.680
du hast halt irgendwie Redis oder sowas,

01:53:09.060 --> 01:53:10.020
du hast halt Frontends,

01:53:10.560 --> 01:53:12.000
vielleicht auch vorne irgendwie

01:53:12.000 --> 01:53:14.440
Web-Server, die SSL

01:53:14.440 --> 01:53:17.180
Terminierung machen oder so, aber

01:53:17.180 --> 01:53:19.540
das war es im Grunde. Also du hast nicht so wahnsinnig viele unterschiedliche

01:53:19.540 --> 01:53:21.240
Dinge. Beim Microservice hast du halt

01:53:21.240 --> 01:53:23.480
vielleicht hunderte unterschiedlicher

01:53:23.480 --> 01:53:25.600
Arten von Microservices, die du unterschiedlich skalieren musst,

01:53:25.660 --> 01:53:27.440
wo du auf unterschiedliche Sachen aufpassen musst. Das ist alles

01:53:27.440 --> 01:53:29.560
furchtbar. Also geht. Also man

01:53:29.560 --> 01:53:31.240
kriegt damit halt Sachen in den Griff, die

01:53:31.240 --> 01:53:33.120
dann halt, wenn man mit

01:53:33.120 --> 01:53:35.380
diesem Muster, man hat halt eine Datenbank, in der

01:53:35.380 --> 01:53:37.500
die Wahrheit drin steht, nicht mehr, wenn das

01:53:37.500 --> 01:53:39.320
nicht mehr ausreicht, kann man das dann halt so

01:53:39.320 --> 01:53:41.180
in den Griff kriegen, aber es ist halt dann schon schlimm.

01:53:41.980 --> 01:53:43.560
Ja, genau.

01:53:44.440 --> 01:53:46.700
Okay, sind wir schon ganz schön groß,

01:53:46.880 --> 01:53:48.840
das heißt, wir müssen noch ziemlich viel beachtet haben.

01:53:50.100 --> 01:53:52.440
Genau, oh, das habe ich, ja, was haben wir denn?

01:53:55.620 --> 01:53:58.960
Ja, vertikalisch noch.

01:53:58.960 --> 01:54:01.280
Ich gucke gerade in die Liste, was wir schon alles haben und was noch nicht.

01:54:01.980 --> 01:54:02.300
Genau.

01:54:04.600 --> 01:54:05.860
Das ist nämlich tatsächlich relativ viel.

01:54:06.100 --> 01:54:06.840
Ja, ja, ja, ja.

01:54:07.440 --> 01:54:09.400
Oh mein Gott, ich weiß nicht, wie lange sind wir denn schon dran?

01:54:09.520 --> 01:54:10.880
Ich glaube, wir sind über zwei Stunden schon, oder?

01:54:10.880 --> 01:54:11.140
Oh nein.

01:54:11.360 --> 01:54:11.960
Nein, noch nicht ganz.

01:54:12.080 --> 01:54:13.600
Na gut, dann ist es harmlos.

01:54:14.200 --> 01:54:16.520
Achso, genau.

01:54:16.620 --> 01:54:18.160
Was ich hier noch an einem Punkt war, es können auch

01:54:18.160 --> 01:54:20.740
im Analyse-System auch Sachen wieder zurücklaufen.

01:54:21.260 --> 01:54:22.640
Zum Beispiel gibt es halt diverse Sachen,

01:54:22.720 --> 01:54:24.720
die gelockt werden, die dann aber trotzdem für die Transaktionen

01:54:24.720 --> 01:54:25.460
wieder eine Rolle spielen.

01:54:26.840 --> 01:54:28.180
Wie so etwas, das hatten wir noch gar nicht.

01:54:28.280 --> 01:54:30.440
Auch die Suche. Am Anfang

01:54:30.440 --> 01:54:32.740
braucht man ja auf jeden Fall, wenn man so eine E-Commerce-Seite

01:54:32.740 --> 01:54:34.440
hat, irgendwie eine Suchmaschine, wo man

01:54:34.440 --> 01:54:35.680
nach Büchern suchen kann oder so.

01:54:37.940 --> 01:54:38.520
Das geht

01:54:38.520 --> 01:54:40.480
auch tatsächlich mit Postgres direkt voll gut.

01:54:41.080 --> 01:54:41.860
Hat integriert

01:54:41.860 --> 01:54:43.500
integrierten Volltext-Index.

01:54:44.100 --> 01:54:44.300
Yay!

01:54:45.880 --> 01:54:47.820
Und man möchte halt auch so eine Facette

01:54:47.820 --> 01:54:49.760
Navigation, nennt man das, haben, wo man,

01:54:49.960 --> 01:54:51.060
wenn man jetzt nach irgendwas gesucht hat,

01:54:52.260 --> 01:54:53.920
hat halt eine Ergebnisliste, dann möchte man

01:54:53.920 --> 01:54:55.960
einschränken nach Kategorien oder nach, weiß ich jetzt,

01:54:55.960 --> 01:54:57.420
wenn es nicht um Bücher geht, sondern um

01:54:57.420 --> 01:54:59.380
Elektronik oder so, kann man vielleicht noch

01:54:59.380 --> 01:55:00.940
Hauptspeicher oder

01:55:00.940 --> 01:55:03.640
Videorekorder, genau,

01:55:03.840 --> 01:55:05.640
VHS oder Betamax, ja,

01:55:05.720 --> 01:55:06.820
das möchte man vielleicht auswählen können.

01:55:08.660 --> 01:55:08.900
Und,

01:55:08.980 --> 01:55:11.580
genau, das geht

01:55:11.580 --> 01:55:13.780
Postgres alles sehr schön. Auch da

01:55:13.780 --> 01:55:14.820
kann man

01:55:14.820 --> 01:55:17.700
irgendwie die Counts für die Facetten ganz gut

01:55:17.700 --> 01:55:19.660
rauskriegen. Ansonsten, wenn man das halt über eine eigene

01:55:19.660 --> 01:55:23.360
Spezial-Datenbank, sowas wie

01:55:23.360 --> 01:55:24.700
Elasticsearch macht oder

01:55:24.700 --> 01:55:27.400
beides Lucene-basiert oder

01:55:27.400 --> 01:55:29.560
Solr oder so macht, dann hat man das Problem,

01:55:29.660 --> 01:55:31.860
da hat man auch wieder dieses, wie bei ETL, das Synchronisationsproblem.

01:55:32.020 --> 01:55:33.580
Du hast halt, wenn sich an der Datenbank was ändert, müssen

01:55:33.580 --> 01:55:35.000
die Änderungen in den Index rein.

01:55:35.900 --> 01:55:37.520
Da hast du eine Latenz dazwischen.

01:55:38.200 --> 01:55:39.920
Wenn du Sachen aus dem Index rausholst,

01:55:40.040 --> 01:55:43.000
du hast jetzt eine Volltext-Suchanfrage,

01:55:43.240 --> 01:55:44.420
du kriegst jetzt IDs aus der

01:55:44.420 --> 01:55:46.020
Suchmaschine, dann

01:55:46.020 --> 01:55:48.540
möchtest du aber vielleicht nach was filtern, was nur in der Datenbank

01:55:48.540 --> 01:55:50.480
drin steht, dann musst du nochmal auf die Datenbank

01:55:50.480 --> 01:55:52.640
da alle Daten rausziehen

01:55:52.640 --> 01:55:54.600
und dann nochmal Counts anders ausrechnen.

01:55:54.740 --> 01:55:56.740
Vielleicht ein paar der Facetten-Counts kommen aus der Suchmaschine,

01:55:57.220 --> 01:55:58.520
ein paar kommen aber aus der Datenbank.

01:55:59.040 --> 01:56:00.500
Das heißt, du hast nicht nur einen Roundtrip über die

01:56:00.500 --> 01:56:02.320
Suchmaschine, du hast auch noch einen Roundtrip über die Datenbank,

01:56:02.760 --> 01:56:03.940
wo du halt irgendwie select

01:56:03.940 --> 01:56:06.720
diverse Sachen vom Datenbank-Ware

01:56:06.720 --> 01:56:08.560
und dann kommt halt ID in und dann

01:56:08.560 --> 01:56:09.580
kommen tausend IDs und so.

01:56:10.040 --> 01:56:13.080
das ist alles kompliziert. Wenn das halt

01:56:13.080 --> 01:56:15.260
ein Statement ist, was du halt abfeuerst,

01:56:15.320 --> 01:56:17.300
oder halt vielleicht eins für

01:56:17.300 --> 01:56:19.160
die Daten selber und eins für die Counts oder so,

01:56:19.940 --> 01:56:21.480
dann ist das halt

01:56:21.480 --> 01:56:23.380
deutlich, ist alles irgendwie viel

01:56:23.380 --> 01:56:25.440
einfacher. Und mit Postgres kriegt

01:56:25.440 --> 01:56:26.940
man auch das am Anfang alles hin.

01:56:27.340 --> 01:56:29.140
Und ja, das ist eigentlich

01:56:29.140 --> 01:56:31.340
sehr nett. Irgendwann geht

01:56:31.340 --> 01:56:33.180
das aber wahrscheinlich dann halt eben auch nicht mehr. Dann muss man halt

01:56:33.180 --> 01:56:35.540
nach und nach Funktionen in Spezial

01:56:35.540 --> 01:56:37.020
Services halt auslagern.

01:56:37.200 --> 01:56:39.220
Einer der ersten, den man wahrscheinlich auslagern wird, ist

01:56:39.220 --> 01:56:41.240
halt Volltext suchen möglicherweise. Das macht

01:56:41.240 --> 01:56:42.680
dann halt irgendwann ein Listing Search oder

01:56:42.680 --> 01:56:44.400
Solar oder so.

01:56:45.660 --> 01:56:46.720
Aber halt auch

01:56:46.720 --> 01:56:49.240
eben sowas wie, wenn man

01:56:49.240 --> 01:56:51.140
jetzt anfängt, eine Query

01:56:51.140 --> 01:56:53.200
zu schreiben, dann kann man

01:56:53.200 --> 01:56:54.800
eben Google Suggest, hatte ich eben schon erwähnt,

01:56:55.780 --> 01:56:57.340
kriegt man halt so Vorschläge.

01:56:58.440 --> 01:56:59.420
Das ist im Grunde,

01:56:59.480 --> 01:57:01.100
man macht dann halt, man sucht auf

01:57:01.100 --> 01:57:02.700
den Queries

01:57:02.700 --> 01:57:05.080
von anderen Leuten. Aber dann hat man halt

01:57:05.080 --> 01:57:06.620
genau das Problem, dass halt

01:57:06.620 --> 01:57:09.160
sozusagen die History der Queries

01:57:09.160 --> 01:57:10.900
es muss halt irgendwie aus dem Analyse-Ding wieder zurück

01:57:10.900 --> 01:57:12.860
ins OLTP-System oder in irgendeinen anderen

01:57:12.860 --> 01:57:14.820
Service, auf dem man dann

01:57:14.820 --> 01:57:16.580
per Suffix-Tree irgendwie nach

01:57:16.580 --> 01:57:17.940
Queries,

01:57:18.340 --> 01:57:20.560
die möglichst ähnlich sind

01:57:20.560 --> 01:57:22.940
zu den drei Buchstaben, die man jetzt schon eingegeben

01:57:22.940 --> 01:57:24.980
hat oder so, raussuchen.

01:57:25.920 --> 01:57:26.760
Wie man die schneller tippen kann,

01:57:26.820 --> 01:57:27.620
drei, vier, fünf, ja.

01:57:28.360 --> 01:57:30.760
Man kann das am Anfang auch alles über Postgres machen,

01:57:30.840 --> 01:57:32.680
wenn es dann halt komplizierter wird, muss man das in eigene Services

01:57:32.680 --> 01:57:34.040
auslagern und so weiter.

01:57:34.180 --> 01:57:36.720
Dann wird das System größer und schwieriger

01:57:36.720 --> 01:57:37.940
und ja.

01:57:39.160 --> 01:57:40.440
Genau. Und

01:57:40.440 --> 01:57:42.920
ja, und immer die Datenbanken,

01:57:42.920 --> 01:57:44.660
die man nimmt, werden halt immer spezialisiert.

01:57:44.780 --> 01:57:46.840
Also das würde ich auch empfehlen. Also man fängt halt mit Postgres an,

01:57:46.940 --> 01:57:48.160
macht mit Postgres einfach alles.

01:57:48.960 --> 01:57:50.900
Und wenn man dann halt irgendwann an Grenzen stößt, dann muss man

01:57:50.900 --> 01:57:52.220
halt, ja,

01:57:53.160 --> 01:57:54.860
wo du dir übel, dann Sachen in

01:57:54.860 --> 01:57:56.800
halt Spezialdatenbanken auslagern. Wo du?

01:57:57.220 --> 01:57:58.480
Und ja,

01:57:59.360 --> 01:58:00.840
bezahlt dann halt

01:58:00.840 --> 01:58:01.620
mit Komplexität.

01:58:03.480 --> 01:58:03.840
Genau.

01:58:05.560 --> 01:58:06.520
Ja, jetzt müssen wir nochmal

01:58:06.520 --> 01:58:08.280
gucken, wie wir das weitermachen. Genau.

01:58:08.480 --> 01:58:10.760
Wir nehmen Redes zum Cachen einfach

01:58:10.760 --> 01:58:12.680
von langlaufenden

01:58:12.680 --> 01:58:14.700
Queries und von irgendwie gerenderten Fragmenten,

01:58:14.800 --> 01:58:16.560
die halt aufwendig zu rendern sind, also

01:58:16.560 --> 01:58:18.560
irgendwelche Listen von Dingen oder so, die

01:58:18.560 --> 01:58:20.580
sich aber jetzt nicht dauernd

01:58:20.580 --> 01:58:20.840
ändern.

01:58:23.680 --> 01:58:24.120
Und

01:58:24.120 --> 01:58:25.600
genau.

01:58:27.400 --> 01:58:28.920
Jetzt werden unsere Daten immer größer.

01:58:29.400 --> 01:58:30.720
Ja, die Daten werden noch immer größer

01:58:30.720 --> 01:58:32.780
und das Problem ist auch, wir sind mittlerweile weltweit unterwegs.

01:58:33.720 --> 01:58:34.640
Wir verkaufen nicht nur

01:58:34.640 --> 01:58:35.260
Bücher, wir verkaufen

01:58:35.260 --> 01:58:38.060
alles von A bis Z

01:58:38.060 --> 01:58:40.060
wie Amazon. Ich weiß nicht, ob ihr das schon gesehen habt,

01:58:40.220 --> 01:58:41.720
es gibt diesen Pfeil von A bis zum Z

01:58:41.720 --> 01:58:42.340
von Amazon.

01:58:43.580 --> 01:58:43.900
Und

01:58:43.900 --> 01:58:48.080
ja, dann stellt sich

01:58:48.080 --> 01:58:50.000
ja die Frage, wenn wir das global machen, wo stellen wir dann den Master

01:58:50.000 --> 01:58:51.540
eigentlich hin? Das ist halt auch schwierig.

01:58:52.900 --> 01:58:53.060
Ja.

01:58:54.120 --> 01:58:56.140
Wo wird der entstehen? Also in einem sicheren Land?

01:58:56.700 --> 01:58:57.000
Ja.

01:58:57.840 --> 01:59:00.240
Wir müssen an alle Stellen

01:59:00.240 --> 01:59:01.980
irgendwie so einen kleinen Master stellen, wo halt viel

01:59:01.980 --> 01:59:04.040
Traffic ist. Kann man den Master mürren,

01:59:04.120 --> 01:59:05.940
dass man ja tatsächlich sagt, dass überall derselbe...

01:59:05.940 --> 01:59:07.500
Ja, es gibt natürlich auch irgendwie für diese

01:59:07.500 --> 01:59:09.460
Geschichten so Lösungen, dass man halt, dass die Master sich

01:59:09.460 --> 01:59:11.600
miteinander synchronisieren, das gibt es für Postgres auch,

01:59:11.700 --> 01:59:13.680
aber das ist alles irgendwie, ich weiß nicht so genau.

01:59:13.680 --> 01:59:15.260
Alles nicht so richtig.

01:59:15.480 --> 01:59:16.480
Das funktioniert alles nicht so richtig.

01:59:17.800 --> 01:59:19.700
Und ja, es gibt auf jeden Fall

01:59:19.700 --> 01:59:21.420
keine nette...

01:59:21.420 --> 01:59:23.760
Es ist halt auch ein mehr oder weniger unlösbares Problem.

01:59:24.120 --> 01:59:25.640
Also das ist auch theoretisch quasi

01:59:25.640 --> 01:59:26.780
nicht wirklich in den Griff zu kriegen.

01:59:27.800 --> 01:59:29.660
Man kann aber Dinge tun,

01:59:29.720 --> 01:59:31.560
indem man halt auf andere Architekturen umstellt.

01:59:31.700 --> 01:59:32.100
Man kann halt

01:59:32.100 --> 01:59:34.580
ja, also

01:59:34.580 --> 01:59:36.300
ich habe jetzt mal hier als Beispiel genommen

01:59:36.300 --> 01:59:38.660
diese, du willst halt, dass manche

01:59:38.660 --> 01:59:39.760
Sachen immer funktionieren.

01:59:41.220 --> 01:59:42.360
Ja, eigentlich sollte immer

01:59:42.360 --> 01:59:43.640
alle möglichen Sachen funktionieren.

01:59:44.380 --> 01:59:46.700
Und manchmal ist dir dann halt irgendwie die Konsistenz

01:59:46.700 --> 01:59:48.180
und so egal. Also

01:59:48.180 --> 01:59:50.000
zum Beispiel für Amazon super wichtig

01:59:50.000 --> 01:59:52.580
ist halt der Einkaufswagen. Du musst halt immer

01:59:52.580 --> 01:59:53.860
weiter, das Spice muss fließen.

01:59:54.240 --> 01:59:55.540
Du musst immer weiter einkaufen können.

01:59:56.600 --> 01:59:58.460
Auch wenn jetzt, daher haben sie das

01:59:58.460 --> 02:00:00.100
halt, ich glaube das war auch, also das

02:00:00.100 --> 02:00:02.700
Amazon Dynamo basiert

02:00:02.700 --> 02:00:04.620
auf einem System, das sie für sich selbst gebaut

02:00:04.620 --> 02:00:06.120
haben, eben für genau diesen

02:00:06.120 --> 02:00:08.540
Shopping Basket und

02:00:08.540 --> 02:00:10.620
der halt genau darauf ausgelegt ist, dass dieses Ding halt

02:00:10.620 --> 02:00:12.620
einfach immer funktioniert. Und das ist mehr

02:00:12.620 --> 02:00:14.840
oder weniger einfach nur so ein total simpler Key-Value-Store

02:00:14.840 --> 02:00:17.000
und

02:00:17.000 --> 02:00:18.600
du lebst halt dann damit, dass das

02:00:18.600 --> 02:00:20.660
nicht konsistent ist. Oder dass halt

02:00:20.660 --> 02:00:22.600
wenn du was kaufst,

02:00:22.600 --> 02:00:24.480
das halt vielleicht nicht mehr im Lager ist. Das kann dann durchaus

02:00:24.480 --> 02:00:26.520
passieren, weil dieses Ding ist halt ein eigener Service, das

02:00:26.520 --> 02:00:28.620
hat keine Verbindung zu einer

02:00:28.620 --> 02:00:30.900
zentral, das hat schon keine Verbindung, aber es kann halt

02:00:30.900 --> 02:00:32.840
nicht den echten Status abfragen, weil

02:00:32.840 --> 02:00:34.220
wo ist der? Das ist halt schwer zu sagen.

02:00:35.960 --> 02:00:36.920
Und das, was Amazon

02:00:36.920 --> 02:00:38.920
dann macht, tatsächlich, habe ich auch gehört,

02:00:39.160 --> 02:00:40.880
dass solche Sachen können dann ja

02:00:40.880 --> 02:00:42.660
auftreten. Du kaufst ein Buch, das ist nicht mehr

02:00:42.660 --> 02:00:44.440
lieferbar.

02:00:45.380 --> 02:00:46.700
Und jetzt? Also das heißt,

02:00:46.800 --> 02:00:48.840
es fällt erst so fünf Minuten später, fällt bei Amazon

02:00:48.840 --> 02:00:50.820
auf, geht nicht. Wir haben

02:00:50.820 --> 02:00:52.720
jetzt zwar, hat jemand was bestellt, wir haben

02:00:52.720 --> 02:00:55.000
die Bestellung zugesagt, du hast eine Bestätigungsmail

02:00:55.000 --> 02:00:56.880
bekommen irgendwie und jetzt fällt aber auf

02:00:56.880 --> 02:00:58.660
so, im Lager ist das nicht mehr drin.

02:00:59.520 --> 02:01:00.840
Wir können es dir nicht schicken.

02:01:00.960 --> 02:01:01.620
Was macht Amazon dann?

02:01:02.740 --> 02:01:04.480
Entweder nachordern von irgendeinem Service,

02:01:04.640 --> 02:01:06.680
wie wir eben das Problem hatten, oder die sagen dann irgendwann

02:01:06.680 --> 02:01:08.920
so, wir schicken dir

02:01:08.920 --> 02:01:09.640
einen Gutschein raus,

02:01:10.000 --> 02:01:11.480
gibt es nicht.

02:01:12.600 --> 02:01:13.860
Entschuldigungsmail und sie geben dir einen Gutschein.

02:01:14.600 --> 02:01:16.640
Da das nicht so super häufig passiert, ist das

02:01:16.640 --> 02:01:18.120
halt nicht schlimm. Das ist halt

02:01:18.120 --> 02:01:20.540
viel einfacher, das

02:01:20.540 --> 02:01:22.040
über Gutschein zu lösen, als

02:01:22.040 --> 02:01:24.440
über ein Datenbanksystem, was das

02:01:24.440 --> 02:01:26.120
irgendwie handeln kann, weil das gibt es eben einfach nicht.

02:01:26.880 --> 02:01:28.380
Und ja.

02:01:30.080 --> 02:01:30.420
Einfach kurz den

02:01:30.420 --> 02:01:32.200
Rendit-Drucker anschmeißen, wird schnell nachproduziert.

02:01:33.940 --> 02:01:34.420
Ja.

02:01:35.620 --> 02:01:36.320
Ja, genau.

02:01:36.440 --> 02:01:38.400
Das ist halt das auch, was dann halt

02:01:38.400 --> 02:01:40.280
gebrochen wird, in relationalen

02:01:40.280 --> 02:01:41.580
Antenmanagements oft Acid.

02:01:42.180 --> 02:01:43.800
Also Atomicity,

02:01:44.260 --> 02:01:46.500
Consistency, Isolation und Durability.

02:01:48.780 --> 02:01:50.220
Atomicity ist eigentlich quasi das, was

02:01:50.220 --> 02:01:52.180
Transaktionen betrifft, dass halt entweder alles

02:01:52.180 --> 02:01:52.980
gut geht oder

02:01:52.980 --> 02:01:56.120
alles fehlschlägt,

02:01:56.180 --> 02:01:58.000
aber nicht irgendwie Teile einer Transaktion oder Teile

02:01:58.000 --> 02:02:00.080
von einer Menge von Dingen, die man tun will,

02:02:00.380 --> 02:02:02.140
halt gehen und dann mancher Sachen nicht gehen.

02:02:02.200 --> 02:02:04.100
Das sollte halt nicht passieren. Konsistenz,

02:02:04.120 --> 02:02:05.100
die heißt halt,

02:02:06.240 --> 02:02:06.320
dass

02:02:06.320 --> 02:02:09.800
die ganzen Foreign Key, also es ist halt die

02:02:09.800 --> 02:02:11.740
referenzielle Integrität halt gewahrt bleibt,

02:02:11.860 --> 02:02:14.080
dass da Sachen nicht zerbrechen, was halt dann auch nicht mehr geht,

02:02:14.120 --> 02:02:15.680
wenn du Sachen über mehrere Datenbanken verteilst, weil

02:02:15.680 --> 02:02:18.000
hast du halt teilweise eben keine

02:02:18.000 --> 02:02:19.520
direkten Verbindungen, sondern du hast halt bloß

02:02:19.520 --> 02:02:20.480
VR-Pies dazwischen.

02:02:23.220 --> 02:02:24.060
Isolation ist halt

02:02:24.060 --> 02:02:25.000
die Geschichte, dass du

02:02:25.000 --> 02:02:27.800
nicht Sachen,

02:02:28.060 --> 02:02:30.020
die andere Transaktionen machen, in deinen Daten

02:02:30.020 --> 02:02:31.940
siehst, also das halt, man nennt das Dirty Read,

02:02:32.000 --> 02:02:32.420
wenn du halt

02:02:32.420 --> 02:02:35.980
in deiner Transaktion Dinge aus anderen

02:02:35.980 --> 02:02:37.600
Transaktionen siehst, die noch nicht abgeschlossen sind,

02:02:38.500 --> 02:02:39.560
sodass du halt, dass du immer,

02:02:40.400 --> 02:02:41.900
dass deine Sicht auf die Datenbank komplett

02:02:41.900 --> 02:02:44.160
isoliert ist von den anderen. Es gibt unterschiedliche Isolationslevel,

02:02:45.620 --> 02:02:46.060
Postgres hat

02:02:46.060 --> 02:02:48.180
per Default den höchsten,

02:02:48.280 --> 02:02:48.580
glaube ich,

02:02:49.580 --> 02:02:52.060
Serializable ist der höchste, dann gibt es noch Repeatable Read,

02:02:54.000 --> 02:02:56.460
Und repeatable read war es, glaube ich, lange.

02:02:56.760 --> 02:02:58.140
Aber mittlerweile ist es serializable.

02:02:59.440 --> 02:03:00.820
Da kann man auch nachgucken, was das bedeutet.

02:03:01.000 --> 02:03:02.860
Es gibt da feine Unterschiede.

02:03:04.600 --> 02:03:09.800
Und genau, Isolation und Durability ist halt einfach nur das,

02:03:09.900 --> 02:03:12.480
wenn eine Transaktion gesagt hat, okay, ich bin durchgeführt,

02:03:12.580 --> 02:03:14.320
dass dann halt auch nichts mehr schiefgehen kann.

02:03:15.600 --> 02:03:18.100
Was extrem schwierig ist zu implementieren.

02:03:19.780 --> 02:03:20.460
Strom aus.

02:03:20.820 --> 02:03:23.920
Genau, Strom aus muss trotzdem, wenn die Datenbank wieder hochkommt,

02:03:24.000 --> 02:03:26.100
alles im richtigen Zustand

02:03:26.100 --> 02:03:27.920
sein. Aber das kann man ja oft

02:03:27.920 --> 02:03:30.080
dann nicht so wirklich gewährleisten. Also man kann ja nicht

02:03:30.080 --> 02:03:32.280
das halt...

02:03:32.280 --> 02:03:34.140
Der Hauptspeicher ist ja flüchtig und nicht...

02:03:34.140 --> 02:03:36.140
Der Hauptspeicher ist flüchtig, das heißt, man darf es nicht in den Hauptspeicher

02:03:36.140 --> 02:03:37.960
einfach nur schreiben, sondern die Transaktion

02:03:37.960 --> 02:03:39.560
darf erst als dann durchgegangen

02:03:39.560 --> 02:03:44.520
zurück...

02:03:44.520 --> 02:03:46.160
ist durchgegangen, wird zurückgegeben,

02:03:46.260 --> 02:03:48.260
wenn das im Write-Ahead-Log gelandet

02:03:48.260 --> 02:03:49.880
ist und das mit F-Sync

02:03:49.880 --> 02:03:51.540
irgendwie auf die Platte geschrieben ist.

02:03:53.340 --> 02:04:04.920
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.

02:04:04.920 --> 02:04:22.000
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,

02:04:22.000 --> 02:04:43.140
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.

02:04:43.740 --> 02:04:45.940
hat man ja viele Tests

02:04:45.940 --> 02:04:47.880
für eine Applikation und es dauert

02:04:47.880 --> 02:04:49.880
lange, bis die durchlaufen, wenn man jetzt irgendeine Änderung

02:04:49.880 --> 02:04:51.800
macht und man führt die Tests

02:04:51.800 --> 02:04:53.780
aus und das dauert ein paar Minuten, das ist halt schlecht, weil

02:04:53.780 --> 02:04:55.740
es halt diesen, man ändert

02:04:55.740 --> 02:04:57.680
was, führt die Tests aus und

02:04:57.680 --> 02:04:59.880
hat dann sofort Feedback-Cycle

02:04:59.880 --> 02:05:01.800
irgendwie kaputt

02:05:01.800 --> 02:05:03.580
macht, wenn man dann halt irgendwie Kaffee trinken

02:05:03.580 --> 02:05:05.640
gehen muss und das macht auch so ein bisschen die

02:05:05.640 --> 02:05:06.340
Konzentration kaputt.

02:05:08.260 --> 02:05:09.720
Daher wäre es schön, wenn die Tests

02:05:09.720 --> 02:05:11.200
irgendwie schnell laufen würden und

02:05:11.200 --> 02:05:12.920
da man aber

02:05:12.920 --> 02:05:15.460
auch für die Tests, jetzt wenn man jetzt ein Django-Projekt

02:05:15.460 --> 02:05:17.300
hat, auch die echte Daten, auch Postgres verwenden

02:05:17.300 --> 02:05:19.200
will, was viele Leute machen, früher gemacht haben,

02:05:20.140 --> 02:05:21.260
ist dann halt ein SQLite zu

02:05:21.260 --> 02:05:22.940
verwenden, das nur in Memory ist.

02:05:23.720 --> 02:05:25.320
Das geht dann viel schneller, aber das Problem ist halt,

02:05:26.000 --> 02:05:27.420
dass SQLite sich anders

02:05:27.420 --> 02:05:29.240
verhält als Postgres und dann laufen die Tests

02:05:29.240 --> 02:05:31.260
durch und man denkt, das ist alles gut und dann geht's

02:05:31.260 --> 02:05:32.700
auf die Datenbank und dann geht's schief.

02:05:33.260 --> 02:05:35.260
Nicht so gut. Aber was man

02:05:35.260 --> 02:05:36.300
tatsächlich machen kann, ist

02:05:36.300 --> 02:05:39.180
Postgres zu sagen, ja, irgendwie nicht F-Synchen.

02:05:39.500 --> 02:05:41.300
Macht man nicht. Und man

02:05:41.300 --> 02:05:43.240
kann auch die Postgres dann auf eine

02:05:43.240 --> 02:05:45.400
In-Memory-Partition

02:05:45.400 --> 02:05:46.620
legen quasi, das geht auch.

02:05:47.500 --> 02:05:49.220
Kann man auch irgendwie per Docker-Argumenten kann man das

02:05:49.220 --> 02:05:51.220
irgendwie sagen und dann sind die Tests halt viel, viel schneller.

02:05:51.440 --> 02:05:53.000
Ja, weil für Tests ist es mir egal, ob das jetzt,

02:05:53.240 --> 02:05:54.620
wenn der Strom ausgeht, dann ist es mir wurscht.

02:05:54.860 --> 02:05:57.080
Ich meine, die Testdatenbank schmeißt sich sowieso

02:05:57.080 --> 02:05:58.500
nach jedem Testlauf wieder weg quasi.

02:05:59.460 --> 02:06:01.120
Also, ja, aber

02:06:01.120 --> 02:06:03.080
für die echte Produktionsdatenbank, die muss

02:06:03.080 --> 02:06:05.240
halt bei Transaktionen tatsächlich dafür sorgen,

02:06:05.360 --> 02:06:07.040
dass das nicht mehr verschwinden kann und das heißt,

02:06:07.100 --> 02:06:09.200
sie muss Epsilon aufrufen und dann, ja, ist das

02:06:09.200 --> 02:06:10.700
halt einfach langsam, da kann man auch nichts machen.

02:06:11.300 --> 02:06:14.280
Okay, einmal ein bisschen Acid.

02:06:14.640 --> 02:06:15.540
Ja, genau, haben wir Acid.

02:06:16.120 --> 02:06:18.400
Und dann, ja, also was wir

02:06:18.400 --> 02:06:20.240
dann heutzutage oft haben, sehen

02:06:20.240 --> 02:06:22.580
bei

02:06:22.580 --> 02:06:24.560
Datenbanken,

02:06:24.780 --> 02:06:26.280
die das halt, oder Dokumentdatenbanken,

02:06:26.560 --> 02:06:28.140
genau, ist halt ein anderes

02:06:28.140 --> 02:06:30.340
Paradigmen, das nennt sich Base.

02:06:30.640 --> 02:06:32.680
Also Basic Availability, Soft State,

02:06:32.760 --> 02:06:33.800
Eventual Consistency.

02:06:34.360 --> 02:06:36.320
Also, wo man halt versucht, die Sachen so

02:06:36.320 --> 02:06:38.180
aufzulockern, um halt es möglich zu machen,

02:06:38.260 --> 02:06:41.220
dass man zum Beispiel mehrere...

02:06:41.300 --> 02:06:43.680
mehrere Datenbanken schreiben kann.

02:06:47.380 --> 02:06:50.060
Ja, wir sind jetzt ziemlich groß geworden, oder?

02:06:51.080 --> 02:06:52.820
Ja, genau, wir sind jetzt ziemlich groß

02:06:52.820 --> 02:06:54.580
und was wir jetzt haben, wenn wir auf mehrere Sachen

02:06:54.580 --> 02:06:59.000
schreiben wollen, ist halt, genau,

02:06:59.100 --> 02:07:00.780
das Asset ist halt weg, Pech gehabt.

02:07:01.060 --> 02:07:04.060
Nein, wir haben noch ein anderes Ding,

02:07:05.040 --> 02:07:10.820
das ist dann noch das Cap Theorem Consistency Availability

02:07:10.820 --> 02:07:12.020
und Partition Tolerance,

02:07:12.800 --> 02:07:14.400
das ist halt auch diese, immer wenn man so Sachen

02:07:14.400 --> 02:07:16.160
Pick-Two-Out-Of-Three-Sachen sieht,

02:07:16.900 --> 02:07:18.700
also das CAP-Theorem ist halt so das ursprüngliche

02:07:18.700 --> 02:07:20.680
Ding dafür, du kannst halt zwei davon

02:07:20.680 --> 02:07:22.620
hinkriegen, aber drei nicht. Und Partition Tolerance ist

02:07:22.620 --> 02:07:24.800
leider nicht optional. Das musst du halt haben.

02:07:25.380 --> 02:07:26.820
Partition was? Partition Tolerance.

02:07:26.940 --> 02:07:28.720
Also was ist, wenn Netzwerkverbindungen

02:07:28.720 --> 02:07:30.740
zwischen zwei deiner Datenbank-Dinger

02:07:30.740 --> 02:07:31.880
irgendwie wegfällt oder so?

02:07:33.320 --> 02:07:34.360
Das musst du halt leider,

02:07:34.920 --> 02:07:36.780
das ist halt mandatory

02:07:36.780 --> 02:07:37.180
sozusagen.

02:07:38.460 --> 02:07:39.920
Das heißt, du kannst nur noch zwischen

02:07:39.920 --> 02:07:42.880
Consistency und Availability

02:07:42.880 --> 02:07:44.400
halt irgendwie wählen.

02:07:45.040 --> 02:07:46.640
Und du hast halt, ja,

02:07:46.780 --> 02:07:48.620
dann gibt es halt Datenbanken, die dann halt

02:07:48.620 --> 02:07:50.980
unterschiedliche Trade-Offs realisieren.

02:07:54.860 --> 02:07:55.060
Ja,

02:07:55.840 --> 02:07:58.220
genau.

02:07:59.180 --> 02:08:01.020
Das ist zum Beispiel, ein interessanter

02:08:01.020 --> 02:08:02.560
Fall ist halt sowas wie CouchDB,

02:08:04.340 --> 02:08:04.900
die halt,

02:08:05.400 --> 02:08:06.800
wo du sogar, wenn du halt offline

02:08:06.800 --> 02:08:07.940
bist, immer noch

02:08:07.940 --> 02:08:10.740
eine Datenbankverbindung

02:08:10.740 --> 02:08:12.680
hast oder immer noch deine Applikation benutzen kannst

02:08:12.680 --> 02:08:14.160
und die schreibt dann halt das in eine lokale

02:08:14.160 --> 02:08:16.540
CouchDB-Instanz, auch interessant,

02:08:17.340 --> 02:08:18.660
weil es ist halt so ein JavaScript-Ding,

02:08:18.740 --> 02:08:19.620
aber

02:08:19.620 --> 02:08:22.780
früher hatte man

02:08:22.780 --> 02:08:24.720
so jQuery als Abstraktionslevel für

02:08:24.720 --> 02:08:26.580
alles, was irgendwie auf diesem

02:08:26.580 --> 02:08:28.680
DOM-Modell im Browser irgendwie Dinge

02:08:28.680 --> 02:08:30.620
tut. Man möchte es ja vereinheitlichen, alle Browser haben

02:08:30.620 --> 02:08:32.280
das unterschiedliche, haben da unterschiedliche Funktionen gehabt,

02:08:32.660 --> 02:08:34.680
also hatte man jQuery und wenn man jQuery

02:08:34.680 --> 02:08:36.320
konnte, dann war es einem halt quasi egal,

02:08:36.840 --> 02:08:38.440
welcher Browser da drunter lag.

02:08:38.520 --> 02:08:40.500
Und bei CouchDB ist es so, das abstrahiert so ein bisschen

02:08:40.500 --> 02:08:42.560
diese Storage-APIs, die Browser haben.

02:08:43.620 --> 02:08:44.780
Das ist halt quasi dafür gedacht,

02:08:44.880 --> 02:08:46.080
wenn du jetzt eine lokale,

02:08:47.120 --> 02:08:49.100
wenn du eine Webseite

02:08:49.100 --> 02:08:51.300
auf einem Smartphone hast

02:08:51.300 --> 02:08:53.180
oder so, und du hast halt nicht immer Verbindungen,

02:08:54.320 --> 02:08:55.300
du möchtest aber trotzdem,

02:08:55.520 --> 02:08:57.140
dass sich deine Webseite so anfühlt,

02:08:57.320 --> 02:08:58.960
als hättest du irgendwie eine Verbindung.

02:08:59.860 --> 02:09:01.340
So offline first

02:09:01.340 --> 02:09:03.220
oder so, jetzt im Shopping-Kontext

02:09:03.220 --> 02:09:04.940
ist das halt nicht so richtig gut

02:09:04.940 --> 02:09:06.940
vorstelle, warum das irgendwie sinnvoll ist, aber

02:09:06.940 --> 02:09:08.240
nehmen wir an, du hast jetzt irgendwie sowas wie

02:09:08.240 --> 02:09:10.980
Trello, also irgendwie so Tasks oder so,

02:09:11.040 --> 02:09:13.020
wo du Sachen machen kannst, da möchtest

02:09:13.020 --> 02:09:14.760
du nicht, dass wenn jetzt du durch einen Tunnel fährst,

02:09:14.840 --> 02:09:16.260
dann nichts mehr geht, sondern

02:09:16.260 --> 02:09:18.880
das geht halt mit CouchDB, das ist halt

02:09:18.880 --> 02:09:20.800
sozusagen wie Jackfairy ein Layer über dem

02:09:20.800 --> 02:09:22.900
Storage-API von deinem Browser, weil

02:09:22.900 --> 02:09:24.920
die können das ja auch alle mittlerweile, die haben meistens SQLite

02:09:24.920 --> 02:09:26.600
oder sonst irgendwas drunter und dann halt

02:09:26.600 --> 02:09:28.620
APIs, mit denen du da irgendwie Dinge drauf tun kannst

02:09:28.620 --> 02:09:30.560
und

02:09:30.560 --> 02:09:32.840
was CouchDB jetzt letztendlich macht,

02:09:32.940 --> 02:09:34.720
ist da nochmal ein Layer drüber zu liegen und

02:09:34.720 --> 02:09:37.760
so ein Replikationsfeature

02:09:37.760 --> 02:09:39.180
zu haben in alle möglichen

02:09:39.180 --> 02:09:41.040
Richtungen. Also es ist halt Master, Master

02:09:41.040 --> 02:09:43.160
oder Datenbank zu Datenbank

02:09:43.160 --> 02:09:45.060
in alle Richtungen. Es ist halt nur so, dass ab und zu

02:09:45.060 --> 02:09:47.160
Konflikte auftreten und die müssen dann vom User

02:09:47.160 --> 02:09:48.940
gelöst werden. Das heißt, du wirst dann

02:09:48.940 --> 02:09:50.840
manchmal gefragt, ist das oder das richtig?

02:09:52.180 --> 02:09:53.000
Aber das passiert

02:09:53.000 --> 02:09:55.040
jetzt auch nicht so super häufig und das ist halt

02:09:55.040 --> 02:09:55.700
schon sehr, sehr nett.

02:09:56.220 --> 02:09:59.260
Also du kannst

02:09:59.260 --> 02:10:00.860
halt, auch wenn du offline bist, deine

02:10:00.860 --> 02:10:02.600
Web-Anwendung weiter so benutzen als

02:10:02.600 --> 02:10:04.720
als wärst du online

02:10:04.720 --> 02:10:06.920
und das synchronisiert sich halt in dem Moment,

02:10:07.060 --> 02:10:07.940
wo du halt wieder Verbindung hast.

02:10:09.680 --> 02:10:09.780
Und

02:10:09.780 --> 02:10:13.260
ja, das ist halt dann sehr auf der Availability-Seite

02:10:13.260 --> 02:10:14.820
und halt dann auf der Konsistenz-Seite halt nicht.

02:10:15.000 --> 02:10:16.420
Deswegen musst du halt dann

02:10:16.420 --> 02:10:19.160
Sachen auch, Konflikte manuell unter Umständen

02:10:19.160 --> 02:10:19.440
lösen.

02:10:22.640 --> 02:10:23.040
Genau.

02:10:25.020 --> 02:10:25.420
Ja.

02:10:27.040 --> 02:10:28.280
So, jetzt haben wir, okay.

02:10:30.380 --> 02:10:31.620
Jetzt sind wir, glaube ich,

02:10:31.840 --> 02:10:33.860
im Grunde mit dem

02:10:33.860 --> 02:10:35.540
ganzen traditionellen Kram

02:10:35.540 --> 02:10:37.820
mehr oder weniger durch. Ja, wahrscheinlich nicht so wirklich.

02:10:38.800 --> 02:10:39.800
Er hat es schon ganz lange geschafft,

02:10:39.880 --> 02:10:40.800
bis er es hier geschafft hat.

02:10:40.800 --> 02:10:42.720
Ja, aber und jetzt kommt

02:10:42.720 --> 02:10:44.820
eigentlich nur noch ein Teil und das ist halt

02:10:44.820 --> 02:10:46.600
irgendwie so Big Data oder

02:10:46.600 --> 02:10:48.680
Urlaub-Geschichten für

02:10:48.680 --> 02:10:50.820
wirklich große Systeme. Really, really, really

02:10:50.820 --> 02:10:52.640
big things. Ja, also

02:10:52.640 --> 02:10:54.780
ich meine, Big Data ist ja so ein bisschen, ich weiß nicht, was

02:10:54.780 --> 02:10:55.640
ein Passwort.

02:10:56.220 --> 02:10:58.300
Was würdest du sagen, ist Big Data oder

02:10:58.300 --> 02:11:00.680
warum wollen Leute das haben?

02:11:01.180 --> 02:11:03.460
Ja, also erstmal hört sich cool an und also jede Excel-Tablette

02:11:03.460 --> 02:11:05.080
mit mehr als, weiß nicht, tausend Teilen kann man schon

02:11:05.080 --> 02:11:07.460
einen Trick machen oder sowas. Also das kommt

02:11:07.460 --> 02:11:09.420
halt, glaube ich, ein bisschen auf den Anwendungsfall an und jeder

02:11:09.420 --> 02:11:11.460
hat natürlich gerne Big Data, weil es natürlich super ist,

02:11:11.840 --> 02:11:13.060
man ganz viel machen kann, man

02:11:13.060 --> 02:11:14.920
kann Analysen mitfahren und sowas.

02:11:15.800 --> 02:11:17.720
Alles, was halt irgendwie anfällt

02:11:17.720 --> 02:11:19.600
an Dingen, die man durch die ganzen modernen

02:11:19.600 --> 02:11:20.980
Daten irgendwie so jederzeit bekommt,

02:11:21.420 --> 02:11:23.640
ist dann irgendwann sehr big. Fühlt sich einfach groß an,

02:11:23.700 --> 02:11:25.320
wenn man ganz viele

02:11:25.320 --> 02:11:27.420
Sensordaten von verschiedenen Punkten bekommt. Was soll man damit machen?

02:11:27.500 --> 02:11:29.360
Man treibt hier irgendwelche Excel-Tabellen rein.

02:11:29.540 --> 02:11:32.160
Die liegen dann halt auf irgendwelchen

02:11:32.160 --> 02:11:33.860
Servern oder halt auch

02:11:33.860 --> 02:11:35.860
einfach nur Rechnern rum und haben halt ganz

02:11:35.860 --> 02:11:37.820
viele große Informationen, ohne dass man damit was anfangen kann

02:11:37.820 --> 02:11:39.980
bisher. Das ist vielleicht schon Big Data,

02:11:40.080 --> 02:11:41.860
ich weiß nicht. Also ich glaube, dass überall

02:11:41.860 --> 02:11:43.840
Daten vorhanden sind, ist vielleicht das

02:11:43.840 --> 02:11:45.680
eigentliche Big Data, aber ob jetzt so

02:11:45.680 --> 02:11:47.900
im Einzelfall das wirklich Big ist, was sagst du?

02:11:48.260 --> 02:11:49.760
Ja, also genau, ich habe

02:11:49.760 --> 02:11:51.800
auch, es gibt dann sehr unterschiedliche

02:11:51.800 --> 02:11:53.880
Auffassungen

02:11:53.880 --> 02:11:55.740
davon. Es gibt dann Leute, die sagen so, ja, was ist nicht mehr

02:11:55.740 --> 02:11:57.280
in der Excel-Tabelle, was ist das schon so?

02:11:57.580 --> 02:11:59.160
Also ich würde sagen, vielleicht etwas halbwegs

02:11:59.160 --> 02:12:00.940
Vernünftigere ist halt, was nicht mehr auf einen Computer passt.

02:12:01.640 --> 02:12:03.220
Aber auch das greift eigentlich zu kurz.

02:12:03.400 --> 02:12:04.820
Ich habe dann letztens nochmal irgendwie

02:12:04.820 --> 02:12:07.820
Meine Spiele dann nur.

02:12:08.640 --> 02:12:10.980
Das war irgendein Talk von Michael Stonebreaker.

02:12:11.220 --> 02:12:13.140
Das sind immer die gleichen Namen,

02:12:13.220 --> 02:12:15.140
auf die man irgendwie in dieser Datenmark-Welt stößt.

02:12:15.240 --> 02:12:16.800
Das sind halt so Michael Stonebreaker,

02:12:16.940 --> 02:12:18.400
Jim Ray, Ted Kord,

02:12:19.540 --> 02:12:20.020
weiß ich nicht,

02:12:20.720 --> 02:12:21.300
Ducatting.

02:12:23.540 --> 02:12:24.320
Das ist auch

02:12:24.320 --> 02:12:25.720
der, der hat auch

02:12:25.720 --> 02:12:28.360
der hat Postgres mitbegründet

02:12:28.360 --> 02:12:30.340
oder Ingress vorher und dann Postgres

02:12:30.340 --> 02:12:32.420
und auch viele

02:12:32.420 --> 02:12:34.160
der noch moderne, der heute

02:12:34.160 --> 02:12:35.960
ganz modernen Geschichten wie

02:12:35.960 --> 02:12:38.320
Column Stores, also C-Store, Paper ist von ihm

02:12:38.320 --> 02:12:40.240
VaultDB für so

02:12:40.240 --> 02:12:42.500
In-Memory-Datenbanken-Geschichten

02:12:42.500 --> 02:12:46.400
ja, der definiert das so

02:12:46.400 --> 02:12:48.480
der sagt halt, naja, es gibt eigentlich nur noch drei Arten

02:12:48.480 --> 02:12:50.240
wie Data Big sein kann, nämlich

02:12:50.240 --> 02:12:52.560
irgendwie, ja, es ist einfach zu viel

02:12:52.560 --> 02:12:54.120
ja, du hast, und der sagt halt

02:12:54.120 --> 02:12:56.520
nicht irgendwas Konkretes, sondern du hast halt

02:12:56.520 --> 02:12:58.300
Probleme mit der Datenmenge. Also es ist halt, wenn du

02:12:58.300 --> 02:13:00.580
wirklich Schwierigkeiten damit hast und damit nicht fertig wärst,

02:13:00.680 --> 02:13:02.600
dann hast du halt ein Problem mit der

02:13:02.600 --> 02:13:04.500
Datenmenge und dann hast du halt Big Data, weil es

02:13:04.500 --> 02:13:06.480
halt für dich schwierig ist, mit dieser Menge

02:13:06.480 --> 02:13:08.680
klarzukommen. Aber was halt auch sein kann,

02:13:08.820 --> 02:13:10.540
ist, und dann hast du halt auch ein Big Data Problem,

02:13:11.020 --> 02:13:12.380
auch wenn es jetzt nicht unbedingt

02:13:12.380 --> 02:13:13.140
eins ist, das

02:13:13.140 --> 02:13:16.400
mit der Datenmenge zu tun hat, wenn die Daten zu schnell kommen.

02:13:16.700 --> 02:13:18.280
Also du könntest mit der Datenmenge vielleicht klarkommen,

02:13:18.380 --> 02:13:20.060
aber sie kommen so schnell, dass du irgendwie nicht fertig wirst.

02:13:20.060 --> 02:13:22.100
Dann hast du so ein Respy oder sowas und das ist dann mal begrenzt

02:13:22.100 --> 02:13:24.100
und dann... Ja, dann hast du auch ein Big Data Problem,

02:13:24.220 --> 02:13:25.940
aber halt eine andere Art von Big Data Problem.

02:13:26.100 --> 02:13:27.960
Es gibt dann noch eins, das ist halt, wenn

02:13:27.960 --> 02:13:30.300
Daten aus ganz vielen sehr unterschiedlichen

02:13:30.300 --> 02:13:31.720
Quellen und sehr unterschiedlicher Art kommen,

02:13:32.020 --> 02:13:33.980
es sind vielleicht gar nicht so viele und sie kommen auch nicht so schnell,

02:13:34.280 --> 02:13:36.000
aber du kriegst sie nicht schnell genug integriert

02:13:36.000 --> 02:13:38.040
oder kriegst es halt nicht in den Griff. Da hast du auch wieder

02:13:38.040 --> 02:13:40.080
ein Big Data Problem, was auch wieder leicht anders ist. Und diese drei

02:13:40.080 --> 02:13:41.800
Dinger sind halt eigentlich alle irgendwie so ein bisschen

02:13:41.800 --> 02:13:44.060
unterschiedlich. Und

02:13:44.060 --> 02:13:45.060
ja,

02:13:45.860 --> 02:13:46.500
oft

02:13:46.500 --> 02:13:49.700
wird es nicht so richtig klar. Und oft ist es,

02:13:49.700 --> 02:13:51.880
also ich würde sagen, Big Data ist so ein gehyptes

02:13:51.880 --> 02:13:53.560
Ding und

02:13:53.560 --> 02:13:55.700
ja, irgendwie

02:13:55.700 --> 02:13:57.260
es werden ganz viele Hadoop-Cluster verkauft.

02:13:58.300 --> 02:13:59.280
Was ist ein Hadoop-Cluster?

02:14:00.680 --> 02:14:01.740
Ja, es ist

02:14:01.740 --> 02:14:03.640
Hadoop ist irgendwie so

02:14:03.640 --> 02:14:04.920
ein, das Start ist

02:14:04.920 --> 02:14:07.920
ein Apache-Projekt,

02:14:07.920 --> 02:14:09.560
das irgendwie mal gestartet ist als

02:14:09.560 --> 02:14:11.440
Implementierung eines

02:14:11.440 --> 02:14:13.320
Konzepts, nennt sich MapReduce.

02:14:13.860 --> 02:14:15.640
Das ist ein Paper, das hat Google mal veröffentlicht.

02:14:16.420 --> 02:14:17.840
Jeff Dean und noch ein paar andere

02:14:17.840 --> 02:14:19.900
haben das veröffentlicht, 2004

02:14:19.900 --> 02:14:21.420
glaube ich. Und

02:14:21.420 --> 02:14:22.920
das ist halt eine Art, mit

02:14:22.920 --> 02:14:25.680
großen Datenmengen umzugehen und die halt so

02:14:25.680 --> 02:14:27.680
horizontal auf ganz viele

02:14:27.680 --> 02:14:28.400
Maschinen zu skalieren.

02:14:29.320 --> 02:14:31.680
Das funktioniert im Grunde so, dass es halt auch genau dafür gedacht

02:14:31.680 --> 02:14:33.580
ist, wenn man jetzt einen großen Suchindex, wie man

02:14:33.580 --> 02:14:35.020
bei Google zum Beispiel hat,

02:14:35.380 --> 02:14:36.680
bauen möchte über das gesamte Web,

02:14:37.480 --> 02:14:39.480
dann kann man das halt eben nicht auf einer Maschine tun.

02:14:39.580 --> 02:14:40.560
Das ist halt völlig ausgeschlossen.

02:14:41.840 --> 02:14:43.400
Und man möchte das halt irgendwie

02:14:43.400 --> 02:14:45.760
auf möglichst

02:14:45.760 --> 02:14:47.680
viele Maschinen, so eine halbe Million oder eine Million oder so

02:14:47.680 --> 02:14:49.540
skalieren. Wie macht man das?

02:14:49.700 --> 02:14:51.460
Und das Konzept, das sie sich dafür überlegt haben,

02:14:51.540 --> 02:14:52.580
nennt sich halt MapReduce und

02:14:52.580 --> 02:14:54.980
ist auch eigentlich nicht wirklich was Neues.

02:14:55.140 --> 02:14:56.500
Früher gab es auch schon ähnliche Konzepte,

02:14:56.620 --> 02:14:58.920
wie sich ScatterGather oder sowas.

02:14:59.920 --> 02:15:02.020
Und im Distributed Computing Teil

02:15:02.020 --> 02:15:03.440
gibt es auch diverse Geschichten, die so ähnlich sind.

02:15:03.780 --> 02:15:05.680
Aber so auf der Skala und so

02:15:05.680 --> 02:15:07.060
und die Art, wie sie das konkret machen,

02:15:07.060 --> 02:15:08.420
war schon irgendwie was Neues

02:15:08.420 --> 02:15:10.400
und auch ein sehr, sehr cooler Ansatz.

02:15:10.980 --> 02:15:12.000
Und zwar machen sie das halt so,

02:15:12.600 --> 02:15:13.720
also im Grunde kann man sich das vorstellen,

02:15:13.800 --> 02:15:15.020
wenn man jetzt eine Webseite hat,

02:15:15.420 --> 02:15:18.140
viele Rechner, die halt Webseiten crawlen,

02:15:18.680 --> 02:15:20.300
nimmt man den Text, zerlegt den halt in Worte

02:15:20.300 --> 02:15:22.580
und man spuckt jetzt

02:15:22.580 --> 02:15:24.800
sozusagen für jedes Wort, einmal das Wort

02:15:24.800 --> 02:15:26.840
oder für die Webseite, die Worte

02:15:26.840 --> 02:15:28.520
aus, aus denen die Webseite besteht,

02:15:28.780 --> 02:15:30.300
plus die Anzahl, wie oft das vorkommt.

02:15:31.220 --> 02:15:32.440
Das ist halt sozusagen die Map-Phase.

02:15:32.640 --> 02:15:33.720
Und das machst du jetzt auf allen

02:15:33.720 --> 02:15:36.540
Maschinen. Und dann

02:15:36.540 --> 02:15:38.660
führst du das halt irgendwann wieder zusammen in einem Reducer.

02:15:40.720 --> 02:15:40.920
Und

02:15:40.920 --> 02:15:42.700
also was du bauen möchtest,

02:15:42.700 --> 02:15:44.000
ist sozusagen so ein

02:15:44.000 --> 02:15:46.340
Index, das ist halt

02:15:46.340 --> 02:15:48.620
wie ein Index

02:15:48.620 --> 02:15:50.400
in einem Buch,

02:15:51.640 --> 02:15:52.820
wo halt steht,

02:15:52.920 --> 02:15:54.240
welches Wort kommt auf welcher Seite vor.

02:15:54.720 --> 02:15:56.920
Und du musst halt für so ein Webseiten-Internet

02:15:56.920 --> 02:15:58.780
musst du halt sagen, welches Wort kommt auf welcher

02:15:58.780 --> 02:15:59.300
Webseite

02:15:59.300 --> 02:16:02.760
vor. Das ist halt das, was du

02:16:02.760 --> 02:16:03.500
hinterher haben willst.

02:16:05.120 --> 02:16:06.800
Und die sortiert man dann nach der Reihenfolge,

02:16:06.860 --> 02:16:08.440
wie oft das immer vorkommt oder so ungefähr. Genau.

02:16:08.600 --> 02:16:10.580
Aber man muss halt auch wissen, wie oft das vorkommt, weil

02:16:10.580 --> 02:16:12.580
man halt bestimmte Geschichten

02:16:12.580 --> 02:16:13.280
nennt.

02:16:14.020 --> 02:16:16.160
Wir stehen am Anfang von der Liste, wie oft das vorkommt.

02:16:16.520 --> 02:16:18.480
Ja, man rechnet so TF-EDF-Scores

02:16:18.480 --> 02:16:20.040
aus und dafür braucht man halt die Termfrequenz.

02:16:20.040 --> 02:16:21.700
So bitte was? TF-EDS?

02:16:21.720 --> 02:16:24.080
Ja, Termfrequenz mal

02:16:24.080 --> 02:16:26.100
Inverse Document Frequency ist halt sozusagen

02:16:26.100 --> 02:16:27.660
ein wichtiger Wert dafür, wie

02:16:27.660 --> 02:16:29.380
wichtig jetzt

02:16:29.380 --> 02:16:32.280
ein Wort ist

02:16:32.280 --> 02:16:34.220
in der Webseite oder

02:16:34.220 --> 02:16:36.340
in einem Dokument. Und dafür muss man

02:16:36.340 --> 02:16:37.540
halt zählen, wie oft ein Wort vorkommt.

02:16:39.340 --> 02:16:40.420
Ja, aber man muss halt auch

02:16:40.420 --> 02:16:42.340
zählen, wie oft das Wort

02:16:42.340 --> 02:16:43.080
überhaupt vorkommt.

02:16:44.720 --> 02:16:46.320
Und dann generell das noch mit dem Kontext und der

02:16:46.320 --> 02:16:47.580
Wichtigkeit und so und zusammensetzen.

02:16:47.760 --> 02:16:49.860
Also in dieser Webphase imitiert man im Grunde nur,

02:16:50.000 --> 02:16:52.200
welche Webseite war das, wie oft ist das

02:16:52.200 --> 02:16:54.120
Wort da vorgekommen und dann werden diese Ströme

02:16:54.120 --> 02:16:56.100
dann zusammen reduced und dann

02:16:56.100 --> 02:16:57.140
sozusagen

02:16:57.140 --> 02:17:00.020
hat man halt irgendwie dann diesen Index, wo dann zu jedem

02:17:00.020 --> 02:17:02.260
Wort steht, auf welchen Webseiten es vorkam und

02:17:02.260 --> 02:17:06.140
ja, wie oft und wie oft

02:17:06.140 --> 02:17:07.940
es insgesamt vorkam und so und dann kann man

02:17:07.940 --> 02:17:09.760
irgendwie so Anfragen machen und das

02:17:09.760 --> 02:17:11.740
kann man halt komplett voneinander trennen, da halt

02:17:11.740 --> 02:17:12.460
bestimmte,

02:17:14.100 --> 02:17:15.840
da man, da sich diese Sachen

02:17:15.840 --> 02:17:17.760
komplett voneinander, du kannst halt

02:17:17.760 --> 02:17:18.580
nach Worten auftrennen.

02:17:20.020 --> 02:17:21.840
Also, du musst halt nur

02:17:21.840 --> 02:17:23.500
dafür sorgen, dass das gleiche Wort immer

02:17:23.500 --> 02:17:25.740
auf, dass alle Sachen, die zum gleichen

02:17:25.740 --> 02:17:27.440
Wort gehören, zusammengeführt werden.

02:17:27.840 --> 02:17:28.800
Aber du kannst halt

02:17:28.800 --> 02:17:32.100
ja, für unterschiedliche Worte unterschiedliche

02:17:32.100 --> 02:17:33.440
Maschinen benutzen.

02:17:33.820 --> 02:17:35.760
Das ist halt gar kein Problem. Und damit kannst du

02:17:35.760 --> 02:17:37.260
es quasi beliebig horizontal skalieren.

02:17:37.680 --> 02:17:39.220
Auch da wiederum ist es schwer zu erklären,

02:17:39.460 --> 02:17:40.620
man kann sich das einfach mal angucken.

02:17:40.800 --> 02:17:42.220
Dann bietet sich einfach so ein Rechenzentrum,

02:17:42.340 --> 02:17:44.400
da schaltet einfach noch eine Maschine ein, wenn du welche brauchst.

02:17:44.840 --> 02:17:46.420
Genau, kannst dann halt immer, einfach immer mehr

02:17:46.420 --> 02:17:48.460
Maschinen dazustellen. Und ja,

02:17:48.560 --> 02:17:50.340
viele Leute haben sich gedacht, oh, das war eine coole, coole

02:17:50.340 --> 02:17:51.740
Idee. Und dann

02:17:51.740 --> 02:17:54.160
ja, derjenige,

02:17:54.600 --> 02:17:56.560
einer von denen, der Namen

02:17:56.560 --> 02:17:58.200
man immer hört, irgendwie, Duck Cutting,

02:17:58.620 --> 02:18:00.420
der hat damals schon bei Excite irgendwie

02:18:00.420 --> 02:18:02.380
die Suchmaschine gebaut, hat dann später eine sehr

02:18:02.380 --> 02:18:04.500
populäre, oder immer noch die populärste

02:18:04.500 --> 02:18:06.280
Volltext-Suchmaschine, die es so gibt,

02:18:06.360 --> 02:18:08.020
Lucine, oder ist die Engine darunter,

02:18:08.820 --> 02:18:10.260
jedenfalls geschrieben, auch

02:18:10.260 --> 02:18:12.200
ein Buch darüber, das

02:18:12.200 --> 02:18:14.360
ja, und

02:18:14.360 --> 02:18:18.580
Irgendwann ist er eher in diesen Big-Data-Hadoop-Bereich gegangen.

02:18:18.780 --> 02:18:22.580
Der hat ursprünglich auch dieses Hadoop-Projekt losgetreten.

02:18:23.020 --> 02:18:27.300
Und dabei ging es halt darum, ein System wie das, was Google zum Bauen der NDCs verwendet hat,

02:18:28.280 --> 02:18:34.280
in Open Source nachzubauen unter diesem Apache-Projekt-Schirm.

02:18:35.620 --> 02:18:37.900
Und ja, das hat auch gut funktioniert.

02:18:38.920 --> 02:18:41.640
Alles ist ein Riesenprojekt geworden.

02:18:42.560 --> 02:18:44.060
Es ist auch für manche Sachen halt total super.

02:18:44.360 --> 02:18:46.320
ich würde jetzt nur sagen, also es wird heute viele

02:18:46.320 --> 02:18:48.360
Dinge verwendet, für die es vielleicht nicht so gut geeignet

02:18:48.360 --> 02:18:48.940
ist eigentlich.

02:18:50.160 --> 02:18:52.500
Zum Beispiel? Ja, also es ist

02:18:52.500 --> 02:18:54.620
glaube ich für viele Firmen heute so die generische

02:18:54.620 --> 02:18:56.320
Data Warehouse-Lösung

02:18:56.320 --> 02:18:58.280
geworden. Obwohl es

02:18:58.280 --> 02:18:59.900
dafür, weiß ich nicht.

02:19:00.440 --> 02:19:02.280
Also ich würde ja sagen, zum Beispiel viele Firmen haben

02:19:02.280 --> 02:19:03.260
eben keinen Big Data. Die haben

02:19:03.260 --> 02:19:06.220
keines dieser drei Big Data-Probleme,

02:19:06.300 --> 02:19:06.560
sondern

02:19:06.560 --> 02:19:09.480
Besser nicht, wie die es machen sollen.

02:19:10.120 --> 02:19:11.940
Ja, die haben einfach nur Daten und

02:19:11.940 --> 02:19:14.140
eigentlich passt das an den Hauptspeicher und die brauchen

02:19:14.140 --> 02:19:15.800
nichts davon. Das ist, die können einfach, die

02:19:15.800 --> 02:19:17.660
Einrichtung mit einem

02:19:17.660 --> 02:19:19.740
Postgres-Server. Ja, oder

02:19:19.740 --> 02:19:21.000
irgendwie nicht mal das.

02:19:22.740 --> 02:19:23.540
Sikulat Errori.

02:19:23.920 --> 02:19:25.360
Jaja, also da

02:19:25.360 --> 02:19:27.480
ein Freund von mir sagt dann immer so, oder

02:19:27.480 --> 02:19:30.020
ich weiß nicht mehr, das, ach, ich hab das

02:19:30.020 --> 02:19:32.120
und ich glaube, ich hab es auf Twitter gelesen, Unsinn.

02:19:32.960 --> 02:19:33.880
Man sollte irgendwie,

02:19:34.080 --> 02:19:35.980
ich weiß aber nicht mehr, wer es war, ich sollte

02:19:35.980 --> 02:19:37.460
eigentlich mal einen Consulting-Service gründen,

02:19:38.060 --> 02:19:39.180
der irgendwie,

02:19:39.860 --> 02:19:41.860
den man engagieren kann,

02:19:41.860 --> 02:19:43.460
wenn man vor der Frage steht, ob man sich jetzt

02:19:43.460 --> 02:19:45.380
ein Hadoop-Cluster irgendwie kaufen möchte

02:19:45.380 --> 02:19:47.100
oder nicht. Die Antwort ist immer nein.

02:19:47.560 --> 02:19:48.620
Gehe ich da hin und sage,

02:19:49.460 --> 02:19:50.100
lass mich überlegen,

02:19:50.520 --> 02:19:51.600
nein.

02:19:52.860 --> 02:19:53.620
Deine Daten

02:19:53.620 --> 02:19:54.360
finden in RAM.

02:19:55.960 --> 02:19:56.400
No.

02:19:57.700 --> 02:19:59.360
Und da einfach jedes Mal

02:19:59.360 --> 02:20:00.440
10.000 Dollar für verlangen.

02:20:01.140 --> 02:20:03.420
Das würde, hätte ich irgendwie

02:20:03.420 --> 02:20:05.560
ein nettes Einkommen durch und

02:20:05.560 --> 02:20:07.700
würde den Unternehmen ein Vielfaches davon sparen.

02:20:08.240 --> 02:20:09.420
Von dem, was sie dann ausgeben, wenn sie

02:20:09.420 --> 02:20:09.760
das nicht will.

02:20:11.760 --> 02:20:14.480
und da ist

02:20:14.480 --> 02:20:16.420
leider viel Wahres dran, also es gibt wenige, die das

02:20:16.420 --> 02:20:17.780
wirklich brauchen, viele

02:20:17.780 --> 02:20:20.360
schaffen es sich trotzdem an und haben dann ein

02:20:20.360 --> 02:20:21.880
kompliziertes, eine

02:20:21.880 --> 02:20:24.080
komplizierte Lösung für ein Problem, das sie nicht haben

02:20:24.080 --> 02:20:25.940
Ich meine, das ist natürlich für die Leute, die

02:20:25.940 --> 02:20:28.400
Geld verdienen. Genau, für das Problem, was sie haben, ist das

02:20:28.400 --> 02:20:30.600
einfach total kompliziert zu benutzen

02:20:30.600 --> 02:20:32.460
also Dinge wären viel einfacher, wenn sie

02:20:32.460 --> 02:20:34.380
das nicht machen würden, aber naja, so ist es halt

02:20:34.380 --> 02:20:34.660
nun mal

02:20:34.660 --> 02:20:38.500
und von diesem

02:20:38.500 --> 02:20:39.980
MapReduce-Ding ist auch

02:20:39.980 --> 02:20:42.060
diese ganze Hadoop-Welt auch schon so ein bisschen

02:20:42.060 --> 02:20:44.240
wieder weg. Auch Google macht nicht mehr wirklich

02:20:44.240 --> 02:20:48.160
MapReduce, also für manche Sachen machen sie möglicherweise

02:20:48.160 --> 02:20:50.000
noch MapReduce, aber es sind ja auch andere

02:20:50.000 --> 02:20:51.980
Systeme gegangen, Prägel,

02:20:52.180 --> 02:20:54.060
so ein Graph-Processing-Ding, was

02:20:54.060 --> 02:20:55.440
sie da machen, was halt relativ viel

02:20:55.440 --> 02:20:57.500
tut von dem, was früher MapReduce gemacht hat.

02:20:59.660 --> 02:21:00.060
Und

02:21:00.060 --> 02:21:01.940
auch bei Hadoop ist es halt so,

02:21:02.100 --> 02:21:03.920
dass das, was geblieben ist, ist

02:21:03.920 --> 02:21:05.900
irgendwie so ein verteilter Dateisystem-Layer,

02:21:05.900 --> 02:21:07.800
so auch Management von

02:21:07.800 --> 02:21:10.000
diesen Nodes

02:21:10.000 --> 02:21:11.680
irgendwie in diesem Cluster.

02:21:13.400 --> 02:21:13.840
Aber

02:21:13.840 --> 02:21:15.940
die Engines, die

02:21:15.940 --> 02:21:17.560
jetzt irgendwie Queries darauf prozessen,

02:21:17.800 --> 02:21:19.500
davon gibt es halt, das nennt sich Hive,

02:21:19.680 --> 02:21:22.060
da schreibt man Queries in so einem SQL-ähnlichen

02:21:22.060 --> 02:21:23.960
oder das ist schon SQL,

02:21:24.860 --> 02:21:25.760
man schreibt halt so SQL

02:21:25.760 --> 02:21:27.860
und das wird dann halt in MapReduce

02:21:27.860 --> 02:21:29.700
Jobs verwandelt und wird dann halt auf den

02:21:29.700 --> 02:21:31.940
ja, also im Grunde die Idee

02:21:31.940 --> 02:21:33.740
bei der ganzen Geschichte ist, dass man halt

02:21:33.740 --> 02:21:35.720
nicht mehr die Daten zu einer Stelle bringt,

02:21:35.720 --> 02:21:37.760
wo sie dann prozessed werden, sondern man bringt

02:21:37.760 --> 02:21:39.440
den Algorithmus zu den Daten.

02:21:40.080 --> 02:21:41.920
Man kann die Daten nicht mehr an einer Stelle zusammenführen,

02:21:41.960 --> 02:21:44.020
weil es sind einfach zu viele. Die liegen halt auf den lokalen

02:21:44.020 --> 02:21:46.020
Nodes und man trägt

02:21:46.020 --> 02:21:47.300
jetzt den Algorithmus zu diesen Daten

02:21:47.300 --> 02:21:49.820
und der läuft dann halt lokal auf den

02:21:49.820 --> 02:21:51.980
Cluster-Nodes darüber und dann am Schluss wird das

02:21:51.980 --> 02:21:54.020
alles wieder zusammengeführt, zusammenreduced

02:21:54.020 --> 02:21:55.700
und dann kriegt man halt das Ergebnis.

02:21:56.160 --> 02:21:57.840
Und für einen selber sieht das so aus, man schreibt halt ein

02:21:57.840 --> 02:21:59.800
SQL-Statement und kriegt halt ein Ergebnis

02:21:59.800 --> 02:22:01.980
und in Wirklichkeit hat man

02:22:01.980 --> 02:22:03.720
dann halt irgendwie einen Job gebaut, der dann halt

02:22:03.720 --> 02:22:06.260
100 Mapper, 100 Reducer

02:22:06.260 --> 02:22:08.620
angestoßen hat und das lief halt über 200 Maschinen

02:22:08.620 --> 02:22:08.940
und

02:22:08.940 --> 02:22:11.560
Wow, that's big.

02:22:13.140 --> 02:22:14.840
Hatte vielleicht das Problem nur Big Data

02:22:14.840 --> 02:22:15.740
dann, also Big,

02:22:16.200 --> 02:22:16.820
nicht Data.

02:22:18.700 --> 02:22:20.400
Aber es wäre

02:22:20.400 --> 02:22:22.080
und das hat dann vielleicht eine halbe Stunde gedauert

02:22:22.080 --> 02:22:24.580
aber es ist halt auch möglich, wenn man das anders gemacht hätte

02:22:24.580 --> 02:22:26.520
hätte diese ganze Geschichte

02:22:26.520 --> 02:22:27.600
auch in der Minute durchlaufen können.

02:22:29.140 --> 02:22:30.380
Ja, es gibt dann auch

02:22:30.380 --> 02:22:32.300
andere Geschichten, die jetzt auf solchen Clustern

02:22:32.300 --> 02:22:34.500
laufen, zum Beispiel rein in Memory-Geschichten

02:22:34.500 --> 02:22:35.660
so was wie Impala

02:22:35.660 --> 02:22:38.060
einer von

02:22:38.060 --> 02:22:40.260
den

02:22:40.260 --> 02:22:42.560
PhD-Studenten von Michael

02:22:42.560 --> 02:22:44.420
Stonebraker, die damals

02:22:44.420 --> 02:22:46.460
Postgres mitgeschrieben haben, ist da

02:22:46.460 --> 02:22:48.700
irgendwie CTO von der Firma, die da, ich habe jetzt aber auch wieder vergessen,

02:22:48.700 --> 02:22:49.760
welche das ist.

02:22:50.680 --> 02:22:52.560
Das macht das halt in Memory, das ist

02:22:52.560 --> 02:22:53.840
in C geschrieben, das ist alles schneller,

02:22:54.380 --> 02:22:56.540
das ist viel angenehmer, wenn man damit arbeitet,

02:22:56.660 --> 02:22:58.500
aber es ist auch so ein bisschen komisch und

02:22:58.500 --> 02:22:59.440
es ist halt auch nicht so richtig,

02:23:01.020 --> 02:23:02.220
es ist halt nur ein bisschen instabil.

02:23:04.380 --> 02:23:04.700
Ist

02:23:04.750 --> 02:23:06.750
gibt diverse

02:23:06.750 --> 02:23:08.750
andere Geschichten. Ach, das war noch ein eigenes

02:23:08.750 --> 02:23:10.390
Thema eigentlich. Spark, SpySpark.

02:23:13.170 --> 02:23:14.730
Was ganz interessant ist,

02:23:15.150 --> 02:23:16.490
ist, was man vielleicht

02:23:16.490 --> 02:23:18.610
lasst mich überlegen.

02:23:19.330 --> 02:23:20.690
Also was sehr interessant ist,

02:23:20.730 --> 02:23:22.470
ist, dass wir heute etwas

02:23:22.470 --> 02:23:22.870
sehen,

02:23:24.210 --> 02:23:26.590
was wir früher eigentlich auch schon

02:23:26.590 --> 02:23:28.390
gedacht hätten, dass wir das im relationalen Bereich bekommen,

02:23:28.530 --> 02:23:30.270
nämlich, oder MySQL hat damit mal angefangen,

02:23:30.650 --> 02:23:32.490
so, die hatten irgendwie

02:23:32.490 --> 02:23:34.350
so eines der coolen Features bei MySQL

02:23:34.350 --> 02:23:36.650
am Anfang war, dass die Storage-Engines

02:23:36.650 --> 02:23:38.410
pluggable waren. Das heißt, du konntest deine eigene

02:23:38.410 --> 02:23:40.310
Storage-Engine da reinbauen. Hat auch kaum

02:23:40.310 --> 02:23:42.150
einer gemacht. Es gab eigentlich nur zwei

02:23:42.150 --> 02:23:43.270
relevante. Was ist eine Storage-Engine?

02:23:43.670 --> 02:23:45.850
Wie die Daten tatsächlich auf der Platte liegen.

02:23:45.930 --> 02:23:46.650
Ah, okay. Letztlich.

02:23:47.710 --> 02:23:50.070
Und das ist halt, es gab MyISAM,

02:23:50.730 --> 02:23:52.250
es gab auch eine CSV-Engine für MySQL,

02:23:52.370 --> 02:23:53.450
da hast du einfach CSVs genommen.

02:23:54.110 --> 02:23:55.630
Aber MyISAM war so populär.

02:23:56.450 --> 02:23:58.150
MySQL hatte aber Probleme. Hatte das Problem,

02:23:58.230 --> 02:24:00.270
dass du, wenn du geschrieben hast, wurde mir die komplette Table

02:24:00.270 --> 02:24:02.010
gelockt. Das heißt, also da lieber nur lesen, nichts

02:24:02.010 --> 02:24:03.450
reinschreiben. So reinschreiben, eher doof.

02:24:04.350 --> 02:24:06.710
hat trotzdem irgendwie, haben das

02:24:06.710 --> 02:24:08.670
viel lange verwendet, Transaktionen und so, das geht alles nicht.

02:24:08.770 --> 02:24:10.750
Asset war nicht so richtig bei MySQL am Anfang und dann

02:24:10.750 --> 02:24:12.750
hatten sie eine Storage-Engine, die das dann aber schon konnte,

02:24:12.850 --> 02:24:14.550
die auch so wirklich Multiversion

02:24:14.550 --> 02:24:16.650
Concurrency-Kontrolle halt richtig konnte und das war

02:24:16.650 --> 02:24:18.410
InnoDB und

02:24:18.410 --> 02:24:20.630
ja, aber eigentlich

02:24:20.630 --> 02:24:22.630
so nachdem InnoDB sich durchgesetzt hatte

02:24:22.630 --> 02:24:24.350
oder irgendwie gut genug war,

02:24:24.850 --> 02:24:26.470
dann hat sich dieser

02:24:26.470 --> 02:24:28.730
Pluggable-Storage-Engine-Geschichte von

02:24:28.730 --> 02:24:30.970
MySQL hat sich dann auch wieder erledigt.

02:24:32.530 --> 02:24:34.350
Aber Postgres

02:24:34.350 --> 02:24:35.930
bekommt jetzt, glaube ich, mit der Version 12, also

02:24:35.930 --> 02:24:38.030
das ist noch nicht sicher, aber es sieht ein bisschen danach aus, als ob sie

02:24:38.030 --> 02:24:39.950
Plugable Storage Engines wieder zurückbekommen.

02:24:40.850 --> 02:24:41.370
Was interessant,

02:24:41.530 --> 02:24:43.430
da ist es dann zum ersten Mal, aber

02:24:43.430 --> 02:24:46.030
das Konzept nochmal irgendwie

02:24:46.030 --> 02:24:47.290
doch nochmal angefasst wird.

02:24:48.110 --> 02:24:49.510
Und interessant ist auch in diesem ganzen

02:24:49.510 --> 02:24:51.670
Analytics-Big-Data-Bereich,

02:24:52.110 --> 02:24:53.530
dass wir da auch sowas sehen. Wir sehen

02:24:53.530 --> 02:24:56.430
halt, es gibt nicht mehr so ein Datenbank-

02:24:56.430 --> 02:24:57.490
System, wo halt die

02:24:57.490 --> 02:25:00.190
wie die Daten gespeichert werden, tatsächlich

02:25:00.190 --> 02:25:02.130
an die anderen Teile,

02:25:02.130 --> 02:25:19.650
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.

02:25:21.790 --> 02:25:41.630
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.

02:25:43.750 --> 02:25:46.010
weil die Art von Curries, die man

02:25:46.010 --> 02:25:48.170
da macht, oft nur wenige Zeilen betreffen.

02:25:48.690 --> 02:25:49.990
Ein paar tausend oder so, aber es sind immer noch

02:25:49.990 --> 02:25:52.170
sehr wenige. Daher macht es Sinn,

02:25:52.650 --> 02:25:54.250
irgendwie zeilenweise zu arbeiten.

02:25:55.470 --> 02:25:55.910
Sozusagen.

02:25:57.110 --> 02:25:57.910
Aber für diese

02:25:57.910 --> 02:25:59.910
Analysegeschichten, dieses ganze Data Warehousing Zeugs,

02:26:00.110 --> 02:26:01.210
ist das überhaupt nicht sinnvoll.

02:26:01.430 --> 02:26:03.910
Dieses Muster, dass man halt

02:26:03.910 --> 02:26:06.070
eher Millionen

02:26:06.070 --> 02:26:07.870
von Zeilen anguckt, aber nur wenige Spalten,

02:26:08.010 --> 02:26:09.650
weil man sich nur für einen bestimmten Aspekt interessiert.

02:26:09.970 --> 02:26:11.950
Man interessiert sich oft eben nur für

02:26:11.950 --> 02:26:13.830
Umsatz oder Preis

02:26:13.830 --> 02:26:15.790
oder sowas. Aber man

02:26:15.790 --> 02:26:17.750
interessiert sich gar nicht für den Namen des Autors

02:26:17.750 --> 02:26:19.810
oder so. Daher möchte man eigentlich nicht

02:26:19.810 --> 02:26:21.790
irgendwie alle Zeilen

02:26:21.790 --> 02:26:23.610
immer komplett angucken, weil dann guckt man sich

02:26:23.610 --> 02:26:24.430
ganz viel Zeug an.

02:26:25.550 --> 02:26:27.170
Der Flaschenhals ist oft

02:26:27.170 --> 02:26:28.470
wie

02:26:28.470 --> 02:26:31.850
die Wandbreite

02:26:31.850 --> 02:26:33.810
zwischen Platte und Hauptspeicher.

02:26:34.010 --> 02:26:35.850
Man muss das halt dann irgendwie durch den Prozessor

02:26:35.850 --> 02:26:37.770
ziehen. Und je weniger Daten man dadurch

02:26:37.770 --> 02:26:39.690
ziehen muss, umso besser. Und bei

02:26:39.690 --> 02:26:41.670
einem zeilenorientierten Format muss ich,

02:26:41.770 --> 02:26:43.850
ich die Datei lese und die Datensätze

02:26:43.850 --> 02:26:45.630
halt zeilenweise drinstehen, muss ich halt da

02:26:45.630 --> 02:26:46.710
sequenziell durch die Zeilen durchgehen.

02:26:46.890 --> 02:26:48.870
Das geht nicht anders.

02:26:49.490 --> 02:26:51.530
Das ist halt total ineffizient, weil wenn ich halt nur

02:26:51.530 --> 02:26:53.510
einen kleinen Teil von diesen Zeilen, nämlich nur

02:26:53.510 --> 02:26:55.250
eine Spalte, irgendwie überhaupt lesen möchte, das heißt,

02:26:56.530 --> 02:26:57.430
wenn ich

02:26:57.430 --> 02:26:59.730
so Analyse-Querys

02:26:59.730 --> 02:27:01.430
auf Datenbanken mache,

02:27:01.610 --> 02:27:03.290
die zeilenbasiert ihre Daten speichern,

02:27:04.050 --> 02:27:05.610
dann ist das super ineffizient und ich habe halt

02:27:05.610 --> 02:27:07.510
so einen Verlust von circa, man sagt

02:27:07.510 --> 02:27:09.470
immer so einen Faktor 50 ungefähr,

02:27:09.930 --> 02:27:11.590
sind die halt einfach aufgrund

02:27:11.590 --> 02:27:13.690
dieser Architekturgeschichte langsamer

02:27:13.690 --> 02:27:15.870
und zwar unoptimierbar

02:27:15.870 --> 02:27:17.850
langsamer als sogenannte

02:27:17.850 --> 02:27:19.790
Column Stores, die halt Daten

02:27:19.790 --> 02:27:21.490
spaltenweise speichern.

02:27:22.650 --> 02:27:22.910
Und

02:27:22.910 --> 02:27:25.470
die ersten

02:27:25.470 --> 02:27:27.790
Dateisystemformate

02:27:27.790 --> 02:27:29.730
oder Formate, in denen die Daten zum Beispiel in Hadoop

02:27:29.730 --> 02:27:31.330
gespeichert wurden, Avro ist glaube ich

02:27:31.330 --> 02:27:32.470
das erste, ich weiß nicht genau,

02:27:33.550 --> 02:27:35.630
sind auch alle zeilenbasiert, weil das war halt so.

02:27:35.830 --> 02:27:37.570
Man hat halt irgendwie zeilenbasiert Sachen gespeichert,

02:27:38.150 --> 02:27:39.470
aber das ist halt eben total

02:27:39.470 --> 02:27:41.450
ineffizient, wenn man halt nur

02:27:41.450 --> 02:27:43.570
bestimmte Spalten von Datensätzen haben

02:27:43.570 --> 02:27:45.470
möchte und dann gibt es halt neuere File-Formate

02:27:45.470 --> 02:27:46.470
wie zum Beispiel, oder

02:27:46.470 --> 02:27:48.110
Serialisierungsformate,

02:27:48.950 --> 02:27:51.310
Parquet-Dateien zum Beispiel,

02:27:51.510 --> 02:27:53.310
das ist halt das, was heute eigentlich immer so verwendet wird,

02:27:53.730 --> 02:27:54.490
das ist halt dann

02:27:54.490 --> 02:27:55.990
spaltenbasiert

02:27:55.990 --> 02:27:59.630
und dann liest man eben nur die Dateien

02:27:59.630 --> 02:28:00.910
oder die Spalten,

02:28:01.530 --> 02:28:03.550
es ist halt in einer Datei nur eine Spalte

02:28:03.550 --> 02:28:05.410
sozusagen, man liest halt nur die Dateien,

02:28:05.450 --> 02:28:05.970
die man halt braucht

02:28:05.970 --> 02:28:09.690
und das ist komprimierbar,

02:28:09.930 --> 02:28:11.910
Es ist chunkbar, sodass ich es auf mehrere Rechner verteilen

02:28:11.910 --> 02:28:13.690
kann und so und hat halt all diese hübschen

02:28:13.690 --> 02:28:14.350
Eigenschaften.

02:28:16.930 --> 02:28:17.330
Und

02:28:17.330 --> 02:28:19.590
ich habe jetzt diese Paket-Files, aber

02:28:19.590 --> 02:28:21.490
das Format der Daten

02:28:21.490 --> 02:28:23.670
auf der Platte, das Serialisierungsformat, ist nicht mehr

02:28:23.670 --> 02:28:24.890
gebunden an die Datenbank, sondern

02:28:24.890 --> 02:28:27.730
als Layer darüber, mit dem ich jetzt

02:28:27.730 --> 02:28:29.450
Abfragen mache, habe ich jetzt sowas wie Hive,

02:28:29.670 --> 02:28:31.370
das macht dann MapReduce-Jobs draus irgendwie.

02:28:33.090 --> 02:28:33.610
Ich habe

02:28:33.610 --> 02:28:35.290
aber auch sowas wie Impala, ich habe

02:28:35.290 --> 02:28:36.970
vielleicht andere Geschichten, ich habe Spark.

02:28:37.910 --> 02:28:39.510
Spark hast du eben noch vergessen, übrigens.

02:28:39.810 --> 02:28:41.370
Ja, Spark, genau, gut, Spark

02:28:41.370 --> 02:28:43.290
hat auch irgendwie, ist was mit anderen

02:28:43.290 --> 02:28:44.190
gestartet, die

02:28:44.190 --> 02:28:47.430
hat auch

02:28:47.430 --> 02:28:49.070
ein eigenes DataFrame-Format, was

02:28:49.070 --> 02:28:51.250
jetzt nicht Parquet war, aber

02:28:51.250 --> 02:28:53.210
also worauf es hinausläuft, ist

02:28:53.210 --> 02:28:55.130
im Grunde, dass ich jetzt

02:28:55.130 --> 02:28:56.990
so ein Format habe wie Parquet,

02:28:57.930 --> 02:28:59.350
in dem die Daten auf der

02:28:59.350 --> 02:29:01.230
Platte liegen und jetzt

02:29:01.230 --> 02:29:03.110
habe ich halt unterschiedliche Engines, die

02:29:03.110 --> 02:29:05.070
jetzt irgendwie, mit denen ich jetzt Queries verarbeite,

02:29:05.150 --> 02:29:07.210
drauf. Ja, also quasi eine

02:29:07.210 --> 02:29:07.910
Trennung zwischen

02:29:07.910 --> 02:29:10.490
dem System, das jetzt meine

02:29:10.490 --> 02:29:12.250
Queries irgendwie beantwortet und dem

02:29:12.250 --> 02:29:14.310
Speicherformat, also quasi sowas ähnliches wie

02:29:14.310 --> 02:29:16.410
ein Plugable Storage Engine, so nur, dass

02:29:16.410 --> 02:29:18.550
halt der Storage-Format ist halt für alle unterschiedlichen

02:29:18.550 --> 02:29:19.890
Engines irgendwie gleich, nämlich Paket,

02:29:20.610 --> 02:29:22.150
aber das, was halt die Dinge

02:29:22.150 --> 02:29:23.490
darauf machen, ist halt unterschiedlich.

02:29:24.330 --> 02:29:26.350
Das ist eine ganz interessante Entwicklung, finde ich. Also das

02:29:26.350 --> 02:29:27.790
ist halt, das ist schon faszinierend

02:29:27.790 --> 02:29:28.790
und

02:29:28.790 --> 02:29:32.210
ja,

02:29:32.710 --> 02:29:33.350
die

02:29:33.350 --> 02:29:36.390
ja, Column Stores

02:29:36.390 --> 02:29:38.370
sind halt sozusagen, das sind für so Data-Warehousing

02:29:38.370 --> 02:29:39.510
eigentlich das Coole. Es gibt

02:29:39.510 --> 02:29:41.030
C-Store,

02:29:42.010 --> 02:29:43.690
Paper ist halt auch eine

02:29:43.690 --> 02:29:46.190
Firma entstanden, Vertica, glaube ich.

02:29:47.490 --> 02:29:48.270
Die machen halt,

02:29:48.350 --> 02:29:50.370
wenn man irgendwie ein großes Data-Warehouse haben möchte,

02:29:50.510 --> 02:29:52.150
dann ist es wahrscheinlich irgendwie so das Beste, wenn man irgendwie

02:29:52.150 --> 02:29:53.870
zu so einer Firma geht und das macht.

02:29:54.170 --> 02:29:56.270
Keine Ahnung. Oder gibt es auch wahrscheinlich

02:29:56.270 --> 02:29:58.010
auch noch andere, die sowas ähnliches machen.

02:29:58.170 --> 02:30:00.170
Aber was halt nicht gut wäre, ist halt, wenn man

02:30:00.170 --> 02:30:02.390
mit so einem Problem zu Oracle

02:30:02.390 --> 02:30:03.610
geht. Weil Oracle ist halt nicht

02:30:03.610 --> 02:30:06.190
Column-Oriented, sondern die sind halt

02:30:06.190 --> 02:30:08.010
zeilenbasiert, egal was sie dazu sagen. Sie versuchen das

02:30:08.010 --> 02:30:09.830
in ihrem Marketing immer zu verschleiern, aber es ist halt

02:30:09.830 --> 02:30:12.150
genau wie MSSQL zwar war

02:30:12.150 --> 02:30:14.430
und die ganzen klassischen relationalen

02:30:14.430 --> 02:30:16.230
Datenbanken, die sind alle zeilenbasiert und da

02:30:16.230 --> 02:30:18.090
gibt es auch nichts, was man tun könnte.

02:30:19.050 --> 02:30:20.290
Ja, es sei denn, man tauscht

02:30:20.290 --> 02:30:21.150
die Storage-Engine aus.

02:30:22.030 --> 02:30:23.850
Bei Postgres wird das nochmal interessant.

02:30:24.550 --> 02:30:26.230
So Postgres, da hat man das Problem halt,

02:30:26.250 --> 02:30:27.870
wenn man ein Data Warehouse auf Postgres aufbaut,

02:30:27.970 --> 02:30:30.250
dann ist man immer dann an die Zeilenweise

02:30:30.250 --> 02:30:32.150
Verarbeitung

02:30:32.150 --> 02:30:33.750
gebunden, kann halt auch nichts machen.

02:30:34.910 --> 02:30:37.370
Wenn man das demnächst dann mit Parquet machen könnte, dann...

02:30:37.370 --> 02:30:39.130
Ja, wenn man irgendwie Parquet und Postgres

02:30:39.130 --> 02:30:40.730
irgendwie verheiraten könnte, das wäre natürlich schon

02:30:40.730 --> 02:30:41.710
ziemlich cool dann irgendwie.

02:30:43.150 --> 02:30:43.370
Ja,

02:30:43.870 --> 02:30:46.910
genau. Und das sind halt so die

02:30:46.910 --> 02:30:48.930
ja,

02:30:49.030 --> 02:30:50.330
das sind halt so diese Geschichten beim

02:30:50.330 --> 02:30:52.070
Data Warehousing.

02:30:52.750 --> 02:30:55.070
Genauso Hadoop, man nennt das auch so, nicht Data Warehouse,

02:30:55.170 --> 02:30:56.670
sondern weil man auch alles mögliche andere drin speichern kann.

02:30:56.750 --> 02:30:58.810
Data Lake, weiß ich gar nicht, ob man da so ins Detail gehen muss,

02:30:58.850 --> 02:31:00.770
aber man hat auch noch Bilder und sonst wie andere

02:31:00.770 --> 02:31:02.830
man kann halt alle möglichen Arten von unterschiedlichen

02:31:02.830 --> 02:31:04.970
Ein Datensee, wie bei der FNES, ganz, ganz tief.

02:31:05.210 --> 02:31:06.290
Ja, das kann auch so ein bisschen umkippen,

02:31:06.630 --> 02:31:07.830
wenn man das dann, Data Swamp.

02:31:10.530 --> 02:31:10.890
Ja,

02:31:11.250 --> 02:31:12.830
und

02:31:12.830 --> 02:31:15.130
ja,

02:31:15.370 --> 02:31:16.910
also, ich bin

02:31:16.910 --> 02:31:18.510
nicht, ehrlich gesagt, nicht so ein Riesenfan von

02:31:18.510 --> 02:31:20.530
Hadoop, muss ich sagen. So, aber

02:31:20.530 --> 02:31:22.870
auch, ich hab da

02:31:22.870 --> 02:31:24.970
auch schon ein bisschen so schmerzhafte

02:31:24.970 --> 02:31:26.750
Erfahrungen mit gemacht.

02:31:28.170 --> 02:31:28.930
Weil so Daten

02:31:28.930 --> 02:31:31.110
rein und raus kriegen, ist irgendwann so ein bisschen hässlich

02:31:31.110 --> 02:31:32.750
und das ist auch immer noch alles

02:31:32.750 --> 02:31:34.690
nicht so weit, also bei so klassischen Datenbanken

02:31:34.690 --> 02:31:36.670
ist halt, da merkt man, also wenn man Postgres-Rat

02:31:36.670 --> 02:31:38.490
verwendet zum Beispiel, merkt man halt so, da ist halt schon

02:31:38.490 --> 02:31:39.390
Jahrzehnte

02:31:39.390 --> 02:31:42.490
Erfahrung drin

02:31:42.490 --> 02:31:44.490
und viele der Use-Cases, die man so hat,

02:31:44.650 --> 02:31:46.710
also wenn man da auf blöde

02:31:46.710 --> 02:31:48.290
Probleme stößt, dann ist man wahrscheinlich selber schuld.

02:31:48.490 --> 02:31:50.430
Also das ist halt

02:31:50.430 --> 02:31:52.710
sehr selten, würde ich jetzt mal so

02:31:52.710 --> 02:31:54.810
90 Prozent der

02:31:54.810 --> 02:31:55.810
Probleme sitzen vor der Tastatur.

02:31:55.830 --> 02:31:58.470
Dass man auf etwas stößt und man hat wirklich ein Problem mit der Datenbank,

02:31:58.550 --> 02:32:00.670
sondern man hat ein Problem mit, man hat die Dokumentation

02:32:00.670 --> 02:32:02.530
nicht genau genug gelesen oder man weiß

02:32:02.530 --> 02:32:04.290
man hat irgendwie ein Verständnisproblem oder so

02:32:04.290 --> 02:32:06.310
und das sind ja alles Sachen, die sich leicht fixen lassen.

02:32:07.470 --> 02:32:08.450
Also es wäre halt

02:32:08.450 --> 02:32:12.410
wenn man tatsächlich ein Problem mit der Datenbank

02:32:12.410 --> 02:32:14.290
hat, wäre es natürlich schlecht,

02:32:14.370 --> 02:32:16.430
weil da kann man nichts machen, außer Datenbank wechseln

02:32:16.430 --> 02:32:17.130
oder irgendwie

02:32:17.130 --> 02:32:20.370
selber neu schreiben oder sowas, nicht gut wäre.

02:32:20.930 --> 02:32:21.090
Und

02:32:21.090 --> 02:32:24.150
bei Hadoop habe ich so das Gefühl,

02:32:24.930 --> 02:32:26.330
es kann natürlich auch was sein, dass ich einfach zu blöd

02:32:26.330 --> 02:32:28.070
war, es nicht zu bedienen, aber ich habe so das Gefühl,

02:32:28.690 --> 02:32:30.210
viele Dinge, die man da macht, sind nicht dadurch

02:32:30.210 --> 02:32:32.290
begrenzt, dass man irgendwie nicht genug weiß oder nicht genug

02:32:32.290 --> 02:32:34.750
nicht richtig verwendet, so das falsch rum hält

02:32:34.750 --> 02:32:36.070
irgendwie, sondern

02:32:36.070 --> 02:32:38.710
bestimmte Sachen gehen einfach noch nicht

02:32:38.710 --> 02:32:40.790
oder gehen nicht richtig. Man hat Use Cases

02:32:40.790 --> 02:32:42.290
und dann stellt man so fest, so ja,

02:32:43.010 --> 02:32:44.890
hat niemand drüber nachgedacht, ist nicht so richtig

02:32:44.890 --> 02:32:46.710
abgebildet, blöd.

02:32:47.290 --> 02:32:47.410
Und

02:32:47.410 --> 02:32:50.650
das wird wahrscheinlich alles irgendwie viel besser, aber momentan

02:32:50.650 --> 02:32:52.610
ist es noch nicht so, ist noch ein bisschen

02:32:52.610 --> 02:32:54.450
scharf, fühlt sich alles ein wenig scharfkantig an.

02:32:54.870 --> 02:32:56.470
Man kann sich überall schneiden und wehtun und aua.

02:32:56.650 --> 02:32:58.950
Ja, und außerdem, dass es halt alles auf dieser Java-Geschichte

02:32:58.950 --> 02:33:00.810
aufsetzt, ist auch sowas, muss ich auch sagen.

02:33:01.030 --> 02:33:02.710
Ah, jetzt sind wir wieder bei dem

02:33:02.710 --> 02:33:04.410
Ding, was wir eigentlich als Running-Gag nehmen wollten, da haben wir es doch

02:33:04.410 --> 02:33:06.530
dazu verlassen. Ja, Java, Java, mal wieder.

02:33:06.850 --> 02:33:07.990
Das ist...

02:33:07.990 --> 02:33:10.150
Nach zweieinhalb Stunden sind wir doch wieder drauf gekommen, ja.

02:33:10.350 --> 02:33:12.570
Ja, aber da ist dann

02:33:12.570 --> 02:33:14.310
möglicherweise der Ausweg, irgendwie sowas wie PySpark

02:33:14.310 --> 02:33:16.470
zu verwenden. Spark, auch nochmal, eigentlich müssen wir

02:33:16.470 --> 02:33:17.590
dann mal ein eigenes Thema zu machen,

02:33:18.290 --> 02:33:20.530
aber sehr schön, das Ding ist so, dass man halt

02:33:20.530 --> 02:33:21.230
quasi

02:33:21.230 --> 02:33:24.730
Sachen automatisch verteilen kann,

02:33:25.050 --> 02:33:26.370
man hat sie lokal, man kann

02:33:26.370 --> 02:33:28.590
damit anfangen, dass man es auf einer Maschine hat und dann

02:33:28.590 --> 02:33:30.470
führt man Sachen auf einen Cluster

02:33:30.470 --> 02:33:32.490
aus und das ist wirklich mehr oder weniger

02:33:32.490 --> 02:33:33.050
seamless.

02:33:35.390 --> 02:33:36.010
Das Einzige,

02:33:37.630 --> 02:33:38.690
man hat sogar einen vollständigen

02:33:38.690 --> 02:33:40.450
Python-Interpreter, das ist irgendwie nicht so

02:33:40.450 --> 02:33:42.490
eine verkrüppelte Version. Man kann halt tatsächlich

02:33:42.490 --> 02:33:44.410
irgendwie Sighten-Sachen

02:33:44.410 --> 02:33:46.270
damit machen. Das heißt, man kriegt Sachen auch wirklich, wirklich

02:33:46.270 --> 02:33:46.630
schnell.

02:33:49.210 --> 02:33:50.550
Im Gegensatz zu

02:33:50.550 --> 02:33:52.330
Java. Java geht vielleicht auch, ich weiß es nicht genau,

02:33:52.410 --> 02:33:54.410
aber ich glaube, es ist ziemlich schwer, Sachen wirklich

02:33:54.410 --> 02:33:56.090
optimiert hinzukriegen.

02:33:56.450 --> 02:33:58.370
Während in Python ist es halt relativ

02:33:58.370 --> 02:34:00.310
leicht, irgendwie mit

02:34:00.310 --> 02:34:02.090
Seiten halt ein Dialekt von Python

02:34:02.090 --> 02:34:03.990
zuschreiben, wo man dann Typ-Annotationen dazu schreibt,

02:34:05.230 --> 02:34:06.150
wo die dann halt zu C

02:34:06.150 --> 02:34:07.950
kompiliert werden, dann wird das als C-Modul, dann wird es wieder

02:34:07.950 --> 02:34:10.210
reimportiert und das kann man halt auch

02:34:10.210 --> 02:34:12.270
auf den Cluster irgendwie ausrollen

02:34:12.270 --> 02:34:13.510
irgendwie über PySpark

02:34:13.510 --> 02:34:16.090
und dass man jetzt irgendwie C-Code irgendwie

02:34:16.090 --> 02:34:18.170
in Java reinbastelt und das

02:34:18.170 --> 02:34:20.110
dann halt über Hadoop, über die MapReduce-Service verteilt,

02:34:20.170 --> 02:34:22.170
weiß ich nicht. Kann auch sein, dass das geht, keine Ahnung, aber das

02:34:22.170 --> 02:34:23.070
klingt irgendwie nicht so leicht.

02:34:24.670 --> 02:34:25.690
Ja, wie auch immer. Also

02:34:25.690 --> 02:34:28.190
Spark ist auf jeden Fall auch noch eine super

02:34:28.190 --> 02:34:30.070
interessante Geschichte, vor allen Dingen, wenn es jetzt darum geht,

02:34:30.310 --> 02:34:31.990
Wenn man jetzt sowas hat wie so ein Data Lake und so,

02:34:32.090 --> 02:34:33.090
wie kommen da die Informationen rein?

02:34:33.770 --> 02:34:38.050
Man möchte eigentlich nicht da so ETL-Jobs machen.

02:34:38.150 --> 02:34:39.050
Das funktioniert alles nicht mehr.

02:34:39.130 --> 02:34:41.190
Man möchte ja auch Echtzeit-Dashboards haben irgendwie.

02:34:43.710 --> 02:34:48.830
Und dann wechselt man halt irgendwann auf so eine Streaming-Architektur,

02:34:48.830 --> 02:34:50.570
wo halt Dinge auf der Webseite,

02:34:51.150 --> 02:34:52.550
also auch gerade wenn man jetzt sowas hat wie,

02:34:53.470 --> 02:34:55.930
also auch Amazon wird, selbst wenn man die Bestellungen nimmt oder so,

02:34:55.970 --> 02:34:56.910
das ist alles noch nicht Big Data,

02:34:57.450 --> 02:34:59.890
aber wenn jetzt zum Beispiel Amazon, und das tun sie bestimmt,

02:35:00.310 --> 02:35:01.830
irgendwie jeden Klick den User

02:35:01.830 --> 02:35:03.430
macht auf der Webseite, auch

02:35:03.430 --> 02:35:05.390
irgendwo eine

02:35:05.390 --> 02:35:06.650
Fakten-Tabelle

02:35:06.650 --> 02:35:09.230
in ihr Data Warehouse, Data Lake

02:35:09.230 --> 02:35:10.750
Ding reinspeichern möchte,

02:35:11.030 --> 02:35:13.810
dann wird das big.

02:35:14.150 --> 02:35:15.630
Weil das ist halt schon viel.

02:35:15.830 --> 02:35:17.670
Dann ist so ein Verhältnis von Bestellungen zu

02:35:17.670 --> 02:35:19.670
Leute machen irgendwie Web-Requests oder klicken

02:35:19.670 --> 02:35:20.990
auf der Seite rum, ist halt wahrscheinlich nochmal so

02:35:20.990 --> 02:35:22.950
ein Faktor 100 oder mehr.

02:35:24.030 --> 02:35:24.210
Und

02:35:24.210 --> 02:35:27.570
dann wird es tatsächlich sehr, sehr groß.

02:35:27.570 --> 02:35:29.370
Und man möchte das aber trotzdem

02:35:29.370 --> 02:35:31.250
alles in Echtzeit haben. Das heißt,

02:35:31.350 --> 02:35:32.650
man macht es nicht so, dass man

02:35:32.650 --> 02:35:34.310
diese Geschichten wieder in die

02:35:34.310 --> 02:35:37.370
OTP-Datenbank reinschreibt

02:35:37.370 --> 02:35:39.290
und dann extrahiert und batchmäßig

02:35:39.290 --> 02:35:41.130
jeden Tag ein Analyse-System

02:35:41.130 --> 02:35:43.290
schreibt, sondern dann generiert

02:35:43.290 --> 02:35:44.650
man halt so Events,

02:35:46.090 --> 02:35:47.270
die dann halt über irgendeinen

02:35:47.270 --> 02:35:48.730
Streaming

02:35:48.730 --> 02:35:50.590
Zeugs halt

02:35:50.590 --> 02:35:53.430
Service laufen,

02:35:53.990 --> 02:35:54.850
der das dann halt

02:35:54.850 --> 02:35:56.730
an unterschiedliche Consumer

02:35:56.730 --> 02:35:58.530
irgendwie ausliefert. Und das sind meistens

02:35:58.530 --> 02:36:00.490
Kafka, AWS hat noch eine eigene

02:36:00.490 --> 02:36:02.710
Lösung, normalerweise auch wieder den Namen vergessen.

02:36:03.830 --> 02:36:04.710
Meinst du aber nicht die Lambda-Service?

02:36:05.130 --> 02:36:06.630
Nee, nee, das ist was anderes.

02:36:06.930 --> 02:36:08.530
Nee, das ist eine eigene, ja.

02:36:08.870 --> 02:36:10.350
Aber, sagen wir mal, Kafka als Beispiel

02:36:10.350 --> 02:36:12.530
ist auch ein Apache-Projekt, das das halt

02:36:12.530 --> 02:36:14.490
sehr schön macht. Und dann serialisiert man

02:36:14.490 --> 02:36:16.350
halt irgendwie die Daten, die man im Event hat,

02:36:16.350 --> 02:36:18.410
also irgendwie als Protokoll-Buffers

02:36:18.410 --> 02:36:18.950
oder sowas.

02:36:20.310 --> 02:36:22.250
Und dann gehen die Dinger halt

02:36:22.250 --> 02:36:24.210
auch da wiederum Serialisierungsformate

02:36:24.210 --> 02:36:26.070
sehr, also es gibt halt sehr unterschiedliche

02:36:26.070 --> 02:36:28.130
Protokoll-Buffers und super, wenn man Daten übertragen möchte

02:36:28.130 --> 02:36:30.050
oder auch dieses Rift von Facebook

02:36:30.050 --> 02:36:32.070
super scheiße, wenn man

02:36:32.070 --> 02:36:33.970
das halt auf die Platte schreibt. Also es wäre halt

02:36:33.970 --> 02:36:36.010
dann auch wieder zeilenbasiert, kann man hinterher nicht mehr gut analysieren.

02:36:36.190 --> 02:36:37.690
Also man kann halt nicht einfach

02:36:37.690 --> 02:36:39.950
irgendwie die Events, die man generiert

02:36:39.950 --> 02:36:41.590
als Protokoll-Buffers irgendwie

02:36:41.590 --> 02:36:44.030
in Kafka kippen und dann

02:36:44.030 --> 02:36:45.770
das irgendwo auf eine Platte schreiben lassen.

02:36:46.690 --> 02:36:47.710
Das reicht halt nicht,

02:36:47.970 --> 02:36:49.890
sondern man muss es halt dann doch auch irgendwie

02:36:49.890 --> 02:36:51.730
wieder irgendwie so Zwischendinge

02:36:51.730 --> 02:36:53.770
kippen, aber man kann halt auch, man kann halt

02:36:53.770 --> 02:36:55.890
etwas haben, was halt teilweise aus

02:36:55.890 --> 02:36:57.690
diesen Parquet-Files liest.

02:36:58.130 --> 02:37:04.210
Und dann halt die aktuellsten Daten liest es halt aus einem Log der Protokoll-Buffer-Events.

02:37:04.850 --> 02:37:08.270
Das muss ja dann vielleicht nur für die letzte halbe Stunde sein oder so, kommt halt mal drauf an.

02:37:09.690 --> 02:37:11.850
Ja, und dann kann man halt tatsächlich Echtzeit-Daten sehen.

02:37:12.130 --> 02:37:17.490
Dann könnte man halt ein Dashboard machen, wo man halt in Echtzeit sieht, wie sich die Zugriffsmuster ändern,

02:37:17.590 --> 02:37:20.910
wenn man jetzt zum Beispiel für einen bestimmten Teil der User irgendwie die Webseite ändert oder so.

02:37:21.730 --> 02:37:22.670
Und das ist natürlich schon sehr nett.

02:37:22.670 --> 02:37:27.230
Und wenn man halt irgendwie Preise erhöht, dann sieht man halt in Echtzeit, wie die Conversion runtergeht.

02:37:28.130 --> 02:37:32.090
Ah, der Preis war gut.

02:37:32.330 --> 02:37:33.210
Und dann kann man halt so als

02:37:33.210 --> 02:37:36.170
Manager vor diesem Dashboard sitzen

02:37:36.170 --> 02:37:36.950
und den Knöpfen drehen.

02:37:38.170 --> 02:37:39.250
Die Firma vor die Wand fahren.

02:37:39.910 --> 02:37:41.950
Und dann irgendwie Profit

02:37:41.950 --> 02:37:42.510
maximieren.

02:37:44.570 --> 02:37:46.170
Das ist schon

02:37:46.170 --> 02:37:47.590
sehr nett. Ist aber auch halt sehr aufwendig.

02:37:48.530 --> 02:37:49.890
Das macht alles

02:37:49.890 --> 02:37:51.030
nochmal viel komplizierter.

02:37:53.550 --> 02:37:53.990
Ja, und

02:37:53.990 --> 02:37:56.010
diese Serialisierungsformat-Geschichte

02:37:56.010 --> 02:37:56.630
ist halt sehr wichtig.

02:37:57.730 --> 02:37:59.030
etwas, was mir bei dem

02:37:59.030 --> 02:38:01.650
Hadoop-Erfahrung

02:38:01.650 --> 02:38:03.770
dann geholfen hat, war

02:38:03.770 --> 02:38:05.770
ein Projekt

02:38:05.770 --> 02:38:06.650
namens Apache Arrow,

02:38:08.570 --> 02:38:09.710
wo es

02:38:09.710 --> 02:38:11.810
darum geht, das ist von dem

02:38:11.810 --> 02:38:13.830
ursprünglichen Autor

02:38:13.830 --> 02:38:15.450
von Pandas, also dieser

02:38:15.450 --> 02:38:17.330
DataFrame-Library

02:38:17.330 --> 02:38:18.210
für Python,

02:38:20.250 --> 02:38:21.650
der hat das gestartet,

02:38:22.110 --> 02:38:23.290
weil der da halt ein,

02:38:23.290 --> 02:38:24.850
und das ist auch tatsächlich,

02:38:25.450 --> 02:38:27.150
also ich, während ich mich halt mit

02:38:27.150 --> 02:38:29.150
Hadoop-Geschäfte, aber mich hat es an den

02:38:29.150 --> 02:38:30.630
gleichen Stellen gejuckt sozusagen, also ich

02:38:30.630 --> 02:38:33.190
das war so zuerst gemacht, also ihn hat es wohl

02:38:33.190 --> 02:38:34.810
auch irgendwie genervt, der hat bei

02:38:34.810 --> 02:38:37.350
Cloudera gearbeitet irgendwie, das ist halt auch so eine von diesen

02:38:37.350 --> 02:38:39.490
Firmen,

02:38:39.590 --> 02:38:41.330
die halt so in diesem Big Data, Hadoop-Bereich

02:38:41.330 --> 02:38:43.290
viel unterwegs sind, auch da irgendwie glaube ich

02:38:43.290 --> 02:38:45.190
einer von den Chefs oder Gründern ist halt

02:38:45.190 --> 02:38:47.230
einer von den, ist auch ein PhD-Student

02:38:47.230 --> 02:38:49.250
von Michael Stonebaker, so sind

02:38:49.250 --> 02:38:51.470
alles irgendwie immer die gleichen Leute und

02:38:51.470 --> 02:38:55.070
der, genau,

02:38:55.270 --> 02:38:56.590
da geht es darum, ging es darum,

02:38:57.150 --> 02:38:58.910
sozusagen ein Interface zu haben,

02:38:59.030 --> 02:39:00.430
das genauso ist wie

02:39:00.430 --> 02:39:02.370
Pandas, also Dataframe

02:39:02.370 --> 02:39:04.290
API quasi zu haben, sodass man halt

02:39:04.290 --> 02:39:06.750
Dinge, man hat so das Gefühl, man hat ein

02:39:06.750 --> 02:39:08.650
Dataframe-Objekt, macht da irgendwelche Sachen drauf,

02:39:09.030 --> 02:39:10.490
so als wäre es ein Pandas-Dataframe,

02:39:10.990 --> 02:39:12.810
aber in Wirklichkeit passieren im Hintergrund

02:39:12.810 --> 02:39:14.650
Sachen auf deinem Cluster.

02:39:15.230 --> 02:39:16.550
Das war in der Bibliothek, nannte sich Ibis,

02:39:16.910 --> 02:39:18.990
und das ist halt genauso auch mein Problem damit,

02:39:19.170 --> 02:39:20.870
dass halt, ich mache ja eigentlich eher

02:39:20.870 --> 02:39:22.810
so Machine-Learning-Dinge

02:39:22.810 --> 02:39:24.690
und benutze

02:39:24.690 --> 02:39:26.870
Pandas eigentlich so zum

02:39:26.870 --> 02:39:28.830
Daten aufräumen, Daten transformieren,

02:39:29.470 --> 02:39:30.910
bevor ich das dann halt in irgendwie

02:39:30.910 --> 02:39:32.750
Machine Learning-Aggregate und so

02:39:32.750 --> 02:39:33.790
und Modelle reinfüttere,

02:39:34.610 --> 02:39:36.690
die dann aber, die dann selber wieder nur Arrays,

02:39:36.910 --> 02:39:38.230
NumPy-Arrays normalerweise nehmen

02:39:38.230 --> 02:39:40.890
und keine DataFrames, aber DataFrames

02:39:40.890 --> 02:39:42.710
ist halt so ein Zwischenschritt und man kann halt sehr leicht

02:39:42.710 --> 02:39:44.730
aus einem DataFrame irgendwie ein Array

02:39:44.730 --> 02:39:46.650
machen, indem man einfach sagt, DataFrame.Values,

02:39:46.710 --> 02:39:48.450
dann hat man das Array

02:39:48.450 --> 02:39:50.830
und ich

02:39:50.830 --> 02:39:52.330
hatte halt immer das Problem, wenn ich jetzt

02:39:52.330 --> 02:39:54.770
damit so Systemen wie Hive oder Impala draufgegangen

02:39:54.770 --> 02:39:56.410
bin, dann kriege ich halt irgendwie so

02:39:56.410 --> 02:39:57.650
eher so ein CSV oder

02:39:57.650 --> 02:40:00.470
so ein Result-Set und dann kriege ich das nicht schnell da raus.

02:40:00.650 --> 02:40:02.170
Das ist halt alles

02:40:02.170 --> 02:40:03.330
ultra langsam und

02:40:03.330 --> 02:40:06.550
ich brauche aber für meine Modelle doch durchaus große Daten

02:40:06.550 --> 02:40:08.470
oft. Das geht alles nicht

02:40:08.470 --> 02:40:10.470
und dann

02:40:10.470 --> 02:40:12.170
wäre es natürlich viel besser gewesen, wenn ich

02:40:12.170 --> 02:40:14.490
einfach nur, wenn jetzt, also

02:40:14.490 --> 02:40:16.790
das, was diese Systeme machen, ist, man schreibt SQL-Statements

02:40:16.790 --> 02:40:18.790
und die machen dann halt irgendwie automatisch

02:40:18.790 --> 02:40:20.610
machen die halt irgendwelche Aktionen

02:40:20.610 --> 02:40:22.530
auf dem Cluster. Wenn es jetzt

02:40:22.530 --> 02:40:24.830
so gewesen wäre, dass ich das einfach nur in DataFrame-Syntax,

02:40:24.910 --> 02:40:26.810
was ich mit den Daten machen wollte, hätte hinschreiben

02:40:26.810 --> 02:40:28.850
können, dann wäre mir ja schon viel geholfen

02:40:28.850 --> 02:40:30.830
gewesen. Und genau das hat

02:40:30.830 --> 02:40:32.490
halt Ibis, diese Bibliothek, die dann

02:40:32.490 --> 02:40:34.410
Westmorekenny bei Cloudera gebaut hat,

02:40:34.530 --> 02:40:36.830
gemacht. Man hatte ein Ding, das war

02:40:36.830 --> 02:40:38.190
wie ein Pandas-Data-Frame,

02:40:38.670 --> 02:40:40.450
wo man da halt irgendwie Group-By gesagt hat und

02:40:40.450 --> 02:40:42.270
dann hat das halt nicht

02:40:42.270 --> 02:40:44.930
das im Hauptspeicher gemacht, wie Pandas,

02:40:44.930 --> 02:40:46.970
sondern das hat dann halt SQL-Statements erzeugt,

02:40:47.270 --> 02:40:48.510
automatisch, die man aber nicht gesehen hat,

02:40:49.030 --> 02:40:49.530
und die dann

02:40:49.530 --> 02:40:52.710
auf den Cluster irgendwie

02:40:52.710 --> 02:40:54.490
losgelassen. Und dann

02:40:54.490 --> 02:40:56.430
magisch

02:40:56.430 --> 02:40:57.830
mit den Ergebnissen irgendwas gemacht.

02:40:59.330 --> 02:41:00.110
Ja, aber

02:41:00.110 --> 02:41:02.550
das hat auch nicht gereicht, weil auch da wieder das Problem war,

02:41:02.610 --> 02:41:04.290
wie kriegt man die Daten wieder, wenn man jetzt,

02:41:04.610 --> 02:41:05.950
man kann eben sowas nicht sagen, wie

02:41:05.950 --> 02:41:08.470
wenn man es jetzt richtig transformiert hat, also da war das schon

02:41:08.470 --> 02:41:10.550
eine Hilfe, aber jetzt hätte man gerne die Werte,

02:41:10.670 --> 02:41:11.670
um sie tatsächlich in den Machine Learning

02:41:11.670 --> 02:41:14.110
Algorithmus reinzupumpen, damit er

02:41:14.110 --> 02:41:15.890
möchte irgendwie ein Modell drauf trainieren.

02:41:16.350 --> 02:41:18.230
Man kann eben jetzt bei diesem Data Frame eben nicht sagen

02:41:18.230 --> 02:41:20.490
df.values. Das geht

02:41:20.490 --> 02:41:22.270
halt nicht, weil die Daten sind halt im Cluster.

02:41:22.910 --> 02:41:24.890
weil sie da irgendwie rauskriegen und man kriegt sie nicht raus.

02:41:24.970 --> 02:41:26.990
Es geht nicht. Also der Weg von

02:41:26.990 --> 02:41:27.810
ja,

02:41:28.970 --> 02:41:30.610
ja, und das war halt dann auch

02:41:30.610 --> 02:41:32.670
irgendwie ein Problem, wo dann das IBIS

02:41:32.670 --> 02:41:34.590
Projekt so ein bisschen dann vorbei war

02:41:34.590 --> 02:41:36.970
und Westman Kinney hat dann auch

02:41:36.970 --> 02:41:38.950
ist dann von Cloudera irgendwie weg und hat

02:41:38.950 --> 02:41:40.970
dann Apache Arrow gestartet und Apache Arrow

02:41:40.970 --> 02:41:41.670
macht halt genau

02:41:41.670 --> 02:41:44.850
da weiter und das hat mir dann auch wieder

02:41:44.850 --> 02:41:46.330
weitergeholfen, weil

02:41:46.330 --> 02:41:48.950
okay, es geht nicht

02:41:48.950 --> 02:41:50.430
anders, man muss tatsächlich auf die rohen

02:41:50.430 --> 02:41:52.370
Parquet-Files im Cluster irgendwie

02:41:52.370 --> 02:41:52.890
zugreifen.

02:41:54.530 --> 02:41:56.510
Und wenn man jetzt irgendwie da drauf was

02:41:56.510 --> 02:41:57.970
machen möchte, man braucht irgendwie ein

02:41:57.970 --> 02:42:00.250
Array-mäßiges Interface auf

02:42:00.250 --> 02:42:02.490
diese Files. Wenn man das hat, dann

02:42:02.490 --> 02:42:04.270
ist man eigentlich im Grunde, dann funktioniert alles.

02:42:05.210 --> 02:42:05.890
Und das macht Arrow.

02:42:06.210 --> 02:42:08.090
Arrow ist halt sozusagen ein

02:42:08.090 --> 02:42:09.930
In-Memory-Datenstruktur,

02:42:10.150 --> 02:42:11.610
Array-Datenstruktur, die halt

02:42:11.610 --> 02:42:14.090
von unterschiedlichen, das ist auch das Ziel dabei,

02:42:14.350 --> 02:42:16.090
ist auch eine Kollaboration mit irgendwie einem der

02:42:16.090 --> 02:42:18.310
wichtigeren Leute, die hinter

02:42:18.310 --> 02:42:19.830
R oder RStudio

02:42:19.830 --> 02:42:21.090
zusammen.

02:42:22.870 --> 02:42:23.550
Die haben das

02:42:23.550 --> 02:42:24.650
beide zusammen gemacht, dieses Projekt.

02:42:27.030 --> 02:42:27.390
Genau.

02:42:28.190 --> 02:42:29.710
Die Idee ist sozusagen, du hast halt

02:42:29.710 --> 02:42:31.750
eine Abstraktionsschicht,

02:42:31.890 --> 02:42:33.610
die halt irgendwie so ein Array-Store

02:42:33.610 --> 02:42:34.610
im Hauptspeicher hält.

02:42:35.610 --> 02:42:37.530
Das macht Apache Vero. Das Ding ist in C++

02:42:37.530 --> 02:42:39.650
geschrieben, aber du kannst halt von Python aus zugreifen

02:42:39.650 --> 02:42:41.170
oder von AdRof zugreifen,

02:42:41.350 --> 02:42:42.610
von Java aus.

02:42:43.510 --> 02:42:45.250
Und du musst es halt nur einmal im Hauptspeicher halten

02:42:45.250 --> 02:42:47.630
und du hast es dann halt in dem Format,

02:42:47.690 --> 02:42:49.550
in dem du es brauchst, um es halt in Machine Learning-Modelle

02:42:49.550 --> 02:42:50.510
reinzupumpen.

02:42:51.790 --> 02:42:53.330
Ja, was du halt, diese ganze

02:42:53.330 --> 02:42:55.270
Loop-Welt, du kannst dein Machine Learning

02:42:55.270 --> 02:42:57.470
Algorithmus ja nicht als MapReduce, das geht halt nicht

02:42:57.470 --> 02:42:59.530
schreiben, weil wenn du ein neuronales

02:42:59.530 --> 02:43:00.870
Netz hast, das hat Verbindungen überall hin,

02:43:01.410 --> 02:43:03.590
dann kannst du es halt nicht klar auf horizontal

02:43:03.590 --> 02:43:05.450
auftreiben in Mapper und Reducer, das funktioniert

02:43:05.450 --> 02:43:06.510
einfach nicht, das ist halt Quatsch.

02:43:07.270 --> 02:43:09.450
Viele Machine Learning

02:43:09.450 --> 02:43:11.270
Algorithmen lassen sich nicht einfach so verteilen.

02:43:12.050 --> 02:43:13.490
Oder, ja, sie brauchen halt

02:43:13.490 --> 02:43:15.530
irgendwie ihre Daten in einem bestimmten Format

02:43:15.530 --> 02:43:17.090
und das ist halt so ein Array-Format, weil das ist alles

02:43:17.090 --> 02:43:19.650
linearer Algebra. Und linearer Algebra

02:43:19.650 --> 02:43:21.530
funktioniert mit Vektoren, Matrizen

02:43:21.530 --> 02:43:23.650
oder halt, man nennt die

02:43:23.650 --> 02:43:25.490
Dinger allgemein Arrays halt.

02:43:26.150 --> 02:43:27.730
Also beliebig dimensionale Arrays.

02:43:29.870 --> 02:43:31.090
Ja, und

02:43:31.090 --> 02:43:33.530
das geht halt so einfach eigentlich

02:43:33.530 --> 02:43:35.150
irgendwie nicht. Und

02:43:35.150 --> 02:43:37.730
ja, mit Apache

02:43:37.730 --> 02:43:39.570
Arrow halt schon. Und außerdem macht

02:43:39.570 --> 02:43:41.570
Apache Arrow dann halt so ein paar Sachen wieder.

02:43:41.630 --> 02:43:43.790
Jetzt sieht es wieder gerade, die halt bei NumPy so ein bisschen kaputt sind.

02:43:45.070 --> 02:43:45.930
Unter anderem

02:43:45.930 --> 02:44:00.270
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.

02:44:01.690 --> 02:44:17.710
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.

02:44:17.710 --> 02:44:41.170
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.

02:44:44.110 --> 02:44:45.710
sagen wir mal so, was die halt tun können.

02:44:45.810 --> 02:44:47.350
Nehmen wir an, du bist Walmart und

02:44:47.350 --> 02:44:49.350
du interessierst dich jetzt dafür,

02:44:49.730 --> 02:44:50.450
keine Ahnung, weißt jetzt,

02:44:51.370 --> 02:44:53.510
es kommt eine Flut, die irgendwie

02:44:53.510 --> 02:44:55.730
deine Stadt überschwemmen wird und

02:44:55.730 --> 02:44:57.670
dann, was werden

02:44:57.670 --> 02:44:58.330
die Leute dann kaufen?

02:45:00.010 --> 02:45:00.410
Okay.

02:45:01.310 --> 02:45:03.150
Für was musst du irgendwie vorsorgen?

02:45:03.650 --> 02:45:05.890
Und bei einem klassischen BI-Ansatz

02:45:05.890 --> 02:45:07.570
wäre halt, du guckst dir halt die Icons an,

02:45:07.690 --> 02:45:09.510
wo Städte überflutet worden sind, da gibt es nicht so viele.

02:45:11.990 --> 02:45:12.390
Substrahierst

02:45:12.390 --> 02:45:14.050
da halt irgendwie so, kriegst dir das halt eine Woche

02:45:14.050 --> 02:45:15.210
vorher, später an

02:45:15.210 --> 02:45:18.330
und überlegst dir dann halt irgendwas und das machst du

02:45:18.330 --> 02:45:20.070
dann. Und dann machst du irgendwie

02:45:20.070 --> 02:45:22.310
gewisse Voraussagen und sagst so, das könnte ungefähr so und so

02:45:22.310 --> 02:45:24.450
aussehen. Das ist halt das, was passiert

02:45:24.450 --> 02:45:26.690
und das ist halt auch das, was heute noch in BI-Abteilungen

02:45:26.690 --> 02:45:28.230
hauptsächlich passiert, dass die Leute halt irgendwie so

02:45:28.230 --> 02:45:29.910
historische Daten angucken und dann so überlegen, so

02:45:29.910 --> 02:45:30.670
und

02:45:30.670 --> 02:45:33.690
ich denke,

02:45:34.010 --> 02:45:36.470
das wird alles so in Zukunft

02:45:36.470 --> 02:45:37.810
eher Richtung Data Science laufen.

02:45:39.210 --> 02:45:40.490
Damit meine ich, dass

02:45:40.490 --> 02:45:42.670
solche Antworten kommen halt dann

02:45:42.670 --> 02:45:43.910
eher von Systemen, die

02:45:43.910 --> 02:45:45.290
Vorhersagen machen.

02:45:46.830 --> 02:45:48.550
Und die werden das deutlich

02:45:48.550 --> 02:45:49.070
besser können.

02:45:50.830 --> 02:45:52.010
Und die werden das halt auch,

02:45:53.030 --> 02:45:54.830
also ein Großteil dieser Analysegeschichte

02:45:54.830 --> 02:45:55.950
wird man halt automatisieren können.

02:45:56.530 --> 02:45:58.630
Und das Problem momentan ist halt

02:45:58.630 --> 02:45:59.490
so ein bisschen, dass die

02:45:59.490 --> 02:46:02.410
Tools, die man hat, nicht zueinander passen.

02:46:02.730 --> 02:46:04.130
Zu dem, die

02:46:04.130 --> 02:46:06.430
so Hadoop-Welt

02:46:06.430 --> 02:46:08.450
passt eigentlich eher so zu dem klassischen

02:46:08.450 --> 02:46:09.030
BI-Ansatz.

02:46:10.490 --> 02:46:35.070
Ä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.

02:46:36.010 --> 02:46:56.930
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.

02:46:56.930 --> 02:46:59.730
und dann musst du halt Software

02:46:59.730 --> 02:47:01.410
entwickeln eigentlich, dann bist du halt so Teil

02:47:01.410 --> 02:47:02.770
der Produktentwicklung

02:47:02.770 --> 02:47:05.790
und ja, das geht halt auch nicht so

02:47:05.790 --> 02:47:07.870
richtig gut und was da ein bisschen fehlt

02:47:07.870 --> 02:47:09.930
ist halt so ein

02:47:09.930 --> 02:47:11.830
ist halt

02:47:11.830 --> 02:47:13.650
etwas, was halt Daten

02:47:13.650 --> 02:47:15.130
in Array-Form im Hauptspeicher hält

02:47:15.130 --> 02:47:17.950
und das macht Apache Arrow

02:47:17.950 --> 02:47:19.430
und deswegen finde ich das Projekt so super interessant

02:47:19.430 --> 02:47:21.890
es gibt dann noch SideDB

02:47:21.890 --> 02:47:22.670
oder sowas

02:47:22.670 --> 02:47:25.790
glaube ich, die auch sowas ähnliches machen, aber da geht's

02:47:25.790 --> 02:47:27.250
irgendwie hin. Und

02:47:27.250 --> 02:47:29.430
ja, es geht Richtung Streaming.

02:47:29.710 --> 02:47:31.130
Spark macht ja auch ganz viel mit Streaming.

02:47:31.890 --> 02:47:33.390
Wobei mich natürlich besonders interessiert

02:47:33.390 --> 02:47:34.890
PySpark, weil Python und so.

02:47:36.510 --> 02:47:36.690
Ja.

02:47:42.190 --> 02:47:43.270
Haben wir da noch irgendwann?

02:47:43.270 --> 02:47:45.290
Ich wollte gerade sagen, wir haben jetzt ganz, ganz

02:47:45.290 --> 02:47:47.190
lange schon, also fast drei Stunden

02:47:47.190 --> 02:47:49.050
schon über die ganzen Daten gesagt. Man merkt ja,

02:47:49.090 --> 02:47:50.050
Jochen ist ja sehr tief drin.

02:47:50.810 --> 02:47:52.790
Das ist auch ein super breites Thema.

02:47:53.830 --> 02:47:55.290
Haben wir tatsächlich die meisten Sachen

02:47:55.290 --> 02:47:57.190
schon jetzt durch? Oder hast du noch was, was du unbedingt

02:47:57.190 --> 02:47:58.970
da zu dem Thema beteiligst? Genau, genau, genau.

02:48:00.150 --> 02:48:01.450
Ja, ach so, ah, und genau,

02:48:01.530 --> 02:48:03.070
wenn man jetzt nochmal zurückkommt zu dem E-Commerce-Ding,

02:48:03.110 --> 02:48:04.850
das war jetzt so eine Exkurs Richtung Big Data.

02:48:05.210 --> 02:48:06.730
Ja, also wenn wir ganz groß sind,

02:48:06.870 --> 02:48:09.290
immer so ein Maß oder so.

02:48:09.670 --> 02:48:11.350
Ja, also das hatten wir auch vorher schon mal

02:48:11.350 --> 02:48:12.550
kurz angeklärt, also

02:48:12.550 --> 02:48:14.790
relationeller Datenbanken oder so, diese Art,

02:48:14.990 --> 02:48:17.010
Daten umzugehen, ist halt besonders gut dann,

02:48:17.110 --> 02:48:19.190
wenn es Daten über Sachen sind, die nicht

02:48:19.190 --> 02:48:20.970
Daten sind. Also physikalische

02:48:20.970 --> 02:48:22.590
Sachen, die sich nicht so schnell ändern,

02:48:23.190 --> 02:48:25.090
bei denen es Sinn macht, ein festes

02:48:25.090 --> 02:48:26.990
Schema zu definieren, dass dann halt auch über längere Zeit

02:48:26.990 --> 02:48:28.950
mehr oder weniger gleich bleiben kann. Man kann natürlich Sachen ändern,

02:48:29.090 --> 02:48:30.830
aber Dinge grundsätzlich ändern

02:48:30.830 --> 02:48:32.030
ist dann schwierig.

02:48:34.750 --> 02:48:35.150
Aber

02:48:35.150 --> 02:48:38.610
das ist jetzt tatsächlich die Zukunft.

02:48:38.790 --> 02:48:40.950
Es ist auch nicht so richtig sinnvoll, diese Amazon-Geschichte

02:48:40.950 --> 02:48:42.350
also heute Amazon zu bauen,

02:48:42.970 --> 02:48:44.730
ist viel, viel einfacher natürlich. Also ich meine,

02:48:44.730 --> 02:48:46.410
das hört sich so an, als wäre es total einfach, Amazon

02:48:46.410 --> 02:48:48.670
zu werden. Das ist es

02:48:48.670 --> 02:48:48.830
nicht.

02:48:50.410 --> 02:48:52.470
Es war auch zu der Zeit, als Amazon

02:48:52.470 --> 02:48:54.690
geworden ist, war es viel schwieriger, weil da gab

02:48:54.690 --> 02:48:56.330
es halt keine Tools. So was wie Postgres

02:48:56.330 --> 02:48:58.090
gab es, aber es war

02:48:58.090 --> 02:48:59.770
nicht in dem

02:48:59.770 --> 02:49:04.310
Zustand wie heute.

02:49:04.450 --> 02:49:05.670
Es wäre nicht nutzbar gewesen.

02:49:06.990 --> 02:49:08.030
Also es gab damals,

02:49:08.310 --> 02:49:10.330
ich weiß nicht wann die angefangen haben, Anfang der 90er

02:49:10.330 --> 02:49:12.470
oder, also Amazon hat sehr, sehr früh angefangen,

02:49:12.690 --> 02:49:13.710
Mitte der 90er, ich weiß nicht genau.

02:49:15.010 --> 02:49:15.730
Da gab es halt nichts.

02:49:16.210 --> 02:49:18.350
Die mussten alles selber bauen. Das ist natürlich

02:49:18.350 --> 02:49:19.310
nochmal ein ganz anderes Problem.

02:49:20.290 --> 02:49:22.310
Während heute man wahrscheinlich mit Postgres,

02:49:22.310 --> 02:49:23.410
Django, Redis

02:49:23.410 --> 02:49:26.150
und ein paar Rechnern wahrscheinlich einen Markt

02:49:26.150 --> 02:49:28.050
wie Deutschland mit so einer ähnlichen

02:49:28.050 --> 02:49:30.130
Seite wie Amazon versorgen könnte.

02:49:31.490 --> 02:49:31.930
Das

02:49:31.930 --> 02:49:33.730
ging halt damals nicht und

02:49:33.730 --> 02:49:36.010
das macht es heute einem natürlich

02:49:36.010 --> 02:49:37.970
vielleicht, aber heute ist halt das Problem, es gibt Amazon schon,

02:49:38.350 --> 02:49:39.890
man muss mit Amazon konkurrieren und

02:49:39.890 --> 02:49:41.490
leider hat man da keine Chance.

02:49:42.450 --> 02:49:43.730
Deswegen funktioniert das auch nicht.

02:49:44.230 --> 02:49:46.210
Aber was natürlich interessant möglicherweise

02:49:46.210 --> 02:49:47.970
ist, ist sich zu überlegen,

02:49:48.310 --> 02:49:50.070
okay, was kann Amazon denn mit dem, was sie

02:49:50.070 --> 02:49:51.950
tun, nicht machen und wo entwickelt sich das

02:49:51.950 --> 02:49:52.730
halt in Zukunft hin.

02:49:53.530 --> 02:49:55.850
Ich habe das auch schon wieder 10 Jahre her,

02:49:55.930 --> 02:49:57.490
unglaublich, oder noch mehr als 10 Jahre sogar.

02:49:58.890 --> 02:50:00.230
Mein Vortrag gehört

02:50:00.230 --> 02:50:02.010
von David Weinberger,

02:50:02.150 --> 02:50:03.830
der ist ein Philosoph,

02:50:04.470 --> 02:50:06.070
hat sich auch viel mit Internetgeschichten

02:50:06.070 --> 02:50:07.190
beschäftigt in Harvard.

02:50:08.370 --> 02:50:09.750
Kann man mal gucken, ich packe ja auch noch

02:50:09.750 --> 02:50:10.230
in die Shownotes.

02:50:12.230 --> 02:50:13.130
Der Vortrag heißt

02:50:13.130 --> 02:50:14.210
Everything's Miscellaneous.

02:50:15.330 --> 02:50:16.230
Da gibt es auch ein Buch zu.

02:50:18.090 --> 02:50:19.630
Der Talk bei Google ist halt

02:50:19.630 --> 02:50:21.750
eine Vorstellung von dem Buchinhalt,

02:50:21.950 --> 02:50:35.050
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.

02:50:35.050 --> 02:50:38.450
Und wir das aber noch gar nicht so richtig antizipiert haben.

02:50:40.050 --> 02:50:43.770
Sein Beispiel ist halt auch E-Commerce und halt auch so Faceted Navigation.

02:50:45.930 --> 02:50:51.630
Und er sagt halt, naja, also in so einem klassischen Laden, wenn du da reingehst, muss man sich überlegen.

02:50:51.950 --> 02:50:53.930
wo man welche Dinge hinpackt, ja, also

02:50:53.930 --> 02:50:55.930
da

02:50:55.930 --> 02:50:58.010
physikalische Objekte nur an einem Ort gleichzeitig sein

02:50:58.010 --> 02:50:59.910
können oder

02:50:59.910 --> 02:51:01.830
überhaupt irgendwo sein müssen, muss man halt

02:51:01.830 --> 02:51:03.990
irgendwie das so strukturieren, dass das der Fall ist

02:51:03.990 --> 02:51:05.910
und dann muss man sich überlegen, okay, wie macht das für die meisten Leute

02:51:05.910 --> 02:51:07.830
Sinn, wenn sie reinkommen, ist immer der

02:51:07.830 --> 02:51:09.170
Salat irgendwie vorne rechts oder keine Ahnung

02:51:09.170 --> 02:51:11.910
und das muss man eigentlich,

02:51:12.250 --> 02:51:13.910
wenn man jetzt Daten über Daten

02:51:13.910 --> 02:51:15.830
hat, gar nicht mehr so

02:51:15.830 --> 02:51:17.850
machen, man könnte das irgendwie so slicing und

02:51:17.850 --> 02:51:19.770
dicing, wie man wollte, also man könnte halt sagen,

02:51:19.890 --> 02:51:21.790
okay, ich bin jemand, der nur schwarze T-Shirts anzieht,

02:51:21.910 --> 02:51:24.950
also alles andere interessiert mich nicht.

02:51:25.630 --> 02:51:27.870
Ich brauche jetzt eine Navigation innerhalb dieser schwarzen T-Shirts,

02:51:27.990 --> 02:51:30.090
aber alle anderen Sachen kann ich schon mal so irgendwie wegschneiden.

02:51:30.790 --> 02:51:33.030
Das würde für alle anderen vielleicht keinen Sinn machen

02:51:33.030 --> 02:51:35.010
oder für andere Leute, jeder hat vielleicht andere Arten.

02:51:36.270 --> 02:51:38.610
Aber ich kann jetzt eine Seite bauen,

02:51:38.810 --> 02:51:40.810
die auf die Bedürfnisse von jedem im Grunde zugeschnitten ist

02:51:40.810 --> 02:51:41.650
oder sich leicht so an...

02:51:41.650 --> 02:51:43.570
Die eigene Filter-Bubble immer erzeugt für den jeweiligen...

02:51:43.570 --> 02:51:45.990
Genau, weil elektronisch habe ich das Problem nicht.

02:51:46.270 --> 02:51:47.990
ich kann für jeden

02:51:47.990 --> 02:51:49.890
eine eigene Art von Laden

02:51:49.890 --> 02:51:52.010
erzeugen

02:51:52.010 --> 02:51:54.090
oder eine eigene Art von Navigation

02:51:54.090 --> 02:51:56.410
bauen. Nur wenn ich denjenigen

02:51:56.410 --> 02:51:57.830
kenne natürlich. Natürlich.

02:51:58.470 --> 02:52:00.170
Oder wenn er es mir halt irgendwie sagt, indem ich

02:52:00.170 --> 02:52:02.470
ein Interface habe, wo man das halt irgendwie einstellen könnte.

02:52:04.010 --> 02:52:04.430
Aber

02:52:04.430 --> 02:52:06.270
das wird kaum gemacht. Es gibt halt meistens

02:52:06.270 --> 02:52:08.170
doch wieder einen Kategorienbaum, der

02:52:08.170 --> 02:52:09.510
halt irgendwie

02:52:09.510 --> 02:52:12.070
Kategorienbaum auf einer Seite ist ja im Grunde

02:52:12.070 --> 02:52:14.250
sowas wie ein

02:52:14.250 --> 02:52:16.270
Weg durch den Laden, der halt vorgegeben ist.

02:52:16.810 --> 02:52:18.250
Warum muss das denn so sein? Das muss

02:52:18.250 --> 02:52:20.050
ja eigentlich, also wir adaptieren da

02:52:20.050 --> 02:52:21.970
eine Sichtweise aus der

02:52:21.970 --> 02:52:23.830
physischen Welt, die

02:52:23.830 --> 02:52:26.130
vielleicht insofern hilfreich ist, weil

02:52:26.130 --> 02:52:27.870
die Leute kennen das so. Ja genau, die kennen das so, ja.

02:52:28.450 --> 02:52:30.250
Insofern macht das auch durchaus Sinn, das so zu tun,

02:52:30.370 --> 02:52:32.090
aber es müsste eigentlich nicht so sein und vielleicht

02:52:32.090 --> 02:52:34.090
wäre es, wenn man das anders machen würde, halt viel effizienter

02:52:34.090 --> 02:52:34.370
und

02:52:34.370 --> 02:52:38.030
genau. Das ist Raum für ein Startup da

02:52:38.030 --> 02:52:39.870
übrigens gerade. Ja, das Problem ist halt nur,

02:52:40.090 --> 02:52:41.990
also ich fand das ja schon vor über 10 Jahren

02:52:41.990 --> 02:52:42.950
interessant, aber

02:52:42.950 --> 02:52:45.650
in der Richtung hat sich noch nicht so wirklich

02:52:45.650 --> 02:52:47.630
wahnsinnig viel getan. Insofern bin ich mir nicht

02:52:47.630 --> 02:52:49.210
sicher, ob das eine gute Idee ist. Also damals war es auch, wenn wir

02:52:49.210 --> 02:52:51.510
zurückblicken, kann man jetzt sagen, damals ein Startup in die

02:52:51.510 --> 02:52:53.110
Richtung zu starten, wäre keine gute Idee gewesen.

02:52:53.730 --> 02:52:55.730
Vielleicht wäre es jetzt eine gute Idee.

02:52:55.890 --> 02:52:57.270
Vielleicht ist es aber erst in fünf Jahren eine gute Idee.

02:52:57.390 --> 02:52:59.430
Keine Ahnung, wann der Zeitpunkt

02:52:59.430 --> 02:53:01.550
richtig ist. Keine Ahnung.

02:53:01.710 --> 02:53:03.490
Man braucht ein Gespür für. Und wenn man das Gespür hat

02:53:03.490 --> 02:53:04.930
und dann an der richtigen Stelle ist, dann ja.

02:53:06.630 --> 02:53:07.430
Braucht man nur noch ein bisschen Geld

02:53:07.430 --> 02:53:08.150
und Geduld.

02:53:09.670 --> 02:53:11.370
Aber genau der

02:53:11.370 --> 02:53:13.230
Punkt, auf den ich eigentlich hinaus will, ist,

02:53:13.850 --> 02:53:15.650
was ist eigentlich, Amazon hat das gleiche

02:53:15.650 --> 02:53:17.670
Interface für alle Arten von Dingen, die sie verkaufen.

02:53:17.830 --> 02:53:19.470
Sie haben am Anfang mit Büchern angefangen,

02:53:19.890 --> 02:53:21.030
weil bei Büchern das Problem,

02:53:22.150 --> 02:53:23.550
weil sie da einen ganz klaren

02:53:23.550 --> 02:53:25.350
Vorteil gegenüber den anderen

02:53:25.350 --> 02:53:27.170
Verkäufern... Du möchtest ein Framing bauen

02:53:27.170 --> 02:53:28.650
für den jeweiligen Kunden.

02:53:29.150 --> 02:53:31.010
Ich möchte halt zum Beispiel einfach nur so

02:53:31.010 --> 02:53:32.490
in die Richtung gehen,

02:53:33.610 --> 02:53:35.710
warum

02:53:35.710 --> 02:53:37.350
muss die Navigation immer gleich aussehen?

02:53:37.350 --> 02:53:39.130
Das eigene Holodeck. Also manchmal geht man

02:53:39.130 --> 02:53:40.970
im Mittelalterladen einkaufen, mal im Cyberstore.

02:53:41.370 --> 02:53:42.850
Genau, je nachdem, was man

02:53:42.850 --> 02:53:44.450
verkaufen möchte. Amazon

02:53:44.450 --> 02:53:46.730
macht jetzt nicht nur Bücher, sondern mittlerweile

02:53:46.730 --> 02:53:48.690
machen sie, Bücher ist jetzt wahrscheinlich

02:53:48.690 --> 02:53:50.230
gar kein großer Anteil mehr an ihrem Geschäft.

02:53:50.770 --> 02:53:52.790
Sie verkaufen viel Elektronik und das sieht

02:53:52.790 --> 02:53:54.730
man der Seite halt auch an. Also vieles von

02:53:54.730 --> 02:53:56.550
der Navigation ist darauf optimiert, dass ich halt

02:53:56.550 --> 02:53:58.850
irgendwie so Elektronik, weiße Ware

02:53:58.850 --> 02:54:00.630
irgendwie kaufen kann. So ein bisschen wie Ambilight beim

02:54:00.630 --> 02:54:01.790
Fernseher.

02:54:02.650 --> 02:54:04.030
Ja, aber halt inhaltlich.

02:54:04.330 --> 02:54:06.690
Das liegt halt vor allen Dingen, dass die Navigation so aussieht, wie sie

02:54:06.690 --> 02:54:08.570
aussieht, liegt halt am Datenbankschema.

02:54:09.390 --> 02:54:10.710
Weil das lässt halt gar

02:54:10.710 --> 02:54:12.710
nicht zu, dass ich irgendwie was großartig anderes baue, weil

02:54:12.710 --> 02:54:13.910
das ist halt mehr oder weniger fix.

02:54:16.930 --> 02:54:18.530
Jetzt ist es natürlich schon so, dass

02:54:18.530 --> 02:54:20.730
unterschiedliche Dinge, also Fahrräder haben halt

02:54:20.730 --> 02:54:22.710
bestimmte, das kann ich schon irgendwie, da kann ich

02:54:22.710 --> 02:54:24.810
ein Schema bauen, das das irgendwie modelliert, oder Bücher

02:54:24.810 --> 02:54:25.910
oder Waschmaschinen.

02:54:27.390 --> 02:54:28.730
Aber die Daten über die

02:54:28.730 --> 02:54:30.850
Daten, die kann ich natürlich irgendwie

02:54:30.850 --> 02:54:32.630
beliebig modellieren.

02:54:32.730 --> 02:54:34.510
Da könnte ich auch beliebige Navigationen draufbauen.

02:54:34.510 --> 02:54:36.350
Und ich könnte auch, also wenn ich jetzt,

02:54:36.970 --> 02:54:38.470
also der Witz ist, was ich

02:54:38.470 --> 02:54:40.410
eigentlich eventuell gerne hätte,

02:54:40.710 --> 02:54:59.670
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.

02:54:59.670 --> 02:55:00.870
dafür müsste er das Schema ändern können.

02:55:02.010 --> 02:55:03.690
Das heißt, er müsste das Schema live

02:55:03.690 --> 02:55:05.710
irgendwie ändern können. Was in relationalen Daten,

02:55:05.790 --> 02:55:07.270
das kannst du vergessen. Also du kannst,

02:55:07.610 --> 02:55:09.550
ich meine, du musst eine Migration machen, du musst halt

02:55:09.550 --> 02:55:09.970
irgendwie,

02:55:11.310 --> 02:55:13.470
das kannst du alles, das kannst du komplett, also

02:55:13.470 --> 02:55:15.390
sagen wir mal so, es geht technisch, aber das ist auf jeden Fall

02:55:15.390 --> 02:55:17.450
Entwicklerarbeit. Das ist halt nicht etwas, was irgendjemand,

02:55:18.170 --> 02:55:19.510
der auf einer Webseite irgendwas einstellt,

02:55:19.630 --> 02:55:22.470
irgendwie, das geht halt

02:55:22.470 --> 02:55:23.070
eher nicht.

02:55:23.890 --> 02:55:25.070
Aber, wenn man jetzt

02:55:25.070 --> 02:55:27.030
sich von diesem relationalen

02:55:27.030 --> 02:55:29.050
Paradigmen so ein bisschen löst und sagt,

02:55:29.170 --> 02:55:31.210
okay, ja, dann ginge das eventuell

02:55:31.210 --> 02:55:33.210
schon. Also im Grunde, wenn man

02:55:33.210 --> 02:55:35.210
jetzt nicht Daten über physikalische

02:55:35.210 --> 02:55:36.830
Objekte hat, sondern Daten über Daten und

02:55:36.830 --> 02:55:39.050
eine Datenbank, die halt

02:55:39.050 --> 02:55:39.870
nicht mehr so

02:55:39.870 --> 02:55:43.250
Fixschema, nicht so ein Fixschema

02:55:43.250 --> 02:55:45.310
hat, dann könnte man eventuell das so machen, dass man

02:55:45.310 --> 02:55:46.270
die Seite

02:55:46.270 --> 02:55:49.150
live so ändert, wie sie

02:55:49.150 --> 02:55:51.070
halt eventuell mehr Sinn macht. Und vielleicht

02:55:51.070 --> 02:55:53.090
könnten das auch die User tun, keine Ahnung. Es ist halt nur so,

02:55:53.170 --> 02:55:55.090
es ist halt so eine Idee. Es ist halt einfach so eine Idee,

02:55:55.530 --> 02:55:56.930
wie geht es jetzt eigentlich weiter?

02:55:57.230 --> 02:55:59.050
Ich meine, Amazon ist im Grunde mehr oder weniger fertig,

02:55:59.050 --> 02:56:09.190
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.

02:56:11.050 --> 02:56:19.470
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.

02:56:21.390 --> 02:56:27.650
Genau, aber das könnte halt irgendwie wie etwas anders aussehen.

02:56:27.750 --> 02:56:29.350
Und was halt da sehr interessant sein könnte,

02:56:29.450 --> 02:56:30.930
sind halt Grafendatenbanken zum Beispiel.

02:56:31.650 --> 02:56:32.550
Wo man halt eben nicht,

02:56:32.850 --> 02:56:34.410
ich hatte das ja auch am Anfang schon mal erwähnt,

02:56:34.530 --> 02:56:36.490
es hätten sich auch Grafendatenbanken durchsetzen können.

02:56:36.570 --> 02:56:39.310
Das ist überhaupt nicht so klar, warum das relational geworden sind.

02:56:39.710 --> 02:56:42.770
Gut, die Grafendatenbanken waren ein bisschen später dran,

02:56:42.770 --> 02:56:47.610
aber ja, und da gibt es zum Beispiel auch ein super interessantes Projekt,

02:56:47.710 --> 02:56:49.070
nennt sich D-Graph.

02:56:49.790 --> 02:56:50.250
D-Graph.

02:56:50.470 --> 02:56:50.630
Ja.

02:56:51.390 --> 02:56:54.910
das ist ein Ex-Mitarbeiter von Google

02:56:54.910 --> 02:56:57.210
und

02:56:57.210 --> 02:56:58.990
der

02:56:58.990 --> 02:57:00.830
ja, der hat sich

02:57:00.830 --> 02:57:02.670
der hat sich irgendwie getroffen

02:57:02.670 --> 02:57:05.110
Google-Beschäftige und dann halt auch

02:57:05.110 --> 02:57:07.070
überlegt, was sind denn jetzt die Sachen, die man

02:57:07.070 --> 02:57:09.090
heutzutage, die Probleme, die man hat, also es muss halt irgendwie so

02:57:09.090 --> 02:57:11.090
es muss halt, Brides müssen

02:57:11.090 --> 02:57:12.490
halt auch

02:57:12.490 --> 02:57:15.270
man darf nicht nur einen Master haben, es muss halt irgendwie skalierbar

02:57:15.270 --> 02:57:17.110
sein, es muss halt

02:57:17.110 --> 02:57:19.070
irgendwie schnell sein und

02:57:19.070 --> 02:57:21.110
der hat, das hat letztes Mal

02:57:21.110 --> 02:57:23.050
als wir über Skalierbarkeit und so, ich glaube, das war in der

02:57:23.050 --> 02:57:24.810
ersten Folge oder so, geredet haben, habe ich auch gesagt,

02:57:25.210 --> 02:57:27.070
Go wäre eventuell ein guter Kandidat, um

02:57:27.070 --> 02:57:29.090
da drin eine Datenbank zu schreiben. Also Python

02:57:29.090 --> 02:57:31.510
halt nicht so. Das ist halt eines der

02:57:31.510 --> 02:57:33.270
wenigen Anwendungsfälle,

02:57:33.330 --> 02:57:35.290
wo ich sagen würde, gut, dafür ist Python nicht so gut geeignet,

02:57:35.370 --> 02:57:36.950
weil, also Python ist gut geeignet, wenn

02:57:36.950 --> 02:57:38.970
man IOMultiplexen muss, also man

02:57:38.970 --> 02:57:40.910
macht einfach nur viel Netzwerk in alle möglichen Richtungen.

02:57:41.350 --> 02:57:43.090
Das geht, da braucht man gar nicht unter Umständen

02:57:43.090 --> 02:57:45.070
viel CPU für, also solange man nicht viel

02:57:45.070 --> 02:57:47.070
CPU dafür braucht. Oder

02:57:47.070 --> 02:57:48.830
es ist gut dafür geeignet, wenn man viel CPU braucht,

02:57:49.030 --> 02:57:50.210
aber nicht so viel

02:57:50.210 --> 02:57:53.130
Concurrency hat, wenn man beides hat,

02:57:53.190 --> 02:57:54.990
man hat viel Concurrency und viel CPU,

02:57:55.170 --> 02:57:56.930
die das braucht, dann ist es halt eher scheiße,

02:57:57.030 --> 02:57:58.430
weil dann erwischt einen halt

02:57:58.430 --> 02:58:00.470
dieser Global Interpreter-Log und

02:58:00.470 --> 02:58:02.950
da stößt man an so

02:58:02.950 --> 02:58:03.930
prinzipielle Grenzen,

02:58:04.450 --> 02:58:04.590
was

02:58:04.590 --> 02:58:08.350
Skalierbarkeit angeht bei Python,

02:58:08.750 --> 02:58:10.390
aber ich würde sagen, naja, nicht so schlimm,

02:58:10.610 --> 02:58:12.690
ist eigentlich ganz gut, weil

02:58:12.690 --> 02:58:14.770
diesen Anwendungsfall haben die wenigsten Programmierer

02:58:14.770 --> 02:58:16.790
und ein Beispiel war

02:58:16.790 --> 02:58:18.730
halt, ja, Datenmarken sind eventuell

02:58:18.730 --> 02:58:20.590
so etwas, was halt genau

02:58:20.590 --> 02:58:22.510
diese Anforderungen hat und was man dann in Python vielleicht

02:58:22.510 --> 02:58:24.010
dann doch nicht so gut schreiben könnte.

02:58:25.090 --> 02:58:25.850
Und ja, tatsächlich,

02:58:26.270 --> 02:58:28.610
dgraph ist in Go

02:58:28.610 --> 02:58:30.190
geschrieben und

02:58:30.190 --> 02:58:32.490
ja, mit Grafen

02:58:32.490 --> 02:58:34.630
könnte man das halt tun. Da kann man halt

02:58:34.630 --> 02:58:36.770
das Schema ändern, live,

02:58:37.010 --> 02:58:38.430
ohne dass man irgendwie

02:58:38.430 --> 02:58:40.350
da so, weil man kann halt beliebige Beziehungen

02:58:40.350 --> 02:58:42.690
ziehen, beliebige Kanten.

02:58:43.250 --> 02:58:44.210
Man muss nicht unbedingt

02:58:44.210 --> 02:58:46.390
sozusagen alles in dieser

02:58:46.390 --> 02:58:48.550
Tabellen, man hat ja nicht mehr unbedingt diese Tabellenstruktur.

02:58:48.730 --> 02:58:51.670
und ja, das ist halt schon

02:58:51.670 --> 02:58:53.790
ziemlich interessant, auch wenn man

02:58:53.790 --> 02:58:57.570
es gibt ja nochmal bei den grafischen Datenmarken

02:58:57.570 --> 02:58:59.030
sowieso Unterschiede, es gibt auch diese ganzen

02:58:59.030 --> 02:59:01.590
ADF-Geschichten, da ist es aber so, dass

02:59:01.590 --> 02:59:03.130
die das nicht

02:59:03.130 --> 02:59:05.510
so optimiert irgendwie auf der Platte

02:59:05.510 --> 02:59:07.570
speichern, also das ist halt eher so

02:59:07.570 --> 02:59:08.850
ein Textformat

02:59:08.850 --> 02:59:11.690
es gibt ja auch Mikroformate auf Webseiten, wo man das benutzen kann

02:59:11.690 --> 02:59:13.370
wo man irgendwelche

02:59:13.370 --> 02:59:15.430
halt Metadaten

02:59:15.430 --> 02:59:17.530
über die Seite irgendwie hinterlegen kann

02:59:17.530 --> 02:59:19.510
ist bei uns auch eine vielleicht nicht so doofe

02:59:19.510 --> 02:59:21.690
Geschichte, gerade was Google angeht, Mikroformate.

02:59:23.010 --> 02:59:23.650
Dann kann halt

02:59:23.650 --> 02:59:25.370
Google automatisch eine ganze Menge Informationen

02:59:25.370 --> 02:59:27.530
aus der Seite ziehen, ohne dass sie das

02:59:27.530 --> 02:59:28.410
halt irgendwie raten müssen.

02:59:29.990 --> 02:59:31.330
Das geht auch schon alles so ein bisschen

02:59:31.330 --> 02:59:32.310
in Richtung Semantik-Web.

02:59:34.430 --> 02:59:35.530
Aber das Problem dabei

02:59:35.530 --> 02:59:36.610
ist, es ist halt nicht optimiert

02:59:36.610 --> 02:59:39.510
und für Graphenabfragen auch nicht optimiert.

02:59:39.630 --> 02:59:41.490
Daher wird es halt alles immer ziemlich langsam

02:59:41.490 --> 02:59:43.410
sein. Und es gibt halt Graphendatenbanken,

02:59:43.610 --> 02:59:45.470
die das halt so optimiert speichern.

02:59:45.470 --> 02:59:47.170
Dazu gehört Dgraph auf jeden Fall,

02:59:47.370 --> 02:59:49.310
die älteste und weitestverwaltete

02:59:49.310 --> 02:59:50.250
Datenbank Neo4j

02:59:50.250 --> 02:59:53.270
macht das auch so,

02:59:53.910 --> 02:59:55.410
aber Neo4j ist

02:59:55.410 --> 02:59:56.310
halt auch, das ist halt Java,

02:59:57.330 --> 02:59:58.630
kann ja schon mal nicht gut sein,

03:00:00.090 --> 03:00:01.370
aber es ist halt auch viel langsamer, muss man

03:00:01.370 --> 03:00:03.310
sagen, als die gemacht, und es ist halt auch, es hat

03:00:03.310 --> 03:00:04.670
eine komische Abfragesprache,

03:00:05.190 --> 03:00:06.250
Cypher heißt die irgendwie,

03:00:08.330 --> 03:00:09.070
ja, und

03:00:09.070 --> 03:00:11.290
naja, und ob das alles

03:00:11.290 --> 03:00:12.910
so, also ist auch Asset und so,

03:00:13.450 --> 03:00:14.450
das ist alles nicht so,

03:00:14.790 --> 03:00:16.750
es geht in die Richtung, aber es ist nicht so toll,

03:00:17.370 --> 03:00:19.330
irgendwie und bei D-Graph sieht das alles

03:00:19.330 --> 03:00:21.290
viel besser aus. Und was auch

03:00:21.290 --> 03:00:23.410
super cool ist bei D-Graph, das ist die Abfragesprache, die nehmen einfach

03:00:23.410 --> 03:00:24.810
GraphQL oder

03:00:24.810 --> 03:00:27.330
Dialekt davon und das ist natürlich auch nochmal sehr

03:00:27.330 --> 03:00:29.130
interessant, weil GraphQL ist natürlich auch momentan

03:00:29.130 --> 03:00:29.930
ein sehr heißes Thema.

03:00:31.750 --> 03:00:32.750
Ja, und

03:00:32.750 --> 03:00:34.810
möglicherweise, wenn man jetzt

03:00:34.810 --> 03:00:36.730
ein neues Amazon bauen würde,

03:00:37.390 --> 03:00:39.210
würde man damit anfangen, würde man

03:00:39.210 --> 03:00:41.110
jetzt das vielleicht nicht auf einer relationalen

03:00:41.110 --> 03:00:43.070
Datenbank aufsetzen, sondern auf sowas wie D-Graph.

03:00:43.730 --> 03:00:44.750
Und dann könnte man

03:00:44.750 --> 03:00:46.930
das so bauen, dass sich die

03:00:46.930 --> 03:00:49.090
Navigation, je nachdem, was

03:00:49.090 --> 03:00:50.870
man da einkauft, halt ändern lässt, auch

03:00:50.870 --> 03:00:51.710
live.

03:00:52.890 --> 03:00:53.890
Und es ist ja trotzdem schnell.

03:00:54.650 --> 03:00:56.790
Und ja,

03:00:57.090 --> 03:00:59.510
und das

03:00:59.510 --> 03:01:02.910
wäre so ein bisschen, dann könnte die Reise irgendwie

03:01:02.910 --> 03:01:04.470
gehen. Ich habe keine Ahnung, ob das

03:01:04.470 --> 03:01:06.510
passieren wird, aber. Ja, let's go.

03:01:09.850 --> 03:01:10.730
Ja, genau. Und dann

03:01:10.730 --> 03:01:12.330
auch, was auch interessant ist, ist halt noch,

03:01:12.730 --> 03:01:14.250
dass man irgendwie durchaus

03:01:14.250 --> 03:01:17.750
so hybride Formen

03:01:17.750 --> 03:01:19.170
haben kann zwischen Dokument-basiert

03:01:19.170 --> 03:01:20.470
oder Schema-less

03:01:20.470 --> 03:01:23.530
oder nur SQL

03:01:23.530 --> 03:01:24.930
und nur NoSQL, das heißt entweder

03:01:24.930 --> 03:01:27.050
steht für Not-Only-SQL

03:01:27.050 --> 03:01:28.210
oder eben

03:01:28.210 --> 03:01:31.370
kein SQL.

03:01:35.090 --> 03:01:35.690
Naja,

03:01:37.510 --> 03:01:39.170
in Postgres hat man zum Beispiel die Möglichkeit, das

03:01:39.170 --> 03:01:41.210
ein bisschen zu kombinieren. Da gibt es halt

03:01:41.210 --> 03:01:41.910
ein sehr schönes

03:01:41.910 --> 03:01:45.010
sehr schönen Spalten-Typ

03:01:45.010 --> 03:01:45.930
nennt sich

03:01:45.930 --> 03:01:48.030
BinaryJSON.

03:01:49.190 --> 03:01:51.010
Also man muss aufpassen, JSON gibt es auch,

03:01:51.130 --> 03:01:52.910
ist aber nur so aus Legacy-Gründen noch dabei.

03:01:53.370 --> 03:01:53.970
Den nicht nehmen,

03:01:55.010 --> 03:01:57.130
der ist alt

03:01:57.130 --> 03:01:58.490
und nicht so gut.

03:01:59.510 --> 03:02:01.050
Aber BinaryJSON ist super,

03:02:01.490 --> 03:02:01.810
weil

03:02:01.810 --> 03:02:05.030
da kann man auch Indizes auf

03:02:05.030 --> 03:02:07.210
Felder innerhalb von dem JSON machen. Das heißt, man kann

03:02:07.210 --> 03:02:09.050
halt die Teile, bei denen man sich nicht sicher ist, wie das

03:02:09.050 --> 03:02:11.190
Schema dafür eigentlich aussehen wird oder die man, wo man

03:02:11.190 --> 03:02:14.010
sozusagen die Definition des Schemas in die Applikation

03:02:14.010 --> 03:02:15.770
verlagern möchte, also wo dann ein

03:02:15.770 --> 03:02:17.770
Applikationsentwickler sagen kann, okay,

03:02:17.990 --> 03:02:19.790
an der Stelle speichere ich die Daten jetzt so und so,

03:02:20.450 --> 03:02:22.050
ja, ich möchte aber gar nicht die Datenbank verändern,

03:02:22.670 --> 03:02:23.930
dann kann er das, wenn er das

03:02:23.930 --> 03:02:25.750
in eine Spalte schreibt, die halt Binary JSON ist,

03:02:25.870 --> 03:02:27.570
einfach so reinschreiben, er kann sogar Sachen

03:02:27.570 --> 03:02:29.830
darin indizieren und so, und

03:02:29.830 --> 03:02:31.610
das ist halt sackschnell,

03:02:31.710 --> 03:02:33.890
das ist ähnlich schnell wie MongoDB,

03:02:34.110 --> 03:02:35.770
MongoDB macht ja, MongoDB ist

03:02:35.770 --> 03:02:37.350
mehr oder weniger nur diese

03:02:37.350 --> 03:02:39.110
B-JSON-Spalte

03:02:39.110 --> 03:02:40.470
aus Postgres.

03:02:41.190 --> 03:02:42.410
Das ist halt mehr oder weniger das Gleiche.

03:02:42.490 --> 03:02:45.670
Das heißt, ich kann das, was ich mit MongoDB mache,

03:02:45.750 --> 03:02:47.910
auch in einer solchen Spalte in Postgres machen.

03:02:48.310 --> 03:02:50.110
Ja gut, MongoDB ist vielleicht noch ein bisschen schneller,

03:02:50.230 --> 03:02:51.490
hat noch ein paar andere Funktionen,

03:02:51.490 --> 03:02:56.630
aber ich glaube nicht,

03:02:56.750 --> 03:02:58.710
dass viele Leute tatsächlich was anderes brauchen würden.

03:02:59.390 --> 03:03:00.850
Ich kann aber auf der anderen Seite bei den Sachen,

03:03:00.930 --> 03:03:01.630
bei denen ich weiß,

03:03:01.810 --> 03:03:03.250
also es gibt ja so etablierte Geschichten,

03:03:03.470 --> 03:03:04.490
da ist schon klar, wie das funktioniert.

03:03:05.010 --> 03:03:06.830
Userverwaltung, wenn ich eine Webseite habe,

03:03:06.990 --> 03:03:07.890
so wenn sich User anmelden,

03:03:08.690 --> 03:03:10.790
das ist alles relational, das ist auch etabliert,

03:03:10.830 --> 03:03:12.030
Da wird sich jetzt auch nicht so viel dran ändern.

03:03:12.710 --> 03:03:15.170
Und dann für die Teile der Applikation, wo ich mir halt nicht sicher bin,

03:03:15.250 --> 03:03:16.450
wo ich nicht weiß, in welche Richtung das geht,

03:03:16.530 --> 03:03:19.150
schreibe ich das halt als JSON, irgendwelche Spalten da.

03:03:20.070 --> 03:03:23.330
Und wenn das dann halt klar geworden ist, wie das Schema da aussieht,

03:03:23.450 --> 03:03:26.310
dann ziehe ich das dann auch Stück für Stück in ein relationales Schema.

03:03:27.770 --> 03:03:29.770
Sodass ich halt dann Vorteile aus beiden Welten habe.

03:03:29.770 --> 03:03:33.930
Und ich würde sagen, das ist halt momentan auch so ein relativ unschlagbares Feature

03:03:33.930 --> 03:03:39.210
von Postgres gegenüber den meisten anderen Datenbanken,

03:03:39.290 --> 03:03:41.350
dass man das halt so flexibel miteinander kombinieren

03:03:41.350 --> 03:03:43.070
kann, weil wenn ich MongoDB habe, habe ich ja das Problem,

03:03:43.490 --> 03:03:45.330
okay, also relational und

03:03:45.330 --> 03:03:47.390
konsistent und sicher und so, das geht

03:03:47.390 --> 03:03:49.290
halt alles nicht so richtig gut. Ich habe halt nur

03:03:49.290 --> 03:03:51.350
dieses Ding,

03:03:51.510 --> 03:03:53.190
wo ich halt meine, ich kann zwar auch ein

03:03:53.190 --> 03:03:54.270
Schema definieren oder so, aber

03:03:54.270 --> 03:03:56.930
ja, das

03:03:56.930 --> 03:03:59.090
ist alles nicht so weit wie bei Postgres.

03:03:59.650 --> 03:03:59.750
Ja,

03:04:00.430 --> 03:04:03.190
also genau, das wollte ich auch noch erwähnt haben, dass das halt

03:04:03.190 --> 03:04:04.390
eine schöne Geschichte ist

03:04:04.390 --> 03:04:05.710
an Postgres.

03:04:09.290 --> 03:04:10.990
Ja, ich glaube, langsam haben wir es, ne?

03:04:11.010 --> 03:04:13.090
Und so langsam sind wir dann eigentlich im Grunde...

03:04:13.090 --> 03:04:17.550
Ich habe ja wirklich viel durchgehalten heute, also über drei Stunden, das war schon die Mammut-Folge hier jetzt, also...

03:04:17.550 --> 03:04:21.290
Okay, ja, aber ich bin mal auch gespannt, wie das so ankommt, weil das ist ja jetzt immer so ein bisschen...

03:04:21.290 --> 03:04:25.150
Ist ja jetzt nicht so Einsteiger oder so, sondern das ist einfach mal so komplett durch...

03:04:25.150 --> 03:04:29.010
Ich habe möglicherweise auch eine Menge Unsinn erzählt, das kann leider auch sein, weil das ist halt auch so...

03:04:29.010 --> 03:04:33.210
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,

03:04:33.230 --> 03:04:36.810
hey, wow, ja, da sind einige interessante Gedanken drin, wie sich das so verändert im Laufe der Zeit.

03:04:37.230 --> 03:04:39.190
Ja, ach so, PIX, genau.

03:04:39.450 --> 03:04:39.590
Ja.

03:04:39.710 --> 03:04:42.410
Hast du, du machst, was machst du mit Datenbanken oder welche Sachen?

03:04:42.410 --> 03:04:48.830
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.

03:04:49.350 --> 03:04:54.330
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.

03:04:55.090 --> 03:05:03.690
Das ist auch interessant, ich glaube SQLite ist eine der Software, die mit am weitesten, die weiteste Deploy-Basis hat irgendwie so.

03:05:03.770 --> 03:05:06.230
Ich glaube, es konkurriert noch mit Curl oder so.

03:05:06.230 --> 03:05:08.070
Das wird auch fast überall

03:05:08.070 --> 03:05:10.010
mit drin. Aber ich glaube, SQLite

03:05:10.010 --> 03:05:11.710
ist auch ein Kandidat für das. Das ist fast überall drin.

03:05:11.970 --> 03:05:12.230
Das ist auch

03:05:12.230 --> 03:05:15.550
CoreData, das ist der

03:05:15.550 --> 03:05:17.790
Datenabstraktionslayer von iOS.

03:05:18.750 --> 03:05:19.970
Da ist auch SQLite drunter.

03:05:20.490 --> 03:05:21.850
Das ist in fast allen Browsern drin.

03:05:22.470 --> 03:05:24.310
Das heißt, wenn man einen Browser hat, hat man SQLite.

03:05:24.430 --> 03:05:26.270
Wenn man irgendwie, das ist auf einer

03:05:26.270 --> 03:05:28.450
Apple Watch, ist eine SQLite-Datenbank

03:05:28.450 --> 03:05:30.350
und zählt die Schritte. Das ist echt total krass.

03:05:30.770 --> 03:05:31.990
Also skaliert von

03:05:31.990 --> 03:05:33.830
einer kleinen Uhr zu

03:05:34.630 --> 03:05:36.010
ich glaube momentan das theoretische

03:05:36.010 --> 03:05:37.450
Limit für SQLite sind irgendwie

03:05:37.450 --> 03:05:38.430
144

03:05:38.430 --> 03:05:42.090
Terabyte oder sowas.

03:05:43.270 --> 03:05:43.890
Kriegt man

03:05:43.890 --> 03:05:45.930
schwer voll. Ja, und es gibt

03:05:45.930 --> 03:05:47.670
glaube ich große SQLite-Datenbanken

03:05:47.670 --> 03:05:48.810
tatsächlich da draußen. Also

03:05:48.810 --> 03:05:51.770
das ist ein super interessantes Projekt und

03:05:51.770 --> 03:05:53.910
ja, auch ich glaube, es wurde

03:05:53.910 --> 03:05:55.970
mal vorgeschlagen, für Langzeitarchivierung

03:05:55.970 --> 03:05:57.890
das SQLite-Format zu nehmen, weil es halt so

03:05:57.890 --> 03:05:59.650
von

03:05:59.650 --> 03:06:02.290
irgendeiner Bibliothek

03:06:02.290 --> 03:06:03.770
ach, weil es halt auch

03:06:03.770 --> 03:06:05.890
sich seit Jahren nicht mehr

03:06:05.890 --> 03:06:07.630
geändert hat, das ist relativ schnell und

03:06:07.630 --> 03:06:10.030
ja, SQLite, super cooles Projekt

03:06:10.030 --> 03:06:11.450
und

03:06:11.450 --> 03:06:13.790
im Zusammenhang habe ich, ist auch einer von

03:06:13.790 --> 03:06:15.670
meinen Pics, was man sich vielleicht mal

03:06:15.670 --> 03:06:17.670
angucken kann, ist ein Projekt namens

03:06:17.670 --> 03:06:18.610
Datasette.

03:06:19.670 --> 03:06:21.810
Datasette, die Kassette, also zum Aufrollen noch.

03:06:22.170 --> 03:06:23.770
So wie, genau, und

03:06:23.770 --> 03:06:25.110
und zwar geht es darum, dass halt für so

03:06:25.110 --> 03:06:27.790
Datenjournalismus, es geht darum, dass man

03:06:27.790 --> 03:06:31.690
Datensätze, die irgendwo veröffentlicht

03:06:31.690 --> 03:06:33.630
wurden, wie man die jetzt navigierbar

03:06:33.630 --> 03:06:34.870
macht für Leute, die jetzt nicht

03:06:34.870 --> 03:06:36.850
das in eine Datenbank importieren wollen

03:06:36.850 --> 03:06:38.150
und dann selber Statements schreiben

03:06:38.150 --> 03:06:40.810
und das macht das halt

03:06:40.810 --> 03:06:42.590
und man kann halt CSVs nehmen, die da reinwerfen

03:06:42.590 --> 03:06:44.750
und dann kriegt man halt so auch ein Interface mit

03:06:44.750 --> 03:06:46.530
Faceted Navigation, mit Volltextsuche, weil

03:06:46.530 --> 03:06:48.210
SQLite kann halt Volltextsuche

03:06:48.210 --> 03:06:50.790
und man kann sogar SQL-Statements

03:06:50.790 --> 03:06:52.510
reinschreiben, man kann aber auch das irgendwie über eine Webseite

03:06:52.510 --> 03:06:53.950
navigieren, das ist ziemlich cool

03:06:53.950 --> 03:06:55.910
und

03:06:55.910 --> 03:06:58.690
ja, das wollte ich auf jeden Fall mal

03:06:58.690 --> 03:07:00.470
erwähnt haben, das kann man sich mal

03:07:00.470 --> 03:07:02.230
anschauen, es gibt dann da so Teile

03:07:02.230 --> 03:07:04.470
von, wo man auch CSVs automatisch

03:07:04.470 --> 03:07:06.230
in SQLite-Datenbanken umwandeln kann.

03:07:06.950 --> 03:07:08.850
Auch interessant, dass man da so frei SQL-Statements

03:07:08.850 --> 03:07:10.550
irgendwie eingeben kann. Das geht ja auch kaum.

03:07:10.690 --> 03:07:12.830
Das geht halt deswegen, weil man bei SQLite

03:07:12.830 --> 03:07:14.870
auch sagen kann, oh, das ist jetzt ein Read-Only-Datenbank.

03:07:15.090 --> 03:07:16.910
Und dann kann man halt mit Statements

03:07:16.910 --> 03:07:18.090
nichts mehr kaputt machen.

03:07:20.310 --> 03:07:20.970
Ja, das ist

03:07:20.970 --> 03:07:22.710
halt ein sehr schönes

03:07:22.710 --> 03:07:23.530
Projekt.

03:07:25.310 --> 03:07:25.410
Ja.

03:07:26.890 --> 03:07:28.790
Genau. Auch wie man

03:07:28.790 --> 03:07:30.250
auf Datenbanken von Patent aus zugreift.

03:07:30.730 --> 03:07:31.230
Es gibt so

03:07:31.230 --> 03:07:35.190
Async

03:07:35.190 --> 03:07:36.470
PG als

03:07:36.470 --> 03:07:39.090
asynchroner Datenbank

03:07:39.090 --> 03:07:41.150
Client für Python.

03:07:41.530 --> 03:07:43.510
Das wird noch sehr interessant, also das ist momentan

03:07:43.510 --> 03:07:45.530
noch ein Problem. Also PsychoPG

03:07:45.530 --> 03:07:46.230
ist halt so der

03:07:46.230 --> 03:07:49.590
Standard Postgres Datenbank

03:07:49.590 --> 03:07:51.370
Client für Python und der kann aber nur

03:07:51.370 --> 03:07:53.150
Textprotokoll und nicht Binary.

03:07:53.390 --> 03:07:54.670
Ist halt schon relativ schnell, aber

03:07:54.670 --> 03:07:57.350
es geht halt mit dem Binärprotokoll halt noch

03:07:57.350 --> 03:07:59.110
schneller und er ist halt nicht asynchron.

03:08:00.390 --> 03:08:02.290
Also was halt ein Problem ist, wenn man jetzt zum Beispiel

03:08:02.290 --> 03:08:03.830
bei Postgres, macht man jetzt

03:08:03.830 --> 03:08:06.090
Volltext-Suche und Navigation

03:08:06.090 --> 03:08:08.290
auf einer Webseite, dann hat man,

03:08:08.490 --> 03:08:10.110
wenn man das mit Django macht, Django ist auch synchron,

03:08:10.590 --> 03:08:12.110
dann

03:08:12.110 --> 03:08:13.710
macht man halt einmal

03:08:13.710 --> 03:08:15.610
und hat jetzt Facet Navigation,

03:08:16.010 --> 03:08:18.010
das heißt, man muss halt an den Facetten,

03:08:18.130 --> 03:08:19.730
das heißt Tags oder Kategorien oder

03:08:19.730 --> 03:08:21.390
irgendwelchen anderen

03:08:21.390 --> 03:08:24.390
Monaten oder was auch immer man halt

03:08:24.390 --> 03:08:25.930
navigierbar halten will,

03:08:26.470 --> 03:08:28.290
schreibt man jetzt noch so Counts dran oder man muss halt

03:08:28.290 --> 03:08:30.110
überhaupt wissen, was hat ein Count von größer 0, damit man

03:08:30.110 --> 03:08:31.550
diese Facette anzeigt oder nicht anzeigt.

03:08:32.530 --> 03:08:34.130
Das sind halt zwei unterschiedliche Statements. Man kriegt

03:08:34.130 --> 03:08:36.110
einmal die Suchergebnisse und dann macht man nochmal ein

03:08:36.110 --> 03:08:37.950
Statement, um die Counts zu holen und

03:08:37.950 --> 03:08:40.090
meistens hat man aber nicht nur diese zwei, sondern noch

03:08:40.090 --> 03:08:42.170
ein paar mehr und das ist halt jedes Mal ein Datenbank

03:08:42.170 --> 03:08:44.030
Roundtrip, das ist jedes Mal, dauert das

03:08:44.030 --> 03:08:45.970
irgendwie ein paar Millisekunden, also

03:08:45.970 --> 03:08:47.870
bei den Suchanfragen, bei den Counts dauert es sogar so

03:08:47.870 --> 03:08:50.170
30, 40 Millisekunden, sodass man halt

03:08:50.170 --> 03:08:52.430
bei so einer normalen Navigation

03:08:52.430 --> 03:08:53.530
auf einer Seite

03:08:53.530 --> 03:08:56.070
wahrscheinlich schon so 150 Millisekunden

03:08:56.070 --> 03:08:58.070
nur SQL-Anfragen hat und

03:08:58.070 --> 03:08:59.950
dann ist man schon bei, wenn dann das Template

03:08:59.950 --> 03:09:01.990
gerendert wird, ist man leicht bei 400, 500 Millisekunden

03:09:01.990 --> 03:09:03.970
und das ist halt dann schon relativ lang, das ist

03:09:03.970 --> 03:09:06.030
schon viel für eine Webseite, eigentlich ein bisschen

03:09:06.030 --> 03:09:07.670
zu viel und man könnte es leicht

03:09:07.670 --> 03:09:10.030
deutlich drücken, wenn jetzt diese

03:09:10.030 --> 03:09:12.030
Statements, die ja nicht voneinander abhängen,

03:09:12.070 --> 03:09:14.070
sondern die man auch parallel abfeuern könnte,

03:09:14.130 --> 03:09:15.950
tatsächlich parallel an die Datenbank gestellt

03:09:15.950 --> 03:09:17.010
würden und dann

03:09:17.010 --> 03:09:19.870
hat man nur noch, ist die Latenz

03:09:19.870 --> 03:09:21.910
oder die Zeit, die man

03:09:21.910 --> 03:09:23.890
braucht, um SQL-Abfragen zu machen

03:09:23.890 --> 03:09:25.890
in dem Webfrontend, ist halt

03:09:25.890 --> 03:09:27.610
dauert nur noch so lange wie das längste Statement

03:09:27.610 --> 03:09:29.890
und alle anderen Sachen sind halt vorher da und das würde halt

03:09:29.890 --> 03:09:31.710
wahrscheinlich bedeuten, dass dann ist man runter auf 50

03:09:31.710 --> 03:09:33.570
Millisekunden oder so, dann haben wir 100 Millisekunden gespart.

03:09:33.870 --> 03:09:35.830
Das wäre ziemlich cool. Aber dafür

03:09:35.830 --> 03:09:37.710
müsste halt Django asynchron sein, dafür müsste

03:09:37.710 --> 03:09:38.830
man halt irgendwie

03:09:38.830 --> 03:09:41.030
AsyncPG verwenden statt

03:09:41.030 --> 03:09:43.370
PsychoPG und

03:09:43.370 --> 03:09:45.630
das wird alles noch ein bisschen dauern. Wahrscheinlich Jahre,

03:09:45.810 --> 03:09:47.670
fürchte ich. Ist auch so, dass

03:09:47.670 --> 03:09:49.450
der Autor von Django Channels,

03:09:49.550 --> 03:09:51.130
das ist diese Geschichte mit den

03:09:51.130 --> 03:09:53.810
WebSockets,

03:09:54.410 --> 03:09:55.790
dass man halt bidirektionale

03:09:55.790 --> 03:09:57.750
Kommunikation zwischen Client und Server hat

03:09:57.750 --> 03:09:58.790
bei Web-Anwendungen.

03:09:59.890 --> 03:10:04.250
Und der hat jetzt dieses Projekt so ein bisschen aufgegeben oder ist nicht mehr Maintainer davon.

03:10:05.350 --> 03:10:09.190
Und das, was man jetzt macht, ist jetzt, der versucht Django Async fähig zu machen.

03:10:10.110 --> 03:10:10.870
Bin mal gespannt, wie das wird.

03:10:11.010 --> 03:10:13.250
Das war ja auch in der Django-Folge, hatten wir das ja irgendwie kurz,

03:10:13.430 --> 03:10:17.430
ob das vielleicht eventuell eine Richtung wäre, in die sich Django entwickeln könnte.

03:10:17.570 --> 03:10:20.310
Und ja, sieht danach aus, so ein bisschen, als ob das kommen würde.

03:10:21.310 --> 03:10:24.670
Und damit sind wir im Grunde durch.

03:10:24.670 --> 03:10:26.170
Sind wir durch mit einer Mammut-Folge.

03:10:26.490 --> 03:10:28.210
Wenn ihr es bis hierhin geschafft habt, also gut ab.

03:10:28.430 --> 03:10:29.790
Ich würde jetzt einiges mehr über Daten backen,

03:10:29.850 --> 03:10:30.950
dass man damit alles anstrengen kann.

03:10:31.930 --> 03:10:33.310
Ja, schöne Sache.

03:10:33.790 --> 03:10:34.470
Ja, und dann...

03:10:34.470 --> 03:10:35.410
Super, dass ihr dabei wart.

03:10:35.510 --> 03:10:35.710
Genau.

03:10:36.250 --> 03:10:38.270
Und ja, wo ihr immer hier seid,

03:10:38.310 --> 03:10:39.010
schönen Tag und so weiter.

03:10:39.110 --> 03:10:39.710
Wenn ihr Fragen habt,

03:10:39.770 --> 03:10:40.830
hallo.at.peisenpodcast.de

03:10:40.830 --> 03:10:42.450
Ja, super.

03:10:42.810 --> 03:10:44.170
Ja, dann bis zur nächsten Folge.

03:10:44.430 --> 03:10:44.910
Ja, bis dahin.

03:10:44.990 --> 03:10:45.250
Tschüss.

03:10:45.330 --> 03:10:45.490
Ciao.