WEBVTT

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

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

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

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

00:00:15.320 --> 00:00:19.640
Jo, hallo. Genau, Datenmanken. Ja, voll gut. Da freue ich mich schon drauf.

00:00:19.640 --> 00:00:21.880
Das ist irgendwie ein Thema, mit dem ich schon viel zu tun hatte.

00:00:21.880 --> 00:00:23.420
Das wird wahrscheinlich eine ein bisschen längere Episode.

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

00:00:26.140 --> 00:00:29.580
Wir wissen noch nicht ganz, ob das gelingt. Wir werden wieder hemmungslos abschweifen.

00:00:30.400 --> 00:00:34.180
Wenn ihr Fragen, Anmerkungen dazu habt, Kommentare, Lob, alles, was ihr uns mitteilen wollt,

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

00:00:36.800 --> 00:00:40.680
Und wie immer findet ihr die Links und zusätzliche Infos der Sendung in den Shownotes.

00:00:40.680 --> 00:00:44.420
Ja, wollen wir das eigentlich vielleicht noch erwähnen, welches Datum wir haben?

00:00:44.420 --> 00:00:47.320
Heute ist der 24.02.2019.

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

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

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

00:00:52.620 --> 00:00:54.580
Ja, ich glaube in der ersten. Und dann haben wir es irgendwie nicht mehr gemacht.

00:00:54.580 --> 00:00:57.820
Aber ich glaube, es ist wahrscheinlich eigentlich ganz interessant, wenn man das hört,

00:00:57.820 --> 00:00:59.580
von wann das aufgenommen wurde.

00:01:00.000 --> 00:01:01.460
Ja, stimmt. Ende Februar 19.

00:01:01.460 --> 00:01:04.500
Und es ist gerade ganz gutes Wetter und es ist ein Sonntag.

00:01:04.500 --> 00:01:05.040
Ja.

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

00:01:06.800 --> 00:01:09.400
Heute ausnahmsweise mal nach dem Brunchen.

00:01:09.400 --> 00:01:10.760
War irgendwie super lecker.

00:01:10.760 --> 00:01:15.700
Ja, ich würde sagen, wir steigen fast direkt ins Thema ein.

00:01:15.700 --> 00:01:19.300
Und es geht halt so ein bisschen darum, ja, das ist glaube ich nicht das erste Mal,

00:01:19.300 --> 00:01:21.960
dass wir versuchen, so eine Folge mit Datenbanken zu strukturieren.

00:01:21.960 --> 00:01:25.280
Das war auch der Grund, warum wir so ein bisschen länger auf die letzte Folge warten mussten.

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

00:01:27.080 --> 00:01:29.840
Ja, was ist überhaupt so eine Datenbank, Jochen?

00:01:30.000 --> 00:01:33.100
Und wir versuchen halt immer wieder, euch vielleicht kurz zu erklären,

00:01:33.100 --> 00:01:35.680
was man damit noch mit Python machen kann oder welche Module es dafür gibt.

00:01:35.680 --> 00:01:37.540
Aber das vielleicht mal als Warnung.

00:01:37.540 --> 00:01:40.480
Python kommt in dieser Folge nicht nur vor und nicht ganz so viel,

00:01:40.480 --> 00:01:42.820
sondern es geht halt tatsächlich darum, wie man das, was man mit Python macht,

00:01:42.820 --> 00:01:46.800
also die Datenbanknutzung, so ein bisschen euch erklären, näher bringen kann.

00:01:46.800 --> 00:01:51.160
Ja, wobei ich denke, dass das halt eigentlich für alle, die Python entwickeln wollen,

00:01:51.160 --> 00:01:55.800
ein interessantes Thema ist, weil da wird man, egal in welchem Bereich man sich da tummelt,

00:01:55.800 --> 00:01:58.680
nicht drumherum kommen, irgendwann etwas mit Datenbanken zu machen.

00:01:59.800 --> 00:02:03.560
Und ja, dafür muss man sich halt dann auch nicht nur mit Python auskennen,

00:02:03.560 --> 00:02:06.180
sondern muss halt auch so ein bisschen verstehen, wie das mit den Datenbanken funktioniert.

00:02:06.180 --> 00:02:08.380
Und man kann halt nicht viel interessante Dinge machen,

00:02:08.380 --> 00:02:10.740
wenn man halt von Datenbanken da gar nichts versteht.

00:02:10.740 --> 00:02:12.780
Und insofern, ja.

00:02:12.780 --> 00:02:14.680
Ja, wir werden noch ein bisschen darauf eingehen, was ist das überhaupt, ne?

00:02:14.680 --> 00:02:17.940
Datenbanken, Unterschiede in einzelnen Datenbanktypen, ein bisschen darstellen.

00:02:17.940 --> 00:02:21.880
Und wir wollen anhand eines kleinen Beispiels euch so ein bisschen so die Problematiken beim Skalieren

00:02:21.880 --> 00:02:24.660
und bei dem Arbeiten mit der Datenbank erklären.

00:02:24.660 --> 00:02:25.540
Genau.

00:02:25.540 --> 00:02:29.280
Und da haben wir uns gedacht, nehmen wir einfach irgendwie etwas, was man halt kennt.

00:02:29.600 --> 00:02:30.880
Ich meine, wozu ist das Internet da?

00:02:30.880 --> 00:02:32.580
Irgendwie Dinge einkaufen, klar, weiß man ja.

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

00:02:35.080 --> 00:02:38.640
Und genau, Amazon hat bestimmt die da schon mal benutzt und weiß halt, wie das funktioniert.

00:02:38.640 --> 00:02:42.940
Und das ist halt eigentlich, denke ich, ein ganz gutes Beispiel für, wofür braucht man eigentlich Datenbanken?

00:02:42.940 --> 00:02:46.780
Weil die haben wahrscheinlich auch für fast alle Datenbanktypen irgendwie eine Anwendung.

00:02:46.780 --> 00:02:50.080
Und daran kann man das vielleicht ganz gut erklären.

00:02:50.080 --> 00:02:52.320
Ja, dann vielleicht fangen wir erstmal einfach an.

00:02:52.320 --> 00:02:55.160
Also mit was würde man einfacherweise anfangen?

00:02:55.160 --> 00:02:59.400
Wenn man jetzt Python hat, möchte Daten haben, man könnte ja einfach so ein Dictionary jetzt nehmen oder sich eine

00:02:59.400 --> 00:03:02.520
Liste erstellen und da irgendwie über Indizes iterieren.

00:03:02.520 --> 00:03:04.560
Dann hätte man ja sowas wie einen kleinen Datensatz schon mal.

00:03:04.560 --> 00:03:09.100
Ja, wenn man das Ganze jetzt mit etwas komplizierteren Daten braucht.

00:03:09.100 --> 00:03:11.840
Wir hatten eben, glaube ich, im Vorgespräch ganz kurz über Struktur gesprochen.

00:03:11.840 --> 00:03:14.600
Da gibt es eine Struktur, die man sich ausdenken muss.

00:03:14.600 --> 00:03:15.700
Das ist gar nicht so trivial.

00:03:15.700 --> 00:03:20.640
Das ist recht wichtig, dass man da so ein bisschen mehr Gedanken dazu macht.

00:03:20.640 --> 00:03:22.920
Wie sieht denn meine Struktur der Daten überhaupt aus?

00:03:22.920 --> 00:03:24.180
Und was soll ich denn damit machen?

00:03:24.180 --> 00:03:26.620
Wie würdest du da direkt vorgehen?

00:03:26.620 --> 00:03:29.360
Ja, also das ist halt, das kommt tatsächlich.

00:03:29.360 --> 00:03:35.200
Auf den Anwendungsfall an und was ich halt in der Praxis im letzten Jahrzehnten so durchgesetzt

00:03:35.200 --> 00:03:36.520
hat, sind relationale Datenbanken.

00:03:36.520 --> 00:03:41.460
Aber es gibt halt auch diverse andere Arten von Datenbanken und die haben alle so ihre

00:03:41.460 --> 00:03:42.220
Berechtigung.

00:03:42.220 --> 00:03:46.880
Alle, die das noch nicht drauf haben, also so SQL oder NoSQL.

00:03:46.880 --> 00:03:48.380
Ja, genannt oft.

00:03:48.380 --> 00:03:49.340
Ja, genau.

00:03:49.340 --> 00:03:52.240
Und ja, es hängt halt davon ab.

00:03:52.240 --> 00:03:57.820
Also man kann natürlich auch einfach Objekte, Python-Objekte nehmen, die irgendwie serialisieren.

00:03:57.820 --> 00:03:58.280
Nennt man das?

00:03:58.280 --> 00:03:59.320
Also zum Beispiel gibt es da in der Steine.

00:03:59.320 --> 00:04:03.440
In der Bibliothek das Pickle-Modul für, was halt aus einem Python-Objekt, das irgendwie

00:04:03.440 --> 00:04:08.780
beliebig aussehen kann, macht das halt eine String- oder Byte-Repräsentation.

00:04:08.780 --> 00:04:12.960
Also eine Serialisierung ist tatsächlich irgendwie die Darstellung als Zeichenkette

00:04:12.960 --> 00:04:18.200
oder Byte-Strecke, damit man die übertragen kann über einen Kanal oder sowas.

00:04:18.200 --> 00:04:18.660
Ja, genau.

00:04:18.660 --> 00:04:19.580
Das nennt man Serialisierung.

00:04:19.580 --> 00:04:22.580
Ist auch im Kontext von Datenbanken eine sehr wichtige Geschichte.

00:04:22.580 --> 00:04:29.280
Und man könnte jetzt zum Beispiel diese Byte-Folgen oder Strings nehmen und die String-Folgen

00:04:29.280 --> 00:04:33.860
halt zahlenweise in einen Pfeil reinschreiben und dann hinterher auch wieder auslesen.

00:04:33.860 --> 00:04:37.880
Also man nimmt einfach zum Beispiel, wenn man jetzt den State von irgendeinem Programm

00:04:37.880 --> 00:04:42.460
speichern möchte, nimmt man einfach alle Objekte, die man jetzt so findet oder die man sich

00:04:42.460 --> 00:04:48.340
irgendwo gemerkt hat, dass man sie hat und serialisiert die halt in Pfeilen, schreibt

00:04:48.340 --> 00:04:49.160
das Ganze in einen Pfeil.

00:04:49.160 --> 00:04:53.220
Genau so habe ich das auch bei meiner ersten versuchten Datenbank-Operation selber gemacht,

00:04:53.220 --> 00:04:54.840
nämlich einfach so die Daten, die ich hatte.

00:04:54.840 --> 00:04:58.760
Es ging da um so Spielerdaten aus dem Sport, habe ich einfach alle Informationen über

00:04:58.760 --> 00:04:59.100
einen Spieler in einem Spiel.

00:04:59.100 --> 00:04:59.120
Und dann habe ich das Ganze in einem Spiel.

00:04:59.120 --> 00:04:59.160
Und dann habe ich das Ganze in einem Spiel.

00:04:59.160 --> 00:04:59.200
Und dann habe ich das Ganze in einem Spiel.

00:04:59.200 --> 00:04:59.260
Und dann habe ich das Ganze in einem Spiel.

00:04:59.280 --> 00:05:01.740
Und dann habe ich das Ganze in eine Zeile gepackt und die zahlenweise in eine Datei

00:05:01.740 --> 00:05:02.120
reingeschrieben.

00:05:02.120 --> 00:05:03.080
Genau.

00:05:03.080 --> 00:05:08.200
Und dann, wenn man jetzt den Status wiederherstellen will des Programms, wenn man das startet,

00:05:08.200 --> 00:05:11.900
dann nimmt das einfach die Datei, liest alles wieder ein und dann ist das im gleichen Zustand

00:05:11.900 --> 00:05:13.080
wie vorher.

00:05:13.080 --> 00:05:18.120
Und genau, wenn man das mit Python-Objekten macht, dann ist es halt nicht mehr menschenlesbar.

00:05:18.120 --> 00:05:23.220
Aber man kann das halt genauso machen, indem man halt CSV schreibt oder sowas halt.

00:05:23.220 --> 00:05:26.460
Dann wäre es halt noch menschenlesbar.

00:05:26.460 --> 00:05:29.200
Da muss man sich halt überlegen, wie man die CSV.

00:05:29.200 --> 00:05:33.460
in Objekte verwandelt oder Objekte wieder in CSV-Zeilen.

00:05:33.460 --> 00:05:37.480
Ich habe einfach den Dictionary-Code in eine Teile reingeschrieben, habe das dann ausgelesen und evaluiert.

00:05:37.480 --> 00:05:40.540
Das war wahrscheinlich nicht die beste Methode, das zu tun, aber funktioniert hat es trotzdem.

00:05:40.540 --> 00:05:41.340
Genau.

00:05:41.340 --> 00:05:45.960
Und wenn man sowas macht, das wurde am Anfang irgendwie bei Web-Entwicklung auch häufig gemacht.

00:05:45.960 --> 00:05:49.680
Das nannte sich dann Flat-Files, Datenbank mit Flat-Files.

00:05:49.680 --> 00:05:52.940
Man hat einfach den State da irgendwie rein.

00:05:52.940 --> 00:05:56.000
Und natürlich ist auch das File-System ja schon irgendwie eine Art Datenbank.

00:05:56.000 --> 00:05:59.100
Das ist halt eine hierarchische Datenbank, die halt so eine Baumstruktur hat.

00:05:59.200 --> 00:06:09.020
Und deren Blätter halt Files sind, Wurzel ist halt Root/ bei Unix-Systemen oder bei Windows ist es irgendwie was komisches mit dem Laufwerksbuchstaben.

00:06:09.020 --> 00:06:13.140
Und ja, das ist natürlich auch eine Struktur.

00:06:13.140 --> 00:06:20.580
Man hat halt irgendwie darüber die Verzeichnis-Lese, die es da gibt, auch schon so Metadaten definiert, dass man halt weiß, so bestimmte Sachen sind halt in bestimmten Verzeichnissen so.

00:06:20.580 --> 00:06:29.020
Und das Ganze gibt es halt auch über Netzwerk-Geschichten, indem man das so hierarchisch, die bekannteste hierarchische Datenbank im Netz.

00:06:29.120 --> 00:06:35.240
Das ist halt so was wie LDAP, Windows nennt das irgendwie Active Directory oder ist auch vielleicht noch ein bisschen komplizierter.

00:06:35.240 --> 00:06:41.060
Und ja, das ist halt schon mal eine grundsätzliche Art, wie man wie man Datenbanken betreiben kann.

00:06:41.060 --> 00:06:57.640
Aber vielleicht etwas, was ich mich ganz gerne auch noch mal einsetzen würde, ist, wie Leute, also wenn man jetzt sich überlegt, wo könnten Leute etwas, das man sonst vielleicht mit Datenbanken tun könnte, irgendwie schon mal gesehen haben?

00:06:57.640 --> 00:06:58.840
Oder was machen viele Leute?

00:06:59.040 --> 00:07:23.060
Und wenn das halt eigentlich auch gut in den Datenbank-Kontext passt, dann würde ich vielleicht sogar eher mit sowas wie Excel oder so anfangen, weil das wird dann oft so scherzhaft auch erwähnt, wenn man sich überlegt, was ist die meisten verwendete, meisten ausgerollte Datenbank-Lösung der Welt, dann könnte man auch sagen, das ist halt Excel, weil viele Leute halt Excel quasi als Datenbank benutzen.

00:07:23.060 --> 00:07:27.000
Allen möglichen Quatschen, irgendwelche Spalten und Teilen reinschreiben und ganz, ganz, ganz, ja.

00:07:28.960 --> 00:07:57.880
Das ist, genau, das ist halt eigentlich, ach so, und vielleicht sollte man sich erstmal grundsätzlich überlegen, stimmt, wenn man schon so anfängt zu erklären, was Datenbanken sind, was ist denn eigentlich Daten, was sind eigentlich Informationen, was sind eigentlich Wissen, da hört man umgangssprachliche Definitionen, die halt, wo man dann weiß, was das ungefähr sein soll, aber wenn man das jetzt aus dem Datenbank-Kontext her präzisieren möchte, dann geht das eigentlich auch relativ schmerzlos, also Daten sind halt sowas wie, also ein Datum wäre,

00:07:58.880 --> 00:08:08.880
irgendwas mit minus 3,5, wäre jetzt ein Datum, einfach nur ein Zahlenwert oder so, und das sagt einem halt natürlich noch nichts.

00:08:08.880 --> 00:08:11.800
Weil es ja kein Bezug dafür ist, minus 3,5, was denn?

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

00:08:12.660 --> 00:08:14.340
Grad Fahrenheit, ne?

00:08:14.340 --> 00:08:28.800
Und, ja, wenn man jetzt von Informationen spricht, dann spricht man von Daten, die halt schon so ein bisschen Kontext haben, also sowas wie minus 3,5 Grad Temperatur, das heißt, man weiß halt, das steht jetzt in der Temperaturspeise,

00:08:28.800 --> 00:08:44.860
und damit weiß man schon mal so ein bisschen, worum es da überhaupt geht, und dann nimmt man das Informationen, und das, was man aber eigentlich in Datenbanken speichern möchte, und dann was machen möchte, das ist irgendwie so Wissen, Begriff dafür ist Wissen,

00:08:44.860 --> 00:08:56.840
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:58.720 --> 00:09:06.680
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:06.680 --> 00:09:10.540
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.400 --> 00:09:24.100
Ja, genau, und dann kann man halt, wenn man Abfragen daran stellt, dann halt Schlussfolgerungen daraus ziehen, und dann vielleicht Dinge vorhersagen, oder halt auch einfach bestimmte Fragen beantwortet bekommen, die einen interessieren.

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

00:09:28.640 --> 00:09:33.760
Ja, genau, das ist das, wofür man eigentlich Datenbanken verwenden möchte.

00:09:33.760 --> 00:09:38.060
Oh, da kann man auch Analysen irgendwann machen. Das ist aber dann, glaube ich, wieder ein neues Thema, wie man Analysen dann mit Daten fährt.

00:09:38.060 --> 00:09:39.220
Die werden wir heute, glaube ich, nicht machen.

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

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

00:09:42.120 --> 00:09:48.800
Okay, ihr müsst heute lange, lange Geduld mitbringen, oder eine große Runde durch den Park, oder ihr könnt gerne zur Wohnung putzen, heute.

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

00:09:51.580 --> 00:09:58.540
Aber ja, ich denke, das ist eigentlich vielleicht ganz interessant, mal so einen groben Überblick, also ich versuche dann zu verhindern,

00:09:58.560 --> 00:10:04.980
zu sehr ins Detail zu gehen, aber wenn man einfach mal so das Gesamtthema Datenbanken mal überblickt hat.

00:10:04.980 --> 00:10:09.240
Ja, ich halte ich so ungern davon ab, so ins Detail zu gehen, weil ich finde das unheimlich interessant, was da alles noch so drinter steckt.

00:10:09.240 --> 00:10:14.140
Ich bin ja sehr curious, was man noch alles so findet und die Details sind halt auch irgendwie wichtig, ja.

00:10:14.140 --> 00:10:18.500
Ja, stimmt. Wir schauen einfach mal. Ich hoffe mal, dass es nicht allzu lang wird, aber.

00:10:18.500 --> 00:10:22.800
Okay, ja, dann fangen wir doch direkt mal mit dem Beispiel an, oder wolltest du noch so ein paar grundsätzliche Dinge über Daten?

00:10:22.800 --> 00:10:27.800
Einmal grundsätzlich darüber, was gibt es für unterschiedliche Arten von Datenbanken, auch um halt dann, ja,

00:10:28.480 --> 00:10:34.500
ja, um darauf dann wieder Bezug nehmen zu können in dem Beispiel und vielleicht auch das, was halt sich jetzt durchgesetzt hat.

00:10:34.500 --> 00:10:44.320
Jedenfalls, das ist halt eben hierarchische Datenbanken, gab es schon ganz lange und ja, Sachen in Flatfiles oder irgendwie strukturierten Dateien hat man auch schon lange.

00:10:44.320 --> 00:10:58.400
Und dann irgendwann 1971, glaube ich, ist ein Paper rausgekommen von Ted Kott und der hat sich halt Gedanken darüber gemacht, wie man eigentlich dieses Problem, ich möchte wissen, irgendwie speichern und dann irgendwie

00:10:58.400 --> 00:11:23.820
Dinge damit später machen, wie man das so grundsätzlich angehen sollte und dessen Idee war halt, also ein Problem, was er gesehen hat mit den bisherigen Ansätzen war, dass viele Leute Zeit damit verbracht haben, die Daten, die sie halt schon auch irgendwie strukturiert, aber halt im eigenen Format in Dateien gespeichert haben, da Algorithmen für zu schreiben, wie die jetzt abzufragen sind.

00:11:23.820 --> 00:11:28.380
Also, wenn man jetzt eben so eine Frage beantwortet haben möchte, wie, keine Ahnung.

00:11:28.380 --> 00:11:43.580
Wie viel, was war denn jetzt die Stadt, in der es letztes Jahr am kältesten war in Deutschland oder so, dann fingen Leute an, dann Algorithmen zu schreiben, die für die Art, wie sie die Daten gespeichert hatten, halt, ja, das Problem gelöst haben, genau.

00:11:43.580 --> 00:11:49.780
Und jeder, der halt die Daten irgendwie anders speichert, muss sich halt einen neuen Algorithmus überlegen, wie er das macht.

00:11:49.780 --> 00:11:58.360
Und das ist ja eigentlich ziemlich blöde, also das wäre irgendwie schlauer, wenn man das standardisieren könnte und also nicht...

00:11:58.360 --> 00:12:23.060
...sich überlegt, welchen Algorithmus oder einen Algorithmus zu schreiben, der halt das irgendwie abfragt, sondern zu beschreiben, was man haben möchte und dann irgendeine Art von Datenbank-Management-System, das dann halt weiß, wie man irgendwie diverse Arten von Indizes baut oder so, dem diese formalisierte Anfrage vorzulegen und das Ding sucht sich dann die beste Art, wie man das dann löst raus und macht das dann für einen.

00:12:23.060 --> 00:12:28.060
Und damit das alles gut geht, muss man halt die Daten auch in einem bestimmten Format...

00:12:28.360 --> 00:12:31.220
...speichern und man sollte die halt in Form von Relationen speichern.

00:12:31.220 --> 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.320 --> 00:12:45.460
Weil in unterschiedlichen Spalten oder Zahlen irgendwie unterschiedliche Dinge drinstehen, die dann nicht zu suchen haben, oder?

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

00:12:48.360 --> 00:12:51.460
Oh, jetzt kommen wir direkt mit den Normalisierungen, ja.

00:12:51.460 --> 00:12:58.340
Weil es nicht wirkliche Beziehungen zwischen Tabellen gibt und das in Datenbanken gibt es halt alles schon.

00:12:58.340 --> 00:13:06.080
Und da gibt es dann auch bestimmte Regeln und Constraints irgendwie überprüft und so.

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

00:13:08.020 --> 00:13:08.560
Genau, genau.

00:13:08.560 --> 00:13:11.240
Ja, und das wird in Excel halt alles nicht gemacht.

00:13:11.240 --> 00:13:18.000
Und ja, das ist halt, das ist in der Praxis ein relativ großes Problem, denke ich.

00:13:18.000 --> 00:13:22.800
Das ist halt, ich habe das, auf den kommen wir später noch zurück vielleicht.

00:13:22.800 --> 00:13:27.800
Der heißt Simon Willison, der hat für den Guardian...

00:13:28.340 --> 00:13:32.880
Vor zehn Jahren ungefähr irgendwie so im Bereich Datenjournalismus irgendwie, da gab es das schon.

00:13:32.880 --> 00:13:36.680
Heute ist das ein großes Thema, aber damals hat das irgendwie keinen so richtig interessiert gearbeitet.

00:13:36.680 --> 00:13:43.100
Und der ist halt eher so, hat was mit Datenbanken da zu tun.

00:13:43.100 --> 00:13:49.140
Und da gab es schon jemanden, der sich damit beschäftigt hat, also von der Zeitung her.

00:13:49.140 --> 00:13:55.440
Wenn es ein Artikel über irgendein Thema Arbeitslosigkeit oder keine Ahnung, irgendwas wirtschaftliche Themen irgendwie ging.

00:13:55.440 --> 00:13:58.320
Wenn man da Schaubilder und Diagramme reinmachen wollte.

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

00:14:00.200 --> 00:14:03.920
Und er kannte irgendwie in allen Institutionen Leute, die er nach diesen Daten fragen konnte.

00:14:03.920 --> 00:14:05.980
Wusste, wo man die bekommt und so, super.

00:14:05.980 --> 00:14:15.460
Aber das Problem ist jetzt, also der Simon Willison, also er aus der Programmiererecke,

00:14:15.460 --> 00:14:17.980
wollte halt die Daten auch anders noch zugänglich machen.

00:14:17.980 --> 00:14:21.460
Und wollte halt gucken, ob man da nicht übergreifend irgendwelche Anfragen stellen kann.

00:14:21.460 --> 00:14:25.640
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:28.300
Und der sagte so, oh ja, ich habe da hier irgendwie ein paar tausend.

00:14:28.300 --> 00:14:29.340
Excel-Files auf meinem Desktop.

00:14:29.340 --> 00:14:31.100
Und da sind die halt drin.

00:14:31.100 --> 00:14:34.140
Und ich weiß halt, in welchen Daten, in welchen Files.

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

00:14:36.120 --> 00:14:41.720
Und ich glaube, das ist tatsächlich eine Situation, die in vielen Unternehmen so ist oder so.

00:14:41.720 --> 00:14:46.420
Dass man halt dann Experten hat dafür, für diese Domänen.

00:14:46.420 --> 00:14:47.820
Die Menschen aus dem Archiv.

00:14:47.820 --> 00:14:51.980
Ja, die aber dann nicht unbedingt jetzt so Datenmarktspezialisten sind.

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

00:14:54.160 --> 00:14:57.160
Aber das funktioniert halt nicht gut, weil...

00:14:58.300 --> 00:15:02.760
Man kann darüber jetzt keine übergreifenden Anfragen stellen.

00:15:02.760 --> 00:15:04.920
Dann hat man auch so ein Problem, wenn man mit Leuten zusammenarbeitet.

00:15:04.920 --> 00:15:09.780
Ja, wie ist das eigentlich, wenn mehrere Leute das jetzt ändern?

00:15:09.780 --> 00:15:14.220
Dann gibt es auch wieder so komische Strategien, wie man hat das dann irgendwie auf einem Netzwerk-Share.

00:15:14.220 --> 00:15:16.480
Und dann muss man sich irgendwie Bescheid sagen, wenn man das ändert.

00:15:16.480 --> 00:15:20.200
Oder man macht das irgendwie über komisch benannte Dateinamen oder sowas.

00:15:20.200 --> 00:15:22.920
Und das ist natürlich alles total furchtbar.

00:15:22.920 --> 00:15:28.020
Also man benutzt dann im Grunde zwei Datenbanken, die nicht wirklich dafür geeignet sind,

00:15:28.020 --> 00:15:28.280
was man dann macht.

00:15:28.280 --> 00:15:31.680
Nämlich einmal das Filesystem, um halt so eine Art Versionskontrolle zu machen.

00:15:31.680 --> 00:15:35.220
Und dann Excel als Datenbank, was halt auch nicht dafür geeignet ist.

00:15:35.220 --> 00:15:39.120
Und dann macht man sich das Leben sehr, sehr schwer.

00:15:39.120 --> 00:15:41.540
Obwohl es deutlich einfacher sein könnte.

00:15:41.540 --> 00:15:49.360
Und ja, das sind aus meiner Perspektive auch so die beiden Dinge, wo man...

00:15:49.360 --> 00:15:50.440
Wenn man Daten organisieren möchte.

00:15:50.440 --> 00:15:54.980
Wenn man in Firmen so leichte Gewinne, die man machen könnte.

00:15:54.980 --> 00:15:57.980
Also die beiden Themen, die halt vollkommen unter...

00:15:58.280 --> 00:16:03.400
Unterschätzt sind, aus meiner Perspektive, sind einmal Versionskontrolle.

00:16:03.400 --> 00:16:07.500
Also das sehe ich ganz oft, dass halt jetzt...

00:16:07.500 --> 00:16:11.340
Also bei Programmierern, die wissen inzwischen, wie das funktioniert und machen das halt auch.

00:16:11.340 --> 00:16:14.760
Und bei denen ist halt Verständnis, was jetzt Git ist und wie man das verwendet,

00:16:14.760 --> 00:16:16.780
irgendwie durchaus angekommen.

00:16:16.780 --> 00:16:18.580
Immer bitte den Git-Flow.

00:16:18.580 --> 00:16:18.880
Ja.

00:16:18.880 --> 00:16:26.180
Aber in den meisten anderen Abteilungen, wo es nicht um Programmieren geht,

00:16:26.180 --> 00:16:28.220
die haben von solchen Dingen noch nie irgendwas gehört.

00:16:28.280 --> 00:16:32.280
Da nimmt man Tipp-X und mal da kurz die Buchstaben, die falsch sind, raus und malt dann da drüber.

00:16:32.280 --> 00:16:35.100
Und wenn man wüsste, was da vorher stand, dann muss man das Tipp-X abkasten.

00:16:35.100 --> 00:16:38.280
Ja, die wissen halt vielleicht, wie sie ihre Programme bedienen oder so.

00:16:38.280 --> 00:16:40.380
Aber die wissen gar nicht, dass sowas geht.

00:16:40.380 --> 00:16:41.820
Und wissen gar nicht, wie das geht.

00:16:41.820 --> 00:16:46.500
Und machen dann sehr umständlich das, was ihnen arbeitet.

00:16:46.500 --> 00:16:48.860
Sehr fehleranfällig, die ihnen Git oder...

00:16:48.860 --> 00:16:52.400
Tabelle 1, Tabelle 1 neu, Tabelle 1 neu, neu, neu, final.

00:16:52.400 --> 00:16:54.100
Und ja, jetzt jetzt wirklich.

00:16:54.100 --> 00:16:58.100
Also da könnte man mit wenig Aufwand...

00:16:58.280 --> 00:16:58.600
Reichen.

00:16:58.600 --> 00:17:04.280
Und eben auch da irgendwie, wenn man Daten speichert und halt auch...

00:17:04.280 --> 00:17:08.980
Man hat ja in Excel dann oft nicht nur Daten, sondern man hat dann Daten und Logik,

00:17:08.980 --> 00:17:12.840
weil man jetzt irgendwelche Reports erzeugt für irgendwie ein Management-Layer oder so.

00:17:12.840 --> 00:17:18.880
Und dann ist das viel Handarbeit, wo im Grunde man, wenn man jetzt ein bisschen...

00:17:18.880 --> 00:17:21.700
Ich habe das gerade gehört, das war gerade ein super kurzer kleiner Nebensatz.

00:17:21.700 --> 00:17:24.560
Wenn man kurz irgendwelche Daten erzeugt, so für den Management-Layer.

00:17:24.560 --> 00:17:28.140
Ja, das ist, denke ich, in Grundform viel.

00:17:28.140 --> 00:17:33.960
Wenn die Leute da so Excel mit irgendwelchen Makros drin oder irgendwelche Skript-Schnipseln drin haben, warum die das verwenden.

00:17:33.960 --> 00:17:39.300
Ja, das Problem ist halt, das funktioniert meistens und dann funktioniert es irgendwann nicht mehr oder die Daten ändern sich.

00:17:39.300 --> 00:17:43.700
Und dann muss man halt irgendwie einen Teil von einem VBA-Skript oder so irgendwie so ein bisschen anpassen.

00:17:43.700 --> 00:17:45.420
Und dann geht was an der anderen Stelle kaputt.

00:17:45.420 --> 00:17:49.900
Und dann ist es auch so, dass man oft Sachen von Hand gefixt hat.

00:17:49.900 --> 00:17:51.700
Also irgendwelche Werte sind halt nicht so, wie sie sein sollen.

00:17:51.700 --> 00:17:53.760
Und bei Excel klickt man 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.560 --> 00:17:57.980
Und dann kommen jetzt neue Daten rein.

00:17:58.020 --> 00:17:58.880
Die sind wieder falsch.

00:17:58.880 --> 00:18:00.140
Und dann muss man es wieder ändern.

00:18:00.140 --> 00:18:01.520
Oder es geht halt kaputt oder so.

00:18:01.520 --> 00:18:05.920
Und das ist einfach so aus einer Programmierersicht nicht so das, was man tun sollte.

00:18:05.920 --> 00:18:08.520
Das geht man dann mit Stunden, um Stunden, um Stunden, um Stunden.

00:18:08.520 --> 00:18:13.480
Genau, aus Programmierersicht ist es so, wenn ich da irgendwie was ändere, dann ist das halt irgendwie Programmlogik.

00:18:13.480 --> 00:18:16.880
Und wenn dann neue Daten reinkommen, dann wird die halt genauso angewendet.

00:18:16.880 --> 00:18:18.120
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:27.900
Und ja, es gibt auch ganz in VBAs natürlich noch so ein...

00:18:27.900 --> 00:18:28.960
Extra-Problem.

00:18:28.960 --> 00:18:30.880
Das soll übrigens bei Python gehen, habe ich gehört.

00:18:30.880 --> 00:18:34.240
Ja, ich weiß, dass bei Microsoft gibt es irgendwie so ein...

00:18:34.240 --> 00:18:37.140
Die haben da auch so ein Priorisierungstool sozusagen.

00:18:37.140 --> 00:18:38.180
Ich weiß nicht genau, was das ist.

00:18:38.180 --> 00:18:42.660
Und ich glaube, das meiste nach Requested Feature ist es, VBA durch Python zu ersetzen.

00:18:42.660 --> 00:18:44.940
Mit irgendwie tausenden Upvotes.

00:18:44.940 --> 00:18:50.340
Aber ich glaube, definitiv dazu geäußert, ob das irgendwie dann kommt, hat sich da auch noch niemand.

00:18:50.340 --> 00:18:53.420
Aber das wäre natürlich auch eine interessante Geschichte.

00:18:53.420 --> 00:18:57.780
Aber man hat auch bei Python dann immer noch das Problem, was man halt wahrscheinlich...

00:18:57.780 --> 00:19:01.060
eigentlich nicht machen können wird, ist sowas wie mit PIP irgendwie Dinge nachinstallieren oder so.

00:19:01.060 --> 00:19:04.300
Selbst wenn es mit Python jetzt die VBA ersetzen würde.

00:19:04.300 --> 00:19:08.160
Gut, man hätte schon den Vorteil natürlich, dass die Standard-Bibliothek von Python sehr viel mächtiger ist,

00:19:08.160 --> 00:19:11.400
als das, was VBA kann.

00:19:11.400 --> 00:19:13.980
Aber es ist halt immer noch nicht...

00:19:13.980 --> 00:19:18.820
Also es gibt diverse Probleme, die noch gelöst werden müssten, damit das alles wirklich smooth ist.

00:19:18.820 --> 00:19:22.280
Und das Grundproblem ist natürlich, dass Excel das vollkommen ungeeignete Tool ist für vieles,

00:19:22.280 --> 00:19:23.320
was da in dem Bereich gemacht wird.

00:19:23.320 --> 00:19:25.940
Ja, aber genau.

00:19:27.660 --> 00:19:32.360
Also eigentlich wäre das, was viele Leute damit machen,

00:19:32.360 --> 00:19:36.760
die wären viel besser bedient, wenn sie halt Python nehmen würden und eine relationale Datenbank.

00:19:36.760 --> 00:19:42.020
Und weil die eben diese ganzen Geschichten auch löst.

00:19:42.020 --> 00:19:45.040
Da gibt es dann halt, wenn da mehrere Leute drauf zugreifen und Dinge ändern,

00:19:45.040 --> 00:19:48.560
dann sorgt die Datenbank dafür, oder das Datenbank-Management-System,

00:19:48.560 --> 00:19:53.740
dass da nichts schief geht, dass alle Leute immer die gleichen Daten sehen,

00:19:53.740 --> 00:19:55.280
jedenfalls innerhalb von einer Transaktion und so.

00:19:57.540 --> 00:20:02.960
Und da gibt es auch die ganze Zugriffskontrolle und all das ist alles schon fertig implementiert.

00:20:02.960 --> 00:20:11.580
Und ja, das ist halt so das, was Leute im Grunde verstehen, wenn man von Datenbanken spricht, denke ich.

00:20:11.580 --> 00:20:16.240
Aber es gibt halt auch noch eine ganze Menge anderer Datenbanken.

00:20:16.240 --> 00:20:22.100
Und dass sich relationale Datenbanken so durchgesetzt haben, ist auch aus meiner Perspektive ein Stück weit Glück.

00:20:22.100 --> 00:20:24.560
Oder hängt halt an der Geschichte von einzelnen Firmen.

00:20:24.560 --> 00:20:27.420
Also man hätte sich auch durchaus vorstellen können, dass sich andere Paradigmen durchgesetzt haben.

00:20:27.420 --> 00:20:29.680
Hätten, haben sie aber irgendwie nicht.

00:20:29.680 --> 00:20:35.180
Und jetzt sind halt so relationale Datenbanken das, was alle irgendwie verwenden.

00:20:35.180 --> 00:20:37.980
Aber es ist auch gar nicht so ein schlechter Ansatz.

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

00:20:40.820 --> 00:20:42.420
Aber nur mal so um...

00:20:42.420 --> 00:20:44.460
Der Vollständigkeit halber, ja.

00:20:44.460 --> 00:20:46.800
Ja, der Vollständigkeit halber, um mal zu sagen, was es sonst noch alles gibt.

00:20:46.800 --> 00:20:49.420
Es gibt halt Dokumentendatenbanken.

00:20:49.420 --> 00:20:51.320
Ja, gibt es auch schon ganz lange.

00:20:51.320 --> 00:20:57.300
LotusNotes ist ja so ein Beispiel für...

00:20:57.300 --> 00:20:57.760
Populär.

00:20:57.760 --> 00:21:06.320
CouchDB, MongoDB, die fallen auch in diesen Dokumentendatenbank-Bereich rein.

00:21:06.320 --> 00:21:07.820
Lösen halt so ein bisschen unterschiedliche Probleme.

00:21:07.820 --> 00:21:18.120
CouchDB löst so ein bisschen das Problem, dass ich nicht unbedingt in einen zentralen Master immer reinschreiben will.

00:21:18.120 --> 00:21:20.840
Weil der halt auch weg sein kann, wenn ich zum Beispiel offline bin oder so.

00:21:20.840 --> 00:21:23.940
Dann kann ich halt nicht da reinschreiben.

00:21:23.940 --> 00:21:26.540
Sondern muss dann halt eventuell erst lokal schreiben.

00:21:26.700 --> 00:21:30.420
Und dann irgendwie die Daten synchronisieren hinterher.

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

00:21:32.120 --> 00:21:36.580
Verwendet tatsächlich auch einen Algorithmus, der aus dem LotusNotes-Dings-Projekt kommt.

00:21:36.580 --> 00:21:44.160
Es gibt Key-Value-Stores, wo man einfach nur irgendeinen Hash irgendwie...

00:21:44.160 --> 00:21:45.620
Also man kann sich das vorstellen wie ein Python-Dict.

00:21:45.620 --> 00:21:48.340
Wo man halt irgendwelche Keys hat.

00:21:48.340 --> 00:21:51.160
Und dann hat man irgendwelche Werte, die man dann zurückbekommt, wenn man den Key da hinschickt.

00:21:51.160 --> 00:21:55.460
Darunter fallen so Sachen wie Redis oder Memcached.

00:21:55.460 --> 00:21:56.680
Oder so oft zum Cache.

00:21:56.700 --> 00:22:00.660
Aber manchmal können sie auch kompliziertere Sachen oder weiter strukturierte Daten.

00:22:00.660 --> 00:22:02.840
Berkeley-DB war lange ganz groß.

00:22:02.840 --> 00:22:04.100
Heute gar nicht mehr so sehr verwendet.

00:22:04.100 --> 00:22:09.480
Ja, aber auch sowas wie Amazon Dynamo oder so fällt da auch drunter.

00:22:09.480 --> 00:22:12.700
Und dann gibt es halt noch so spaltenorientierte Datenbanken.

00:22:12.700 --> 00:22:14.660
Wobei ich auch da sagen würde, es gibt zwei unterschiedliche Arten.

00:22:14.660 --> 00:22:18.720
Aber halt sowas wie Bigtable, wo Google einen Index drin speichert.

00:22:18.720 --> 00:22:21.200
Oder das entsprechende Hadoop-Äquivalent.

00:22:21.200 --> 00:22:23.620
Oder das Äquivalent aus dem Hadoop-Ökosystem Edgebase.

00:22:23.620 --> 00:22:26.580
Die Dinger sind halt dafür gedacht, dass man da so ein bisschen mehr Daten hat.

00:22:26.580 --> 00:22:30.660
Die Dinger sind halt dafür gedacht, gigantische Datenmengen irgendwie zu speichern.

00:22:30.660 --> 00:22:34.740
Und das halt machen sie dann irgendwie eher so spaltbasiert.

00:22:34.740 --> 00:22:38.000
Cassandra, Apache Cassandra ist auch so ein Projekt, das das genauso macht.

00:22:38.000 --> 00:22:41.680
Dann ein komplett anderes Paradigma sind Grafendatenbanken.

00:22:41.680 --> 00:22:48.380
Wo man Daten eben nicht in Tabellen speichert, sondern man speichert eher Knoten und Kanten.

00:22:48.380 --> 00:22:52.920
Und die Relationen zwischen den Daten sind halt nicht dadurch dargestellt,

00:22:52.920 --> 00:22:55.660
dass man jetzt halt irgendwie Zeilen in einer Tabelle hat.

00:22:56.460 --> 00:23:02.800
Und dadurch, dass man halt beliebige Beziehungen im Grunde zwischen Knoten irgendwie hat,

00:23:02.800 --> 00:23:03.660
das ist jetzt ein bisschen abstrakt.

00:23:03.660 --> 00:23:05.480
Weiß ich auch gar nicht genau, wie ich das erklären kann.

00:23:05.480 --> 00:23:08.560
Vielleicht kann man das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.

00:23:08.560 --> 00:23:09.380
Vielleicht kann ich das nachher nochmal im praktischen Beispiel ein bisschen besser erläutern.

00:23:09.380 --> 00:23:12.080
Genau.

00:23:12.080 --> 00:23:15.300
Aber das ist halt so eine ganz andere Art von Datenbanken.

00:23:15.300 --> 00:23:19.760
Da würde ich sagen, das hätte auch sich anstelle von relationalen Datenbanken durchsetzen können.

00:23:19.760 --> 00:23:20.760
Ja.

00:23:20.760 --> 00:23:26.440
Und genau, auch das, was mit dem Semantik-Web vielleicht haben manche Leute,

00:23:26.460 --> 00:23:33.460
davon schon gehört, so RDF, Tuppel-Stores, das ist auch alles im Grunde Grafendatenbanken.

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

00:23:36.880 --> 00:23:37.280
Genau.

00:23:37.280 --> 00:23:42.340
Und dann gibt es natürlich noch so wirklich anwendungsspezifische Datenbanken,

00:23:42.340 --> 00:23:49.460
sowas wie Volltext-Suchmaschinen, also Volltext-Indizes oder für Zeitreihen gibt es auch spezialisierte Geschichten,

00:23:49.460 --> 00:23:56.440
Influx-DB oder Timescale-DB oder halt sowieso für, du hast halt ein bestimmtes Problem,

00:23:56.460 --> 00:24:00.780
wie du möchtest dieses, bei Google sieht man halt, Google-Suggest hieß das Feature,

00:24:00.780 --> 00:24:04.300
wenn man Google-Query eingibt, dann werden einem so Vorschläge gemacht.

00:24:04.300 --> 00:24:10.360
Dafür braucht man halt spezielle Art, das zu indizieren, das ist Suffix-Trees.

00:24:10.360 --> 00:24:17.600
Und das kann ja, ja, dafür gibt es dann auch wieder spezielle Server, mit denen man das machen kann und so.

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

00:24:20.180 --> 00:24:26.020
Es gibt halt für bestimmte Anwendungsfälle gibt es sowas halt, aber ja, ist jetzt manchmal jetzt in solcher Funktion

00:24:26.460 --> 00:24:32.680
in so verbreiteteren Datenbanken enthalten, aber es gibt halt auch mal spezialisierte Geschichten dafür.

00:24:32.680 --> 00:24:35.060
Ja.

00:24:35.060 --> 00:24:38.560
Vielleicht die ganzen Basissachen werden noch komplett nicht kurz erwähnt.

00:24:38.560 --> 00:24:39.160
Ah ja, okay.

00:24:39.160 --> 00:24:42.200
So, keine Ahnung, MySQL oder Postgres.

00:24:42.200 --> 00:24:45.180
Ach so, das sind, ja genau, das sind Beispiele für relationale Datenbanken.

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

00:24:49.620 --> 00:24:55.740
Oracle und MSSQL-Server, Sybase, das wären so die kommerziellen.

00:24:56.460 --> 00:25:00.360
Ja, Geschichten, DB2 von IBM, ja.

00:25:00.360 --> 00:25:07.420
Oder zur Historie, im Grunde die, nachdem dieses Paper irgendwie, das ist übrigens sehr,

00:25:07.420 --> 00:25:11.200
das sollte man nicht schon uns packen, das ist sehr empfehlenswert, das sich mal anzulesen von Headcourt.

00:25:11.200 --> 00:25:18.160
Der hat damals bei IBM gearbeitet und da ist ein System daraus entstanden, das nennt sich System R.

00:25:18.160 --> 00:25:26.420
Das haben irgendwie so ein paar Leute bei IBM geschrieben und daraus ist halt DB2,

00:25:26.460 --> 00:25:31.840
auch von IBM entstanden irgendwann, aber halt Oracle bezieht sich auch da drauf, glaube ich.

00:25:31.840 --> 00:25:34.280
Ich weiß jetzt aber nicht, wie die Verbindung zu Oracle ist.

00:25:34.280 --> 00:25:40.680
Und dann gab es halt auch Leute in Berkeley, die versucht haben, das zu implementieren, das Paper.

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

00:25:43.560 --> 00:25:51.740
Michael Stonebreaker war das damals und das war am Anfang noch gar keine Datenbank für beliebige Daten,

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

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

00:25:56.460 --> 00:26:01.340
Und wurde dann zu einer normalen, relationalen Datenbank sozusagen.

00:26:01.340 --> 00:26:09.020
Und das ist auch faszinierend, also dieses ganze Postgres-Projekt ist der Wahnsinn eigentlich.

00:26:09.020 --> 00:26:15.040
Das hat halt irgendwie Mitte der 80er ist das gestartet oder halt, wenn man Ingress dazu zählt, noch früher.

00:26:15.040 --> 00:26:23.460
Und ist jetzt über 30 Jahre wahrscheinlich, hat das auch einen Buckel und ist immer noch top.

00:26:23.460 --> 00:26:25.400
State of the Art.

00:26:25.400 --> 00:26:25.880
State of the Art immer noch dabei.

00:26:25.880 --> 00:26:26.420
Das kommt immer noch.

00:26:26.460 --> 00:26:27.000
Tolle Sachen dazu.

00:26:27.000 --> 00:26:36.380
Ist wahrscheinlich auch so die, sie nennen sich selber irgendwie die, ich weiß gar nicht, wie ich das übersetzen soll,

00:26:36.380 --> 00:26:40.640
die Advanteste, die fortschrittlichste Open-Source-Datenbank.

00:26:40.640 --> 00:26:44.080
Gut, Oracle und so hat wahrscheinlich noch ein bisschen mehr Funktionen.

00:26:44.080 --> 00:26:50.640
Aber ja, tatsächlich wird meistens aber, wahrscheinlich aus Kostengründen,

00:26:50.640 --> 00:26:55.500
tatsächlich jetzt so im Internetumfeld irgendwie dann meistens werden so Open-Source-Datenbanken verwendet.

00:26:56.460 --> 00:27:01.520
Ja, ich habe schon mal gesehen, dass Leute Oracle verwenden, aber das ist eher selten.

00:27:01.520 --> 00:27:08.380
Jetzt so bei, als Backend für Webseiten verwendet man normalerweise nicht Oracle, das ist halt auch einfach viel zu teuer.

00:27:08.380 --> 00:27:14.780
Oder MSSQL-Server, doch, das gibt es tatsächlich Leute, die das als Backend für Webseiten verwenden.

00:27:14.780 --> 00:27:22.680
Ein Beispiel einer populären Seite, die halt auf MSSQL-Server läuft, ist Stack Overflow.

00:27:22.680 --> 00:27:24.540
Das ist auch faszinierend.

00:27:26.460 --> 00:27:33.060
Ja, der war, ich weiß nicht, ob es der Gründer selber war, der war auch Produktmanager bei Microsoft, glaube ich.

00:27:33.060 --> 00:27:37.300
Insofern, also die machen viel auf dem Microsoft-Stack und holen da unglaubliche Sachen raus.

00:27:37.300 --> 00:27:40.960
Also die haben irgendwie ein halbes Rack oder, also das letzte Mal, gut, das ist jetzt auch schon lange her,

00:27:40.960 --> 00:27:44.500
dass ich da irgendwie Artikel zu gelesen habe, aber das letzte Mal, dass ich das gelesen habe,

00:27:44.500 --> 00:27:49.880
war Stack Overflow tatsächlich unter den Top Ten der traffic-stärksten Webseiten weltweit.

00:27:49.880 --> 00:27:53.580
Und die haben dafür, Hardware war irgendwie so ein halbes Rack oder so.

00:27:53.580 --> 00:27:56.020
Und das ist natürlich schon extrem beeindruckend.

00:27:56.460 --> 00:27:59.020
Das ist überhaupt sowas, was halt wahrscheinlich viele Leute nicht wissen,

00:27:59.020 --> 00:28:01.180
die jetzt wieder nicht so viel Erfahrung haben mit Datenbanken.

00:28:01.180 --> 00:28:07.000
Die können echt wahnsinnig viel Dinge tun gleichzeitig und so.

00:28:07.000 --> 00:28:12.380
Also man kriegt aus so einer ordentlich konfigurierten und getunten relationalen Datenbank

00:28:12.380 --> 00:28:17.560
schon so mindestens ein paar tausend, vielleicht auch ein paar zehntausend Requests oder Statements pro Sekunde raus,

00:28:17.560 --> 00:28:18.540
die die halt verarbeiten können.

00:28:18.540 --> 00:28:20.580
Und dann kann man natürlich eine Menge machen.

00:28:26.460 --> 00:28:28.400
Also vorausgesetzt der ganze Kram passt in den Hauptspeicher.

00:28:28.400 --> 00:28:33.060
Aber man macht keine Dinge, die das irgendwie langsam machen.

00:28:33.060 --> 00:28:34.720
Also es ist halt auch nicht so einfach, das zu optimieren.

00:28:34.720 --> 00:28:37.360
Aber ja, genau.

00:28:37.360 --> 00:28:39.860
Und das ist halt auch dieser Bereich der relationalen Datenbank.

00:28:39.860 --> 00:28:42.220
Das ist halt der größte Datenbankbereich eigentlich.

00:28:42.220 --> 00:28:46.600
Ja, vielleicht kommen wir dann, wollen wir zu dem praktischen Beispiel.

00:28:46.600 --> 00:28:46.900
Ja, mit dem Beispiel, genau.

00:28:46.900 --> 00:28:47.320
Das wäre super.

00:28:47.320 --> 00:28:50.020
Wie macht man das jetzt alles und wie baut man das auf und warum?

00:28:50.020 --> 00:28:52.000
Und was kann man damit so schönes machen?

00:28:52.000 --> 00:28:54.460
Und was für Probleme könnten wir darüber stolpern und sowas?

00:28:54.460 --> 00:28:56.460
Ja, dann...

00:28:56.460 --> 00:28:59.040
Nehmen wir doch mal an, wir wollen jetzt Amazon nachbauen.

00:28:59.040 --> 00:29:01.600
Wir haben einen kleinen Buchhandel in der Garage.

00:29:01.600 --> 00:29:05.660
Ja, und wir überlegen uns jetzt so...

00:29:05.660 --> 00:29:07.400
Da liegen jetzt ganz viele Bücher auf dem Boden.

00:29:07.400 --> 00:29:08.740
Und dann will irgendjemand bestellen.

00:29:08.740 --> 00:29:12.080
Dann muss dann irgendjemand in die Garage laufen, gucken, wie ist denn jetzt der Titel?

00:29:12.080 --> 00:29:12.520
Habe ich den?

00:29:12.520 --> 00:29:13.980
Dann liegt ein Buch unter dem anderen.

00:29:13.980 --> 00:29:16.240
Das wäre natürlich doof, wenn man erstmal alleine suchen muss.

00:29:16.240 --> 00:29:20.160
Deswegen haben wir jetzt überlegt, ja, pass auf, wir schreiben das Ganze jetzt in eine Datenbank.

00:29:20.160 --> 00:29:21.680
Wie fangen wir jetzt mal an?

00:29:21.680 --> 00:29:24.280
Vielleicht reden wir kurz über das Schema, wie man sowas aufbaut.

00:29:24.280 --> 00:29:24.740
Nochmal kurz.

00:29:24.740 --> 00:29:25.580
Genau.

00:29:26.460 --> 00:29:32.800
Also, man würde jetzt zum Beispiel eben die Mitteilinformationen über diese Bücher,

00:29:32.800 --> 00:29:38.460
also sowas wie Titel, ISBN-Preis und so...

00:29:38.460 --> 00:29:40.120
Autor.

00:29:40.120 --> 00:29:42.640
Genau, würde man halt in eine Datenbank schreiben.

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

00:29:45.140 --> 00:29:46.560
Vielleicht, ja.

00:29:46.560 --> 00:29:47.460
Was auch immer man da...

00:29:47.460 --> 00:29:49.460
Man würde das halt in eine Tabelle schreiben.

00:29:49.460 --> 00:29:53.460
Aber man würde jetzt möglicherweise schon nicht den Autor...

00:29:53.460 --> 00:29:56.460
Wenn man jetzt den Namen des Autors mit...

00:29:56.460 --> 00:29:58.580
in diese Tabelle reinschreibt, dann hat man unter Umständen

00:29:58.580 --> 00:29:59.340
ein Problem, nämlich

00:29:59.980 --> 00:30:01.300
wenn jetzt halt...

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

00:30:02.960 --> 00:30:05.560
Ja, genau. Heiratet oder sonst

00:30:05.560 --> 00:30:06.800
irgendwie seinen Namen ändert,

00:30:06.800 --> 00:30:09.180
dann müsste man ja,

00:30:09.180 --> 00:30:11.140
dann kann man natürlich irgendwie alle

00:30:11.140 --> 00:30:13.640
Zeilen, in denen der Name drinsteht,

00:30:13.640 --> 00:30:14.180
die ändern,

00:30:14.180 --> 00:30:17.640
aber man kann ja auch Pech haben und

00:30:17.640 --> 00:30:19.660
wenn das jemand von Hand macht, dann ändert er halt

00:30:19.660 --> 00:30:21.520
das nur, weil er davon gehört hat, dass es jetzt

00:30:21.520 --> 00:30:23.400
für dieses Buch geändert werden soll, das nur in einer Zeile

00:30:23.400 --> 00:30:25.500
und lässt die anderen halt weg und dann hat man halt...

00:30:25.500 --> 00:30:27.360
Wir könnten Suche und Ersetze machen und dann machen wir sowas,

00:30:27.360 --> 00:30:29.280
dann machen wir für jedes Jahr,

00:30:29.380 --> 00:30:31.180
das wir für Bestellung haben oder jeden Monat, eine neue Datenbank,

00:30:31.180 --> 00:30:33.200
eine neue Tabelle und dann müssten wir einmal nach

00:30:33.200 --> 00:30:35.240
drei Jahren oder sowas 36 verschiedene Dateien öffnen,

00:30:35.240 --> 00:30:37.120
immer Suche und Ersetze ausführen und dann den Namen ändern.

00:30:37.120 --> 00:30:38.760
Ist doch super, oder nicht?

00:30:38.760 --> 00:30:41.180
Ich könnte sagen, dass das nah dran ist

00:30:41.180 --> 00:30:43.000
an dem, was viele Leute tatsächlich machen, aber das

00:30:43.000 --> 00:30:45.100
kann man auch eleganter tun in der Datenbank

00:30:45.100 --> 00:30:47.280
und dann hätte man möglicherweise

00:30:47.280 --> 00:30:48.820
nur einen sogenannten Fremdschlüssel

00:30:48.820 --> 00:30:50.040
in der Spalte Autor

00:30:50.040 --> 00:30:52.320
in der Büchertabelle

00:30:52.320 --> 00:30:55.300
und dann würde man den Namen

00:30:55.300 --> 00:30:57.340
des Autors halt von der Autotabelle ändern

00:30:57.340 --> 00:30:58.780
und dann wäre das

00:30:58.780 --> 00:31:01.040
automatisch in allen Zeilen

00:31:01.040 --> 00:31:01.880
in allen Bücher

00:31:01.880 --> 00:31:05.160
oder allen Zeilen der Büchertabelle, in denen das referenziert wird,

00:31:05.160 --> 00:31:07.140
würde das

00:31:07.140 --> 00:31:08.940
automatisch geändert werden.

00:31:08.940 --> 00:31:11.020
Und dann brauchen wir ja noch eine andere Tabelle

00:31:11.020 --> 00:31:12.960
Autorix, wo dann alle Autorinnen

00:31:12.960 --> 00:31:14.020
drinstehen.

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

00:31:17.540 --> 00:31:19.740
Und

00:31:19.740 --> 00:31:22.400
ich überlege gerade,

00:31:22.400 --> 00:31:25.020
das ist jetzt natürlich

00:31:25.020 --> 00:31:26.680
also Autoren, ein Beispiel,

00:31:26.680 --> 00:31:28.380
ein anderes Beispiel wäre User, die jetzt auf der Webseite

00:31:28.380 --> 00:31:30.060
irgendwas einkaufen wollen oder so, da gibt es

00:31:30.060 --> 00:31:32.000
da würde man in der Bestellung halt auch

00:31:32.000 --> 00:31:34.500
nicht den User selber irgendwie in jede Bestellung schreiben,

00:31:34.500 --> 00:31:36.600
sondern halt irgendwie die ID

00:31:36.600 --> 00:31:38.580
von dem User, der irgendwas

00:31:38.580 --> 00:31:39.840
eingekauft hat und

00:31:39.840 --> 00:31:42.720
im Grunde

00:31:42.720 --> 00:31:44.580
also ja, das heißt Datenbank

00:31:44.580 --> 00:31:46.440
Normalisierung, wenn man jetzt dafür sorgt,

00:31:46.440 --> 00:31:48.260
erinnert so ein bisschen an

00:31:48.260 --> 00:31:50.340
wenn man Software schreibt, nennt sich das Dry,

00:31:50.340 --> 00:31:52.660
so Don't Repeat Yourself, also wenn man Software

00:31:52.660 --> 00:31:54.540
schreibt, sollte man auch Funktionalität,

00:31:54.540 --> 00:31:56.380
die man an mehreren Stellen verwendet, halt nicht an mehreren

00:31:56.380 --> 00:31:58.340
Stellen implementiert haben, weil wenn man das an

00:31:58.340 --> 00:32:00.300
einer Stelle ändert und fräst es halt an der anderen,

00:32:00.300 --> 00:32:00.880
dann hat man halt

00:32:00.880 --> 00:32:04.480
ja, einmal ist es dann inkonsistent

00:32:04.480 --> 00:32:06.560
das Verhalten und ja,

00:32:06.560 --> 00:32:07.800
man hat halt auch die Gefahr, dass

00:32:07.800 --> 00:32:10.500
dass man Dinge, die man einmal gefixt hat, halt dann

00:32:10.500 --> 00:32:11.220
nochmal auftauchen.

00:32:11.220 --> 00:32:14.380
Das ist doch bestimmt schon ein, zwei Mal passiert, oder? Also mir hat das früher ständig passiert

00:32:14.380 --> 00:32:16.240
und dann ist mir irgendwann aufgefallen, oh, ich mach

00:32:16.240 --> 00:32:18.500
eine Funktion und dann macht man die Funktion und dann macht man einen Test

00:32:18.500 --> 00:32:20.340
und dann ist es halt erledigt

00:32:20.340 --> 00:32:21.700
sozusagen. Also

00:32:21.700 --> 00:32:24.540
sollte man halt möglichst versuchen, Dinge, die man

00:32:24.540 --> 00:32:26.380
so logik, die irgendwo ist, halt immer nur einmal

00:32:26.380 --> 00:32:28.260
irgendwo stehen zu haben. Ist natürlich manchmal nicht so ganz einfach,

00:32:28.300 --> 00:32:30.360
und das ist bei Datenbanken halt auch nicht, weil

00:32:30.360 --> 00:32:32.540
das weist sich so ein bisschen mit anderen Anforderungen,

00:32:32.540 --> 00:32:34.080
die man hat, wenn es halt schnell sein soll,

00:32:34.080 --> 00:32:35.680
dann ist das manchmal etwas schwierig, weil

00:32:35.680 --> 00:32:38.360
relationale Datenbanken, dann wenn man

00:32:38.360 --> 00:32:40.160
halt viele Tabellen miteinander verknüpft, man nennt das halt

00:32:40.160 --> 00:32:42.160
Join, ja, das heißt, man kann halt anhand von

00:32:42.160 --> 00:32:44.620
diesen Verzweigungs-,

00:32:44.620 --> 00:32:46.500
also Fremdschlüssel-Dingsies

00:32:46.500 --> 00:32:48.280
kann man halt Tabellen aneinander

00:32:48.280 --> 00:32:49.620
ketten.

00:32:49.620 --> 00:32:51.140
Ja, verketten.

00:32:51.140 --> 00:32:54.060
Man kann sich das vorstellen, man legt die halt sozusagen

00:32:54.060 --> 00:32:56.120
nebeneinander, sodass halt die

00:32:56.120 --> 00:32:57.840
Spalte mit dem Schlüssel übereinander liegt, ja,

00:32:58.260 --> 00:33:00.220
sozusagen, und wenn man das mit vielen macht, dann werden die Abfragen

00:33:00.220 --> 00:33:02.560
langsam. So ein bisschen wie an so einen Spielautomaten,

00:33:02.560 --> 00:33:04.220
wenn ihr so einen einahmigen Banditen

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

00:33:06.180 --> 00:33:08.180
und wenn ihr dann parallel so ein Alles-Zeit-Gewinn,

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

00:33:09.920 --> 00:33:12.220
Dann hat man

00:33:12.220 --> 00:33:14.060
die Zeile anhand von dem Schlüssel irgendwie

00:33:14.060 --> 00:33:15.020
zusammengeführt, ja, genau.

00:33:15.020 --> 00:33:16.700
Und, äh,

00:33:16.700 --> 00:33:19.140
ja, ähm,

00:33:19.140 --> 00:33:22.160
also, ähm, also das ist halt auch, wie man

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

00:33:23.600 --> 00:33:26.200
Kunst, und man braucht Erfahrung dafür,

00:33:26.200 --> 00:33:28.220
ähm,

00:33:28.220 --> 00:33:30.180
ähm, aber man kann halt sagen, ja,

00:33:30.180 --> 00:33:32.040
man sollte das so ein bisschen normalisieren, also

00:33:32.040 --> 00:33:34.120
meistens gibt es dann ganz viele unterschiedliche Normalformen,

00:33:34.120 --> 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.660 --> 00:33:41.920
zwischen dritter und Boy-Scout-Normalform, oder sowas,

00:33:41.920 --> 00:33:44.020
aber ich möchte gar nicht so sehr im Detail darauf eingehen,

00:33:44.020 --> 00:33:45.620
was jetzt die Unterschiede zwischen den Normalformen sind,

00:33:45.620 --> 00:33:47.940
also irgendwie kann man sich auch durchlesen auf Wikipedia,

00:33:47.940 --> 00:33:50.120
oder so, braucht man auch im Alltag eigentlich gar nicht

00:33:50.120 --> 00:33:52.200
zu 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.740
ein Datenbankschema okay aussieht,

00:33:55.740 --> 00:33:58.180
und dann macht man das halt so

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

00:34:00.360 --> 00:34:01.940
und nehme ein Whiteboard,

00:34:01.940 --> 00:34:03.920
einen Zettel, und schreibe mir auf, wie die Daten

00:34:03.920 --> 00:34:05.880
aussehen sollen. Ja, ja, tatsächlich, also

00:34:05.880 --> 00:34:07.280
wenn ich irgendwie

00:34:07.280 --> 00:34:09.940
einen Datenbank designe für irgendein Projekt, dann

00:34:09.940 --> 00:34:11.960
nehme ich mir einen Zettel, und

00:34:11.960 --> 00:34:15.000
fange an, Entity-Relationship-Diagramme

00:34:15.000 --> 00:34:16.160
zu malen, so nennt man die.

00:34:16.160 --> 00:34:17.980
Was passiert denn später, wenn ich während

00:34:17.980 --> 00:34:19.940
dem Projekt merke, hey, ich habe aber die und die

00:34:19.940 --> 00:34:20.860
Daten vergessen?

00:34:20.860 --> 00:34:24.060
Bastel ich da einfach irgendwo rein, ergänze ich dann dieses Schema

00:34:24.060 --> 00:34:25.520
einfach, oder? Ja,

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

00:34:28.140 --> 00:34:29.220
also das ist ja auch so ein Problem,

00:34:29.220 --> 00:34:30.400
man kann

00:34:30.400 --> 00:34:33.840
Datenbanken

00:34:33.840 --> 00:34:35.520
nicht so richtig super ändern,

00:34:35.520 --> 00:34:37.740
also, relationelle Datenbanken,

00:34:37.740 --> 00:34:39.740
das Schema lässt sich schon ändern,

00:34:39.740 --> 00:34:40.980
aber das ist halt so ein bisschen

00:34:40.980 --> 00:34:43.720
knifflig, und wenn man das tut, muss man halt

00:34:43.720 --> 00:34:45.200
irgendwie aufpassen.

00:34:45.200 --> 00:34:47.820
Dass alte Datenbanken noch kompatibel sind, oder sowas?

00:34:47.820 --> 00:34:49.820
Ja, dass

00:34:49.820 --> 00:34:51.660
man das so ändert, dass nicht

00:34:51.660 --> 00:34:53.720
irgendwelche Inkonsistenzen entstehen, und auch

00:34:53.720 --> 00:34:55.620
das halt... Wie wäre das jetzt bei unserem

00:34:55.620 --> 00:34:56.320
Beispiel, beispielsweise?

00:34:58.100 --> 00:35:00.100
Also, wenn ich mir jetzt überlege, ich brauche

00:35:00.100 --> 00:35:02.180
jetzt eine neue Spalte in dieser Büchertabelle,

00:35:02.180 --> 00:35:04.340
ja, weiß ich nicht, es gibt jetzt nicht nur

00:35:04.340 --> 00:35:06.380
die ESPN...

00:35:06.380 --> 00:35:08.400
Jemand, oder das Genre, oder sowas,

00:35:08.400 --> 00:35:09.640
jemand sammelt Seefahrerbücher.

00:35:09.640 --> 00:35:12.000
Eine Kategorie, da würde ich halt tatsächlich, also

00:35:12.000 --> 00:35:14.080
das, was man sich zuerst überlegen könnte, ist, man macht

00:35:14.080 --> 00:35:16.580
einfach ein Textfeld

00:35:16.580 --> 00:35:17.940
oder Charfield,

00:35:17.940 --> 00:35:20.580
das halt den Kategorienamen

00:35:20.580 --> 00:35:20.980
enthält,

00:35:20.980 --> 00:35:24.120
und dann hat man halt das Problem, okay,

00:35:24.120 --> 00:35:24.980
dann stellt man fest,

00:35:24.980 --> 00:35:28.060
oder am besten noch, okay, fangen wir so

00:35:28.060 --> 00:35:28.280
an.

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

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

00:35:33.620 --> 00:35:34.960
und sagt jetzt,

00:35:34.960 --> 00:35:38.120
okay, alle Texts, also weiß ich nicht,

00:35:38.120 --> 00:35:39.860
Politistik,

00:35:39.860 --> 00:35:41.420
Seephara-Roman, oder

00:35:41.420 --> 00:35:44.060
schreibt man jetzt, Komma separiert

00:35:44.060 --> 00:35:45.860
halt in eine Spalte rein,

00:35:45.860 --> 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.840 --> 00:35:54.100
okay, nee, das geht nicht, darf ich so nicht machen?

00:35:54.100 --> 00:35:56.100
Also der eigentliche Grund,

00:35:56.100 --> 00:35:58.020
warum man das nicht so machen sollte, ist halt, dass es die

00:35:58.020 --> 00:35:59.960
Anfragen halt schwierig macht und dass man

00:35:59.960 --> 00:36:01.900
es auch sehr schlecht ändern kann und dass, wenn man

00:36:01.900 --> 00:36:03.240
was ändert, kann man Sachen kaputt machen,

00:36:03.240 --> 00:36:04.860
weil

00:36:04.860 --> 00:36:07.180
Inkonsistenzen entstehen können und so.

00:36:07.180 --> 00:36:12.020
Dann zieht man erst mal diese Dinge

00:36:12.020 --> 00:36:13.920
auseinander und sagt halt, okay, nicht in

00:36:13.920 --> 00:36:15.460
einer Spalte

00:36:15.460 --> 00:36:19.980
mehrere Texts reinschreiben, sondern

00:36:19.980 --> 00:36:21.680
dann hätte man sozusagen eine

00:36:21.680 --> 00:36:23.760
N-zu-M-Relation, also nicht nur, wo ein

00:36:23.760 --> 00:36:25.920
Fremdschlüssel in der einen Tabelle zu einem Fremdschlüssel in der anderen Tabelle

00:36:25.920 --> 00:36:27.940
passt, sondern man hat dazwischen den Link,

00:36:27.980 --> 00:36:30.100
man hat jetzt einmal Text als Relation

00:36:30.100 --> 00:36:32.100
und einmal halt die Bücher als Relation

00:36:32.100 --> 00:36:33.880
oder als Tabellen halt und

00:36:33.880 --> 00:36:35.700
dazwischen hat man jetzt noch eine Link-Tabelle

00:36:35.700 --> 00:36:37.300
oder eine Link-Relation zwischen

00:36:37.300 --> 00:36:39.740
Büchern und Text, sodass man

00:36:39.740 --> 00:36:41.920
mehrere, also für jedes Tag hätte man dann sozusagen

00:36:41.920 --> 00:36:43.480
einen Eintrag in der Link-Tabelle,

00:36:43.480 --> 00:36:44.800
wo dann drin steht,

00:36:44.800 --> 00:36:47.880
ID von diesem Buch, ID von

00:36:47.880 --> 00:36:49.980
diesem Tag, ja, und das ist dann halt sozusagen

00:36:49.980 --> 00:36:51.760
die Verbindung

00:36:51.760 --> 00:36:53.720
zwischen den beiden Tabellen, sondern halt

00:36:53.720 --> 00:36:55.860
eine Tabelle mit allen Texten, die ist möglicherweise gar nicht

00:36:55.860 --> 00:36:57.520
so lang, es gibt vielleicht nur 1000 Texte oder so,

00:36:57.980 --> 00:36:59.360
und

00:36:59.360 --> 00:37:01.600
vielleicht ein paar Millionen Bücher und

00:37:01.600 --> 00:37:03.640
jetzt hat man halt eine Link-Tabelle, die

00:37:03.640 --> 00:37:05.980
wahrscheinlich dann irgendwie ein paar 10 Millionen Bücher

00:37:05.980 --> 00:37:07.880
oder ein paar 10 Millionen

00:37:07.880 --> 00:37:09.520
Zeilen oder so lang ist, wo halt

00:37:09.520 --> 00:37:11.680
jedem Buch ein paar Texte

00:37:11.680 --> 00:37:13.740
zugewiesen werden. Und dann

00:37:13.740 --> 00:37:15.760
ist es alles wieder schön in einer Normalform und

00:37:15.760 --> 00:37:17.120
das kann man dann auch wieder nett abfragen.

00:37:17.120 --> 00:37:19.300
Ja,

00:37:19.300 --> 00:37:21.580
wenn man dann aber

00:37:21.580 --> 00:37:23.840
quasi diesen Text halt,

00:37:23.840 --> 00:37:25.820
wenn man diese Texte jetzt aber betrachtet

00:37:25.820 --> 00:37:27.860
als Blätter in einem Kategorienbaum oder

00:37:27.860 --> 00:37:29.940
so, dann wird es wieder so ein bisschen schwierig,

00:37:29.940 --> 00:37:31.900
weil dann versucht man etwas in einer relationalen Datenbank

00:37:31.900 --> 00:37:33.520
abzuspeichern, was gar nicht so gut geht, nämlich

00:37:33.520 --> 00:37:35.480
irgendwie so Baumstrukturen oder

00:37:35.480 --> 00:37:36.780
Grafenstrukturen.

00:37:36.780 --> 00:37:39.800
Das kann man dann auch machen, und wenn es

00:37:39.800 --> 00:37:41.880
nicht viele Texte oder Kategorien sind,

00:37:41.880 --> 00:37:43.780
dann würde man versuchen, das wahrscheinlich in erste Z

00:37:43.780 --> 00:37:44.100
nehmen.

00:37:44.100 --> 00:37:47.500
Das ist, kann man sich mal angucken,

00:37:47.500 --> 00:37:49.700
wenn einen das interessiert, wie das, dann kann man

00:37:49.700 --> 00:37:51.640
dann halt auch 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.420 --> 00:37:57.500
Was man macht ist, man schreibt dann jede,

00:37:57.740 --> 00:37:59.660
man hat so eine Kategorie in Baum und man schreibt

00:37:59.660 --> 00:38:01.860
dann an jede, jedes

00:38:01.860 --> 00:38:03.600
Element in dieser hierarchischen

00:38:03.600 --> 00:38:05.380
Struktur, den travisiert man einmal

00:38:05.380 --> 00:38:07.780
First Order, ich weiß

00:38:07.780 --> 00:38:08.260
gar nicht genau.

00:38:08.260 --> 00:38:11.840
Und also beim

00:38:11.840 --> 00:38:13.860
Durchlaufen nummeriert man jeden Knoten,

00:38:13.860 --> 00:38:15.480
an dem man vorbeiläuft, durch

00:38:15.480 --> 00:38:17.660
und man hat eine Spalte links und

00:38:17.660 --> 00:38:19.580
eine Spalte rechts und links,

00:38:19.580 --> 00:38:21.640
wenn man links an den Sachen vorbeiläuft

00:38:21.640 --> 00:38:23.240
in den Baum, schreibt man halt die

00:38:23.240 --> 00:38:25.660
Nummern links rein und dann rechts, wenn man

00:38:25.660 --> 00:38:27.620
rechts dran vorbeiläuft und dann kann man so Sachen

00:38:27.620 --> 00:38:29.620
Range-Abfragen dazwischen machen

00:38:29.620 --> 00:38:31.440
und magischerweise führt das dann dazu, dass man

00:38:31.440 --> 00:38:33.140
so Subbäume rausselekten kann und so.

00:38:33.140 --> 00:38:35.260
Aber das ist dann halt schon so wirklich fortgeschritten.

00:38:35.260 --> 00:38:37.560
Und im Endeffekt,

00:38:37.560 --> 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.600 --> 00:38:43.280
dann wäre es wahrscheinlich besser, das gar nicht mehr in der

00:38:43.280 --> 00:38:44.960
Relationalen Datenbank zu machen, sondern das irgendwie

00:38:44.960 --> 00:38:47.940
in einen anderen Service zu packen.

00:38:47.940 --> 00:38:49.480
Ja, und da sind wir schon,

00:38:49.480 --> 00:38:51.360
boah, das ging aber schnell, da sind wir schon an Grenzen,

00:38:51.360 --> 00:38:53.480
wenn man das in der Relationalen Datenbank gut machen kann.

00:38:53.480 --> 00:38:55.500
Ja, also das Dorfschachtrekarat ist mittlerweile

00:38:55.500 --> 00:38:57.500
rausgewachsen, also wir können die ganzen Bücher dann

00:38:57.500 --> 00:38:58.380
in der Garage nicht mehr lagern.

00:38:58.380 --> 00:39:00.940
Nee, nee, nee, Moment, Moment, wir sind noch nicht, also was eigentlich auch,

00:39:00.940 --> 00:39:02.400
nee, wir sind noch nicht

00:39:02.400 --> 00:39:05.400
so weit, wir sind noch immer bei der ganz normalen, einfachen

00:39:05.400 --> 00:39:06.560
Datenbank, würde ich sagen.

00:39:06.560 --> 00:39:09.400
Ja, also das,

00:39:09.400 --> 00:39:11.220
wofür wir die nämlich auch brauchen, die Datenbank,

00:39:11.220 --> 00:39:12.940
ist halt so Transaktionen-Prozessen,

00:39:12.940 --> 00:39:15.320
wenn jemand was kauft zum Beispiel. Oh, jemand hat bei uns

00:39:15.320 --> 00:39:17.460
eine E-Mail geschickt, hat gesagt, hey, habt ihr das Buch da?

00:39:17.460 --> 00:39:18.760
Und wir gucken nach, sagen ja,

00:39:18.760 --> 00:39:21.100
können wir dir schicken. Dann, ja,

00:39:21.100 --> 00:39:23.160
bitte an die und die Adresse und so, dann machen wir so ein Paket,

00:39:23.160 --> 00:39:25.340
machen da so ein Stempel drauf und sagen, hey,

00:39:25.340 --> 00:39:27.480
hier bitte dein Buch.

00:39:27.480 --> 00:39:29.600
Ja, und dafür, dass das gut

00:39:29.600 --> 00:39:31.340
funktioniert, dann müssen halt auch einige Sachen

00:39:31.340 --> 00:39:33.500
für gewährleistet sein und

00:39:33.500 --> 00:39:35.120
das ist halt zum Beispiel so etwas wie,

00:39:35.120 --> 00:39:37.480
naja, wenn ich halt ein Buch kaufe, dann muss ich irgendwie

00:39:37.480 --> 00:39:39.420
sicherstellen, dass das im Lager ist. Das heißt, wenn

00:39:39.420 --> 00:39:41.620
jetzt ich ein

00:39:41.620 --> 00:39:43.440
Buch verschicke, dann sage ich meiner

00:39:43.440 --> 00:39:45.480
Datenbank irgendwie so, okay, jetzt

00:39:45.480 --> 00:39:46.760
ist davon eins weniger da im Lager.

00:39:46.760 --> 00:39:49.400
Aber wenn jetzt auf der Webseite jemand sagt, ich würde

00:39:49.400 --> 00:39:51.420
dieses Buch einkaufen, dann muss halt gewährleistet

00:39:51.420 --> 00:39:52.960
sein, dass das halt noch da ist. Das heißt,

00:39:52.960 --> 00:39:55.640
ich brauche halt eine zentrale

00:39:55.640 --> 00:39:57.460
Stelle, in der die Wahrheit... Ihr fällt direkt

00:39:57.460 --> 00:39:58.540
wieder eines der Probleme ein.

00:39:58.540 --> 00:40:01.480
Zwei Leute wollen das gleiche Buch haben,

00:40:01.480 --> 00:40:03.340
was nur noch einmal da ist und die wollen gleichzeitig eins

00:40:03.340 --> 00:40:05.340
kaufen. Genau, das ist halt

00:40:05.340 --> 00:40:06.940
eine problematische Geschichte.

00:40:06.940 --> 00:40:09.440
Aber wenn man jetzt eine Datenbank hat,

00:40:09.440 --> 00:40:11.440
die

00:40:11.440 --> 00:40:13.340
sozusagen Wahrheit kennt und alle

00:40:13.340 --> 00:40:15.260
nur auf die zugreifen, dann

00:40:15.260 --> 00:40:17.380
kann im Grunde nichts passieren. Also da können

00:40:17.380 --> 00:40:18.560
keine Konflikte auftreten,

00:40:18.560 --> 00:40:21.460
weil in dem Moment, wo jemand auf kaufen klickt

00:40:21.460 --> 00:40:23.440
auf der Webseite und es noch ein Buch da

00:40:23.440 --> 00:40:25.460
war...

00:40:25.460 --> 00:40:27.440
Die Frage ist halt jetzt, was

00:40:27.440 --> 00:40:29.420
man macht, wenn viele Kunden sich immer so ein Buch

00:40:29.420 --> 00:40:31.480
angucken, das in ihren Warenkorb reintun,

00:40:31.480 --> 00:40:33.920
weil sie es kaufen wollen, aber 90%

00:40:33.920 --> 00:40:35.460
dieser Kunden einfach gar nicht am Ende kaufen,

00:40:35.460 --> 00:40:37.380
sondern irgendwie wieder abspringen, weil die dann sagen, naja, doch nicht.

00:40:37.380 --> 00:40:39.440
Und dann hätten

00:40:39.440 --> 00:40:41.300
jetzt ja alle sich bei sich in den Warenkorb reingelegt und

00:40:41.300 --> 00:40:43.500
wenn nur noch eins da ist, vielleicht hätte

00:40:43.500 --> 00:40:45.360
der Zweite direkt angezeigt bekommen, gibt gar nichts, der ihn wirklich

00:40:45.360 --> 00:40:45.800
gekauft hätte.

00:40:45.800 --> 00:40:49.260
Also was natürlich passieren kann, ist, dass dir angezeigt wird,

00:40:49.260 --> 00:40:51.000
es gibt noch ein Buch, obwohl es keins mehr gibt.

00:40:51.000 --> 00:40:53.720
Weil du sitzt

00:40:53.720 --> 00:40:55.260
halt vor der Webseite und

00:40:55.260 --> 00:40:56.440
machst nichts.

00:40:57.420 --> 00:40:59.420
Oh, leider war jemand schneller und hat vor zwei Sekunden...

00:40:59.420 --> 00:41:01.640
Genau, du kannst, sobald du draufdrückst, in dem Moment,

00:41:01.640 --> 00:41:03.560
wo sozusagen diese

00:41:03.560 --> 00:41:05.380
Bestelltransaktion gestartet wird und dann

00:41:05.380 --> 00:41:07.480
in der Datenbank aber die Bedingungen,

00:41:07.480 --> 00:41:09.340
es muss mindestens eins im Lager sein, damit

00:41:09.340 --> 00:41:11.260
die Bestellung ausgeführt werden kann, nicht mehr erfüllt ist

00:41:11.260 --> 00:41:13.460
und diese Constraint wird verletzt,

00:41:13.460 --> 00:41:15.420
dann sagt die Datenbank so, geht

00:41:15.420 --> 00:41:17.520
nicht. Und dann kann man ihm so eine

00:41:17.520 --> 00:41:19.440
Fehlanwendung anzeigen und sagen so, oh ja, tut uns leid,

00:41:19.440 --> 00:41:21.420
das hat nicht geklappt, kein

00:41:21.420 --> 00:41:21.940
Buch mehr auf Lager.

00:41:21.940 --> 00:41:24.120
Das ist ja im Grunde okay.

00:41:24.120 --> 00:41:26.260
Ja, gerade so.

00:41:27.420 --> 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.840 --> 00:41:32.140
okay, du hast das jetzt bestellt,

00:41:32.140 --> 00:41:35.160
und dann sagt er am Schluss so,

00:41:35.160 --> 00:41:37.100
äh, du kriegst doch kein Buch, weil

00:41:37.100 --> 00:41:38.920
war keins mehr da. Das ist dann halt so ein bisschen blöder.

00:41:38.920 --> 00:41:41.360
Ist aber eine Situation, die dann später, wenn wir halt

00:41:41.360 --> 00:41:43.200
nicht mehr auf einer Datenbank bleiben können,

00:41:43.200 --> 00:41:44.380
weil das einfach

00:41:44.380 --> 00:41:47.340
von der Skalierung her

00:41:47.340 --> 00:41:48.740
nicht mehr klappen kann irgendwann,

00:41:48.740 --> 00:41:51.100
dann kommen wir in solche Situationen rein

00:41:51.100 --> 00:41:53.140
und da müssen wir uns dann überlegen, wie wir damit umgehen.

00:41:53.140 --> 00:41:55.360
Aber solange das alles auf einer Datenbank läuft,

00:41:55.360 --> 00:41:57.400
ist das

00:41:57.400 --> 00:41:59.640
im Grunde kein Problem, kann man das sauber lösen.

00:41:59.640 --> 00:42:00.840
Ich hatte ja, so mal es war,

00:42:00.840 --> 00:42:03.080
ich hatte das vielleicht schon mal kurz erwähnt, bei einer Bank.

00:42:03.080 --> 00:42:05.200
Ich habe eine Transaktion gemacht, da hat dann

00:42:05.200 --> 00:42:07.180
die Bank gesagt, ja, ist wunderbar, dein Überweisung wurde

00:42:07.180 --> 00:42:09.260
vernünftig ausgeführt, und dann

00:42:09.260 --> 00:42:10.840
zwei Wochen später

00:42:10.840 --> 00:42:13.020
kriegte ich dann so eine Mahnung, und dann habe ich noch mal

00:42:13.020 --> 00:42:14.400
aufs Konto geguckt, und die Transaktion war weg.

00:42:14.400 --> 00:42:16.940
War nicht da. Was war, habe ich dann da angerufen,

00:42:16.940 --> 00:42:19.080
haben gesagt, oh, ja, also in irgendeiner Logfile

00:42:19.080 --> 00:42:21.020
stand das dann wohl noch drin, dass ich so eine Transaktion eigentlich

00:42:21.020 --> 00:42:22.880
gemacht hatte, die aber nicht ausgeführt worden war.

00:42:22.880 --> 00:42:24.840
Das war ein bisschen blöd dann für mich, aber

00:42:24.840 --> 00:42:27.140
ja, scheint wohl auch mal so

00:42:27.380 --> 00:42:28.940
ein, ja, also

00:42:28.940 --> 00:42:31.380
möglicherweise war das eben eine Bank,

00:42:31.380 --> 00:42:33.060
und das ist tatsächlich bis, ich weiß nicht,

00:42:33.060 --> 00:42:35.060
vor gar nicht allzu langer Zeit

00:42:35.060 --> 00:42:37.400
tatsächlich üblich gewesen, wo dann

00:42:37.400 --> 00:42:39.100
die Transaktionen nicht

00:42:39.100 --> 00:42:40.900
in einer relationalen Datenbank

00:42:40.900 --> 00:42:42.700
direkt ausgeführt werden, sondern

00:42:42.700 --> 00:42:45.100
wo es dann Batch-Prozessen gibt,

00:42:45.100 --> 00:42:46.980
nachts. Also die Sparkassen haben das

00:42:46.980 --> 00:42:48.060
lange gemacht.

00:42:48.060 --> 00:42:51.200
Man schmeißt dann manuell die ausgedruckten

00:42:51.200 --> 00:42:52.780
Briefchen ins Überweisungs...

00:42:52.780 --> 00:42:55.280
Lochkarten. Fährt jemand mit den

00:42:55.280 --> 00:42:57.360
Lochkarten dahin, und dann kommen die in so einen Laser, und dann werden

00:42:57.360 --> 00:42:58.920
die da durch, und vielleicht, wenn dann eine Lochkarte rausfällt,

00:42:58.920 --> 00:43:00.680
dann ist halt eine Transaktion weg. Nicht so gut.

00:43:00.680 --> 00:43:03.180
Ja, aber kann, sowas kann tatsächlich

00:43:03.180 --> 00:43:05.140
passieren, und das ist natürlich etwas,

00:43:05.140 --> 00:43:07.000
was ja gerade bei der Bank eigentlich, wenn man sich

00:43:07.000 --> 00:43:09.140
denkt, na, sollte eigentlich nicht. Aber, ja,

00:43:09.140 --> 00:43:10.900
aber wenn man

00:43:10.900 --> 00:43:12.840
ein sauberes, relationales Datenbanksystem

00:43:12.840 --> 00:43:14.960
verwendet, dann

00:43:14.960 --> 00:43:17.120
kann das

00:43:17.120 --> 00:43:19.000
eigentlich nicht, oder sagen wir so, das bietet einem

00:43:19.000 --> 00:43:20.440
Lösungen für dieses Problem, und

00:43:20.440 --> 00:43:22.940
im Grunde, wenn

00:43:22.940 --> 00:43:24.900
das Ding sagt, ja, die Transaktion ist durch, dann

00:43:24.900 --> 00:43:27.060
hat das auch funktioniert. Man kann sich auch darauf verlassen.

00:43:27.340 --> 00:43:28.340
Ja, und auch

00:43:28.340 --> 00:43:29.980
davon an, welche Daten man verwendet.

00:43:29.980 --> 00:43:31.900
Es gibt halt welche, die nicht so richtig

00:43:31.900 --> 00:43:34.140
alle Features unterstützen, die man dafür braucht.

00:43:34.140 --> 00:43:34.940
Also, zum Beispiel,

00:43:34.940 --> 00:43:38.040
was man eigentlich dafür braucht, damit das ordentlich

00:43:38.040 --> 00:43:39.700
funktioniert, ist,

00:43:39.700 --> 00:43:41.680
man braucht halt Isolation

00:43:41.680 --> 00:43:44.040
zwischen unterschiedlichen

00:43:44.040 --> 00:43:46.040
Transaktionen. Also, Transaktion heißt eigentlich

00:43:46.040 --> 00:43:46.280
nur,

00:43:46.280 --> 00:43:50.120
dass man mehrere Schritte,

00:43:50.120 --> 00:43:51.240
die man ausführt,

00:43:51.240 --> 00:43:54.380
irgendwie zusammenbündelt,

00:43:54.380 --> 00:43:56.060
und dann halt entweder alle

00:43:56.060 --> 00:43:57.100
funktionieren, oder keiner.

00:43:57.340 --> 00:43:59.340
Ja, und das wäre halt

00:43:59.340 --> 00:44:01.260
genauso ein Fall, wie, ich kaufe

00:44:01.260 --> 00:44:03.500
ein Buch, ist halt ein Ding, in der Datenbank

00:44:03.500 --> 00:44:05.220
müssen jetzt mehrere Sachen passieren. Da muss halt

00:44:05.220 --> 00:44:05.520
irgendwie,

00:44:05.520 --> 00:44:09.240
diese Bestellung muss erzeugt werden, dann muss

00:44:09.240 --> 00:44:11.860
irgendwie aus dem Lagerstand

00:44:11.860 --> 00:44:12.660
irgendwie

00:44:12.660 --> 00:44:14.280
rausgelöscht, muss halt

00:44:14.280 --> 00:44:17.020
der Lagerbestand um eins reduziert werden,

00:44:17.020 --> 00:44:19.260
und so, und das sind halt

00:44:19.260 --> 00:44:20.820
mehrere Statements, die ausgeführt werden.

00:44:20.820 --> 00:44:22.780
Und jetzt müsste halt,

00:44:22.780 --> 00:44:23.800
wenn

00:44:23.800 --> 00:44:25.960
jemand anders in der Zeit

00:44:25.960 --> 00:44:27.320
das gekauft hat, und es

00:44:27.320 --> 00:44:30.540
dieser Bücher mehr auf Lager gibt,

00:44:30.540 --> 00:44:32.500
müsste halt dann

00:44:32.500 --> 00:44:33.800
nachdem

00:44:33.800 --> 00:44:37.060
der eine Teil der Transaktion, nämlich

00:44:37.060 --> 00:44:38.060
das Reduzieren

00:44:38.060 --> 00:44:41.600
des Lagerbestandes

00:44:41.600 --> 00:44:43.240
von diesem Buch nicht mehr funktioniert,

00:44:43.240 --> 00:44:45.040
müsste halt auch das andere, nämlich das Erzeugen der Bestellung,

00:44:45.040 --> 00:44:47.200
auch fehlschlagen, und dann halt eine Fehlermeldung

00:44:47.200 --> 00:44:48.820
zurückkommen. Und dann ist es halt sauber.

00:44:48.820 --> 00:44:51.300
Wenn ich jetzt ein System habe,

00:44:51.300 --> 00:44:52.660
das das nicht macht, und ich

00:44:52.660 --> 00:44:55.140
erzeuge die Bestellung, habe jetzt in meiner Bestellung

00:44:55.140 --> 00:44:56.840
eine Tabelle, das Ding erzeugt,

00:44:57.120 --> 00:44:58.740
sag jetzt in der

00:44:58.740 --> 00:44:59.880
Lagerstandstabelle

00:44:59.880 --> 00:45:02.840
dieses Buch eins weniger, und dann sagt das,

00:45:02.840 --> 00:45:04.980
hier habe ich eigentlich von Strand auf, es darf nicht

00:45:04.980 --> 00:45:07.000
weniger als null werden, also minus eins Bücher

00:45:07.000 --> 00:45:09.000
ist schwer, das funktioniert irgendwie

00:45:09.000 --> 00:45:10.940
nicht so richtig, dann sollte

00:45:10.940 --> 00:45:13.680
und es dann knallt,

00:45:13.680 --> 00:45:15.100
dann kann das natürlich,

00:45:15.100 --> 00:45:17.040
wenn ich jetzt ein System habe, das keine Transaktion kann,

00:45:17.040 --> 00:45:18.940
dann hätte ich jetzt die Bestellung zwar immer noch da,

00:45:18.940 --> 00:45:20.000
aber...

00:45:20.000 --> 00:45:23.120
Was ist denn jetzt als Beispiel, 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:27.080
minus ein Buch ist, dass das nachbestellt wird von

00:45:27.080 --> 00:45:29.000
dem Händler um die Ecke, also

00:45:29.000 --> 00:45:30.520
der hat noch eine Garage nebenan, ist noch ein Händler,

00:45:30.520 --> 00:45:33.060
der hat auch so Bücher, und vielleicht hat der eins

00:45:33.060 --> 00:45:35.000
da, und dann sage ich einfach, ja, ich muss das irgendwo anders herbekommen.

00:45:35.000 --> 00:45:37.000
Könnte ich ja auch wollen.

00:45:37.000 --> 00:45:38.180
Kann man auch machen,

00:45:38.180 --> 00:45:41.100
müsste dann, ja, das hängt dann vom System ab,

00:45:41.100 --> 00:45:42.920
was die Logik dann macht. Man könnte ja sagen,

00:45:42.920 --> 00:45:44.960
okay, die Bestellung wird trotzdem ausgeführt, dafür wird dann aber

00:45:44.960 --> 00:45:47.120
das... Oder das Buch wird gedruckt oder sowas, ne?

00:45:47.120 --> 00:45:48.140
Ziel, wann das... Ja, genau,

00:45:48.140 --> 00:45:49.940
wenn normal produziert,

00:45:49.940 --> 00:45:52.980
aber dann verändert sich möglicherweise das Ziel dafür, wann es halt

00:45:52.980 --> 00:45:55.080
ausgeliefert wird, oder so, ne?

00:45:55.080 --> 00:45:57.040
Und das ist halt dann, je nachdem, wie das System

00:45:57.040 --> 00:45:58.140
funktioniert, kann man das machen.

00:45:58.140 --> 00:46:01.220
Okay, also ich habe am Anfang mir so ein Schema ausgedacht, wo dann halt drinsteht,

00:46:01.220 --> 00:46:02.860
was ich überhaupt alles machen will, machen kann,

00:46:02.860 --> 00:46:04.960
und wenn mir irgendwelche neuen Dinge einfallen,

00:46:04.960 --> 00:46:07.000
oder so, dann muss ich kurz

00:46:07.000 --> 00:46:08.560
überlegen, was

00:46:08.560 --> 00:46:10.800
nicht an meinem Schema endet, aber

00:46:10.800 --> 00:46:12.980
am besten mache ich das Schema am Anfang schon so

00:46:12.980 --> 00:46:14.900
fertig, vollständig, dass das

00:46:14.900 --> 00:46:16.700
unproblematischer geht. Das ist halt,

00:46:16.700 --> 00:46:19.080
das ist ein bisschen ein Problem, man sollte ein Schema

00:46:19.080 --> 00:46:21.040
schon von Anfang an halbwegs so designen,

00:46:21.040 --> 00:46:22.200
dass es halt passt, das ist

00:46:22.200 --> 00:46:24.780
später nicht mehr so ganz einfach, das zu ändern,

00:46:24.780 --> 00:46:27.000
man kann das natürlich ändern, aber

00:46:27.000 --> 00:46:28.780
das ist auf jeden Fall...

00:46:28.780 --> 00:46:30.920
Ja, aber das hängt ja ein bisschen vom Geschäftsmodell ab, ne?

00:46:30.920 --> 00:46:32.780
Wenn ich jetzt auf einmal merke, so, oh, ich verkaufe

00:46:32.780 --> 00:46:34.100
jetzt vielleicht gar keine Bücher mehr, sondern,

00:46:34.100 --> 00:46:36.660
weiß nicht, kompliziertere Produkte, oder so was,

00:46:36.660 --> 00:46:38.840
die noch einen anderen Aufwand haben, die jetzt nicht nur getaggt

00:46:38.840 --> 00:46:40.500
werden sollen, sondern wo noch mehr

00:46:40.500 --> 00:46:42.120
Metainformationen drin sind, irgendwelche

00:46:42.120 --> 00:46:44.660
anderen Snippets, also der Buchtext vielleicht

00:46:44.660 --> 00:46:46.080
noch, oder andere

00:46:46.080 --> 00:46:48.480
Informationen, die dazugehören, oder so,

00:46:48.480 --> 00:46:52.260
dann wäre das ja notwendig.

00:46:52.260 --> 00:46:54.800
Ich kann ja nicht jedes Mal einen Neudankmann anfangen, sondern ich muss ja auch

00:46:54.800 --> 00:46:56.060
gucken, dass die irgendwie mit skaliert.

00:46:56.960 --> 00:46:58.800
Aber das sind wirklich schwierige Probleme,

00:46:58.800 --> 00:47:01.260
das ist ein bisschen unintuitiv,

00:47:01.260 --> 00:47:03.100
dass das so knifflig ist,

00:47:03.100 --> 00:47:05.000
aber es ist leider so. Ein wirklich

00:47:05.000 --> 00:47:06.580
lustiges Beispiel aus der Praxis,

00:47:06.580 --> 00:47:08.980
das zeigt, dass

00:47:08.980 --> 00:47:10.680
es halt nicht so einfach ist, möglicherweise

00:47:10.680 --> 00:47:12.460
ist, finde ich, iTunes,

00:47:12.460 --> 00:47:13.580
der App Store,

00:47:13.580 --> 00:47:16.180
und der App Store war am Anfang,

00:47:16.180 --> 00:47:18.480
man hat den nicht neu entwickelt, sondern das war,

00:47:18.480 --> 00:47:20.520
man hat den, also über iTunes

00:47:20.520 --> 00:47:22.780
konnte Apple ja schon immer irgendwie so Musik verkaufen,

00:47:22.780 --> 00:47:24.120
das hat auch recht gut funktioniert,

00:47:24.120 --> 00:47:26.860
oder halt deutlich früher,

00:47:26.920 --> 00:47:28.720
als es jetzt das iPhone gab und

00:47:28.720 --> 00:47:30.140
den App Store, und dann

00:47:30.140 --> 00:47:32.620
sollte es halt dieses App Store Feature geben,

00:47:32.620 --> 00:47:34.520
und dann haben sie halt einfach ihr

00:47:34.520 --> 00:47:36.480
iTunes-Song-Verkauf-Ding genommen,

00:47:36.480 --> 00:47:38.740
und das halt einfach nur gesagt,

00:47:38.740 --> 00:47:40.240
okay, das sind jetzt keine Songs, sondern das sind Apps.

00:47:40.240 --> 00:47:42.400
Was halt dazu führt, dass bis heute,

00:47:42.400 --> 00:47:44.740
und jetzt sind wir mehr als 10 Jahre später,

00:47:44.740 --> 00:47:47.300
bis heute

00:47:47.300 --> 00:47:48.860
haben halt irgendwie Apps einen Titel

00:47:48.860 --> 00:47:50.800
und eine Länge, Songlänge oder sowas,

00:47:50.800 --> 00:47:52.840
was halt totaler Quatsch ist, das passt ja überhaupt

00:47:52.840 --> 00:47:54.800
nicht zusammen, aber es ist halt sehr, sehr

00:47:54.800 --> 00:47:56.240
schwer, das zu ändern, weil,

00:47:56.880 --> 00:47:58.840
ja, das würde so viel Logik

00:47:58.840 --> 00:48:01.220
irgendwie brechen,

00:48:01.220 --> 00:48:02.740
dass in anderen Systemen,

00:48:02.740 --> 00:48:04.620
das ist halt extrem, also

00:48:04.620 --> 00:48:05.580
du kannst halt, ja,

00:48:05.580 --> 00:48:08.680
also eine solche Migration durchzuführen, ist halt hinterher

00:48:08.680 --> 00:48:10.360
sehr, sehr schwer, und

00:48:10.360 --> 00:48:12.440
also quasi die ganzen Daten einmal anfassen und

00:48:12.440 --> 00:48:14.580
abgleichen und bereinigen und schrubben und putzen.

00:48:14.580 --> 00:48:16.560
Die Daten sind gar nicht so sehr das Problem,

00:48:16.560 --> 00:48:18.920
das Problem sind die anderen Systeme,

00:48:18.920 --> 00:48:20.440
die es auch alle drumherum gibt, die sich verlassen,

00:48:20.440 --> 00:48:22.000
dass die Datenbanken so aussehen, wie sie aussehen.

00:48:22.000 --> 00:48:24.560
Also wenn ich jetzt, also die Daten selber zu ändern,

00:48:24.560 --> 00:48:26.060
ist, glaube ich, wäre nicht so das Problem,

00:48:26.840 --> 00:48:28.740
weil ich muss jeden Prozess bei jedem Nutzer dieser Datenbank

00:48:28.740 --> 00:48:30.500
darüber informieren, dass er sich das Schema...

00:48:30.500 --> 00:48:32.660
Und der muss damit klarkommen, und das

00:48:32.660 --> 00:48:34.220
ist halt möglicherweise Legacy-Code,

00:48:34.220 --> 00:48:36.480
der letzte, der sich damit auskannte,

00:48:36.480 --> 00:48:38.400
vor fünf Jahren gegangen ist, aber

00:48:38.400 --> 00:48:40.480
das System macht irgendwas Vitales, was irgendwie

00:48:40.480 --> 00:48:41.660
total wichtig ist für das

00:48:41.660 --> 00:48:44.560
Business, und, tja, dann

00:48:44.560 --> 00:48:46.440
wird es halt richtig schwer, und wenn du dann nicht nur

00:48:46.440 --> 00:48:47.920
ein solches System hast, sondern zig,

00:48:47.920 --> 00:48:50.780
dann kann es sein, dass du halt zehn Jahre lang das nicht mehr ändern kannst.

00:48:50.780 --> 00:48:52.740
Manchmal

00:48:52.740 --> 00:48:54.220
sieht man dann so ein bisschen lächerlich aus, aber

00:48:54.220 --> 00:48:56.120
wie jetzt in dem Apple-Fall,

00:48:56.800 --> 00:48:59.340
wenn man keine Songlänge hat,

00:48:59.340 --> 00:49:01.520
ja, aber

00:49:01.520 --> 00:49:03.280
es ist halt, das zeigt halt so ein bisschen,

00:49:03.280 --> 00:49:05.320
wie knifflig das dann werden kann,

00:49:05.320 --> 00:49:07.480
wenn man Pech hat.

00:49:07.480 --> 00:49:09.060
Ja,

00:49:09.060 --> 00:49:11.220
und das ist auch so ein Problem bei

00:49:11.220 --> 00:49:13.100
relationalen Datenbanken insgesamt,

00:49:13.100 --> 00:49:15.020
möglicherweise, würde ich sagen, also

00:49:15.020 --> 00:49:17.660
gerade der E-Commerce-Fall oder der Amazon-Fall

00:49:17.660 --> 00:49:19.640
funktioniert eigentlich ganz gut,

00:49:19.640 --> 00:49:21.320
zunächst, also später wird das dann halt auch

00:49:21.320 --> 00:49:23.500
nochmal ein bisschen problematischer, aber weil

00:49:23.500 --> 00:49:25.400
physische Dinge

00:49:25.400 --> 00:49:26.360
halt

00:49:26.760 --> 00:49:28.660
relativ stabil sind, was irgendwie so ihre

00:49:28.660 --> 00:49:30.640
Eigenschaften angeht. Also, da funktionieren

00:49:30.640 --> 00:49:32.300
relationale Datenbanken halt besonders gut.

00:49:32.300 --> 00:49:35.060
Unwahrscheinlich, dass so ein Buch noch ein anderes

00:49:35.060 --> 00:49:36.620
Kappa enthält, oder sowas.

00:49:36.620 --> 00:49:38.460
Also, dass sich Bücher jetzt irgendwie,

00:49:38.460 --> 00:49:40.600
dass die plötzlich ein Attribut bekommen, was

00:49:40.600 --> 00:49:42.180
es halt vorher nicht gab. Die wachsen Flügel.

00:49:42.180 --> 00:49:44.540
Die haben halt irgendwie Titel, Seitenanzahlen, oder sowas,

00:49:44.540 --> 00:49:46.140
aber dass jetzt plötzlich irgendwie, keine Ahnung,

00:49:46.140 --> 00:49:48.740
ich weiß nicht, was man sich da

00:49:48.740 --> 00:49:50.560
vorstellen könnte, man müsste jetzt irgendwie

00:49:50.560 --> 00:49:52.620
Bücher...

00:49:52.620 --> 00:49:54.420
Jedes Buch enthält einen Geist,

00:49:54.420 --> 00:49:56.460
Bücher haben Flügel,

00:49:56.720 --> 00:50:00.120
ja, keine Ahnung,

00:50:00.120 --> 00:50:02.080
Bücher kann man jetzt essen, oder so, haben einen bestimmten Geschmack.

00:50:02.080 --> 00:50:04.360
Das ist sehr unwahrscheinlich, dass das passiert, weil

00:50:04.360 --> 00:50:06.400
das würde bedeuten, dass sich die physikalische

00:50:06.400 --> 00:50:07.980
Realität irgendwie ändert, was sie ja

00:50:07.980 --> 00:50:08.960
natürlich auch tut.

00:50:08.960 --> 00:50:12.500
Aber das tut sie relativ langsam.

00:50:12.500 --> 00:50:14.700
Und das ist gut,

00:50:14.700 --> 00:50:15.840
weil das können relativ,

00:50:15.840 --> 00:50:18.300
wenn man jetzt sozusagen diese

00:50:18.300 --> 00:50:20.400
physischen Dinge in der Datenbank beschrieben hat, die kann sich

00:50:20.400 --> 00:50:22.300
auch nur langsam ändern. Und das passt dann so ein bisschen

00:50:22.300 --> 00:50:24.340
zueinander. Also, das ist halt, wenn man

00:50:24.340 --> 00:50:26.440
jetzt die Eigenschaften von einem Buch erstmal erfasst hat, dann ändert sich

00:50:26.440 --> 00:50:26.680
da wahrscheinlich nichts.

00:50:26.680 --> 00:50:28.620
Da ist wahrscheinlich in den nächsten 20 Jahren nicht mehr so wahnsinnig viel dran.

00:50:28.620 --> 00:50:30.740
Und da muss man auch in der Datenbank nicht so wahnsinnig viel ändern.

00:50:30.740 --> 00:50:32.840
Wenn man jetzt ein anderes

00:50:32.840 --> 00:50:34.720
Problem hat, und man jetzt

00:50:34.720 --> 00:50:36.480
zum Beispiel in der Datenbank nicht Daten

00:50:36.480 --> 00:50:38.280
über physikalische Objekte hält,

00:50:38.280 --> 00:50:40.280
sondern Daten über Daten.

00:50:40.280 --> 00:50:42.740
Oh, Metadaten.

00:50:42.740 --> 00:50:43.680
Metadaten.

00:50:43.680 --> 00:50:46.480
Die können sich dummerweise

00:50:46.480 --> 00:50:48.680
unter Umständen, je nachdem wie...

00:50:48.680 --> 00:50:50.540
Daten über Daten über Daten.

00:50:50.540 --> 00:50:52.400
Ja, da kann plötzlich die

00:50:52.400 --> 00:50:54.620
Geschwindigkeit, mit der sich die Strukturen da ändern

00:50:54.620 --> 00:50:56.640
müssen, deutlich schneller

00:50:56.640 --> 00:50:58.540
werden. Und dann wird es schwierig. Dann sind relationale

00:50:58.540 --> 00:51:00.120
Datenbanken auch so, das ist dann ein Problem.

00:51:00.120 --> 00:51:02.560
Das ist auch möglicherweise einer der Gründe dafür,

00:51:02.560 --> 00:51:04.340
warum jetzt in letzter Zeit halt immer mehr so

00:51:04.340 --> 00:51:06.500
NoSQL oder

00:51:06.500 --> 00:51:08.200
Dokumentdatenbanken

00:51:08.200 --> 00:51:10.020
oder

00:51:10.020 --> 00:51:12.080
wenn man das, manche nennen das auch

00:51:12.080 --> 00:51:13.980
Schema-less, warum die halt

00:51:13.980 --> 00:51:16.620
populärer werden, weil man damit

00:51:16.620 --> 00:51:18.440
halt möglicherweise auf diese geänderten Anforderungen

00:51:18.440 --> 00:51:20.140
halt besser reagieren kann, dass man

00:51:20.140 --> 00:51:22.180
ja, möglicherweise ad hoc

00:51:22.180 --> 00:51:24.440
das Schema irgendwie ändern muss und das halt

00:51:24.440 --> 00:51:26.100
in der relationalen Datenbank nicht so ganz einfach ist.

00:51:26.600 --> 00:51:28.600
So absolut kann man das auch nicht sagen. Also es gibt

00:51:28.600 --> 00:51:30.120
da diverse Möglichkeiten, wie man die

00:51:30.120 --> 00:51:32.520
Geschichten miteinander verbinden kann und

00:51:32.520 --> 00:51:34.140
ja,

00:51:34.140 --> 00:51:36.460
wenn Schema-less ist, halt auch nicht

00:51:36.460 --> 00:51:38.400
Schema-less, sondern das bedeutet halt mehr oder

00:51:38.400 --> 00:51:40.580
weniger nur, dass das Schema jetzt implizit

00:51:40.580 --> 00:51:42.440
in deiner Applikation ist und du halt

00:51:42.440 --> 00:51:44.460
immer aufpassen musst, wenn du deine Applikation änderst, dass du

00:51:44.460 --> 00:51:46.520
da das Schema nicht kaputt machst oder änderst oder so

00:51:46.520 --> 00:51:48.480
und das überlegen sich viele Leute

00:51:48.480 --> 00:51:50.580
dann nicht so richtig und dann ändern sie irgendwas. Dann passieren

00:51:50.580 --> 00:51:51.560
furchtbare Dinge und

00:51:51.560 --> 00:51:54.020
dann fällt ihnen auf, dass sie doch ein Schema haben.

00:51:56.560 --> 00:51:58.520
Und ja, dass sie dieses Problem halt doch nicht

00:51:58.520 --> 00:52:00.400
losgeworden sind. Also

00:52:00.400 --> 00:52:02.540
es ist leider alles nicht so einfach und

00:52:02.540 --> 00:52:04.640
das ist

00:52:04.640 --> 00:52:06.520
tatsächlich so, dass man bei

00:52:06.520 --> 00:52:08.420
Datenbanken halt im Design

00:52:08.420 --> 00:52:10.440
am Anfang ein bisschen mehr Arbeit hat, aber dafür

00:52:10.440 --> 00:52:12.580
hat man auch dann einen lustigen Vorteil,

00:52:12.580 --> 00:52:14.560
nämlich, ja, es ist immer so schön, irgendwie

00:52:14.560 --> 00:52:16.000
Daten

00:52:16.000 --> 00:52:18.160
altern wie Wein, ja, also wenn man halt

00:52:18.160 --> 00:52:20.500
viele gute Daten hat, das ist super und wenn

00:52:20.500 --> 00:52:22.420
das mehr werden, das ist immer schön und das altert auch

00:52:22.420 --> 00:52:24.000
gut, ja, das wird immer besser mit der Zeit.

00:52:24.000 --> 00:52:26.520
Man kann immer mehr Wissen daraus generieren,

00:52:26.520 --> 00:52:28.520
man kann immer mehr Fragen beantworten oder so,

00:52:28.520 --> 00:52:30.080
das ist eine sehr schöne Sache und

00:52:30.080 --> 00:52:32.360
Applikationscode,

00:52:32.360 --> 00:52:33.860
Altert wie Fisch,

00:52:33.860 --> 00:52:36.500
ja, also das ist

00:52:36.500 --> 00:52:38.380
nicht gut, wenn immer Features drankommen

00:52:38.380 --> 00:52:40.400
oder Sachen geändert werden, also das wird immer

00:52:40.400 --> 00:52:42.420
schlimmer mit der Zeit. Das ist eigentlich selten

00:52:42.420 --> 00:52:44.600
so, dass man irgendwie jetzt mehrere Jahre

00:52:44.600 --> 00:52:46.580
irgendwie ein Projekt entwickelt und die Codequalität

00:52:46.580 --> 00:52:48.300
wird immer besser. Das ist irgendwie

00:52:48.300 --> 00:52:49.460
nicht so, sondern es wird immer,

00:52:49.460 --> 00:52:52.260
es wird irgendwie, und daher ist halt

00:52:52.260 --> 00:52:53.980
noch ein Frickel da, noch ein Frickel dort,

00:52:53.980 --> 00:52:55.880
kleines Modülchen an der Seite,

00:52:56.480 --> 00:52:58.540
und auch das Problem ist halt, die Anforderungen

00:52:58.540 --> 00:52:59.760
verschieben sich halt irgendwie

00:52:59.760 --> 00:53:02.480
oder, sagen wir mal so, die Realität

00:53:02.480 --> 00:53:04.140
ändert sich und dann ist halt

00:53:04.140 --> 00:53:06.460
der ursprüngliche Plan oder die

00:53:06.460 --> 00:53:08.320
ursprüngliche Architektur der Applikation ist halt

00:53:08.320 --> 00:53:09.540
nicht mehr darauf angepasst und so

00:53:09.540 --> 00:53:12.460
und da hat man

00:53:12.460 --> 00:53:14.420
dann halt, ja, genau

00:53:14.420 --> 00:53:15.800
dieses Problem,

00:53:15.800 --> 00:53:18.360
dass, wenn man jetzt das Schema verlagert

00:53:18.360 --> 00:53:20.260
in die Applikation und die Applikation aber

00:53:20.260 --> 00:53:22.180
altert wie Fisch, dann halt man halt auch, ja,

00:53:22.180 --> 00:53:23.880
dann altern auch die Daten nicht gut und

00:53:23.880 --> 00:53:26.440
deswegen ist es eigentlich schon sinnvoll, eine Trennlinie zu haben,

00:53:26.440 --> 00:53:28.440
um zu sagen, okay, selbst wenn wir die

00:53:28.440 --> 00:53:30.500
Applikation irgendwann wegschmeißen müssen,

00:53:30.500 --> 00:53:32.460
neu schreiben müssen oder so, dann haben wir immer noch

00:53:32.460 --> 00:53:34.340
die Daten und die sind halt sauber

00:53:34.340 --> 00:53:36.360
strukturiert und das sieht alles gut aus

00:53:36.360 --> 00:53:38.700
und das kann eine sehr wertvolle

00:53:38.700 --> 00:53:40.260
Sache sein, wenn man das richtig macht

00:53:40.260 --> 00:53:42.220
und, ja,

00:53:42.220 --> 00:53:44.620
genau,

00:53:44.620 --> 00:53:46.560
deswegen ist diese Trennung,

00:53:46.560 --> 00:53:48.400
wo man halt irgendwie strikte,

00:53:48.400 --> 00:53:50.080
ein striktes Schema hat und das

00:53:50.080 --> 00:53:52.580
auch diverse Constraints,

00:53:52.580 --> 00:53:54.520
die halt irgendwie, also dass man halt solche Sachen drin hat,

00:53:54.520 --> 00:53:56.400
wie es kann nicht im Lager

00:53:56.400 --> 00:53:57.020
Sachen geben,

00:53:57.020 --> 00:54:00.440
mit einem Lagerstand von Minus irgendwas,

00:54:00.440 --> 00:54:02.420
das darf halt nicht sein, da ist ein Fehler passiert

00:54:02.420 --> 00:54:04.200
und kann die Datenbank schon dafür sorgen,

00:54:04.200 --> 00:54:06.480
dass das halt nicht da reingeschrieben

00:54:06.480 --> 00:54:08.080
wird, weil die sagt halt so, nee, so nicht,

00:54:08.080 --> 00:54:10.140
man muss halt bloß dieses Constraint definieren und sagen, so,

00:54:10.140 --> 00:54:12.340
auf dieser Spalte, da dürfen keine negativen Werte

00:54:12.340 --> 00:54:14.140
auftauchen oder eben sowas wie ein Gehalt,

00:54:14.140 --> 00:54:15.960
das darf auch nicht negativ werden oder

00:54:15.960 --> 00:54:16.940
das halt

00:54:16.940 --> 00:54:20.260
bestimmte Datumsinformationen halt nicht

00:54:20.260 --> 00:54:21.540
so und so sein können,

00:54:21.540 --> 00:54:22.740
ja,

00:54:22.740 --> 00:54:24.740
oder

00:54:24.740 --> 00:54:25.420
dass man halt,

00:54:26.360 --> 00:54:28.260
tatsächlich, auch

00:54:28.260 --> 00:54:30.620
was man mit Postgres machen kann, Postgres ist halt

00:54:30.620 --> 00:54:32.900
wirklich eine schöne Wahl für, wenn man jetzt mit so einer

00:54:32.900 --> 00:54:33.580
Geschichte anfängt,

00:54:33.580 --> 00:54:36.180
das kann so tolle Sachen wie,

00:54:36.180 --> 00:54:37.360
wenn wir jetzt,

00:54:37.360 --> 00:54:40.560
um in diesem Buchhandelsbeispiel zu bleiben,

00:54:40.560 --> 00:54:42.020
du hast jetzt eine Büchertabelle,

00:54:42.020 --> 00:54:44.520
da sind natürlich auch alte Bücher drin, weil die werden ja auch

00:54:44.520 --> 00:54:46.700
möglicherweise referenziert

00:54:46.700 --> 00:54:48.300
von Bestellungen, die

00:54:48.300 --> 00:54:50.560
lange

00:54:50.560 --> 00:54:52.500
zurückliegen oder so, du möchtest aber,

00:54:52.500 --> 00:54:54.520
wenn du jetzt eine Suche irgendwie auf der

00:54:54.520 --> 00:54:56.100
Website hast oder du hast halt irgendwie

00:54:56.100 --> 00:54:58.240
so eine Facette Navigation, wo

00:54:58.240 --> 00:54:59.740
du nach Kategorien einschränken kannst

00:54:59.740 --> 00:55:01.500
und da klickt jetzt ein User drauf

00:55:01.500 --> 00:55:03.720
und sagt, okay, ich hätte jetzt da gerne

00:55:03.720 --> 00:55:05.940
Romane oder Seefahrer-Romane,

00:55:05.940 --> 00:55:07.520
dann

00:55:07.520 --> 00:55:09.960
gibt es einen Index, der das halt schnell macht,

00:55:09.960 --> 00:55:12.100
diese Abfrage und du willst jetzt

00:55:12.100 --> 00:55:13.880
aber Sachen von diesem Index ausschließen,

00:55:13.880 --> 00:55:16.100
zum Beispiel Bücher, die es gar nicht mehr gibt,

00:55:16.100 --> 00:55:17.940
die nicht mehr produziert werden, die vor Jahren

00:55:17.940 --> 00:55:20.260
irgendwie nicht mehr, seit Jahren nicht mehr gedruckt

00:55:20.260 --> 00:55:22.060
werden und das kann man mit Postgres tun, man kann

00:55:22.060 --> 00:55:23.180
dann sagen so, also

00:55:23.180 --> 00:55:26.060
ich brauche diese Einträge,

00:55:26.060 --> 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:31.900 --> 00:55:33.460
die ja brechen würde, wenn ich

00:55:33.460 --> 00:55:36.020
zu einfach löschen würde, dann hätte ich

00:55:36.020 --> 00:55:37.920
halt einen Pointer in der Bestellungstabelle,

00:55:37.920 --> 00:55:39.480
der halt auch etwas zeigt, was es nicht mehr gibt,

00:55:39.480 --> 00:55:42.060
das wäre schlecht, weil ich dann gar nicht mehr

00:55:42.060 --> 00:55:42.800
weiß, was es sein soll und so,

00:55:42.800 --> 00:55:46.000
aber trotzdem werden diese Dinger

00:55:46.000 --> 00:55:47.980
nicht mehr in den Index geschrieben, also

00:55:47.980 --> 00:55:49.900
ich kann halt den Index so definieren, dass er nur

00:55:49.900 --> 00:55:51.560
Sachen,

00:55:51.560 --> 00:55:54.180
Bücher mit reinnimmt,

00:55:54.180 --> 00:55:55.840
die halt auch tatsächlich noch verkauft werden,

00:55:56.060 --> 00:55:57.840
und das heißt, das ist nicht so,

00:55:57.840 --> 00:56:00.100
und an solchen Stellen ist Postgres halt sehr schön,

00:56:00.100 --> 00:56:01.160
hat sehr viele Features,

00:56:01.160 --> 00:56:04.020
zum Beispiel jetzt im Unterschied zu MySQL, wo das

00:56:04.020 --> 00:56:05.980
halt so, solche Sachen gehen da gar nicht, also das

00:56:05.980 --> 00:56:08.060
halt, und da hast du dann halt ein Problem, wenn du ganz,

00:56:08.060 --> 00:56:09.980
bei Büchern ist es jetzt nicht so schlimm, also

00:56:09.980 --> 00:56:11.200
so viele Bücher gibt es nicht und

00:56:11.200 --> 00:56:14.060
so viele, die dann halt nicht mehr

00:56:14.060 --> 00:56:15.940
verkauft werden, auch nicht, aber man könnte sich

00:56:15.940 --> 00:56:17.900
vorstellen, es gibt durchaus Anwendungen, wo man dieses

00:56:17.900 --> 00:56:20.080
Problem ganz massiv bekommt, dass man halt

00:56:20.080 --> 00:56:21.920
eine Menge gelöschte Geschichten in der Tabelle hat,

00:56:21.920 --> 00:56:24.060
die man aber nicht wirklich löschen kann, sondern nur als gelöscht markiert,

00:56:24.060 --> 00:56:25.960
und dann der Index aber,

00:56:26.020 --> 00:56:27.560
immer größer wird und langsamer wird, weil

00:56:27.560 --> 00:56:30.060
ja, man halt nicht so einen partiellen

00:56:30.060 --> 00:56:31.180
Index über Sachen haben kann.

00:56:31.180 --> 00:56:34.100
Ja, überhaupt, Postgres kann

00:56:34.100 --> 00:56:36.100
halt auch noch diverse andere Geschichten, damit könnte man halt auch so Sachen

00:56:36.100 --> 00:56:38.100
lösen, wie, welche Pakete kriege ich

00:56:38.100 --> 00:56:40.000
eigentlich in so einen Lieferwagen rein und so, weil

00:56:40.000 --> 00:56:41.380
der kann halt, das Ding kann halt nicht nur

00:56:41.380 --> 00:56:44.080
so B-Trees, die man

00:56:44.080 --> 00:56:44.780
jetzt für

00:56:44.780 --> 00:56:48.020
Textabfragen,

00:56:48.020 --> 00:56:49.980
Indexabfragen benutzt, also dass man sagt,

00:56:49.980 --> 00:56:50.400
welche

00:56:50.400 --> 00:56:53.900
Kategorie beginnt jetzt mit folgenden drei Buchstaben

00:56:53.900 --> 00:56:55.980
oder so, da nimmt man B-Tree, aber

00:56:55.980 --> 00:56:57.740
es kann halt auch solche Sachen wie Polygone,

00:56:57.740 --> 00:56:59.660
Abmessungen,

00:56:59.660 --> 00:57:01.660
überdeckt das eine das andere,

00:57:01.660 --> 00:57:03.820
es kann halt so

00:57:03.820 --> 00:57:05.300
A-Trees, die man halt für diese ganzen

00:57:05.300 --> 00:57:07.920
räumlichen Datengeschichten braucht,

00:57:07.920 --> 00:57:09.680
aber es kann nicht nur das, sondern es kann auch so Sachen wie,

00:57:09.680 --> 00:57:11.420
welche Sachen liegen nah an anderen, so

00:57:11.420 --> 00:57:13.180
KD-Trees, Brawl-Trees,

00:57:13.180 --> 00:57:15.620
es kann sogar Suffix-Trees, also

00:57:15.620 --> 00:57:17.420
Postgres kann da eine ganze Menge unterschiedlicher

00:57:17.420 --> 00:57:19.120
Abfragen und Indizes,

00:57:19.120 --> 00:57:21.600
die man, also

00:57:21.600 --> 00:57:23.740
Aber ich glaube, die lohnen sich jetzt noch nicht bei unserem

00:57:23.740 --> 00:57:25.060
kleinen Laden, wir sind ja glaube ich noch,

00:57:25.060 --> 00:57:25.800
Doch, doch,

00:57:25.940 --> 00:57:27.580
Ja, ja, wenn du

00:57:27.580 --> 00:57:29.920
deine Lagerhaltung,

00:57:29.920 --> 00:57:31.780
das möchtest du im gleichen System machen, damit

00:57:31.780 --> 00:57:33.440
du nicht das Problem kriegst,

00:57:33.440 --> 00:57:35.600
dass du den Start-State zwischen

00:57:35.600 --> 00:57:37.800
unterschiedlichen Systemen synchronisieren musst, also wenn du

00:57:37.800 --> 00:57:39.720
jetzt deine Lagerhaltung in einem System machst und

00:57:39.720 --> 00:57:41.800
machst dann deine Webseite

00:57:41.800 --> 00:57:43.860
oder die Datenbank, die die Webseite

00:57:43.860 --> 00:57:45.900
betreibt,

00:57:45.900 --> 00:57:47.760
sozusagen, über die du

00:57:47.760 --> 00:57:49.420
Bücher verkaufst, wenn das unterschiedliche Systeme sind,

00:57:49.420 --> 00:57:51.680
dann musst du den State zwischen diesen Systemen ja

00:57:51.680 --> 00:57:53.660
irgendwie synchronisieren.

00:57:53.660 --> 00:57:55.900
Was

00:57:55.900 --> 00:57:57.660
schlecht ist, würde ich zum Beispiel sagen,

00:57:57.660 --> 00:57:58.940
das ist halt am Anfang

00:57:58.940 --> 00:58:01.900
sehr, sehr hilfreich, wenn das alles ein System ist,

00:58:01.900 --> 00:58:03.660
weil man dann eben

00:58:03.660 --> 00:58:05.780
tatsächlich eben die referenzielle Integrität,

00:58:05.780 --> 00:58:07.680
Constraints, über alle Daten

00:58:07.680 --> 00:58:09.880
hinweg machen kann und dann von der

00:58:09.880 --> 00:58:11.560
Datenbank sicherstellen lassen kann schon, dass

00:58:11.560 --> 00:58:13.580
bestimmte Sachen nicht gehen und dass bestimmte

00:58:13.580 --> 00:58:14.660
Sachen immer erfüllt sein müssen.

00:58:14.660 --> 00:58:17.500
Das heißt, unser Schema setzt das dann tatsächlich fest und das

00:58:17.500 --> 00:58:19.140
kommt dann sonst direkt ein Fehler aus der Datenbank, hey,

00:58:19.140 --> 00:58:21.220
nur dürfen wir nicht, geht nicht und wir haben das Schema

00:58:21.220 --> 00:58:23.620
dabei erarbeitet in unseren kleinen Laden und so sollten wir dann

00:58:23.620 --> 00:58:25.860
Und dann kann dann die Applikation oder die Programmierer

00:58:25.860 --> 00:58:26.820
die jetzt vielleicht gar nicht,

00:58:26.820 --> 00:58:29.500
die Leute, die die Webseite bauen, die haben jetzt

00:58:29.500 --> 00:58:30.960
vielleicht gar nicht so viel Ahnung von Lagerhaltung,

00:58:30.960 --> 00:58:33.520
die können aber, egal was sie auf der Datenbank machen, sie können nichts

00:58:33.520 --> 00:58:35.680
kaputt machen, weil wenn sie etwas

00:58:35.680 --> 00:58:37.160
tun, was eigentlich nicht geht, wie zum Beispiel

00:58:37.160 --> 00:58:39.080
einen Lagerstand von hoch auf minus eins setzen,

00:58:39.080 --> 00:58:40.880
dann sagt ihnen die Datenbank, ne, mach ich nicht.

00:58:40.880 --> 00:58:43.560
Und dann kriegen sie halt einen Fehler. Und das ist

00:58:43.560 --> 00:58:45.720
halt sauber, weil wenn du jetzt zwei Systeme hättest

00:58:45.720 --> 00:58:47.680
und musst jetzt da synchronisieren

00:58:47.680 --> 00:58:49.000
und jetzt ist aber schon irgendwie was Blödes passiert.

00:58:49.000 --> 00:58:50.800
Der Datenbank steht jetzt minus zwei Bücher und dann

00:58:50.800 --> 00:58:53.500
sagt die eine Datenbank, du sagst aber eigentlich nicht, dann sagt die

00:58:53.500 --> 00:58:55.620
eine Datenbank, ja, hab ich aber. Und dann, ja, okay.

00:58:55.820 --> 00:58:57.200
Da kommst du halt in Teufels Küche.

00:58:57.200 --> 00:58:59.400
Also man könnte sich vorstellen, dass das eine gute Idee wäre,

00:58:59.400 --> 00:59:01.700
weil das macht, dann wird man halt relativ schnell feststellen,

00:59:01.700 --> 00:59:03.180
ist keine gute Idee, ist doof.

00:59:03.180 --> 00:59:07.900
Das ist auch vielleicht ein bisschen unintuitiv,

00:59:07.900 --> 00:59:09.700
aber ja. Und natürlich,

00:59:09.700 --> 00:59:11.580
nachher muss man Sachen funktionierender

00:59:11.580 --> 00:59:13.560
rausnehmen und man muss dann das

00:59:13.560 --> 00:59:15.580
in mehrere Systeme aufkleinern. 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:19.500 --> 00:59:21.360
Ja.

00:59:21.360 --> 00:59:23.640
Genau.

00:59:23.640 --> 00:59:25.400
Also wo sind wir jetzt eigentlich genau?

00:59:25.780 --> 00:59:27.320
Klein und niedlich, wir haben

00:59:27.320 --> 00:59:29.440
Postgres, machen alles

00:59:29.440 --> 00:59:31.360
über Postgres, wir haben noch ein bisschen JavaScript

00:59:31.360 --> 00:59:33.400
auf der Client-Seite, ansonsten

00:59:33.400 --> 00:59:35.280
nehmen wir, sagen wir mal, Django oder so

00:59:35.280 --> 00:59:36.480
als Web-Framework.

00:59:36.480 --> 00:59:39.700
Also genau, jetzt kommen wir erstmal zu

00:59:39.700 --> 00:59:40.320
wie machen wir jetzt Python?

00:59:40.320 --> 00:59:43.540
Genau, da brauchen

00:59:43.540 --> 00:59:45.440
wir halt irgendeine Art, wie wir auf die Datenbank

00:59:45.440 --> 00:59:46.360
zugreifen.

00:59:46.360 --> 00:59:49.260
Üblicherweise, wie man

00:59:49.260 --> 00:59:51.320
Statements oder Abfragen an eine Datenbank formuliert, ist halt

00:59:51.320 --> 00:59:53.360
SQL, heutzutage halt so der Standard

00:59:53.360 --> 00:59:54.720
für solche Systeme.

00:59:55.740 --> 00:59:58.920
Aber das ist halt immer ein bisschen Fremdkörper.

00:59:59.960 --> 01:00:01.760
Code schreiben und dann hat man jetzt so ein

01:00:01.760 --> 01:00:03.840
SQL-Statement. Das passt von der Syntax her

01:00:03.840 --> 01:00:05.740
überhaupt nicht in Python rein. Da muss man einen langen String

01:00:05.740 --> 01:00:07.760
machen, der irgendwie vernünftig aussieht und

01:00:07.760 --> 01:00:09.700
da muss dann alles stehen, was mit der Datenbank reden kann.

01:00:09.700 --> 01:00:11.480
Genau, und das ist halt irgendwie

01:00:11.480 --> 01:00:13.920
nicht so schön. Also das gibt dann unterschiedliche

01:00:13.920 --> 01:00:15.880
Methoden. Wenn man jetzt

01:00:15.880 --> 01:00:17.840
tatsächlich mit den rohen Statements arbeitet, es gibt Leute,

01:00:17.840 --> 01:00:19.840
die packen halt alle Statements in

01:00:19.840 --> 01:00:21.860
ein File und packen dann

01:00:21.860 --> 01:00:23.760
Funktionen drum und dann ruft man halt diese Funktionen auf.

01:00:23.760 --> 01:00:25.900
Das kann man machen, das hat so

01:00:25.900 --> 01:00:27.780
Vor- und Nachteile. Dann kann man aber auch sagen,

01:00:27.780 --> 01:00:29.480
okay, das ist aber schlecht, eigentlich möchte ich

01:00:29.480 --> 01:00:31.860
in dem Moment, wo ich mit den Daten arbeite, das Statement

01:00:31.860 --> 01:00:33.800
auch sehen und auch ändern können. Dann

01:00:33.800 --> 01:00:35.900
packt man halt sozusagen die Statements

01:00:35.900 --> 01:00:37.740
immer an die Stelle, wo man halt

01:00:37.740 --> 01:00:39.300
tatsächlich mit den Daten arbeitet. Das hat

01:00:39.300 --> 01:00:41.840
auch wiederum Vor- und Nachteile. Das hat den Vorteil, dass man halt

01:00:41.840 --> 01:00:43.440
Sachen leicht ändern kann. Das hat den Nachteil,

01:00:43.440 --> 01:00:45.920
dass man unter Umständen mehrere Statements,

01:00:45.920 --> 01:00:47.680
die sehr ähnlich oder gleich sind, an

01:00:47.680 --> 01:00:48.600
unterschiedlichen Stellen hat.

01:00:48.600 --> 01:00:51.340
Alles nicht so total toll.

01:00:51.340 --> 01:00:53.820
Auch nicht so ein einfaches Problem.

01:00:53.820 --> 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:00:59.000
sind so

01:00:59.000 --> 01:01:00.300
objektrelationale Mapper

01:01:00.300 --> 01:01:00.980
oder ORMs.

01:01:00.980 --> 01:01:04.140
In Django ist einer eingebaut.

01:01:04.140 --> 01:01:06.020
Der Django ORM.

01:01:06.020 --> 01:01:08.200
Ja, genau. Wo man dann halt

01:01:08.200 --> 01:01:10.220
gar nicht wirklich mitkriegt,

01:01:10.220 --> 01:01:12.020
dass das SQL unten drunter ist, sondern

01:01:12.020 --> 01:01:14.280
man schreibt halt ganz normale

01:01:14.280 --> 01:01:15.600
Python-Code.

01:01:15.600 --> 01:01:18.760
Man definiert

01:01:18.760 --> 01:01:20.460
die Daten, die man in der Datenbank stehen haben

01:01:20.460 --> 01:01:21.900
möchte, einfach nur als Klassen.

01:01:21.900 --> 01:01:24.280
Das heißt, das Schema wird nochmal

01:01:24.280 --> 01:01:25.520
als Klasse eingebaut, oder?

01:01:25.520 --> 01:01:28.520
Das Schema entsteht dadurch,

01:01:28.520 --> 01:01:30.620
dass man unterschiedliche Klassen

01:01:30.620 --> 01:01:32.420
hat, die irgendwie in Beziehung zueinander stehen.

01:01:32.420 --> 01:01:34.500
Also, was aufeinander neppt,

01:01:34.500 --> 01:01:35.540
ist halt Klasse und Tabelle.

01:01:35.540 --> 01:01:38.420
Also, ich hätte dann, wenn ich Bücher kaufen möchte, halt eine

01:01:38.420 --> 01:01:38.940
Klasse Book.

01:01:38.940 --> 01:01:42.080
Und dann hätte ich halt vielleicht eine Klasse

01:01:42.080 --> 01:01:43.560
Tag. Und

01:01:43.560 --> 01:01:46.220
wir hatten das ja eben mit dem Beispiel, ich habe eine

01:01:46.220 --> 01:01:48.300
N-zu-M-Beziehung zwischen Tags und

01:01:48.300 --> 01:01:50.380
Büchern. Und dann würde man

01:01:50.380 --> 01:01:52.540
entweder 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:57.860 --> 01:01:59.420
Tags ist halt ein

01:01:59.420 --> 01:02:01.700
wie heißt

01:02:01.700 --> 01:02:03.240
das in Django?

01:02:03.240 --> 01:02:04.760
Weiß jetzt irgendwie

01:02:04.760 --> 01:02:07.340
irgendwas, Foreign Key Field

01:02:07.340 --> 01:02:08.840
irgendwas, aber man sagt halt, das ist halt

01:02:08.840 --> 01:02:10.660
Many-to-Many-Relation irgendwas.

01:02:10.660 --> 01:02:13.380
Weiß ich nicht, muss ich nachgucken. Aber auf jeden Fall definiert man

01:02:13.380 --> 01:02:15.040
das halt wie eine Spalte in der

01:02:15.040 --> 01:02:17.540
Tabelle. Also, Attribute

01:02:17.540 --> 01:02:18.920
der Klasse sind halt Spalten in der Tabelle.

01:02:18.920 --> 01:02:21.400
Und sagt man halt, das hier ist ein Many-to-Many-Beziehung

01:02:21.400 --> 01:02:23.260
zu der Relation

01:02:23.260 --> 01:02:25.460
Tags. Und dann hat man

01:02:25.460 --> 01:02:27.480
die Link-Tabelle wird automatisch erzeugt. Man kriegt

01:02:27.480 --> 01:02:28.040
das gar nicht mit.

01:02:28.040 --> 01:02:31.420
Und im Code

01:02:31.420 --> 01:02:33.340
hat man halt nur Bücher und Tags und halt

01:02:33.340 --> 01:02:35.060
dann diese Beziehungen dazwischen. Und dann

01:02:35.060 --> 01:02:38.840
ja, wenn man

01:02:38.840 --> 01:02:40.400
sich das halt so hindefiniert hat

01:02:40.400 --> 01:02:42.960
und dann halt alle Klassen, die man so braucht, beziehungsweise

01:02:42.960 --> 01:02:45.000
alle Tabellen, die man halt irgendwie in der Datenbank haben möchte,

01:02:45.000 --> 01:02:47.440
definiert hat mit den Spalten

01:02:47.440 --> 01:02:49.120
und den Typen der Spalten und den

01:02:49.120 --> 01:02:50.840
entsprechenden Constraints und den Indices und den ganzen

01:02:50.840 --> 01:02:52.680
Kladderadatsch, die man auch sonst noch so braucht,

01:02:52.680 --> 01:02:54.440
dann sagt man

01:02:54.440 --> 01:02:57.000
Migrate

01:02:57.000 --> 01:02:59.220
und dann werden die ganzen

01:02:59.220 --> 01:03:01.100
Tabellen in der Datenbank

01:03:01.100 --> 01:03:01.860
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.820
diese Migrationen tun sollen. Nämlich zum Beispiel irgendwie

01:03:16.820 --> 01:03:17.760
Tabellen anlegen,

01:03:17.760 --> 01:03:20.940
Indizes anlegen oder sonst irgendwas.

01:03:20.940 --> 01:03:22.940
In die kann man auch beliebige andere Dinge

01:03:22.940 --> 01:03:25.000
reinschreiben. Also man kann halt auch selber Migrationen

01:03:26.620 --> 01:03:28.360
einfach so von Hand schreiben.

01:03:28.360 --> 01:03:30.200
Wenn man zum Beispiel jetzt sowas wie, es gibt so

01:03:30.200 --> 01:03:32.480
Datenbank-Trigger. Also man kann halt

01:03:32.480 --> 01:03:33.280
sowas...

01:03:33.280 --> 01:03:36.500
Ja, man könnte halt, also wenn

01:03:36.500 --> 01:03:37.340
zum Beispiel

01:03:37.340 --> 01:03:40.620
Nutzer taggen selber

01:03:40.620 --> 01:03:41.740
und erfinden eine neue Kategorie.

01:03:41.740 --> 01:03:44.160
Ja.

01:03:44.160 --> 01:03:46.560
Ich überlege gerade,

01:03:46.560 --> 01:03:48.440
mir fällt ehrlich gesagt jetzt gerade nicht so ein

01:03:48.440 --> 01:03:50.400
tolles Beispiel ein, aber im Grunde, was das tut,

01:03:50.400 --> 01:03:52.340
ist, wenn sich halt in einer

01:03:52.340 --> 01:03:54.380
bestimmten Spalte irgendwas ändert,

01:03:54.380 --> 01:03:56.500
dass dann automatisch andere Aktionen passieren.

01:03:56.620 --> 01:03:58.040
Innerhalb der Datenbank.

01:03:58.040 --> 01:04:00.220
Und das kann man halt

01:04:00.220 --> 01:04:02.500
festlegen, haben auch einen SQL-Syntax

01:04:02.500 --> 01:04:04.600
und man schreibt das halt einfach in eine Migration rein.

01:04:04.600 --> 01:04:06.560
Ja, oder man kann auch sogar Sort-Procedures,

01:04:06.560 --> 01:04:08.420
die halt dann irgendwie eine komplizierte Geschichte, die dann

01:04:08.420 --> 01:04:10.560
irgendwie ausgeführt wird, wenn ein neuer Autor

01:04:10.560 --> 01:04:12.040
angelegt wird oder sonst irgendwas.

01:04:12.040 --> 01:04:14.520
Dann müssen vielleicht noch diverse andere Geschichten gemacht werden.

01:04:14.520 --> 01:04:16.940
Das kann man

01:04:16.940 --> 01:04:17.740
ganz normal in diese

01:04:17.740 --> 01:04:19.860
Django-Migration auch reinschreiben. Man kann da die

01:04:19.860 --> 01:04:22.120
SQL reinschreiben und

01:04:22.120 --> 01:04:24.260
die werden dann mit ausgeführt und dann werden halt diese

01:04:24.260 --> 01:04:26.520
Sort-Procedures oder Trigger in die Datenbank mit reingeschrieben.

01:04:26.620 --> 01:04:28.060
Und sind dann halt da.

01:04:28.060 --> 01:04:29.360
Und

01:04:29.360 --> 01:04:32.640
was im Schema passiert

01:04:32.640 --> 01:04:34.080
oder was da drin ist, das wird halt dann von

01:04:34.080 --> 01:04:36.520
diesem Django-Migrationssystem verwaltet und

01:04:36.520 --> 01:04:38.740
alle Migrationen, die ausgeführt worden sind,

01:04:38.740 --> 01:04:40.220
werden halt auch wieder

01:04:40.220 --> 01:04:42.520
in derselben Datenbank halt gehalten

01:04:42.520 --> 01:04:44.320
von Django selbst. Da gibt es dann halt auch Tabellen zu.

01:04:44.320 --> 01:04:46.380
Und man kann jetzt Sachen auch wieder zurückrollen. Also man kann

01:04:46.380 --> 01:04:47.980
zum Beispiel sagen, wenn man eine Änderung gemacht hat

01:04:47.980 --> 01:04:50.580
und feststellt, oh, die war nicht so toll, dann sagt man

01:04:50.580 --> 01:04:52.460
halt einfach so migrate und dann gibt man die

01:04:52.460 --> 01:04:54.360
Nummer der Migration an

01:04:54.360 --> 01:04:56.460
davor und dann rollt sich die Datenbank in den

01:04:56.460 --> 01:04:57.680
Zustand davor zurück.

01:04:57.680 --> 01:05:00.340
Und dann

01:05:00.340 --> 01:05:02.340
löscht man einfach die Migration und dann war's das.

01:05:02.340 --> 01:05:04.320
Also das macht es halt sehr angenehm

01:05:04.320 --> 01:05:06.200
damit zu arbeiten und sowas braucht man auf jeden Fall.

01:05:06.200 --> 01:05:08.100
Also selbst wenn man jetzt sowas nicht wie Django verwendet,

01:05:08.100 --> 01:05:10.320
sondern das alles von Hand macht, dann braucht

01:05:10.320 --> 01:05:12.260
man auch irgendeine Art, wie man damit umgeht und das

01:05:12.260 --> 01:05:13.880
war teilweise früher ziemlich übel. Also

01:05:13.880 --> 01:05:16.420
keine so gute Unterstützung in den Frameworks für sowas

01:05:16.420 --> 01:05:18.400
gab. Da hat man das halt irgendwie von Hand gemacht

01:05:18.400 --> 01:05:20.500
und da passieren dann immer wieder Unfälle.

01:05:20.500 --> 01:05:22.420
Man hat halt irgendeine

01:05:22.420 --> 01:05:23.560
Datenbank vergessen oder

01:05:23.560 --> 01:05:26.060
wenn man jetzt halt mehrere Datenbanken hat

01:05:26.300 --> 01:05:27.160
oder

01:05:27.160 --> 01:05:30.480
es geht irgendwie sowas verloren, man weiß nicht genau

01:05:30.480 --> 01:05:31.820
in welchem Zustand die Datenbank ist, weil

01:05:31.820 --> 01:05:34.280
irgendwie man meint, man hätte die ausgeführt, aber

01:05:34.280 --> 01:05:36.320
dann ist es irgendwie doch nicht passiert

01:05:36.320 --> 01:05:38.580
oder weil eben nirgendwo

01:05:38.580 --> 01:05:40.400
drinsteht, in welchem Zustand die Datenbank ist,

01:05:40.400 --> 01:05:42.460
sondern man nur Leute fragt

01:05:42.460 --> 01:05:44.360
irgendwie so, also hast du die Migration jetzt eigentlich auf der

01:05:44.360 --> 01:05:45.820
Produktionsdatenbank schon ausgeführt oder nicht?

01:05:45.820 --> 01:05:46.920
Ja, ja, hab ich gemacht.

01:05:46.920 --> 01:05:49.340
Das ist vielleicht auch nicht passiert.

01:05:49.340 --> 01:05:52.320
Also es wäre schön, wenn das halt irgendwie selbst

01:05:52.320 --> 01:05:54.280
auch in der Datenbank festgehalten wird,

01:05:54.280 --> 01:05:55.080
in welchem Zustand man ist.

01:05:56.140 --> 01:05:58.020
Ja, und das, jetzt so ein

01:05:58.020 --> 01:05:59.920
Framework 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.260 --> 01:06:05.600
Ja, ja, Art damit umzugehen.

01:06:05.600 --> 01:06:07.940
Ja, kann man Flask, wenn man jetzt das andere

01:06:07.940 --> 01:06:09.700
große Web

01:06:09.700 --> 01:06:12.000
ja, Framework kann man jetzt

01:06:12.000 --> 01:06:14.200
nicht da so wirklich zu sagen, aber die andere Paradigmen,

01:06:14.200 --> 01:06:15.720
wie man Web-Anwendungen

01:06:15.720 --> 01:06:17.180
in Python entwickelt,

01:06:17.180 --> 01:06:19.680
wenn man das in 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.980 --> 01:06:28.220
einen Namen, die Migrationslösung

01:06:28.220 --> 01:06:30.040
dafür, den entdecke ich mir jetzt gerade

01:06:30.040 --> 01:06:32.040
nicht erinnern, und da geht das

01:06:32.040 --> 01:06:34.080
alles auch. SQL-Alchemy ist sogar deutlich mächtiger

01:06:34.080 --> 01:06:35.860
als der Django-ORM,

01:06:35.860 --> 01:06:37.140
aber ist halt nicht integriert.

01:06:37.140 --> 01:06:39.720
Und, ja, also

01:06:39.720 --> 01:06:40.640
Flask ist auch super,

01:06:40.640 --> 01:06:43.200
der Trade-Off ist halt so ein bisschen,

01:06:43.200 --> 01:06:46.160
was einen Django so abnimmt,

01:06:46.160 --> 01:06:46.940
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.760 --> 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:52.660 --> 01:06:55.120
Und das wird halt dafür,

01:06:55.820 --> 01:06:58.040
dass das alles konsistent bleibt und man upgraden kann

01:06:58.040 --> 01:07:00.180
und so, dafür wird gesorgt, da muss man selber sich nicht drum kümmern.

01:07:00.180 --> 01:07:02.060
Wenn man jetzt Flask macht und dann halt ganz viele

01:07:02.060 --> 01:07:04.120
unterschiedliche Teile

01:07:04.120 --> 01:07:06.080
hat und die ihre Versionen

01:07:06.080 --> 01:07:08.160
ändern und so, dann muss man selber am Ball bleiben

01:07:08.160 --> 01:07:09.660
und auch Konflikte halt selber auflösen.

01:07:09.660 --> 01:07:12.220
Das heißt, man hat so langfristig mehr zu tun damit.

01:07:12.220 --> 01:07:13.920
Aber dafür ist man halt auch

01:07:13.920 --> 01:07:16.060
flexibler und kann halt, wenn einem

01:07:16.060 --> 01:07:17.900
eine bestimmte Art von ORM besser gefällt, den halt

01:07:17.900 --> 01:07:19.900
verwenden. Es gibt halt auch zum Beispiel irgendwie

01:07:19.900 --> 01:07:21.860
neuere, also SQL-Alchemy ist sehr alt,

01:07:21.860 --> 01:07:23.080
Django-ORM ist relativ alt.

01:07:23.080 --> 01:07:25.420
Es gibt Peewee,

01:07:25.660 --> 01:07:27.640
und Pony-ORM oder so

01:07:27.640 --> 01:07:29.580
sind jetzt modernere Geschichten,

01:07:29.580 --> 01:07:31.680
sieht besser aus, macht unten drunter

01:07:31.680 --> 01:07:32.940
irgendwie was sehr ähnliches, aber

01:07:32.940 --> 01:07:35.660
ja, genau.

01:07:35.660 --> 01:07:37.600
Also ein Teil davon ist halt immer, wie man die

01:07:37.600 --> 01:07:39.320
Relationen und Tabellen definieren kann.

01:07:39.320 --> 01:07:41.060
Das sind meistens 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:45.540
Und der andere Teil vom ORM

01:07:45.540 --> 01:07:47.580
ist halt, wie man Abfragen auf die Datenbank halt

01:07:47.580 --> 01:07:49.340
abfeuert. Und

01:07:49.340 --> 01:07:51.540
das, was man eigentlich

01:07:51.540 --> 01:07:53.460
fast bei allen ORMs dann so macht, ist

01:07:53.460 --> 01:07:55.500
man

01:07:55.500 --> 01:07:57.600
macht so Method-Chaining.

01:07:57.600 --> 01:07:59.120
Ich weiß nicht, sagt dir das was?

01:07:59.120 --> 01:08:01.260
Bis jetzt nicht.

01:08:01.260 --> 01:08:03.400
Ja, gibt's auch so oft in

01:08:03.400 --> 01:08:05.460
Data Science, also Pandas oder so, da macht man das auch.

01:08:05.460 --> 01:08:08.520
Also man kann in Python,

01:08:08.520 --> 01:08:11.580
ja, man kann ja irgendwas sagen, so man hat ein Objekt, Punkt,

01:08:11.580 --> 01:08:13.360
Methodenaufruf,

01:08:13.360 --> 01:08:15.460
oder Punkt Attribut, Punkt,

01:08:15.460 --> 01:08:17.340
wieder noch was anderes, Punkt, wieder noch was anderes.

01:08:17.340 --> 01:08:19.740
Wenn zum Beispiel eine Methode

01:08:19.740 --> 01:08:21.400
ja ein Objekt zurückgibt, dann kann man auf diesem

01:08:21.400 --> 01:08:22.580
Objekt wieder was anderes aufrufen.

01:08:22.580 --> 01:08:25.300
Wenn ich das alles in eine Teile schreibe, wird das irgendwann relativ

01:08:25.340 --> 01:08:27.360
lang. Aber wenn ich jetzt ein Statement

01:08:27.360 --> 01:08:29.360
modellieren möchte, das halt viele Where-Bedingungen

01:08:29.360 --> 01:08:31.520
hat, die Art, in Django

01:08:31.520 --> 01:08:33.400
ORM das hinzuschreiben, wäre halt zu sagen, Filter

01:08:33.400 --> 01:08:35.280
irgendeine Spalte

01:08:35.280 --> 01:08:37.660
gleich

01:08:37.660 --> 01:08:39.120
irgendeinen Wert oder sowas.

01:08:39.120 --> 01:08:41.280
Aber dann hab ich noch ein zweites, dann sag ich Punkt, Filter,

01:08:41.280 --> 01:08:43.060
nächste Spalte, wieder ein anderer Wert oder so.

01:08:43.060 --> 01:08:45.460
Und das

01:08:45.460 --> 01:08:47.280
wird halt relativ länglich. Daraus wird dann halt ein

01:08:47.280 --> 01:08:49.360
Statement generiert, aber was ich

01:08:49.360 --> 01:08:50.700
halt tun kann, ist zu sagen,

01:08:50.700 --> 01:08:53.380
Klammer auf, und dann halt Query-Set, Punkt,

01:08:53.380 --> 01:08:53.800
Filter,

01:08:54.700 --> 01:08:56.960
Punkt, Annotate,

01:08:56.960 --> 01:08:58.920
und dann Dinge

01:08:58.920 --> 01:09:00.700
gruppieren oder so, oder neue Spalte

01:09:00.700 --> 01:09:01.280
hinzufügen.

01:09:01.280 --> 01:09:04.740
Und ich mach hinten noch eine weitere Klammer drumrum,

01:09:04.740 --> 01:09:06.460
dann kann ich das halt auch einrücken. Und dann

01:09:06.460 --> 01:09:08.620
rück ich das so ein, dass alle Punkte untereinander stehen.

01:09:08.620 --> 01:09:10.360
Und dann hab ich halt so ein mehrzeiliges

01:09:10.360 --> 01:09:12.780
Dings, was so ein bisschen

01:09:12.780 --> 01:09:14.400
eine Zwischenform ist zwischen SQL und

01:09:14.400 --> 01:09:15.780
Python-Code.

01:09:15.780 --> 01:09:20.580
Ja, aber ich

01:09:20.580 --> 01:09:22.640
spare mir dadurch sozusagen, dass

01:09:22.640 --> 01:09:24.660
jedes Mal irgendeine Zwischenvariable zuweisen zu müssen.

01:09:24.700 --> 01:09:26.700
Ansonsten könnte ich ja

01:09:26.700 --> 01:09:28.700
natürlich sagen, Query-Set gleich, Query-Set, Punkt, Filter,

01:09:28.700 --> 01:09:30.240
irgendwas. Und dann sag ich in der nächsten Zeile,

01:09:30.240 --> 01:09:32.680
Query-Set gleich, Query-Set, Punkt,

01:09:32.680 --> 01:09:34.540
Filter, noch irgendwie eine andere Spalte,

01:09:34.540 --> 01:09:36.040
where, irgendwas.

01:09:36.040 --> 01:09:38.600
Ich kann das aber auch alles in

01:09:38.600 --> 01:09:40.480
ein einziges Dings reinschreiben.

01:09:40.480 --> 01:09:41.280
Und man nennt das

01:09:41.280 --> 01:09:43.440
Message-Chaining.

01:09:43.440 --> 01:09:46.620
Ja, und das ist halt irgendwie

01:09:46.620 --> 01:09:48.480
das, bei

01:09:48.480 --> 01:09:50.360
Pandas ist es halt genauso, da hat man Data-Frames, auf denen man

01:09:50.360 --> 01:09:52.420
Sachen macht, und die geben dann auch immer

01:09:52.420 --> 01:09:54.180
wieder ein Data-Frame zurück, die Fehler der Methoden.

01:09:54.700 --> 01:09:56.540
Und die kann man halt auch so chainen. Und dann hat man da oft

01:09:56.540 --> 01:09:58.500
so mehrzeitige Dinge, wo halt die Punkte untereinander stehen.

01:09:58.500 --> 01:10:00.520
Also wenn man nicht weiß, was das ist, das ist Message-Chaining.

01:10:00.520 --> 01:10:02.380
Und das ist halt so eine Methode, um

01:10:02.380 --> 01:10:04.420
Dinge halt in eine

01:10:04.420 --> 01:10:06.320
State zu... Irgendwie schon mal ein bisschen gesehen, aber so wirklich

01:10:06.320 --> 01:10:08.620
wissen, was das Message-Chaining heißt, ist natürlich...

01:10:08.620 --> 01:10:10.480
Ja, genau. Und

01:10:10.480 --> 01:10:12.220
im Grunde ist es halt dann, wenn man

01:10:12.220 --> 01:10:14.140
OEMs, wenn man Queries in OEMs so macht,

01:10:14.140 --> 01:10:16.440
ist es halt so ein bisschen, ist es so ein Zwischending

01:10:16.440 --> 01:10:16.940
zwischen

01:10:16.940 --> 01:10:20.440
SQL und Python, aber das funktioniert

01:10:20.440 --> 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.540 --> 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.240 --> 01:10:34.400
Und wenn ich jetzt irgendwie, keine Ahnung,

01:10:34.400 --> 01:10:36.540
mir überlege, dass ich

01:10:36.540 --> 01:10:38.640
eine bestimmte Art von Optimierung

01:10:38.640 --> 01:10:39.700
machen möchte an den Statements,

01:10:39.700 --> 01:10:41.360
dann wäre die halt

01:10:41.360 --> 01:10:43.140
auch immer gleich.

01:10:43.140 --> 01:10:46.460
Das heißt, dann habe ich halt dieses Problem,

01:10:46.460 --> 01:10:48.420
dass ich sonst hätte, wenn ich das alles in einen

01:10:48.420 --> 01:10:50.220
File schreiben würde, oder wenn ich

01:10:50.220 --> 01:10:52.540
fast gleiche Statements in unterschiedliche

01:10:52.540 --> 01:10:54.380
Files schreiben würde, wenn ich die

01:10:54.380 --> 01:10:56.420
Statements beim Code haben will, das habe

01:10:56.420 --> 01:10:58.460
ich damit dann nicht mehr. Und das ist natürlich ein sehr schöner Effekt.

01:10:58.460 --> 01:11:00.140
Und das ist halt, ja,

01:11:00.140 --> 01:11:01.920
das ist einer der Hauptnutzen von OEMs, also

01:11:01.920 --> 01:11:04.280
ein anderer schöner Nutzen ist halt, dass man halt diese

01:11:04.280 --> 01:11:06.280
ganze Migrationsgeschichte, wie ändern sich Sachen, halt auch

01:11:06.280 --> 01:11:08.460
automatisiert hat, beziehungsweise die ganzen Prozesse drumherum

01:11:08.460 --> 01:11:10.380
irgendwie zumindest mal abgebildet hat.

01:11:10.380 --> 01:11:12.620
Ja, also sind wir jetzt klein und niedlich,

01:11:12.620 --> 01:11:13.340
und das haben wir jetzt gemacht.

01:11:13.340 --> 01:11:16.080
Genau, und dann würde man so ein Framework verwenden, OEM,

01:11:16.080 --> 01:11:17.580
und dann ist man eigentlich,

01:11:17.580 --> 01:11:19.540
ja, das geht alles ins Git,

01:11:19.540 --> 01:11:22.220
gibt Versionskontrolle dafür, und dann

01:11:22.220 --> 01:11:24.220
das ist eigentlich alles schon relativ komfortabel.

01:11:24.220 --> 01:11:25.560
Ähm,

01:11:25.560 --> 01:11:26.980
ja.

01:11:26.980 --> 01:11:29.200
Ähm,

01:11:29.200 --> 01:11:32.060
Ja, was passiert jetzt? Also wir sind klein,

01:11:32.060 --> 01:11:33.960
und jetzt haben wir das schon gebaut, aber

01:11:33.960 --> 01:11:35.980
ja, wann funktioniert das denn nicht mehr so?

01:11:35.980 --> 01:11:37.420
Äh, ja.

01:11:37.420 --> 01:11:38.760
Ähm,

01:11:38.760 --> 01:11:40.860
genau.

01:11:40.860 --> 01:11:43.780
Wir haben als Onlinehandel einen

01:11:43.780 --> 01:11:45.500
riesen Vorteil gegenüber

01:11:45.500 --> 01:11:47.720
stationärem Buchhandel, weil

01:11:47.720 --> 01:11:51.940
das ist auch eine interessante Statistik.

01:11:51.940 --> 01:11:53.700
Das kommt, glaube ich, aus diesem,

01:11:54.060 --> 01:11:55.840
ähm, Buch-Longtail, irgendwie,

01:11:55.840 --> 01:11:57.420
äh, von, wie soll ich sagen, von

01:11:57.420 --> 01:11:59.320
Wired-Redaktion, ah, weiß ich, hab den Namen vergessen.

01:11:59.320 --> 01:12:01.360
Äh, jedenfalls, ähm,

01:12:01.360 --> 01:12:03.520
schreibt er da, dass Amazon

01:12:03.520 --> 01:12:05.700
macht die Hälfte des Umsatzes mit

01:12:05.700 --> 01:12:07.740
Büchern, die nicht in den Top 300.000 sind.

01:12:07.740 --> 01:12:08.880
Mhm.

01:12:08.880 --> 01:12:11.940
So, äh, weil eben

01:12:11.940 --> 01:12:14.020
Bücher verkaufen, äh,

01:12:14.020 --> 01:12:14.920
so ein, so ein,

01:12:14.920 --> 01:12:18.740
oder verkaufte Bücher hat so eine Longtail-Verteilung.

01:12:18.740 --> 01:12:19.680
Also es gibt halt

01:12:19.680 --> 01:12:21.740
äh, sehr, Leute wollen sehr

01:12:21.740 --> 01:12:23.900
unterschiedliche Bücher kaufen. Also es

01:12:23.900 --> 01:12:25.800
werden viele Bücher verkauft, aber von denen nur ganz

01:12:25.800 --> 01:12:27.860
wenige. Und das ist

01:12:27.860 --> 01:12:29.280
halt blöd für einen

01:12:29.280 --> 01:12:31.860
Laden, der die Bücher halt physisch vorhalten

01:12:31.860 --> 01:12:33.740
muss. Weil auch selbst wenn Bücher nicht so groß sind,

01:12:33.740 --> 01:12:36.040
ich kann halt in so einem Innenstadt-

01:12:36.040 --> 01:12:37.760
Buchladen kann ich halt

01:12:37.760 --> 01:12:38.900
irgendwie ein paar tausend Bücher haben.

01:12:38.900 --> 01:12:41.340
Äh, und dann ist halt irgendwie Schluss.

01:12:41.340 --> 01:12:43.580
Und dann muss ich mir überlegen, welche das sind. Aber wenn jetzt,

01:12:43.580 --> 01:12:45.340
also, nehmen wir an, ich hab...

01:12:45.340 --> 01:12:47.100
Das hat aber auch ein Zielpublikum. Das heißt, ich weiß genau, hey,

01:12:47.100 --> 01:12:50.120
in mir kommen jetzt nur ganz wieder alte, antiquarische,

01:12:50.120 --> 01:12:51.580
ähm, interessierte Menschen rein.

01:12:51.580 --> 01:12:53.740
Dann sollte ich vielleicht dafür sorgen, dass in meinem

01:12:53.740 --> 01:12:55.560
Laden viele antiquarische Bücher sind.

01:12:55.560 --> 01:12:57.540
Oder es kommen jetzt noch ganz viele hippe Leute rein,

01:12:57.540 --> 01:12:59.580
die wollen alle, was sie bei IT wissen, sollte ich vielleicht in ein IT-Buchladen.

01:12:59.580 --> 01:13:01.660
Ja, ja. Aber selbst, selbst wenn du

01:13:01.660 --> 01:13:03.500
jetzt, äh, all diese Zielgruppen zusammennimmst

01:13:03.500 --> 01:13:05.120
und dann irgendwie das riesige, den riesigsten,

01:13:05.120 --> 01:13:07.480
äh, also, das ist halt das Problem. Wenn die

01:13:07.480 --> 01:13:09.520
Zielgruppe zu klein ist, dann lohnt sich das

01:13:09.520 --> 01:13:11.380
nicht. Äh, aber wenn sie, äh, selbst

01:13:11.380 --> 01:13:13.620
wenn du jetzt einen riesigen Buchladen hast, in dem 300.000

01:13:13.620 --> 01:13:15.300
Bücher passen, was äh, ziemlich groß sein müsste,

01:13:15.300 --> 01:13:17.620
dann machst du

01:13:17.620 --> 01:13:19.560
immer nur, äh, trotzdem noch die Hälfte des

01:13:19.560 --> 01:13:20.920
Umsatzes von Amazon, weil

01:13:20.920 --> 01:13:23.580
Amazon macht halt nochmal so viel Umsatz mit den

01:13:23.580 --> 01:13:25.560
ganzen Rest. Das heißt, sie haben dann, sie können

01:13:25.560 --> 01:13:26.860
einfach viel besser skalieren,

01:13:26.860 --> 01:13:29.200
weil sie einfach viel mehr Bücher verkaufen.

01:13:29.200 --> 01:13:31.040
Und, ähm, ja, dagegen,

01:13:31.040 --> 01:13:33.440
ich wüsste nicht, dass es da irgendein Mittel gegeben gibt.

01:13:33.440 --> 01:13:35.640
Ich fürchte... Was aber auch bedeuten würde, dass Amazon

01:13:35.640 --> 01:13:37.500
auch diese Minus-Eins-Bestellung annehmen müsste, weil das

01:13:37.500 --> 01:13:39.360
müssen sie auch irgendwo in einem riesigen Lager jedes

01:13:39.360 --> 01:13:41.420
Buch liegen haben. Ja, müssen sie tatsächlich wahrscheinlich.

01:13:41.420 --> 01:13:43.600
Oder sie müssen es halt on demand irgendwie drucken können

01:13:43.600 --> 01:13:45.660
oder so. Gut, klar, sie müssen

01:13:45.660 --> 01:13:47.460
damit irgendwie umgehen. Äh, 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.420
Zum Beispiel, äh... Hey, Autor, schreib doch

01:13:53.420 --> 01:13:54.660
bitte nochmal eine neue Vorstellung.

01:13:54.660 --> 01:13:56.260
So ein paar Bestellungen, ja.

01:13:56.260 --> 01:13:58.860
Aber, äh,

01:13:58.860 --> 01:14:01.420
ja, ich meine, du hast halt als, äh,

01:14:01.420 --> 01:14:03.420
als stationärer Buchhandlung

01:14:03.420 --> 01:14:05.280
hast du ja keinen Vorteil mehr, wenn

01:14:05.280 --> 01:14:06.860
du dann auch wieder bestellst, weil dann

01:14:06.860 --> 01:14:09.360
machst du halt zwei Sachen und die eine, ja,

01:14:09.360 --> 01:14:11.220
und dann als Amazon hast du einfach

01:14:11.220 --> 01:14:13.540
einen strukturellen Vorteil,

01:14:13.540 --> 01:14:15.880
fürchte ich. Äh, und dann kannst du...

01:14:15.880 --> 01:14:17.160
Okay, und dann ist es cool, weil dann können wir einfach mit unserer

01:14:17.160 --> 01:14:19.700
Postgres-Lösung direkt so unter dem ORM...

01:14:19.700 --> 01:14:21.420
Genau. Die interessante...

01:14:21.420 --> 01:14:23.400
Also mit 3.000 Millionen, also mit 3.000 Millionen ist das überhaupt kein Problem,

01:14:23.420 --> 01:14:25.260
äh, also da könnten wir auch, also ich würde sagen,

01:14:25.260 --> 01:14:27.280
so ein Markt wie Deutschland kannst du wahrscheinlich tatsächlich mit

01:14:27.280 --> 01:14:29.560
einer Datenbank und mit allen Büchern, die es überhaupt gibt,

01:14:29.560 --> 01:14:31.060
locker bedienen. Das ist

01:14:31.060 --> 01:14:32.540
kein so großes Problem.

01:14:32.540 --> 01:14:35.360
Äh, wenn es jetzt

01:14:35.360 --> 01:14:36.620
nur darum geht, die Bücher zu verkaufen.

01:14:36.620 --> 01:14:39.400
Aber, äh, wenn wir

01:14:39.400 --> 01:14:41.560
jetzt, äh, zum Beispiel eben sowas rauskriegen

01:14:41.560 --> 01:14:43.340
wollen, wie, äh,

01:14:43.340 --> 01:14:44.880
was sind eigentlich die Top 300.000 Bücher?

01:14:44.880 --> 01:14:47.400
Wo kommt denn diese Zahl eigentlich her?

01:14:47.400 --> 01:14:49.020
Ja, und, äh,

01:14:49.020 --> 01:14:51.200
überhaupt rauszukriegen, okay, wir machen die Hälfte

01:14:51.200 --> 01:14:53.280
unseres Umsatzes mit den nicht, mit Büchern, die nicht

01:14:53.280 --> 01:14:54.200
in den Top 300.000 sind,

01:14:54.200 --> 01:14:57.260
dann, äh, müssen wir, äh, nicht nur

01:14:57.260 --> 01:14:59.400
die Bücher speichern, sondern dann müssen wir halt

01:14:59.400 --> 01:15:01.320
auch, äh, speichern

01:15:01.320 --> 01:15:03.320
zum Beispiel, welche Bücher gekauft worden sind und so

01:15:03.320 --> 01:15:05.060
und die, also die Historie aller Bestellungen und so.

01:15:05.060 --> 01:15:07.400
Und das ist dann halt unter Umständen

01:15:07.400 --> 01:15:07.960
viel, viel mehr.

01:15:07.960 --> 01:15:11.260
Und, äh, dann, äh,

01:15:11.260 --> 01:15:13.060
wird es allmählich problematisch, weil dann haben wir

01:15:13.060 --> 01:15:15.460
unterschiedliche, äh, Use Cases,

01:15:15.460 --> 01:15:17.440
äh, oder unterschiedliche Abfragemuster.

01:15:17.440 --> 01:15:18.940
Also wir haben zum Beispiel diese

01:15:18.940 --> 01:15:20.760
Transaktions, ähm,

01:15:20.760 --> 01:15:23.140
äh... Also das Lager, das einfach immer noch

01:15:23.140 --> 01:15:24.400
weiß, wie viele Bücher sind da und das schicken wir raus.

01:15:24.400 --> 01:15:26.600
Oder wir haben jemanden, der macht Marketing oder sowas.

01:15:26.600 --> 01:15:28.960
Das System, das macht halt Bestellungen, oder wir haben halt Anfragen, die

01:15:28.960 --> 01:15:30.460
Bestellungen machen oder solche Sachen wie

01:15:30.460 --> 01:15:33.040
zeig mir alle Bücher in, äh, Seefacher-Romane

01:15:33.040 --> 01:15:34.740
oder so. Äh,

01:15:34.740 --> 01:15:37.020
aber die, diese Art von

01:15:37.020 --> 01:15:39.160
Anfragen wie, sag mir mal, wie viel Umsatz

01:15:39.160 --> 01:15:41.300
ich mit den, äh,

01:15:41.300 --> 01:15:43.280
äh, äh, nicht in Top 300.000

01:15:43.280 --> 01:15:45.000
enthaltenen Bücher im letzten Jahr gemacht habe.

01:15:45.000 --> 01:15:47.140
Das ist eine ganz andere Art

01:15:47.140 --> 01:15:47.640
von Anfrage.

01:15:47.640 --> 01:15:51.100
Ja, während die, die Anfragen vorher, die machen

01:15:51.100 --> 01:15:53.040
immer nur auf kleinen Datenmengen in der Datenbank,

01:15:53.080 --> 01:15:54.820
irgendwas, immer zeilenweise meistens.

01:15:54.820 --> 01:15:56.460
Und, ähm,

01:15:56.460 --> 01:15:58.880
oft ändern sie auch irgendwas oder schreiben

01:15:58.880 --> 01:16:00.880
irgendwas. Aber gut, Großteil, wenn man noch die

01:16:00.880 --> 01:16:03.060
große Mehrheit wird Read-Anfragen

01:16:03.060 --> 01:16:05.060
sein, aber die, äh, beziehen

01:16:05.060 --> 01:16:07.000
sich normalerweise nicht auf wahnsinnig viele

01:16:07.000 --> 01:16:09.100
Daten, äh, Teilen, sondern immer nur relativ

01:16:09.100 --> 01:16:10.360
wenige oder wenige tausend Zeilen.

01:16:10.360 --> 01:16:12.940
Und, ähm, ja, eben operieren halt

01:16:12.940 --> 01:16:14.920
auch ja zeilenweise während diese andere

01:16:14.920 --> 01:16:16.780
Anfrage jetzt dieses, wie viel Umsatz.

01:16:16.780 --> 01:16:18.980
Ja, das ist halt dann

01:16:18.980 --> 01:16:20.700
nur noch eine Spalte aus den Bestellungen

01:16:20.700 --> 01:16:22.860
und dann auch, äh, geht es

01:16:23.020 --> 01:16:25.080
wahrscheinlich aber über lange Zeiträume,

01:16:25.080 --> 01:16:26.860
über ein Jahr, mehrere Jahre

01:16:26.860 --> 01:16:28.740
und dann halt über alle Bücher.

01:16:28.740 --> 01:16:31.000
Das ist eine Anfrage,

01:16:31.000 --> 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:33.740 --> 01:16:36.620
So, und jetzt beißen sich die, diese, diese

01:16:36.620 --> 01:16:38.680
Abfrage-Muster beißen sich halt massiv.

01:16:38.680 --> 01:16:40.600
Mhm, mhm. Äh, wer, also,

01:16:40.600 --> 01:16:42.860
weil, äh, das Problem ist, dass die

01:16:42.860 --> 01:16:44.700
Datenbank irgendwie gewährleisten muss, dass die,

01:16:44.700 --> 01:16:46.780
deine Sicht auf die Welt, also auf die Datenbank,

01:16:46.780 --> 01:16:48.940
konsistent bleibt, während die Anfrage läuft.

01:16:48.940 --> 01:16:50.680
Die Anfrage läuft jetzt aber wahrscheinlich relativ lang.

01:16:50.680 --> 01:16:52.960
Du musst hier irgendwie alle Daten, die in der Datenbank

01:16:52.960 --> 01:16:54.680
liegen, oder einen Großteil davon, musst du dir sicher angucken,

01:16:54.680 --> 01:16:56.260
wenn sie dir hinterher so was sagen,

01:16:56.260 --> 01:16:58.640
eine Zahl geben will, wie viel Umsatz waren das jetzt so.

01:16:58.640 --> 01:17:00.260
Ähm,

01:17:00.260 --> 01:17:02.700
und währenddessen werden aber

01:17:02.700 --> 01:17:04.540
Bestellungen abgearbeitet oder werden Dinge gemacht,

01:17:04.540 --> 01:17:05.660
Sachen an der Datenbank geändert,

01:17:05.660 --> 01:17:08.200
die jetzt aber nicht direkt

01:17:08.200 --> 01:17:10.480
durchschlagen können auf deine Anfrage, sondern

01:17:10.480 --> 01:17:12.520
da werden immer nur Kopien gemacht, oder es,

01:17:12.520 --> 01:17:14.820
ja, und sozusagen, es wird dann halt ein Timestamp

01:17:14.820 --> 01:17:16.660
mit reingeschrieben, es wird halt, nein, das ist Multiversion

01:17:16.660 --> 01:17:18.500
Concurrency Control. Äh,

01:17:18.500 --> 01:17:20.620
Multiversen! Ja,

01:17:20.620 --> 01:17:22.880
Multiversion Concurrency Control,

01:17:22.900 --> 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:28.900 --> 01:17:30.920
je nachdem, wer sie, wer gerade fragt.

01:17:30.920 --> 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.940
diese Query läuft, umso länger muss die Datenbank

01:17:38.940 --> 01:17:41.140
jetzt mehrere Versionen ihrer selbst aufrechterhalten.

01:17:41.140 --> 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.540 --> 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.840
anfragen und irgendwann wird man halt merken, so morgens um neun

01:17:52.840 --> 01:17:55.120
wenn dann halt irgendwie die, die, äh,

01:17:55.120 --> 01:17:56.640
äh, Business Intelligence

01:17:56.640 --> 01:17:58.720
Abteilung irgendwie anfängt, äh, wenn

01:17:58.720 --> 01:18:00.580
da die Analysten sitzen und dann irgendwie, ja gut,

01:18:00.580 --> 01:18:02.580
ich weiß nicht, am Anfang wird man sowas noch nicht haben, aber

01:18:02.580 --> 01:18:04.440
irgendwann wird man das gleich dann, wenn die halt ihre

01:18:04.440 --> 01:18:06.720
Analysequeries abschießen, dann

01:18:06.720 --> 01:18:08.340
wird plötzlich die Webseite langsam.

01:18:08.340 --> 01:18:10.760
Ja, weil halt die Datenbank langsam wird,

01:18:10.760 --> 01:18:12.580
weil die Queries werden langsam, weil, äh, plötzlich

01:18:12.580 --> 01:18:14.720
äh, muss die, äh, muss die Datenbank

01:18:14.720 --> 01:18:16.840
irgendwie mit mehreren, äh,

01:18:16.840 --> 01:18:18.780
Zuständen irgendwie rum

01:18:18.780 --> 01:18:20.560
jonglieren. Ja.

01:18:20.560 --> 01:18:22.780
Das ist blöd. Und dann muss man sich halt, äh,

01:18:22.780 --> 01:18:24.680
sowas überlegen. Und, äh,

01:18:24.680 --> 01:18:26.640
das ist dann halt so der Moment, äh,

01:18:26.640 --> 01:18:28.780
wo man dann sagen muss, okay, wir, wir

01:18:28.780 --> 01:18:30.680
können das nicht mehr. Es wäre schön, alles in einer Datenbank

01:18:30.680 --> 01:18:32.520
zu haben, aber es geht nicht. Diese beiden Use Cases

01:18:32.520 --> 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.600 --> 01:18:38.460
dass man das halt in unterschiedliche Systeme packt.

01:18:38.460 --> 01:18:40.960
Und, ähm,

01:18:40.960 --> 01:18:42.500
ja, also das eine nennt man,

01:18:42.500 --> 01:18:44.340
äh, auch, äh, irgendwie OTP,

01:18:44.340 --> 01:18:46.680
ja, Online Transaction Processing.

01:18:46.680 --> 01:18:48.520
Das ist halt sozusagen der

01:18:48.520 --> 01:18:50.660
Webseite, also Datenbank ist hinter

01:18:50.660 --> 01:18:52.720
einer Webseite, die irgendwie Bücher verkauft und, und Prozess

01:18:52.720 --> 01:18:53.740
hier Transaktionen, Bestellungen.

01:18:53.740 --> 01:18:56.540
Und der andere Teil nennt sich, äh,

01:18:56.540 --> 01:18:58.680
OLAP, äh, Online Analytical, äh,

01:18:58.680 --> 01:18:59.840
Analytical Processing.

01:18:59.840 --> 01:19:02.680
Und, äh, ist halt das so, wenn

01:19:02.680 --> 01:19:04.900
man das mal gehört hat, irgendwie, wenn Leute über Data Warehousing

01:19:04.900 --> 01:19:06.760
sprechen oder Data Warehouses oder so, das ist halt

01:19:06.760 --> 01:19:09.000
das. Ähm,

01:19:09.000 --> 01:19:10.520
und, äh,

01:19:10.520 --> 01:19:12.880
genau, äh, das sind beides

01:19:12.880 --> 01:19:14.700
meistens relationale Datenbanken,

01:19:14.700 --> 01:19:15.640
wenn man anfängt jedenfalls.

01:19:15.640 --> 01:19:18.700
Äh, aber die sehen

01:19:18.700 --> 01:19:20.700
unterschiedlich aus. Äh, also wir haben

01:19:20.700 --> 01:19:22.700
unterschiedliche Anfragen werden gestellt.

01:19:22.700 --> 01:19:24.760
Ja, Analyseanfragen sind oft, laufen

01:19:24.760 --> 01:19:26.480
länger, gucken sich viele,

01:19:26.480 --> 01:19:28.420
viele Zeilen an.

01:19:28.420 --> 01:19:30.760
Äh, Transaktionsanfragen sind oft

01:19:30.760 --> 01:19:32.800
kurz und, ähm, ja, gucken

01:19:32.800 --> 01:19:34.680
sich wenige Zeilen an. Und da geht's auch darum,

01:19:34.680 --> 01:19:36.840
dass die Latenz relativ kurz ist. Bei vielen Analyseanfragen

01:19:36.840 --> 01:19:38.740
ist das gar nicht so wichtig. Äh,

01:19:38.740 --> 01:19:40.780
dass die jetzt, ob die jetzt eine Minute oder länger

01:19:40.780 --> 01:19:42.680
oder weniger lang laufen, ist gar nicht so, gar nicht so

01:19:42.680 --> 01:19:44.880
entscheidend. Und auch die Analyse-Datenbanken

01:19:44.880 --> 01:19:46.700
sind oft viel, viel größer, weil man halt historische

01:19:46.700 --> 01:19:48.740
Daten mit drin hat. Äh, was

01:19:48.740 --> 01:19:50.740
halt für eine Transaktionsdatenbank tödlich wäre, weil

01:19:50.740 --> 01:19:52.640
die, bei der es möglichst das

01:19:52.640 --> 01:19:54.400
komplette, äh,

01:19:54.400 --> 01:19:56.700
Working-Set der Datenbank im Hauptspeicher,

01:19:56.700 --> 01:19:58.560
damit das halt alles schnell geht, damit die Latenz

01:19:58.560 --> 01:20:00.780
äh, niedrig bleibt,

01:20:00.780 --> 01:20:02.720
damit halt die Webseite schön, äh,

01:20:02.720 --> 01:20:04.500
sich schön snappy irgendwie anfühlt.

01:20:04.500 --> 01:20:06.840
Äh, und

01:20:06.840 --> 01:20:09.040
bei, äh, bei den, den Analyse-Datenbanken

01:20:09.040 --> 01:20:10.800
ist dabei unter Umständen wichtig, dass ich

01:20:10.800 --> 01:20:12.800
halt historische Daten da halt auch mit drin haben kann.

01:20:12.800 --> 01:20:14.680
Und die sind, werden dann halt vielleicht so groß,

01:20:14.680 --> 01:20:16.060
dass man das halt nicht mehr im Hauptspeicher halten kann.

01:20:16.060 --> 01:20:18.380
Ja, aber, äh,

01:20:18.380 --> 01:20:21.020
die Queries werden dann halt langsam,

01:20:21.020 --> 01:20:22.540
aber das ist halt möglicherweise,

01:20:22.580 --> 01:20:24.360
wichtiger, historische Daten zu haben, als dass

01:20:24.360 --> 01:20:26.700
Queries halt schnell sind. Und dann, äh,

01:20:26.700 --> 01:20:28.620
wenn, wenn sich eine, eine Query

01:20:28.620 --> 01:20:30.540
irgendwie ein paar Millionen oder paar Zehn Millionen Zeilen anguckt,

01:20:30.540 --> 01:20:32.260
dann ist es eh nicht mehr schnell, selbst wenn es im Hauptspeicher ist.

01:20:32.260 --> 01:20:34.320
Und ob es dann jetzt eine Minute oder zwei Minuten dauert,

01:20:34.320 --> 01:20:35.380
das hat dann auch irgendwie wurscht.

01:20:35.380 --> 01:20:38.720
Ja, äh, genau. Und dann, äh,

01:20:38.720 --> 01:20:40.600
hat man eben diese beiden unterschiedlichen Systeme

01:20:40.600 --> 01:20:42.460
und dann kriegt man halt aber auch genau diese Probleme,

01:20:42.460 --> 01:20:44.560
die man dann hat, wenn man mehrere,

01:20:44.560 --> 01:20:46.540
mehrere Sichten auf die Welt,

01:20:46.540 --> 01:20:48.480
äh, hat oder einen Status, äh,

01:20:48.480 --> 01:20:50.460
irgendwie eines, man hat jetzt keinen gemeinsamen Status

01:20:50.460 --> 01:20:52.520
mehr, sondern man hat jetzt, äh,

01:20:52.520 --> 01:20:54.260
äh, den Status

01:20:54.260 --> 01:20:55.820
des Systems in

01:20:55.820 --> 01:20:58.560
unterschiedlicher Form in unterschiedlichen Datenmanken.

01:20:58.560 --> 01:21:00.520
Äh, das heißt,

01:21:00.520 --> 01:21:02.500
man muss jetzt zum Beispiel die Transaktionen, die irgendwie

01:21:02.500 --> 01:21:04.280
in dem einen System aufgelaufen sind, überführen

01:21:04.280 --> 01:21:06.940
in das Analyse-System.

01:21:06.940 --> 01:21:08.480
Äh, das macht man

01:21:08.480 --> 01:21:10.360
üblicherweise bei einem Prozess, der nennt sich, äh,

01:21:10.360 --> 01:21:12.520
ETL, äh, Extract, Transform,

01:21:12.520 --> 01:21:14.800
Load. Und man halt die, äh,

01:21:14.800 --> 01:21:16.640
Daten, die einen interessieren, halt täglich oder so.

01:21:16.640 --> 01:21:18.120
Also meistens fängt man so, so was an wie,

01:21:18.120 --> 01:21:20.760
ja, das sind halt dann Jobs, die nachts laufen,

01:21:20.760 --> 01:21:22.460
äh, wenn halt die Datenmangel sowieso nicht so

01:21:22.460 --> 01:21:24.780
unterlasst sind, weil nicht so viele Leute, äh,

01:21:24.780 --> 01:21:26.640
äh, einkaufen, äh,

01:21:26.640 --> 01:21:28.760
liest man halt irgendwie alles, was einen so

01:21:28.760 --> 01:21:30.660
interessiert, dann aus der Transaktionsdatenbank aus.

01:21:30.660 --> 01:21:32.500
Dann, ähm, ist der, der

01:21:32.500 --> 01:21:34.880
Transformationsprozess halt sowas wie,

01:21:34.880 --> 01:21:36.540
ich muss die Daten in ein anderes Schema transformieren.

01:21:36.540 --> 01:21:38.240
Und das ist halt so wie so Stern

01:21:38.240 --> 01:21:40.380
ist da, äh, Schema, äh, Schema oder

01:21:40.380 --> 01:21:41.860
Snowflake-Schema, je nachdem.

01:21:41.860 --> 01:21:44.680
Ähm, das ist auch

01:21:44.680 --> 01:21:46.720
irgendwie gewisserweise normalisiert oder, man kann auch

01:21:46.720 --> 01:21:47.720
sagen, denormalisiert, je nachdem.

01:21:47.720 --> 01:21:50.240
Ähm, aber es ist halt auf jeden Fall anders.

01:21:50.240 --> 01:21:52.300
Äh, es ist halt davon optimiert, dass ich bestimmte

01:21:52.400 --> 01:21:53.660
Daten von Analysen fahren kann.

01:21:53.660 --> 01:21:56.160
Und lädt das dann ganz,

01:21:56.160 --> 01:21:58.400
lädt das Ganze halt in die, äh,

01:21:58.400 --> 01:22:00.140
in, in, in, in, in das

01:22:00.140 --> 01:22:01.320
Analyse-Datenbank-System.

01:22:01.320 --> 01:22:03.760
Für deine BI. Genau.

01:22:03.760 --> 01:22:05.240
Äh, ja.

01:22:05.240 --> 01:22:07.900
Und, äh, äh,

01:22:07.900 --> 01:22:09.840
ja, das ist,

01:22:09.840 --> 01:22:11.540
das ist halt immer so ein bisschen, das ist halt

01:22:11.540 --> 01:22:14.220
ein bisschen fies alles. Aber, ja, bleibt dann halt

01:22:14.220 --> 01:22:16.200
nichts übrig, muss man irgendwie machen. Wie würden wir es denn

01:22:16.200 --> 01:22:18.080
jetzt machen? Wenn wir Python jetzt haben, jetzt haben wir ja irgendwie so

01:22:18.080 --> 01:22:20.000
ein neues System und jetzt haben wir eigentlich irgendwie,

01:22:20.000 --> 01:22:22.340
das ist unser, äh, OLTP-Datenbank

01:22:22.340 --> 01:22:24.160
System, war aufgebaut mit den Transaktionen für unsere

01:22:24.160 --> 01:22:26.100
Webseite. Was bauen wir denn da, damit wir

01:22:26.100 --> 01:22:28.060
jetzt so ein OLAP-Ding dranhängen können, weil wir

01:22:28.060 --> 01:22:30.080
die analytische Abteilung einstellen? Ja, machen wir auch mit, mit

01:22:30.080 --> 01:22:32.220
Postgres, äh, so ein Ding, äh,

01:22:32.220 --> 01:22:34.060
da. Also eine zweite Postgres-Datenbank, eben die erste

01:22:34.060 --> 01:22:36.140
Packung. Ja, genau. Die halt ein bisschen anders aussieht.

01:22:36.140 --> 01:22:37.860
Die hat dann vielleicht nicht ganz so viele Hauptspeicher, die hat dann

01:22:37.860 --> 01:22:40.140
aber dafür halt irgendwie mehr Plattenplatz

01:22:40.140 --> 01:22:42.100
und auch irgendwie Storage

01:22:42.100 --> 01:22:43.720
möglicherweise in unterschiedlicher Qualität.

01:22:43.720 --> 01:22:46.180
Äh, wenn man sagt, okay, äh, vielleicht

01:22:46.180 --> 01:22:48.100
für die letzten, 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.280
Monat oder für die letzten sechs Monate haben wir die halt

01:22:52.280 --> 01:22:54.200
auf SSDs oder so, auf ein System, was halt

01:22:54.200 --> 01:22:56.380
noch schnell, weil, weil der größte

01:22:56.380 --> 01:22:58.120
Teil wird, äh, der Queries geht natürlich

01:22:58.120 --> 01:22:59.580
auf Daten, die relativ aktuell sind.

01:22:59.580 --> 01:23:02.280
Und dann ab einem Jahr oder so, so liegen die Daten

01:23:02.280 --> 01:23:03.300
dann vielleicht auf Platten,

01:23:03.300 --> 01:23:06.100
äh, die halt dann eher

01:23:06.100 --> 01:23:08.040
langsam sind, aber da nur ein kleiner Teil der

01:23:08.040 --> 01:23:09.880
Queries halt so lange zurückgeht,

01:23:09.880 --> 01:23:12.000
ist es halt nicht so schlimm, wenn das ein bisschen langsamer ist.

01:23:12.000 --> 01:23:14.160
Und diese Art von Queries muss dann halt ein bisschen

01:23:14.160 --> 01:23:16.800
warten. Ja, äh,

01:23:16.800 --> 01:23:18.980
und das ist halt ganz anders beim, äh,

01:23:18.980 --> 01:23:20.160
im Vergleich zum OLTP-System,

01:23:20.160 --> 01:23:22.220
wo man halt sagt, das muss alles

01:23:22.220 --> 01:23:23.960
mehr oder weniger im Hauptspeicher sein. Und, äh,

01:23:23.960 --> 01:23:25.960
klar, ist auch wichtig, dass es, dass Sachen schnell geschrieben werden,

01:23:25.960 --> 01:23:27.960
deswegen muss das, wo was hingeschrieben wird, muss halt

01:23:27.960 --> 01:23:30.160
auch sackschnell sein. Also, da würde man

01:23:30.160 --> 01:23:31.900
auch eher lieber dann schnelle SSDs nehmen,

01:23:31.900 --> 01:23:34.100
aber es ist halt nicht wichtig,

01:23:34.100 --> 01:23:36.000
viel mehr Plattenplatz zu haben,

01:23:36.000 --> 01:23:37.560
als man Hauptspeicher hat, weil das will man ja eh nicht.

01:23:37.560 --> 01:23:39.540
Mhm, mhm. Ähm,

01:23:39.540 --> 01:23:41.600
ja, äh,

01:23:41.600 --> 01:23:43.860
und, ähm, genau,

01:23:43.860 --> 01:23:45.760
diese LTE, diese LTE-Prozesse sind dann halt

01:23:45.760 --> 01:23:47.140
irgendwelche Skripte, die dann halt irgendwie

01:23:47.140 --> 01:23:49.940
über irgendeine Task, äh,

01:23:49.940 --> 01:23:52.160
ja, Skandalik lösen. Ja, das läuft natürlich dann,

01:23:52.160 --> 01:23:54.120
das ist unser Business Intelligence-System, also

01:23:54.120 --> 01:23:55.680
jetzt nicht sekundengenau funktioniert.

01:23:55.680 --> 01:23:58.140
Ja, genau. Weil wir halt immer wieder diese Jobs

01:23:58.140 --> 01:24:00.180
machen müssen. Wenn wir uns jetzt an was

01:24:00.180 --> 01:24:02.060
ganz anderes denken, weiß ich nicht, Aktienkursanalyse

01:24:02.060 --> 01:24:03.560
oder sowas, wir haben irgendwelche Portfolios, dann

01:24:03.560 --> 01:24:05.820
ist das natürlich dann doof, ne, weil

01:24:05.820 --> 01:24:08.360
dann das nicht dem echten Stock-Market

01:24:08.360 --> 01:24:10.200
entspricht dann, sondern wir müssen das halt

01:24:10.200 --> 01:24:11.960
dann jedes Mal eine neue Kopie machen, wenn man diese

01:24:11.960 --> 01:24:14.100
Analytics fahren will. Ja, ja, genau.

01:24:14.100 --> 01:24:16.120
Also, äh, natürlich, das ist, das ist tatsächlich

01:24:16.120 --> 01:24:18.100
ein Problem. Und, ähm,

01:24:18.100 --> 01:24:20.160
die, die Lösung

01:24:20.160 --> 01:24:22.100
dafür ist, dass man dann halt, äh, irgendwann nicht

01:24:22.100 --> 01:24:23.700
mehr so ETL in dem Sinne

01:24:23.700 --> 01:24:25.900
macht, dass man das halt irgendwie abends Batch-Processing macht,

01:24:25.900 --> 01:24:27.560
äh, sondern dass man halt

01:24:27.560 --> 01:24:30.260
irgendwie so Streaming-Geschichten, äh,

01:24:30.260 --> 01:24:32.240
verwendet, halt, äh, Apache Kafka

01:24:32.240 --> 01:24:33.900
und so ist halt etwas, was häufig verwendet wird.

01:24:33.900 --> 01:24:35.900
Aber da kommen wir später zu, weil das ist auch eine

01:24:35.900 --> 01:24:37.960
Geschichte, wo man, dann, das wird

01:24:37.960 --> 01:24:39.980
halt eh, äh, erst dann relevant,

01:24:39.980 --> 01:24:41.960
wenn man, wenn man dann

01:24:41.960 --> 01:24:43.980
nochmal ein gutes Stück größer geworden ist und

01:24:43.980 --> 01:24:45.920
man, äh, mit den traditionellen Data-Warehouse-Geschichten

01:24:45.920 --> 01:24:48.000
auch nicht mehr klarkommt. Und der Weltbeherrschung

01:24:48.000 --> 01:24:49.800
ist unikat. Ja, genau,

01:24:49.800 --> 01:24:52.040
dazu muss man dann schon mal noch ein bisschen, oder halt

01:24:52.040 --> 01:24:53.460
eine andere Art von Daten sammelt, ne.

01:24:53.460 --> 01:24:55.960
Ähm, also ich würde sagen, dieser klassische,

01:24:55.960 --> 01:24:58.360
äh, Bereich, ja, selbst wenn man halt, äh,

01:24:58.360 --> 01:24:59.940
nur tagesaktuelle Daten hat, ist man damit

01:24:59.940 --> 01:25:01.940
wahrscheinlich viel besser aufgestellt

01:25:01.940 --> 01:25:04.240
als jetzt wahrscheinlich viele stationäre,

01:25:04.240 --> 01:25:06.320
äh, Buchhändler oder so, ne. Selbst das, äh,

01:25:06.320 --> 01:25:07.900
wird einen schon, äh,

01:25:07.900 --> 01:25:10.040
wird einem da schon einen deutlichen Vorteil verschaffen. Und ich denke

01:25:10.040 --> 01:25:11.940
mal, am Anfang ist es halt so, dass, das ist halt das, was alle

01:25:11.940 --> 01:25:14.060
machen, womit alle irgendwie anfangen, dass sie das halt

01:25:14.060 --> 01:25:16.040
tagesweise oder so, äh,

01:25:16.040 --> 01:25:18.140
Batch-mäßig, äh, äh, erledigen.

01:25:18.140 --> 01:25:20.280
Und, äh,

01:25:20.280 --> 01:25:21.980
genau, ja, da ist man halt, äh,

01:25:21.980 --> 01:25:23.740
irgendwie so bei diesem Data-Warehousing-Thema. Ich hab da

01:25:23.740 --> 01:25:25.180
das mal irgendwann, ähm,

01:25:25.180 --> 01:25:27.400
äh,

01:25:27.400 --> 01:25:30.060
das ist auch in den Shownotes verlinkt, gibt's einen, äh,

01:25:30.060 --> 01:25:32.560
schönen Essay, äh,

01:25:32.560 --> 01:25:33.880
äh, der heißt, äh,

01:25:33.880 --> 01:25:36.020
Data-Warehousing for Cavemen. Ah, ja, genau.

01:25:36.020 --> 01:25:37.300
Das ist von 1997 oder so.

01:25:37.300 --> 01:25:39.740
Aber, äh,

01:25:39.740 --> 01:25:42.120
das finde ich nach wie vor gut, ist auch relativ humorvoll.

01:25:42.120 --> 01:25:44.580
Äh, da geht's darum, äh,

01:25:44.580 --> 01:25:46.080
der, der schreibt auch so,

01:25:46.080 --> 01:25:47.740
ja, vielleicht interessiert es manche Leute irgendwie, wie man

01:25:47.740 --> 01:25:49.940
da einer Dollar die Stunde, äh, verdienen kann, indem

01:25:49.940 --> 01:25:51.920
man irgendwie die sensibelsten Daten von irgendwelchen Firmen

01:25:51.920 --> 01:25:53.280
massiert. Muss ich sofort wissen, ja.

01:25:53.280 --> 01:25:56.060
Genau, weil beim Freelance ist das vielleicht gar nicht

01:25:56.060 --> 01:25:58.420
so uninteressant. Ja, und, äh,

01:25:58.420 --> 01:25:59.940
also, das ist auch ein Feld, das es schon lange

01:25:59.940 --> 01:26:02.060
gibt. Äh, ich hab das am Anfang aber auch nicht,

01:26:02.060 --> 01:26:03.760
ähm, ich hab zuerst nur diesen

01:26:03.760 --> 01:26:05.960
OTP-Use-Case gekannt und dann hab ich diesen, bin ich

01:26:05.960 --> 01:26:07.880
irgendwann auf diesen Essay gestoßen und dachte so, oh, das ist aber interessant.

01:26:07.880 --> 01:26:09.920
Und daraufhin halt

01:26:09.920 --> 01:26:11.880
dann auch so angefangen, mich so ein bisschen mit Data-Warehousing-Kram

01:26:11.880 --> 01:26:13.860
zu beschäftigen. Aber es ist auch ein sehr interessantes Thema.

01:26:13.860 --> 01:26:16.060
Also, der, der, der entscheidende Punkt ist im Grunde,

01:26:16.060 --> 01:26:17.920
dass man halt solche Abfragen machen

01:26:17.920 --> 01:26:18.960
können möchte, wie,

01:26:18.960 --> 01:26:21.860
äh, also, wie unterscheidet sich

01:26:21.860 --> 01:26:23.800
denn jetzt, äh, keine Ahnung,

01:26:23.800 --> 01:26:26.160
das Volumen der verkauften Bücher in einer bestimmten Kategorie,

01:26:26.160 --> 01:26:28.020
nachdem ich irgendeine Werbeaktion gemacht habe, ja.

01:26:28.020 --> 01:26:30.140
Oder, äh, B-Tests,

01:26:30.140 --> 01:26:31.680
ja, ich hab jetzt irgendwie manchen Usern,

01:26:31.680 --> 01:26:33.480
mh, bestimmter, äh,

01:26:33.480 --> 01:26:35.900
ja, die haben halt ein Design gesehen, das ein bisschen

01:26:35.900 --> 01:26:37.580
anders aussah oder halt, äh,

01:26:37.580 --> 01:26:39.800
ein bisschen anders. Oder alle Leute, die letzte Woche gekauft

01:26:39.800 --> 01:26:41.860
haben für ein bestimmtes Produkt, die bekommen

01:26:41.860 --> 01:26:43.760
jetzt einen besonderen Gutschein, der

01:26:43.760 --> 01:26:45.820
für drei Tage gültig ist oder sowas. Ja, und,

01:26:45.820 --> 01:26:47.640
und, genau, ich möchte hinterher gucken, was ist denn dann

01:26:47.640 --> 01:26:49.740
passiert, ja. War das jetzt erfolgreich oder nicht? Oder wie erfolgreich

01:26:49.740 --> 01:26:51.820
war denn das? Und, ähm,

01:26:51.820 --> 01:26:51.840
ähm,

01:26:51.840 --> 01:26:51.840
ähm,

01:26:51.840 --> 01:26:53.840
ähm, dafür muss ich halt, äh,

01:26:53.840 --> 01:26:55.840
ja, äh, bestimmte

01:26:55.840 --> 01:26:58.060
Arten von Anfragen, die ansonsten

01:26:58.060 --> 01:26:59.780
keine Rolle spielen können, gut machen können.

01:26:59.780 --> 01:27:01.780
Und dafür hab ich halt so eine Struktur. Ich hab eine

01:27:01.780 --> 01:27:03.980
Fakten-Tabelle und dann drumherum Dimensionstabellen,

01:27:03.980 --> 01:27:05.660
in denen halt solche Sachen drinstehen, wie,

01:27:05.660 --> 01:27:07.900
ja, das war jetzt ein User, äh,

01:27:07.900 --> 01:27:09.780
für den ich, dem ich diese Version

01:27:09.780 --> 01:27:11.720
der Webseite angezeigt habe. Oder das

01:27:11.720 --> 01:27:13.840
hier, äh, äh, also man hat zum Beispiel sowas wie,

01:27:13.840 --> 01:27:15.200
daran kann man's vielleicht ganz gut

01:27:15.200 --> 01:27:17.300
verstehen, ähm,

01:27:17.300 --> 01:27:20.060
Time ist halt eine Dimension. Und in der Fakten-Tabelle,

01:27:20.060 --> 01:27:21.560
also Fakten wären sowas wie Bestellungen,

01:27:21.820 --> 01:27:24.420
äh, ist halt, äh,

01:27:24.420 --> 01:27:26.020
sozusagen, Time

01:27:26.020 --> 01:27:28.040
nicht etwas, jetzt ein Zeitstempel oder so,

01:27:28.040 --> 01:27:30.200
der da reingeschrieben wird, sondern da ist halt, das ist halt eine

01:27:30.200 --> 01:27:31.620
ID, ein Fremdschlüssel,

01:27:31.620 --> 01:27:34.460
und der zeigt halt in eine Time-Dimension,

01:27:34.460 --> 01:27:35.660
und das ist halt eine,

01:27:35.660 --> 01:27:38.060
ähm, Dimensionstabelle, in der drinsteht,

01:27:38.060 --> 01:27:39.920
was diese Zeit bedeutet, und dann

01:27:39.920 --> 01:27:41.720
stehen da eben solche Dinge dran, wie,

01:27:41.720 --> 01:27:44.080
naja, also, auch da wiederum,

01:27:44.080 --> 01:27:45.900
kann sein, dass dann, also, da steht nicht

01:27:45.900 --> 01:27:47.900
weg der Zeitstempel, sondern da steht dann dran, also,

01:27:47.900 --> 01:27:49.780
das war ein Werktag. Das war ein

01:27:49.780 --> 01:27:51.420
Feiertag in folgenden Bundesländern.

01:27:51.800 --> 01:27:53.160
Äh, das war, äh,

01:27:53.160 --> 01:27:55.200
keine Ahnung, ähm, das war Sommer.

01:27:55.200 --> 01:27:57.420
Ja, sodass ich dann halt solche Abfragen machen kann, wie,

01:27:57.420 --> 01:27:59.680
äh, wie ist denn der Verkauf der Bücher

01:27:59.680 --> 01:28:01.460
in dieser Kategorie im Sommervergleich

01:28:01.460 --> 01:28:03.380
zu Winter? Ja, und dadurch, da ich

01:28:03.380 --> 01:28:05.460
diese Information, das ist jetzt Sommer, halt

01:28:05.460 --> 01:28:07.500
direkt an dem Zeitdings dran habe, kann ich halt

01:28:07.500 --> 01:28:09.700
Abfragen machen, die sehr effizient alles rausfiltern,

01:28:09.700 --> 01:28:11.440
was halt irgendwie Sommer ist, und, und so.

01:28:11.440 --> 01:28:12.180
Äh,

01:28:12.180 --> 01:28:15.880
aber solche Abfragen machen halt in, in dem OTP-Teil,

01:28:15.880 --> 01:28:17.400
oder wenn ich jetzt eine Webseite, machen überhaupt

01:28:17.400 --> 01:28:18.920
keinen Sinn. Das heißt, ja,

01:28:18.920 --> 01:28:21.060
die Schemata sehen dann halt ganz anders aus.

01:28:21.780 --> 01:28:23.480
Äh, ja, äh, genau.

01:28:23.480 --> 01:28:25.340
Wenn einen interessiert, wie das, wie das wirklich so

01:28:25.340 --> 01:28:27.100
ordentlich funktioniert, also ich finde, dieser, dieser

01:28:27.100 --> 01:28:29.420
Data Warehousing for Kaverman-Essay ist ein schöner Start.

01:28:29.420 --> 01:28:31.640
Äh, aber da gibt's auch jede Menge,

01:28:31.640 --> 01:28:33.360
kann man sich, kann man sich durchlesen, wie, wie das so

01:28:33.360 --> 01:28:34.900
klappt. Ähm,

01:28:34.900 --> 01:28:37.700
ja, äh,

01:28:37.700 --> 01:28:38.800
genau.

01:28:38.800 --> 01:28:41.120
Ach so.

01:28:41.120 --> 01:28:43.480
Äh, richtig, genau. Da haben wir jetzt

01:28:43.480 --> 01:28:45.300
schon mal ein bisschen über den Analyse-Teil gesprochen,

01:28:45.300 --> 01:28:47.280
aber wir haben natürlich auch ein Problem, wenn

01:28:47.280 --> 01:28:48.740
jetzt Leute immer mehr Zeugs kaufen,

01:28:48.740 --> 01:28:51.520
ähm, dass irgendwie, äh,

01:28:51.760 --> 01:28:54.040
halt unsere, äh, unsere Datenbank

01:28:54.040 --> 01:28:55.460
halt vielleicht irgendwann ein bisschen langsamer wird,

01:28:55.460 --> 01:28:57.620
nicht mehr, nicht mehr genug Transaktionen prozessen kann.

01:28:57.620 --> 01:28:59.740
Ja, was macht man da? Man muss halt optimieren,

01:28:59.740 --> 01:29:01.480
das ist auch oft ein wichtiger Teil,

01:29:01.480 --> 01:29:03.180
und es ist auch nicht so einfach, ähm,

01:29:03.180 --> 01:29:06.080
weil mal so ein, äh,

01:29:06.080 --> 01:29:08.160
die einzige Datenbank,

01:29:08.160 --> 01:29:09.740
für die ich das wirklich mal gemacht habe,

01:29:09.740 --> 01:29:11.460
so, äh, war, war jetzt eigentlich MySQL,

01:29:11.460 --> 01:29:13.000
ich verwende heutzutage eher Postgres, aber,

01:29:13.000 --> 01:29:15.640
äh, äh, da hab ich dann auch mal so ein, so ein

01:29:15.640 --> 01:29:17.740
Optimierungs-, äh, MySQL

01:29:17.740 --> 01:29:19.220
Performance-Optimierungskurs besucht,

01:29:19.220 --> 01:29:21.660
äh, und,

01:29:21.740 --> 01:29:23.660
äh, das, äh, schönes Zitat, also,

01:29:23.660 --> 01:29:25.640
äh, Chris Köntrop hat den, den damals

01:29:25.640 --> 01:29:27.700
irgendwo in München, äh,

01:29:27.700 --> 01:29:29.820
äh, durchgeführt, äh, der damals

01:29:29.820 --> 01:29:32.100
hat da bei MySQL gearbeitet, und,

01:29:32.100 --> 01:29:34.000
ähm, der, äh,

01:29:34.000 --> 01:29:35.740
der Einsatz, der mir auch in Erinnerung

01:29:35.740 --> 01:29:37.460
geblieben ist, der meinte so, ja, wenn man Datenbank

01:29:37.460 --> 01:29:39.600
Performance optimieren will, ja, so,

01:29:39.600 --> 01:29:41.680
OLTP, ähm,

01:29:41.680 --> 01:29:43.700
dann gibt es da eigentlich, äh, so im Wesentlichen

01:29:43.700 --> 01:29:45.580
drei Sachen, die man tun kann, um eine Datenbank

01:29:45.580 --> 01:29:47.640
schnell zu machen, ja, also, das Erste,

01:29:47.640 --> 01:29:49.560
was man eigentlich immer machen kann, äh,

01:29:49.560 --> 01:29:51.440
das ist, das funktioniert auch fast immer,

01:29:51.440 --> 01:29:51.720
äh, das ist, äh,

01:29:51.720 --> 01:29:53.640
das ist super, kann einfach mal ein bisschen mehr

01:29:53.640 --> 01:29:55.740
Hauptspeicher reinstecken in die Datenbank, ne, das ist schon mal

01:29:55.740 --> 01:29:57.700
auf jeden Fall schneller, das, das ist immer gut.

01:29:57.700 --> 01:29:59.920
Und das, wenn das

01:29:59.940 --> 01:30:01.680
nicht mehr so richtig reicht. Eine zweite

01:30:01.680 --> 01:30:03.760
Geschichte, die man auch immer tun kann, auch sehr gut

01:30:03.760 --> 01:30:05.800
hilft, ist, man kann einfach noch ein bisschen

01:30:05.800 --> 01:30:07.280
mehr Speicher reinstecken in die Datenbank.

01:30:07.280 --> 01:30:09.200
Und das dritte Ding ist...

01:30:09.200 --> 01:30:11.780
Das dritte Ding ist, wenn man

01:30:11.780 --> 01:30:13.380
an eine Grenze gekommen ist,

01:30:13.380 --> 01:30:15.280
die dann auch...

01:30:15.280 --> 01:30:17.760
Das letzte Mittel, zu dem man greifen kann, wenn das auch nicht

01:30:17.760 --> 01:30:19.880
hilft, ist halt, man könnte einfach ein bisschen mehr Hauptspeicher

01:30:19.880 --> 01:30:20.880
in die Datenbank reinstecken.

01:30:20.880 --> 01:30:23.860
Okay. Wie viel Hauptspeicher

01:30:23.860 --> 01:30:25.080
hat denn dann so eine große Datenbank?

01:30:25.080 --> 01:30:27.380
Ja, so viel, wie halt geht eigentlich.

01:30:27.380 --> 01:30:29.160
Also es kommt darauf an, wie viel du benötigst.

01:30:29.240 --> 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.160 --> 01:30:34.580
die du auf einer Webseite verkaufen willst,

01:30:34.580 --> 01:30:36.020
dann ist es egal.

01:30:36.020 --> 01:30:39.800
Da kommst du halt

01:30:39.800 --> 01:30:41.220
mit einem, weiß ich nicht,

01:30:41.220 --> 01:30:43.780
mit der Beliebigkeit,

01:30:43.780 --> 01:30:45.280
mit einem Raspberry Pi kannst du das machen.

01:30:45.280 --> 01:30:46.900
Das ist wurscht. Aber

01:30:46.900 --> 01:30:48.680
wenn du jetzt,

01:30:48.680 --> 01:30:50.860
sagen wir mal so, wenn dein

01:30:50.860 --> 01:30:53.040
Working Set der Datenbank, also die

01:30:53.040 --> 01:30:55.420
Menge der Daten, die halt auf der Platte liegen, wenn die Datenbank

01:30:55.420 --> 01:30:57.300
runtergefahren ist, wenn das halt

01:30:57.300 --> 01:30:58.620
30 Gigabyte hat,

01:30:58.740 --> 01:31:01.120
dann sollte deine Datenbank mindestens mal

01:31:01.120 --> 01:31:03.060
30 Gigabyte haben, eher so 64 vielleicht.

01:31:03.060 --> 01:31:04.420
Hauptspeicher.

01:31:04.420 --> 01:31:07.180
Weil es gibt halt auch noch diverse Strukturen, die im Hauptspeicher

01:31:07.180 --> 01:31:09.140
gehalten werden, die man halt auch

01:31:09.140 --> 01:31:09.540
braucht.

01:31:09.540 --> 01:31:13.360
Und dann ist halt

01:31:13.360 --> 01:31:15.360
das Limit eigentlich nur, also sagen wir so,

01:31:15.360 --> 01:31:15.980
das ist halt viel.

01:31:15.980 --> 01:31:19.180
Nehmen wir an, wir haben das, was heute

01:31:19.180 --> 01:31:21.020
so ein Sweetspot ist, sind es halt

01:31:21.020 --> 01:31:22.780
vielleicht 256 Gigabyte oder so.

01:31:22.780 --> 01:31:24.240
Hauptspeicher.

01:31:24.240 --> 01:31:27.120
Da geht eine ganze Menge rein.

01:31:27.120 --> 01:31:27.980
Also es ist halt,

01:31:28.040 --> 01:31:29.780
ist für mich schwer

01:31:29.780 --> 01:31:30.380
vorstellbar,

01:31:30.380 --> 01:31:34.140
welche Systeme, die Transaction Processing

01:31:34.140 --> 01:31:35.340
machen, dann mehr Hauptspeicher benötigen.

01:31:35.340 --> 01:31:37.960
Oder mehr Daten haben, die sie jetzt

01:31:37.960 --> 01:31:39.760
unbedingt im Hauptspeicher halten müssen. Das gibt es kaum.

01:31:39.760 --> 01:31:41.720
Also, ja gut,

01:31:41.720 --> 01:31:43.580
es gibt schon, wenn man jetzt an sowas denkt, wie

01:31:43.580 --> 01:31:45.960
Google, man indiziert das Web und möchte

01:31:45.960 --> 01:31:47.880
halt so ein Echtzeit-Suchabfragen

01:31:47.880 --> 01:31:49.760
über alle Webseiten machen, das geht nicht mehr.

01:31:49.760 --> 01:31:50.300
Das ist klar.

01:31:50.300 --> 01:31:53.820
Aber so

01:31:53.820 --> 01:31:56.040
viele...

01:31:56.040 --> 01:31:57.720
So groß müsste man werden. Also Amazon,

01:31:57.840 --> 01:31:59.640
fällt da bestimmt auch nicht rein. Also Amazon

01:31:59.640 --> 01:32:01.480
hat...

01:32:01.480 --> 01:32:02.280
Na gut,

01:32:02.280 --> 01:32:05.740
Amazons Teil, der einen jetzt mit Produkten

01:32:05.740 --> 01:32:06.100
versorgt,

01:32:06.100 --> 01:32:09.500
diese Webseite, das wird nicht so groß sein.

01:32:09.500 --> 01:32:11.800
Die haben andere Teile, die halt

01:32:11.800 --> 01:32:13.460
dann unter Umständen sehr groß geworden sind, aber

01:32:13.460 --> 01:32:15.720
ja, das kriegst du eigentlich alles locker

01:32:15.720 --> 01:32:17.380
in einer Datenbank unter.

01:32:17.380 --> 01:32:19.600
Die haben dann halt ein anderes Problem. Amazon wird das Problem bekommen,

01:32:19.600 --> 01:32:21.500
dass die halt mit der Schreiblast nicht mehr klarkommen.

01:32:21.500 --> 01:32:23.660
Aber das könntest du

01:32:23.660 --> 01:32:25.900
alles irgendwie in den Hauptspeicher

01:32:25.900 --> 01:32:27.140
von so einer Datenbank packen.

01:32:27.840 --> 01:32:29.340
Also ich würde sagen, für die

01:32:29.340 --> 01:32:31.560
fast alle Anwendungsfälle heutzutage

01:32:31.560 --> 01:32:32.320
ist das halt groß genug.

01:32:32.320 --> 01:32:35.600
Ja, ab

01:32:35.600 --> 01:32:37.380
256 Gigabyte wird es ein bisschen schwierig.

01:32:37.380 --> 01:32:39.860
Also man

01:32:39.860 --> 01:32:41.700
kann auch einen Terabyte Hauptspeicher irgendwie

01:32:41.700 --> 01:32:43.460
in den Rechner stecken.

01:32:43.460 --> 01:32:45.720
Das kostet irgendwie weniger als 10.000 Euro heutzutage.

01:32:45.720 --> 01:32:47.600
Ja, also das geht auch. Es wird dann halt,

01:32:47.600 --> 01:32:49.600
wenn man so wirklich so wahnsinnig viel Hauptspeicher drin hat,

01:32:49.600 --> 01:32:51.480
dann kriegt man halt ein bisschen Probleme mit der

01:32:51.480 --> 01:32:53.600
Architektur, das ist ja so

01:32:53.600 --> 01:32:55.540
ein bisschen PC-basiert und

01:32:55.540 --> 01:32:57.740
so viel Hauptspeicher-Wandbreite hat man da ja nicht.

01:32:57.840 --> 01:32:58.840
Und das wird dann irgendwann,

01:32:58.840 --> 01:33:01.920
man muss ja die ganzen Prozessoren auch irgendwie mit Daten

01:33:01.920 --> 01:33:03.880
versorgen, ja, und wenn man jetzt da irgendwie,

01:33:03.880 --> 01:33:04.380
weiß ich nicht,

01:33:04.380 --> 01:33:06.480
da fährt ja kein Bus hin.

01:33:06.480 --> 01:33:09.440
32 Prozessoren oder 64 oder sowas.

01:33:09.440 --> 01:33:11.840
So irgendwann ist dann halt, also der Sweet Spot ist

01:33:11.840 --> 01:33:13.960
würde ich sagen heute eher so bei, weiß ich nicht,

01:33:13.960 --> 01:33:15.880
irgendwie 64 Prozessoren oder sowas und 256

01:33:15.880 --> 01:33:17.180
Gigabyte Hauptspeicher und so.

01:33:17.180 --> 01:33:19.980
Aber das, also egal, also vielleicht geht auch ein Terabyte,

01:33:19.980 --> 01:33:20.520
ich hab keine Ahnung.

01:33:20.520 --> 01:33:23.420
Für die meisten, aller, aller, aller

01:33:23.420 --> 01:33:25.580
Anwendungsfälle reicht das alles vollkommen aus.

01:33:25.580 --> 01:33:27.680
Und es ist ein sehr guter Tipp,

01:33:27.680 --> 01:33:29.600
zu sagen, also jetzt, wenn du

01:33:29.600 --> 01:33:31.520
tatsächlich irgendwie ein Working Set von 30 Gigabyte

01:33:31.520 --> 01:33:33.520
hättest, nimm nicht eine Datenbank, die

01:33:33.520 --> 01:33:35.500
jetzt 8 Gigabyte hat, dann hast du ein Problem. Dann bist du gleich

01:33:35.500 --> 01:33:37.980
mal irgendwie mehrere Größenordnungen

01:33:37.980 --> 01:33:39.580
langsamer, als wenn du das in den Hauptspeicher

01:33:39.580 --> 01:33:41.480
packen würdest, ja, und kriegst halt einen Haufen Probleme, die

01:33:41.480 --> 01:33:42.360
du sonst einfach nicht hättest.

01:33:42.360 --> 01:33:45.580
Ja, das war früher alles noch viel schlimmer, als es

01:33:45.580 --> 01:33:47.160
einen riesigen Unterschied gab zwischen

01:33:47.160 --> 01:33:49.420
sozusagen permanentem Storage,

01:33:49.420 --> 01:33:50.440
also

01:33:50.440 --> 01:33:53.440
rotierendem Rost,

01:33:53.440 --> 01:33:54.720
ja, so alles.

01:33:54.720 --> 01:33:57.200
Und Hauptspeicher, ja, da war der

01:33:57.520 --> 01:33:59.800
Unterschied so

01:33:59.800 --> 01:34:03.520
1 zu 10.000 oder so

01:34:03.520 --> 01:34:05.760
Geschwindigkeitsunterschied. Das ist jetzt

01:34:05.760 --> 01:34:06.620
nicht mehr ganz so schlimm,

01:34:06.620 --> 01:34:09.740
wenn man SSDs hat, aber es ist

01:34:09.740 --> 01:34:11.560
immer noch ziemlich schlimm, also es ist immer noch

01:34:11.560 --> 01:34:13.440
ein riesen Unterschied, und daher

01:34:13.440 --> 01:34:15.480
ja, das

01:34:15.480 --> 01:34:17.520
will eigentlich, dass die heißen Daten im Hauptspeicher sind.

01:34:17.520 --> 01:34:18.320
Ja,

01:34:18.320 --> 01:34:21.700
genau, das ist halt

01:34:21.700 --> 01:34:23.600
ein Ansatz, um das zu optimieren, dann hat man oft das

01:34:23.600 --> 01:34:25.320
Problem, man hat halt so eine Asymmetrie zwischen

01:34:25.320 --> 01:34:27.360
Lese- und Schreibquerys,

01:34:27.360 --> 01:34:29.480
und selbst wenn man mit

01:34:29.480 --> 01:34:31.420
so einer Datenbank halt irgendwie

01:34:31.420 --> 01:34:32.840
ein paar tausend Queries pro Sekunde

01:34:32.840 --> 01:34:33.880
abfeiern kann,

01:34:33.880 --> 01:34:37.260
irgendwann gerät man in eine

01:34:37.260 --> 01:34:39.260
Konkurrenz zwischen Schreibquerys und Lesequerys,

01:34:39.260 --> 01:34:41.360
wenn man jetzt nur eine Datenbank verwendet,

01:34:41.360 --> 01:34:43.340
und das ist halt irgendwie schlecht, weil

01:34:43.340 --> 01:34:45.040
man möchte eigentlich immer in der Lage sein, weil man

01:34:45.040 --> 01:34:47.300
braucht ja eine, man darf eigentlich nur eine Datenbank

01:34:47.300 --> 01:34:49.140
haben, auf die man schreibt, also

01:34:49.140 --> 01:34:51.300
wenn man mehrere Datenbanken hat, von denen man liest, ist nicht so schlimm,

01:34:51.300 --> 01:34:53.380
das geht, aber man kann halt nicht

01:34:53.380 --> 01:34:55.340
so richtig gut mehrere Datenbanken haben, auf die man

01:34:55.340 --> 01:34:57.040
schreibt, weil man ja

01:34:57.040 --> 01:34:59.180
diesen zentralen Punkt, an dem der

01:34:59.180 --> 01:35:01.060
Status gehalten wird, behalten möchte.

01:35:01.060 --> 01:35:03.300
Wenn wir scheinbar auf dieselbe Stelle schreiben, zum Beispiel.

01:35:03.300 --> 01:35:03.820
Ja, genau.

01:35:03.820 --> 01:35:07.040
Also, was man jetzt machen könnte, wenn man zu viele

01:35:07.040 --> 01:35:09.320
Leseanfragen hat, man verteilt die dann

01:35:09.320 --> 01:35:11.140
halt auf sogenannte Slave-Datenbanken, das heißt,

01:35:11.140 --> 01:35:12.760
man hat halt so eine Master-Slave-Architektur,

01:35:12.760 --> 01:35:15.220
und eine Master-Datenbank,

01:35:15.220 --> 01:35:17.400
von der man lesen und schreiben kann,

01:35:17.400 --> 01:35:19.380
von der man lesen kann und auf die man schreiben kann,

01:35:19.380 --> 01:35:21.580
und

01:35:21.580 --> 01:35:23.300
es gibt

01:35:23.300 --> 01:35:24.680
halt eine Reihe von

01:35:24.680 --> 01:35:26.680
Slave-Datenbanken, von denen man nur lesen kann,

01:35:26.720 --> 01:35:28.640
auf die man nicht schreiben kann. Wie oft wird denn da geslaved?

01:35:28.640 --> 01:35:30.780
Also, wie oft wird dieser Slave denn aktualisiert auf den Master?

01:35:30.780 --> 01:35:32.460
Ja, da gibt es dann Mechanismen für,

01:35:32.460 --> 01:35:36.420
also der Master schreibt halt irgendwie

01:35:36.420 --> 01:35:38.460
einen Log, das Log wird irgendwie an die Slaves übertragen,

01:35:38.460 --> 01:35:40.360
und die vollziehen dann sozusagen die Transaktionen,

01:35:40.360 --> 01:35:41.660
die der Master gemacht hat, halt nach.

01:35:41.660 --> 01:35:43.800
Das ist

01:35:43.800 --> 01:35:46.360
meistens wahrscheinlich instantan, mehr oder weniger.

01:35:46.360 --> 01:35:48.660
Bei viel Last,

01:35:48.660 --> 01:35:50.740
oder wenn halt eine große geografische

01:35:50.740 --> 01:35:52.160
Differenz ist, also wenn es halt irgendwie über

01:35:52.160 --> 01:35:54.360
den Atlantik oder den Pazifik geht oder so, klar, dann hast du halt

01:35:54.360 --> 01:35:56.540
Zeitunterschiede, oder halt auch wenn die Last so groß ist,

01:35:56.640 --> 01:35:58.580
dass die Slaves nicht mehr

01:35:58.580 --> 01:35:59.320
gut hinterherkommen,

01:35:59.320 --> 01:36:02.400
dann hast du natürlich,

01:36:02.400 --> 01:36:04.540
dann hast du eventuell so ein bisschen Lack von vielleicht ein paar

01:36:04.540 --> 01:36:06.300
Sekunden oder vielleicht auch mal eine Minute oder sowas.

01:36:06.300 --> 01:36:08.540
Aber es gibt halt viele Anfragen, für die ist

01:36:08.540 --> 01:36:10.200
das egal. Also viele Leseanfragen

01:36:10.200 --> 01:36:12.480
ist auch, oft cached man das ja auch

01:36:12.480 --> 01:36:14.000
dann nochmal irgendwie im Hauptspeicher

01:36:14.000 --> 01:36:16.480
in Redis oder Memcache

01:36:16.480 --> 01:36:18.240
oder so, und sagt halt ja,

01:36:18.240 --> 01:36:20.420
also dieses Ding hier kannst du fünf Minuten lang

01:36:20.420 --> 01:36:21.020
cachen.

01:36:21.020 --> 01:36:24.380
Das ist ja dann auch egal, und

01:36:24.380 --> 01:36:26.480
bei den Anfragen, die auf Slaves gehen, ist auch so

01:36:26.480 --> 01:36:28.520
oft so, es ist halt wurscht, also so oft

01:36:28.520 --> 01:36:30.320
ändern sich Dinge halt nicht, wenn irgendein Account nicht so richtig

01:36:30.320 --> 01:36:32.320
stimmt oder so. Naja, nicht so

01:36:32.320 --> 01:36:34.360
schlimm. Es gibt Dinge, bei denen das schlimm

01:36:34.360 --> 01:36:36.280
ist, aber kommen gleich noch zu, da muss man das halt

01:36:36.280 --> 01:36:38.360
anders machen, aber bei vielen

01:36:38.360 --> 01:36:40.400
Sachen 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.440 --> 01:36:43.880
Man kann halt dann die Leselast auf die

01:36:43.880 --> 01:36:46.360
Slaves sozusagen transferieren

01:36:46.360 --> 01:36:48.260
und dann gibt es halt bestimmte Abfragen,

01:36:48.260 --> 01:36:50.260
also gerade, wenn man jetzt kurz davor ist,

01:36:50.260 --> 01:36:52.360
eine Bestellung zu machen oder so, wo man dann schon

01:36:52.360 --> 01:36:54.440
im Code weiß, so okay, jetzt gibt's

01:36:54.440 --> 01:36:56.400
hier gleich eine Transaktion oder so, und dann

01:36:56.400 --> 01:36:58.340
macht man auch die Leseanfragen auf den Master, damit

01:36:58.340 --> 01:37:00.280
man da halt eben nicht das Problem hat, dass man

01:37:00.280 --> 01:37:02.280
eventuell Daten sieht, die eine Minute alt

01:37:02.280 --> 01:37:04.320
sind, aber da das die allermeisten

01:37:04.320 --> 01:37:05.840
Anfragen ja gar nicht sind, sondern

01:37:05.840 --> 01:37:08.540
die meisten Navigationsanfragen, wenn ich jetzt in Kategorien

01:37:08.540 --> 01:37:10.480
rumklicke oder irgendwelche Filter

01:37:10.480 --> 01:37:12.240
auswähle oder nach irgendwas suche oder so,

01:37:12.240 --> 01:37:14.480
diese ganzen Anfragen beziehen sich auf Daten,

01:37:14.480 --> 01:37:16.400
die sich jetzt gar nicht so häufig ändern. Das kann

01:37:16.400 --> 01:37:18.520
alles auch eine Minute alt sein, das ist wurscht.

01:37:18.520 --> 01:37:20.340
Und erst wenn ich halt

01:37:20.340 --> 01:37:21.400
eine Bestellung mache, dann

01:37:21.400 --> 01:37:24.460
muss ich halt zusehen, dass ich aktuelle

01:37:24.460 --> 01:37:26.000
Daten sehe, wie zum Beispiel ist halt

01:37:26.320 --> 01:37:27.920
das Buch noch auf Lager oder so.

01:37:27.920 --> 01:37:30.660
Und diese wenigen Anfragen,

01:37:30.660 --> 01:37:31.380
die halt dann

01:37:31.380 --> 01:37:34.540
aktuell sein sollten, die gehen

01:37:34.540 --> 01:37:36.340
dann direkt an den Master. Und das kann man halt im Code sagen.

01:37:36.340 --> 01:37:38.340
Man kann ja sagen, okay, an dieser Stelle

01:37:38.340 --> 01:37:40.360
bitte eine Verbindung auf den Master und nicht auf den

01:37:40.360 --> 01:37:42.280
Slave. Und

01:37:42.280 --> 01:37:44.420
die Schreibanfragen müssen dann halt auf den

01:37:44.420 --> 01:37:46.300
Master gehen, weil man ja nur an einer

01:37:46.300 --> 01:37:47.280
Stelle schreiben will.

01:37:47.280 --> 01:37:50.340
Und mit dieser Architektur kommt man relativ weit.

01:37:50.340 --> 01:37:52.200
Also das ist eine

01:37:52.200 --> 01:37:54.340
Geschichte, das ist auch so klassischer

01:37:54.340 --> 01:37:56.300
Lampstack-Architektur, Wikipedia-Seite,

01:37:56.320 --> 01:37:57.020
so aufgebaut.

01:37:57.020 --> 01:37:59.920
Du hast jetzt gerade noch zwei Sachen gesagt, die vielleicht noch mal kurz von uns

01:37:59.920 --> 01:38:02.140
von Redis einmal eben gesprochen und

01:38:02.140 --> 01:38:04.020
gerade vom 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.200 --> 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.140 --> 01:38:13.700
kann teilweise sortierte

01:38:13.700 --> 01:38:16.060
Listen und sowas auch halten,

01:38:16.060 --> 01:38:18.280
aber kann ein bisschen

01:38:18.280 --> 01:38:19.300
mehr als Memcached.

01:38:19.300 --> 01:38:22.120
Memcached ist rein so, du hast ein Key und

01:38:22.120 --> 01:38:24.040
kriegst halt dann irgendwie Value zurück und wird

01:38:24.040 --> 01:38:25.560
im Hauptspeicher gehalten, deswegen ist es schön schnell.

01:38:26.320 --> 01:38:28.500
Wurde popularisiert

01:38:28.500 --> 01:38:30.000
auch Memcached, vor allen Dingen durch den

01:38:30.000 --> 01:38:32.120
Lampstack. Lamp ist einfach Linux, Apache,

01:38:32.120 --> 01:38:33.520
MySQL, PHP

01:38:33.520 --> 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 ich weiß nicht, ob sie das noch benutzen, keine Ahnung,

01:38:42.120 --> 01:38:44.360
ist halt Wikipedia. Wir haben auch immer

01:38:44.360 --> 01:38:44.840
schöne

01:38:44.840 --> 01:38:48.200
Artikel darüber gehabt, wie sie

01:38:48.200 --> 01:38:50.120
ihre Systeme aufbauen. Also ist ja auch Wikipedia

01:38:50.120 --> 01:38:52.340
eine der, ich glaube, die sind auch mit Sicherheit immer noch

01:38:52.340 --> 01:38:53.700
in den Top 10 der weltweit

01:38:53.700 --> 01:38:56.000
teufelstärksten Seiten und

01:38:56.000 --> 01:38:57.780
haben halt auch viel dazu veröffentlicht, wie

01:38:57.780 --> 01:38:59.200
ihre Architektur aussieht.

01:38:59.200 --> 01:39:01.800
Und die haben halt auch genau das, die meisten Sachen sind

01:39:01.800 --> 01:39:04.020
Leseranfragen, aber manchmal wird halt auch was geändert

01:39:04.020 --> 01:39:06.120
oder geschrieben und die machen das halt mit

01:39:06.120 --> 01:39:07.920
MySQL und vielen Slaves und

01:39:07.920 --> 01:39:10.220
ja, extensiver

01:39:10.220 --> 01:39:11.820
Verwendung von Memcached, die zum

01:39:11.820 --> 01:39:13.880
Cachen von irgendwelchen gerenderten Fragmenten und

01:39:13.880 --> 01:39:16.040
Daten, für die man jetzt

01:39:16.040 --> 01:39:17.240
nicht nochmal eine Query machen möchte.

01:39:17.240 --> 01:39:20.000
Was wäre denn jetzt der neueste Stack, würdest du sagen, den man jetzt

01:39:20.000 --> 01:39:20.600
verwenden sollte?

01:39:20.600 --> 01:39:23.920
Ja, das kommt halt darauf an, wenn man eben

01:39:23.920 --> 01:39:24.680
PHP mag.

01:39:26.000 --> 01:39:28.260
Ja, kann man das auch

01:39:28.260 --> 01:39:30.020
immer noch machen,

01:39:30.020 --> 01:39:31.980
wobei ich jetzt nicht genau weiß, ob das alles immer noch so

01:39:31.980 --> 01:39:34.000
populär ist. Memcached, glaube ich, ist so ein bisschen auf dem Weg

01:39:34.000 --> 01:39:35.880
nach draußen. Wahrscheinlich

01:39:35.880 --> 01:39:37.640
würde auch in dem Umfeld eher heutzutage

01:39:37.640 --> 01:39:38.480
Redis verwendet.

01:39:38.480 --> 01:39:41.700
Aber jetzt

01:39:41.700 --> 01:39:43.540
im Python-Umfeld

01:39:43.540 --> 01:39:45.700
würde ich sagen, ja, da ist halt

01:39:45.700 --> 01:39:47.520
einmal so grob die Wahl zwischen,

01:39:47.520 --> 01:39:49.940
es gibt natürlich noch viel mehr und es gibt natürlich auch gute Gründe,

01:39:49.940 --> 01:39:51.780
andere Sachen zu verwenden, aber so die populärsten

01:39:51.780 --> 01:39:54.000
Geschichten sind halt Django und Flask

01:39:54.000 --> 01:39:56.000
und eben als

01:39:56.000 --> 01:39:57.680
in Memory Cache

01:39:57.680 --> 01:39:59.480
ist bei beiden eigentlich

01:39:59.480 --> 01:40:01.180
Redis sozusagen, dass das verwendet wird.

01:40:01.180 --> 01:40:03.440
Datenbank, eigentlich würde ich auch sagen,

01:40:03.440 --> 01:40:04.920
Postgres wird bei beiden verwendet.

01:40:04.920 --> 01:40:07.560
Man kann auch was anderes nehmen natürlich. Ja, es gibt auch Leute, die

01:40:07.560 --> 01:40:09.500
Django mit MongoDB verwenden.

01:40:09.500 --> 01:40:11.480
Das geht. Es gibt auch sogar valide

01:40:11.480 --> 01:40:13.520
Use Cases dafür. Es gibt auch Leute, die

01:40:13.520 --> 01:40:15.420
Flask

01:40:15.420 --> 01:40:18.000
irgendwie mit, weiß ich nicht,

01:40:18.000 --> 01:40:20.380
CouchDB

01:40:20.380 --> 01:40:21.880
mit allen

01:40:21.880 --> 01:40:23.240
möglichen Dingen verheiraten.

01:40:23.240 --> 01:40:25.780
Aber so als, womit ich

01:40:25.780 --> 01:40:27.420
anfangen würde, ist auf jeden Fall Postgres

01:40:27.420 --> 01:40:29.560
und dann halt eben SQL Alchemy beziehungsweise

01:40:29.560 --> 01:40:30.200
Django ORM

01:40:30.200 --> 01:40:33.620
und Redis, genau, als

01:40:33.620 --> 01:40:34.860
in Memory Cache und

01:40:34.860 --> 01:40:37.800
ja, wahrscheinlich braucht man auch noch ein Message

01:40:37.800 --> 01:40:38.460
Queue-System.

01:40:38.460 --> 01:40:41.740
Ist aber

01:40:41.740 --> 01:40:43.760
dann auch schon, also dann gibt es noch so ein paar Sachen, die man

01:40:43.760 --> 01:40:45.180
braucht. Was ist denn die Message Queue?

01:40:45.180 --> 01:40:47.280
Also man hat oft so Dinge,

01:40:47.280 --> 01:40:49.740
wo man dem User möglicherweise

01:40:49.740 --> 01:40:51.080
etwas direkt

01:40:51.080 --> 01:40:54.120
eine Antwort

01:40:54.120 --> 01:40:55.560
geben will, aber

01:40:55.560 --> 01:40:57.500
es ist halt ein Job, der dann irgendwie länger

01:40:57.500 --> 01:40:58.140
dauert, wie

01:40:58.140 --> 01:41:01.600
in unserem Buchstore wäre das

01:41:01.600 --> 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.180 --> 01:41:07.080
Na gut, warte mal, lass mal überlegen.

01:41:07.080 --> 01:41:09.060
Das ist kein so gutes Beispiel. End-User, was

01:41:09.060 --> 01:41:10.420
könnte der denn tun?

01:41:10.420 --> 01:41:13.560
Ja,

01:41:13.560 --> 01:41:14.700
zum Beispiel

01:41:14.700 --> 01:41:19.060
du verfasst einen Kommentar jetzt

01:41:19.060 --> 01:41:21.220
oder eine Bewertung für irgendeinen Artikel

01:41:21.220 --> 01:41:23.460
und du möchtest, wenn der jetzt

01:41:23.460 --> 01:41:25.420
auf Abschicken drückt, der User, dass er

01:41:25.420 --> 01:41:27.380
sofort seinen Kommentar unter dem

01:41:27.380 --> 01:41:27.920
Artikel sieht.

01:41:27.920 --> 01:41:31.600
Aber in Wirklichkeit

01:41:31.600 --> 01:41:35.160
wenn wir den ja vielleicht noch prüfen,

01:41:35.160 --> 01:41:36.600
also wenn das jetzt irgendwas Populäres ist.

01:41:36.600 --> 01:41:37.360
Sag mal so, du

01:41:37.360 --> 01:41:38.400
oder

01:41:38.400 --> 01:41:45.380
das könnte jetzt

01:41:45.380 --> 01:41:46.160
hässlich geworden sein.

01:41:46.160 --> 01:41:48.160
Das tut mir leid, da muss ich mich entschuldigen.

01:41:48.160 --> 01:41:50.520
Bisschen erkältet.

01:41:50.520 --> 01:41:52.940
Ja,

01:41:52.940 --> 01:41:53.720
ähm

01:41:53.720 --> 01:41:54.060
ähm

01:41:54.060 --> 01:41:55.260
ähm

01:41:55.260 --> 01:41:55.260
ähm

01:41:55.260 --> 01:41:55.280
ähm

01:41:55.280 --> 01:41:55.900
wenn

01:41:55.900 --> 01:41:57.900
also eigentlich möchte man halt

01:41:57.900 --> 01:41:59.880
wenn jetzt zum Beispiel ein Artikel ist, der häufig

01:41:59.880 --> 01:42:01.700
verkauft wird, ja, und dann jemand schreibt irgendwie

01:42:01.700 --> 01:42:04.200
der Artikel ist voll scheiße, keine Ahnung

01:42:04.200 --> 01:42:06.920
ähm, das hat ja dann unter Umständen direkt

01:42:06.920 --> 01:42:08.580
äh, äh, Konsequenzen

01:42:08.580 --> 01:42:10.700
oder es macht am besten noch irgendwie ein Mitbewerber

01:42:10.700 --> 01:42:12.500
äh, macht irgendwas fieses, äh, irgendwie

01:42:12.500 --> 01:42:15.100
ähm, ähm

01:42:15.100 --> 01:42:17.400
ja, dann will man das möglicherweise nicht, dass das sofort

01:42:17.400 --> 01:42:18.900
allen sichtbar wird, sondern man muss halt

01:42:18.900 --> 01:42:20.240
irgendwie erst irgendwie, ja

01:42:20.240 --> 01:42:23.160
irgendeine Redaktion drauf gucken oder so

01:42:23.160 --> 01:42:25.120
äh, aber das ist halt nicht

01:42:25.120 --> 01:42:27.000
etwas, was man dem User anzeigen möchte, also

01:42:27.000 --> 01:42:29.040
ähm, man hat dann halt sozusagen etwas

01:42:29.040 --> 01:42:31.120
so zwei Prozesse, die voneinander so ein bisschen entkoppelt

01:42:31.120 --> 01:42:32.980
sind, so man, man, der User drückt auf Speichern, sieht

01:42:32.980 --> 01:42:35.140
seinen Kommentar oder seine Bewertung und

01:42:35.140 --> 01:42:37.060
ähm, 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 drauf gucken sollte

01:42:40.480 --> 01:42:43.360
äh, aber das geht halt 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.000
ja, in so eine Queue, in eine Warteschlange

01:42:47.000 --> 01:42:48.980
eingereiht, ja, dann gibt's eine Redaktion, die hat dann halt

01:42:48.980 --> 01:42:50.940
diese Jobs, muss sich halt irgendwelche Kommentare an

01:42:50.940 --> 01:42:53.000
sensitiven Stellen oder so angucken und die

01:42:53.000 --> 01:42:55.040
dann abarbeiten, aber

01:42:55.040 --> 01:42:56.880
das ist halt sozusagen der, äh,

01:42:56.880 --> 01:42:58.700
das, diesen, diesen Job, äh,

01:42:58.700 --> 01:43:00.960
in die Warteschlange tun und dieses, dieser, dieser

01:43:00.960 --> 01:43:03.020
menschliche Prozess mit menschlicher Interaktion

01:43:03.020 --> 01:43:05.020
das ist jetzt nicht mehr Teil von dem Web-Request

01:43:05.020 --> 01:43:06.620
das heißt

01:43:06.620 --> 01:43:09.020
der Teil muss irgendwie entkoppelt sein

01:43:09.020 --> 01:43:10.900
das heißt, der Web-Request

01:43:10.900 --> 01:43:11.640
ist ja irgendwie vorbei

01:43:11.640 --> 01:43:14.880
aber dieser Web-Request löst dann halt, äh,

01:43:14.880 --> 01:43:16.820
irgendwie, schreibt dann halt irgendwie diesen

01:43:16.820 --> 01:43:18.980
Job in die Queue, genau, solche Sachen

01:43:18.980 --> 01:43:20.960
hat man oft, auch wenn sich, äh, auch

01:43:20.960 --> 01:43:23.140
genau, ha, das ist ein gutes Beispiel

01:43:23.140 --> 01:43:24.960
das ist mir jetzt eingefallen

01:43:24.960 --> 01:43:27.000
äh, vielleicht möchtest du, dass

01:43:27.000 --> 01:43:29.000
wenn du jetzt in der Suche, äh,

01:43:29.000 --> 01:43:30.840
nach irgendwas suchst, dann

01:43:30.840 --> 01:43:33.180
Produkte 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.200 --> 01:43:37.100
das heißt, der Text, äh, deiner

01:43:37.100 --> 01:43:38.920
Bewertungen muss indiziert werden von der Suchmaschine

01:43:38.920 --> 01:43:41.080
äh, 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:47.000
weil, ja, und

01:43:47.000 --> 01:43:49.160
dann wird halt auch so ein Task erzeugt, äh,

01:43:49.160 --> 01:43:51.020
für, äh, so, das hier muss

01:43:51.020 --> 01:43:52.920
ja noch mitindiziert werden, aber es wird nicht sofort

01:43:52.920 --> 01:43:54.640
indiziert, weil das, ähm,

01:43:54.880 --> 01:43:56.880
ist halt etwas, was lange, eine Operation

01:43:56.880 --> 01:43:59.020
lange dauern kann und man möchte ja nicht, dass der

01:43:59.020 --> 01:44:01.040
äh, Web-Request dann

01:44:01.040 --> 01:44:02.540
so lange dauert, wie die Operation dauert, sondern

01:44:02.540 --> 01:44:04.540
man sagt, okay, man gibt dem Web-Request,

01:44:04.540 --> 01:44:06.980
es ist okay, dein Kommentar wurde gespeichert und hat dann aber noch

01:44:06.980 --> 01:44:08.900
diesen zusätzlichen Task erzeugt, der dann

01:44:08.900 --> 01:44:10.380
irgendwann später ausgeführt werden muss

01:44:10.380 --> 01:44:13.240
und dafür braucht man diese Task, Task-Queues

01:44:13.240 --> 01:44:14.940
die halt, wenn man ein komplexeres, äh,

01:44:14.940 --> 01:44:16.680
Web-System hat, dann braucht man sowas halt,

01:44:16.680 --> 01:44:18.400
weil solche Fälle halt immer wieder auftreten

01:44:18.400 --> 01:44:21.000
ja, äh, kann man

01:44:21.000 --> 01:44:22.860
aber Redis auch für verwenden, äh,

01:44:22.860 --> 01:44:24.700
also was für Django ist halt, was häufig

01:44:24.800 --> 01:44:26.740
verwendet ist, Salary, kann ich nicht unbedingt

01:44:26.740 --> 01:44:29.060
empfehlen, ist irgendwie eher schmerzhaft, ähm,

01:44:29.060 --> 01:44:31.060
ja, äh,

01:44:31.060 --> 01:44:32.620
die unter, drunter liegenden Geschichten

01:44:32.620 --> 01:44:34.680
sind oft sowas wie RabbitMQ oder so

01:44:34.680 --> 01:44:36.780
im Allgemeinen ist das Protokoll irgendwie AMQ

01:44:36.780 --> 01:44:38.880
psch, irgendwas, weiß nicht genau

01:44:38.880 --> 01:44:41.320
ja, aber das ist nochmal ein ganz eigenes, ähm,

01:44:41.320 --> 01:44:43.100
äh, Feld mit diesen ganzen Message-Queues

01:44:43.100 --> 01:44:44.320
ähm,

01:44:44.320 --> 01:44:47.460
ja, äh,

01:44:47.460 --> 01:44:48.220
genau

01:44:48.220 --> 01:44:50.900
Master-Slaves-Architektur

01:44:50.900 --> 01:44:52.420
hatten wir jetzt, äh, ja,

01:44:52.420 --> 01:44:54.300
genau, ähm, irgendwann

01:44:54.720 --> 01:44:56.920
kann natürlich auch sein, dass das nicht mehr, äh,

01:44:56.920 --> 01:44:59.120
dass das nicht mehr reicht

01:44:59.120 --> 01:45:01.660
und dann müssen wir halt, äh,

01:45:01.660 --> 01:45:03.140
irgendwie die Datenbank auftrennen

01:45:03.140 --> 01:45:04.840
also wenn zum Beispiel grad die, äh,

01:45:04.840 --> 01:45:06.920
das wird sich, das wird sich nach einem Böden

01:45:06.920 --> 01:45:08.860
die Schreiblast groß genug geworden ist

01:45:08.860 --> 01:45:10.560
dann, äh, geht das halt alles nicht mehr

01:45:10.560 --> 01:45:12.960
äh, und dann kann man halt

01:45:12.960 --> 01:45:14.960
äh, die Datenbank muss man dann auftrennen

01:45:14.960 --> 01:45:16.880
das ist furchtbar, weil dann verliert man eine ganze

01:45:16.880 --> 01:45:19.240
Menge der Vorteile, die man halt, äh,

01:45:19.240 --> 01:45:20.900
hat, wenn man eine Datenbank hat, eben referenzielle

01:45:20.900 --> 01:45:23.120
Integrität, äh, irgendwie, dass Transaktionen

01:45:23.120 --> 01:45:24.640
isoliert sind, diese ganzen Geschichten

01:45:24.640 --> 01:45:26.800
das geht alles nicht mehr so wirklich und das muss man dann alles

01:45:26.800 --> 01:45:28.720
in der Applikation machen, in der Applikationslogik

01:45:28.720 --> 01:45:30.840
und das macht alles Dinge unfassbar

01:45:30.840 --> 01:45:32.780
viel komplizierter, deswegen sollte man das möglichst nicht

01:45:32.780 --> 01:45:34.880
tun, ja, also, wenn man die mal verkauft, äh,

01:45:34.880 --> 01:45:35.920
irgendwie, ja, also,

01:45:35.920 --> 01:45:39.020
unser System ist super, weil das schadet

01:45:39.020 --> 01:45:40.800
automatisch oder sowas, also das ist nicht etwas, was

01:45:40.800 --> 01:45:42.700
man haben will, ja, also wenn das, wenn man

01:45:42.700 --> 01:45:43.960
klein genug ist, dass man das nicht braucht

01:45:43.960 --> 01:45:46.540
sollte man das nicht machen, weil das bedeutet halt, dass man

01:45:46.540 --> 01:45:48.600
diese ganzen Dinge, die einem sonst die Datenbank

01:45:48.600 --> 01:45:50.740
quasi schenkt, selber machen muss

01:45:50.740 --> 01:45:52.760
in den Applikationscode und das ist halt, äh,

01:45:52.760 --> 01:45:53.760
sehr, sehr schwierig

01:45:54.560 --> 01:45:56.360
äh, aber manchmal geht's halt leider nicht anders

01:45:56.360 --> 01:45:58.220
dann gibt's halt zwei Möglichkeiten, man schadet irgendwie

01:45:58.220 --> 01:46:00.520
äh, horizontal, also man sollte

01:46:00.520 --> 01:46:01.960
so lange, man nennt das Upscaling

01:46:01.960 --> 01:46:04.380
äh, so lange wie möglich die Maschine

01:46:04.380 --> 01:46:06.040
größer machen und mehr Hauptspeicher reinstecken

01:46:06.040 --> 01:46:08.360
äh, wenn das halt dann irgendwann tatsächlich nicht mehr geht

01:46:08.360 --> 01:46:10.200
dann, äh, muss man halt, äh,

01:46:10.200 --> 01:46:11.840
entweder horizontal oder vertikal

01:46:11.840 --> 01:46:14.580
schaden, äh, und das ist halt

01:46:14.580 --> 01:46:16.100
aufzahlen, das heißt, horizontal

01:46:16.100 --> 01:46:18.300
äh, man...

01:46:18.300 --> 01:46:19.740
Mehrere Maschinen, die die gleiche Datenbank benutzen?

01:46:19.740 --> 01:46:22.700
Nee, das, äh, äh, nee, die gleiche

01:46:22.700 --> 01:46:24.480
Datenbank würde einem ja nicht helfen, wenn es zu viele

01:46:24.480 --> 01:46:26.460
Ja. Ähm, dann muss

01:46:26.460 --> 01:46:28.460
die Daten, Datenbank halt irgendwo trennen

01:46:28.460 --> 01:46:29.840
und die Frage ist, wo trennt man jetzt auf?

01:46:29.840 --> 01:46:31.880
Man kann halt entweder... In Tabellen oder...

01:46:31.880 --> 01:46:34.140
Innerhalb von Tabellen die Zeilen auseinander trennen

01:46:34.140 --> 01:46:36.140
das wäre eben horizontal skalieren, dass man dann sagt

01:46:36.140 --> 01:46:38.440
okay, alle Bücher, die mit Buchstaben A anfangen

01:46:38.440 --> 01:46:40.740
kommen jetzt auf die Datenbank, alle Bücher mit Buchstaben

01:46:40.740 --> 01:46:42.740
B bis F kommen auf die Datenbank

01:46:42.740 --> 01:46:43.480
Mhm.

01:46:43.480 --> 01:46:46.620
Ähm... Oder so regional halt Queries trennen

01:46:46.620 --> 01:46:48.040
von wo kommt die denn jetzt oder sowas?

01:46:48.040 --> 01:46:49.720
Ja, regional kann man natürlich auch trennen

01:46:49.720 --> 01:46:52.520
äh, das ist dann nochmal, nochmal eine andere

01:46:52.520 --> 01:46:54.400
äh, wäre nochmal eine andere Geschichte, könnte man auch

01:46:54.400 --> 01:46:56.820
machen, das heißt aber, das wäre quasi horizontales

01:46:56.820 --> 01:46:58.140
Schaden auf den Usern

01:46:58.140 --> 01:47:00.160
Mhm. Ja, nach Region eben

01:47:00.160 --> 01:47:02.280
Äh, das wird, also, dass man

01:47:02.280 --> 01:47:04.240
also meistens würde man auf Usern

01:47:04.240 --> 01:47:05.640
schaden irgendwie tatsächlich, ja

01:47:05.640 --> 01:47:08.160
Man halt sagt, wo, was ist das für ein User

01:47:08.160 --> 01:47:10.300
und dann, ja, entweder regional

01:47:10.300 --> 01:47:11.480
oder halt irgendwie

01:47:11.480 --> 01:47:14.200
so sonst irgendein Hashwert

01:47:14.200 --> 01:47:15.700
oder so, ähm

01:47:15.700 --> 01:47:18.440
äh, und vertikal

01:47:18.440 --> 01:47:19.860
wäre halt, man trennt

01:47:19.860 --> 01:47:22.240
äh, nach Tabellen auf, das heißt

01:47:22.240 --> 01:47:24.320
man sagt, okay, wir haben hier ein System, das kümmert

01:47:24.320 --> 01:47:26.400
sich um die Bücher, wir haben ein System, das kümmert sich um die User

01:47:26.400 --> 01:47:28.120
wir haben ein System, das kümmert sich um

01:47:28.120 --> 01:47:30.140
Lagerhaltung, das, das wäre halt

01:47:30.140 --> 01:47:32.260
äh, man teilt dann nicht quasi in den Zeilen

01:47:32.260 --> 01:47:34.120
sondern man teilt halt an den

01:47:34.120 --> 01:47:35.220
Tabellengrenzen

01:47:35.220 --> 01:47:38.160
Mhm. Ähm... Ja, macht

01:47:38.160 --> 01:47:40.240
natürlich so vollständig, abfragen dann ein bisschen langsamer, oder so

01:47:40.240 --> 01:47:42.040
Ja, das Problem ist dann halt, dass man mehrere

01:47:42.040 --> 01:47:44.240
äh, Systeme fragen muss, wenn man jetzt

01:47:44.240 --> 01:47:46.140
irgendwie was machen, also wenn man jetzt die

01:47:46.140 --> 01:47:48.040
Amazon-Seite anzeigen möchte, dann

01:47:48.040 --> 01:47:50.460
äh, muss man halt unter Umständen

01:47:50.460 --> 01:47:51.340
viele Systeme fragen

01:47:51.340 --> 01:47:54.240
Tatsächlich ist es etwas, was Amazon wirklich

01:47:54.240 --> 01:47:56.140
passiert ist, irgendwie, ich glaube

01:47:56.140 --> 01:47:58.100
2008, 2009 gab es dann auch, äh,

01:47:58.100 --> 01:47:59.560
irgendwie haben sie Artikel darüber geschrieben

01:47:59.560 --> 01:48:02.180
äh, damals nannte sich

01:48:02.180 --> 01:48:04.060
das nicht, also heute läuft das Ganze unter dem Stichwort

01:48:04.060 --> 01:48:06.060
irgendwie, Microservices oder so

01:48:06.060 --> 01:48:08.080
nennt man das dann, dass man halt, äh

01:48:08.080 --> 01:48:09.740
äh, Teile eines Systems

01:48:09.740 --> 01:48:12.180
äh, in kleinere Services auslagert

01:48:12.180 --> 01:48:14.360
ähm,

01:48:14.360 --> 01:48:16.120
damals, äh, nannte sich das

01:48:16.120 --> 01:48:18.020
anders, war aber quasi eine gleiche Idee

01:48:18.020 --> 01:48:20.440
äh, nannte sich, äh, äh

01:48:20.440 --> 01:48:22.000
äh, Service-Oriented

01:48:22.000 --> 01:48:22.580
Architecture

01:48:24.160 --> 01:48:26.420
äh, und Amazon hatte das Problem, dass sie

01:48:26.420 --> 01:48:28.860
auf der Hauptseite, also wenn du einfach nur Amazon.com

01:48:28.860 --> 01:48:30.640
eingegeben hast, äh, dann

01:48:30.640 --> 01:48:32.880
wurde dir halt das Ding aus, die Seite ausgeliefert

01:48:32.880 --> 01:48:34.960
aber damals war es halt

01:48:34.960 --> 01:48:36.740
schon so, dass da so viel Zeugs

01:48:36.740 --> 01:48:38.960
drin war, also dann werden dir irgendwelche Empfehlungen angezeigt

01:48:38.960 --> 01:48:39.720
dann wird dir irgendwas

01:48:39.720 --> 01:48:42.580
angezeigt, wo wie viel Zeugs in deinem

01:48:42.580 --> 01:48:43.480
Warenkorb ist

01:48:43.480 --> 01:48:46.280
und das ist einem zwar nicht so bewusst, aber das ist wirklich

01:48:46.280 --> 01:48:48.220
viel Zeug bei Amazon und

01:48:48.220 --> 01:48:50.460
sie hatten das Problem, sie machen ungefähr 300

01:48:50.460 --> 01:48:52.560
SQL-Statements, wenn du

01:48:52.560 --> 01:48:54.080
äh, die Seite

01:48:54.080 --> 01:48:55.980
anguckst, oder so ein paar hundert, ja

01:48:55.980 --> 01:48:58.160
ähm, da das

01:48:58.160 --> 01:48:59.320
irgendwie, ähm

01:48:59.320 --> 01:49:02.160
da die irgendwie nur sequentiell ausgeführt

01:49:02.160 --> 01:49:04.160
wurden, äh, macht das halt die Latenz hoch, weil

01:49:04.160 --> 01:49:05.940
äh, ja, synchron

01:49:05.940 --> 01:49:08.000
äh, sequentiell, das heißt

01:49:08.000 --> 01:49:09.420
die ganzen Latenzen addieren sich auf

01:49:09.420 --> 01:49:11.660
das heißt, allein bis die ganzen

01:49:11.660 --> 01:49:13.960
äh, SQL-Statements abgearbeitet sind

01:49:13.960 --> 01:49:15.940
vergehen ein paar hundert Millisekunden, äh

01:49:15.940 --> 01:49:17.140
und die du einfach warten musst

01:49:17.140 --> 01:49:19.540
und das ist halt scheiße, ne, man weiß ungefähr so

01:49:19.540 --> 01:49:21.900
weiß ich, pro hundert Millisekunden droppt

01:49:21.900 --> 01:49:24.000
dein Conversion 10%

01:49:24.000 --> 01:49:25.680
oder so, ich weiß nicht, ne, wahrscheinlich weniger, aber

01:49:25.680 --> 01:49:28.840
also, ist halt nicht so gut

01:49:28.840 --> 01:49:30.160
das heißt, du kannst ja ausrechnen

01:49:30.160 --> 01:49:32.060
wie viel mehr Umsatz du machen würdest, wenn du das

01:49:32.060 --> 01:49:33.340
irgendwie schneller ausliefern könntest

01:49:33.340 --> 01:49:36.340
joa, äh, und dann haben sie

01:49:36.340 --> 01:49:38.040
halt gesagt, okay, das müssen wir irgendwie anders machen

01:49:38.040 --> 01:49:40.440
äh, dann haben sie das halt in Services

01:49:40.440 --> 01:49:41.920
aufgeteilt, dann haben sie gesagt, okay, wir haben hier den

01:49:41.920 --> 01:49:44.260
Recommendation-Service, wo dann die, wo sich die

01:49:44.260 --> 01:49:45.880
Webseite per JavaScript irgendwie

01:49:45.880 --> 01:49:48.200
macht irgendwie ein XHTTP-Request oder so und holt sich

01:49:48.200 --> 01:49:49.980
dann die Recommendations von diesem Service

01:49:49.980 --> 01:49:52.120
und dann haben wir den, äh, irgendwie

01:49:52.120 --> 01:49:53.840
keine Ahnung, Basket, äh,

01:49:53.840 --> 01:49:55.920
Service für deinen Einkaufs, äh,

01:49:55.920 --> 01:49:57.800
Korb oder so, äh,

01:49:57.800 --> 01:49:59.880
und da ist halt, das Ding holt sich halt, was

01:49:59.880 --> 01:50:01.720
für Dinge liegen da momentan grad drin und

01:50:01.720 --> 01:50:04.020
äh, ja, ähm

01:50:04.020 --> 01:50:05.760
genau, äh, und das

01:50:05.760 --> 01:50:07.920
das, äh, das haben die damals so

01:50:07.920 --> 01:50:09.920
gemacht, äh, ja, und dann

01:50:09.920 --> 01:50:11.880
das geht dann natürlich alles irgendwie mehr oder weniger

01:50:11.880 --> 01:50:13.280
auch nicht so total parallel, aber mehr

01:50:13.280 --> 01:50:15.920
paralleler als vorher und dann

01:50:15.920 --> 01:50:17.460
kann die Webseite insgesamt deutlich schneller sein

01:50:17.460 --> 01:50:19.980
ähm, ja

01:50:19.980 --> 01:50:22.100
genau, heute, heute würde man sagen, Microservices

01:50:22.100 --> 01:50:23.680
du hast halt ein Microservice pro

01:50:23.680 --> 01:50:25.700
irgendwie Ding, was du irgendwie da machst

01:50:25.700 --> 01:50:26.300
auf der Webseite

01:50:26.300 --> 01:50:29.740
und, äh, die komplette Seite

01:50:29.740 --> 01:50:31.840
aggregiert nur noch, äh, irgendwie die Daten aus all

01:50:31.840 --> 01:50:32.640
diesen Services

01:50:32.640 --> 01:50:35.880
äh, ja, das, damit kriegt man das

01:50:35.880 --> 01:50:37.620
tatsächlich in den Griff, wenn man so ein riesiges Ding hat

01:50:37.620 --> 01:50:39.760
und viele unterschiedliche Sachen und das nicht mehr in eine Datenbank passt

01:50:39.760 --> 01:50:42.040
dann kann man das so machen, das ist aber nicht so, dass man das machen sollte

01:50:42.040 --> 01:50:43.840
also solange das, solange man das anders

01:50:43.840 --> 01:50:45.840
machen kann, solange man das mit einer Datenbank

01:50:45.840 --> 01:50:47.860
hinkriegt, sollte man das mit einer Datenbank machen, weil das ist

01:50:47.860 --> 01:50:49.820
viel, viel angenehmer

01:50:49.820 --> 01:50:51.860
also, äh, Microservices

01:50:51.860 --> 01:50:53.520
sind halt dann, man schiebt dann halt einen Haufen

01:50:53.520 --> 01:50:55.660
der, äh, äh

01:50:55.660 --> 01:50:57.660
der, der, der Komplexität in eine andere

01:50:57.660 --> 01:50:59.780
Richtung, man hat dann plötzlich Architekturkomplexität

01:50:59.780 --> 01:51:02.080
man hat plötzlich, äh, äh

01:51:02.080 --> 01:51:03.500
ja, sozusagen im Ops

01:51:03.500 --> 01:51:05.740
äh, Teil von DevOps wird es plötzlich viel schwieriger

01:51:05.740 --> 01:51:07.720
man muss halt das alles irgendwie maintainen

01:51:07.720 --> 01:51:09.180
man muss halt plötzlich, wenn man jetzt sagt, okay, ich

01:51:09.180 --> 01:51:10.700
ähm

01:51:10.700 --> 01:51:13.520
äh, ich update jetzt diesen

01:51:13.520 --> 01:51:15.660
Service, äh, also dann hängen da halt andere Dinge von

01:51:15.660 --> 01:51:16.860
ab unter Umständen

01:51:16.860 --> 01:51:18.440
äh, dann

01:51:18.440 --> 01:51:21.480
hab ich halt, ich kann, ich kann

01:51:21.480 --> 01:51:23.360
ja, sagen wir mal so, wenn man das halt irgendwie so schön

01:51:23.360 --> 01:51:25.520
hat, Master-Slave-Architektur, Loadbalancer

01:51:25.520 --> 01:51:27.640
davor, vor den Datenbanken, ein paar Frontends

01:51:27.640 --> 01:51:29.400
dann, äh, selbst da

01:51:29.400 --> 01:51:31.320
ist es schon kompliziert, wenn ich jetzt, äh, irgendwie

01:51:31.320 --> 01:51:33.280
äh, äh, zum Beispiel ein Schema

01:51:33.280 --> 01:51:35.140
ändern möchte oder so, was ich im Produktivbetrieb

01:51:35.140 --> 01:51:37.240
dann vielleicht nicht mehr tun kann, weil die Datenbank viel zu langsam

01:51:37.240 --> 01:51:39.480
liefe, weil, wenn ich das Schema

01:51:39.480 --> 01:51:41.400
ändere, muss ich bei den Tabellen, die

01:51:41.400 --> 01:51:43.580
ich ändere, halt unter Umständen eine Kopie der Tabellen

01:51:43.580 --> 01:51:45.140
mehr oder weniger mache, das heißt, ich muss halt

01:51:45.140 --> 01:51:47.320
möglicherweise doppelt so viel Daten im Hauptspeicher halten, was

01:51:47.320 --> 01:51:49.440
halt vielleicht nicht geht, das heißt

01:51:49.440 --> 01:51:51.540
ich muss vielleicht sowas machen wie, ich tausche die Datenbank

01:51:51.540 --> 01:51:53.200
aus, ne, ich mach eine Kopie der Datenbank und

01:51:53.200 --> 01:51:55.020
äh, die Datenbank mit dem neuen Schema

01:51:55.020 --> 01:51:57.220
stell ich dann ins neue Master rein und so

01:51:57.220 --> 01:51:59.480
so oft hat man dann so Sachen wie, oder

01:51:59.480 --> 01:52:01.280
wenn man die Software updatet, man nimmt halt Sachen

01:52:01.280 --> 01:52:03.480
äh, ja

01:52:03.480 --> 01:52:05.380
Rechner aus der, aus der Verteilung im Loadbalancer

01:52:05.380 --> 01:52:07.500
updatet den, oder die Hälfte

01:52:07.500 --> 01:52:09.540
davon, und äh

01:52:09.540 --> 01:52:11.400
äh, die andere Hälfte läuft noch auf der alten Software

01:52:11.400 --> 01:52:13.580
und dann schaltet man halt um, oder so

01:52:13.580 --> 01:52:15.400
ne, solche Sachen kann man machen, und das ist

01:52:15.400 --> 01:52:17.260
das geht noch, das ist auch dann schon kompliziert, weil

01:52:17.260 --> 01:52:19.060
man muss sich dann halt, äh, Gedanken machen

01:52:19.060 --> 01:52:20.140
wie man das tut

01:52:20.140 --> 01:52:22.980
und man muss halt irgendein System haben, das unterstützt,

01:52:23.040 --> 01:52:24.740
dass man das automatisch machen kann, sodass man halt

01:52:24.740 --> 01:52:26.880
nicht jedes Mal, wenn man irgendwie

01:52:26.880 --> 01:52:28.960
sowas wie eine Schemaänderung macht, oder wenn man halt

01:52:28.960 --> 01:52:29.640
äh, irgendwie eine

01:52:29.640 --> 01:52:32.780
komplexere Änderung im Applikationscode

01:52:32.780 --> 01:52:34.600
in den Frontends hat, dass man da halt dann irgendwie

01:52:34.600 --> 01:52:36.740
jemand setzen muss und das dann von Hand macht, das sollte nicht so sein

01:52:36.740 --> 01:52:38.640
sondern man sollte dann auf den Knopf drücken und sagen, okay

01:52:38.640 --> 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:42.260 --> 01:52:44.780
wenn man Microservices hat, wird das

01:52:44.780 --> 01:52:46.720
Ganze viel schlimmer, das ist halt da nicht so

01:52:46.720 --> 01:52:48.760
dann, dann hat man eine viel komplexere Abhängigkeit

01:52:48.760 --> 01:52:50.720
zwischen den Geschichten, und dann wird dieses ganze

01:52:50.720 --> 01:52:52.880
Ops-Thema halt, äh, richtig, richtig

01:52:52.880 --> 01:52:54.600
ätzend, ähm, auch

01:52:54.600 --> 01:52:56.180
Skalierung wird richtig ätzend, weil

01:52:56.180 --> 01:52:58.720
dann willst du halt, wenn du halt, ja, so

01:52:58.720 --> 01:53:00.300
in so einer klassischen Architektur hast du nur

01:53:00.300 --> 01:53:02.480
wenige unterschiedliche Arten von

01:53:02.480 --> 01:53:04.120
äh, ähm

01:53:04.120 --> 01:53:06.860
Maschinen, die halt irgendwas machen, du hast halt Datenbanken, du hast halt

01:53:06.860 --> 01:53:08.680
irgendwie Redis oder sowas

01:53:08.680 --> 01:53:10.820
äh, du hast halt Frontends, äh, vielleicht

01:53:10.820 --> 01:53:12.860
doch vorne irgendwie, äh

01:53:12.860 --> 01:53:14.440
äh, Webserver, die SSL

01:53:14.440 --> 01:53:16.700
äh, ähm, Terminierung machen

01:53:16.700 --> 01:53:18.680
oder so, aber, aber das war's im Grunde, also du hast nicht so

01:53:18.680 --> 01:53:20.680
wahnsinnig viele unterschiedliche Dinge, beim Microservice

01:53:20.680 --> 01:53:22.720
hast du halt, ja, vielleicht

01:53:22.720 --> 01:53:24.620
hundert unterschiedliche Arten von Microservices, die du

01:53:24.620 --> 01:53:26.620
unterschiedlich skalieren musst, wo du auch unterschiedliche Sachen

01:53:26.620 --> 01:53:28.180
aufpassen musst, das ist alles furchtbar, also

01:53:28.180 --> 01:53:30.540
geht, also man kriegt damit halt Sachen

01:53:30.540 --> 01:53:32.440
in den Griff, die, äh, dann halt, wenn man

01:53:32.440 --> 01:53:34.680
mit, äh, diesem Muster, man hat halt

01:53:34.680 --> 01:53:36.280
eine Datenbank, in der die Wahrheit drinsteht, nicht mehr

01:53:36.280 --> 01:53:38.740
äh, wenn das nicht mehr ausreicht, kann man

01:53:38.740 --> 01:53:40.540
das dann halt so in den Griff kriegen, aber es ist halt

01:53:40.540 --> 01:53:42.000
dann schon schlimm, ja

01:53:42.000 --> 01:53:43.560
äh, genau

01:53:43.560 --> 01:53:46.320
ähm, okay, sind wir schon ganz

01:53:46.320 --> 01:53:48.180
groß, das heißt, wir müssen noch ziemlich viel, äh,

01:53:48.180 --> 01:53:50.460
Bachtes haben, okay, genau

01:53:50.460 --> 01:53:52.560
oh, das hab ich, äh, ja, was haben wir denn

01:53:52.560 --> 01:53:54.740
äh

01:53:54.740 --> 01:53:55.960
ja

01:53:55.960 --> 01:53:57.920
ähm

01:53:57.920 --> 01:54:00.400
ich guck gerade in die Liste, was wir jetzt noch

01:54:00.400 --> 01:54:02.320
alles haben und was noch nicht, genau

01:54:02.320 --> 01:54:04.420
äh

01:54:04.420 --> 01:54:06.700
das ist nämlich tatsächlich relativ viel, ja, ja, ja

01:54:06.700 --> 01:54:08.380
oh mein Gott, ich weiß nicht, wie lange

01:54:08.380 --> 01:54:10.540
wie lange sind wir denn schon dran, ich glaube, wir sind über zwei Stunden

01:54:10.540 --> 01:54:12.360
schon, oder, oder nicht ganz, nein, noch nicht ganz, na gut

01:54:12.360 --> 01:54:14.440
dann, das ist harmlos, naja

01:54:14.440 --> 01:54:16.540
achso, genau

01:54:16.540 --> 01:54:18.160
was ich hier noch, ein Punkt war, es können auch

01:54:18.160 --> 01:54:20.120
im Analyse-System auch Sachen wieder

01:54:20.120 --> 01:54:22.400
zurücklaufen, äh, zum Beispiel gibt es halt diverse

01:54:22.400 --> 01:54:24.280
Sachen, die gelockt werden, die dann aber trotzdem für die

01:54:24.280 --> 01:54:25.480
Transaktionen wieder eine Rolle spielen

01:54:25.480 --> 01:54:28.180
äh, wie so etwas, das hatten wir noch gar nicht

01:54:28.180 --> 01:54:30.420
ist auch, äh, die Suche, ja, am Anfang

01:54:30.420 --> 01:54:32.200
äh, man braucht ja auf jeden Fall, wenn man irgendwie so

01:54:32.200 --> 01:54:34.200
eine E-Commerce-Seite hat, irgendwie eine, eine Suchmaschine

01:54:34.200 --> 01:54:35.700
wo man irgendwie nach Büchern suchen kann, oder so

01:54:35.700 --> 01:54:38.520
äh, das geht

01:54:38.520 --> 01:54:40.500
auch tatsächlich mit Postgres direkt, voll gut

01:54:40.500 --> 01:54:42.380
äh, hat eine integrierte, äh

01:54:42.380 --> 01:54:44.220
integrierten Volltext-Index, ähm, ja

01:54:44.220 --> 01:54:46.340
ja, und

01:54:46.340 --> 01:54:48.340
äh, man möchte halt auch so eine Facetten-Navigation

01:54:48.340 --> 01:54:50.280
nennt man das, haben, wo man, wenn man jetzt

01:54:50.280 --> 01:54:51.060
nach irgendwas gesucht hat,

01:54:52.240 --> 01:54:54.320
hat halt eine Ergebnisliste, dann möchte man einschränken

01:54:54.320 --> 01:54:56.200
nach Kategorien, oder nach, weiß ich jetzt, wenn

01:54:56.200 --> 01:54:57.400
wenn es nicht um Bücher geht, sondern um

01:54:57.400 --> 01:55:00.220
Elektronik oder so, kann man vielleicht noch Hauptspeicher

01:55:00.220 --> 01:55:01.520
oder, äh,

01:55:01.520 --> 01:55:04.660
VHS

01:55:04.660 --> 01:55:06.240
oder Betamax, ja, so möchte man vielleicht

01:55:06.240 --> 01:55:06.800
auswählen können

01:55:06.800 --> 01:55:10.160
und, äh, genau

01:55:10.160 --> 01:55:12.320
ähm, das geht mit Postgres

01:55:12.320 --> 01:55:14.200
alles sehr schön, auch da kann man

01:55:14.200 --> 01:55:16.200
äh, äh, irgendwie

01:55:16.200 --> 01:55:18.080
die Counts für die Facetten ganz gut rauskriegen

01:55:18.080 --> 01:55:19.580
ansonsten, wenn man das halt über eine eigene

01:55:19.580 --> 01:55:21.720
äh, äh, ja,

01:55:22.080 --> 01:55:24.320
Spezial-Datenbank sowas wie, äh, Elasticsearch

01:55:24.320 --> 01:55:25.940
macht oder Lucille, äh, äh,

01:55:25.940 --> 01:55:28.260
beides Lucille-basiert oder, oder Solar oder so

01:55:28.260 --> 01:55:30.300
macht, dann hat man das Problem, da hat man auch wieder dieses

01:55:30.300 --> 01:55:32.240
wie bei ETL, das Synchronisationsproblem, du hast halt

01:55:32.240 --> 01:55:34.220
wenn sich an der Datenbank was ändert, müssen die Änderungen in den

01:55:34.220 --> 01:55:36.320
Index rein, da hast du

01:55:36.320 --> 01:55:38.180
eine Latenz dazwischen, äh,

01:55:38.180 --> 01:55:40.060
wenn du Sachen aus dem Index rausholst, ja,

01:55:40.060 --> 01:55:42.300
du, äh, suchen, hast jetzt eine Volltext-Suchanfrage

01:55:42.300 --> 01:55:44.420
und kriegst jetzt IDs aus der

01:55:44.420 --> 01:55:46.000
Suchmaschine, dann

01:55:46.000 --> 01:55:48.200
möchtest du aber vielleicht nach was filtern, was nur in der

01:55:48.200 --> 01:55:50.440
Datenbank drinsteht, dann musst du nochmal auf die Datenbank

01:55:50.440 --> 01:55:51.920
äh, da alle Daten raus,

01:55:51.920 --> 01:55:54.080
äh, ziehen und dann nochmal Counts anders

01:55:54.080 --> 01:55:56.020
ausrechnen, ja, vielleicht ein paar der Facetten-Counts

01:55:56.020 --> 01:55:58.040
kommen aus der Suchmaschine, ein paar kommen aber aus der

01:55:58.040 --> 01:56:00.200
Datenbank, das heißt, du hast nicht nur einen Roundtrip

01:56:00.200 --> 01:56:02.320
über die Suchmaschine, du hast auch noch einen Roundtrip über die Datenbank,

01:56:02.320 --> 01:56:04.260
wo du halt irgendwie select, äh,

01:56:04.260 --> 01:56:06.120
irgendwie diverse Sachen vom Datenbank,

01:56:06.120 --> 01:56:08.180
äh, where und dann kommt halt ID in

01:56:08.180 --> 01:56:09.580
und dann kommen tausend IDs und so,

01:56:09.580 --> 01:56:12.100
äh, das ist alles

01:56:12.100 --> 01:56:14.040
kompliziert, wenn das halt ein Statement

01:56:14.040 --> 01:56:15.800
ist, was du halt abfeuerst oder halt

01:56:15.800 --> 01:56:18.000
vielleicht eins für die Daten selber

01:56:18.000 --> 01:56:20.280
und eins für die Counts oder so, ähm,

01:56:20.280 --> 01:56:21.760
dann ist das halt deutlich

01:56:21.760 --> 01:56:23.720
ist alles irgendwie viel einfacher

01:56:23.720 --> 01:56:26.140
und, äh, mit Postgres kriegt man auch das am Anfang

01:56:26.140 --> 01:56:27.660
äh, alles hin und, ähm,

01:56:27.660 --> 01:56:30.160
ja, das ist eigentlich, äh, eigentlich sehr nett

01:56:30.160 --> 01:56:32.120
äh, irgendwann geht das aber wahrscheinlich dann halt

01:56:32.120 --> 01:56:33.840
eben auch nicht mehr, dann muss man halt nach und nach

01:56:33.840 --> 01:56:35.940
Funktionen in Spezial, äh,

01:56:35.940 --> 01:56:38.000
Services halt auslagern, ne, eine der ersten, die man

01:56:38.000 --> 01:56:39.800
wahrscheinlich auslagern wird, ist halt Volltext-Suche

01:56:39.800 --> 01:56:41.780
möglicherweise, das macht dann halt irgendwann

01:56:41.780 --> 01:56:43.300
ein Listing-Search oder, oder

01:56:43.300 --> 01:56:45.840
Solar oder so, äh,

01:56:45.840 --> 01:56:47.780
aber halt auch, ähm, eben

01:56:47.780 --> 01:56:49.560
sowas wie, wenn man jetzt

01:56:49.560 --> 01:56:51.600
anfängt eine Query zu schreiben

01:56:51.600 --> 01:56:53.540
äh, kennt man eben

01:56:53.540 --> 01:56:55.740
Google Suggest, hatte ich eben schon erwähnt, äh

01:56:55.740 --> 01:56:57.360
ähm, kriegt man halt so Vorschläge

01:56:57.360 --> 01:56:59.600
das, das ist im Grunde, man

01:56:59.600 --> 01:57:01.740
macht dann halt, äh, man sucht auf den, auf den

01:57:01.740 --> 01:57:03.680
Query, Queries von anderen

01:57:03.680 --> 01:57:05.500
Leuten, äh, aber dann hat man halt genau das

01:57:05.500 --> 01:57:07.320
Problem, dass halt sozusagen

01:57:07.320 --> 01:57:09.540
die History der Queries muss halt

01:57:09.540 --> 01:57:11.120
irgendwie aus dem Analyse-Ding wieder zurück ins

01:57:11.120 --> 01:57:13.580
OLTP-System oder in irgendeinen anderen Service, der

01:57:13.580 --> 01:57:15.700
äh, auf dem man dann per Suffix-Tree

01:57:15.700 --> 01:57:16.580
irgendwie nach

01:57:16.580 --> 01:57:19.320
Queries, die

01:57:19.320 --> 01:57:21.440
möglichst ähnlich sind zu den

01:57:21.440 --> 01:57:23.500
drei Buchstaben, die man jetzt schon eingegeben hat oder so

01:57:23.500 --> 01:57:25.000
äh, äh, raussuchen

01:57:25.000 --> 01:57:27.440
Ja, natürlich, wenn man tippen kann, drei, vier, fünf

01:57:27.440 --> 01:57:29.360
Ja, ja, ja, und, äh, also man kann das am Anfang

01:57:29.360 --> 01:57:31.520
äh, auch alles über Postgres machen, wenn's dann halt komplizierter

01:57:31.520 --> 01:57:33.320
wird, muss man das als ein eigenes Service auslagern

01:57:33.320 --> 01:57:35.420
und so weiter und so, dann wird's halt alles, dann wird

01:57:35.420 --> 01:57:37.000
das System größer und schwieriger und

01:57:37.000 --> 01:57:39.480
ja, äh, genau

01:57:39.480 --> 01:57:41.180
und, ähm, ja

01:57:41.180 --> 01:57:43.380
und immer die Datenbanken, die man nimmt

01:57:43.380 --> 01:57:45.480
werden halt immer spezialisiert, also das würde ich auch empfehlen

01:57:45.480 --> 01:57:47.040
also man fängt halt mit Postgres an, macht

01:57:47.040 --> 01:57:49.540
mit Postgres einfach alles und wenn man dann halt

01:57:49.540 --> 01:57:51.280
irgendwann an Grenzen stößt, dann muss man halt, äh

01:57:51.280 --> 01:57:52.240
äh, ja

01:57:52.240 --> 01:57:55.720
wo du dir übel, äh, dann Sachen in halt Spezialdatenbanken

01:57:55.720 --> 01:57:56.840
auslagern, wo du

01:57:56.840 --> 01:57:58.500
äh, und, äh, ja

01:57:58.500 --> 01:58:01.640
äh, bezahlt dann halt mit Komplexität

01:58:01.640 --> 01:58:02.660
ähm

01:58:02.660 --> 01:58:05.700
genau, äh

01:58:05.700 --> 01:58:07.560
Ja, jetzt müssen wir nochmal, wie wir das weitermachen

01:58:07.560 --> 01:58:09.580
genau, wir nehmen, wir nehmen Redis

01:58:09.580 --> 01:58:10.720
zum Cachen, einfach

01:58:10.720 --> 01:58:13.440
äh, von, von langlaufenden Queries und von

01:58:13.440 --> 01:58:15.480
irgendwie gerenderten Fragmenten, die halt aufwendig

01:58:15.480 --> 01:58:17.240
zu rendern sind, äh, also irgendwelche Listen von

01:58:17.240 --> 01:58:19.360
von Dingen oder so, die sich aber jetzt nicht

01:58:19.360 --> 01:58:20.820
äh, dauernd ändern

01:58:20.820 --> 01:58:21.120
äh

01:58:21.120 --> 01:58:22.840
ähm

01:58:22.840 --> 01:58:24.180
und

01:58:24.180 --> 01:58:27.040
genau, ähm

01:58:27.040 --> 01:58:30.460
Ja, die Daten werden noch immer

01:58:30.460 --> 01:58:32.360
größer und das Problem ist auch, wir sind mittlerweile weltweit

01:58:32.360 --> 01:58:34.420
unterwegs, äh, wir verkaufen

01:58:34.420 --> 01:58:35.280
nicht nur Bücher, wir verkaufen

01:58:35.280 --> 01:58:38.060
alles von A bis Z

01:58:38.060 --> 01:58:40.160
die Amazon, das habt ihr ja schon gesehen, habt ihr

01:58:40.160 --> 01:58:41.700
den Pfeil von A bis Z

01:58:41.700 --> 01:58:44.480
Amazon und, ähm

01:58:44.480 --> 01:58:46.380
ja

01:58:46.380 --> 01:58:48.480
äh, dann stellt sich ja die Frage, wenn

01:58:48.480 --> 01:58:50.560
wir das global machen, wo stellen wir dann die Maßnahmen eigentlich hin?

01:58:50.660 --> 01:58:51.560
Das ist halt auch schwierig

01:58:51.560 --> 01:58:53.820
ja, äh

01:58:53.820 --> 01:58:56.140
Wo wird der entstehen? Also in einem sicheren Land?

01:58:56.140 --> 01:58:56.980
Ja

01:58:56.980 --> 01:59:00.800
Wir müssen an alle Stellen irgendwie so einen kleinen

01:59:00.800 --> 01:59:02.680
Master stellen, wo halt viel, äh, Traffic ist

01:59:02.680 --> 01:59:04.720
Kann man den Master mirern, dass man dann tatsächlich

01:59:04.720 --> 01:59:05.920
sagt, dass überall derselbe, äh

01:59:05.920 --> 01:59:08.760
Ja, es gibt natürlich auch irgendwie für diese, diese Geschichten so Lösungen, dass man halt

01:59:08.760 --> 01:59:10.600
dass die Master sich miteinander synchronisieren

01:59:10.600 --> 01:59:12.660
das gibt's für Postgres auch, aber das ist alles irgendwie

01:59:12.660 --> 01:59:13.780
ich weiß nicht so genau

01:59:13.780 --> 01:59:16.500
alles nicht so richtig, das funktioniert alles nicht so richtig

01:59:16.500 --> 01:59:18.700
und, äh, ja

01:59:18.700 --> 01:59:20.500
da gibt's, es gibt auf jeden Fall keine nette

01:59:20.500 --> 01:59:22.260
äh, äh, das ist halt auch ein

01:59:22.260 --> 01:59:24.100
mehr oder weniger unlösbares Problem, also

01:59:24.100 --> 01:59:26.440
äh, das ist auch theoretisch quasi nicht wirklich in den Griff

01:59:26.440 --> 01:59:28.360
zu kriegen. Man kann aber

01:59:28.360 --> 01:59:30.480
ähm, Dinge tun, indem man halt auf andere

01:59:30.480 --> 01:59:32.080
Architekturen umstellt, man kann halt

01:59:32.080 --> 01:59:34.580
äh, ja, also

01:59:34.580 --> 01:59:36.300
ich hab jetzt mal hier als Beispiel genommen

01:59:36.300 --> 01:59:38.400
diese, du willst halt, dass

01:59:38.400 --> 01:59:39.760
manche Sachen immer funktionieren

01:59:39.760 --> 01:59:42.360
Ja, eigentlich sollte immer

01:59:42.360 --> 01:59:43.820
alle Sachen, möglichen Sachen funktionieren, ja

01:59:43.820 --> 01:59:46.180
und manchmal ist dir dann halt irgendwie

01:59:46.180 --> 01:59:48.240
die Konsistenz und so egal, ja, also

01:59:48.240 --> 01:59:50.340
äh, zum Beispiel für Amazon super wichtig, äh

01:59:50.340 --> 01:59:52.160
äh, ist halt der Einkaufswagen, ja

01:59:52.160 --> 01:59:53.880
du musst halt immer weiter, das Preis muss fließen

01:59:53.880 --> 01:59:55.540
jetzt musst du immer weiter einkaufen können

01:59:55.540 --> 01:59:58.180
äh, auch wenn jetzt, äh, daher haben

01:59:58.180 --> 01:59:59.280
sie das halt, ich glaub das war auch

01:59:59.280 --> 02:00:01.800
Amazon Dynamo basiert

02:00:01.800 --> 02:00:03.480
auf einem System, das sie für sich selbst

02:00:03.480 --> 02:00:05.220
gebaut haben, eben für genau diesen

02:00:05.220 --> 02:00:07.620
Shopping Basket und

02:00:07.620 --> 02:00:09.540
der halt genau darauf ausgelegt ist, dass dieses Ding

02:00:09.540 --> 02:00:11.560
halt einfach immer funktioniert. Und das ist

02:00:11.560 --> 02:00:13.180
mehr oder weniger einfach nur so ein total simpler

02:00:13.180 --> 02:00:13.940
Key-Value-Store

02:00:13.940 --> 02:00:17.520
und du lebst halt dann damit, dass

02:00:17.520 --> 02:00:19.460
das nicht konsistent ist. Oder dass

02:00:19.460 --> 02:00:21.500
halt, wenn du was kaufst,

02:00:21.500 --> 02:00:23.360
das halt vielleicht nicht mehr im Lager ist. Das kann dann

02:00:23.360 --> 02:00:25.440
durchaus passieren, weil dieses Ding ist halt ein eigener Service,

02:00:25.440 --> 02:00:26.940
das hat keine Verbindung

02:00:26.940 --> 02:00:29.000
zu einer zentralen, das hat schon keine Verbindung,

02:00:29.140 --> 02:00:31.360
aber es kann halt nicht den echten Status

02:00:31.360 --> 02:00:33.320
abfragen, weil wo ist der? Das ist halt schwer zu sagen.

02:00:33.320 --> 02:00:35.300
Und

02:00:35.300 --> 02:00:37.240
das, was Amazon dann macht, tatsächlich,

02:00:37.240 --> 02:00:38.380
habe ich auch gehört, dass

02:00:38.380 --> 02:00:40.960
solche Sachen können dann ja auftreten. Du kaufst ein Buch,

02:00:40.960 --> 02:00:41.780
das ist nicht mehr

02:00:41.780 --> 02:00:45.040
lieferbar. Und jetzt?

02:00:45.040 --> 02:00:47.180
Also das heißt, es fällt erst so fünf Minuten später

02:00:47.180 --> 02:00:48.240
bei Amazon auf.

02:00:48.240 --> 02:00:51.220
Geht nicht. Wir haben jetzt zwar, hat jemand

02:00:51.220 --> 02:00:52.960
was bestellt, wir haben die Bestellung zugesagt, du hast

02:00:52.960 --> 02:00:54.940
eine Bestätigungs-Mail bekommen irgendwie

02:00:54.940 --> 02:00:57.180
und jetzt fällt aber auf so, fuck, im Lager ist

02:00:57.180 --> 02:00:59.000
das nicht mehr drin. Wir können es

02:00:59.000 --> 02:01:00.720
dir nicht schicken. Was macht Amazon dann?

02:01:00.720 --> 02:01:02.880
Ja, also höchstens entweder nachordern

02:01:02.880 --> 02:01:04.760
von irgendeinem Service, wie wir eben das Problem hatten,

02:01:04.760 --> 02:01:06.000
oder die sagen dann irgendwann so,

02:01:06.000 --> 02:01:08.740
wir schicken dir einen Gutschein raus,

02:01:08.740 --> 02:01:10.580
irgendwas gibt es nicht.

02:01:10.580 --> 02:01:12.620
Genau, es kommt eine Entschuldigungs-Mail und sie geben dir

02:01:12.620 --> 02:01:14.720
einen Gutschein. Da das nicht so

02:01:14.720 --> 02:01:16.220
super häufig passiert, ist das halt nicht schlimm.

02:01:16.220 --> 02:01:18.460
Das ist halt viel einfacher,

02:01:18.460 --> 02:01:20.880
das über Gutschein zu lösen,

02:01:20.880 --> 02:01:23.180
als über ein Datenbanksystem,

02:01:23.180 --> 02:01:24.520
was das irgendwie handeln kann, weil das gibt es

02:01:24.520 --> 02:01:25.220
eben einfach nicht.

02:01:25.220 --> 02:01:27.480
Und ja,

02:01:28.860 --> 02:01:30.420
einfach kurz den 3D-Drucker anschmeißen,

02:01:30.420 --> 02:01:31.300
wird schnell nachproduziert.

02:01:31.300 --> 02:01:35.960
Ja, genau, das ist halt

02:01:35.960 --> 02:01:38.220
das auch, was dann halt gebrochen wird

02:01:38.220 --> 02:01:40.140
in relationalen Datenbanknehmern, das ist oft

02:01:40.140 --> 02:01:41.480
Asset, also

02:01:41.480 --> 02:01:44.120
Atomicity, Consistency,

02:01:44.120 --> 02:01:45.600
Isolation und Durability.

02:01:45.600 --> 02:01:48.540
Atomicity ist

02:01:48.540 --> 02:01:50.120
eigentlich quasi das, was Transaktionen betrifft,

02:01:50.120 --> 02:01:52.080
dass halt entweder alles gut geht oder

02:01:52.080 --> 02:01:54.540
alles

02:01:54.540 --> 02:01:56.740
fehlschlägt, aber nicht irgendwie Teile einer Transaktion

02:01:56.740 --> 02:01:58.600
oder Teile von einer Menge von Dingen,

02:01:58.720 --> 02:02:00.400
die man tun will, halt gehen und dann

02:02:00.400 --> 02:02:02.120
mancher Sachen nicht gehen, das sollte halt nicht passieren.

02:02:02.120 --> 02:02:04.200
Consistency heißt halt,

02:02:04.200 --> 02:02:05.420
dass

02:02:05.420 --> 02:02:08.280
die ganzen Foreign Key,

02:02:08.280 --> 02:02:10.620
dass halt die referenzielle Integrität halt gewahrt

02:02:10.620 --> 02:02:12.580
bleibt, dass da Sachen nicht zerbrechen, was halt

02:02:12.580 --> 02:02:14.600
dann auch nicht mehr geht, wenn du Sachen über mehrere Datenbanken verteilst,

02:02:14.600 --> 02:02:16.660
weil dann hast du halt teilweise

02:02:16.660 --> 02:02:18.620
eben keine direkten Verbindungen, sondern du hast halt bloß

02:02:18.620 --> 02:02:19.580
wie APIs dazwischen.

02:02:19.580 --> 02:02:22.740
Isolation

02:02:22.740 --> 02:02:24.060
ist halt die Geschichte, dass du

02:02:24.060 --> 02:02:25.520
nicht

02:02:25.520 --> 02:02:28.300
Sachen, die andere Transaktionen machen,

02:02:28.580 --> 02:02:30.600
in deinen Daten siehst, also das ist halt, man nennt das

02:02:30.600 --> 02:02:32.200
Dirty Read, wenn du halt

02:02:32.200 --> 02:02:34.700
in deiner Transaktion Dinge

02:02:34.700 --> 02:02:36.700
aus anderen Transaktionen siehst, die noch nicht abgeschlossen sind,

02:02:36.700 --> 02:02:38.660
sodass du halt, dass du immer,

02:02:38.660 --> 02:02:40.600
dass deine Sicht auf die Daten

02:02:40.600 --> 02:02:42.460
mal komplett isoliert ist. Es gibt unterschiedliche

02:02:42.460 --> 02:02:43.260
Isolationslevel.

02:02:43.260 --> 02:02:46.160
Postgres hat per Default den

02:02:46.160 --> 02:02:47.680
höchsten, glaube ich,

02:02:47.680 --> 02:02:50.440
Serializable ist der höchste, dann gibt es noch

02:02:50.440 --> 02:02:51.160
Repeatable Read.

02:02:51.160 --> 02:02:54.420
Repeatable Read war

02:02:54.420 --> 02:02:56.040
lange, war es glaube ich lange, aber

02:02:56.040 --> 02:02:57.240
mittlerweile ist es Serializable.

02:02:58.440 --> 02:02:59.920
Kann man auch nachgucken, was das bedeutet.

02:02:59.920 --> 02:03:01.960
Es gibt da feine Unterschiede.

02:03:01.960 --> 02:03:03.840
Und

02:03:03.840 --> 02:03:06.420
genau,

02:03:06.420 --> 02:03:08.320
Isolation und Durability ist halt

02:03:08.320 --> 02:03:10.140
einfach nur das, wenn eine Transaktion

02:03:10.140 --> 02:03:12.200
gesagt hat, okay, ich bin durchgeführt, dass dann halt

02:03:12.200 --> 02:03:13.440
auch nichts mehr schief gehen kann.

02:03:13.440 --> 02:03:16.120
Was extrem

02:03:16.120 --> 02:03:17.220
schwierig ist zu implementieren.

02:03:17.220 --> 02:03:19.560
Strom aus.

02:03:19.560 --> 02:03:22.140
Genau, Strom aus muss trotzdem, wenn

02:03:22.140 --> 02:03:24.120
die Datenbank wieder hochkommt, alles

02:03:24.120 --> 02:03:25.440
im richtigen Zustand sein.

02:03:25.440 --> 02:03:27.680
Aber das kann man ja oft dann nicht so wirklich

02:03:27.680 --> 02:03:28.420
gewährleisten.

02:03:28.420 --> 02:03:30.060
Also man kann ja nicht, das ist halt

02:03:30.060 --> 02:03:33.080
Der Hauptspeicher ist ja flüchtig und nicht

02:03:33.080 --> 02:03:35.240
Der Hauptspeicher ist flüchtig, das heißt, man darf es nicht in den Hauptspeicher

02:03:35.240 --> 02:03:37.240
einfach nur schreiben, sondern die Transaktion darf

02:03:37.240 --> 02:03:38.680
erst als dann durchgegangen

02:03:38.680 --> 02:03:43.200
zurück,

02:03:43.200 --> 02:03:45.260
ist durchgegangen, wird zurückgegeben,

02:03:45.260 --> 02:03:47.360
wenn das im Ride-Ahead-Log gelandet

02:03:47.360 --> 02:03:48.980
ist und das mit F-Sync

02:03:48.980 --> 02:03:50.660
irgendwie auf die Platte geschrieben ist.

02:03:50.660 --> 02:03:53.160
Ja, und

02:03:53.160 --> 02:03:54.620
F-Sync ist halt teurer,

02:03:54.620 --> 02:03:56.200
teurer Syscall,

02:03:56.200 --> 02:03:58.280
das macht das sehr langsam,

02:03:58.280 --> 02:04:00.300
auch diese Isolation

02:04:00.300 --> 02:04:02.220
macht es halt langsam, aber das sind auch

02:04:02.220 --> 02:04:04.020
alle Sachen, die man halt weiter runterfahren kann.

02:04:04.020 --> 02:04:05.120
Du kannst halt zum Beispiel auch,

02:04:05.120 --> 02:04:08.300
das machen Leute halt

02:04:08.300 --> 02:04:10.260
auch für Postgres zum Beispiel,

02:04:10.260 --> 02:04:12.240
du kannst unterschiedlichen Usern

02:04:12.240 --> 02:04:14.180
unterschiedliche Isolationslevel geben, und dann kannst du

02:04:14.180 --> 02:04:15.920
sagen, wenn jemand Analyse-Querries macht,

02:04:15.920 --> 02:04:18.200
oder bestimmte Arten von Queries,

02:04:18.200 --> 02:04:19.480
bei denen es völlig egal ist, ob die

02:04:19.480 --> 02:04:21.880
super isoliert sind oder nicht, dann kannst du sagen,

02:04:21.880 --> 02:04:24.160
dieser User hat halt

02:04:24.160 --> 02:04:25.440
ein viel niedrigeres Isolationslevel,

02:04:25.440 --> 02:04:27.380
der macht dann halt Dirt-Reads, aber das ist halt

02:04:27.380 --> 02:04:28.220
egal für dessen.

02:04:28.280 --> 02:04:30.780
So kann man Sachen deutlich beschleunigen.

02:04:30.780 --> 02:04:34.020
Dann, was man auch machen kann,

02:04:34.020 --> 02:04:35.560
das sollte man halt jetzt nicht tun, wenn man

02:04:35.560 --> 02:04:38.640
Bestellungstransaktionen

02:04:38.640 --> 02:04:40.020
prozessiert, aber

02:04:40.020 --> 02:04:42.240
zum Beispiel, wenn man testet.

02:04:42.240 --> 02:04:44.400
Oft hat man ja

02:04:44.400 --> 02:04:46.120
viele Tests für eine Applikation

02:04:46.120 --> 02:04:48.160
und es dauert lange, bis die durchlaufen,

02:04:48.160 --> 02:04:49.200
wenn man jetzt irgendeine Änderung macht,

02:04:49.200 --> 02:04:51.980
und man führt die Tests aus und das dauert ein paar Minuten,

02:04:51.980 --> 02:04:53.280
das ist halt schlecht, weil es halt diesen,

02:04:53.280 --> 02:04:56.300
man ändert was, führt die Tests aus

02:04:56.300 --> 02:04:58.160
und hat dann sofort Feedback,

02:04:58.160 --> 02:04:59.560
der Cycle irgendwie

02:04:59.560 --> 02:05:01.920
kaputt macht, wenn man dann halt

02:05:01.920 --> 02:05:03.980
Kaffee trinken gehen muss, und das macht

02:05:03.980 --> 02:05:05.440
auch so ein bisschen die Konzentration kaputt.

02:05:05.440 --> 02:05:08.180
Daher wäre es

02:05:08.180 --> 02:05:09.840
schön, wenn die Tests irgendwie schnell laufen würden,

02:05:09.840 --> 02:05:12.020
und da man aber

02:05:12.020 --> 02:05:14.080
auch für die Tests, wenn man jetzt

02:05:14.080 --> 02:05:15.600
ein Django-Projekt hat, auch die echten Daten, auch

02:05:15.600 --> 02:05:17.600
Postgres verwenden will, was viele Leute machen,

02:05:17.600 --> 02:05:20.240
früher gemacht haben, ist dann halt ein SQLite

02:05:20.240 --> 02:05:22.040
zu verwenden, das nur in Memory ist.

02:05:22.040 --> 02:05:24.020
Das geht dann viel schneller, aber das Problem

02:05:24.020 --> 02:05:26.160
ist halt, dass SQLite

02:05:26.160 --> 02:05:28.120
sich anders verhält als Postgres, und dann laufen die

02:05:28.120 --> 02:05:30.080
Tests durch, und man denkt, das ist alles gut, und dann

02:05:30.080 --> 02:05:31.780
geht es auf die Datenbank, und dann geht es schief.

02:05:31.780 --> 02:05:32.720
Nicht so gut.

02:05:32.720 --> 02:05:35.400
Aber was man tatsächlich machen kann, ist

02:05:35.400 --> 02:05:37.880
Postgres zu sagen, ja, irgendwie nicht

02:05:37.880 --> 02:05:39.140
absinken, macht man nicht.

02:05:39.140 --> 02:05:42.280
Und man kann auch die Postgres dann auf eine

02:05:42.280 --> 02:05:44.500
In-Memory-Partition

02:05:44.500 --> 02:05:45.700
legen, quasi, das geht auch.

02:05:45.700 --> 02:05:48.060
Kann man auch irgendwie, per Docker-Argumenten

02:05:48.060 --> 02:05:49.820
kann man das irgendwie sagen, und dann sind die Tests halt

02:05:49.820 --> 02:05:51.980
viel, viel schneller. Weil für Tests ist es mir egal, ob das

02:05:51.980 --> 02:05:53.720
jetzt, wenn der Strom ausgeht, dann ist es mir wurscht.

02:05:53.720 --> 02:05:55.920
Ich meine, die Testdatenbank schmeißt

02:05:55.920 --> 02:05:57.600
sowieso nach jedem Testlauf wieder weg, quasi.

02:05:58.120 --> 02:05:58.560
Also,

02:05:58.560 --> 02:06:01.720
ja, aber für die echte Produktionsdatenbank,

02:06:01.720 --> 02:06:03.880
die muss halt bei Transaktionen tatsächlich

02:06:03.880 --> 02:06:05.720
dafür sorgen, dass das nicht mehr verschwinden kann,

02:06:05.720 --> 02:06:07.300
und das heißt, sie muss Absinthe aufrufen, und dann

02:06:07.300 --> 02:06:09.920
ist das halt einfach langsam, da kann man auch nichts machen.

02:06:09.920 --> 02:06:13.600
Okay, einmal ein bisschen Acid, ne?

02:06:13.600 --> 02:06:14.640
Ja, genau, haben wir Acid.

02:06:14.640 --> 02:06:17.500
Und dann, ja, also was wir

02:06:17.500 --> 02:06:19.340
dann heutzutage oft haben, sehen

02:06:19.340 --> 02:06:21.660
bei

02:06:21.660 --> 02:06:23.660
Datenbanken,

02:06:23.660 --> 02:06:25.380
die das halt, oder Dokumentdatenbanken,

02:06:25.380 --> 02:06:27.200
genau, ist halt ein anderes

02:06:27.200 --> 02:06:29.460
Party-Management, das nennt sich Base,

02:06:29.460 --> 02:06:31.080
also Basic Availability,

02:06:31.080 --> 02:06:32.900
Soft-State, Eventual Consistency,

02:06:32.900 --> 02:06:35.420
also, wo man halt versucht, die Sachen so

02:06:35.420 --> 02:06:37.280
aufzulockern, um halt es möglich zu machen,

02:06:37.280 --> 02:06:38.640
dass man zum Beispiel mehrere

02:06:38.640 --> 02:06:41.380
Datenbanken

02:06:41.380 --> 02:06:42.780
schreiben kann.

02:06:42.780 --> 02:06:43.760
Ja.

02:06:43.760 --> 02:06:46.880
Ja.

02:06:46.880 --> 02:06:49.160
Wir sind jetzt dann ziemlich groß geworden, oder?

02:06:49.160 --> 02:06:51.300
Ja, genau,

02:06:51.300 --> 02:06:53.160
wir sind jetzt ziemlich groß, und was wir jetzt haben, wenn wir auf

02:06:53.160 --> 02:06:53.700
mehrere Sachen

02:06:53.700 --> 02:06:56.960
schreiben wollen,

02:06:57.040 --> 02:06:58.940
ist halt, genau, das Acid ist halt weg,

02:06:58.940 --> 02:06:59.880
Pech gehabt.

02:06:59.880 --> 02:07:03.160
Nein, wir haben noch ein anderes Ding,

02:07:03.160 --> 02:07:04.660
das ist dann noch

02:07:04.660 --> 02:07:07.480
das Cap Theorem,

02:07:07.480 --> 02:07:09.900
Consistency, Availability

02:07:09.900 --> 02:07:11.120
und Partition Tolerance,

02:07:11.120 --> 02:07:13.500
das ist halt auch dieses, wenn man immer, wenn man so Sachen

02:07:13.500 --> 02:07:15.260
Pick-Two-out-of-Three-Sachen sieht,

02:07:15.260 --> 02:07:17.800
also das Cap Theorem ist halt so das ursprüngliche

02:07:17.800 --> 02:07:19.780
Ding dafür, du kannst halt zwei davon

02:07:19.780 --> 02:07:21.600
hinkriegen, aber drei nicht, und Partition Tolerance

02:07:21.600 --> 02:07:23.660
ist leider nicht optional, das musst du halt

02:07:23.660 --> 02:07:25.920
haben, weil dann noch Partition Tolerance,

02:07:25.920 --> 02:07:26.580
also was ist, wenn,

02:07:26.580 --> 02:07:28.080
wenn Netzwerkverbindung zwischen

02:07:28.080 --> 02:07:29.840
zwei deiner Datenbank-Dinger

02:07:29.840 --> 02:07:30.980
irgendwie wegfällt, oder so,

02:07:30.980 --> 02:07:33.480
das musst du halt leider,

02:07:33.480 --> 02:07:35.880
das ist halt mandatory,

02:07:35.880 --> 02:07:37.080
sozusagen, und

02:07:37.080 --> 02:07:39.040
das heißt, du kannst nur noch zwischen

02:07:39.040 --> 02:07:41.960
Consistency und Availability

02:07:41.960 --> 02:07:43.500
halt irgendwie wählen.

02:07:43.500 --> 02:07:45.740
Und du hast halt, ja,

02:07:45.740 --> 02:07:47.720
dann gibt's halt Datenbanken, die dann halt

02:07:47.720 --> 02:07:50.080
unterschiedliche Trade-Offs realisieren.

02:07:50.080 --> 02:07:54.160
Ja.

02:07:54.160 --> 02:07:54.460
Ja.

02:07:56.580 --> 02:07:57.320
Genau.

02:07:57.320 --> 02:08:00.120
Das ist zum Beispiel, ein interessanter

02:08:00.120 --> 02:08:01.640
Fall ist halt sowas wie CouchDB,

02:08:01.640 --> 02:08:04.000
die halt,

02:08:04.000 --> 02:08:06.220
wo du sogar, wenn du halt offline bist,

02:08:06.220 --> 02:08:07.040
immer noch,

02:08:07.040 --> 02:08:09.820
wo du immer noch eine Datenbankverbindung

02:08:09.820 --> 02:08:11.980
hast, oder immer noch deine Applikation benutzen kannst, und die

02:08:11.980 --> 02:08:13.240
schreibt dann halt das in eine lokale

02:08:13.240 --> 02:08:15.640
CouchDB-Instanz, auch interessant,

02:08:15.640 --> 02:08:17.780
weil es ist halt so ein JavaScript-Ding,

02:08:17.780 --> 02:08:18.720
aber

02:08:18.720 --> 02:08:22.020
früher hatte man so

02:08:22.020 --> 02:08:23.840
jQuery als Abstraktionslevel für

02:08:23.840 --> 02:08:25.700
alles, was irgendwie auf diesem

02:08:25.700 --> 02:08:28.060
DOM-Modell im Browser irgendwie Dinge tut.

02:08:28.060 --> 02:08:29.800
Man möchte es ja vereinheitlichen, alle Browser haben das

02:08:29.800 --> 02:08:31.380
unterschiedlich, die haben da unterschiedliche Funktionen gehabt.

02:08:31.380 --> 02:08:33.800
Also hatte man jQuery, und wenn man jQuery

02:08:33.800 --> 02:08:35.420
konnte, dann war es einem halt quasi egal,

02:08:35.420 --> 02:08:37.780
welcher Browser da drunter lag, und bei

02:08:37.780 --> 02:08:39.620
CouchDB ist es so, das abstrahiert so ein bisschen

02:08:39.620 --> 02:08:41.660
diese Storage-APIs, die Browser haben.

02:08:41.660 --> 02:08:43.860
Das ist halt quasi dafür gedacht,

02:08:43.860 --> 02:08:45.160
wenn du jetzt eine lokale,

02:08:45.160 --> 02:08:48.180
wenn du eine Webseite

02:08:48.180 --> 02:08:50.180
auf einem Smartphone

02:08:50.180 --> 02:08:51.860
hast, oder so, und du hast halt nicht immer

02:08:51.860 --> 02:08:53.820
Verbindungen, du möchtest

02:08:53.820 --> 02:08:55.600
aber trotzdem, dass dich deine Webseite

02:08:55.600 --> 02:08:57.560
so anfühlt, als hättest du irgendwie

02:08:57.560 --> 02:08:59.920
eine Verbindung, so offline

02:08:59.920 --> 02:09:01.220
first, oder so, jetzt

02:09:01.220 --> 02:09:03.620
im Shopping-Kontext ist das halt nicht so

02:09:03.620 --> 02:09:05.560
richtig gut vorstellbar, warum das irgendwie

02:09:05.560 --> 02:09:07.340
sinnvoll ist, aber nehmen wir an, du hast jetzt irgendwie sowas wie

02:09:07.340 --> 02:09:09.780
Trello, also irgendwie so Tasks

02:09:09.780 --> 02:09:11.000
oder so, wo du Sachen machen kannst,

02:09:11.000 --> 02:09:13.860
da möchtest du nicht, dass wenn du jetzt durch einen Tunnel fährst,

02:09:13.860 --> 02:09:15.380
dann nichts mehr geht, sondern

02:09:15.380 --> 02:09:17.540
das geht halt mit CouchDB,

02:09:17.540 --> 02:09:19.500
das ist halt sozusagen wie Jackfairy Lea

02:09:19.500 --> 02:09:21.700
über dem Storage-API von deinem Browser,

02:09:21.700 --> 02:09:23.580
weil die können das ja auch alle mittlerweile, die haben meistens

02:09:23.580 --> 02:09:25.560
SQLite oder sonst irgendwas drunter, und dann

02:09:25.560 --> 02:09:27.740
halt APIs, mit denen du da irgendwie Dinge drauf tun kannst,

02:09:27.740 --> 02:09:29.680
und

02:09:29.680 --> 02:09:31.720
was CouchDB jetzt letztendlich

02:09:31.720 --> 02:09:33.820
macht, ist da nochmal ein Layer drüber zu liegen, und

02:09:33.820 --> 02:09:35.720
so ein Replikationsfeature

02:09:35.720 --> 02:09:37.480
zu haben,

02:09:37.480 --> 02:09:39.480
in alle möglichen Richtungen, also es sind halt

02:09:39.480 --> 02:09:41.460
Master-Master, oder

02:09:41.460 --> 02:09:43.720
Datenbank zu Datenbank in alle Richtungen, es ist halt nur so,

02:09:43.720 --> 02:09:45.580
dass ab und zu können halt Konflikte auftreten, und die

02:09:45.580 --> 02:09:47.480
müssen dann vom User gelöst werden,

02:09:47.480 --> 02:09:49.220
das heißt, du wirst halt manchmal gefragt, ist das oder das

02:09:49.220 --> 02:09:51.560
richtig, aber

02:09:51.560 --> 02:09:53.300
das passiert jetzt auch nicht so super häufig,

02:09:53.300 --> 02:09:55.320
und das ist halt schon sehr, sehr nett, also

02:09:55.520 --> 02:09:56.900
das ist halt,

02:09:56.900 --> 02:09:59.580
also du kannst halt, auch wenn du offline bist,

02:09:59.580 --> 02:10:01.420
halt deine Web-Anwendung weiter so benutzen,

02:10:01.420 --> 02:10:03.580
als wärst du

02:10:03.580 --> 02:10:05.580
online, und das synchronisiert sich halt

02:10:05.580 --> 02:10:07.020
in dem Moment, wo du halt wieder Verbindungen hast,

02:10:07.020 --> 02:10:08.900
und

02:10:08.900 --> 02:10:11.440
ja, das ist halt dann sehr auf der

02:10:11.440 --> 02:10:13.580
Availability-Seite, und halt dann auf der Konsistenz-Seite

02:10:13.580 --> 02:10:15.520
halt nicht, deswegen musst du halt dann

02:10:15.520 --> 02:10:17.600
Sachen auch, Konflikte manuell

02:10:17.600 --> 02:10:18.540
unter Umständen lösen.

02:10:18.540 --> 02:10:22.040
Genau.

02:10:22.040 --> 02:10:24.560
Ja.

02:10:25.520 --> 02:10:27.380
So, jetzt haben wir, okay,

02:10:27.380 --> 02:10:30.700
jetzt sind wir, glaube ich,

02:10:30.700 --> 02:10:31.540
im Grunde

02:10:31.540 --> 02:10:34.640
mit dem ganzen traditionellen Kram

02:10:34.640 --> 02:10:35.960
mehr oder weniger durch,

02:10:35.960 --> 02:10:36.940
wahrscheinlich nicht so wirklich,

02:10:36.940 --> 02:10:38.900
wahrscheinlich haben wir es schon ganz lange geschafft,

02:10:38.900 --> 02:10:42.440
aber, und jetzt kommt eigentlich nur noch

02:10:42.440 --> 02:10:43.920
nur noch ein Teil, und das ist halt

02:10:43.920 --> 02:10:45.720
irgendwie so Big Data, oder

02:10:45.720 --> 02:10:47.780
Urlaub-Geschichten für

02:10:47.780 --> 02:10:48.920
wirklich große Dinge.

02:10:48.920 --> 02:10:50.640
Really, really, really big things.

02:10:50.640 --> 02:10:52.580
Ja, also, ich meine, Big Data

02:10:52.580 --> 02:10:53.880
ist ja so ein bisschen, ich weiß nicht, was

02:10:53.880 --> 02:10:55.480
sagt, was

02:10:55.480 --> 02:10:57.400
würdest du sagen, ist Big Data, oder

02:10:57.400 --> 02:11:00.020
warum wollen Leute das haben, oder?

02:11:00.020 --> 02:11:01.840
Ja, also, erstmal hört sich cool an, und also

02:11:01.840 --> 02:11:03.860
jede echte Tablette mit mehr als, weiß nicht, tausend Teilen

02:11:03.860 --> 02:11:05.500
kann man schon dann irgendwie fick machen, oder sowas.

02:11:05.500 --> 02:11:08.020
Also, das kommt halt, glaube ich, ein bisschen auf den Anwendungsfall

02:11:08.020 --> 02:11:09.860
an, und jeder hat natürlich gerne Big Data, weil es

02:11:09.860 --> 02:11:11.820
natürlich super ist, man ganz viel machen kann,

02:11:11.820 --> 02:11:14.020
man kann Analysen mitfahren, und sowas.

02:11:14.020 --> 02:11:15.900
Alles, was

02:11:15.900 --> 02:11:17.760
halt irgendwie anfällt an Dingen, die man

02:11:17.760 --> 02:11:19.700
durch die ganzen modernen Daten irgendwie so jederzeit

02:11:19.700 --> 02:11:21.260
bekommt, ist dann irgendwann sehr big.

02:11:21.260 --> 02:11:23.080
Fühlt sich einfach groß an, wenn man

02:11:23.080 --> 02:11:25.360
ganz viele Sensordaten von verschiedenen

02:11:25.360 --> 02:11:27.700
Punkten bekommt, was soll man damit machen, man treibt hier irgendwelche

02:11:27.700 --> 02:11:28.660
Excel-Tabellen rein, also

02:11:28.660 --> 02:11:31.260
die liegen dann halt auf irgendwelchen

02:11:31.260 --> 02:11:33.300
Servern, oder halt auch einfach nur

02:11:33.300 --> 02:11:35.120
Rechnern rum, und dann hat man ganz viele

02:11:35.120 --> 02:11:37.120
große Informationen, ohne dass man damit was anfangen kann bisher.

02:11:37.120 --> 02:11:39.400
Das ist vielleicht schon Big Data, ich weiß

02:11:39.400 --> 02:11:40.960
nicht, also, ich glaube, dass überall

02:11:40.960 --> 02:11:43.320
Daten vorhanden sind, ist vielleicht das eigentliche

02:11:43.320 --> 02:11:45.220
Big Data, aber ob jetzt so im Einzelfall

02:11:45.220 --> 02:11:47.000
das wirklich big ist, was sagst du?

02:11:47.000 --> 02:11:49.080
Ja, also, genau, ich habe auch,

02:11:49.080 --> 02:11:50.900
es gibt dann sehr unterschiedliche

02:11:50.900 --> 02:11:53.260
Auffassungen davon,

02:11:53.260 --> 02:11:55.340
es gibt dann Leute, die sagen so, ja, was ist nicht mehr in der Excel-Tabelle,

02:11:55.340 --> 02:11:57.260
was ist schon so, also, ich würde sagen,

02:11:57.260 --> 02:11:59.300
vielleicht etwas halbwegs Vernünftigeres ist halt, was nicht mehr

02:11:59.300 --> 02:12:01.280
auf einen Computer passt, aber auch das

02:12:01.280 --> 02:12:03.180
greift eigentlich zu kurz, ich habe dann letztens

02:12:03.180 --> 02:12:03.900
nochmal irgendwie,

02:12:03.900 --> 02:12:06.920
Feines Spiel ist er nun.

02:12:06.920 --> 02:12:09.120
Ja, das war irgendein Talk von

02:12:09.120 --> 02:12:11.080
Michael Stonebreaker, das ist auch, es gibt so,

02:12:11.080 --> 02:12:13.500
das sind immer die gleichen Namen, auf die man irgendwie in dieser Datenmark-Welt

02:12:13.500 --> 02:12:15.340
stößt, das sind halt so, Michael Stonebreaker,

02:12:15.340 --> 02:12:16.460
Jim Ray,

02:12:16.460 --> 02:12:19.120
Taccott, weiß ich nicht,

02:12:19.120 --> 02:12:20.400
Ducatting,

02:12:20.400 --> 02:12:23.420
das ist auch

02:12:23.420 --> 02:12:25.220
der, der hat auch so einen

02:12:25.220 --> 02:12:27.460
ja, der hat Postgres mitgegründet

02:12:27.460 --> 02:12:29.440
oder Ingress vorher und dann Postgres

02:12:29.440 --> 02:12:31.260
und auch

02:12:31.260 --> 02:12:33.260
viele der noch moderne, der heute

02:12:33.260 --> 02:12:35.060
jetzt ganz modernen Geschichten, wie

02:12:35.060 --> 02:12:37.200
Column Stores, also C-Store, Papers von

02:12:37.200 --> 02:12:39.340
ihm, Volt, wie für so

02:12:39.340 --> 02:12:41.580
In-Memory-Datenbanken-Geschichten,

02:12:41.580 --> 02:12:45.300
ja, der definiert

02:12:45.300 --> 02:12:47.280
das so, der sagt halt, naja, es gibt eigentlich nur noch drei

02:12:47.280 --> 02:12:49.360
Arten, wie Data-Big sein kann, nämlich

02:12:49.360 --> 02:12:51.040
irgendwie, ja, es ist einfach

02:12:51.040 --> 02:12:53.240
zu viel, ja, du hast, und der sagt halt

02:12:53.240 --> 02:12:54.920
nicht irgendwas Konkretes, sondern halt,

02:12:55.100 --> 02:12:56.800
du hast halt Probleme mit der Datenmenge, ja, also

02:12:56.800 --> 02:12:58.840
es ist halt, wenn du wirklich Schwierigkeiten damit hast

02:12:58.840 --> 02:13:00.420
und damit nicht fertig wärst, dann hast du halt

02:13:00.420 --> 02:13:02.800
ein Problem mit der Datenmenge und dann hast du halt

02:13:02.800 --> 02:13:04.760
Big Data, weil es halt für dich schwierig ist,

02:13:04.760 --> 02:13:06.900
mit dieser Menge klarzukommen, aber

02:13:06.900 --> 02:13:08.840
was halt auch sein kann, ist, und dann hast du halt

02:13:08.840 --> 02:13:10.760
auch ein Big Data-Problem, auch wenn es

02:13:10.760 --> 02:13:12.280
jetzt nicht unbedingt eins ist, das

02:13:12.280 --> 02:13:14.800
das mit der Datenmenge zu tun hat, wenn

02:13:14.800 --> 02:13:16.760
die Daten zu schnell kommen, also du könntest mit der Datenmenge

02:13:16.760 --> 02:13:18.700
vielleicht klarkommen, aber sie kommen so schnell, dass du irgendwie

02:13:18.700 --> 02:13:19.160
nicht fertig wirst.

02:13:19.160 --> 02:13:23.220
Ja, dann hast du auch ein Big Data-Problem,

02:13:23.220 --> 02:13:25.040
aber halt eine andere Art von Big Data-Problem,

02:13:25.060 --> 02:13:27.040
es gibt dann noch eins, das ist halt, wenn

02:13:27.040 --> 02:13:29.400
Daten aus ganz vielen, sehr unterschiedlichen

02:13:29.400 --> 02:13:30.840
Quellen und sehr unterschiedlicher Art kommen,

02:13:30.840 --> 02:13:33.080
sind es vielleicht gar nicht so viele und sie kommen auch nicht so schnell,

02:13:33.080 --> 02:13:35.100
aber du kriegst sie nicht schnell genug integriert

02:13:35.100 --> 02:13:37.140
oder kriegst es halt nicht in den Griff. Da hast du auch wieder

02:13:37.140 --> 02:13:38.940
ein Big Data-Problem, was auch wieder leicht anders ist, und diese

02:13:38.940 --> 02:13:40.900
drei Dinger sind halt eigentlich alle irgendwie so ein bisschen

02:13:40.900 --> 02:13:43.160
unterschiedlich, und

02:13:43.160 --> 02:13:44.160
ja,

02:13:44.160 --> 02:13:45.600
oft

02:13:45.600 --> 02:13:48.780
wird es nicht so richtig klar, und oft ist es,

02:13:48.780 --> 02:13:51.180
ich würde auch sagen, Big Data ist so ein gehyptes Ding,

02:13:51.180 --> 02:13:52.660
und

02:13:52.660 --> 02:13:55.020
ja, irgendwie, es gibt

02:13:55.020 --> 02:13:56.400
ganz viele Hadoop-Cluster verkauft.

02:13:56.400 --> 02:13:58.380
Was ist ein Hadoop-Cluster?

02:13:58.380 --> 02:14:00.820
Ja, es ist,

02:14:00.820 --> 02:14:03.020
Hadoop ist irgendwie so ein,

02:14:03.020 --> 02:14:04.640
das Start ist ein

02:14:04.640 --> 02:14:07.040
Apache-Projekt,

02:14:07.040 --> 02:14:08.900
das irgendwie mal gestartet ist als so

02:14:08.900 --> 02:14:10.520
Implementierung eines

02:14:10.520 --> 02:14:12.420
Konzepts, nennt sich MapReduce,

02:14:12.420 --> 02:14:14.720
das ist ein Paper, das hat Google mal veröffentlicht,

02:14:14.720 --> 02:14:16.960
Jeff Dean und noch ein paar andere

02:14:16.960 --> 02:14:19.000
haben das veröffentlicht, 2004

02:14:19.000 --> 02:14:21.000
glaube ich, und das

02:14:21.000 --> 02:14:22.820
ist halt eine Art, mit großen

02:14:22.820 --> 02:14:24.780
Datenmengen umzugehen, und die halt so

02:14:24.980 --> 02:14:27.020
horizontal irgendwie auf ganz viele Maschinen

02:14:27.020 --> 02:14:29.140
zu skalieren. Das funktioniert

02:14:29.140 --> 02:14:31.000
im Grunde so, dass es halt auch genau dafür gedacht ist,

02:14:31.000 --> 02:14:32.700
wenn man jetzt einen großen Suchindex, wie man

02:14:32.700 --> 02:14:34.980
bei Google zum Beispiel hat, irgendwie bauen

02:14:34.980 --> 02:14:36.880
möchte über das gesamte Web, dann

02:14:36.880 --> 02:14:39.000
kann man das halt eben nicht auf einer Maschine tun, das ist halt

02:14:39.000 --> 02:14:39.680
völlig ausgeschlossen,

02:14:39.680 --> 02:14:42.480
und man möchte das halt irgendwie

02:14:42.480 --> 02:14:45.100
ja, auf möglichst viele

02:14:45.100 --> 02:14:47.260
Maschinen, so eine halbe Million, eine Million oder so, skalieren.

02:14:47.260 --> 02:14:48.980
Wie macht man das? Und

02:14:48.980 --> 02:14:50.940
das Konzept, das sich dafür überlegt haben, nennt sich halt

02:14:50.940 --> 02:14:53.120
MapReduce, und ist auch eigentlich

02:14:53.120 --> 02:14:54.940
nicht wirklich was Neues, früher gab es da

02:14:54.940 --> 02:14:56.100
auch schon ein ähnliches Konzept, wie nennt man sich

02:14:56.100 --> 02:14:59.040
ScalaGather oder sowas, und

02:14:59.040 --> 02:15:01.120
im Distributed Computing Teil

02:15:01.120 --> 02:15:02.540
gibt es auch diverse Geschichten, die so ähnlich sind,

02:15:02.540 --> 02:15:04.940
aber so auf der Skala und so, und

02:15:04.940 --> 02:15:06.920
die Art, wie sie das konkret machen, ist halt schon, war schon

02:15:06.920 --> 02:15:09.000
irgendwie was Neues, und auch ein sehr, sehr, sehr

02:15:09.000 --> 02:15:10.960
cooler Ansatz, und zwar machen sie das halt

02:15:10.960 --> 02:15:12.820
so, dass, also im Grunde kann man sich das vorstellen,

02:15:12.820 --> 02:15:14.120
wenn man jetzt eine Webseite hat,

02:15:14.120 --> 02:15:16.720
viele Rechner, die halt Webseiten

02:15:16.720 --> 02:15:19.000
crawlen, nimmt man den Text, zerlegt den halt

02:15:19.000 --> 02:15:20.720
in Worte, und man

02:15:20.720 --> 02:15:23.100
spuckt jetzt sozusagen für jedes Wort

02:15:23.100 --> 02:15:24.900
einmal das Wort, oder für die Webseite

02:15:24.900 --> 02:15:26.980
die Worte aus, aus denen die

02:15:26.980 --> 02:15:28.980
Webseite besteht, plus die Anzahl, wie oft das

02:15:28.980 --> 02:15:30.900
vorkommt. Das ist halt sozusagen

02:15:30.900 --> 02:15:32.820
die Map-Phase, und das machst du jetzt auf allen

02:15:32.820 --> 02:15:34.040
Maschinen,

02:15:34.040 --> 02:15:37.020
und dann führst du das halt irgendwann wieder zusammen

02:15:37.020 --> 02:15:37.760
in einem Reducer,

02:15:37.760 --> 02:15:40.940
und, also

02:15:40.940 --> 02:15:42.760
was du bauen möchtest, ist sozusagen so

02:15:42.760 --> 02:15:44.620
ein Index,

02:15:44.620 --> 02:15:45.440
das ist halt

02:15:45.440 --> 02:15:48.640
wie ein Index in einem

02:15:48.640 --> 02:15:49.520
Buch,

02:15:49.520 --> 02:15:52.900
wo halt steht, welches Wort kommt auf welcher

02:15:52.900 --> 02:15:54.580
Seite vor, ja, und du musst,

02:15:54.860 --> 02:15:57.060
musst halt für so ein Webseiten-Internet, musst du halt sagen, welches Wort

02:15:57.060 --> 02:15:58.380
kommt auf welcher Webseite

02:15:58.380 --> 02:16:00.960
vor,

02:16:00.960 --> 02:16:02.600
das ist halt das, was du hinterher haben willst.

02:16:02.600 --> 02:16:05.180
Und die sortiert man dann

02:16:05.180 --> 02:16:06.940
nach der Reihenfolge, wie oft das immer vorkommt, oder so

02:16:06.940 --> 02:16:09.000
ungefähr. Genau, man muss halt auch wissen, wie oft das

02:16:09.000 --> 02:16:11.040
vorkommt, weil man halt bestimmte

02:16:11.040 --> 02:16:12.780
Geschichten nutzt, man, ja.

02:16:12.780 --> 02:16:15.000
Wir stehen am Anfang von der Liste, wie oft das

02:16:15.000 --> 02:16:16.680
vorkommt. Ja, man rechnet so

02:16:16.680 --> 02:16:18.860
TF-IDF-Scores aus, und dafür brauchen wir halt die

02:16:18.860 --> 02:16:20.800
Term-Frequenz. So, bitte, was? TF-IDF-Scores?

02:16:20.800 --> 02:16:23.180
Ja, Term-Frequenz mal

02:16:23.180 --> 02:16:24.280
Inverse Document Frequency.

02:16:24.820 --> 02:16:26.760
Das ist halt sozusagen ein wichtiger Wert dafür, wie

02:16:26.760 --> 02:16:28.460
wichtig jetzt

02:16:28.460 --> 02:16:30.800
ein Wort

02:16:30.800 --> 02:16:32.860
ist in einem, in einer

02:16:32.860 --> 02:16:33.820
Webseite oder in einem Dokument.

02:16:33.820 --> 02:16:36.640
Und dafür muss man halt zählen, wie oft ein Wort vorkommt.

02:16:36.640 --> 02:16:39.040
Ja, aber man muss

02:16:39.040 --> 02:16:40.860
halt auch zählen,

02:16:40.860 --> 02:16:42.180
wie oft das Wort überhaupt vorkommt.

02:16:42.180 --> 02:16:44.880
Und dann generell das noch mit dem

02:16:44.880 --> 02:16:46.700
Kontext und der Wichtigkeit und so im Zusammenhang setzen.

02:16:46.700 --> 02:16:48.800
Ja, also in dieser Webphase imitiert man im Grunde

02:16:48.800 --> 02:16:50.540
nur, welche Webseite war das, wie

02:16:50.540 --> 02:16:52.760
oft ist das Wort da vorgekommen, und dann werden

02:16:52.760 --> 02:16:54.700
diese Ströme dann zusammenreduced,

02:16:54.780 --> 02:16:56.240
und dann sozusagen

02:16:56.240 --> 02:16:58.660
hat man halt irgendwie dann diesen Index,

02:16:58.660 --> 02:17:00.920
wo dann zu jedem Wort steht, auf welchen Webseiten es vorkam,

02:17:00.920 --> 02:17:04.480
ja, wie oft,

02:17:04.480 --> 02:17:06.280
und wie oft es insgesamt vorkam und so.

02:17:06.280 --> 02:17:08.160
Und dann kann man irgendwie so Anfragen machen.

02:17:08.160 --> 02:17:10.440
Und das kann man halt komplett voneinander trennen,

02:17:10.440 --> 02:17:11.560
da halt bestimmte,

02:17:11.560 --> 02:17:14.720
da man, da sich diese

02:17:14.720 --> 02:17:15.980
Sachen komplett voneinander,

02:17:15.980 --> 02:17:17.680
du kannst halt nach Worten auftrennen.

02:17:17.680 --> 02:17:20.620
Also, du musst halt

02:17:20.620 --> 02:17:22.600
nur dafür sorgen, dass das gleiche Wort immer

02:17:22.600 --> 02:17:24.660
auf, dass alle Sachen, die zum

02:17:24.660 --> 02:17:26.540
gleichen Wort gehören, zusammengeführt werden.

02:17:26.540 --> 02:17:27.900
Aber du kannst halt

02:17:27.900 --> 02:17:30.400
ja, für unterschiedliche Worte

02:17:30.400 --> 02:17:32.540
unterschiedliche Maschinen benutzen.

02:17:32.540 --> 02:17:33.760
Das ist halt gar kein Problem.

02:17:33.760 --> 02:17:36.380
Und damit kannst du es quasi beliebig horizontal skalieren.

02:17:36.380 --> 02:17:38.320
Auch da wiederum ist es schwer zu erklären,

02:17:38.320 --> 02:17:40.180
man kann sich das einfach mal angucken, aber gibt's auch...

02:17:40.810 --> 02:17:43.490
Rechenzentrum, da schalte einfach noch eine Maschine ein, wenn du welche brauchst.

02:17:43.490 --> 02:17:45.510
Genau, du kannst halt einfach immer mehr

02:17:45.510 --> 02:17:47.070
Maschinen dazustellen und

02:17:47.070 --> 02:17:49.030
viele Leute haben sich gedacht, oh, das war eine coole

02:17:49.030 --> 02:17:50.830
Idee und dann

02:17:50.830 --> 02:17:52.510
ja,

02:17:52.510 --> 02:17:55.030
einer von denen,

02:17:55.030 --> 02:17:56.710
der Namen man immer hört, irgendwie,

02:17:56.710 --> 02:17:58.890
der hat damals schon bei Excite

02:17:58.890 --> 02:18:01.190
die Suchmaschine gebaut, hat dann später

02:18:01.190 --> 02:18:02.970
eine sehr populäre oder immer noch die

02:18:02.970 --> 02:18:05.190
populärste Volltext-Suchmaschine, die es

02:18:05.190 --> 02:18:07.110
so gibt, Lucine, oder ist die Engine darunter

02:18:07.110 --> 02:18:09.110
jedenfalls geschrieben,

02:18:09.110 --> 02:18:10.410
auch ein Buch darüber,

02:18:10.810 --> 02:18:11.290
das

02:18:11.290 --> 02:18:14.530
ja, und irgendwann hat er sich halt diesen

02:18:14.530 --> 02:18:16.770
ist er eher so in diesen Big Data

02:18:16.770 --> 02:18:18.890
Hadoop-Bereich gegangen, der hat halt ursprünglich auch

02:18:18.890 --> 02:18:20.230
irgendwie dieses Hadoop-Projekt dann

02:18:20.230 --> 02:18:23.050
losgetreten und dabei ging es halt darum,

02:18:23.050 --> 02:18:24.950
ein System wie das, was Google halt

02:18:24.950 --> 02:18:26.530
zum Bauen der NDCs verwendet hat,

02:18:26.530 --> 02:18:28.770
in Open Source nachzubauen

02:18:28.770 --> 02:18:31.110
unter diesem

02:18:31.110 --> 02:18:32.810
Apache-Projekt

02:18:32.810 --> 02:18:34.770
Schirm und

02:18:34.770 --> 02:18:36.990
ja, das hat auch gut funktioniert,

02:18:36.990 --> 02:18:38.390
alles

02:18:38.390 --> 02:18:40.750
ist ein Riesenprojekt geworden,

02:18:40.810 --> 02:18:42.670
es ist auch für manche Sachen halt

02:18:42.670 --> 02:18:44.590
total super, ich würde jetzt nur sagen,

02:18:44.590 --> 02:18:46.490
es wird heute viele Dinge verwendet, für die es

02:18:46.490 --> 02:18:48.010
vielleicht nicht so gut geeignet ist eigentlich

02:18:48.010 --> 02:18:49.230
und

02:18:49.230 --> 02:18:52.850
ja, also es ist, glaube ich, für viele Firmen

02:18:52.850 --> 02:18:55.410
heute so die generische Data-Warehouse-Lösung

02:18:55.410 --> 02:18:55.750
geworden,

02:18:55.750 --> 02:18:58.990
obwohl es dafür, weiß ich nicht,

02:18:58.990 --> 02:19:00.650
also ich würde ja sagen, zum Beispiel

02:19:00.650 --> 02:19:02.150
viele Firmen haben eben keinen Big Data,

02:19:02.150 --> 02:19:05.330
die haben keines dieser drei Big Data-Probleme,

02:19:05.330 --> 02:19:05.650
sondern

02:19:05.650 --> 02:19:08.590
du bist eigentlich noch nicht, wie die es machen sollen.

02:19:08.590 --> 02:19:10.690
Ja, die haben einfach nur Daten,

02:19:10.810 --> 02:19:12.790
und eigentlich passt das an den Hauptspeicher

02:19:12.790 --> 02:19:14.690
und die brauchen nichts davon, das ist, die können einfach

02:19:14.690 --> 02:19:15.930
die, also

02:19:15.930 --> 02:19:18.770
Ja, oder

02:19:18.770 --> 02:19:20.090
irgendwie, nicht mal das,

02:19:20.090 --> 02:19:23.330
ja, ja,

02:19:23.330 --> 02:19:24.170
also

02:19:24.170 --> 02:19:26.150
ein Freund von mir sagt dann immer so,

02:19:26.150 --> 02:19:29.090
ach, ich hab das,

02:19:29.090 --> 02:19:30.650
und ich glaube, ich hab das Twitter gelesen,

02:19:30.650 --> 02:19:32.590
Unsinn, also man sollte

02:19:32.590 --> 02:19:33.970
irgendwie, ich weiß aber nicht mehr, wer es war,

02:19:33.970 --> 02:19:36.570
ich sollte eigentlich mal einen Consulting-Service gründen,

02:19:36.570 --> 02:19:38.270
der irgendwie,

02:19:38.270 --> 02:19:40.730
den man engagieren

02:19:40.730 --> 02:19:40.790
kann,

02:19:40.810 --> 02:19:42.550
wenn man vor der Frage steht, ob man sich jetzt

02:19:42.550 --> 02:19:44.850
ein Hadoop-Cluster irgendwie kaufen möchte oder nicht,

02:19:44.850 --> 02:19:46.210
die Antwort ist immer nein,

02:19:46.210 --> 02:19:47.710
gehe ich da hin und sage,

02:19:47.710 --> 02:19:50.730
lass mich überlegen, äh, nein.

02:19:50.730 --> 02:19:52.710
Deine Daten

02:19:52.710 --> 02:19:53.650
fit in den RAM, ja,

02:19:53.650 --> 02:19:55.450
no.

02:19:55.450 --> 02:19:58.450
Und da einfach jedes Mal

02:19:58.450 --> 02:19:59.530
10.000 Dollar für verlangen,

02:19:59.530 --> 02:20:02.490
das würde, hätte ich irgendwie

02:20:02.490 --> 02:20:04.250
ein nettes Einkommen durch,

02:20:04.250 --> 02:20:06.810
und würde den Unternehmen ein Vielfaches davon sparen,

02:20:06.810 --> 02:20:08.530
von dem, was sie dann ausgeben, wenn sie

02:20:08.530 --> 02:20:10.730
Hadoop-Beratung, das hat der Frühjahrsagent,

02:20:10.810 --> 02:20:10.950
ja,

02:20:10.950 --> 02:20:13.270
äh, und das ist,

02:20:13.270 --> 02:20:14.990
da ist leider vielmehr was dran, also es gibt

02:20:14.990 --> 02:20:17.370
wenige, die das wirklich brauchen, äh, viele, äh,

02:20:17.370 --> 02:20:19.110
schaffen es sich trotzdem an und haben

02:20:19.110 --> 02:20:21.310
dann ein kompliziertes, eine, äh,

02:20:21.310 --> 02:20:23.170
komplizierte Lösung für ein Problem, das sie nicht haben.

02:20:23.170 --> 02:20:25.010
Ich meine, das ist natürlich für die Leute, die

02:20:25.010 --> 02:20:27.110
Geld verdienen. Genau, das Problem, was sie haben,

02:20:27.110 --> 02:20:29.130
ist das einfach total kompliziert, äh,

02:20:29.130 --> 02:20:30.950
zu benutzen, also Dinge wären

02:20:30.950 --> 02:20:32.350
viel einfacher, wenn sie das nicht machen würden, aber,

02:20:32.350 --> 02:20:33.730
naja, so ist es halt nun mal,

02:20:33.730 --> 02:20:35.530
äh,

02:20:35.530 --> 02:20:39.050
und von diesem MapReduce-Ding ist auch,

02:20:39.050 --> 02:20:40.790
äh, diese ganze Hadoop-Welt auch schon so ein,

02:20:40.810 --> 02:20:42.630
so ein bisschen wieder weg, auch Google macht

02:20:42.630 --> 02:20:44.770
nicht mehr wirklich, äh,

02:20:44.770 --> 02:20:46.710
äh, MapReduce, also vielleicht, manche Sachen

02:20:46.710 --> 02:20:48.630
machen sie möglicherweise noch MapReduce, aber es sind

02:20:48.630 --> 02:20:50.690
auch andere Systeme, äh, gegangen, äh,

02:20:50.690 --> 02:20:53.010
Pregel, so ein Graph-Processing-Ding,

02:20:53.010 --> 02:20:54.530
was sie da machen, was halt relativ viel

02:20:54.530 --> 02:20:56.590
tut von dem, was früher MapReduce gemacht hat,

02:20:56.590 --> 02:20:58.630
ähm,

02:20:58.630 --> 02:21:00.730
und, ähm, auch bei Hadoop ist es

02:21:00.730 --> 02:21:02.650
halt so, dass, äh, das, was geblieben

02:21:02.650 --> 02:21:04.990
ist, ist irgendwie so ein verteilter Dateisystem-Layer,

02:21:04.990 --> 02:21:06.550
so auch Management

02:21:06.550 --> 02:21:08.550
von diesen, äh,

02:21:08.550 --> 02:21:10.410
Nodes, äh, irgendwie in diesem, in diesem

02:21:10.410 --> 02:21:10.790
Pflaster,

02:21:11.490 --> 02:21:13.610
ähm, aber, äh,

02:21:13.610 --> 02:21:14.790
die, äh, Engines,

02:21:14.790 --> 02:21:16.650
die jetzt irgendwie Queries darauf prozessen,

02:21:16.650 --> 02:21:18.590
dafür gibt's halt, äh, das nennt sich Hive,

02:21:18.590 --> 02:21:21.150
irgendwie, da schreibt man Queries in so einem SQL-ähnlichen,

02:21:21.150 --> 02:21:23.050
äh, oder, das ist schon SQL,

02:21:23.050 --> 02:21:24.870
man schreibt halt so SQL,

02:21:24.870 --> 02:21:27.230
und das wird dann halt in MapReduce-Jobs

02:21:27.230 --> 02:21:28.770
verwandelt und wird dann halt auf den,

02:21:28.770 --> 02:21:31.030
äh, ja, also im Grunde die Idee

02:21:31.030 --> 02:21:32.830
bei dem ganzen, bei der ganzen Geschichte ist, dass man halt

02:21:32.830 --> 02:21:34.810
nicht mehr die Daten zu einer Stelle bringt,

02:21:34.810 --> 02:21:36.890
wo sie dann processed werden, sondern man bringt

02:21:36.890 --> 02:21:38.530
den Algorithmus zu den Daten,

02:21:38.530 --> 02:21:40.610
die liegen halt, man kann die Daten nicht mehr an einer Stelle

02:21:40.610 --> 02:21:42.490
zusammenführen, weil es sind einfach zu viele, die liegen halt

02:21:42.490 --> 02:21:44.670
auf den lokalen Nodes, und man, äh,

02:21:44.670 --> 02:21:46.390
trägt jetzt den Algorithmus zu diesen Daten,

02:21:46.390 --> 02:21:48.550
und der läuft dann halt lokal

02:21:48.550 --> 02:21:50.570
auf den, auf den Clusternodes da drüber, und dann

02:21:50.570 --> 02:21:52.290
am Schluss wird das alles wieder zusammengeführt, äh,

02:21:52.290 --> 02:21:54.510
zusammenreduced, und dann kriegt man halt das

02:21:54.510 --> 02:21:56.410
Ergebnis, ja, und für einen selber sieht das so aus,

02:21:56.410 --> 02:21:57.990
man schreibt halt ein SQL-Statement und kriegt halt

02:21:57.990 --> 02:22:00.830
ein Ergebnis, äh, und in Wirklichkeit

02:22:00.830 --> 02:22:02.390
hat man dann halt irgendwie einen Job gebaut, der

02:22:02.390 --> 02:22:04.350
dann halt, äh, 100 Mapper,

02:22:04.350 --> 02:22:06.430
100 Reducer angestoßen hat,

02:22:06.430 --> 02:22:08.430
und das lief halt über 200 Maschinen, und, ähm,

02:22:08.430 --> 02:22:09.770
ja.

02:22:10.410 --> 02:22:12.110
Big. Ja, ja, ja.

02:22:12.110 --> 02:22:14.570
Hatte vielleicht das Problem nur Big Data dann, also

02:22:14.570 --> 02:22:16.190
Big, nicht Data. Ja.

02:22:16.190 --> 02:22:18.710
Haha. Aber, ja,

02:22:18.710 --> 02:22:20.550
aber es wäre halt, das hat dann vielleicht

02:22:20.550 --> 02:22:22.430
eine halbe Stunde gedauert, aber es ist halt auch möglich, dass

02:22:22.430 --> 02:22:24.390
wenn man das anders gemacht hätte, hätte

02:22:24.390 --> 02:22:26.690
diese ganze Geschichte auch in der Minute durchlaufen können,

02:22:26.690 --> 02:22:28.670
ja, und, ja,

02:22:28.670 --> 02:22:30.810
es gibt dann auch andere Geschichten, die jetzt auf solchen

02:22:30.810 --> 02:22:32.670
Clustern laufen, äh, zum Beispiel

02:22:32.670 --> 02:22:34.730
rein in Memory-Geschichten, so was wie Impala,

02:22:34.730 --> 02:22:36.630
äh, einer

02:22:36.630 --> 02:22:37.630
von, ähm,

02:22:37.630 --> 02:22:40.090
äh, den, den PhD,

02:22:40.210 --> 02:22:42.090
äh, Studenten von Michael Stonewrecker,

02:22:42.090 --> 02:22:44.370
die, äh, damals Postgres mitgeschrieben

02:22:44.370 --> 02:22:46.250
haben, äh, ist da irgendwie CTO von

02:22:46.250 --> 02:22:48.310
der Firma, die da, ich hab jetzt auch wieder vergessen, welche das ist,

02:22:48.310 --> 02:22:50.130
äh, das

02:22:50.130 --> 02:22:52.110
macht das halt in Memory, das ist in C geschrieben,

02:22:52.110 --> 02:22:53.870
das ist alles schneller, das, äh,

02:22:53.870 --> 02:22:56.670
das ist viel angenehmer, wenn man damit arbeitet, aber es ist

02:22:56.670 --> 02:22:58.210
auch so ein bisschen komisch, und es ist halt auch nicht so

02:22:58.210 --> 02:22:58.510
richtig,

02:22:58.510 --> 02:23:02.290
äh, es ist halt nur ein bisschen instabil, ähm,

02:23:02.290 --> 02:23:04.030
äh, es gibt,

02:23:04.030 --> 02:23:06.050
äh, diverse andere

02:23:06.050 --> 02:23:08.010
Geschichten, jetzt gibt's, ach, das war noch ein eigenes Thema,

02:23:08.010 --> 02:23:09.450
eigentlich Spark, Spice Spark,

02:23:10.010 --> 02:23:10.950
ähm,

02:23:10.950 --> 02:23:14.050
äh, was ganz interessant ist, ist,

02:23:14.050 --> 02:23:15.590
äh, ja, was man vielleicht,

02:23:15.590 --> 02:23:17.710
lass mich überlegen,

02:23:17.710 --> 02:23:20.210
also, was, was sehr interessant ist, ist, dass wir

02:23:20.210 --> 02:23:21.950
heute, äh, etwas sehen,

02:23:21.950 --> 02:23:23.730
äh,

02:23:23.730 --> 02:23:26.070
was wir früher eigentlich auch schon gedacht hätten,

02:23:26.070 --> 02:23:28.090
dass wir das im relationalen Bereich bekommen, nämlich, äh,

02:23:28.090 --> 02:23:30.530
oder MySQL hat damit mal angefangen, so, ähm,

02:23:30.530 --> 02:23:32.390
die hatten irgendwie so ein, eines der

02:23:32.390 --> 02:23:34.150
coolen Features bei MySQL am Anfang war, dass

02:23:34.150 --> 02:23:36.190
die, die Storage Engines pluggable

02:23:36.190 --> 02:23:38.010
waren, das heißt, du konntest deine eigene Storage Engine

02:23:38.010 --> 02:23:39.850
da reinbauen, hat auch kaum Änder gemacht,

02:23:39.850 --> 02:23:41.690
es gab eigentlich nur zwei Relevante,

02:23:41.690 --> 02:23:43.910
wie, wie, wie die Daten

02:23:43.910 --> 02:23:45.730
tatsächlich auf der Platte liegen, äh, okay, letztlich,

02:23:45.730 --> 02:23:48.350
äh, und das ist halt, äh,

02:23:48.350 --> 02:23:49.750
es gab MyISAM, äh,

02:23:49.750 --> 02:23:51.810
es gab auch eine CSV-Engine für MySQL, da hast du einfach

02:23:51.810 --> 02:23:53.970
CSV ausgebaut, aber MyISAM

02:23:53.970 --> 02:23:55.770
war so populär, äh, MySQL

02:23:55.770 --> 02:23:57.710
hatte aber Probleme, hatte das Problem, dass du, wenn du

02:23:57.710 --> 02:23:59.670
geschrieben hast, wurde immer die komplette Table gelockt,

02:23:59.670 --> 02:24:01.750
das heißt, also, da lieber nur lesen, nichts reinschreiben, so

02:24:01.750 --> 02:24:03.850
reinschreiben, eher doof, ähm,

02:24:03.850 --> 02:24:05.790
hat trotzdem, irgendwie haben das

02:24:05.790 --> 02:24:07.770
viele lang verwendete Transaktionen, so, das geht alles nicht,

02:24:07.770 --> 02:24:09.770
Asset war nicht so richtig bei MySQL am Anfang, und dann,

02:24:09.810 --> 02:24:11.850
äh, dann hatten sie eine Storage-Engine, die das dann einfach schon konnte,

02:24:11.850 --> 02:24:13.650
die auch so wirklich Multiversion

02:24:13.650 --> 02:24:15.750
Concurrency-Control halt richtig konnte, und das war

02:24:15.750 --> 02:24:18.050
InnoDB, und, äh,

02:24:18.050 --> 02:24:19.690
ja, aber, äh, eigentlich

02:24:19.690 --> 02:24:21.710
so, nachdem InnoDB sich durchgesetzt hatte,

02:24:21.710 --> 02:24:23.410
oder irgendwie gut genug war,

02:24:23.410 --> 02:24:25.570
dann, äh, hat sich dieser

02:24:25.570 --> 02:24:27.670
Plugable-Storage-Engine-Geschichte von,

02:24:27.670 --> 02:24:29.350
von, äh, MySQL hat sich dann auch wieder

02:24:29.350 --> 02:24:30.050
erledigt,

02:24:30.050 --> 02:24:33.750
aber, äh, äh, Postgres bekommt

02:24:33.750 --> 02:24:35.730
jetzt, glaube ich, mit der Version 12, also, naja, das ist noch nicht sicher,

02:24:35.730 --> 02:24:38.170
aber es sieht ein bisschen danach aus, als ob sie die Plugable-Storage-Engines

02:24:38.170 --> 02:24:39.030
wieder zurückbekommen,

02:24:39.770 --> 02:24:40.750
was interessant, äh,

02:24:40.750 --> 02:24:42.530
da ist es dann zum ersten Mal, aber

02:24:42.530 --> 02:24:45.130
das Konzept nochmal, äh, irgendwie

02:24:45.130 --> 02:24:47.210
doch nochmal angefasst wird, äh,

02:24:47.210 --> 02:24:49.190
und interessant ist auch in diesem ganzen, äh,

02:24:49.190 --> 02:24:50.770
Analytics-Big-Data-Bereich,

02:24:50.770 --> 02:24:52.610
dass wir da auch sowas sehen, wir sehen

02:24:52.610 --> 02:24:55.750
halt, äh, es gibt nicht mehr so ein Datenbank-System,

02:24:55.750 --> 02:24:57.570
wo halt die Repre, also

02:24:57.570 --> 02:24:59.270
wie die Daten gespeichert werden, tatsächlich

02:24:59.270 --> 02:25:01.210
an die anderen Teile,

02:25:01.210 --> 02:25:03.530
also im Grunde besteht ja so ein Datenbank-System

02:25:03.530 --> 02:25:05.230
aus vielen unterschiedlichen Geschichten, es besteht halt aus

02:25:05.230 --> 02:25:07.570
so ein, äh, äh, ähm,

02:25:07.570 --> 02:25:09.730
System, das irgendwie einfach nur

02:25:09.730 --> 02:25:11.490
die Daten managt, äh, irgendwie

02:25:11.490 --> 02:25:13.350
und, und Zugriffsrechte verwaltet

02:25:13.350 --> 02:25:15.150
und irgendwie, und dann gibt's halt so Dinge,

02:25:15.150 --> 02:25:17.450
wie speichert man das auf der Platte, es gibt Indizes,

02:25:17.450 --> 02:25:18.750
es gibt so viele unterschiedliche Teile

02:25:18.750 --> 02:25:20.670
und, äh,

02:25:20.670 --> 02:25:23.490
ja, wir sehen jetzt so ein bisschen, dass das halt, äh,

02:25:23.490 --> 02:25:25.170
auch alles wieder so ein bisschen

02:25:25.170 --> 02:25:27.330
Plugable wird, gerade auch in diesem Big-Data-Bereich, also,

02:25:27.330 --> 02:25:29.270
ah, auch wichtig, äh,

02:25:29.270 --> 02:25:31.030
wenn man diese Analyse-Geschichten macht, hat man

02:25:31.030 --> 02:25:33.410
im Grunde, äh,

02:25:33.410 --> 02:25:35.050
äh, ist die Art, wie, also,

02:25:35.050 --> 02:25:37.550
die Daten in relationalen Datenbanken

02:25:37.550 --> 02:25:39.570
gespeichert werden, ist, äh,

02:25:39.690 --> 02:25:41.510
äh, ist teilenweise, ja, weil,

02:25:41.510 --> 02:25:43.730
äh, man oft, weil, weil die

02:25:43.730 --> 02:25:45.410
Art von Queries, die man da macht,

02:25:45.410 --> 02:25:47.250
oft nur wenige Zeilen betreffen.

02:25:47.250 --> 02:25:49.570
Ein paar tausend oder so, aber es sind immer noch sehr wenige.

02:25:49.570 --> 02:25:51.690
Daher macht es Sinn, äh,

02:25:51.690 --> 02:25:53.330
irgendwie, zeilenweise zu arbeiten,

02:25:53.330 --> 02:25:54.930
äh, sozusagen.

02:25:54.930 --> 02:25:57.670
Ähm, aber für diese Analyse-Geschichten,

02:25:57.670 --> 02:25:59.610
dieses ganze Data-Warehousing-Zeugs, äh, ist das

02:25:59.610 --> 02:26:00.770
überhaupt nicht sinnvoll. Dieses

02:26:00.770 --> 02:26:03.430
Muster, dass man halt, ähm,

02:26:03.430 --> 02:26:05.710
eher Millionen von Zeilen

02:26:05.710 --> 02:26:07.570
anguckt, aber nur wenige Spalten, weil man sich nur

02:26:07.570 --> 02:26:09.650
für einen bestimmten Aspekt interessiert. Man interessiert sich

02:26:09.650 --> 02:26:10.990
oft eben nur für

02:26:10.990 --> 02:26:13.730
Umsatz oder Preis oder sowas, oder,

02:26:13.730 --> 02:26:15.630
äh, aber man interessiert sich gar nicht

02:26:15.630 --> 02:26:17.610
für den Namen des Autors oder so, aber

02:26:17.610 --> 02:26:19.690
daher möchte man eigentlich nicht irgendwie

02:26:19.690 --> 02:26:21.710
alle Zeilen immer komplett angucken,

02:26:21.710 --> 02:26:23.550
weil dann guckt man sich ganz viel Zeugs an,

02:26:23.550 --> 02:26:25.570
so die, das, der, das, der

02:26:25.570 --> 02:26:27.550
Flaschenhals ist oft, wie,

02:26:27.550 --> 02:26:29.670
äh, ist oft die, die

02:26:29.670 --> 02:26:31.270
Bandbreite zwischen

02:26:31.270 --> 02:26:33.650
Platte und Hauptspeicher, so, man muss das halt

02:26:33.650 --> 02:26:35.170
dann irgendwie durch den Prozessor ziehen

02:26:35.170 --> 02:26:37.690
und je weniger Daten man dadurch ziehen muss, umso besser.

02:26:37.690 --> 02:26:39.610
Und bei einem Zeilen

02:26:39.610 --> 02:26:41.610
orientierten Format muss ich, wenn ich die Datei lese

02:26:41.610 --> 02:26:43.530
und die Datei, äh, die Datensätze halt zeilenweise

02:26:43.530 --> 02:26:45.530
drinstehen, muss ich halt da sequenziell durch die Zeilen

02:26:45.530 --> 02:26:47.630
durchgehen. Da hilft's, geht nicht

02:26:47.630 --> 02:26:49.710
anders. Und das ist halt total ineffizient,

02:26:49.710 --> 02:26:51.570
weil ich, wenn ich halt nur einen kleinen Teil von

02:26:51.570 --> 02:26:53.550
diesen Zeilen, nämlich nur eine Spalte, irgendwie überhaupt

02:26:53.550 --> 02:26:54.350
lesen möchte. Das heißt,

02:26:54.350 --> 02:26:57.030
wenn ich, äh,

02:26:57.030 --> 02:26:59.610
so Analyse-Querys auf, äh,

02:26:59.610 --> 02:27:01.650
Datenbanken mache, die zeilenbasiert

02:27:01.650 --> 02:27:03.550
ihre Daten speichern, dann ist

02:27:03.550 --> 02:27:05.530
das super ineffizient und ich hab halt so einen Verlust

02:27:05.530 --> 02:27:07.230
von circa, so, man sagt so immer so 5,

02:27:07.230 --> 02:27:09.570
Faktor 50 ungefähr, sind die halt

02:27:09.570 --> 02:27:11.790
einfach aufgrund dieser Architekturgeschichte

02:27:11.790 --> 02:27:13.850
langsamer, und zwar

02:27:13.850 --> 02:27:15.410
unoptimierbar langsamer

02:27:15.410 --> 02:27:17.570
als, äh, äh, sogenannte Column-Stores,

02:27:17.570 --> 02:27:19.330
die halt Daten, äh,

02:27:19.330 --> 02:27:20.970
spaltenweise speichern, ne.

02:27:20.970 --> 02:27:22.350
Und, ähm,

02:27:22.350 --> 02:27:25.550
die, äh, die ersten, äh,

02:27:25.550 --> 02:27:27.630
Dateisystem-Formate oder Formate,

02:27:27.630 --> 02:27:29.450
in denen die Daten zum Beispiel in Hadoop gespeichert wurden,

02:27:29.450 --> 02:27:31.530
äh, Abo ist, glaub ich, so das erste, ich weiß nicht genau,

02:27:31.530 --> 02:27:33.770
äh, sind auch alle zeilenbasiert,

02:27:33.770 --> 02:27:35.530
weil das war halt so, ne, man hat halt irgendwie

02:27:35.530 --> 02:27:37.510
zeilenbasiert Sachen gespeichert, aber

02:27:37.510 --> 02:27:39.510
das ist halt eben total ineffizient,

02:27:39.530 --> 02:27:41.510
wenn man halt nur bestimmte Spalten

02:27:41.510 --> 02:27:43.350
von Datensätzen haben möchte, und dann gibt's halt

02:27:43.350 --> 02:27:45.330
neuere File-Formate wie zum Beispiel, äh,

02:27:45.330 --> 02:27:47.190
oder Serialisierungsformate,

02:27:47.190 --> 02:27:49.530
Parquet, äh, äh,

02:27:49.530 --> 02:27:51.390
Dateien zum Beispiel, das ist halt das, was heute

02:27:51.390 --> 02:27:53.550
eigentlich immer so verwendet wird, das ist halt dann

02:27:53.550 --> 02:27:55.070
spaltenbasiert,

02:27:55.070 --> 02:27:57.270
äh, und dann, dann liest man eben

02:27:57.270 --> 02:27:59.470
nur die Dateien, oder du, du,

02:27:59.470 --> 02:28:01.690
die Spalten, das ist halt in einer Datei

02:28:01.690 --> 02:28:03.130
nur eine Spalte, sozusagen,

02:28:03.130 --> 02:28:05.030
man liest halt nur die Dateien, die man halt braucht,

02:28:05.030 --> 02:28:06.690
ähm,

02:28:06.690 --> 02:28:09.450
und das ist komprimierbar, es ist chunk,

02:28:09.490 --> 02:28:11.550
sodass ich es auf mehrere Rechner verteilen kann, und so,

02:28:11.550 --> 02:28:13.490
und hat halt all diese hübschen Eigenschaften,

02:28:13.490 --> 02:28:14.810
ähm,

02:28:14.810 --> 02:28:17.350
und ich hab jetzt

02:28:17.350 --> 02:28:19.490
diese, diese Parquet-Files, aber das, also das

02:28:19.490 --> 02:28:21.530
Format der, der Daten, äh, auf der Platte,

02:28:21.530 --> 02:28:23.670
das Serialisierungsformat ist nicht mehr gebunden an die Datenbank,

02:28:23.670 --> 02:28:25.370
sondern, äh, als

02:28:25.370 --> 02:28:27.390
Layer da drüber, mit dem ich jetzt Abfragen mache,

02:28:27.390 --> 02:28:29.490
hab ich jetzt sowas wie Hive, das macht dann MapReduce

02:28:29.490 --> 02:28:31.750
Drops draus irgendwie, äh,

02:28:31.750 --> 02:28:33.450
ich hab, äh, aber auch sowas

02:28:33.450 --> 02:28:35.390
wie Impala, ich hab vielleicht andere

02:28:35.390 --> 02:28:37.470
Geschichten, ich hab Spark, und, äh,

02:28:37.470 --> 02:28:39.450
das hast du eben noch vergessen, übrigens, äh,

02:28:39.450 --> 02:28:41.330
Spark, genau, gut, Spark hat auch irgendwie mit,

02:28:41.330 --> 02:28:43.550
ist was mit anderen, was anderen gestartet, die, die,

02:28:43.550 --> 02:28:44.410
äh,

02:28:44.410 --> 02:28:47.710
äh, hat auch ein eigenes DataFrame-Format,

02:28:47.710 --> 02:28:49.410
äh, was, was jetzt nicht Parquet war,

02:28:49.410 --> 02:28:51.470
aber, also, worauf es hinausläuft,

02:28:51.470 --> 02:28:53.230
ist, äh, im Grunde,

02:28:53.230 --> 02:28:55.510
dass ich jetzt, äh, so ein Format

02:28:55.510 --> 02:28:57.350
habe wie Parquet, ähm,

02:28:57.350 --> 02:28:58.870
in dem die Daten auf der Platte liegen,

02:28:58.870 --> 02:29:01.330
und jetzt hab ich halt unterschiedliche

02:29:01.330 --> 02:29:03.430
Engines, die jetzt irgendwie, mit denen ich jetzt

02:29:03.430 --> 02:29:05.410
Queries verarbeite drauf, ja,

02:29:05.410 --> 02:29:06.910
so quasi eine Trennung zwischen,

02:29:06.910 --> 02:29:09.410
ähm, dem System, das jetzt

02:29:09.410 --> 02:29:11.330
meine Queries irgendwie beantwortet, und dem

02:29:11.330 --> 02:29:13.410
Speicherformat, also quasi sowas ähnliches wie

02:29:13.410 --> 02:29:15.350
ein Plugable Storage Engine, so, nur

02:29:15.350 --> 02:29:17.190
dass halt, der Storage-Format ist halt für alle

02:29:17.190 --> 02:29:18.930
unterschiedlichen Engines irgendwie gleich, nämlich Parquet,

02:29:18.930 --> 02:29:21.230
aber das, was halt die, äh, Dinge

02:29:21.230 --> 02:29:22.590
darauf machen, ist halt unterschiedlich.

02:29:22.590 --> 02:29:25.270
Äh, und das ist eine ganz interessante Entwicklung, finde ich, also

02:29:25.270 --> 02:29:26.870
das ist halt, äh, das ist schon faszinierend,

02:29:26.870 --> 02:29:28.310
und, ähm,

02:29:28.310 --> 02:29:29.890
äh,

02:29:29.890 --> 02:29:33.650
ja, die, äh,

02:29:33.650 --> 02:29:35.470
äh, ja, Column Stores

02:29:35.470 --> 02:29:37.450
sind halt sozusagen, das, äh, sind für so Data Warehousing

02:29:37.450 --> 02:29:39.310
eigentlich das, das Coole, es gibt all, es sind,

02:29:39.370 --> 02:29:40.170
es ist, es hieß da,

02:29:40.170 --> 02:29:43.170
Paper ist halt auch eine, äh,

02:29:43.170 --> 02:29:45.270
Firma entstanden, Vertica, glaube ich,

02:29:45.270 --> 02:29:47.350
äh, äh, die machen halt,

02:29:47.350 --> 02:29:49.450
wenn man, wenn man irgendwie ein großes Data Warehouse haben möchte,

02:29:49.450 --> 02:29:51.230
dann ist es wahrscheinlich irgendwie so das Beste, wenn man irgendwie

02:29:51.230 --> 02:29:52.950
zu so einer Firma geht und das macht,

02:29:52.950 --> 02:29:55.350
keine Ahnung, oder es gibt es auch wahrscheinlich

02:29:55.350 --> 02:29:57.250
auch noch andere, die sowas ähnliches machen, ne,

02:29:57.250 --> 02:29:59.210
aber was halt nicht gut wäre, ist halt, wenn man,

02:29:59.210 --> 02:30:01.270
äh, wenn man, wenn man mit so einem Problem zu

02:30:01.270 --> 02:30:03.070
Oracle geht, ne, weil Oracle ist halt nicht Column,

02:30:03.070 --> 02:30:05.290
äh, ist halt nicht Column-Oriented, sondern die sind halt

02:30:05.290 --> 02:30:07.090
zahlenbasiert, egal, was sie dazu sagen, sie versuchen das

02:30:07.090 --> 02:30:08.910
mit ihrem Marketing immer zu verschleiern, aber es ist halt,

02:30:09.330 --> 02:30:11.470
ja, genau wie MSSQL zwar war und

02:30:11.470 --> 02:30:13.530
die ganzen klassischen relationalen

02:30:13.530 --> 02:30:15.310
Datenbanken, die sind alle zahlenbasiert und da

02:30:15.310 --> 02:30:17.190
gibt es auch nichts, was man tun könnte.

02:30:17.190 --> 02:30:19.390
Ja, es sei denn, man tauscht

02:30:19.390 --> 02:30:21.370
die Storage-Editen aus, und so, und das ist halt, äh,

02:30:21.370 --> 02:30:22.950
bei Postgres wird das nochmal interessant.

02:30:22.950 --> 02:30:25.310
So Postgres, da hat man das Problem halt,

02:30:25.310 --> 02:30:27.210
wenn man ein Data Warehouse auf Postgres aufbaut, dann

02:30:27.210 --> 02:30:29.310
ist man immer dann an die zahlenweise,

02:30:29.310 --> 02:30:31.250
äh, äh, Verarbeitung

02:30:31.250 --> 02:30:32.830
gebunden, kann halt auch nichts machen.

02:30:32.830 --> 02:30:35.110
Ähm. Wenn man das zunächst dann halt mit Parquet

02:30:35.110 --> 02:30:37.130
machen könnte, dann... Ja, wenn man irgendwie

02:30:37.130 --> 02:30:39.290
Parquet und Postgres irgendwie verheiraten könnte, das

02:30:39.290 --> 02:30:40.770
wäre natürlich schon ziemlich cool dann irgendwie.

02:30:40.770 --> 02:30:43.450
Ja, äh,

02:30:43.450 --> 02:30:45.370
genau. Und das

02:30:45.370 --> 02:30:47.130
sind halt so die, ähm,

02:30:47.130 --> 02:30:49.370
ja, das sind halt so diese Geschichten beim,

02:30:49.370 --> 02:30:51.150
beim, beim Data Warehousing,

02:30:51.150 --> 02:30:53.270
äh, genau, so Hadoop, man nennt das auch so,

02:30:53.270 --> 02:30:55.230
nicht Data Warehouse, sondern weil man auch alles mögliche andere

02:30:55.230 --> 02:30:56.970
darin speichern kann, Data Lake, äh, weiß ich gar nicht,

02:30:56.970 --> 02:30:59.110
ob man da so ins Detail gehen muss, aber man hat auch noch Bilder und

02:30:59.110 --> 02:31:01.110
sonst wie andere, man kann halt alle möglichen

02:31:01.110 --> 02:31:02.450
Arten von unterschiedlichen Daten...

02:31:02.450 --> 02:31:05.370
Ja, man kann auch so ein bisschen umkippen,

02:31:05.370 --> 02:31:07.230
wenn man das dann Data Swamp...

02:31:09.250 --> 02:31:10.750
Äh, ja, ähm,

02:31:10.750 --> 02:31:13.770
und, äh, äh,

02:31:13.770 --> 02:31:14.870
ja, also,

02:31:14.870 --> 02:31:17.110
ich bin nicht, ich bin nicht, ehrlich gesagt, nicht so ein

02:31:17.110 --> 02:31:18.670
Riesenfan von Hadoop, muss ich sagen.

02:31:18.670 --> 02:31:20.910
So, aber, äh,

02:31:20.910 --> 02:31:22.750
auch, ich hab da auch schon, äh,

02:31:22.750 --> 02:31:24.930
ein bisschen so schmerzhafte Erfahrungen, äh,

02:31:24.930 --> 02:31:27.050
mit, mitgemacht, äh,

02:31:27.050 --> 02:31:29.050
weil so Daten rein und rauskriegen ist

02:31:29.050 --> 02:31:30.850
irgendwann so ein bisschen hässlich und, ähm,

02:31:30.850 --> 02:31:33.110
ja, das ist auch noch alles nicht so weit, also bei, bei so

02:31:33.110 --> 02:31:34.670
klassischen Datenbanken ist halt, da merkt man,

02:31:34.670 --> 02:31:36.990
so wenn man Postgres gerade verwendet zum Beispiel, merkt man halt so,

02:31:36.990 --> 02:31:38.870
das ist halt schon Jahrzehnte, äh,

02:31:39.210 --> 02:31:41.030
äh, Erfahrungen

02:31:41.030 --> 02:31:43.290
drin und viele der Use Cases, die man

02:31:43.290 --> 02:31:44.530
so hat, also wenn man da auf

02:31:44.530 --> 02:31:47.110
blöde Probleme stößt, dann ist man wahrscheinlich selber

02:31:47.110 --> 02:31:48.230
schuld, also das ist halt,

02:31:48.230 --> 02:31:51.330
das ist halt sehr selten, würde ich

02:31:51.330 --> 02:31:51.870
jetzt mal so...

02:31:51.870 --> 02:31:56.150
Ja, dass man auf etwas stößt

02:31:56.150 --> 02:31:57.210
und man hat wirklich ein Problem mit der

02:31:57.210 --> 02:31:59.170
Datenbank, sondern man hat ein Problem mit, man hat die

02:31:59.170 --> 02:32:00.850
Dokumentation nicht genau genug gelesen oder

02:32:00.850 --> 02:32:03.390
man weiß, man hat irgendwie ein Verständnisproblem oder so

02:32:03.390 --> 02:32:05.230
und das sind ja alles Sachen, die sich gleich fixen

02:32:05.230 --> 02:32:07.530
lassen, da muss man, also es wäre halt

02:32:07.530 --> 02:32:09.170
vielleicht schon mal...

02:32:09.170 --> 02:32:11.030
Ja, äh, wenn man tatsächlich ein Problem

02:32:11.030 --> 02:32:12.950
mit der Datenbank hat, ist natürlich, äh, wäre

02:32:12.950 --> 02:32:14.770
natürlich schlecht, weil da kann man nichts machen, ne, außer

02:32:14.770 --> 02:32:16.170
Datenbank wechseln oder irgendwie,

02:32:16.170 --> 02:32:18.970
äh, selber neu schreiben oder sowas,

02:32:18.970 --> 02:32:20.990
nicht gut, ja, äh, und, ähm,

02:32:20.990 --> 02:32:23.230
bei Hadoop habe ich so das Gefühl,

02:32:23.230 --> 02:32:25.150
es kann auch durchaus sein, dass ich einfach

02:32:25.150 --> 02:32:27.170
so blöd weiß, es zu bedienen, aber ich habe so das Gefühl,

02:32:27.170 --> 02:32:29.110
viele Dinge, die man da macht, sind nicht

02:32:29.110 --> 02:32:30.930
dadurch begrenzt, dass man irgendwie nicht genug weiß oder

02:32:30.930 --> 02:32:32.990
nicht genug, das nicht richtig verwendet

02:32:32.990 --> 02:32:35.050
oder es falsch rum hält irgendwie, sondern,

02:32:35.050 --> 02:32:37.030
äh, bestimmte Sachen

02:32:37.030 --> 02:32:38.670
gehen einfach noch nicht oder gehen nicht richtig oder

02:32:39.130 --> 02:32:41.150
man hat Use Cases und dann schleppt man so fest so,

02:32:41.150 --> 02:32:43.070
ja, hat niemand drüber nachgedacht,

02:32:43.070 --> 02:32:44.870
äh, ist nicht so richtig abgebildet, hm,

02:32:44.870 --> 02:32:46.990
blöd, und, ähm,

02:32:46.990 --> 02:32:49.190
das wird wahrscheinlich alles irgendwie viel besser,

02:32:49.190 --> 02:32:50.650
aber momentan ist es noch nicht so,

02:32:50.650 --> 02:32:53.530
ne, es ist noch ein bisschen scharf, fühlt sich alles ein wenig scharfkantig an.

02:32:53.530 --> 02:32:55.230
Man kann sich überschneiden und wehtun

02:32:55.230 --> 02:32:57.150
und aua. Ja, und außerdem, dass es halt alles

02:32:57.150 --> 02:32:58.950
auf dieser Java-Geschichte aufsetzt, ist auch sowas,

02:32:58.950 --> 02:33:00.470
muss ich auch sagen. Ah,

02:33:00.470 --> 02:33:03.090
sind wir wieder bei dem Ding, was wir eigentlich als Running-Gag nehmen wollten,

02:33:03.090 --> 02:33:05.110
haben wir es doch dazu verlassen. Ja, Java,

02:33:05.110 --> 02:33:07.270
mal wieder, das ist, äh...

02:33:07.270 --> 02:33:09.030
Ja, so, nach zweieinhalb Stunden sind wir doch wieder drauf gekommen,

02:33:09.130 --> 02:33:10.990
ja. Ja, ähm, und, aber,

02:33:10.990 --> 02:33:12.970
aber da ist dann möglicherweise der Ausweg, irgendwie sowas wie

02:33:12.970 --> 02:33:14.810
PySpark zu verwenden, das mag auch nochmal,

02:33:14.810 --> 02:33:16.670
eigentlich müssen wir da nochmal ein eigenes Thema zu machen,

02:33:16.670 --> 02:33:19.110
äh, auch, aber sehr schön, das Ding ist so,

02:33:19.110 --> 02:33:20.190
dass man halt, äh, quasi,

02:33:20.190 --> 02:33:23.090
äh, Sachen automatisch

02:33:23.090 --> 02:33:25.090
verteilen kann, man hat sie lokal,

02:33:25.090 --> 02:33:27.210
man kann das mit anfangen, dass man es auf einer Maschine hat

02:33:27.210 --> 02:33:29.090
und dann, äh, äh, führt man Sachen

02:33:29.090 --> 02:33:30.830
auf einen Cluster aus und das ist wirklich

02:33:30.830 --> 02:33:32.790
mehr oder weniger seamless, äh,

02:33:32.790 --> 02:33:35.090
äh, das Einzige,

02:33:35.090 --> 02:33:37.110
ähm, man hat

02:33:37.110 --> 02:33:39.010
sogar einen vollständigen Python-Interpreter, ne, das ist

02:33:39.010 --> 02:33:41.170
irgendwie nicht so eine verkrüppelte Version, man kann halt

02:33:41.170 --> 02:33:43.330
tatsächlich irgendwie Saiten, äh,

02:33:43.330 --> 02:33:45.090
Sachen damit machen, das heißt, man kriegt Sachen auch wirklich,

02:33:45.090 --> 02:33:47.470
wirklich schnell, ähm,

02:33:47.470 --> 02:33:49.090
ja, im Gegensatz

02:33:49.090 --> 02:33:51.070
von, zu Java, Java geht vielleicht auch, ich weiß

02:33:51.070 --> 02:33:52.930
es nicht genau, aber ich glaube, es ist ziemlich schwer, äh, Sachen

02:33:52.930 --> 02:33:55.170
wirklich optimiert hinzukriegen,

02:33:55.170 --> 02:33:56.810
äh, während in Python ist es halt

02:33:56.810 --> 02:33:58.570
relativ leicht, äh, irgendwie

02:33:58.570 --> 02:34:00.930
mit, mit Saiten halt ein Dialekt von

02:34:00.930 --> 02:34:03.070
Python zu schreiben, wo man dann Typ-Annotationen dazu schreibt,

02:34:03.070 --> 02:34:05.010
äh, wo dann, die dann halt

02:34:05.010 --> 02:34:06.830
zu C kompiliert werden, dann wird das als C-Modul, dann wird's

02:34:06.830 --> 02:34:08.850
wieder reimportiert und, äh, das kann man

02:34:08.890 --> 02:34:10.790
halt auch auf den Cluster irgendwie

02:34:10.790 --> 02:34:12.610
ausrollen, irgendwie über PySpark

02:34:12.610 --> 02:34:14.870
und dass man jetzt irgendwie C-Code

02:34:14.870 --> 02:34:16.830
irgendwie in Java reinbastelt

02:34:16.830 --> 02:34:18.850
und das dann halt über Hadoop, über die MapReduce-Shows

02:34:18.850 --> 02:34:20.870
verteilt, weiß ich nicht, kann auch sein, dass das geht, keine Ahnung,

02:34:20.870 --> 02:34:22.130
aber das klingt irgendwie nicht so leicht.

02:34:22.130 --> 02:34:24.770
Ja, wie auch immer, also,

02:34:24.770 --> 02:34:26.850
ähm, Spark ist auf jeden Fall auch

02:34:26.850 --> 02:34:28.790
noch eine super interessante Geschichte, vor allen Dingen, wenn es jetzt

02:34:28.790 --> 02:34:30.830
darum geht, wenn man jetzt sowas hat wie so ein Data Lake

02:34:30.830 --> 02:34:32.170
und so, wie kommen da die Informationen rein,

02:34:32.170 --> 02:34:34.890
man möchte eigentlich nicht, ähm,

02:34:34.890 --> 02:34:36.890
äh, da so ETL-Jobs

02:34:36.890 --> 02:34:38.770
machen, das funktioniert alles nicht mehr, man möchte ja auch echt

02:34:38.770 --> 02:34:40.270
Zeit-Dashboards haben, irgendwie.

02:34:40.270 --> 02:34:42.970
Äh, und

02:34:42.970 --> 02:34:44.830
dann muss man halt auf so eine, oder

02:34:44.830 --> 02:34:46.690
sollte man, dann wechselt man halt irgendwann

02:34:46.690 --> 02:34:48.690
auf so eine Streaming-Architektur, wo halt, äh,

02:34:48.690 --> 02:34:50.770
Dinge auf der Webseite, also auch gerade

02:34:50.770 --> 02:34:52.690
wenn man jetzt sowas hat wie, also

02:34:52.690 --> 02:34:54.750
auch Amazon wird, selbst wenn man die Bestellungen nimmt

02:34:54.750 --> 02:34:56.850
oder so, das ist alles noch nicht Big Data, aber

02:34:56.850 --> 02:34:58.690
wenn jetzt zum Beispiel Amazon, und das tun sie

02:34:58.690 --> 02:35:00.910
bestimmt, äh, irgendwie jeden Klick den User

02:35:00.910 --> 02:35:03.150
macht auf der Webseite, auch, äh,

02:35:03.150 --> 02:35:04.890
irgendwo, irgendwo eine, äh,

02:35:04.890 --> 02:35:06.550
Fakten-Tabelle, äh,

02:35:06.550 --> 02:35:08.330
in ihr Data Warehouse, Data Lake,

02:35:08.650 --> 02:35:09.830
Ding reinspeichern möchte,

02:35:09.830 --> 02:35:11.750
ja, dann

02:35:11.750 --> 02:35:14.290
wird das Big, weil das ist halt schon

02:35:14.290 --> 02:35:16.450
viel, dann ist so, so Verhältnis von Bestellungen

02:35:16.450 --> 02:35:18.450
zu, Leute machen irgendwie Web-Requests

02:35:18.450 --> 02:35:20.090
oder klicken auf der Seite rum, ist halt wahrscheinlich nochmal so

02:35:20.090 --> 02:35:22.350
100, Faktor 100 oder mehr.

02:35:23.110 --> 02:35:23.310
Und

02:35:23.310 --> 02:35:26.650
ja, dann wird es tatsächlich sehr, sehr groß

02:35:26.650 --> 02:35:28.450
und man möchte das aber trotzdem

02:35:28.450 --> 02:35:30.330
alles in Echtzeit haben. Das heißt,

02:35:30.330 --> 02:35:31.770
man macht es nicht so, dass man

02:35:31.770 --> 02:35:33.410
diese Geschichten wieder in die

02:35:33.410 --> 02:35:36.450
OTP-Datenbank reinschreibt

02:35:36.450 --> 02:35:38.390
und dann extrahiert und batchmäßig

02:35:38.390 --> 02:35:40.530
jeden Tag ein Analysesystem schreibt,

02:35:40.530 --> 02:35:42.550
sondern dann generiert man

02:35:42.550 --> 02:35:43.750
halt so Events,

02:35:43.750 --> 02:35:46.350
die dann halt über irgendeinen

02:35:46.350 --> 02:35:47.810
Streaming

02:35:47.810 --> 02:35:49.690
Zeugs halt

02:35:49.690 --> 02:35:52.550
Service laufen,

02:35:52.550 --> 02:35:53.930
der das dann halt

02:35:53.930 --> 02:35:55.790
an unterschiedliche Consumer

02:35:55.790 --> 02:35:57.890
irgendwie ausliefert. Und das sind meistens Kafka,

02:35:57.890 --> 02:35:59.970
AWS hat noch eine eigene Lösung,

02:35:59.970 --> 02:36:01.810
normalerweise auch wieder den Namen vergessen.

02:36:01.810 --> 02:36:04.270
Meint aber nicht die Lambda-Service, ist das was anderes?

02:36:04.270 --> 02:36:05.690
Nee, nee, das ist was anderes.

02:36:05.690 --> 02:36:08.070
Nee, das ist eine eigene, ja, aber

02:36:08.070 --> 02:36:10.230
sagen wir mal, Kafka als Beispiel ist auch ein

02:36:10.230 --> 02:36:12.090
Apache-Projekt, das das halt sehr schön macht.

02:36:12.090 --> 02:36:13.830
Und dann serialisiert man halt

02:36:13.830 --> 02:36:15.430
irgendwie die Daten, die man im Event hat,

02:36:15.430 --> 02:36:18.030
als Protokoll-Buffers oder sowas.

02:36:18.030 --> 02:36:19.670
Und

02:36:19.670 --> 02:36:21.330
dann gehen die Dinger halt

02:36:21.330 --> 02:36:23.710
auch da wiederum Serialisierungsformate sehr, also

02:36:23.710 --> 02:36:25.950
es gibt halt sehr unterschiedliche Protokoll-Buffers

02:36:25.950 --> 02:36:27.730
sind super, wenn man Daten übertragen möchte oder auch dieses

02:36:27.730 --> 02:36:29.150
Thrift von Facebook.

02:36:29.150 --> 02:36:31.810
Super scheiße, wenn man das halt auf die Platte

02:36:31.810 --> 02:36:33.390
schreibt. Also es wäre halt dann auch wieder

02:36:33.390 --> 02:36:35.290
zeilenbasiert, kann man hinterher nicht mehr gut analysieren. Also

02:36:35.290 --> 02:36:37.510
man kann halt nicht einfach irgendwie

02:36:37.510 --> 02:36:39.410
die Events, die man generiert als

02:36:39.410 --> 02:36:40.690
Protokoll-Buffers irgendwie

02:36:40.690 --> 02:36:43.630
in Kafka kippen und dann das

02:36:43.630 --> 02:36:44.850
irgendwo auf eine Platte schreiben lassen.

02:36:44.850 --> 02:36:47.650
Das reicht halt nicht, sondern man muss

02:36:47.650 --> 02:36:49.370
es halt dann doch auch irgendwie wieder

02:36:49.370 --> 02:36:51.510
irgendwie so Zwischendinge kippen.

02:36:51.510 --> 02:36:53.390
Aber man kann halt auch, man kann halt etwas haben,

02:36:53.390 --> 02:36:54.990
was halt teilweise aus

02:36:54.990 --> 02:36:56.790
diesen Parquet-Files liest.

02:36:56.790 --> 02:36:59.550
Und dann halt die aktuellsten Daten liest es halt aus

02:36:59.550 --> 02:37:00.610
einem Log der

02:37:00.610 --> 02:37:03.310
der Protokoll-Buffer-Events.

02:37:03.310 --> 02:37:05.470
Weil das muss ja dann vielleicht nur für die letzte

02:37:05.470 --> 02:37:07.350
halbe Stunde sein oder so. Kommt halt mal drauf an.

02:37:07.350 --> 02:37:09.590
Ja, und dann kann man

02:37:09.590 --> 02:37:10.950
halt tatsächlich Echtzeit-Daten sehen.

02:37:10.950 --> 02:37:12.690
Dann könnte man halt ein Dashboard machen, wo man halt

02:37:12.690 --> 02:37:15.570
in Echtzeit sieht, wie sich

02:37:15.570 --> 02:37:17.230
die Zugriffsmuster ändern, wenn man jetzt zum Beispiel

02:37:17.230 --> 02:37:19.330
für einen bestimmten Teil der User irgendwie die Webseite

02:37:19.330 --> 02:37:21.330
ändert oder so. Und das ist natürlich

02:37:21.330 --> 02:37:23.270
schon sehr nett. Und wenn man halt irgendwie Preise

02:37:23.270 --> 02:37:25.210
erhöht, dann sieht man halt irgendwie in Echtzeit, wie

02:37:25.210 --> 02:37:26.330
die Conversion runtergeht.

02:37:26.330 --> 02:37:32.030
Ja, und dann kann man halt so

02:37:32.030 --> 02:37:33.710
als Manager

02:37:33.710 --> 02:37:35.270
vor diesem Dashboard sitzen

02:37:35.270 --> 02:37:36.050
und den Köpfen drehen.

02:37:36.050 --> 02:37:38.330
Die kommen auch vor die Wand fahren.

02:37:38.330 --> 02:37:41.050
Ja, und dann irgendwie Profit

02:37:41.050 --> 02:37:41.690
maximieren.

02:37:41.690 --> 02:37:45.270
Das ist schon

02:37:45.270 --> 02:37:46.690
sehr nett. Ist aber auch halt sehr aufwendig.

02:37:46.690 --> 02:37:49.290
Das macht alles nochmal

02:37:49.290 --> 02:37:50.070
viel komplizierter.

02:37:50.070 --> 02:37:53.090
Ja, und

02:37:53.090 --> 02:37:55.110
diese Serialisierungsformat-Geschichte

02:37:55.110 --> 02:37:55.730
ist halt sehr wichtig.

02:37:55.730 --> 02:37:58.090
Etwas, was mir bei dem

02:37:58.090 --> 02:38:00.750
Hadoop-Erfahrung

02:38:00.750 --> 02:38:02.850
dann geholfen hat, war

02:38:02.850 --> 02:38:05.110
ein Projekt namens

02:38:05.110 --> 02:38:05.750
Apache Arrow,

02:38:05.750 --> 02:38:09.230
wo es darum geht,

02:38:09.230 --> 02:38:10.950
das ist von dem

02:38:10.950 --> 02:38:13.390
ursprünglichen Autor von

02:38:13.390 --> 02:38:15.070
Pandas, also dieser DataFrame

02:38:15.070 --> 02:38:17.290
Library für Python,

02:38:19.250 --> 02:38:20.750
und der hat das gestartet,

02:38:20.750 --> 02:38:23.090
weil der da halt ein...

02:38:23.090 --> 02:38:24.550
Und das ist auch tatsächlich...

02:38:24.550 --> 02:38:26.830
Während ich mich halt mit Hadoop gestellt habe,

02:38:26.830 --> 02:38:28.950
mich hat es an den gleichen Stellen gejuckt,

02:38:28.950 --> 02:38:29.350
sozusagen.

02:38:29.350 --> 02:38:31.690
Das hat er zuerst gemacht.

02:38:31.690 --> 02:38:32.810
Also ihn hat das wohl auch irgendwie

02:38:32.810 --> 02:38:34.970
genervt. Der hat bei Cloudera gearbeitet.

02:38:34.970 --> 02:38:36.430
Das ist halt auch so eine von diesen

02:38:36.430 --> 02:38:39.190
Firmen, die halt so in diesem

02:38:39.190 --> 02:38:41.410
Big Data, Hadoop-Bereich viel unterwegs sind.

02:38:41.410 --> 02:38:42.870
Auch da, glaube ich, einer von den

02:38:42.870 --> 02:38:45.410
Chefs oder Gründern ist halt einer von den...

02:38:45.410 --> 02:38:46.570
Auch ein PhD-Student von

02:38:46.570 --> 02:38:47.690
Michael Stonebraker.

02:38:47.690 --> 02:38:49.050
Das sind also irgendwie immer die

02:38:49.050 --> 02:38:49.450
leitenden Leute.

02:38:49.450 --> 02:38:53.450
Und...

02:38:53.450 --> 02:38:55.650
Genau. Da ging es darum,

02:38:55.650 --> 02:38:56.910
sozusagen ein

02:38:56.910 --> 02:38:59.210
Interface zu haben, das genauso ist

02:38:59.210 --> 02:39:00.730
wie Pandas, also

02:39:00.730 --> 02:39:02.870
DataFrame-API quasi zu haben,

02:39:02.870 --> 02:39:04.670
sodass man halt Dinge...

02:39:04.670 --> 02:39:06.550
Man hat so das Gefühl, man hat ein DataFrame-Objekt,

02:39:06.550 --> 02:39:09.590
macht da irgendwelche Sachen drauf, so als wäre es ein Pandas-DataFrame.

02:39:09.590 --> 02:39:11.230
Aber in Wirklichkeit passieren

02:39:11.230 --> 02:39:13.170
im Hintergrund Sachen

02:39:13.170 --> 02:39:15.010
auf deinem Cluster. Das war eine Bibliothek,

02:39:15.010 --> 02:39:16.870
nannte sich Ibis, und das ist halt genauso auch

02:39:16.870 --> 02:39:18.850
mein Problem damit, dass halt

02:39:18.850 --> 02:39:20.730
ich mache ja eigentlich eher so Machine-Learning

02:39:20.730 --> 02:39:22.610
Dinge und

02:39:22.610 --> 02:39:24.450
benutze Pandas

02:39:24.450 --> 02:39:26.410
eigentlich so zum Daten

02:39:26.410 --> 02:39:27.930
aufräumen, Daten transformieren,

02:39:27.930 --> 02:39:30.010
bevor ich das dann halt in irgendwie

02:39:30.010 --> 02:39:32.870
Machine-Learning-Aggregate und so und Modelle reinfüttere,

02:39:32.870 --> 02:39:34.370
die dann aber

02:39:34.370 --> 02:39:36.590
selber wieder nur Arrays, NumPy-Arrays

02:39:36.590 --> 02:39:38.870
normalerweise nehmen und keine DataFrames.

02:39:38.870 --> 02:39:40.550
Aber DataFrames ist halt so ein

02:39:40.550 --> 02:39:42.690
Zwischenschritt und man kann halt sehr leicht aus einem DataFrame

02:39:42.690 --> 02:39:44.690
irgendwie ein Array machen, indem man einfach sagt

02:39:44.690 --> 02:39:46.530
DataFrame.Values, dann hat man die...

02:39:46.530 --> 02:39:47.530
Das Array.

02:39:48.650 --> 02:39:50.770
Und ich hatte halt immer das Problem,

02:39:50.770 --> 02:39:52.630
wenn ich jetzt da mit so Systemen wie

02:39:52.630 --> 02:39:54.690
Hive oder Impala draufgegangen bin, dann kriege ich halt

02:39:54.690 --> 02:39:56.270
irgendwie eher so ein CSV

02:39:56.270 --> 02:39:58.650
oder so ein Result-Set und dann kriege ich

02:39:58.650 --> 02:39:59.570
das nicht schnell da raus.

02:39:59.570 --> 02:40:02.030
Das ist halt alles ultra langsam.

02:40:02.030 --> 02:40:04.550
Ich brauche aber für meine Modelle

02:40:04.550 --> 02:40:05.910
doch durchaus große Daten oft.

02:40:05.910 --> 02:40:07.570
Das geht alles nicht.

02:40:07.570 --> 02:40:10.850
Dann wäre das natürlich viel besser gewesen,

02:40:10.850 --> 02:40:12.930
wenn ich einfach nur...

02:40:12.930 --> 02:40:14.810
Das, was diese Systeme machen,

02:40:14.810 --> 02:40:16.750
ist, man schreibt SQL-Statements und die machen

02:40:16.750 --> 02:40:18.450
dann halt irgendwie automatisch...

02:40:18.450 --> 02:40:20.150
Machen die halt irgendwelche Aktionen auf dem Cluster.

02:40:20.150 --> 02:40:22.630
Wenn das jetzt so gewesen wäre, dass ich das

02:40:22.630 --> 02:40:24.770
einfach nur in DataFrame-Syntax, was ich mit den Daten

02:40:24.770 --> 02:40:26.230
machen wollte, hätte hinschreiben können,

02:40:26.230 --> 02:40:28.270
dann wäre mir ja schon viel geholfen gewesen.

02:40:28.270 --> 02:40:30.770
Und genau das hat halt IBIS,

02:40:30.770 --> 02:40:32.350
diese Bibliothek, die dann Wes McKenney bei

02:40:32.350 --> 02:40:33.970
Cloudera gebaut hat, gemacht.

02:40:33.970 --> 02:40:36.590
Man hatte ein Ding, das war wie ein

02:40:36.590 --> 02:40:38.310
Pandas-DataFrame, wo man da halt irgendwie

02:40:38.310 --> 02:40:40.750
GroupBy gesagt hat und dann hat das

02:40:40.750 --> 02:40:41.370
halt nicht

02:40:41.370 --> 02:40:44.490
das im Hauptspeicher gemacht wie Pandas, sondern das hat

02:40:44.490 --> 02:40:46.050
dann halt SQL-Statements erzeugt,

02:40:46.050 --> 02:40:48.250
automatisch, die man aber nicht gesehen hat, und die dann

02:40:48.250 --> 02:40:50.450
auf den

02:40:50.450 --> 02:40:52.630
Cluster irgendwie losgelassen

02:40:52.630 --> 02:40:53.670
und dann

02:40:53.670 --> 02:40:56.490
magisch irgendwie mit Ergebnissen

02:40:56.490 --> 02:40:56.930
irgendwas gemacht.

02:40:56.930 --> 02:41:00.550
Ja, aber das hat halt auch nicht gereicht, weil

02:41:00.550 --> 02:41:02.510
auch da wieder das Problem war, wie kriegt man die Daten wieder

02:41:02.510 --> 02:41:04.450
raus, wenn man jetzt, man kann eben sowas

02:41:04.450 --> 02:41:06.590
nicht sagen, wie wenn man es jetzt richtig transformiert

02:41:06.590 --> 02:41:08.110
hat, also da war das schon eine Hilfe, aber

02:41:08.110 --> 02:41:10.330
jetzt hätte man gerne die Werte, um sie tatsächlich in

02:41:10.330 --> 02:41:12.870
Machine Learning-Algorithmus reinzupumpen,

02:41:12.870 --> 02:41:14.450
damit er möchte irgendwie ein Modell

02:41:14.450 --> 02:41:16.390
drauf trainieren. Und man kann eben jetzt bei diesem

02:41:16.390 --> 02:41:17.310
DataFrame eben nicht sagen,

02:41:18.050 --> 02:41:20.110
df.values, das geht halt nicht, weil

02:41:20.110 --> 02:41:22.110
die Daten sind halt im Cluster, weil

02:41:22.110 --> 02:41:23.970
sie da irgendwie rauskriegen und man kriegt die nicht raus,

02:41:23.970 --> 02:41:26.070
das geht nicht. Also der Weg von

02:41:26.070 --> 02:41:26.890
ja,

02:41:26.890 --> 02:41:29.710
ja, und das war halt dann auch

02:41:29.710 --> 02:41:32.330
irgendwie ein Problem, wo dann das IBIS-Projekt

02:41:32.330 --> 02:41:33.690
so ein bisschen dann vorbei war

02:41:33.690 --> 02:41:36.070
und, weißt du, Kenny hat dann auch

02:41:36.070 --> 02:41:38.050
von Cloudera irgendwie weg und hat

02:41:38.050 --> 02:41:40.050
dann Apache Arrow gestartet und Apache Arrow

02:41:40.050 --> 02:41:40.750
macht halt genau

02:41:40.750 --> 02:41:43.950
da weiter und das hat mir dann auch wieder

02:41:43.950 --> 02:41:45.410
weitergeholfen, weil

02:41:45.410 --> 02:41:47.850
okay, das geht

02:41:47.850 --> 02:41:49.510
nicht anders, man muss tatsächlich auf die rohen

02:41:49.510 --> 02:41:51.990
Parquet-Files im Cluster irgendwie zugreifen

02:41:51.990 --> 02:41:53.910
und

02:41:53.910 --> 02:41:55.990
wenn man jetzt irgendwie da drauf was machen möchte,

02:41:55.990 --> 02:41:58.150
man braucht irgendwie ein Array-mäßiges

02:41:58.150 --> 02:41:59.970
Interface auf diese

02:41:59.970 --> 02:42:01.850
Files. Wenn man das hat, dann ist man

02:42:01.850 --> 02:42:03.370
eigentlich im Grunde, dann funktioniert alles.

02:42:03.370 --> 02:42:05.630
Und das macht Arrow. Arrow

02:42:05.630 --> 02:42:08.070
ist halt sozusagen ein In-Memory

02:42:08.070 --> 02:42:10.130
Datenstruktur, Array-Datenstruktur,

02:42:10.130 --> 02:42:11.750
die halt von

02:42:11.750 --> 02:42:13.730
unterschiedlichen, das ist auch das Ziel dabei, ist auch eine

02:42:13.730 --> 02:42:15.190
Kollaboration mit irgendwie einem der

02:42:15.190 --> 02:42:17.810
wichtigeren Leute, die hinter R,

02:42:17.810 --> 02:42:18.930
oder R-Studio

02:42:18.930 --> 02:42:20.170
zusammen,

02:42:20.170 --> 02:42:23.750
die haben das beide zusammen gemacht, dieses Projekt

02:42:23.750 --> 02:42:24.470
und

02:42:24.470 --> 02:42:27.910
genau, die Idee

02:42:27.910 --> 02:42:29.350
ist sozusagen, du hast halt eine

02:42:29.350 --> 02:42:31.310
Abstraktionsschicht, die halt

02:42:31.310 --> 02:42:33.710
irgendwie so ein Arrays-Thor im Hauptspeicher hält,

02:42:33.710 --> 02:42:35.510
das macht Apache Arrow,

02:42:35.510 --> 02:42:37.770
deswegen ist ein C++ geschrieben, aber du kannst

02:42:37.770 --> 02:42:39.430
halt von Python aus zugreifen, von R drauf

02:42:39.430 --> 02:42:41.710
zugreifen, von Java aus

02:42:41.710 --> 02:42:43.630
und du musst es halt nur einmal

02:42:43.630 --> 02:42:45.730
im Hauptspeicher halten und du hast

02:42:45.730 --> 02:42:47.690
es dann halt in dem Format, in dem du es brauchst, um es

02:42:47.690 --> 02:42:49.590
halt in Machine Learning-Modelle reinzupumpen.

02:42:49.590 --> 02:42:51.490
Ja, was du halt

02:42:51.490 --> 02:42:53.210
diese ganze Loop-Welt,

02:42:53.210 --> 02:42:55.230
kannst du dein Machine Learning-Algorithmus ja nicht als

02:42:55.230 --> 02:42:57.290
MapReduce, das geht halt nicht, schreiben, weil

02:42:57.290 --> 02:42:59.510
wenn du ein neuronales Netz hast, das hat Verbindungen

02:42:59.510 --> 02:43:01.510
überall hin, da kannst du es halt nicht

02:43:01.510 --> 02:43:03.470
klar horizontal auftreiben in

02:43:03.470 --> 02:43:05.590
Mapper und Reducer, das funktioniert einfach nicht, das ist halt Quatsch.

02:43:05.590 --> 02:43:07.210
Viele, oder auch

02:43:07.210 --> 02:43:09.450
viele Machine Learning-Algorithmen lassen sich nicht

02:43:09.450 --> 02:43:11.290
einfach so verteilen. Oder

02:43:11.290 --> 02:43:13.290
ja, sie brauchen halt irgendwie

02:43:13.290 --> 02:43:15.730
ihre Daten in einem bestimmten Format und das ist halt so ein Array-Format,

02:43:15.730 --> 02:43:17.210
weil das ist alles lineare Algebra,

02:43:17.570 --> 02:43:19.230
und lineare Algebra funktioniert

02:43:19.230 --> 02:43:21.230
mit Vektoren, Matrizen, oder

02:43:21.230 --> 02:43:23.570
halt, man nennt die Dinger allgemein

02:43:23.570 --> 02:43:25.330
Arrays halt, also

02:43:25.330 --> 02:43:26.830
beliebig dimensionale Arrays.

02:43:26.830 --> 02:43:29.470
Ja,

02:43:29.470 --> 02:43:31.290
und das

02:43:31.290 --> 02:43:33.090
geht halt so einfach eigentlich irgendwie nicht.

02:43:33.090 --> 02:43:34.230
Und

02:43:34.230 --> 02:43:37.270
ja, mit Apache Arrow halt

02:43:37.270 --> 02:43:39.270
schon. Und außerdem macht Apache

02:43:39.270 --> 02:43:41.290
Arrow dann halt so ein paar Sachen wieder, zieht es wieder gerade,

02:43:41.290 --> 02:43:42.850
die halt bei NumPy so ein bisschen kaputt sind.

02:43:42.850 --> 02:43:45.010
Unter anderem,

02:43:45.010 --> 02:43:47.430
was halt total blöd ist, ist halt, aber das habe ich

02:43:47.450 --> 02:43:48.990
auch schon mal erwähnt, dass es halt kein

02:43:48.990 --> 02:43:51.290
Kanal für Integer gibt und so,

02:43:51.290 --> 02:43:53.070
also mit Missing Values ist halt schwer

02:43:53.070 --> 02:43:54.950
bei NumPy Arrays.

02:43:54.950 --> 02:43:56.090
Und

02:43:56.090 --> 02:43:59.350
ja, es gibt ja noch diverse andere Probleme.

02:43:59.350 --> 02:44:01.490
Und ja,

02:44:01.490 --> 02:44:03.250
das klingt eigentlich super interessant und ich glaube,

02:44:03.250 --> 02:44:05.030
das ist halt auch so ein bisschen der Weg in die Zukunft, weil

02:44:05.030 --> 02:44:06.130
dieser ganze

02:44:06.130 --> 02:44:09.350
Business Intelligence-Bereich, also ich habe oft irgendwie mit

02:44:09.350 --> 02:44:11.330
so Business Intelligence-Abteilungen

02:44:11.330 --> 02:44:13.330
auch zu tun gehabt, in denen

02:44:13.330 --> 02:44:15.050
dann so, an die wurde dann immer so

02:44:15.050 --> 02:44:17.330
Datasites und Machine Learning irgendwie so angedockt. Ja, also das

02:44:17.330 --> 02:44:19.090
ist halt, Business Intelligence ist etwas, was halt

02:44:19.090 --> 02:44:20.390
große Firmen halt schon lange haben.

02:44:20.390 --> 02:44:23.290
Aber die machen

02:44:23.290 --> 02:44:25.010
halt sowas wie, ja, also einmal

02:44:25.010 --> 02:44:27.030
die Leute, die dann Dinge da machen, sind da so

02:44:27.030 --> 02:44:27.530
Analysten.

02:44:27.530 --> 02:44:30.390
Oft super schlaue Leute.

02:44:30.390 --> 02:44:32.990
Aber

02:44:32.990 --> 02:44:39.510
ich überlege gerade, wie man

02:44:39.510 --> 02:44:40.250
da hinfühlen kann.

02:44:40.250 --> 02:44:44.790
Sagen wir mal so, was die halt tun können.

02:44:44.790 --> 02:44:47.130
Nehmen wir an, du bist Walmart und du

02:44:47.130 --> 02:44:49.090
interessierst dich jetzt dafür, keine Ahnung,

02:44:49.090 --> 02:44:51.290
weißt jetzt, es kommt eine Flut,

02:44:51.290 --> 02:44:52.930
die irgendwie deine Stadt

02:44:52.930 --> 02:44:55.130
überschwemmen wird und dann

02:44:55.130 --> 02:44:57.010
was werden die Leute

02:44:57.010 --> 02:44:57.870
dann kaufen oder so.

02:44:57.870 --> 02:45:01.010
Für was musst du

02:45:01.010 --> 02:45:02.890
irgendwie vorsorgen? Und

02:45:02.890 --> 02:45:04.990
bei einem klassischen BI-Ansatz

02:45:04.990 --> 02:45:06.910
wäre halt, du guckst dir halt die Icons da an, wo

02:45:06.910 --> 02:45:08.610
Städte überflutet worden sind, da gibt es nicht so viele.

02:45:08.610 --> 02:45:11.470
Substrahierst

02:45:11.470 --> 02:45:12.930
da halt irgendwie so, guckst dir das halt

02:45:12.930 --> 02:45:14.270
eine Woche später an

02:45:14.270 --> 02:45:16.770
und überlegst dir dann halt irgendwas.

02:45:16.770 --> 02:45:16.930
Und das,

02:45:16.930 --> 02:45:18.590
und das machst du dann. Und dann machst du

02:45:18.590 --> 02:45:20.290
irgendwie gewisse Voraussagen und sagst so,

02:45:20.290 --> 02:45:21.730
das könnte ungefähr so und so aussehen.

02:45:21.730 --> 02:45:24.570
Das ist halt das, was passiert. Und das ist halt auch das, was

02:45:24.570 --> 02:45:26.490
heute noch in BI-Abteilungen hauptsächlich passiert,

02:45:26.490 --> 02:45:28.570
dass die Leute halt irgendwie so historische Daten angucken und dann so

02:45:28.570 --> 02:45:29.010
überlegen so.

02:45:29.010 --> 02:45:32.790
Und ich denke,

02:45:32.790 --> 02:45:34.710
das wird alles

02:45:34.710 --> 02:45:36.570
so in Zukunft eher Richtung Data Science

02:45:36.570 --> 02:45:36.870
laufen.

02:45:36.870 --> 02:45:39.590
Damit meine ich, dass

02:45:39.590 --> 02:45:42.750
solche Antworten kommen halt dann eher von Systemen,

02:45:42.750 --> 02:45:44.390
die Vorhersagen machen.

02:45:44.390 --> 02:45:46.490
Und

02:45:46.490 --> 02:45:48.190
die werden das deutlich besser können.

02:45:48.190 --> 02:45:51.090
Und die werden das halt auch,

02:45:51.090 --> 02:45:53.930
also ein Großteil dieser Analysegeschichte

02:45:53.930 --> 02:45:55.050
wird man halt automatisieren können.

02:45:55.050 --> 02:45:58.050
Und das Problem momentan ist halt so ein bisschen,

02:45:58.050 --> 02:45:59.970
dass die Tools,

02:45:59.970 --> 02:46:01.490
die man hat, nicht zueinander passen.

02:46:01.490 --> 02:46:03.210
Zu dem, die

02:46:03.210 --> 02:46:05.530
so Hadoop-Welt

02:46:05.530 --> 02:46:07.550
passt eigentlich eher so zu dem klassischen

02:46:07.550 --> 02:46:08.130
BI-Ansatz.

02:46:08.130 --> 02:46:11.610
Und was auch bei diesem

02:46:11.610 --> 02:46:13.610
BI-Ansatz ein Problem ist, ist halt, dass man das nicht wirklich

02:46:13.610 --> 02:46:15.230
wieder zurück in Produkte übersetzen kann.

02:46:15.230 --> 02:46:16.050
Also das sind auch,

02:46:16.290 --> 02:46:18.270
Leute nicht, nicht unbedingt Leute, die halt

02:46:18.270 --> 02:46:20.230
dann Produkte bauen können, die halt entwickeln können oder

02:46:20.230 --> 02:46:22.270
Services bauen können. Auch mit

02:46:22.270 --> 02:46:24.210
diesem ganzen, wie baut man Dinge,

02:46:24.210 --> 02:46:26.090
wie macht man Produktentwicklung?

02:46:26.090 --> 02:46:28.330
Nicht so, das ist nicht so was, was natürlich

02:46:28.330 --> 02:46:30.310
für die ist, sondern das ist halt eher so etwas, was sie dann

02:46:30.310 --> 02:46:32.330
halt auch machen müssen vielleicht,

02:46:32.330 --> 02:46:34.290
aber wo sie sich halt auch nicht so gut bei fühlen.

02:46:34.290 --> 02:46:36.210
Das aber halt

02:46:36.210 --> 02:46:38.250
absolut erforderlich ist, weil viele von den Sachen sollen

02:46:38.250 --> 02:46:40.310
ja dann automatisch auch Dinge tatsächlich tun.

02:46:40.310 --> 02:46:42.310
Ja, so viele Ergebnisse, die dann

02:46:42.310 --> 02:46:44.110
halt automatisch generiert werden, sollen halt nicht dazu führen,

02:46:44.110 --> 02:46:46.170
dass es halt irgendwie eine nette Präsentation irgendwie

02:46:46.170 --> 02:46:47.970
an einen Management-Layer gibt oder so.

02:46:47.970 --> 02:46:50.090
Sondern du willst halt, dass dann

02:46:50.090 --> 02:46:52.170
da tatsächlich

02:46:52.170 --> 02:46:54.030
Entscheidungen auch rausfallen, die irgendwas auf deiner

02:46:54.030 --> 02:46:56.010
Webseite verändern oder die irgendwelche Dinge tun.

02:46:56.010 --> 02:46:58.230
Und dann musst

02:46:58.230 --> 02:47:00.070
du halt Software entwickeln eigentlich. Dann bist du halt

02:47:00.070 --> 02:47:01.850
so Teil der Produktentwicklung.

02:47:01.850 --> 02:47:04.110
Und ja, das

02:47:04.110 --> 02:47:05.990
geht halt auch nicht so richtig gut. Und was

02:47:05.990 --> 02:47:08.110
da ein bisschen fehlt, ist halt so ein

02:47:08.110 --> 02:47:11.590
ist halt etwas, was halt

02:47:11.590 --> 02:47:14.210
Daten in Array-Form im Hauptspeicher hält.

02:47:14.210 --> 02:47:16.050
Und das

02:47:16.050 --> 02:47:18.010
macht Apache Arrow. Und deswegen finde ich das Projekt so

02:47:18.010 --> 02:47:20.050
superinteressant. Es gibt da noch

02:47:20.050 --> 02:47:21.770
SciDB oder sowas.

02:47:21.770 --> 02:47:23.990
Ob ich die auch sowas ähnliches machen?

02:47:23.990 --> 02:47:25.390
Aber da geht's irgendwie hin.

02:47:25.390 --> 02:47:27.910
Und ja, es geht Richtung

02:47:27.910 --> 02:47:30.210
Streaming. Spark macht ja auch ganz viel mit Streaming.

02:47:30.210 --> 02:47:32.090
Wobei mich natürlich besonders

02:47:32.090 --> 02:47:33.970
interessiert PySpark, weil Python und so.

02:47:33.970 --> 02:47:35.770
Ja.

02:47:35.770 --> 02:47:42.030
Haben wir da noch

02:47:42.030 --> 02:47:43.570
Irgendwann. Ich wollte schon fragen. Wir haben jetzt

02:47:43.570 --> 02:47:45.990
ganz lange schon, also fast drei

02:47:45.990 --> 02:47:47.650
Stunden schon über die ganzen Daten gesagt.

02:47:47.650 --> 02:47:49.130
Wir merken, der Jochen ist ja sehr tief drin.

02:47:49.130 --> 02:47:51.890
Das ist auch ein super breites Thema.

02:47:51.890 --> 02:47:53.710
Haben wir tatsächlich die

02:47:53.710 --> 02:47:55.750
meisten Sachen schon jetzt durch? Oder hast du noch was,

02:47:55.750 --> 02:47:57.330
was du unbedingt da zu dem Thema gespeichert hast?

02:47:57.330 --> 02:47:58.030
Genau, genau, genau.

02:47:58.030 --> 02:48:01.690
Ach so, ah, genau. Wenn wir jetzt nochmal zurückkommen zu dem

02:48:01.690 --> 02:48:03.290
E-Commerce-Ding. Das war jetzt so eine Exkurs Richtung

02:48:03.290 --> 02:48:05.810
Big Data. Also wenn wir ganz froh sind.

02:48:05.810 --> 02:48:07.770
Das neue Thema. Immer so

02:48:07.770 --> 02:48:09.850
Mars oder so. Ja, also das hatten wir

02:48:09.850 --> 02:48:11.150
auch vorher schon mal kurz angekündigt.

02:48:11.150 --> 02:48:13.870
Relationale Datenbanken oder so. Diese Art

02:48:13.870 --> 02:48:15.830
Daten umzugehen ist halt besonders gut.

02:48:15.870 --> 02:48:17.190
Und dann, wenn es Daten über

02:48:17.190 --> 02:48:18.870
Sachen sind, die nicht Daten sind. Also

02:48:18.870 --> 02:48:21.690
physikalische Sachen, die sich nicht so schnell ändern,

02:48:21.690 --> 02:48:23.730
bei denen es Sinn macht,

02:48:23.730 --> 02:48:25.790
ein festes Schema zu definieren, das dann halt auch über längere

02:48:25.790 --> 02:48:27.610
Zeit mehr oder weniger gleich bleiben kann. Man kann natürlich

02:48:27.610 --> 02:48:29.550
Sachen ändern, aber Dinge grundsätzlich

02:48:29.550 --> 02:48:31.110
ändern, ist dann schwierig.

02:48:31.110 --> 02:48:33.510
Und

02:48:33.510 --> 02:48:34.310
aber

02:48:34.310 --> 02:48:37.710
das ist jetzt tatsächlich Zukunft.

02:48:37.710 --> 02:48:39.770
Es ist auch nicht so richtig sinnvoll, diese Amazon

02:48:39.770 --> 02:48:41.450
Geschichte, also heute Amazon zu bauen,

02:48:41.450 --> 02:48:43.810
ist viel, viel einfacher natürlich. Also ich meine,

02:48:43.810 --> 02:48:45.750
das hört sich so an, als wäre es total einfach, Amazon zu

02:48:45.750 --> 02:48:47.750
werden. Das ist es

02:48:47.750 --> 02:48:47.930
nicht.

02:48:47.930 --> 02:48:51.570
Es war auch zu der Zeit, als Amazon

02:48:51.570 --> 02:48:53.490
Amazon geworden ist, war es viel schwieriger, weil da

02:48:53.490 --> 02:48:55.410
gab es halt keine Tools. So was wie Postgres

02:48:55.410 --> 02:48:57.190
gab es, aber es war

02:48:57.190 --> 02:48:58.850
nicht in dem

02:48:58.850 --> 02:49:03.390
Zustand, wie heute.

02:49:03.390 --> 02:49:04.750
Es wäre nicht nutzbar gewesen.

02:49:04.750 --> 02:49:07.410
Also es gab damals, als

02:49:07.410 --> 02:49:09.570
ich weiß nicht wann die angefangen haben, Anfang der 90er oder

02:49:09.570 --> 02:49:11.570
also Amazon hat sehr, sehr früh angefangen,

02:49:11.570 --> 02:49:12.810
Mitte der 90er, ich weiß nicht genau.

02:49:12.810 --> 02:49:15.630
Da gab es halt nichts. Die mussten

02:49:15.630 --> 02:49:17.450
alle selber bauen. Das war, ist natürlich

02:49:17.450 --> 02:49:18.390
nochmal ein ganz anderes Problem.

02:49:18.390 --> 02:49:21.410
Während heute man wahrscheinlich mit Postgres,

02:49:21.410 --> 02:49:23.470
Django, Redis, irgendwie

02:49:23.470 --> 02:49:25.370
und ein paar Rechnern wahrscheinlich einen Markt wie

02:49:25.370 --> 02:49:27.390
Deutschland mit so einer ähnlichen Seite

02:49:27.390 --> 02:49:29.230
wie Amazon versorgen könnte.

02:49:29.230 --> 02:49:31.010
Das

02:49:31.010 --> 02:49:33.110
ging halt damals nicht und das

02:49:33.110 --> 02:49:35.390
macht es heute einem natürlich viel leichter.

02:49:35.390 --> 02:49:37.050
Aber heute ist halt das Problem, es gibt Amazon schon.

02:49:37.050 --> 02:49:38.990
Man muss mit Amazon konkurrieren und

02:49:38.990 --> 02:49:40.570
leider hat man da keine Chance.

02:49:40.570 --> 02:49:42.830
Deswegen funktioniert das auch nicht.

02:49:42.830 --> 02:49:45.570
Aber was natürlich interessant möglicherweise ist,

02:49:45.570 --> 02:49:47.050
ist sich zu überlegen,

02:49:47.050 --> 02:49:49.430
okay, was kann Amazon denn mit dem, was sie tun,

02:49:49.430 --> 02:49:51.830
nicht machen und wo entwickelt sich das halt in Zukunft hin?

02:49:51.830 --> 02:49:52.890
Ich habe

02:49:52.890 --> 02:49:55.390
das auch schon wieder zehn Jahre her, unglaublich,

02:49:55.390 --> 02:49:56.610
oder noch mehr als zehn Jahre sogar.

02:49:56.610 --> 02:49:59.330
Mein Vortrag gehört

02:49:59.330 --> 02:50:01.430
von David Weinberger, der ist

02:50:01.430 --> 02:50:02.950
ein Philosoph,

02:50:02.950 --> 02:50:05.170
auf Internetgeschichten

02:50:05.170 --> 02:50:06.270
beschäftigt in Harvard.

02:50:06.270 --> 02:50:09.310
Kann man mal gucken, packe ich auch noch in die Shownotes.

02:50:09.310 --> 02:50:13.290
Der Vortrag heißt Everything is Miscellaneous.

02:50:13.290 --> 02:50:15.330
Da gibt es auch ein Buch zu.

02:50:15.570 --> 02:50:18.390
Der Talk bei Google

02:50:18.390 --> 02:50:19.470
ist halt eine Vorstellung

02:50:19.470 --> 02:50:21.430
von dem Buchinhalt, mehr oder weniger,

02:50:21.430 --> 02:50:23.690
wo er darüber spricht,

02:50:23.690 --> 02:50:25.050
dass wir

02:50:25.050 --> 02:50:26.590
jetzt so

02:50:26.590 --> 02:50:30.590
in der Zeit von Internet

02:50:30.590 --> 02:50:31.530
und Computern

02:50:31.530 --> 02:50:33.710
sich ja Dinge komplett verschieben

02:50:33.710 --> 02:50:35.530
im Grunde, oder wir das aber noch

02:50:35.530 --> 02:50:37.550
gar nicht so richtig antizipiert haben.

02:50:37.550 --> 02:50:39.770
Sein Beispiel

02:50:39.770 --> 02:50:41.450
ist halt auch E-Commerce und halt auch

02:50:41.450 --> 02:50:42.830
so Faceted Navigation.

02:50:45.510 --> 02:50:47.430
Er sagt halt, naja, also in so einem klassischen

02:50:47.430 --> 02:50:49.190
Laden, wenn du da reingehst,

02:50:49.190 --> 02:50:51.510
muss man sich überlegen, wo man

02:50:51.510 --> 02:50:52.630
welche Dinge hinpackt.

02:50:52.630 --> 02:50:55.970
Da physikalische Objekte

02:50:55.970 --> 02:50:57.390
nur an einem Ort gleichzeitig sein können,

02:50:57.390 --> 02:51:00.030
oder überhaupt irgendwo sein müssen,

02:51:00.030 --> 02:51:02.090
muss man halt irgendwie das so strukturieren,

02:51:02.090 --> 02:51:03.870
dass das der Fall ist, und dann muss man sich überlegen,

02:51:03.870 --> 02:51:05.270
okay, wie macht das für die meisten Leute Sinn,

02:51:05.270 --> 02:51:07.810
wenn sie reinkommen, ist immer der Salat irgendwie vorne rechts,

02:51:07.810 --> 02:51:08.270
oder keine Ahnung.

02:51:08.270 --> 02:51:11.850
Und das muss man eigentlich, wenn man jetzt

02:51:11.850 --> 02:51:13.270
Daten über Daten hat,

02:51:13.270 --> 02:51:15.110
gar nicht mehr so machen.

02:51:15.510 --> 02:51:17.810
Das Slicen und Dicen, wie man wollte.

02:51:17.810 --> 02:51:19.870
Also man könnte halt sagen, okay, ich bin jemand, der nur

02:51:19.870 --> 02:51:21.170
schwarze T-Shirts anzieht, also

02:51:21.170 --> 02:51:24.050
alles andere interessiert mich nicht.

02:51:24.050 --> 02:51:26.110
Ich brauche jetzt eine Navigation innerhalb

02:51:26.110 --> 02:51:27.970
dieser schwarzen T-Shirts, aber alle anderen Sachen kann ich

02:51:27.970 --> 02:51:29.170
schon mal so irgendwie wegschneiden.

02:51:29.170 --> 02:51:32.110
Das würde für alle anderen vielleicht keinen Sinn machen,

02:51:32.110 --> 02:51:34.110
oder für andere Leute, jeder hat vielleicht andere Arten,

02:51:34.110 --> 02:51:36.170
was er, aber ich kann

02:51:36.170 --> 02:51:37.990
jetzt eine Seite bauen, die

02:51:37.990 --> 02:51:39.890
auf die Bedürfnisse von jedem im Grunde zugeschnitten ist,

02:51:39.890 --> 02:51:40.350
oder sich leicht so an...

02:51:40.350 --> 02:51:42.670
Die eigene Filterbubble immer erzeugt für den jeweiligen...

02:51:42.670 --> 02:51:45.310
Elektronisch habe ich das Problem nicht, oder

02:51:45.450 --> 02:51:48.110
ich kann für jeden eine eigene

02:51:48.110 --> 02:51:48.990
Art von Laden

02:51:48.990 --> 02:51:51.630
erzeugen,

02:51:51.630 --> 02:51:54.070
oder eine eigene Art von Navigation bauen.

02:51:54.070 --> 02:51:56.110
Nur wenn ich denjenigen kenne, natürlich.

02:51:56.110 --> 02:51:57.970
Natürlich, oder

02:51:57.970 --> 02:51:59.930
wenn er es mir halt irgendwie sagt, indem ich ein Interface habe,

02:51:59.930 --> 02:52:01.550
wo man das halt irgendwie einstellen könnte.

02:52:01.550 --> 02:52:04.070
Aber das wird kaum

02:52:04.070 --> 02:52:05.930
gemacht. Es gibt halt meistens doch wieder einen

02:52:05.930 --> 02:52:07.610
Kategorienbaum, der halt

02:52:07.610 --> 02:52:10.050
irgendwie... Kategorienbaum

02:52:10.050 --> 02:52:11.850
auf einer Seite ist ja im Grunde irgendwie sowas wie

02:52:11.850 --> 02:52:13.910
ein Weg durch

02:52:13.910 --> 02:52:15.350
einen Laden, der halt vorgegeben ist.

02:52:15.450 --> 02:52:17.030
Warum muss das denn so sein?

02:52:17.030 --> 02:52:19.150
Das muss ja eigentlich... Also wir adaptieren da

02:52:19.150 --> 02:52:21.010
eine Sichtweise aus der

02:52:21.010 --> 02:52:22.910
physischen Welt, die

02:52:22.910 --> 02:52:25.230
vielleicht insofern hilfreich ist, weil

02:52:25.230 --> 02:52:26.010
die Leute kennen das so.

02:52:26.010 --> 02:52:29.350
Insofern macht das auch durchaus Sinn, das so zu tun,

02:52:29.350 --> 02:52:31.190
aber es müsste eigentlich nicht so sein. Und vielleicht

02:52:31.190 --> 02:52:33.210
wäre es, wenn man das anders machen würde, halt viel effizienter.

02:52:33.210 --> 02:52:35.490
Genau.

02:52:35.490 --> 02:52:37.670
Das ist das Raum für ein Startup da übrigens gerade.

02:52:37.670 --> 02:52:38.950
Ja, das Problem ist halt nur,

02:52:38.950 --> 02:52:41.090
also ich fand das ja schon vor über 10 Jahren

02:52:41.090 --> 02:52:42.070
interessant, aber

02:52:42.070 --> 02:52:45.250
in der Richtung hat sich noch nicht so wirklich wahnsinnig viel

02:52:45.250 --> 02:52:46.890
getan. Insofern bin ich mir nicht sicher,

02:52:46.890 --> 02:52:48.790
ob das eine gute... Also damals war es auch, wenn wir zurückblicken,

02:52:48.790 --> 02:52:50.770
kann man jetzt sagen, damals ein Startup in die Richtung

02:52:50.770 --> 02:52:52.210
zu starten, wäre keine gute Idee gewesen.

02:52:52.210 --> 02:52:54.810
Vielleicht wäre es jetzt eine gute Idee.

02:52:54.810 --> 02:52:56.350
Vielleicht ist es aber erst in 5 Jahren eine gute Idee.

02:52:56.350 --> 02:52:56.810
Keine Ahnung.

02:52:56.810 --> 02:53:00.650
Wenn der Zeitpunkt richtig ist, keine Ahnung.

02:53:00.650 --> 02:53:02.590
Man braucht ein Gespür für. Und wenn man das Gespür hat

02:53:02.590 --> 02:53:03.850
und dann an der richtigen Stelle ist, dann...

02:53:03.890 --> 02:53:07.250
Ja, brauchen wir noch ein bisschen Geld und Geduld.

02:53:07.250 --> 02:53:12.310
Ja, aber genau der Punkt, auf den ich eigentlich hinaus will, ist,

02:53:12.310 --> 02:53:16.770
was ist eigentlich, Amazon hat das gleiche Interface für alle Arten von Dingen, die sie verkaufen.

02:53:16.770 --> 02:53:20.130
Sie haben am Anfang mit Büchern angefangen, weil bei Büchern das Problem,

02:53:20.130 --> 02:53:24.470
weil sie da einen ganz klaren Vorteil gegenüber den anderen

02:53:24.470 --> 02:53:27.750
Ja, du möchtest ein Framing bauen für den jeweiligen Kunden.

02:53:27.750 --> 02:53:31.590
Ja, ich möchte halt zum Beispiel einfach nur so in die Richtung gehen,

02:53:33.890 --> 02:53:36.450
warum muss die Navigation immer gleich aussehen.

02:53:36.450 --> 02:53:40.070
Das eigene Holodeck, also manchmal geht man im Mittelalterladen einkaufen, mal im Cyberstore.

02:53:40.070 --> 02:53:42.610
Genau, je nachdem, was man verkaufen möchte.

02:53:42.610 --> 02:53:46.250
Amazon macht jetzt nicht nur Bücher, sondern mittlerweile machen sie,

02:53:46.250 --> 02:53:49.330
Bücher ist jetzt wahrscheinlich gar kein großer Anteil mehr an ihrem Geschäft.

02:53:49.330 --> 02:53:52.810
Sie verkaufen viel Elektronik und das sieht man der Seite halt auch an.

02:53:52.810 --> 02:53:58.490
Also vieles von der Navigation ist darauf optimiert, dass ich halt irgendwie so Elektronik, weiße Ware irgendwie kaufen kann.

02:53:58.490 --> 02:54:00.910
So ein bisschen wie Ambilight beim Fernseher.

02:54:00.910 --> 02:54:03.130
Ja, aber halt inhaltlich.

02:54:03.130 --> 02:54:03.530
Ja, ja.

02:54:03.530 --> 02:54:07.650
Und das liegt halt vor allen Dingen, dass die Navigation so aussieht, wie sie aussieht, liegt halt an Datenbankschema.

02:54:07.650 --> 02:54:12.990
Weil das lässt halt gar nicht zu, dass ich irgendwie was großartig anderes baue, weil das ist halt mehr oder weniger fix.

02:54:12.990 --> 02:54:20.190
Jetzt ist es natürlich schon so, dass unterschiedliche Dinge, also Fahrräder haben halt bestimmte,

02:54:20.190 --> 02:54:23.090
das kann ich schon irgendwie, da kann ich ein Schema bauen, das das irgendwie modelliert.

02:54:23.090 --> 02:54:24.990
Oder Bücher oder Waschmaschinen.

02:54:24.990 --> 02:54:31.190
Aber die Daten über die Daten, die kann ich natürlich irgendwie beliebig modellieren.

02:54:31.190 --> 02:54:33.510
Da könnte ich auch beliebige Navigationen drauf bauen.

02:54:33.530 --> 02:54:39.490
Und ich könnte auch, also wenn ich jetzt, also der Witz ist, was ich eigentlich eventuell gerne hätte,

02:54:39.490 --> 02:54:45.030
dass jetzt, wenn jetzt ein Produktmanager, der für die Kategorie Fahrräder oder sowas zuständig ist,

02:54:45.030 --> 02:54:55.630
auf eine irgendwie super Idee kommt, wie man das Navigieren mal macht und die Leute zufriedener zu den Fahrrädern, die sie haben wollen, führen kann,

02:54:55.630 --> 02:54:58.770
dann müsste er ja die Navigation umstellen können.

02:54:58.770 --> 02:54:59.970
Dafür müsste er das Schema ändern können.

02:54:59.970 --> 02:55:03.390
Das heißt, er müsste das Schema live irgendwie ändern.

02:55:03.530 --> 02:55:05.810
Was in relationalen Daten, das kannst du vergessen.

02:55:05.810 --> 02:55:12.150
Also du kannst, ich meine, du musst eine Migration machen, du musst halt irgendwie, das kannst du alles, das kannst du komplett.

02:55:12.150 --> 02:55:15.030
Also sagen wir mal so, es geht technisch, aber das ist auf jeden Fall Entwicklerarbeit.

02:55:15.030 --> 02:55:19.070
Das ist halt nicht etwas, was irgendjemand, der auf einer Webseite irgendwas einstellt, irgendwie.

02:55:19.070 --> 02:55:22.170
Das geht halt eher nicht.

02:55:22.170 --> 02:55:30.570
Aber wenn man jetzt von diesem, sich von diesem relationalen Paradigmen so ein bisschen löst und sagt, okay, ja, dann ginge das eventuell schon.

02:55:30.570 --> 02:55:33.010
Also im Grunde, wenn man jetzt nicht.

02:55:33.530 --> 02:55:42.490
Daten über physikalische Effekte hat, sondern Daten über Daten und eine Datenbank, die halt nicht mehr so fixe Schema, nicht so ein fixes Schema hat,

02:55:42.490 --> 02:55:49.370
dann könnte man eventuell so machen, dass man die Seite live so ändert, wie sie halt eventuell mehr Sinn macht.

02:55:49.370 --> 02:55:50.970
Und vielleicht könnten das auch die User tun.

02:55:50.970 --> 02:55:51.410
Keine Ahnung.

02:55:51.410 --> 02:55:52.910
Es ist halt nur so, es ist halt so eine Idee.

02:55:52.910 --> 02:55:56.030
Es ist halt einfach so eine Idee, wie geht es jetzt eigentlich weiter.

02:55:56.030 --> 02:55:58.150
Ich meine, Amazon ist im Grunde mehr oder weniger fertig.

02:55:58.150 --> 02:56:03.490
Wir haben Amazon nachgebaut und wir hatten auch das Problem, dass unsere Navigation,

02:56:03.530 --> 02:56:08.290
egal ob das jetzt Fahrräder, Waschmaschinen oder sonst irgendwas ist, würde halt genau gleich aussehen oder Mode.

02:56:08.290 --> 02:56:18.590
Und da könnten wir ja im Grunde nichts machen, weil das Schema halt für Angebote halt immer gleich sein muss, weil die sind ja alle in einem Datenbankschirm.

02:56:18.590 --> 02:56:20.950
So, genau.

02:56:20.950 --> 02:56:26.730
Aber das könnte halt irgendwie wie etwas anders aussehen.

02:56:26.730 --> 02:56:31.650
Und was halt da sehr interessant sein könnte, sind halt Grafen-Datenbanken zum Beispiel, wo man halt eben nicht.

02:56:31.650 --> 02:56:33.490
Also ich hatte das ja auch am Anfang schon mal erwähnt.

02:56:33.530 --> 02:56:35.590
Es hätten sich auch Grafen-Datenbanken durchsetzen können.

02:56:35.590 --> 02:56:38.410
Das ist überhaupt nicht so klar, warum das relational geworden sind.

02:56:38.410 --> 02:56:41.890
Gut, die Grafen-Datenbanken waren ein bisschen später dran.

02:56:41.890 --> 02:56:48.150
Aber ja, und da gibt es zum Beispiel auch ein super interessantes Projekt, nennt sich D-Graph.

02:56:48.150 --> 02:56:49.350
D-Graph.

02:56:49.350 --> 02:56:49.730
Ja.

02:56:49.730 --> 02:56:53.990
Das ist ein Ex-Mitarbeiter von Google.

02:56:53.990 --> 02:57:01.770
Und der hat sich irgendwie getroffen.

02:57:01.770 --> 02:57:02.990
Da hat man Google geschaut.

02:57:03.530 --> 02:57:07.310
Da hat man halt auch überlegt, was sind denn jetzt die Sachen, die man heutzutage hat, die Probleme, die man hat.

02:57:07.310 --> 02:57:08.170
Also es muss halt irgendwie so.

02:57:08.170 --> 02:57:11.570
Brides müssen halt auch.

02:57:11.570 --> 02:57:13.450
Man darf nicht nur einen Master haben.

02:57:13.450 --> 02:57:14.610
Es muss halt irgendwie skalierbar sein.

02:57:14.610 --> 02:57:17.630
Es muss halt irgendwie schnell sein.

02:57:17.630 --> 02:57:23.330
Und der hat, das hat letztes Mal, als wir über Skalierbarkeit und so, ich glaube, das war in der ersten Folge oder so geredet haben,

02:57:23.330 --> 02:57:27.310
habe ich auch gesagt, so Go wäre eventuell ein guter Kandidat, um da drin einen Datenbank zu schreiben.

02:57:27.310 --> 02:57:28.710
Also Python halt nicht so.

02:57:28.710 --> 02:57:33.510
Das ist halt eines der wenigen Anwendungsfälle, wo ich sagen würde, gut, dafür ist Python.

02:57:33.530 --> 02:57:37.750
Python ist gut geeignet, wenn man I.O. multiplexen muss.

02:57:37.750 --> 02:57:40.010
Also man macht einfach nur viel Netzwerk in alle möglichen Richtungen.

02:57:40.010 --> 02:57:40.830
Das geht.

02:57:40.830 --> 02:57:42.990
Da braucht man gar nicht unter Umständen viel CPU für.

02:57:42.990 --> 02:57:44.870
Also solange man nicht viel CPU dafür braucht.

02:57:44.870 --> 02:57:51.330
Oder es ist gut dafür geeignet, wenn man viel CPU braucht, aber nicht so viel Concurrency hat.

02:57:51.330 --> 02:57:56.030
Wenn man beides hat, man hat viel Concurrency und viel CPU, die das braucht, dann ist es halt eher scheiße.

02:57:56.030 --> 02:57:59.210
Weil dann erwischt einen halt dieser Global Interpreter-Log.

02:57:59.210 --> 02:58:02.990
Und da stößt man an so prinzipielle Grenzen.

02:58:03.530 --> 02:58:07.450
Was Kalierbarkeit angeht bei Python.

02:58:07.450 --> 02:58:09.490
Aber ich würde sagen, naja, nicht so schlimm.

02:58:09.490 --> 02:58:13.870
Ist eigentlich ganz gut, weil diesen Anwendungsfall haben die wenigsten Programmierer.

02:58:13.870 --> 02:58:17.110
Und ein Beispiel war halt Datenbanken.

02:58:17.110 --> 02:58:20.470
Eventuell so etwas, was halt genau diese Anforderungen hat.

02:58:20.470 --> 02:58:23.090
Und was man dann in Python vielleicht doch nicht so gut schreiben könnte.

02:58:23.090 --> 02:58:28.010
Und ja, tatsächlich, Ggraph ist in Go geschrieben.

02:58:28.010 --> 02:58:32.830
Und mit Graphen-Datenbanken könnte man das halt tun.

02:58:32.930 --> 02:58:38.170
Da kann man halt das Schema ändern, live, ohne dass man irgendwie da so...

02:58:38.170 --> 02:58:41.770
Weil man kann halt beliebige Beziehungen ziehen, beliebige Kanten.

02:58:41.770 --> 02:58:46.010
Man muss nicht unbedingt sozusagen alles in dieser Tabellen...

02:58:46.010 --> 02:58:47.650
Man hat ja nicht mehr unbedingt diese Tabellenstruktur.

02:58:47.650 --> 02:58:52.010
Und ja, das ist halt schon ziemlich interessant.

02:58:52.010 --> 02:58:54.770
Auch wenn man...

02:58:54.770 --> 02:58:57.350
Also es gibt ja nochmal bei den Graphen-Datenbanken sowieso Unterschiede.

02:58:57.350 --> 02:58:59.750
Es gibt auch diese ganzen ADF-Geschichten.

02:58:59.750 --> 02:59:02.350
Da ist es aber so, dass die das nicht...

02:59:02.930 --> 02:59:05.050
So optimiert irgendwie auf der Platte speichern.

02:59:05.050 --> 02:59:07.950
Das ist halt eher so ein Textformat.

02:59:07.950 --> 02:59:10.770
Es gibt ja auch Mikroformate auf Webseiten, wo man das benutzen kann.

02:59:10.770 --> 02:59:16.630
Wo man irgendwelche Metadaten über die Seite hinterlegen kann.

02:59:16.630 --> 02:59:18.930
Das ist bei uns auch eine vielleicht nicht so doofe Geschichte.

02:59:18.930 --> 02:59:20.790
Gerade was Google angeht, Mikroformate.

02:59:20.790 --> 02:59:25.230
Dann kann halt Google automatisch eine ganze Menge Informationen aus der Seite ziehen.

02:59:25.230 --> 02:59:27.490
Ohne dass sie das halt irgendwie raten müssen.

02:59:27.490 --> 02:59:31.410
Das geht auch schon alles so ein bisschen in Richtung Semantik-Web.

02:59:32.930 --> 02:59:35.710
Aber das Problem dabei ist, es ist halt nicht optimiert.

02:59:35.710 --> 02:59:38.610
Und für Graphenabfragen auch nicht optimiert.

02:59:38.610 --> 02:59:40.850
Daher wird es halt immer ziemlich langsam sein.

02:59:40.850 --> 02:59:44.570
Und es gibt halt Graphen-Datenbanken, die das halt so optimiert speichern.

02:59:44.570 --> 02:59:46.250
Dazu gehört D-Graph auf jeden Fall.

02:59:46.250 --> 02:59:52.330
Die älteste und weitestverweitete Datenbank Neo4j macht das auch so.

02:59:52.330 --> 02:59:54.830
Aber Neo4j ist halt auch...

02:59:54.830 --> 02:59:55.390
Das ist halt Java.

02:59:55.390 --> 02:59:57.710
Kann ja schon mal nicht gut sein.

02:59:57.710 --> 03:00:00.890
Aber es ist halt auch viel langsamer, muss man sagen, als D-Graph.

03:00:00.890 --> 03:00:02.130
Und es ist halt auch...

03:00:02.130 --> 03:00:03.690
Es hat eine komische Abfragesprache.

03:00:03.690 --> 03:00:05.310
Also Cypher heißt die irgendwie.

03:00:05.310 --> 03:00:08.810
Und naja.

03:00:08.810 --> 03:00:10.730
Und ob das alles so...

03:00:10.730 --> 03:00:11.990
Ist auch Acid und so.

03:00:11.990 --> 03:00:13.850
Das ist alles nicht so...

03:00:13.850 --> 03:00:15.850
Also es geht in die Richtung, aber es ist nicht so toll.

03:00:15.850 --> 03:00:16.990
Irgendwie.

03:00:16.990 --> 03:00:18.970
Und bei D-Graph sieht das alles viel besser aus.

03:00:18.970 --> 03:00:22.070
Und was auch super cool ist bei D-Graph, ist die Abfragesprache.

03:00:22.070 --> 03:00:22.990
Die nehmen einfach GraphQL.

03:00:22.990 --> 03:00:24.770
Oder ein Dialekt davon.

03:00:24.770 --> 03:00:26.710
Und das ist natürlich auch nochmal sehr interessant.

03:00:26.710 --> 03:00:29.030
Weil GraphQL ist natürlich auch momentan ein sehr heißes Thema.

03:00:31.330 --> 03:00:36.530
Und möglicherweise, wenn man jetzt ein neues Amazon bauen würde...

03:00:36.530 --> 03:00:37.630
Würde man damit anfangen.

03:00:37.630 --> 03:00:41.130
Würde man jetzt das vielleicht nicht auf einer relationalen Datenbank aufsetzen,

03:00:41.130 --> 03:00:42.150
sondern auf sowas wie D-Graph.

03:00:42.150 --> 03:00:44.830
Und dann könnte man das so bauen,

03:00:44.830 --> 03:00:48.770
dass sich die Navigation je nachdem, was man da einkauft,

03:00:48.770 --> 03:00:49.730
halt ändern lässt.

03:00:49.730 --> 03:00:50.810
Auch live.

03:00:50.810 --> 03:00:52.970
Und ist ja trotzdem schnell.

03:00:52.970 --> 03:00:55.450
Und...

03:00:55.450 --> 03:00:55.890
Ja.

03:00:55.890 --> 03:01:00.670
Und das wäre so ein bisschen...

03:01:00.670 --> 03:01:02.230
Dann könnte die Reise irgendwie gehen.

03:01:02.230 --> 03:01:05.050
Ich habe keine Ahnung, ob das passieren wird, aber...

03:01:05.050 --> 03:01:05.610
Ja, let's go.

03:01:05.610 --> 03:01:09.530
Ja, genau.

03:01:09.530 --> 03:01:10.910
Und dann auch, was auch interessant ist,

03:01:10.910 --> 03:01:13.350
ist halt noch, dass man irgendwie durchaus

03:01:13.350 --> 03:01:17.230
so hybride Formen haben kann

03:01:17.230 --> 03:01:18.250
zwischen Dokument-basiert

03:01:18.250 --> 03:01:19.570
oder Schema-less

03:01:19.570 --> 03:01:22.630
oder nur SQL,

03:01:22.630 --> 03:01:23.150
nur NoSQL.

03:01:23.150 --> 03:01:26.150
Das steht halt entweder für Not-Only-SQL

03:01:26.150 --> 03:01:27.290
oder eben

03:01:27.290 --> 03:01:30.430
kein SQL.

03:01:30.670 --> 03:01:33.410
Ähm...

03:01:33.410 --> 03:01:34.250
Ähm...

03:01:34.250 --> 03:01:35.690
Naja...

03:01:35.690 --> 03:01:36.630
Äh...

03:01:36.630 --> 03:01:38.030
In Toastgres hat man zum Beispiel die Möglichkeit,

03:01:38.030 --> 03:01:39.490
das ein bisschen zu kombinieren.

03:01:39.490 --> 03:01:41.710
Da gibt es halt ein sehr schönes...

03:01:41.710 --> 03:01:42.370
Ähm...

03:01:42.370 --> 03:01:44.070
Sehr schönen Spalten-Typ.

03:01:44.070 --> 03:01:45.550
Nennt sich...

03:01:45.550 --> 03:01:46.250
Äh...

03:01:46.250 --> 03:01:47.090
Binary-Jason.

03:01:47.090 --> 03:01:49.210
Ja, so muss es auch passen.

03:01:49.210 --> 03:01:50.110
Jason gibt es auch.

03:01:50.110 --> 03:01:51.990
Ist aber nur so aus Legacy-Gründen noch dabei.

03:01:51.990 --> 03:01:53.050
Den nicht nehmen.

03:01:53.050 --> 03:01:55.030
Der ist...

03:01:55.030 --> 03:01:55.650
Äh...

03:01:55.650 --> 03:01:56.250
Der ist alt.

03:01:56.250 --> 03:01:57.570
Und nicht so gut.

03:01:57.570 --> 03:02:00.150
Aber Binary-Jason ist super,

03:02:00.150 --> 03:02:00.510
weil...

03:02:00.510 --> 03:02:02.310
Weil, äh...

03:02:02.310 --> 03:02:04.570
Da kann man auch Indizes auf Felder

03:02:04.570 --> 03:02:05.810
innerhalb von dem Jason machen.

03:02:05.810 --> 03:02:07.930
Das heißt, man kann halt die Teile, bei denen man sich nicht sicher ist,

03:02:07.930 --> 03:02:09.250
wie das Schema dafür eigentlich aussehen wird,

03:02:09.250 --> 03:02:12.470
oder die man, wo man sozusagen die Definition des Schemas

03:02:12.470 --> 03:02:13.930
in die Applikation verlagern möchte,

03:02:13.930 --> 03:02:16.110
also wo dann ein Applikationsentwickler sagen kann,

03:02:16.110 --> 03:02:18.890
okay, an der Stelle speichere ich die Daten jetzt so und so.

03:02:18.890 --> 03:02:21.130
Ja, ich möchte aber gar nicht die Datenbank verändern.

03:02:21.130 --> 03:02:22.230
Dann kann er das,

03:02:22.230 --> 03:02:24.850
wenn er das in eine Spalte schreibt, die halt Binary-Jason ist,

03:02:24.850 --> 03:02:26.010
einfach so reinschreiben.

03:02:26.010 --> 03:02:27.570
Er kann sogar Sachen da drin indizieren und so.

03:02:27.570 --> 03:02:29.850
Und, ähm...

03:02:29.850 --> 03:02:30.350
Und das ist halt...

03:02:30.350 --> 03:02:30.690
Zack, schnell.

03:02:30.690 --> 03:02:32.970
Das ist ähnlich schnell wie MongoDB.

03:02:32.970 --> 03:02:34.190
MongoDB macht ja...

03:02:34.190 --> 03:02:38.190
MongoDB ist mehr oder weniger nur diese B-Jason-Spalte

03:02:38.190 --> 03:02:39.550
aus Postgres.

03:02:39.550 --> 03:02:41.490
Das ist halt mehr oder weniger das Gleiche.

03:02:41.490 --> 03:02:42.450
Das heißt, wenn ich jetzt...

03:02:42.450 --> 03:02:44.750
Ich kann das, was ich mit MongoDB mache,

03:02:44.750 --> 03:02:46.990
auch in einer solchen Spalte in Postgres machen.

03:02:46.990 --> 03:02:47.730
Ja, gut.

03:02:47.730 --> 03:02:49.210
MongoDB ist vielleicht noch ein bisschen schneller,

03:02:49.210 --> 03:02:51.750
hat noch ein paar andere Funktionen, aber...

03:02:51.750 --> 03:02:52.450
Ja...

03:02:52.450 --> 03:02:52.850
Das...

03:02:52.850 --> 03:02:54.570
Also...

03:02:54.570 --> 03:02:56.390
Ich glaube nicht, dass viele Leute

03:02:56.390 --> 03:02:57.790
tatsächlich was anderes brauchen würden.

03:02:57.790 --> 03:02:59.950
Ich kann aber auf der anderen Seite bei den Sachen,

03:02:59.950 --> 03:03:00.190
bei denen ich...

03:03:00.190 --> 03:03:00.910
Wenn ich weiß...

03:03:00.910 --> 03:03:02.350
Also, es gibt ja so etablierte Geschichten,

03:03:02.350 --> 03:03:03.570
da ist schon klar, wie das funktioniert.

03:03:03.570 --> 03:03:04.310
User-Verwaltung,

03:03:04.310 --> 03:03:05.910
wenn ich eine Webseite habe,

03:03:05.910 --> 03:03:07.170
so, wenn sich User anmelden...

03:03:07.170 --> 03:03:08.950
Das ist alles relational,

03:03:08.950 --> 03:03:09.870
das ist auch etabliert,

03:03:09.870 --> 03:03:11.130
da wird sich jetzt auch nicht so viel dran ändern.

03:03:11.130 --> 03:03:13.310
Und dann für die Teile der Applikation,

03:03:13.310 --> 03:03:14.270
wo ich mir halt nicht sicher bin,

03:03:14.270 --> 03:03:15.530
wo ich nicht weiß, in welche Richtung das geht,

03:03:15.530 --> 03:03:16.250
mache ich dann halt...

03:03:16.250 --> 03:03:17.170
Schreibe ich das halt als JSON,

03:03:17.170 --> 03:03:18.230
irgendwelche Spalten da.

03:03:18.230 --> 03:03:21.490
Und wenn das dann halt klar geworden ist,

03:03:21.490 --> 03:03:22.410
wie das Schema da aussieht,

03:03:22.410 --> 03:03:24.510
dann ziehe ich das dann auch Stück für Stück

03:03:24.510 --> 03:03:25.410
in ein relationales Schema.

03:03:25.410 --> 03:03:28.870
Sodass ich halt dann Vorteile aus beiden Welten habe.

03:03:28.870 --> 03:03:29.430
Und ich würde sagen,

03:03:29.490 --> 03:03:33.010
das ist halt momentan auch so ein relativ unschlagbares Feature

03:03:33.010 --> 03:03:38.290
von Postgres gegenüber den meisten anderen Datenbanken,

03:03:38.290 --> 03:03:40.590
dass man das halt so flexibel miteinander kombinieren kann.

03:03:40.590 --> 03:03:41.590
Weil, wenn ich MongoDB habe,

03:03:41.590 --> 03:03:42.170
habe ich ja das Problem,

03:03:42.170 --> 03:03:46.090
okay, also relational und konsistent und sicher und so,

03:03:46.090 --> 03:03:47.390
das geht halt alles nicht so richtig gut.

03:03:47.390 --> 03:03:50.450
Ich habe halt nur dieses Ding,

03:03:50.450 --> 03:03:51.490
wo ich halt meine...

03:03:51.490 --> 03:03:53.030
Ich kann zwar auch ein Schema definieren oder so,

03:03:53.030 --> 03:03:53.850
aber...

03:03:53.850 --> 03:03:58.210
Ja, das ist alles nicht so weit wie bei Postgres.

03:03:58.210 --> 03:03:58.810
Ja.

03:03:59.490 --> 03:04:00.810
Ja, also genau,

03:04:00.810 --> 03:04:01.750
das wollte ich auch noch erwähnt haben,

03:04:01.750 --> 03:04:04.830
dass das halt eine schöne Geschichte ist an Postgres.

03:04:04.830 --> 03:04:09.310
Ja, ich glaube, langsam haben wir es, ne?

03:04:09.310 --> 03:04:12.170
Ja, und so langsam sind wir dann eigentlich im Grunde...

03:04:12.170 --> 03:04:13.590
Ich habe ja wirklich viel durchgehalten heute,

03:04:13.590 --> 03:04:14.310
also über drei Stunden,

03:04:14.310 --> 03:04:16.650
das war schon die Mammut-Folge hier jetzt, also...

03:04:16.650 --> 03:04:18.330
Okay, ja, aber ich bin mal auch gespannt,

03:04:18.330 --> 03:04:18.850
wie das so ankommt,

03:04:18.850 --> 03:04:20.370
weil das ist ja jetzt immer so ein bisschen...

03:04:20.370 --> 03:04:22.210
Das ist ja jetzt nicht so ein Einsteiger oder so,

03:04:22.210 --> 03:04:24.230
sondern das ist einfach mal so komplett durch...

03:04:24.230 --> 03:04:26.150
Ich habe möglicherweise auch eine Menge Unsinn erzählt,

03:04:26.150 --> 03:04:28.130
das kann leider auch sein, weil das ist halt auch so...

03:04:28.130 --> 03:04:29.430
Ja, aber man kann sich irgendwann die Folge nochmal anhören,

03:04:29.490 --> 03:04:30.610
wenn man so ein bisschen weiter ist in dem Thema,

03:04:30.610 --> 03:04:32.290
und dann vielleicht merkt man so,

03:04:32.290 --> 03:04:34.550
hey, wow, ja, das waren einige interessante Gedankengründe,

03:04:34.550 --> 03:04:35.910
wie sich das so verändert im Laufe der Zeit.

03:04:35.910 --> 03:04:38.310
Ja, ach so, PIX, genau.

03:04:38.310 --> 03:04:38.670
Ja.

03:04:38.670 --> 03:04:39.150
Hast du...

03:04:39.150 --> 03:04:39.810
Du machst...

03:04:39.810 --> 03:04:41.550
Was machst du mit Datenbanken oder welche Sachen?

03:04:41.550 --> 03:04:42.310
Ich bin ja noch gerade am Anfang.

03:04:42.310 --> 03:04:43.910
Ich nehme erst mal so ein bisschen SQLite oder sowas,

03:04:43.910 --> 03:04:45.230
das ist ganz super, das ist ja direkt dabei,

03:04:45.230 --> 03:04:46.270
und dann kann man direkt loslegen

03:04:46.270 --> 03:04:47.870
und seine ersten Datenbanken ein bisschen füttern.

03:04:47.870 --> 03:04:49.510
Für den Einstieg auch gar nicht so schlecht,

03:04:49.510 --> 03:04:51.130
dann kann man erst mal ein paar SQL-Skaten sehen

03:04:51.130 --> 03:04:54.190
und vielleicht mit SQL-Alchemy das machen und dann...

03:04:54.190 --> 03:04:54.750
Das ist auch interessant.

03:04:54.750 --> 03:04:58.750
Ich glaube, SQLite ist eine der Softwaren,

03:04:59.490 --> 03:05:00.670
die mit am weitesten...

03:05:00.670 --> 03:05:02.770
Die weiteste Deploy-Basis hat irgendwie so.

03:05:02.770 --> 03:05:05.310
Ich glaube, das konkurriert noch mit Curl oder so.

03:05:05.310 --> 03:05:08.090
Das wird auch fast überall SQL mit drin.

03:05:08.090 --> 03:05:10.090
Aber ich glaube, SQLite ist auch ein Kandidat für das.

03:05:10.090 --> 03:05:10.810
Das ist fast überall drin.

03:05:10.810 --> 03:05:13.990
Das ist auch Core Data,

03:05:13.990 --> 03:05:16.890
das ist der Datenabstraktionslayer von iOS.

03:05:16.890 --> 03:05:19.050
Da ist auch SQLite drunter.

03:05:19.050 --> 03:05:20.930
Das ist in fast allen Browsern drin.

03:05:20.930 --> 03:05:23.390
Das heißt, wenn man einen Browser hat, hat man SQLite.

03:05:23.390 --> 03:05:26.210
Das ist auf einer Apple Watch.

03:05:26.210 --> 03:05:28.310
Das ist eine SQLite-Datenbank und zählt die Schritte.

03:05:28.310 --> 03:05:29.190
Das ist ein echter Teil.

03:05:29.490 --> 03:05:32.290
Also es skaliert von einer kleinen Uhr

03:05:32.290 --> 03:05:36.210
zu, ich glaube, momentan das theoretische Limit für SQLite

03:05:36.210 --> 03:05:41.190
sind irgendwie 144 Terabyte oder sowas.

03:05:41.190 --> 03:05:43.810
Kriegt man schwer voll.

03:05:43.810 --> 03:05:46.750
Ja, und es gibt, glaube ich, große SQLite-Datenbanken

03:05:46.750 --> 03:05:47.610
tatsächlich da draußen.

03:05:47.610 --> 03:05:50.530
Das ist ein super interessantes Projekt.

03:05:50.530 --> 03:05:53.630
Ich glaube, es wurde mal vorgeschlagen,

03:05:53.630 --> 03:05:56.270
für Langzeitarchivierung das SQLite-Format zu nehmen,

03:05:56.270 --> 03:05:57.530
weil es halt so...

03:05:58.350 --> 03:06:01.330
Von irgendeiner Bibliothek.

03:06:01.330 --> 03:06:05.390
Weil es halt auch sich seit Jahren nicht mehr geändert hat.

03:06:05.390 --> 03:06:06.270
Das ist relativ schnell.

03:06:06.270 --> 03:06:09.110
Und ja, SQLite, super cooles Projekt.

03:06:09.110 --> 03:06:14.150
Und im Zusammenhang ist auch einer von meinen Pics,

03:06:14.150 --> 03:06:15.530
was man sich vielleicht mal angucken kann,

03:06:15.530 --> 03:06:17.690
ist ein Projekt namens Datasette.

03:06:17.690 --> 03:06:19.150
Datasette.

03:06:19.150 --> 03:06:20.890
Die Kassette, also zum Aufrollen noch.

03:06:20.890 --> 03:06:21.910
So wie, genau.

03:06:21.910 --> 03:06:25.390
Und zwar geht es darum, dass halt für so Datenjournalismus,

03:06:25.390 --> 03:06:26.890
es geht darum, dass man...

03:06:28.350 --> 03:06:31.110
Datensätze, die irgendwo veröffentlicht wurden,

03:06:31.110 --> 03:06:32.950
wie man die jetzt navigierbar macht,

03:06:32.950 --> 03:06:35.950
für Leute, die jetzt nicht das in eine Datenbank importieren wollen

03:06:35.950 --> 03:06:37.250
und dann selber Statements schreiben.

03:06:37.250 --> 03:06:39.910
Und das macht das halt.

03:06:39.910 --> 03:06:41.690
Und man kann ja CSV ausnehmen, die da reinwerfen.

03:06:41.690 --> 03:06:43.690
Und dann kriegt man halt so auch ein Interface

03:06:43.690 --> 03:06:45.410
mit Facetten Navigation, mit Volltextsuche,

03:06:45.410 --> 03:06:47.290
weil halt auch SQLite kann halt Volltextsuche.

03:06:47.290 --> 03:06:50.270
Und man kann sogar SQL Statements reinschreiben.

03:06:50.270 --> 03:06:51.990
Man kann aber auch das irgendwie über eine Webseite navigieren.

03:06:51.990 --> 03:06:53.010
Das ist ziemlich cool.

03:06:53.010 --> 03:06:58.330
Und ja, das wollte ich auf jeden Fall mal erwähnt haben.

03:06:58.350 --> 03:06:59.970
Das kann man sich mal anschauen.

03:06:59.970 --> 03:07:02.190
Es gibt dann da so Teile von,

03:07:02.190 --> 03:07:05.330
wo man auch CSVs automatisch in SQLite-Datenbanken umwandeln kann.

03:07:05.330 --> 03:07:08.690
Auch interessant, dass man da so frei SQL-Statements irgendwie eingeben kann.

03:07:08.690 --> 03:07:09.630
Das geht ja auch kaum.

03:07:09.630 --> 03:07:12.410
Aber das geht halt deswegen, weil man bei SQLite auch sagen kann,

03:07:12.410 --> 03:07:13.970
oh, das ist jetzt ein Read-Only-Datenbank.

03:07:13.970 --> 03:07:17.190
Und dann kann man halt mit Statements nichts mehr kaputt machen.

03:07:17.190 --> 03:07:22.630
Ja, das ist halt ein sehr schönes Projekt.

03:07:22.630 --> 03:07:24.510
Ja.

03:07:24.510 --> 03:07:26.450
Dann, genau.

03:07:26.450 --> 03:07:27.450
Also, auch wie man auf Datenbank...

03:07:28.350 --> 03:07:29.350
Von Python aus zugreift.

03:07:29.350 --> 03:07:40.250
Es gibt so Async-PG als asynchroner Datenbank-Client für Python.

03:07:40.250 --> 03:07:41.790
Das wird noch sehr interessant.

03:07:41.790 --> 03:07:43.430
Also, das ist notar noch ein Problem.

03:07:43.430 --> 03:07:49.470
Also, Psycho-PG ist halt so der Standard-Postgres-Datenbank-Client für Python.

03:07:49.470 --> 03:07:52.250
Und der kann aber nur Textprotokoll und nicht Binary.

03:07:52.250 --> 03:07:53.490
Ist halt schon relativ schnell.

03:07:53.490 --> 03:07:56.730
Aber es geht halt mit dem Binärprotokoll halt noch schneller.

03:07:56.730 --> 03:07:58.330
Und er ist halt nicht asynchron.

03:07:58.350 --> 03:08:00.650
Also, was halt ein Problem ist,

03:08:00.650 --> 03:08:02.250
wenn man jetzt zum Beispiel bei Postgres,

03:08:02.250 --> 03:08:06.450
macht man jetzt Volltext-Suche und Navigation auf einer Webseite.

03:08:06.450 --> 03:08:08.450
Dann hat man, wenn man das mit Django macht,

03:08:08.450 --> 03:08:09.210
Django ist auch synchron.

03:08:09.210 --> 03:08:12.770
Dann macht man halt einmal,

03:08:12.770 --> 03:08:14.690
hat jetzt Facet-Navigation.

03:08:14.690 --> 03:08:17.110
Das heißt, man muss halt an den Facetten,

03:08:17.110 --> 03:08:18.570
das heißt Text oder Kategorien

03:08:18.570 --> 03:08:22.530
oder irgendwelchen anderen Monaten

03:08:22.530 --> 03:08:25.030
oder was auch immer man halt navigierbar halten will,

03:08:25.030 --> 03:08:26.870
schreibt man halt so Counts dran.

03:08:26.870 --> 03:08:27.850
Oder man muss halt überhaupt wissen,

03:08:27.950 --> 03:08:28.930
was hat ein Count von größer Null,

03:08:28.930 --> 03:08:30.650
damit man diese Facette anzeigt oder nicht anzeigt.

03:08:30.650 --> 03:08:32.830
Das sind halt zwei unterschiedliche Statements.

03:08:32.830 --> 03:08:33.990
Man kriegt einmal die Suchergebnisse

03:08:33.990 --> 03:08:35.470
und dann macht man nochmal ein Statement,

03:08:35.470 --> 03:08:36.630
um die Counts zu holen.

03:08:36.630 --> 03:08:38.870
Und meistens hat man aber nicht nur diese zwei,

03:08:38.870 --> 03:08:39.510
sondern noch ein paar mehr.

03:08:39.510 --> 03:08:41.730
Und das ist halt jedes Mal ein Datenbank-Roundtrip.

03:08:41.730 --> 03:08:44.310
Das ist jedes Mal, dauert das irgendwie ein paar Millisekunden.

03:08:44.310 --> 03:08:46.470
Also bei den Suchanfragen, bei den Counts,

03:08:46.470 --> 03:08:48.230
dauert es sogar so irgendwie 30, 40 Millisekunden.

03:08:48.230 --> 03:08:52.610
Sodass man halt bei so einer normalen Navigation auf einer Seite

03:08:52.610 --> 03:08:56.190
wahrscheinlich schon so 150 Millisekunden nur SQL-Anfragen hat.

03:08:56.190 --> 03:08:57.930
Und dann ist man schon bei,

03:08:57.950 --> 03:08:59.450
wenn dann das Template gerendert wird,

03:08:59.450 --> 03:09:01.090
ist man leicht bei 400, 500 Millisekunden.

03:09:01.090 --> 03:09:02.710
Und das ist halt dann schon relativ lang.

03:09:02.710 --> 03:09:03.950
Das ist schon viel für eine Webseite.

03:09:03.950 --> 03:09:05.550
Eigentlich ein bisschen zu viel.

03:09:05.550 --> 03:09:08.290
Und man könnte es leicht deutlich drücken,

03:09:08.290 --> 03:09:09.930
wenn jetzt diese Statements,

03:09:09.930 --> 03:09:11.130
die ja nicht voneinander abhängen,

03:09:11.130 --> 03:09:13.150
sondern die man auch parallel abfeuern könnte,

03:09:13.150 --> 03:09:15.290
tatsächlich parallel an die Datenbank gestellt würden.

03:09:15.290 --> 03:09:17.710
Und dann hat man nur noch,

03:09:17.710 --> 03:09:21.250
ist die Latenz oder die Zeit, die man braucht,

03:09:21.250 --> 03:09:24.070
um SQL-Abfragen zu machen in dem Webfrontend,

03:09:24.070 --> 03:09:26.690
dauert nur noch so lange wie das längste Statement.

03:09:26.690 --> 03:09:27.750
Und alle anderen Sachen,

03:09:27.790 --> 03:09:28.330
die sind halt vorher da.

03:09:28.330 --> 03:09:29.510
Und das würde halt wahrscheinlich bedeuten,

03:09:29.510 --> 03:09:31.450
dass dann ist man runter auf 50 Millisekunden oder so.

03:09:31.450 --> 03:09:32.650
Dann hat man 100 Millisekunden gespart.

03:09:32.650 --> 03:09:33.610
Das wäre ziemlich cool.

03:09:33.610 --> 03:09:36.270
Aber dafür müsste halt Django asynchron sein.

03:09:36.270 --> 03:09:39.770
Dafür müsste man halt irgendwie Async-PG verwenden

03:09:39.770 --> 03:09:41.650
statt Psycho-PG.

03:09:41.650 --> 03:09:44.010
Und das wird alles noch ein bisschen dauern.

03:09:44.010 --> 03:09:45.210
Wahrscheinlich Jahre, fürchte ich.

03:09:45.210 --> 03:09:48.530
Ist auch so, dass der Autor von Django Channels,

03:09:48.530 --> 03:09:52.910
das ist diese Geschichte mit den Web-Sockets,

03:09:52.910 --> 03:09:55.330
dass man halt bidirektionale Kommunikation

03:09:55.330 --> 03:09:57.530
zwischen Client und Server hat bei Web-Anwendungen.

03:09:57.630 --> 03:10:01.730
Der hat jetzt dieses Projekt so ein bisschen aufgegeben

03:10:01.730 --> 03:10:03.330
oder ist nicht mehr Maintainer davon.

03:10:03.330 --> 03:10:05.390
Und das, was man jetzt macht,

03:10:05.390 --> 03:10:08.290
ist jetzt der Versuch, Django Async fähig zu machen.

03:10:08.290 --> 03:10:09.970
Ich bin mal gespannt, wie das wird.

03:10:09.970 --> 03:10:11.190
Das war ja auch in der Django-Folge,

03:10:11.190 --> 03:10:12.370
hatten wir das ja irgendwie kurz,

03:10:12.370 --> 03:10:15.350
ob das vielleicht eventuell eine Richtung wäre,

03:10:15.350 --> 03:10:16.510
in die sich Django entwickeln könnte.

03:10:16.510 --> 03:10:18.070
Und ja, es sieht danach aus,

03:10:18.070 --> 03:10:19.410
so ein bisschen als ob es kommen würde.

03:10:19.410 --> 03:10:23.730
Und damit sind wir im Grunde durch.

03:10:23.730 --> 03:10:25.270
Sind wir durch mit einer Mammut-Folge.

03:10:25.270 --> 03:10:27.310
Wenn ihr es bis hierhin geschafft habt, also gut ab.

03:10:27.470 --> 03:10:28.850
Es wird jetzt einiges mehr über Datenbanken,

03:10:28.850 --> 03:10:30.050
dass man damit alles anstrengen kann.

03:10:30.050 --> 03:10:32.390
Ja, schöne Sache.

03:10:32.390 --> 03:10:34.510
Super, dass ihr dabei wart.

03:10:34.510 --> 03:10:37.370
Und ja, wo ihr auch immer hier seid,

03:10:37.370 --> 03:10:38.110
schönen Tag und so weiter.

03:10:38.110 --> 03:10:40.830
Wenn ihr Fragen habt, hallo.at.peisenpodcast.de

03:10:40.830 --> 03:10:43.250
Ja, dann bis zum nächsten Mal.

03:10:43.250 --> 03:10:44.350
Auf Wiedersehen. Tschüss.