WEBVTT 00:00:19.200 --> 00:00:25.520 Hallihallo, herzlich willkommen zu Radiots Binärgewitter No 00:00:26.160 --> 00:00:26.720 One. 00:00:27.440 --> 00:00:30.800 Und ja, ist so ein bisschen unser neues Format hier. 00:00:30.960 --> 00:00:33.200 Ihr habt den Namen bestimmt schon mal ein bisschen gehört. 00:00:33.280 --> 00:00:37.680 Wir haben ihn in der einen oder anderen Sendung schon erwähnt und jetzt haben wir es endlich mal geschafft, 00:00:37.760 --> 00:00:40.800 uns hier in Stuttgart zusammenzusetzen. 00:00:40.960 --> 00:00:46.560 Und ja, ich habe, oder ich würde mal sagen, das ist so eine Geek Talk-Runde. 00:00:47.120 --> 00:00:51.040 Also so ein bisschen wie auch in unserer Talks-Sendung sitzen wir hier zusammen, 00:00:51.200 --> 00:00:56.800 aber der Unterschied ist, wir nehmen uns nur ein Thema vor und versuchen das mal durchzukauen. 00:00:57.120 --> 00:01:04.000 Wir veranschlagen jetzt mal so circa zwei Stunden und das heutige Thema der ersten Ausgabe ist No 00:01:04.240 --> 00:01:05.200 SQL. 00:01:05.520 --> 00:01:11.360 Und da sind heute dabei Dirk, ehemaliger DBA, 00:01:11.600 --> 00:01:18.160 also Datenbankadministrator für DB2 und Oracle und zurzeit irgendein Unix-Futzi in so einer Bank. 00:01:18.480 --> 00:01:19.040 Genau. 00:01:19.440 --> 00:01:20.160 Ganz genau. 00:01:20.800 --> 00:01:21.920 Dann Marc. 00:01:22.320 --> 00:01:22.880 Hallo. 00:01:23.440 --> 00:01:30.400 Der irgendwas macht sich auf jeden Fall in seiner Masterthesis mit NoSQL beschäftigt hat, 00:01:30.560 --> 00:01:32.800 dann aber am Ende doch wieder MySQL benutzt hat. 00:01:33.120 --> 00:01:34.080 Unter anderem. 00:01:34.880 --> 00:01:36.320 Und Flydi ist da. 00:01:36.560 --> 00:01:37.040 Hallo. 00:01:37.280 --> 00:01:39.040 Der macht auch irgendwas mit MySQL. 00:01:39.280 --> 00:01:39.760 Und es moderiert. 00:01:40.800 --> 00:01:42.640 Und es moderiert der Ingo, der nichts macht. 00:01:42.960 --> 00:01:46.800 Genau, ich mache nichts, ich bin nur die, ich bin ja sowieso synthetisiert. 00:01:46.960 --> 00:01:49.040 Du bist, ich weiß ja, ich bin ja in diesem Mischpult. 00:01:49.520 --> 00:01:52.480 Habe ich von gelesen, aber es gibt mittlerweile echt fast Lebensecht. 00:01:52.640 --> 00:01:52.800 Was? 00:01:52.880 --> 00:01:53.760 Da hast du von gelesen. 00:01:53.840 --> 00:01:55.760 Ja, dass du eigentlich nur eine synthetische Stimme bist. 00:01:56.320 --> 00:01:57.920 Da gibt es schon Artikel drüber im Internet. 00:01:58.320 --> 00:01:58.960 Ganz Papers drüber. 00:01:59.280 --> 00:02:00.800 Ganze Papers, wie das funktioniert und so. 00:02:01.120 --> 00:02:02.800 Wir haben das eindeutig bewiesen, das ist einfach so. 00:02:02.960 --> 00:02:03.200 Genau, also. 00:02:03.440 --> 00:02:04.240 Das ist jetzt halt mit Leben. 00:02:04.640 --> 00:02:06.240 Er sieht Lisa und jetzt Ingo. 00:02:06.960 --> 00:02:11.040 Genau, und ich bestehe den Turing-Test, wollte ich nur mal dazu sagen. 00:02:11.600 --> 00:02:16.000 Wir versuchen, also die Sendung ist ein bisschen geektalkig, das heißt also, 00:02:16.560 --> 00:02:21.200 wir setzen hier ein paar grundlegende Sachen an Informatik voraus. 00:02:21.520 --> 00:02:24.560 Aber so spezielle Themen versuchen wir zu erklären. 00:02:24.800 --> 00:02:30.240 Also, ja, wer schon mal von einem Linux gesessen hat und so ein bisschen sich mit einer Weile damit 00:02:30.240 --> 00:02:31.760 beschäftigt, kann hier gut folgen. 00:02:32.000 --> 00:02:34.240 Wer nicht, der ist hier vielleicht falsch. 00:02:34.640 --> 00:02:36.320 Oder sollte in der Wikipedia noch schlagen. 00:02:36.560 --> 00:02:42.000 Oder wir machen immer eine lange Linkliste dazu, muss ich dann halt nochmal ein bisschen einlesen. 00:02:42.160 --> 00:02:48.080 Aber die Themen, die speziell sind, also das, was um NoSQL, wenn wir hier vom Kapp-Theorem nachher reden oder 00:02:48.080 --> 00:02:50.160 so, solche Sachen werden wir erklären. 00:02:50.320 --> 00:02:55.280 Ganz am Anfang wird es mal darum gehen, was NoSQL überhaupt ist, was es sein soll. 00:02:55.440 --> 00:03:01.280 Wer ihr das schon weiß, der kann jetzt mal so zehn Minuten vorskippen und dann zu den weiteren spannenden 00:03:01.360 --> 00:03:05.040 Themen kommen, aber wir würden vielleicht ganz am Anfang mal sagen, 00:03:06.640 --> 00:03:08.880 was ist NoSQL eigentlich? 00:03:09.040 --> 00:03:13.280 FlyDy, magst du das vielleicht mal so in zwei, drei Sätzen zusammenfassen? 00:03:14.080 --> 00:03:18.320 Also der Begriff NoSQL steht ja, wie viele vielleicht denken, 00:03:18.560 --> 00:03:24.800 werden nicht für kein SQL, sondern für not only SQL, also nicht ausschließlich SQL. 00:03:25.680 --> 00:03:30.880 Und da geht es im Endeffekt darum, ja, 00:03:31.120 --> 00:03:35.600 einen Namen für eine Familie von Datenbanksystemen zu finden, 00:03:36.240 --> 00:03:40.400 die bisher keinen Namen hatten und die sich eigentlich alle durch den Fakt auszeichnen, 00:03:40.560 --> 00:03:43.520 dass sie kein SQL als Abfragesprache benutzen. 00:03:43.840 --> 00:03:49.840 Und auch normalerweise nicht das relationale Modell, das wir von den bisherigen relationalen Datenbanken seit 00:03:49.840 --> 00:03:51.280 Jahrzehnten kennen. 00:03:52.000 --> 00:03:52.960 Okay, ja. 00:03:53.600 --> 00:03:58.800 Und wenn wir dann gerade schon bei normalen Datenbanken sind, die es ja schon seit den, 00:03:58.880 --> 00:04:00.560 keine Ahnung, 60ern, 70ern. 00:04:01.120 --> 00:04:05.040 Ich glaube, da gab es dieses Paper von Visokott, das relationale Modell, 00:04:05.120 --> 00:04:08.240 das hat es eigentlich alles eingeläutet. 00:04:08.560 --> 00:04:13.840 Sagen wir 1960, 70 irgend sowas in dem Dreh gibt, also schon Steinalt. 00:04:15.680 --> 00:04:19.200 Also ich meine, in der Informationstechnik würde man sagen, das ist Steinzeit. 00:04:19.360 --> 00:04:19.760 Definitiv. 00:04:20.000 --> 00:04:23.280 Also es ändert sich ja so viel jedes Jahr. 00:04:23.520 --> 00:04:28.960 Und ja, wofür braucht man dann so Datenbanken im Allgemeinen? 00:04:30.160 --> 00:04:30.480 Ja. 00:04:32.160 --> 00:04:32.720 Ich fange mal an. 00:04:32.880 --> 00:04:33.360 Ja, genau. 00:04:33.600 --> 00:04:38.880 Okay, also grundlegend ist eine Datenbank eigentlich ein Software-System, 00:04:39.120 --> 00:04:44.000 das generell irgendwelche Sachen speichert, auf die ihr später gerne mal wieder zugreifen wollt. 00:04:44.240 --> 00:04:47.600 Das ist, ich sag mal, eins der einfachsten Themen und eins der Sachen, 00:04:47.680 --> 00:04:51.120 wie es wahrscheinlich von so Anwendungsentwicklern am meisten eingesetzt wird, 00:04:51.280 --> 00:04:53.600 ist einfach Anwendungsdaten zu speichern. 00:04:53.680 --> 00:04:57.680 Bedeutet, ihr habt da irgendeine Web-Anwendung gemacht und da gibt es irgendwie ein paar Benutzer drin von mir 00:04:57.680 --> 00:04:58.000 aus. 00:04:58.400 --> 00:05:02.720 Und dass ihr die Benutzer nicht nur irgendwie bei euch im Programm im RAM haltet, 00:05:02.800 --> 00:05:07.200 sondern dass die auch nach einem Serverneustadt mal da sind, muss man die Benutzer ja irgendwo hin kopieren 00:05:07.200 --> 00:05:10.800 auf Festplatte, dass man die auch nachher wieder laden kann. 00:05:11.200 --> 00:05:16.320 Und das ist ein Anwendungszweck von Datenbank, einfach die Persistenz von so Anwendungsdaten sicherstellen. 00:05:16.400 --> 00:05:22.160 Bedeutet, ihr nehmt eure Daten, werft die wie auch immer in ein Datenbanksystem rein und wenn der Benutzer 00:05:22.160 --> 00:05:25.360 später wiederkommt, sagt ihr, ah, Andreas Müller, okay, kurz gucken, 00:05:25.440 --> 00:05:29.360 ja, hab deine Daten und du kannst ihm dann seine Freundesliste und was weiß ich alles zeigen. 00:05:29.520 --> 00:05:35.520 Das ist so eine Art, Datenbank zu benutzen, die eigentlich auch recht, ich sag mal, beliebt ist. 00:05:35.680 --> 00:05:36.720 Da gibt es aber noch mehr. 00:05:36.800 --> 00:05:37.920 Ich gebe jetzt einfach mal weiter. 00:05:38.080 --> 00:05:38.720 Da gibt es noch mehr. 00:05:38.880 --> 00:05:39.040 Ja. 00:05:39.200 --> 00:05:42.160 Also Datenbank ist natürlich Daten und Bank und die Sachen Daten. 00:05:42.720 --> 00:05:44.560 Und du arbeitest in der Bank, also bist du dafür quasi. 00:05:45.200 --> 00:05:50.880 Der Name kommt schon ein Stück weit auch daher im Deutschen, weil man halt die Daten sicher in einer Anwendung 00:05:50.880 --> 00:05:55.680 oder auf der Platte aufbewahren möchte und sie möglichst auch wiederfinden möchte in einem Stück und so, 00:05:55.760 --> 00:05:57.040 wie sie vorher reingegeben wurden. 00:05:57.360 --> 00:05:58.720 Das ist erstmal das Erste. 00:06:00.160 --> 00:06:04.160 Und das zweite ist, dass man eine sogenannte Transaktionssicherheit hat. 00:06:04.240 --> 00:06:06.960 Das heißt, dass man, wenn man Abfragen auf die Datenbank durchführt, 00:06:07.120 --> 00:06:11.200 dass man, am besten kann man das bei einer Gelderbhebung beim Bankautomaten sehen, 00:06:11.440 --> 00:06:15.280 dass das Geld erst dann dem Konto belastet wird, wenn das Geld auch wirklich vorne aus dem Automaten 00:06:15.280 --> 00:06:15.760 rauskommt. 00:06:15.840 --> 00:06:19.920 Das heißt, es werden mehrere Aktionen zu einer übergeordneten Aktion zusammengezogen. 00:06:20.000 --> 00:06:25.040 Und erst wenn alle Teile dieser Aktionen funktioniert haben, dann erst wird das in der Datenbank 00:06:25.040 --> 00:06:25.920 festgeschrieben. 00:06:26.080 --> 00:06:29.680 Das ist transaktionsorientiertes Datenbankmanagement, wenn man es so will. 00:06:29.840 --> 00:06:30.080 Richtig. 00:06:30.240 --> 00:06:33.360 Ist auch nicht bei allen Datenbanken oder bei allen, ich sag mal, doch, 00:06:33.520 --> 00:06:36.560 Datenbanken, sagen wir es mal direkt so, ist auch nicht bei allen verfügbar. 00:06:36.640 --> 00:06:39.200 Also viele von den Sachen, über die wir heute reden, das NoSgeldzeug, 00:06:39.360 --> 00:06:41.680 die haben das Konzept von Transaktionen einfach nicht. 00:06:41.920 --> 00:06:44.880 Weil gerade bei einer Bank, klar, braucht man auf jeden Fall, ist doof, 00:06:44.960 --> 00:06:48.160 wenn da auf einmal 100 Euro wechseln, aber irgendwo nicht 100 Euro hinzukommen. 00:06:48.400 --> 00:06:51.680 Und na gut, ich meine, die Bank wird es freuen, aber die Kunden werden deshalb nicht verärgert sein. 00:06:52.080 --> 00:06:55.200 Die Bank wird es aber nicht freuen, wenn es umgekehrt ist, wenn das Red aus dem Automaten kommt und irgendwie 00:06:55.200 --> 00:06:56.240 nicht im Konto belastet wird. 00:06:56.400 --> 00:06:56.480 Genau. 00:06:57.200 --> 00:07:04.160 Also das ist eine Problemdomäne, die durch zum Beispiel relationale bisherige Datenbanksysteme sehr gut 00:07:04.160 --> 00:07:05.040 gelöst wird. 00:07:06.000 --> 00:07:07.440 Es gibt aber noch einen dritten. 00:07:08.400 --> 00:07:13.360 Warte mal, wo wir gerade dabei waren, also ich komme aus meiner Datenbankvorlesung, 00:07:13.440 --> 00:07:16.480 die schon irgendwie Jahrzehnte her ist, kommt mir dieses ACED. 00:07:17.680 --> 00:07:19.840 Dieses Ich habe es gerade nochmal gemacht. 00:07:24.640 --> 00:07:27.280 Isolation und Durability. 00:07:28.560 --> 00:07:29.040 Genau. 00:07:29.200 --> 00:07:35.840 Ja, das sind so diese Eigenschaften, die man Datenbankmanagementsystemen oder auch teilweise verteilten 00:07:35.840 --> 00:07:41.840 Systemen generell so mehr oder weniger zuweist und die können die einzelnen Teile davon, 00:07:41.920 --> 00:07:44.720 also das sind, die müssen nicht alles implementieren, aber das sind, 00:07:44.880 --> 00:07:48.080 ich sag mal, eine schöne Gliederung, wie man so ein System beschreiben kann. 00:07:48.240 --> 00:07:49.600 Kann man sagen, wie sieht denn das aus? 00:07:49.680 --> 00:07:52.400 Hat der überhaupt Konsistenz von den Daten? 00:07:52.640 --> 00:07:55.760 Wenn ich da beim einen was wegtun, beim anderen was dazu und zwischendrin crasht was, 00:07:55.840 --> 00:07:57.120 wie sieht denn das mit den Daten aus? 00:07:57.360 --> 00:08:03.280 Das ist eben dieses Acid-Prinzip, das, ich sag mal so, die Verlässlichkeit von den Systemen schön beschreibt. 00:08:03.440 --> 00:08:06.880 Und das Problem an dem Ganzen ist eben, Acid kostet halt Performance. 00:08:07.040 --> 00:08:09.840 Man muss mehr machen, man muss mehr Sicherheitsvorkehrungen treffen. 00:08:10.480 --> 00:08:11.520 Dafür hat man mehr Sicherheit. 00:08:11.680 --> 00:08:14.960 Dafür wird man mehr Sicherheit, dafür hat man aber auch langsamer und es gibt teilweise Sachen, 00:08:15.040 --> 00:08:17.200 wo man vielleicht gar nicht so viel Sicherheit braucht. 00:08:17.360 --> 00:08:21.040 Ich meine, wen interessiert es, ob ein Tweet irgendwie auf Twitter mal weg ist? 00:08:21.280 --> 00:08:21.920 Ja, ich glaube, man kann da. 00:08:23.520 --> 00:08:26.640 Ja, aber alle anderen Milliardenleute, die natürlich Twitter nutzen, nicht. 00:08:26.960 --> 00:08:29.920 Aber ich meine, man kann da ja mal vielleicht zwei Extrembeispiele gegeneinander stellen. 00:08:30.000 --> 00:08:34.240 Ich meine, man hat auf einmal auf der einen Seite so, wo es jetzt nicht so unbedingt wichtig ist, 00:08:34.880 --> 00:08:38.000 diese ganzen Anforderungen zu erfüllen, hat man vielleicht mal den Tweet, 00:08:38.080 --> 00:08:41.840 bei dem es jetzt vielleicht nicht unbedingt relevant ist, ob der jetzt bei allen ankommt. 00:08:42.000 --> 00:08:43.120 Oder wann der bei allen ankommt. 00:08:43.680 --> 00:08:45.440 Oder wann man bei allen ankommt. 00:08:45.600 --> 00:08:51.520 Auf der anderen Seite hat man jetzt vielleicht mal Geldautomaten, wo man tatsächlich sicherstellen will, 00:08:51.600 --> 00:08:56.080 dass dieses Geld, was jetzt hier abgehoben wird, auch tatsächlich dann auch vom Konto abgebucht wird. 00:08:56.160 --> 00:09:01.360 Und nicht, dass man jetzt irgendwie hier, keine Ahnung, vielleicht zwei Bankkarten hat oder sonst irgendwas 00:09:01.440 --> 00:09:07.360 und an zwei Automaten gleichzeitig was abhebt und dann im Endeffekt nur das Geld nur einmal abgebucht wird. 00:09:07.520 --> 00:09:14.000 Also es wäre ja für die Bank relativ schädigend. 00:09:14.240 --> 00:09:17.920 Richtig, das ist dieses Asset-Prinzip, sowieso auf Englisch, AC-ID, 00:09:18.080 --> 00:09:22.400 gibt es in der Wikipedia auch einen schönen Artikel drüber, falls sich da jemand dran ergötzen will. 00:09:22.640 --> 00:09:28.160 Genau, aber wenn ich jetzt Daten speichere, Anwendungsdaten, warum tue ich das in einem 00:09:28.480 --> 00:09:34.240 Datenbankmanagementsystem und nicht einfach so auf die Festplatte in ein Dateisystem? 00:09:35.360 --> 00:09:40.880 Da gibt es zumindest noch die dritte Sache, die auch für Datenbanken spricht, in Verteilung zum Beispiel. 00:09:41.120 --> 00:09:46.000 Wenn das in deinem Dateisystem, deinem Standarddateisystem, kannst dir auch Dateien speichern, 00:09:46.080 --> 00:09:49.280 das ist ja super, die kommen auch normalerweise so zurück, wie du die da hingelegt hast. 00:09:49.600 --> 00:09:52.720 Das Problem ist, dass du so ziemlich der Einzige bist, der darauf Zugriff hat. 00:09:52.800 --> 00:09:57.520 Außer du packst dann halt wieder was drüber wie irgendein Samba oder FDP oder irgendein anderes Protokoll, 00:09:57.600 --> 00:10:01.520 das dafür verantwortlich ist, das Zeug hin und her zu schicken und verfügbar zu machen. 00:10:01.760 --> 00:10:06.160 Und das ist zum Beispiel eine Aufgabe, wo Datenbanken ganz nett sind. 00:10:06.320 --> 00:10:11.040 Die meisten Datenbanken haben ein Netzwerkinterface, die die Daten nach außen auch öffnen. 00:10:11.280 --> 00:10:16.320 Bedeutet, du hast dann irgendwie fünf Web-Server und die würden alle gerne auf dieselben Daten zugreifen. 00:10:16.400 --> 00:10:19.200 Das bedeutet jetzt nicht, dass die alle auf demselben Rechner laufen müssen, 00:10:19.280 --> 00:10:21.760 sondern so eine Datenbank bietet dir auch eine schöne Möglichkeit an, 00:10:21.840 --> 00:10:26.560 deine Daten nach außen anzubieten und auch Daten von außen entgegenzunehmen. 00:10:27.920 --> 00:10:28.240 Ja. 00:10:29.520 --> 00:10:32.240 Ich glaube, richtig interessant wird es halt auch, wenn man mal den Fall hat, 00:10:32.320 --> 00:10:37.200 in dem die entweder die Datenmenge oder die Rechenleistung auf einem Rechner nicht ausreichen und man die 00:10:37.200 --> 00:10:39.680 Daten dann gezwungenermaßen verteilen muss. 00:10:39.920 --> 00:10:43.920 Und sowas bieten halt Datenbanksysteme im Endeffekt auch die Möglichkeit, 00:10:44.240 --> 00:10:48.720 sowohl seine Daten als auch jetzt irgendwie die Rechenzeit, 00:10:48.800 --> 00:10:54.000 die benötigt wird, um gewisse Abfragen zu erledigen, auf mehrere Maschinen zu verteilen und somit performanter 00:10:54.320 --> 00:10:58.160 und vielleicht auch besser verfügbar zu sein. 00:10:58.320 --> 00:10:58.640 Genau. 00:10:59.120 --> 00:11:00.800 Was kann ich noch mit Datenbanken machen? 00:11:01.280 --> 00:11:05.840 Was man zum Beispiel mit Dateisystemen nicht machen kann oder nicht anständig machen kann aktuell, 00:11:06.320 --> 00:11:07.760 suchen nach Inhalten. 00:11:08.000 --> 00:11:14.000 Ich meine, das kann zwar so, keine Ahnung, der Mac hat sein Spotlight und Windows hat seinen komischen Hund, 00:11:14.080 --> 00:11:15.360 der da im Kreis rumrennt. 00:11:15.600 --> 00:11:16.640 Das kann nicht, wie der heißt. 00:11:18.640 --> 00:11:20.240 Bei Linux gibt es dann Beagle, genau. 00:11:20.560 --> 00:11:20.960 Strichy. 00:11:21.280 --> 00:11:25.760 Richtig, aber das ist ja alles, was das, was ein Dateisystem nicht bietet, 00:11:25.920 --> 00:11:30.640 nämlich die verstehen deine Daten nicht nur als so Blob, 00:11:30.720 --> 00:11:33.680 den sie eigentlich nur rein und rausreichen können und dass man irgendjemand sagen kann, 00:11:33.760 --> 00:11:36.480 ich hätte gerne die Mitte davon, das kriegt ein Dateisystem ja auch noch hin, 00:11:36.640 --> 00:11:39.360 sondern die verstehen deine Daten wirklich als Dokumente. 00:11:39.440 --> 00:11:43.200 Und da werden wir später auch noch dazukommen, da gibt es einen Haufen Datenbanken, die das auch tun. 00:11:43.360 --> 00:11:47.120 Jetzt nicht alle, aber es gibt einige, die auch wissen, dass, wenn da zum Beispiel, 00:11:47.840 --> 00:11:52.800 keine Ahnung, Name Jürgen Alter 52 drin steht, dass 52 eine Zahl ist. 00:11:52.960 --> 00:11:56.560 Und dann kann man vielen Datenbankensystemen auch sagen, du, zähl da mal eins dazu. 00:11:56.800 --> 00:12:00.400 Und dann wissen die, wenn ich 52 plus 1 mache, ist das 53. 00:12:00.640 --> 00:12:04.640 Ein Dateisystem rafft es nicht so ganz, wenn du eben sagst, hier die Datei heißt 5.jpg, 00:12:04.720 --> 00:12:05.920 addier da mal zwei dazu. 00:12:06.000 --> 00:12:07.520 Da denke ich dann auch so, hä, was? 00:12:08.400 --> 00:12:09.840 Wobei wir da auch einen Unterschied machen müssen. 00:12:09.920 --> 00:12:12.480 Also ein Dateisystem ist nicht anderes als ein Speicherort für Daten. 00:12:13.040 --> 00:12:13.200 Genau. 00:12:13.440 --> 00:12:18.080 Genau, da ist keine Logik implementiert, das ist einfach nur eine Möglichkeit, eine Datei irgendwo zu lagern. 00:12:18.240 --> 00:12:18.560 Richtig. 00:12:18.720 --> 00:12:22.560 Und eine darauf aufgesetzte Logik, die könnte ja auch ein Grab sein, 00:12:22.640 --> 00:12:25.680 auf dem Linux zum Beispiel, die einfach die Daten im Volltext durchsucht, 00:12:25.760 --> 00:12:26.880 das ist wieder ein anderer Punkt. 00:12:27.040 --> 00:12:27.280 Richtig. 00:12:27.520 --> 00:12:31.200 Und ein Datenbanksystem hat halt eine einheitliche Oberfläche für Daten, 00:12:31.520 --> 00:12:34.160 um Daten reinzubringen und auch Daten wieder rauszuzusetzen. 00:12:34.640 --> 00:12:39.440 Das ist sowohl in der Lage, also die Daten auch ganz normal abzuspeichern und zu persistieren, 00:12:39.680 --> 00:12:46.160 als auch die Daten, die da tatsächlich gespeichert werden, zu verstehen und dann auf Anfragen zu 00:12:46.160 --> 00:12:48.720 reagieren, die diese Daten jetzt betreffen. 00:12:48.800 --> 00:12:55.680 Zum Beispiel gibt mir jetzt alle Benutzer, die Jürgen heißen und irgendwie über 50 Jahre alt sind zum 00:12:55.680 --> 00:12:55.920 Beispiel. 00:12:56.160 --> 00:12:56.960 Ja, das genau. 00:12:57.280 --> 00:13:00.880 Oder sie ist auch in der Lage, Daten zu manipulieren, ohne dass ich mir die Daten hole, 00:13:00.960 --> 00:13:03.360 manipuliere und das komplette Paket wieder zurückschicke. 00:13:03.520 --> 00:13:05.200 Sondern man sagt halt, mach mal eins mehr. 00:13:05.280 --> 00:13:07.040 Und der weiß dann, was das bedeutet. 00:13:07.200 --> 00:13:12.240 Das ist eben so die andere Möglichkeit, wie man Datenbanken einsetzt, gerade um Daten zu manipulieren bzw. 00:13:12.640 --> 00:13:13.920 effizient zu durchsuchen. 00:13:14.160 --> 00:13:17.600 Dass man dann sagt, gib mir alle Leute, die Jürgen Heißen in, keine Ahnung, 00:13:17.760 --> 00:13:20.240 Stuttgart wohnen, über 52 sind und und und. 00:13:20.560 --> 00:13:25.840 Und viele Datenbanksysteme, nach wie vor auch nicht alle, gerade relationale Datenbanksysteme tun sich da 00:13:25.840 --> 00:13:26.560 eigentlich sehr hervor. 00:13:26.640 --> 00:13:30.880 Die haben meist dieses Feature-Set, um Daten effizient zu durchsuchen. 00:13:31.280 --> 00:13:35.440 Bieten da auch dann entsprechende Indexierungsmöglichkeiten, Datenstrukturen, 00:13:35.520 --> 00:13:39.760 die das Ganze recht schnell halten und dass man halt nicht wie bei einem Grep einfach mal knallhart über alles 00:13:39.760 --> 00:13:44.160 drüber rast und dann so einen Full-Table-Scan heißt es dann quasi bei Datenbanken macht, 00:13:44.240 --> 00:13:47.840 sondern die bieten da auch Möglichkeiten an, das elegant und schnell zu machen. 00:13:48.080 --> 00:13:52.480 Das wäre dann die Möglichkeit, neben dem Archivieren auch Daten zu durchsuchen und zu manipulieren. 00:13:52.800 --> 00:13:56.960 Das läuft im Großen und Ganzen so ab, dass Daten in relationalen Datenbanken in Tabellen abgelegt werden und 00:13:56.960 --> 00:13:59.360 jede Spalte überlegt euch eine Adresse. 00:13:59.520 --> 00:14:02.400 Da gibt es einen Vornamen, einen Namen, eine Anrede, eine Straße, einen Ort, 00:14:02.560 --> 00:14:06.400 eine Postteilzahl und vielleicht ein Land und eine Telefonnummer und bla bla bla bla bla bla. 00:14:06.560 --> 00:14:10.320 Und wenn ich jetzt bei 80 Millionen Bundesbürgern danach nach allen Leuten suche, 00:14:10.400 --> 00:14:12.880 die Müller heißen, dann gibt es zwei Möglichkeiten, das zu machen. 00:14:13.120 --> 00:14:16.560 Ich gucke mir die ganze Tabelle von oben nach unten an und gucke überall im Namensfeld nach, 00:14:16.720 --> 00:14:18.800 hey, bist du ein Müller oder hey, bist du ein Müller? 00:14:19.040 --> 00:14:23.520 Oder ich lege einen sogenannten Index an und der Index ist nichts anderes als eine weitere Tabelle, 00:14:23.840 --> 00:14:28.160 in der alle Suchbegriffe, 00:14:28.240 --> 00:14:32.400 alle Namen aufgelistet sind und dazu die Datensatznummer, wo dieser Suchbegriff zu finden ist, 00:14:32.480 --> 00:14:33.280 letzten Endes. 00:14:33.440 --> 00:14:35.200 Und die werden in Bäumen organisiert. 00:14:35.440 --> 00:14:39.440 Genau, das ist dieser B Plus-Baumes zum Beispiel, das, womit sie eigentlich alle kochen. 00:14:39.680 --> 00:14:44.160 Muss man auch sagen, wir reden ja eigentlich über NoSQL-Systeme, aber die kochen alle nur mit Wasser. 00:14:44.320 --> 00:14:48.160 Also wenn die Daten indizieren, die benutzen alle B Plus-Bäume, erstaunlicherweise. 00:14:48.320 --> 00:14:53.840 Es gibt dann spezialisierte Indexe für, ich sag mal, die nicht so generisch sind, 00:14:53.920 --> 00:14:59.680 die dann vielleicht ein bisschen schneller sind, aber generell geben sich sowohl NoSQL als auch die RDBMS, 00:14:59.760 --> 00:15:03.520 die relationalen Datenbanksysteme, da recht wenig, was Indizierung angeht. 00:15:03.680 --> 00:15:05.040 Vielleicht bisschen in der Implementierung. 00:15:05.120 --> 00:15:08.880 Das ist einmal schneller, einmal nicht so schnell, aber ja, das ist halt die Suche, 00:15:08.960 --> 00:15:10.640 die sie entweder können oder nicht. 00:15:11.440 --> 00:15:14.960 Ja, vielleicht neben Archivierung und Suche gibt es natürlich auch noch eine Sache, 00:15:15.040 --> 00:15:19.680 die ein Dateisystem so auch, ja gut, sie können es so halbwegs. 00:15:19.760 --> 00:15:21.920 Es wäre die Navigation über Daten. 00:15:23.680 --> 00:15:27.680 Ja, also ein Dateisystem ist halt in der Hinsicht relativ beschränkt, 00:15:28.480 --> 00:15:33.600 dass es nur Daten in Baumstrukturen verwalten kann. 00:15:34.080 --> 00:15:40.320 Und man halt im Endeffekt relativ schwer tut, Daten semantisch richtig miteinander zu verknüpfen, 00:15:40.400 --> 00:15:42.160 was zum Beispiel jetzt Datenbanksysteme können. 00:15:42.240 --> 00:15:47.920 Also man kann sich jetzt mal ein Beispiel vorstellen, in dem man zum Beispiel jetzt ein Blog-System hat und 00:15:47.920 --> 00:15:54.400 man hat da Benutzer und die Benutzer können Posts schreiben und man kann dem Blocksystem dann halt im 00:15:54.400 --> 00:15:57.760 Endeffekt sagen, zeig mir jetzt mal alle Blockposts von diesem Benutzer an. 00:15:57.920 --> 00:16:02.160 Und somit hat man halt eine semantische Verknüpfung zwischen Benutzer und Blogpost. 00:16:02.720 --> 00:16:06.080 Und sowas lässt sich halt auf einem Dateisystem relativ schwer abbilden. 00:16:06.320 --> 00:16:08.960 Also möglich wäre es natürlich über so Sachen wie Soft- oder Hardlinks, 00:16:09.040 --> 00:16:10.640 die manche Dateisysteme ja unterstützen. 00:16:10.800 --> 00:16:13.600 Ich könnte mir da natürlich einen Ordner machen, der dann irgendwie, 00:16:13.760 --> 00:16:16.560 keine Ahnung, Blogposts von heißt, dann mache ich mir einen Unterordner, 00:16:16.640 --> 00:16:19.600 der heißt dann Andreas und da drin mache ich dann Links auf alle Textdateien, 00:16:19.680 --> 00:16:21.040 die Andreas gepostet hat. 00:16:21.200 --> 00:16:24.400 Nur erstens mal müsste das dann halt meine Anwendung selber machen. 00:16:24.720 --> 00:16:27.200 Geht, ist eigentlich auch kein Problem und wenn ich die alle haben will, 00:16:27.280 --> 00:16:30.000 dann gehe ich halt in den Ordner und sage, hier zeig mir alle Einträge. 00:16:30.960 --> 00:16:37.280 Das Problem ist nur, dass die da nicht so wunderbar designed für wurden und gerade wenn du was 00:16:37.600 --> 00:16:39.680 Neues machen willst, was bisher noch nicht da war. 00:16:39.760 --> 00:16:43.040 Also wenn halt einer sagt, ich hätte jetzt gerne mal alle Einträge von Andreas, 00:16:43.200 --> 00:16:48.320 die irgendwie mit das Wort Hund beinhalten, dann hast du echt ein Problem, 00:16:48.480 --> 00:16:50.000 das über Links nur abzubilden. 00:16:50.080 --> 00:16:53.680 Da musst du halt wieder dein Crepe rausholen und jede Menge Logik implementieren. 00:16:53.760 --> 00:16:57.360 Und diese Logik bieten viele Datenbanksysteme, also gerade relationale, 00:16:57.440 --> 00:17:00.640 einfach schon sauber implementiert und schnell für dich an. 00:17:00.960 --> 00:17:02.560 Die sind drauf spezialisiert, genau. 00:17:03.280 --> 00:17:08.560 Und also so gerade Daten zusammenstellen ist da eine recht schöne Sache in der Hinsicht. 00:17:09.200 --> 00:17:13.200 Das ist auch so das Letzte, was dann Datenbanksysteme auch noch teilweise machen, 00:17:13.280 --> 00:17:15.040 ist im Grenzbereich Reporting. 00:17:16.000 --> 00:17:21.760 Du hast eine Unmengen an Daten und die hast du halt so gelagert, dass dann halt Montagmorg der Businessmensch 00:17:21.760 --> 00:17:24.480 aus deiner Abteilung kommt und sagt, ah, wir brauchen alle Leute aus Peru, 00:17:24.560 --> 00:17:26.000 die bei uns was gekauft haben. 00:17:26.240 --> 00:17:32.480 Und das hast du dann zum ersten Mal gehört, aber deine Datenbank ermöglicht dir halt diese Daten halbwegs 00:17:32.480 --> 00:17:38.720 schnell rauszufiltern aus deinem Datenset und sollte der das öfter machen, 00:17:38.800 --> 00:17:43.360 dann holt man sich halt einen DBA oder einen Anbindungsentwickler, der was dafür versteht und kann dann auch 00:17:43.360 --> 00:17:45.200 entsprechende Indexe setzen, dass das auch schnell wird. 00:17:45.360 --> 00:17:47.840 Ein typischer bekannter Report ist ein Kontoauszug zum Beispiel. 00:17:48.400 --> 00:17:51.040 Da werden alle Buchungen rausgesucht, die genau zu meinem Konto passen. 00:17:51.120 --> 00:17:52.080 Oder eine Handyrechnung. 00:17:52.240 --> 00:17:52.880 Oder eine Handyrechnung. 00:17:53.280 --> 00:17:59.200 Der so einmal im Monat eine Abfrage gestartet wird, wie oft hat man denn telefoniert und mit wem und zu 00:17:59.200 --> 00:18:03.680 welchem Tarif und dann wird am Ende des Monats da halt eine Rechnung rausgeneriert. 00:18:03.920 --> 00:18:04.160 Genau. 00:18:04.640 --> 00:18:09.440 Das sind jetzt eigentlich so die Sachen, also nochmal Persistenz, Suchen in Daten, 00:18:09.600 --> 00:18:14.480 Navigation über Daten, dass man sich da irgendwie was zusammenstellt oder halt Reporting, 00:18:14.560 --> 00:18:15.600 was ja auch in die Richtung geht. 00:18:15.680 --> 00:18:19.600 Das ist, was Datenbanken alles können, aber was sie nicht können müssen. 00:18:19.920 --> 00:18:22.640 Genau, also normale, relationale Datenbanksystem. 00:18:22.960 --> 00:18:24.400 Implementieren das normalerweise alles. 00:18:24.480 --> 00:18:28.320 Das Problem ist halt, ihr könnt euch vorstellen, dieses ganze Suchen und Navigation und Reporting, 00:18:28.400 --> 00:18:29.760 das braucht alles ewig Zeit. 00:18:29.920 --> 00:18:34.480 Weil wenn jetzt jemand einen neuen Datensatz hinzufügt, dann fügt der nicht nur den Datensatz hinzu und damit 00:18:34.480 --> 00:18:37.040 hat sich, sondern dann denkt der Server, okay, jetzt schaue ich erstmal, 00:18:37.120 --> 00:18:41.040 welche Indexe muss ich denn jetzt updaten, fängt er an, seine Indexe dadurch abzudaten? 00:18:41.200 --> 00:18:44.240 Und der hat wesentlich mehr zu tun, als nur diese Daten zu speichern. 00:18:44.640 --> 00:18:48.960 Und ihr müsst da oft, gerade bei den relationalen Datenbanken, 00:18:49.040 --> 00:18:52.320 also den SQL-basierten Datenbanken, mit SQL drauf zugreifen. 00:18:52.400 --> 00:18:55.600 Ihr müsst da eine Abfragesprache lernen, die unglaublich mächtig ist. 00:18:55.680 --> 00:18:59.520 Damit könnt ihr echt super Sachen machen, aber eventuell wollt ihr das gar nicht. 00:18:59.680 --> 00:19:06.240 Twitter zum Beispiel irgendwie gibt mir alle Posts vom User, keine Ahnung, RB2K oder Radio Tux oder sonst was. 00:19:06.560 --> 00:19:10.480 Da gibt es gar nicht so viel zu tun, wenn du deine Daten sowieso schon so speichern kannst. 00:19:10.640 --> 00:19:13.920 Also wenn du echt ein klares Datenmodell hast, gibt es halt die Möglichkeit, 00:19:14.080 --> 00:19:20.800 das wesentlich schneller in einer Lösung anzubieten, die nicht Suche und Reporting und Navigation 00:19:20.800 --> 00:19:23.280 unterstützt, sondern einfach nur Daten raus, Daten rein und das war's. 00:19:23.600 --> 00:19:24.320 Weil es nicht braucht. 00:19:24.480 --> 00:19:28.400 Genau, aber dafür dann auch sehr schnell und eventuell ist es dann einfach, 00:19:28.480 --> 00:19:30.080 das Ding zum Beispiel verteilt aufzubauen. 00:19:30.160 --> 00:19:33.200 Und da in die Kerbe schlägt NoSQL so ein bisschen rein, würde ich sagen. 00:19:33.440 --> 00:19:36.640 Warum ist es einfacher, das verteilt aufzubauen? 00:19:36.880 --> 00:19:41.760 Äh, weil du zum Beispiel gerade so Sachen wie Reporting, die halt Joints brauchen, das ist, äh, 00:19:42.290 --> 00:19:44.690 Braucht ziemlich viel Logik dahinter, würde ich behaupten. 00:19:44.850 --> 00:19:48.770 Du brauchst auch, musst halt deine Server entsprechend an und deine Daten entsprechend partitionieren. 00:19:48.930 --> 00:19:51.330 Teure Systeme machen das vielleicht von alleine. 00:19:51.410 --> 00:19:57.330 Mit MySQL fängst du da ganz schön an, deine Entwickler so ein bisschen zum DBA zu mutieren oder dein DBA zu 00:19:57.330 --> 00:19:59.010 beschäftigen, die Daten zu verteilen. 00:19:59.330 --> 00:20:03.570 Es gibt halt Systeme, die extrem auf sowas spezialisiert sind, 00:20:03.650 --> 00:20:07.090 wo du dann einfach nur sagst, irgendwo einen Server hochfahren, sagen, 00:20:07.170 --> 00:20:10.290 hier sind eine anderen Freunde, hol dir mal die Daten und er macht komplett alles, 00:20:10.370 --> 00:20:14.450 was Load Balancing angeht, was Verteilen von Daten, Sicherheit, Replikation, 00:20:14.610 --> 00:20:15.810 alles automatisch. 00:20:16.130 --> 00:20:20.610 Kann dir dann aber halt leider auch nicht so elegant Reports erstellen, 00:20:20.690 --> 00:20:23.250 wie das dann zum Beispiel ein relationales System könnte. 00:20:23.650 --> 00:20:27.810 Und gut, das wäre natürlich alles möglich, also man kann die Dinge im Grunde beliebig kombinieren, 00:20:27.890 --> 00:20:30.930 aber es ist halt eine Leistung von den Programmierern der Datenbank, 00:20:31.010 --> 00:20:33.010 das dann auch noch schnellen fehlerfrei zu machen. 00:20:33.170 --> 00:20:36.690 Und wie gesagt, das ist so ein bisschen die Kerbe, wo NoSQL reinschlägt und sagt, 00:20:36.850 --> 00:20:41.490 ja, relationale Systeme sind super für viele Sachen, ich brauche aber gar nicht so was Kompliziertes. 00:20:41.570 --> 00:20:46.050 Ich will nicht, dass meine Entwickler da viel SQL schreiben müssen und irgendwie eventuell noch Objekte auf 00:20:46.050 --> 00:20:51.010 die relationalen Schemata abbilden und mappen und hin und her, sondern speich ein Objekt, 00:20:51.090 --> 00:20:53.570 gib ein Objekt zurück, mehr kann es nicht, mehr muss es aber auch nicht. 00:20:53.730 --> 00:20:57.970 Ja genau, also wo wir auch gerade beim Beispiel Twitter waren, 00:20:58.770 --> 00:21:03.730 die verwenden ja als Hauptpersistenzlayer immer noch MySQL. 00:21:04.850 --> 00:21:08.530 Haben da allerdings im Endeffekt, also nutzen die kaum Features davon, 00:21:08.610 --> 00:21:13.010 sondern die benutzen das im Endeffekt nur als Persistenzlayer, 00:21:13.250 --> 00:21:19.570 um ihre Tweets und ihre Benutzerdaten und so weiter einfach mal 00:21:19.570 --> 00:21:23.090 wegzuschreiben, dass sie sicher haben. 00:21:23.650 --> 00:21:30.450 Und im Endeffekt so Features wie Joints und so weiter funktionieren da halt bei dem Grad von Verteilung, 00:21:30.530 --> 00:21:33.810 wie man es bei so großen Web-Anwendungen hat, auch nicht mehr wirklich gut, 00:21:34.050 --> 00:21:39.970 weil so die Verteilung der Daten über extrem viele Server da halt einfach 00:21:41.250 --> 00:21:42.930 nicht mehr richtig funktioniert. 00:21:43.090 --> 00:21:43.330 Genau. 00:21:43.890 --> 00:21:47.810 Man kann sich das auch so vorstellen, dass so ein Datenbanksystem sowas wie ein Multifunktionswerkzeug ist 00:21:47.810 --> 00:21:52.370 oder ein Schweizer Taschenmesser und das kann die einzelnen Aufgaben nicht besonders gut, 00:21:52.690 --> 00:21:54.370 kann aber alles zusammen eben. 00:21:54.450 --> 00:21:55.890 Das können halt nicht so viele. 00:21:56.130 --> 00:22:01.010 Und so eine Spezialanwendung wie beispielsweise eine NoSQL-Datenbank, 00:22:01.090 --> 00:22:04.450 die kann halt dieses Spezialgebiet, was sie braucht, besonders gut und dafür den Rest halt. 00:22:04.610 --> 00:22:04.770 Richtig. 00:22:05.090 --> 00:22:09.010 Genau, mit der Kettensäge willst du dir kein Brot schmieren an Baumfällen, aber es geht ganz gut. 00:22:09.330 --> 00:22:12.450 Es geht einmal, aber im Schweiz-Taschenmesser Baumfällen ist dann auch doof. 00:22:12.930 --> 00:22:14.290 Das geht alles, muss man aber nicht. 00:22:14.770 --> 00:22:18.450 Und das ist, ich denke, das war auch so, also Objektdatenbanken, die gibt es ja auch schon lange, 00:22:18.530 --> 00:22:21.010 so spezialisierte Datenbanken, um Objekte abzulegen. 00:22:21.170 --> 00:22:27.570 Aber das war halt gut am Anfang hat man halt sich auf dieses SQL eingeschossen, 00:22:27.650 --> 00:22:32.850 da gab es super Produkte für, jeder hat's gelernt und jetzt kommt man auch teilweise so ein bisschen an 00:22:32.850 --> 00:22:34.210 Grenzen von SQL. 00:22:34.370 --> 00:22:38.770 Erstens mal, es wird nicht nur noch in Reporting-Systemen benutzt und es wird alles teilweise zum Beispiel 00:22:38.930 --> 00:22:43.890 sowas wie Facebook, das auf ein SQL zu packen, ist schon hart an der Grenze, 00:22:43.970 --> 00:22:48.130 weil einfach viele Algorithmen ein B Plusbaum, der skaliert irgendwann einfach auch nicht mehr. 00:22:48.770 --> 00:22:51.810 So elegant, den muss man dann verteilen und balancieren und schieß mich tot. 00:22:51.970 --> 00:22:53.970 Und da gibt es vielleicht bessere Möglichkeiten, sowas zu machen. 00:22:54.290 --> 00:22:57.890 Da ist ein Datenbanksystem, mit sich selber beschäftigt und richtig nicht mit den Daten, genau. 00:22:58.210 --> 00:23:03.650 Und ich glaube also, wenn man das historisch betrachtet, dann waren Datenbanksystem am Anfang auch nicht 00:23:04.210 --> 00:23:08.370 unbedingt dazu gedacht, jetzt Anwendungsdaten zu präsentieren, sondern gerade so Dinge, 00:23:08.450 --> 00:23:12.930 wie wir gerade besprochen haben, Reportings zu erstellen und Businesszahlen zu verwalten. 00:23:13.730 --> 00:23:16.450 Und die wurden halt weniger jetzt dafür designt. 00:23:17.570 --> 00:23:23.170 Ja, die wurden jetzt auch weniger dafür designt, so Sachen wie jetzt ein Blocksystem oder so ein soziales 00:23:23.170 --> 00:23:24.050 Netzwerk zu verwalten. 00:23:24.690 --> 00:23:27.570 Hauptanwendungsgebiete für Datenbanken waren früher halt Banken und Versicherungen. 00:23:27.650 --> 00:23:29.890 Und da haben die ihre ganzen Features, ja. 00:23:29.970 --> 00:23:30.610 Das ist halt der Punkt. 00:23:30.770 --> 00:23:35.810 Und der klassische Kontoauszug oder die Mobilfunkrechnung, das sind so absolut typische Anwendungsgebiete für 00:23:35.810 --> 00:23:36.290 Datenbanken. 00:23:36.690 --> 00:23:37.010 Genau. 00:23:37.170 --> 00:23:41.250 Und da muss man auch sagen, da sind es ja auch noch eigentlich was, welche der besten Systeme dafür. 00:23:41.330 --> 00:23:45.490 Also du kannst dann, du kannst nicht alles mit NoSQL ersetzen. 00:23:45.570 --> 00:23:49.330 Es macht einfach, also mit diesem Not only SQL-Zeug ersetzen, es macht einfach oft Sinn, 00:23:49.410 --> 00:23:51.410 auch eine relationale Datenbank zu verwenden. 00:23:51.570 --> 00:23:52.610 Manchmal halt nicht. 00:23:53.170 --> 00:23:56.850 Also wo macht es denn Sinn, NoSQL-Datenbanken zu nehmen? 00:23:57.090 --> 00:24:00.210 Genau, ähm Also klar, wir reden jetzt schon so ein bisschen drüber, 00:24:00.290 --> 00:24:04.690 also es ist, es hat irgendwas mit dem Web zu tun, da kamen einfach neue Anforderungen jetzt. 00:24:05.810 --> 00:24:10.610 Und genau, also man kann da, glaube ich, mehrere Dinge unterscheiden. 00:24:10.770 --> 00:24:15.730 Zum einen mal hat man bei großen Web-Anwendungen halt auch oft das Problem, 00:24:16.050 --> 00:24:19.250 mache ich jetzt irgendwie ein kleines Startup und fängt irgendwie mit einer Kiste an, 00:24:19.330 --> 00:24:23.090 die man irgendwo gehostet hat, und wächst vielleicht dann ganz schnell. 00:24:23.490 --> 00:24:28.370 Und da hat man halt im Endeffekt auch so das Bedürfnis, seine Datenhaltung mitwachsen zu lassen, 00:24:28.450 --> 00:24:31.970 sodass man halt immer mehr User dann bedienen kann. 00:24:32.770 --> 00:24:39.570 Und das machen relationale Datenbanken, wenn überhaupt auch nur mit enormem 00:24:39.570 --> 00:24:43.250 Konfigurationsaufwand und da hätte man vielleicht gerne als so ein kleines Unternehmen, 00:24:43.330 --> 00:24:48.450 was jetzt irgendwie eine Web-Anwendung auf den Markt bringt, auch gerne die Möglichkeit, 00:24:48.690 --> 00:24:53.890 das, wie der Mark vorhin schon beschrieben hat, automatisch einfach Server nachzuschieben und das wächst dann 00:24:53.890 --> 00:24:54.690 dynamisch mit. 00:24:55.170 --> 00:25:01.250 Also so eine Geschichte wäre auf jeden Fall ein Anwendungsfall, wo man dann so eine SQL-Datenbank einsetzen 00:25:01.250 --> 00:25:02.530 kann und tut. 00:25:02.930 --> 00:25:08.930 Es ist auch gerade, ich meine, wir haben ja hier einen echten DBA quasi bei uns oder DBA außer Dienst im 00:25:08.930 --> 00:25:10.610 Ruhestand oder keine Ahnung. 00:25:11.330 --> 00:25:11.890 Von damals. 00:25:12.210 --> 00:25:13.170 Von damals, ja. 00:25:14.210 --> 00:25:15.170 Also in den 70ern. 00:25:15.490 --> 00:25:16.770 Richtig, also Steine gegessen. 00:25:18.530 --> 00:25:22.290 Nee, genau, da, ich meine, viele Sachen, die wir sagen, würdest du sagen, 00:25:22.450 --> 00:25:25.730 dass so große, ich sag mal, Anführungszeichen, Enterprise-Teure-Systeme, 00:25:25.890 --> 00:25:29.330 nennen Oracle mit der größten Lizenz, die du dafür kriegst, oder ein DB2, 00:25:29.890 --> 00:25:33.010 bieten die auch so Möglichkeiten an, das dynamisch mitwachsen zu lassen, 00:25:33.090 --> 00:25:38.050 oder würdest du sagen, dass das dann doch eher eine unangenehme Geschichte ist? 00:25:38.290 --> 00:25:42.690 Also die Tendenz bei den Interpretatenbanken geht in Richtung selbstorganisierten Datenbanken, 00:25:43.010 --> 00:25:43.810 das ist ganz klar. 00:25:43.970 --> 00:25:46.930 Allerdings sind die noch nicht so toll. 00:25:47.010 --> 00:25:49.970 Und ob man einfach einen Server nachschubsen kann, das weiß ich tatsächlich. 00:25:50.050 --> 00:25:51.970 Also den aktuellsten Stand weiß ich jetzt nicht mehr. 00:25:52.130 --> 00:25:54.450 Ich habe vor drei Jahren als DBA aufgehört. 00:25:54.930 --> 00:25:59.330 Aber generell, und da hast du einfach recht, ist die Tatsache so, dass du eine Menge nachkonfigurieren musst. 00:25:59.410 --> 00:26:02.690 Das geht nicht so ohne weiteres, dass man einfach irgendwo eine Box aufbaut und sagt, 00:26:02.850 --> 00:26:04.050 hey, benutzt die mal mit. 00:26:04.290 --> 00:26:07.010 Also das ging zumindest zu dem Zeitpunkt noch nicht. 00:26:07.330 --> 00:26:10.210 Sie holen wohl auf, aber sind da lange noch nicht. 00:26:10.450 --> 00:26:10.770 Genau. 00:26:11.410 --> 00:26:17.250 Muss ich einfach viel mehr im Vorhinein überlegen, was ist der Einsatzzweck von dieser Datenbank jetzt? 00:26:17.410 --> 00:26:20.450 Wie baue ich mein Schema auf, was sollen da für Daten rein? 00:26:20.610 --> 00:26:24.370 Wie viel Server, auf wie viele Server soll das mal ausgelegt werden? 00:26:24.610 --> 00:26:29.730 Fange ich da jetzt schon an zu partitionieren, überlege ich mir, der Teil kommt jetzt auf den Server, 00:26:29.890 --> 00:26:34.290 weil das wird eh so groß, da reicht einer nicht aus oder ich muss mir gleich ein Mainframe kaufen oder was 00:26:34.290 --> 00:26:34.690 auch immer. 00:26:35.250 --> 00:26:39.090 Ja, ein gutes Beispiel ist ja, dass die ganzen Datenbanken sind ja deswegen so schnell, 00:26:39.170 --> 00:26:40.770 weil sie komplett im Speicher liegen. 00:26:40.930 --> 00:26:45.330 Und bei Partitionen ist es ja so, dass man weiß, welcher Server welche Daten im Speicher hat. 00:26:45.490 --> 00:26:50.050 Und wenn man jetzt überlegt, dass bei so einem Standard-SQL-Datenbank ein Server dazu geschubst wird, 00:26:50.130 --> 00:26:53.330 dann müsste sie ja intern gesagt werden, du nimmst die Sachen aus dem Speicher raus, 00:26:53.490 --> 00:26:56.370 hast dafür mehr Platz für andere Daten und das ist der neue Server, 00:26:56.450 --> 00:26:58.610 der genau diese Daten hält, die du vorher hattest. 00:26:58.850 --> 00:27:00.610 Und genau das geht halt nicht dynamisch. 00:27:01.410 --> 00:27:06.690 Genau, und das ist halt auch was, was man halt im Normalfall nicht unbedingt sofort weiß, 00:27:06.770 --> 00:27:09.970 wenn man jetzt anfängt, eine Anwendung zu schreiben oder irgendwie ein System zu entwickeln, 00:27:10.050 --> 00:27:11.650 was irgendwie auf eine Datenbank aufsetzt. 00:27:12.050 --> 00:27:15.330 Das ist auch generell, was in der Softwareentwicklung in letzter Zeit ja ein bisschen mehr hochkam. 00:27:15.810 --> 00:27:19.810 Wenn ich mit einer Datenbank arbeite, wäre es ja gut, wenn ich mir vorher sehr viel Gedanken über mein Schema 00:27:19.810 --> 00:27:20.370 gemacht habe. 00:27:20.530 --> 00:27:23.090 Weil das im Nachhinein zu verändern, ist immer ein bisschen ein Pain. 00:27:23.250 --> 00:27:26.370 Und ich kann nicht zwei Schemata gleichzeitig fahren im Normalfall. 00:27:26.530 --> 00:27:31.650 Weil ich habe halt meine Tabelle und gut, ich kann dann Keys mit einem Null belegen oder sowas in der Art. 00:27:32.050 --> 00:27:32.930 Das geht schon, aber. 00:27:33.570 --> 00:27:35.970 Der Standardweg ist ja da nicht, das alles in der Tabelle zu machen, 00:27:36.050 --> 00:27:38.130 sondern zu sagen, ich greife nur noch auf Views zu. 00:27:38.290 --> 00:27:40.930 Und wenn ich dann die Tabelle ändere, dann ändere ich den View nicht. 00:27:41.010 --> 00:27:44.770 Sonst heißt die View ist im Prinzip eine Sicht auf die Daten, deswegen der Name. 00:27:45.810 --> 00:27:51.570 Und ich wird mit Systemtabellen so gemacht, sodass ältere Clients auch noch auf neuere Datenbanken zugreifen 00:27:51.570 --> 00:27:55.730 können, weil sich diese übergeordnete Sicht nicht geändert hat, auch wenn da drunter alles sich verändert hat. 00:27:55.890 --> 00:27:59.010 Also ich kann diese Änderung schon durchführen, aber die sind sehr, sehr schmerzhaft. 00:27:59.330 --> 00:28:02.850 Wenn ich eine Datenbank mit 80 Millionen Datensätzen habe, die über mehrere Gigabytes läuft, 00:28:03.010 --> 00:28:07.890 ich füge ein normales Tabellenfeld hinzu, dann wird bei 80 Millionen Datensätzen Platz freigeschaut, 00:28:08.050 --> 00:28:12.050 um diese Daten, äh, nein, gar nicht warm, dann wird das erstmal nur im Schema bekannt gegeben und irgendwann 00:28:12.130 --> 00:28:15.490 muss man reorganisieren und beim Reorganisieren wird halt dieser Platz auch freigeschaufelt, 00:28:15.570 --> 00:28:16.850 dass das direkt dazu geklatscht wird. 00:28:17.010 --> 00:28:19.250 Genau, und man muss dann halt im Endeffekt auch seine ganzen Indizes, 00:28:19.330 --> 00:28:22.770 die man anlegt, um die Daten schnell wieder zu finden und die Views halt auch neu aufbauen, 00:28:22.850 --> 00:28:25.250 was halt auch ein relativ großer Organisationsaufwand ist. 00:28:25.570 --> 00:28:30.130 Genau, also es gibt die Möglichkeit, das im Live-System zu machen, dann wartest du Wochen und es gibt die 00:28:30.130 --> 00:28:33.810 Möglichkeit, den Index erstmal wegzuschmeißen, die Datenänderungen zu machen und dann den Index wieder neu 00:28:33.810 --> 00:28:34.290 aufzubauen. 00:28:34.450 --> 00:28:34.770 Richtig. 00:28:34.850 --> 00:28:38.050 Und da ist auch sowas, was bei vielen von diesen NoSQL-Geschichten, 00:28:38.130 --> 00:28:41.490 gerade wie man jetzt auch, also in letzter Zeit kam ja zum Beispiel im Programmieren auch immer mehr diese 00:28:41.490 --> 00:28:42.370 dynamischen Sprachen. 00:28:42.530 --> 00:28:46.530 Dynamisch typisiert, gut gab es vor langer Zeit, Smalltalk war zum Beispiel auch super dynamisch. 00:28:46.690 --> 00:28:48.530 Aber wir kam dann, Lisp auch, ja klar. 00:28:48.610 --> 00:28:50.610 Aber wir kamen dann in eine Zeit rein, wo dann alle angefangen haben, 00:28:50.770 --> 00:28:55.650 C und Java zu programmieren, was alles ein bisschen statisch ist und ein bisschen schwer und ein bisschen viel 00:28:55.650 --> 00:28:56.450 UML und so. 00:28:56.530 --> 00:29:01.170 Und in letzter Zeit kam mir dieses Agile auf, dass man sich nicht so extrem viel Gedanken von vorn reinmacht, 00:29:01.250 --> 00:29:04.450 sondern einfach ein System hat, das einem erlaubt, wenn man es denn beherrscht, 00:29:04.610 --> 00:29:06.690 auch live recht viel Änderungen zu machen. 00:29:07.010 --> 00:29:09.970 Und gerade da schlägt dieses NoSQL auch rein. 00:29:10.130 --> 00:29:16.130 Die meisten von diesen NoSQL-Datenbanken oder viele, sag ich mal, sind zum Beispiel schemafreie Datenbanken. 00:29:16.210 --> 00:29:18.290 Bedeutet, ich kann die Daten da reinhauen, wie ich will. 00:29:18.370 --> 00:29:23.010 Ich bin nicht auf meine vorhandenen Tabellen beschränkt, sondern die Datenbank nimmt alle Daten an, 00:29:23.090 --> 00:29:25.490 wie ich sie ihm reingebe und ins Schema wechsel. 00:29:26.770 --> 00:29:29.650 Ist dann insofern recht einfach, als dass ich vielleicht irgendwo eine, 00:29:30.130 --> 00:29:33.170 keine Ahnung, in dem Dokument sich da reinwerfe, halt einfach Schema-Version, 00:29:33.410 --> 00:29:34.210 ein Feld drin habe. 00:29:34.290 --> 00:29:40.850 Und dann gehe ich einfach mal von 1 auf 2 und füge zwei, drei Felder hinzu und da muss ich am Datenbanksserver 00:29:40.850 --> 00:29:41.490 gar nichts ändern. 00:29:41.570 --> 00:29:43.570 Das muss ich dann halt in meiner Applikation machen. 00:29:43.810 --> 00:29:46.930 Bin dafür aber auch recht leichtgewichtig, weil ich mein Datenschema, 00:29:47.570 --> 00:29:51.010 ich sag mal, meine Änderung ist nur in meinem Code und nicht über all meine kompletten Daten, 00:29:51.090 --> 00:29:52.690 die ich bisher schon gespeichert habe. 00:29:52.850 --> 00:29:55.970 Das ist auch so ein bisschen eine Geschichte, wo dieses NoSQL reinschlägt, 00:29:56.130 --> 00:29:59.650 dass sie einfach sagen, wir sind einfach ein bisschen dynamischer, ihr müsst euch nicht so viel Gedanken 00:29:59.650 --> 00:30:03.410 machen, wir wachsen mit und wir machen auch Änderungen ein bisschen besser mit. 00:30:03.570 --> 00:30:09.330 Es ist natürlich architektonisch auch problematisch teilweise, aber es ermöglicht dir halt einfach, 00:30:09.410 --> 00:30:12.930 gerade wenn du mal was prototypen willst, nicht ewig lang drüber nachzudenken, 00:30:13.010 --> 00:30:14.610 sondern du kannst es einfach schnell durchsetzen. 00:30:14.850 --> 00:30:17.810 Wobei das Tuning dann in dem Fall auch in der Regel so ausbaut, dass es aussieht, 00:30:17.970 --> 00:30:19.410 größere Boxen und mehr Boxen aufzubauen. 00:30:19.890 --> 00:30:21.010 Mehr Boxen, genau, ist immer so. 00:30:21.330 --> 00:30:25.410 Be klassischen Datenbanken ist es halt so, dass ein DBA, so ein Datenbank-Administrator mit einem 00:30:25.410 --> 00:30:28.930 Anwendungsentwickler, der vorwiegend SQL macht, auf die Datenbank guckt und sich anguckt. 00:30:29.090 --> 00:30:31.730 Genau, was läuft langsam, was läuft schnell, wie kann man das verändern. 00:30:31.890 --> 00:30:35.730 Das ist auch gerade die Möglichkeiten zu tunen, ist bei NoSkill auch nicht so verbreitet. 00:30:35.810 --> 00:30:39.010 Also dass ich jetzt bestimmen kann, welcher Index für welchen Teil wie verwendet wird, 00:30:39.170 --> 00:30:40.210 hast du im Normalfall nicht. 00:30:40.290 --> 00:30:42.850 Das ist alles, wie gesagt, recht leichtgewichtig, gar nicht so komplex, 00:30:42.930 --> 00:30:47.170 die versuchen es einfach zu halten und skalieren dann halt von mir aus in die Breite, 00:30:47.250 --> 00:30:49.490 anstatt da effizient auf einem System zu arbeiten. 00:30:50.210 --> 00:30:52.930 Gut, ich meine, früher hatte man das ja auch so, man hat um sein Mainframe, 00:30:53.010 --> 00:30:57.650 da lag die Datenbank drauf und da lag auch der Batchjob drauf, der irgendwann das alles wieder rausberechnet 00:30:57.650 --> 00:30:59.810 hat und dir dann den Kontoauszug ausgespuckt hat. 00:30:59.890 --> 00:31:05.490 Da war es ja auch nicht wichtig, ob der jetzt heute oder morgen erst zur Verfügung steht, mein Gott, ja. 00:31:06.290 --> 00:31:10.850 Heute ist man da einfach schneller und das, was Google auch groß gemacht hat, 00:31:11.010 --> 00:31:14.690 viele Pizza-Boxen irgendwo reinschieben und damit skalieren. 00:31:14.850 --> 00:31:20.130 Und nicht für Millionen erstmal ein paar Rechner hinzustellen, sondern halt immer, 00:31:20.210 --> 00:31:25.810 oh, wir brauchen mehr, dann kaufen wir jetzt mal wieder ein paar Schachteln und stecken die ins Rack rein und 00:31:25.890 --> 00:31:27.730 skalieren uns da wieder weiter drauf. 00:31:27.970 --> 00:31:29.330 Hat sich einfach geändert über die Zeit. 00:31:29.730 --> 00:31:30.930 Ich nenne das jetzt auch mal klassische Welt. 00:31:31.090 --> 00:31:35.170 In der klassischen Welt ist es tatsächlich auch so, dass das erste Tuning immer über die Hardware passiert, 00:31:35.330 --> 00:31:36.370 weil Leute teuer sind. 00:31:36.530 --> 00:31:40.290 Und wenn sich ein DBA und ein Anwendungsentwickler zusammensetzen und die zwei Monatsgehälter drauf 00:31:40.370 --> 00:31:44.770 verprassen, um 5% Änderung, also 5% Performance-Steigung rauszuhauen, 00:31:44.930 --> 00:31:49.170 dann ist es billiger ein größtes Blech dahin zu letzten Endes. 00:31:49.810 --> 00:31:54.130 Aber irgendwann kommt das halt an Grenzen, weil halt die internen Strukturen von relationalen 00:31:54.130 --> 00:31:58.450 Datenbanksystemen sehr aufwendig sind und dann blockieren die sich vielleicht gegenseitig. 00:31:58.530 --> 00:31:59.570 Das genau hatte ich auch. 00:31:59.730 --> 00:32:03.410 Das ist auch eine super Überleitung eigentlich, gerade wenn wir von Grenzen von Datenbanken reden. 00:32:03.650 --> 00:32:07.170 Da gibt es sowas, das immer und immer wieder erwähnt wird, das sogenannte KAP-Theorem. 00:32:07.490 --> 00:32:09.250 So wie ACID natürlich auch ein Akronym. 00:32:09.490 --> 00:32:11.250 Das Akronym, heißt das Akronym, ich glaube ja. 00:32:12.290 --> 00:32:13.170 CAP. 00:32:14.130 --> 00:32:20.370 Das war damals im Symposium on Principles of Distributed Computing 2002. 00:32:21.250 --> 00:32:23.890 Haben so, ja, da hier Wikipedia offen und direkt dabei. 00:32:24.370 --> 00:32:25.170 Ich war dabei. 00:32:26.130 --> 00:32:31.570 Genau, das war irgendwie University of California, Berkeley und MIT haben so ein bisschen zusammengearbeitet. 00:32:32.690 --> 00:32:34.850 Entschuldigung, ich war bei dem Ausspruch dabei. 00:32:36.610 --> 00:32:40.210 Genau, auf jeden Fall haben sich da ein paar intelligente Leute was überlegt und nämlich, 00:32:40.690 --> 00:32:43.650 wo sind denn die Grenzen von Datenbanken, wo sind denn die Trade-offs, 00:32:43.810 --> 00:32:44.530 die wir machen müssen? 00:32:44.690 --> 00:32:47.330 Das haben wir ja vorher erwähnt, wir haben teilweise so Sachen wie, 00:32:47.650 --> 00:32:52.290 skaliert gut, aber ist langsam, ist schnell, aber skaliert nicht gut und vielleicht sind die Daten sicher, 00:32:52.370 --> 00:32:52.850 aber auch nicht. 00:32:53.010 --> 00:32:55.010 Und das vereint dieses Kapp-Theorie ein bisschen. 00:32:55.650 --> 00:32:56.850 Ich will da einer von euch drüber reden. 00:32:57.170 --> 00:32:58.050 Ja, ich kann mal anfangen. 00:32:58.210 --> 00:32:58.450 Tu das. 00:32:59.010 --> 00:33:00.530 Immer der, der es aufgeschrieben hat. 00:33:01.650 --> 00:33:06.610 Und zwar, ähm, lass mich mal kurz überlegen, wie fange ich da jetzt ein bisschen an? 00:33:09.010 --> 00:33:10.450 Für was steht denn CAP? 00:33:10.690 --> 00:33:11.650 Also, genau. 00:33:12.050 --> 00:33:15.170 Ich wollte eigentlich noch was anderes sagen, fällt mir wahrscheinlich später nochmal ein. 00:33:15.730 --> 00:33:16.850 Was Fotis kommt wieder? 00:33:17.170 --> 00:33:22.210 Also dieses CAP-Theorem, dieses CAP steht in dem Fall für Consistency, 00:33:22.370 --> 00:33:24.370 Availability und Partition Tolerance. 00:33:24.770 --> 00:33:30.850 Und das sind im Endeffekt so die Grenzen, die ganz allgemein für Datenbanksysteme gelten. 00:33:30.930 --> 00:33:33.810 Und zwar auch für verteilte Systeme generell. 00:33:34.050 --> 00:33:35.650 Oder allgemein für verteilte Systeme. 00:33:35.810 --> 00:33:40.290 Und zwar darf man sich aus diesen drei Dingen, die eigentlich alle gut sind und die man eigentlich alle haben 00:33:40.290 --> 00:33:43.970 will, nur zwei aussuchen, weil die sich gegenseitig teilweise widersprechen. 00:33:44.770 --> 00:33:49.010 Und zwar hat man hier in dem Fall also Consistency auf Deutsch Konsistenz. 00:33:50.130 --> 00:33:55.490 Will man im Endeffekt seine Daten in einem konsistenten Zustand behalten. 00:33:55.650 --> 00:34:02.370 Also stellt sich jetzt vor, man hat mehrere Datenbankserver 00:34:02.530 --> 00:34:08.290 und auf denen wird gleichzeitig derselbe Datensatz in einer gewissen Art und Weise geändert. 00:34:08.450 --> 00:34:14.450 Dann möchte man ja, dass dieser Stand auf beiden Servern zusammengefasst wird und 00:34:15.810 --> 00:34:21.010 irgendwie einen Zustand geschaffen wird, der halt im Endeffekt auf beiden Systemen konsistent ist. 00:34:21.330 --> 00:34:23.570 Da hatten wir ja vorher dieses nette Beispiel mit den Bankautomaten, 00:34:23.650 --> 00:34:28.370 glaube ich, wenn ich an zwei Bankautomaten, habe ich zwei EC-Karten auf dasselbe Konto gleichzeitig abhebe, 00:34:28.610 --> 00:34:32.530 da ist die Bank natürlich daran interessiert, dass ihre Daten konsistent sind und nicht so, 00:34:32.690 --> 00:34:34.610 ups, gratis Geld für alle. 00:34:35.330 --> 00:34:38.850 Genau, dann hat man im Endeffekt noch den Punkt Availability. 00:34:38.930 --> 00:34:41.810 Da möchte man einfach, wenn man eine Anfrage ans Datenbanksystem stellt, 00:34:41.890 --> 00:34:45.010 möchte man auch eine Antwort darauf zurückbekommen. 00:34:45.410 --> 00:34:49.250 Und das eigentlich erwartet man das bei jeder Anfrage. 00:34:50.690 --> 00:34:53.010 Ja, also wäre es praktisch. 00:34:53.970 --> 00:34:55.090 Könnte man ja erwarten. 00:34:55.490 --> 00:35:00.610 Und der dritte und letzte Punkt wäre Partition Tolerance, was so viel bedeutet wie, 00:35:00.770 --> 00:35:05.170 man hat jetzt ein Datenbanksystem, was sich vielleicht über mehrere Rechner, 00:35:05.410 --> 00:35:11.970 vielleicht auch über mehrere Rechenzentren auf mehreren Kontinenten auf der Welt erstreckt. 00:35:12.210 --> 00:35:18.930 Und was passiert jetzt, wenn da mal, keine Ahnung, ein Bagger reißt ein Glasfaserkabel ab 00:35:18.930 --> 00:35:22.370 und die verlieren ihre Netzwerkanbindungen zueinander? 00:35:22.850 --> 00:35:29.490 Was passiert dann mit den Daten, wenn da auf beiden Seiten dieser gekappten Verbindung 00:35:29.730 --> 00:35:31.170 jetzt die Daten geändert werden? 00:35:31.330 --> 00:35:31.650 Genau. 00:35:31.970 --> 00:35:36.290 Und das sind so im Endeffekt diese Punkte und da kann man sich halt immer jeweils zwei aussuchen. 00:35:36.850 --> 00:35:37.410 Warum? 00:35:38.530 --> 00:35:42.850 Naja, das hat einer behauptet und andere gewesen. 00:35:43.650 --> 00:35:48.770 Also weil diese Kombination von jeweils zwei die dritte dann wiederum ausschließt. 00:35:48.850 --> 00:35:53.250 Also man kann sich jetzt zum Beispiel vorstellen, man möchte ein System haben, 00:35:53.570 --> 00:35:59.810 was konsistent ist und eine Partition Tolerance bietet. 00:36:00.690 --> 00:36:06.370 Da kann man sich vorstellen, okay, man hat jetzt zum Beispiel so einen Schwierigkeiten. 00:36:07.890 --> 00:36:08.370 Nimm Bugger. 00:36:09.570 --> 00:36:10.130 Perfektes Beispiel. 00:36:10.530 --> 00:36:11.330 Ne, immer noch kaputt. 00:36:11.490 --> 00:36:15.170 Genau, was ich gerade noch sagen wollte, ist, man hat da jetzt so ein Programm, 00:36:15.330 --> 00:36:21.490 äh, so ein Protokoll, was man zwischen den Servern spricht, um dieses Synchronisieren der Daten, 00:36:21.570 --> 00:36:23.730 damit die konsistent bleiben, auszuhandeln. 00:36:23.890 --> 00:36:27.730 So, jetzt reißt der Bugger die Leitung weg und auf beiden Seiten werden Daten geändert, 00:36:27.970 --> 00:36:29.650 die können also nicht miteinander reden. 00:36:29.810 --> 00:36:34.210 Das heißt, man hat jetzt entweder, äh man hat jetzt einen Fall, die können nicht miteinander reden, 00:36:34.290 --> 00:36:40.530 die sollen aber konsistent bleiben, also kann auf eine Anfrage, die jetzt an eine Seite des 00:36:40.530 --> 00:36:44.450 Datenbanksystems gestellt wird, kann die diese Anfrage nicht beantworten, 00:36:44.530 --> 00:36:46.370 weil sie da die Konsistenz nicht garantieren kann. 00:36:46.530 --> 00:36:49.970 Richtig, bedeutet, wir haben es zwar konsistent jetzt, weil wir versauen unsere Daten ja nicht, 00:36:50.050 --> 00:36:52.370 weil der eine sagt, ja nö, kann ich, ich sehe den anderen ja nicht. 00:36:52.530 --> 00:36:58.050 Wir haben auch eine Partitionstoleranz, weil die arbeiten ja immer noch weiter, 00:36:58.130 --> 00:37:01.890 aber die Availability ist halt ein Problem, weil eine meiner Nodes ist jetzt halt weg, 00:37:01.970 --> 00:37:07.730 weil der Bugger dazwischen kam und die andere funktioniert noch, also die toleriert die Partitionierung. 00:37:07.970 --> 00:37:12.450 Wir mussten jetzt halt leider auf die Availability achten und deswegen eine der Nodes redet jetzt halt nicht 00:37:12.450 --> 00:37:12.530 mehr. 00:37:12.610 --> 00:37:13.810 Und die sagt dann, nö, sorry. 00:37:13.970 --> 00:37:16.450 Ich hätte sogar jetzt gesagt, ich kann die Toleranznot dann erhalten, 00:37:16.530 --> 00:37:18.370 wenn ich die Availability runterschraube. 00:37:18.450 --> 00:37:23.170 Das heißt, ich kann das anderen ändern von Datensatz nur dann erlauben, wenn einer runterfährt, grundsätzlich. 00:37:23.250 --> 00:37:23.410 Exakt. 00:37:23.650 --> 00:37:26.690 Und das macht ein Cluster-System unter Unix so, dass sie einfach den Node, 00:37:26.770 --> 00:37:28.770 der den anderen nicht erreichen kann, rausschmeißen. 00:37:28.850 --> 00:37:28.930 Genau. 00:37:29.250 --> 00:37:30.290 Der bleibt einfach stehen. 00:37:30.610 --> 00:37:31.090 Richtig. 00:37:31.250 --> 00:37:32.930 Und könnte man natürlich auch anders machen. 00:37:33.010 --> 00:37:35.730 Man könnte in dem Fall dann auch sagen, ja, macht jetzt keinen Sinn, 00:37:35.810 --> 00:37:39.810 aber dann könnte man sagen, ich hätte gern, dass meine Availability und Partition Tolerance hoch ist. 00:37:39.970 --> 00:37:41.570 Meine Consistency ist mir aber egal. 00:37:41.730 --> 00:37:44.210 Bei Bankautomaten ist ein bisschen doof, aber wir könnten ja sagen, 00:37:44.370 --> 00:37:48.850 beide Automaten machen noch ihr Zeug und der dann halt nachher zuerst wieder zurückschreit, 00:37:48.930 --> 00:37:50.690 ha, ich habe eine Änderung, der gewinnt dann. 00:37:51.090 --> 00:37:54.290 Versaut meine Daten komplett, aber hey, alle Leute können zum Bankautomaten. 00:37:54.530 --> 00:37:59.410 Und das ist zum Beispiel bei so Sachen wie, keine Ahnung, was hat man denn? 00:37:59.490 --> 00:37:59.730 Irgendwie. 00:38:00.290 --> 00:38:01.970 Ja, bei Twitter oder so wäre es jetzt nicht schlimm. 00:38:02.050 --> 00:38:03.090 Ja, bei Twitter wäre es nicht schlimm. 00:38:03.170 --> 00:38:06.370 Oder irgendwie Sachen, wo du echt willst, dass die Leute an das System rankommen, 00:38:06.450 --> 00:38:07.970 weil du echt sonst ein Problem hast. 00:38:08.130 --> 00:38:10.930 Keine Ahnung, Sauerstoffmasken in Flugzeugen. 00:38:11.010 --> 00:38:12.290 Das ist vielleicht eine total blöde Idee. 00:38:12.450 --> 00:38:13.410 Aber wenn es halt echt ein wichtiges. 00:38:15.330 --> 00:38:18.770 Richtig, wenn es halt echt ein wichtiges System ist, dann ist es vielleicht echt mal besser, 00:38:18.850 --> 00:38:22.450 dass die Leute weiterarbeiten können, als dass deine Daten dann halt irgendwie hops gehen. 00:38:22.850 --> 00:38:25.810 Wie gesagt, ist so ein Trade-off. 00:38:25.890 --> 00:38:27.250 Ich glaube, das kommt auch auf die Daten an. 00:38:27.330 --> 00:38:30.850 Wenn wir jetzt so ein Beispiel haben wie Twitter, so ein Tweet, der wird einmal abgesetzt und dann nie wieder 00:38:30.850 --> 00:38:31.250 geändert. 00:38:31.330 --> 00:38:32.610 Man kann den auch gar nicht ändern. 00:38:33.330 --> 00:38:38.210 Wenn da jetzt zwischendurch mal eine Netzwerkverbindung zwischen ein paar Rechenzentren wegbrechen würde, 00:38:38.290 --> 00:38:44.290 dann könnte man da auch weiterschreiben und dann diese Tweets später wieder zusammenführen, 00:38:44.450 --> 00:38:47.970 weil diese Datensätze an sich, die werden ja nicht geändert, die werden ja immer nur hinzugefügt. 00:38:48.210 --> 00:38:50.450 Genau, aber die Konsistenz ist halt in dem Fall futsch, weil ich sage, 00:38:50.530 --> 00:38:52.050 gib mir die neuesten Nachrichten von dem. 00:38:52.130 --> 00:38:57.250 Und obwohl der in seinem Teil vom Rechenzentrum auf der anderen Seite vom Baggerloch das Zeug geschrieben hat, 00:38:57.330 --> 00:38:59.090 habe ich es halt nicht, aber in dem Fall total egal. 00:38:59.650 --> 00:39:00.770 Oder nehmen wir jetzt mal ein Seekabel. 00:39:00.930 --> 00:39:04.930 Wir haben jetzt irgendwie User in den USA, die sehen dann die Daten richtig und die User in Europa auf der 00:39:04.930 --> 00:39:09.570 anderen Seite vom Seekabel, die sehen dann vielleicht alte Daten, weil die sich untereinander noch nicht 00:39:09.570 --> 00:39:10.210 gesynt haben. 00:39:10.450 --> 00:39:10.690 Genau. 00:39:10.850 --> 00:39:14.210 Und Proxystrukturen wie Akamai zum Beispiel, die weltweit aufgebaut sind, 00:39:14.290 --> 00:39:16.370 wenn da mal zwischendurch die Synchronisation fehlstrich. 00:39:16.530 --> 00:39:21.170 Ja, wenn einer mal eine Datei bekommt, die jetzt irgendwie ein paar Minuten älter ist als eine andere Version, 00:39:21.250 --> 00:39:21.810 dann ist es halt so. 00:39:21.970 --> 00:39:26.210 Jetzt halt Availability ist da wesentlich wichtiger als dann die Konsistenz. 00:39:26.450 --> 00:39:26.690 Genau. 00:39:26.850 --> 00:39:30.690 Und das sind so die drei Sachen, bei denen man hin und her machen kann. 00:39:30.770 --> 00:39:32.290 Und man kriegt leider nicht alle drei. 00:39:32.370 --> 00:39:34.690 Oder zumindest kam noch keiner drauf, wie man das machen könnte. 00:39:35.570 --> 00:39:37.650 Weiß nicht, wo du es vielleicht sogar bewiesen, ich weiß nicht. 00:39:38.450 --> 00:39:39.250 Universitäres Paper. 00:39:40.850 --> 00:39:42.210 In dem Paper war ein Proof drin, ja. 00:39:42.930 --> 00:39:44.850 Ich habe nochmal nicht nachvollzogen, was ich verstehe. 00:39:45.570 --> 00:39:48.690 Es gibt auch immer wieder Kritik an dem ganzen System, aber im Normalfall ist es so, 00:39:48.770 --> 00:39:53.970 dass du zwei von drei haben kannst und auf das andere musst du dann halt ein bisschen verzichten. 00:39:54.130 --> 00:39:54.770 Das ist halt schade. 00:39:54.930 --> 00:39:58.450 Und wenn wir jetzt hier von klassischen Datenbanksystemen geredet haben bisher, 00:39:58.530 --> 00:40:03.010 die relationalen, die waren dann eigentlich zum Großteil von der CR-Soite. 00:40:03.170 --> 00:40:06.290 Das heißt, die haben Consistency und Availability garantiert. 00:40:06.690 --> 00:40:09.970 Allerdings mangelt es bei denen bei der Partition Tolerance. 00:40:10.130 --> 00:40:10.210 Genau. 00:40:10.370 --> 00:40:15.090 Und wenn wir jetzt hier von den Großteil der NoSQL-Lösung reden, ähm 00:40:15.610 --> 00:40:20.970 Da ist dann halt im Endeffekt so, dass die sagen, okay, wir können jetzt Consistency ein bisschen opfern, 00:40:21.770 --> 00:40:25.370 sind dafür verfügbar und haben eine gute Partitioning Tolerance. 00:40:25.530 --> 00:40:25.690 Richtig. 00:40:25.850 --> 00:40:29.290 Und man muss auch natürlich sagen, wenn die die opfern, also wir reden immer noch von Computersystemen, 00:40:29.370 --> 00:40:33.130 ist nicht, dass das dann zehn Minuten später die Änderung ankommt, sondern wir reden da über 2, 00:40:33.210 --> 00:40:37.290 3, 5, 10 Millisekunden, je nachdem wie der Rechenweg so dazwischen liegt. 00:40:37.450 --> 00:40:41.850 Und für die Zeit, ja Gott, dann hält das halt vielleicht auch ein bisschen länger im Speicher, 00:40:41.930 --> 00:40:43.370 wenn er abstürzt, ist halt weg. 00:40:43.610 --> 00:40:48.090 Aber gerade wenn wir keine Bank-Accounts haben, sondern so Sachen, die echt auch hops gehen können. 00:40:48.330 --> 00:40:48.810 Wie Twitter. 00:40:49.050 --> 00:40:49.450 Wie Twitter. 00:40:49.530 --> 00:40:52.890 Twitter ist so das Beispiel, das einfach interessiert einfach keinen, noch alle benutzen es. 00:40:54.410 --> 00:40:58.330 Oder man nennt es mal jetzt irgendwie Facebook-Nachrichten oder Foursquare-Check-Ins, 00:40:58.570 --> 00:41:00.570 da kommt es im Endeffekt überall aufs selbe raus. 00:41:00.730 --> 00:41:05.610 Das sind halt irgendwie so relativ triviale Daten, wo es jetzt nicht so besonders viel ausmacht, 00:41:05.770 --> 00:41:08.010 wenn das jetzt mal eine Millisekunde früher oder später angeht. 00:41:08.170 --> 00:41:10.810 Richtig, also da wird keiner weinen, wenn er erst zwei Sekunden später sich, 00:41:10.890 --> 00:41:14.570 dass dein Kumpel jetzt, keine Ahnung, im Rathaus in Bukarest eingecheckt hat. 00:41:14.650 --> 00:41:14.970 Zum Beispiel. 00:41:15.210 --> 00:41:17.850 Aber die Frauen und Ehemänner und die wollen es eigentlich mal genau wissen. 00:41:18.170 --> 00:41:21.450 Richtig, aber ich glaube, auf zwei Millisekunden, da wird dann, da ist die Grenze erreicht, 00:41:21.530 --> 00:41:22.170 wo du sagen kannst, nein. 00:41:25.130 --> 00:41:25.530 Okay, dann. 00:41:25.770 --> 00:41:26.890 Ich will gar kein Facebook-Account. 00:41:27.130 --> 00:41:28.970 Dann musst du die CA-Sorte fahrend überein. 00:41:30.010 --> 00:41:30.570 Genau. 00:41:31.050 --> 00:41:33.370 Ja, und das ist so generell Datenbanken. 00:41:33.850 --> 00:41:37.210 Genau, das betrifft also NoSQL wie SQL-Datenbanken. 00:41:37.930 --> 00:41:42.730 Wie kann man denn NoSQL-Datenbanken so einteilen? 00:41:42.810 --> 00:41:47.930 Also da gibt es, das eine sind die relationellen Datenbanken und wir hatten schon so ein paar 00:41:48.170 --> 00:41:53.290 Dokument-Datenbanken oder so, aber was machen diese NoSQL-Datenbanken eigentlich so anders? 00:41:53.530 --> 00:41:53.930 Genau. 00:41:54.410 --> 00:41:57.450 Also generell sind es halt verschiedene Daten. 00:41:57.930 --> 00:42:02.010 Wenn wir von den alten Datenbanken herden, das sind relationale, die das Ganze in Tabellen und Spalten halten. 00:42:02.810 --> 00:42:05.370 Zeilen und Spalten, sorry, in Tabellen mit Zeilen und Spalten. 00:42:05.850 --> 00:42:06.170 Genau. 00:42:06.250 --> 00:42:12.490 Und die NoSQL, die haben halt das, es ist ja kein homogenes Feld, die sind ja auch unterschiedlich. 00:42:12.570 --> 00:42:15.930 Aber da gibt es verschiedene Arten, Daten zu speichern, verschiedene Schemata, 00:42:16.010 --> 00:42:18.330 die sich für verschiedene Sachen gut bzw. 00:42:18.650 --> 00:42:19.850 schlecht ereignen. 00:42:20.010 --> 00:42:22.330 Ich würde einfach sagen, wir gehen jetzt mal so der Reihenfolge nach durch, 00:42:22.410 --> 00:42:25.290 dass wir alle ein bisschen reden und keine Ahnung. 00:42:25.530 --> 00:42:27.770 Soll ich mal mit dem Leichten anfangen, dem Key-Value? 00:42:28.010 --> 00:42:30.330 Das ist, dann muss ich nicht so viel sagen, das ist gut. 00:42:31.210 --> 00:42:36.090 Key-Value ist einfach, ich weiß nicht, wenn ihr programmiert, da gibt es so Sachen wie eine Hashmap oder ein 00:42:36.090 --> 00:42:39.530 Dictionary oder wie auch immer ihr das nennen würdet, ein assoziatives Array. 00:42:39.690 --> 00:42:42.890 Bedeutet, ihr habt einen Key, das ist im Normalfall ein String oder eine Nummer, 00:42:42.970 --> 00:42:46.730 je nachdem, wie ihr es haben wollt, und ihr habt ein Value, das ist was auch immer da drin steckt. 00:42:46.810 --> 00:42:49.690 Das ist im Normalfall ein Stück Text oder eine Zahl oder sonst was. 00:42:49.850 --> 00:42:52.730 Und das ist das komplette Datenschema von Key Value Stores. 00:42:52.890 --> 00:42:55.770 Bedeutet, ihr habt einen Key, den nennt ihr zum Beispiel, keine Ahnung, 00:42:55.850 --> 00:42:58.970 wenn ihr eure Benutzer verwaltet, wird zum Beispiel ein Benutzername, 00:42:59.130 --> 00:43:02.890 das, was in den RDBMS normalerweise ein Primary-Key war. 00:43:02.970 --> 00:43:06.330 Also das Ding, was eigentlich deinen Datensatz, den du willst, identifiziert. 00:43:06.650 --> 00:43:07.610 Zum Beispiel ein Benutzer. 00:43:07.690 --> 00:43:09.850 Auf Twitter gibt es nur einen, der gleich heißen kann. 00:43:10.010 --> 00:43:14.090 Bedeutet, machen wir doch einfach den mal zum Key und Value könnten dann zum Beispiel die Tweets sein, 00:43:14.170 --> 00:43:15.210 die diese Person macht. 00:43:15.450 --> 00:43:16.410 Bedeutet, wenn du. 00:43:17.290 --> 00:43:20.410 Du kannst nicht großartig viel machen, aber was du machen kannst, ist sagen, 00:43:20.570 --> 00:43:22.410 gib mir alle Tweets von Person XY. 00:43:22.890 --> 00:43:25.690 Und das funktioniert dann super schnell und es ist Key Value, Ende. 00:43:25.930 --> 00:43:31.450 Ist ein recht einfaches Schema und gerade für so Sachen oder auch Caches wird es recht oft eingesetzt. 00:43:31.610 --> 00:43:36.330 Wenn wir zum Beispiel so HTTP-Daten cachen wollen oder Datenbankergebnisse cachen wollen oder so, 00:43:36.490 --> 00:43:38.010 die sind ja alle recht eindeutig. 00:43:38.170 --> 00:43:40.730 Zum Beispiel ein Ahnung. 00:43:40.970 --> 00:43:45.450 Die Inbox von einem User oder die Startseite, laufen wir einfach mal die Startseite von Dick.com, 00:43:45.530 --> 00:43:52.410 Reddit.com, diesen riesigen sozialen News-Gedöns, die wird ja irgendwie hunderte Male 00:43:52.410 --> 00:43:53.450 pro Sekunde abgerufen. 00:43:53.690 --> 00:43:57.290 Wenn ich hunderte Male pro Sekunde zu meinem Backend-System gehe und das Skript starte, 00:43:57.370 --> 00:44:00.730 das mir die Startseite rausholt, dann ist das eine ziemlich böse Sache, 00:44:00.890 --> 00:44:02.490 wenn mein Server mich dann nicht mehr mag. 00:44:03.690 --> 00:44:06.970 Das Gute ist aber, da kommt immer dasselbe Ergebnis raus. 00:44:07.050 --> 00:44:11.450 Also da gibt es kleine Änderungen und wenn wir nur alle 60 Sekunden eine neue Seite zeigen, 00:44:11.530 --> 00:44:16.330 reicht es im Normalfall aus, weil so viele Neuigkeiten kommen da gar nicht. 00:44:16.410 --> 00:44:18.250 Also oder Startseite der Tagesschau. 00:44:18.330 --> 00:44:21.530 So oft passiert nichts Neues, dass wir nicht 60 Sekunden was Altes dran stehen lassen können. 00:44:21.770 --> 00:44:26.730 Also es würde gar nicht funktionieren, die Systeme würden, also wenn eine oft aufgerufene Seite brauchen, 00:44:26.890 --> 00:44:30.570 ein Cache, weil sonst geht das Datenbanksystem einfach flüchtig. 00:44:30.810 --> 00:44:35.690 Und natürlich haben Datenbanken haben Datenbanken auch Caches, aber da ist einfach jede Menge Zeug dazwischen 00:44:35.850 --> 00:44:39.850 und oft haben wir so Sachen wie Memcache zum Beispiel, da ist einfach die Index-HTML und dann hat er den 00:44:39.850 --> 00:44:41.530 HTML-Source, den er ausliefern soll. 00:44:41.610 --> 00:44:44.650 Der wurde einmal generiert oder wird halt alle 60 Sekunden neu gebaut. 00:44:45.130 --> 00:44:50.170 Und das ist so der klassische Key-Value-Store, gib mir die Index-HTML und er muss dann gar niemand mehr 00:44:50.170 --> 00:44:53.610 fragen, sondern er sagt, hier hast du einen riesigen Haufen Daten, er hat keine Ahnung, 00:44:53.690 --> 00:44:56.250 was die Daten sind, aber die sollen rauskommen. 00:44:56.490 --> 00:44:56.970 Key-Value. 00:44:57.290 --> 00:44:58.970 Auch da gibt es zwei Methoden, das zu invalidieren. 00:44:59.050 --> 00:45:03.450 Einmal nach Zeit, nur einmal pro Minute oder zu sagen, dass das System sagt, hör mal zu, du bist ungültig. 00:45:03.690 --> 00:45:04.730 Genau, ich meine, man kriegt neu. 00:45:04.970 --> 00:45:07.530 Man kann sich ja jetzt auch vorstellen, man hat so einen Tagesschau, 00:45:07.690 --> 00:45:12.010 einen News-Ticker und der weiß ja, wann ein neuer Eintrag kommt, 00:45:12.090 --> 00:45:13.210 nämlich wenn er abgeschickt wurde. 00:45:13.290 --> 00:45:16.970 Und wenn der dann abgeschickt wurde, dann wird im Endeffekt das HTML einfach neu generiert, 00:45:17.130 --> 00:45:19.370 der Cache-Eintrag neu geschrieben und dann war es das. 00:45:19.930 --> 00:45:22.250 Aber da müssten wir, glaube ich, auch nochmal eine extra Sendung zum Caching machen. 00:45:22.330 --> 00:45:25.850 Da gibt es natürlich auch eine Menge Probleme, die wir jetzt hier am besten nicht ansprechen. 00:45:26.410 --> 00:45:28.170 Die können wir am Beispiel von Radio Tuxton verdeutlichen. 00:45:29.210 --> 00:45:31.930 Es gibt zwei große Probleme in der Informatik. 00:45:32.410 --> 00:45:35.530 Einmal Namensgebung und das zweite ist Cache-Invalidierung. 00:45:35.770 --> 00:45:37.210 Richtig, da gab es irgendwas ein Zitat. 00:45:37.530 --> 00:45:37.690 Genau. 00:45:37.770 --> 00:45:39.850 Und vielleicht noch ein Zusatz zu dem Key-Value. 00:45:40.010 --> 00:45:44.490 Wir können natürlich in dem Value auch Objekte speichern, die unsere Daten, 00:45:44.650 --> 00:45:47.450 unsere Anwendung braucht, indem wir uns einfach ein Format überlegen, 00:45:47.530 --> 00:45:51.610 wie zum Beispiel JSON, das ein Objekt nimmt, das wir so im Speicher haben, 00:45:51.690 --> 00:45:57.770 unser logisches, gedachtes Objekt in objektorientierten Sprache und das einfach serialisiert in einen Text. 00:45:57.930 --> 00:46:01.530 Da gibt es dann JSON oder du kannst es auch mit XML machen, wenn du denn lustig bist. 00:46:01.770 --> 00:46:08.570 Und das erlaubt uns zum Beispiel auch einen Status, einen Zustand von meiner Anwendung in die Datenbank zu 00:46:08.570 --> 00:46:13.130 stecken, ohne großartig viele Tabellen und so zu verwenden, indem wir das einfach in ein Textstück klatschen 00:46:13.130 --> 00:46:16.170 und den dann einfach reinhauen und nachher auch wieder rausholen können. 00:46:17.050 --> 00:46:19.850 Das wäre auch noch so eine Möglichkeit, Daten da drin zu speichern. 00:46:20.010 --> 00:46:25.930 Ja, oder man macht es mit einem Blob, also einem Binary-Objekt, dann wäre es schon eher ein Document Store. 00:46:26.650 --> 00:46:28.170 Ja, nee, der Blob ist auch schon. 00:46:28.410 --> 00:46:30.250 Dein Datenmann hat ja keine Ahnung, was das Zeug ist. 00:46:30.730 --> 00:46:31.530 Kommen wir gleich noch zu. 00:46:31.690 --> 00:46:36.570 Man kann das Ganze aber auch mit einer normalen SQL-Sache machen, 00:46:36.650 --> 00:46:38.890 indem ich einfach nur eine Tabelle habe, dann ist es genau dasselbe. 00:46:39.050 --> 00:46:39.210 Richtig. 00:46:39.450 --> 00:46:41.130 Ist ziemlich zwei Spalten, genau. 00:46:43.130 --> 00:46:48.490 Was wäre es auch eine Spalte Key und eine Spalte Value und dann kann man die zueinander zuordnen und da so 00:46:48.490 --> 00:46:48.890 reinschreiben? 00:46:49.130 --> 00:46:50.250 Das machen auch viele so. 00:46:50.330 --> 00:46:54.090 Es ist halt, du musst nach wie vor über SQL gehen und die Datenbank macht halt noch ein bisschen mehr. 00:46:54.410 --> 00:46:59.450 Ich sag mal, die muss deine Abfrage parsen in einer Sprache, die nicht so einfach zu parsen ist, 00:46:59.610 --> 00:47:02.570 geht ein bisschen Zeit drauf, klappt aber auch wunderbar, machen auch viele so. 00:47:02.810 --> 00:47:06.650 Gutes Beispiel fällt mir gerade ein, sind Username und Passwörter für so Key-Value-Stores. 00:47:06.810 --> 00:47:08.650 Genau, das ist zum Beispiel so ein Klassiker. 00:47:09.290 --> 00:47:09.850 Genau. 00:47:10.010 --> 00:47:12.730 Ja, das ist auch viel mehr gibt es da auch über Key-Value nicht zu sagen. 00:47:12.810 --> 00:47:13.850 Aber da gibt es ja noch mehr. 00:47:14.650 --> 00:47:17.450 Ja, vielleicht nimmt sich den zweiten hier in der Liste. 00:47:17.850 --> 00:47:19.690 Es gibt auch die sogenannten Column-Stores. 00:47:19.850 --> 00:47:25.690 Da speichert man seine Daten jetzt nicht so in Key-Value-Paren, sondern man speichert die in Spalten, 00:47:25.770 --> 00:47:28.650 die wiederum miteinander ineinander verschachtelt werden können. 00:47:28.730 --> 00:47:31.050 Das hört sich jetzt ein bisschen kompliziert an. 00:47:31.450 --> 00:47:32.010 Ist auch. 00:47:32.490 --> 00:47:35.610 Genau, es ist eins der Datenmodelle, die nicht so natürlich sind. 00:47:35.930 --> 00:47:39.210 Ich glaube, du kannst da ein bisschen mehr dazu erzählen als ich, weil du ja schon mal mit solchen Systemen 00:47:39.210 --> 00:47:39.930 gearbeitet hast. 00:47:40.490 --> 00:47:42.330 Es gibt ja nicht so viele, die das so machen. 00:47:42.410 --> 00:47:44.810 Also eins wäre zum Beispiel, nur mal ein paar Namen schon zu sagen, 00:47:44.890 --> 00:47:47.770 da kommen wir vielleicht noch drauf Hase, macht es zum Beispiel so, 00:47:47.930 --> 00:47:50.330 Cassandra-bedingt, ja auch. 00:47:50.970 --> 00:47:55.290 Das ist halt im Grunde, wenn ihr euch vorstellt, wenn ihr in einem Key-Value-Store hatten wir ja gerade, 00:47:55.370 --> 00:47:59.130 und wenn ihr statt dem Value jetzt nochmal einen Key speichert, der eventuell noch einen Value enthalten kann 00:47:59.210 --> 00:48:04.890 oder mehrere andere Keys, ist also so ein, es heißt immer ein mehrdimensionaler Hash. 00:48:05.050 --> 00:48:06.890 Ja, also man kann die halt im Endeffekt, man hat. 00:48:07.290 --> 00:48:09.930 Wenn du in den Hash einen Hashtagst, in dem ein Hash stackt, in dem Hash deckt, 00:48:10.090 --> 00:48:14.170 bedeutet, du hast da so eine Art, ja, klingt ein bisschen freaky jetzt. 00:48:14.250 --> 00:48:18.090 Also du hast zum Beispiel erstmal einen Hash, der heißt User. 00:48:18.250 --> 00:48:24.810 Und in dem Ding sind jede Menge Einträge drin, die dann zum Beispiel irgendwie Radio Tux heißt, 00:48:24.890 --> 00:48:26.250 wenn wir das mit Twitter jetzt so machen. 00:48:26.570 --> 00:48:27.130 Von mir aus. 00:48:27.210 --> 00:48:29.770 Und in diesem User steckt dann wiederum was anderes drin. 00:48:30.090 --> 00:48:35.770 Und lass es zum Beispiel sowas sein wie, wir haben jetzt einen User und an dem hängen jetzt irgendwie 00:48:35.770 --> 00:48:40.170 Blogposts dran und an diesen Blogposts hängen jetzt wieder Kommentare dran. 00:48:40.250 --> 00:48:44.650 Und dann kann man halt so sagen, okay, man hat jetzt einen User und der verweist auf mehrere Blogposts und 00:48:44.650 --> 00:48:48.890 diese Blogposts verweisen wiederum jeweils auf mehrere Kommentare, dann ist das halt so ein verschachteles 00:48:48.970 --> 00:48:49.130 System. 00:48:49.450 --> 00:48:49.610 Genau. 00:48:50.090 --> 00:48:56.170 In dem man halt wie vorher auch beschrieben Key-Value-Paare allerdings in Verschachtelerform speichert. 00:48:56.410 --> 00:49:01.370 Genau, man kann das natürlich auch ganz normal mit, also das kann auch durch normalen Key-Value emuliert 00:49:01.370 --> 00:49:01.530 werden. 00:49:01.610 --> 00:49:04.970 Ich kann ja einfach sagen, ich habe einen User, der heißt RB2K und anstatt, 00:49:05.050 --> 00:49:07.610 dass ich da die Kommentare reinhänge, kann ich mir einen neuen Key machen, 00:49:07.690 --> 00:49:10.250 der heißt irgendwie Kommentare von RB2K. 00:49:10.730 --> 00:49:17.050 Würde natürlich auch gehen, nur ist das so ein bisschen, ja, da ist halt sehr viel Logik dann in meinem 00:49:17.050 --> 00:49:21.930 Keynamen drin und bei den Column Stores kann ich die Logik ein bisschen aufs Datenmodell verschieben. 00:49:22.250 --> 00:49:26.010 Hat auch irgendwie einige Vorteile, um das danach zu skalieren und Pippapo. 00:49:26.890 --> 00:49:31.370 Ja, aber Column Stores ist so ein bisschen, ja, wenn ihr es euch wirklich interessiert, lest es mal durch. 00:49:31.450 --> 00:49:35.530 Es gibt da viele Leute, die was drüber schreiben, schwer zu erklären, das Ganze. 00:49:36.490 --> 00:49:40.810 Aber wo wir gerade bei Dokumenten waren, es gibt natürlich auch noch so dieses System, 00:49:41.050 --> 00:49:46.730 was jetzt Dokumente, wie du es vorhin schon gemeint hast, in natürlicher Form, 00:49:46.810 --> 00:49:47.530 sag ich mal, speichert. 00:49:48.010 --> 00:49:54.170 Also ich habe so eine OpenOffice Writer-Datei und speichere die da ein. 00:49:54.410 --> 00:49:59.290 Es würde technisch gesehen sogar gehen, da dieses Open Office-Format intern XML verwendet. 00:49:59.370 --> 00:50:04.890 Und wenn die Datenbank in der Lage wäre, XML zu verstehen, dann wäre das tatsächlich möglich. 00:50:04.970 --> 00:50:09.450 Aber nee, tatsächlich geht es hier um Dokumente in Form von strukturierten Daten. 00:50:09.530 --> 00:50:11.770 Also das ist jetzt relativ oft JSON. 00:50:11.930 --> 00:50:14.410 Das kann auch so Sachen wie XML sein. 00:50:14.650 --> 00:50:20.490 Es gibt tatsächlich auch vielleicht auch Leute, die irgendwie INI-Files oder sowas als Struktur benutzen. 00:50:20.810 --> 00:50:22.890 Aber gängig sind eigentlich JSON und XML. 00:50:22.970 --> 00:50:23.210 Genau. 00:50:23.450 --> 00:50:24.810 Und der große Unterschied ist. 00:50:25.050 --> 00:50:29.210 Also ich speichere da kein MPG-File oder so einfach so rein. 00:50:30.170 --> 00:50:30.730 Kannst du auch. 00:50:30.970 --> 00:50:36.810 Kannst du auch, aber dann ist halt im Endeffekt, dass Datenbank, also das ist ja der große Punkt bei diesen 00:50:36.810 --> 00:50:41.530 Dokumentdatenbanken, ist ja, dass die in der Lage sind, das Datenformat zu verstehen. 00:50:41.690 --> 00:50:46.170 Die können zwar auch sowas wie jetzt einen Film oder irgendwie ein Bild abspeichern. 00:50:46.410 --> 00:50:49.050 Aber dann könnte ich es auch direkt auf dem Dateisystem abgeben. 00:50:49.210 --> 00:50:49.850 Könntest du auch. 00:50:50.410 --> 00:50:52.650 Aber dann hätte ich ja keinen Index vielleicht drüber. 00:50:53.210 --> 00:50:53.530 Ja. 00:50:54.170 --> 00:50:59.050 Okay, plus du kannst jetzt halt, du kannst zwar das Bild als Binärdatei abspeichern, 00:50:59.130 --> 00:51:03.610 die solche Datentypen gibt, aber das Dokumentensystem ist jetzt nicht in der Lage zu sagen, 00:51:03.770 --> 00:51:06.810 wäre ich denn auf dem Bild abgebildet zum Beispiel. 00:51:07.210 --> 00:51:10.250 Oder gib mir mal das Bild irgendwie in der halben Größe zurück. 00:51:10.730 --> 00:51:11.930 Der hat ja keine Ahnung, was das ist ein bisschen. 00:51:12.410 --> 00:51:13.370 Der kennt ja kein JPG. 00:51:13.450 --> 00:51:14.410 Genau, der versteht dieses Format. 00:51:14.810 --> 00:51:15.610 Warum eigentlich nicht? 00:51:15.850 --> 00:51:16.090 Richtig. 00:51:18.250 --> 00:51:22.250 Man machen wird allerdings ein bisschen rechenintensiv, aber gibt es Server, die das machen? 00:51:22.810 --> 00:51:24.250 Adobe bietet dir sowas an. 00:51:24.570 --> 00:51:25.450 Ja, gut. 00:51:25.930 --> 00:51:28.090 Also da gibt es von Adobe, heißt es irgendwie so einen. 00:51:28.330 --> 00:51:31.770 Nee, nee, gibt es wirklich von Adobe gibt es irgendeinen Mediaserver, der dir das dir macht tatsächlich? 00:51:32.010 --> 00:51:36.330 Richtig, und das ist halt eine Dokumentdatenbank, weil er weiß, was in ihm gespeichert wird. 00:51:36.410 --> 00:51:37.690 Er kann damit operieren. 00:51:37.770 --> 00:51:38.010 Ohne. 00:51:38.730 --> 00:51:44.170 Ich meine, könnte man natürlich auch so sehen, ich speichere da jetzt ein Open Office-Dokument rein und ihr 00:51:44.170 --> 00:51:46.650 sagt in der Anfrage, gib mir jetzt ein PDF zurück. 00:51:46.810 --> 00:51:51.930 Technisch gesehen wäre das nichts anderes als das, was die Datenbanksysteme jetzt heute schon machen, 00:51:52.090 --> 00:51:59.050 nur das Ganze halt mit einer relativ hohen Rechenleistung oder mit einem hohen Rechenaufwand verbunden. 00:51:59.290 --> 00:52:01.850 Genau, vielleicht auch in dem Zusammenhang mit dem OpenOffice ist eine gute Idee. 00:52:01.930 --> 00:52:04.490 Du könntest natürlich dann, wenn das wirklich ein Dokumenten-Datenbank wäre, 00:52:04.570 --> 00:52:08.170 die OpenOffice versteht, könntest du auch sagen, gib mir alle Überschriften zurück. 00:52:08.250 --> 00:52:08.330 Genau. 00:52:08.570 --> 00:52:10.890 Oder gib mir alle Wörter, die in Rot geschrieben sind, zurück. 00:52:11.050 --> 00:52:14.810 Bedeutet, du speicherst da nicht nur einen Textblo rein und du bist der Einzige, 00:52:14.890 --> 00:52:18.250 der es kapiert, sondern die Datenbank kann auch Operationen ausführen. 00:52:18.490 --> 00:52:22.410 Zum Beispiel, wenn da eine Zahl drin ist, dann kannst du der Datenbank irgendwie einen Befehl schicken und 00:52:22.410 --> 00:52:25.770 sagen, erhöh die Zahl mal um 12 oder multipliziere die mit 19. 00:52:25.930 --> 00:52:27.530 Das geht nicht, wenn das nur Text ist. 00:52:27.610 --> 00:52:31.290 Wenn irgendwie da ein großer Text drin steckt, dann kann die Datenbank da wenig mit anfangen. 00:52:31.370 --> 00:52:36.730 Aber wenn du speziell sagst, hier speichere ich eine Zahl rein und die Datenbank Zahlen versteht, 00:52:36.890 --> 00:52:38.730 dann könnte die damit auch arbeiten. 00:52:38.890 --> 00:52:42.250 Das sind halt, ja, wie das Lady gesagt hat, versteht halt, was drinsteckt. 00:52:42.570 --> 00:52:46.250 Wenn ich über Millionen von Datensätze rattern muss, dann habe ich ja im Prinzip nichts gewonnen gegenüber 00:52:46.250 --> 00:52:48.330 einer typisch relationalen Datenbank. 00:52:48.490 --> 00:52:51.130 Das kriege ich auch mit normaler, relationaler Logik abgebildet. 00:52:51.370 --> 00:52:56.410 Klar bekommt man das abgebildet, die Sache ist nur, wie guckt man auf die Daten. 00:52:56.730 --> 00:53:01.610 Also mir als Anwendungsentwickler ist das immer so ein bisschen unangenehm, 00:53:01.770 --> 00:53:07.290 wenn ich objektorientiert programmiere und ich denke da in Objekten und in Datenstrukturen, 00:53:07.370 --> 00:53:10.570 die da in der Programmiersprache vorkommen und alles, alles toll, alles super, 00:53:10.890 --> 00:53:12.250 weiß ich voll, wie das geht. 00:53:12.410 --> 00:53:17.210 Und dann muss ich das Zeug persistieren und muss dann auf Tabellendenkweise umschwenken. 00:53:17.610 --> 00:53:24.010 Und also dieser Übergang, der ist alles andere als fließend und 00:53:24.490 --> 00:53:30.410 da ist meines Erachtens nach ganz, ganz schön, wenn man dann so Geschichten wird, 00:53:30.570 --> 00:53:36.810 zum Beispiel Document Stores hat, die schon relativ ähnlich sind wie die Datenstrukturen, 00:53:36.890 --> 00:53:39.290 die ich in meiner Applikation vorhalte. 00:53:39.530 --> 00:53:42.890 Also wenn man jetzt gerade mal JSON, also die JavaScript-Object-Notation, 00:53:42.970 --> 00:53:48.250 falls sich jemand nachschlagen will, nimmt, das ist ein relativ einfaches Datenformat, 00:53:48.730 --> 00:53:52.970 was so einfache Typen, äh, Datentypen hat, 00:53:53.130 --> 00:53:59.130 wie Strings, Nummern, Arrays und assoziative Arrays, 00:53:59.210 --> 00:54:00.330 also Hashmaps. 00:54:01.050 --> 00:54:06.330 Und das sind im Endeffekt Datenstrukturen, die ich es in der Form schon in meiner Programmiersprache vorliegen 00:54:06.330 --> 00:54:08.090 habe und dort auch benutze. 00:54:08.250 --> 00:54:12.570 Und wenn ich diese jetzt in der Form so direkt in die Datenbank speichern kann, 00:54:12.730 --> 00:54:17.290 dann erübrigt sich das Übersetzen in Tabellen halt im Endeffekt genau. 00:54:17.690 --> 00:54:20.250 Da gibt es ja auch viele Produkte, die das bisher schon ermöglicht haben. 00:54:20.330 --> 00:54:24.890 Deswegen gibt es Hibernate zum Beispiel oder Topplink heißt es, glaube ich, 00:54:25.050 --> 00:54:27.530 oder Active Record bei Rails zum Beispiel. 00:54:27.610 --> 00:54:31.450 Die machen ja nichts anderes, als dem Entwickler von Tabellen und Spalten wegzuhalten, 00:54:31.530 --> 00:54:33.450 sondern ihn in seiner schönen Objektwelt zu lassen. 00:54:33.610 --> 00:54:33.770 Genau. 00:54:34.010 --> 00:54:38.810 Das Problem ist natürlich, das ist wie mit dem Ferrari-Nackerflügen, geht schon, aber geht auch einfacher. 00:54:38.970 --> 00:54:39.850 Also diese und schneller. 00:54:40.170 --> 00:54:45.610 Diese Produkte, die du gerade beschrieben hast, die nennt sich ORM für objektrelationale Mapper und die werden 00:54:45.610 --> 00:54:48.570 halt relativ schnell sehr, sehr komplex. 00:54:48.730 --> 00:54:55.610 Also wenn man, also ich kenne das Beispiel von dem Vergleich CouchDB gegenüber 00:54:56.650 --> 00:55:02.250 CouchDB gegenüber Active Record, dem objektrationalen Mapper von Ruby and Rails. 00:55:02.410 --> 00:55:04.890 Und die haben ungefähr ähnlich viel Code. 00:55:04.970 --> 00:55:08.570 Und das eine ist eine komplette Datenbank und das andere ist nur der Mapper zu der Datenbank. 00:55:08.650 --> 00:55:15.530 Da merkt man schon, da ist relativ viel Komplexität auch drin, um da SQL zu generieren 00:55:15.530 --> 00:55:20.170 und automagisch die Tabellen auch anzulegen und zu migrieren und so weiter. 00:55:20.490 --> 00:55:23.130 Ich wollte nämlich sagen, es gibt so XML-Mapper gibt es nämlich schon länger. 00:55:23.290 --> 00:55:26.250 Genau, das können nämlich normalerweise die großen Datenbanken mittlerweile richtig. 00:55:26.650 --> 00:55:28.730 Da schmeißt du eine XML drauf und den Rest macht die Daten. 00:55:29.370 --> 00:55:32.970 Da gibt es auch einen super Paper oder sogar einen Blogpost, das sehr berühmt dadurch geworden ist, 00:55:33.050 --> 00:55:39.850 von Ted Noort, The Vietnam of Computer Science, wo er halt so ein bisschen den sogenannten Impedance 00:55:40.250 --> 00:55:44.730 Mismatch, wird es genannt, beschreibt, dass einfach meine Daten, die ich in Objekten habe, 00:55:45.210 --> 00:55:50.250 dass es viel Arbeit ist, die auf Tabellen abzubilden und dass es da verschiedene Möglichkeiten gibt und alle 00:55:50.250 --> 00:55:54.010 haben Vor- und Nachteile, ich könnte es entweder ganz flach machen oder ich kann dann halt irgendwelche 00:55:54.010 --> 00:55:58.890 Normalformen angeben und es dann irgendwie ewig durchprügeln und da könnt ihr euch, 00:55:59.290 --> 00:56:02.810 auch in den Shownotes mal einen Link zu dem Paper kommen, da redet er ein bisschen drüber, 00:56:03.450 --> 00:56:07.290 dass das vielleicht gar nicht so gut zusammenpasst und dass man da vielleicht auch drüber nachdenken könnte, 00:56:07.450 --> 00:56:09.210 Objekte anders zu speichern als in Tabellen. 00:56:09.290 --> 00:56:09.530 Genau. 00:56:09.770 --> 00:56:14.250 Und da gab es ja jetzt auch schon seit Jahren so objektorientierte Datenbanken, 00:56:14.330 --> 00:56:16.410 die versucht haben, sowas abzubilden. 00:56:16.730 --> 00:56:23.210 Die hatten allerdings oft starke Performance-Probleme und kamen deshalb auch nicht so richtig groß zum 00:56:23.210 --> 00:56:23.610 Einsatz. 00:56:23.690 --> 00:56:30.330 Also mir würde jetzt auch spontan kein System einfallen, was irgendwie eine relevante Verbreitung hat. 00:56:30.410 --> 00:56:31.130 Fällt dir was eigentlich? 00:56:31.450 --> 00:56:32.650 TB2 spricht XML. 00:56:32.810 --> 00:56:36.330 Also das seitdem seit dem Viper-Release. 00:56:36.410 --> 00:56:37.850 Das kann ich mir merken, da war ich mal bei EBS. 00:56:38.730 --> 00:56:40.010 Das Nummer 9, glaube ich, Version 9. 00:56:40.170 --> 00:56:41.690 Genau, bin mir nicht so hundertprozentig sicher. 00:56:41.930 --> 00:56:46.970 Ne, ich meinte jetzt dedizierte, objektorientierte Datenbanksysteme, fällt mir gerade spontan keins ein. 00:56:47.050 --> 00:56:51.610 Die großen, die haben das dann nachgerüstet, so als Zusatzfeature, was man dann noch mit anbieten kann. 00:56:51.770 --> 00:56:53.450 Aber so dedizierte Objektstores. 00:56:54.090 --> 00:56:56.890 Es gab halt, also es gab früher schon welche Gemstone zum Beispiel, 00:56:56.970 --> 00:57:00.570 was bei Smalltalk recht groß war, weil Smalltalk halt echt mal objektorientiert ist, 00:57:00.650 --> 00:57:01.210 also alles. 00:57:01.290 --> 00:57:03.530 Und die haben dann halt auch so eine objektorientierte Basis. 00:57:03.610 --> 00:57:10.170 Es gibt hier immer so Jade, Diversant Object Database, DB2 haben sie auch irgendwie dieses Informex 00:57:10.410 --> 00:57:11.210 reingebaut. 00:57:11.530 --> 00:57:12.890 Und da gab es schon welche. 00:57:13.210 --> 00:57:18.810 Ja, wobei es gibt tatsächlich so auf spezielle Frameworks oder Programmiersprachen festgelegte 00:57:18.810 --> 00:57:21.530 Datenbanksysteme gibt es schon ein paar, die mir jetzt auch einfallen. 00:57:21.770 --> 00:57:26.890 Also es gibt zum Beispiel für Erlangen dieses Mnesia, was irgendwie mal Amnesia hieß und dann haben sie das A 00:57:26.970 --> 00:57:27.210 weggelassen. 00:57:28.170 --> 00:57:32.490 Nee, das haben sie weggelassen, weil das Amnesie für eine Datenbank als Name ist. 00:57:32.650 --> 00:57:33.610 Richtig vergisst alles. 00:57:34.730 --> 00:57:36.090 Schon den ersten Buchstaben vergessen. 00:57:36.650 --> 00:57:41.370 Und dann gibt es auch in Soap für Python, 00:57:41.770 --> 00:57:48.170 die benutzen intern dann eine objektorientierte Datenbank, aber das sind halt relativ spezialisierte Lösungen, 00:57:48.250 --> 00:57:52.090 die halt auch nur aus bestimmten Programmiersprachen aufrufbar ist. 00:57:52.250 --> 00:57:54.490 Genau, es gab auch irgendwie Object-DB für Java mal. 00:57:54.570 --> 00:57:55.690 Ich weiß nicht, was war Derby? 00:57:55.770 --> 00:57:56.650 War Derby relational? 00:57:56.810 --> 00:57:57.370 Weiß das jemand? 00:57:57.610 --> 00:58:00.250 Derby war, glaube ich, auch eine objektorientierte. 00:58:01.690 --> 00:58:03.370 War Derby nicht sogar ein Twitter zwischen beiden wieder? 00:58:03.610 --> 00:58:04.490 Ja, das kann gut sein. 00:58:06.810 --> 00:58:08.650 Achso, die berühmteste, Gott, wie hieß sie denn? 00:58:08.730 --> 00:58:09.450 Berkeley DB. 00:58:09.770 --> 00:58:14.010 Berkeley DB war so ewig alt, robust wie Sau, aber. 00:58:14.490 --> 00:58:16.970 Wird immer noch eingesetzt, liegt die unter LDAP drunter. 00:58:17.370 --> 00:58:17.770 Richtig, genau. 00:58:18.010 --> 00:58:19.690 Die funktioniert nicht auf NFS, aber das ist egal. 00:58:20.010 --> 00:58:22.890 Oder unter deinem Mail-Server oder unter was weiß ich. 00:58:24.170 --> 00:58:24.890 Also gab es schon, aber. 00:58:26.410 --> 00:58:27.610 Richtig, aber war halt nie so für die. 00:58:27.850 --> 00:58:29.370 Es gehört eigentlich nicht Oracle, ja. 00:58:29.610 --> 00:58:30.090 Dieser Rechner. 00:58:30.570 --> 00:58:32.250 And that's why you can't have nice things. 00:58:32.650 --> 00:58:32.970 Genau. 00:58:33.290 --> 00:58:34.410 Alles Oracle gehört. 00:58:34.570 --> 00:58:34.810 Genau. 00:58:35.530 --> 00:58:36.330 Ja, ne. 00:58:36.810 --> 00:58:38.410 So viel zum Thema Dokumente. 00:58:38.650 --> 00:58:38.890 Genau. 00:58:39.210 --> 00:58:41.290 Gibt es noch eine, weiß nicht, die Graphen. 00:58:41.690 --> 00:58:42.090 Die Grafen. 00:58:42.250 --> 00:58:42.570 Graftdaten. 00:58:42.810 --> 00:58:45.210 Ingo, hast du da nicht neulich mal so einen Podcast drüber gemacht? 00:58:45.610 --> 00:58:46.650 Deswegen weiß ich trotzdem noch nicht. 00:58:46.970 --> 00:58:48.410 Kann man doch mal einen Plog anbringen. 00:58:48.570 --> 00:58:49.050 Ja, genau. 00:58:49.130 --> 00:58:53.690 Also wer sich mehr über Graf-Datenbanken das anhören will, 00:58:53.770 --> 00:58:58.490 wir haben da letztens im Dezember einen Podcast zemacht. 00:58:58.650 --> 00:59:05.290 Da war ich in Erfurt und habe mit einem mit Alexander Ollingen 00:59:05.290 --> 00:59:08.410 geredet über Graf-Datenbanken und hier in Deutschland wird eine entwickelt, 00:59:08.490 --> 00:59:09.930 die nennt sich Graf DB. 00:59:10.410 --> 00:59:12.970 Und da gehen wir sowas mal alles durch. 00:59:13.130 --> 00:59:15.690 Also was sind Graf-Datenbanken, wofür benutzt man das? 00:59:15.770 --> 00:59:20.890 Und am Ende haben wir auch nochmal das, was jetzt bei uns auch gleich kommt, so einen kleinen Überblick drin. 00:59:21.850 --> 00:59:26.570 Was ist eigentlich aus seiner Sicht gut für NoSQL-Datenbanken? 00:59:26.730 --> 00:59:29.050 Also welche sollte man für welchen Typ nehmen? 00:59:29.210 --> 00:59:31.450 Wofür sind Graf-Datenbanken gut? 00:59:31.530 --> 00:59:37.130 Also wer da sich ein bisschen tiefer einsteigen will, kann sich diesen Extra-Podcast dann auch so zwei 00:59:37.130 --> 00:59:37.450 Stunden. 00:59:38.330 --> 00:59:41.450 Das Modell generell vielleicht noch, das muss nicht ganz ablassen. 00:59:41.530 --> 00:59:44.570 So Leute, die ein bisschen mathematisch angehaucht sind, da gibt es ja diese Graphentheorie, 00:59:44.650 --> 00:59:49.370 da gibt es dann halt Ecken und Kanten oder Edges und Vertices im Englischen. 00:59:50.570 --> 00:59:51.370 Was Ecken? 00:59:51.530 --> 00:59:51.770 Nee. 00:59:53.210 --> 00:59:53.850 Knoten und Kanten. 00:59:54.090 --> 00:59:56.730 Noten und Kanten, Gott und Edges und Vertices heißt halt dann. 00:59:56.970 --> 00:59:57.850 Ja, oder Nodes. 00:59:58.090 --> 00:59:59.050 Oder Nodes, genau. 00:59:59.290 --> 01:00:04.650 Und das ist halt das Schema, so wie andere ihre Daten in Tabellen mit Zeilen und Spalten ablegen. 01:00:05.530 --> 01:00:11.050 Genau, machen die das halt über quasi auch Relationen ablegen. 01:00:11.230 --> 01:00:12.590 Aber halt nicht in Beziehung gerade. 01:00:12.750 --> 01:00:12.910 Genau. 01:00:13.710 --> 01:00:19.950 Einfach nur ist der Freund von oder sowas, kann man dann ruhig mal als Beziehung benutzen und gibt einem halt 01:00:19.950 --> 01:00:23.550 die Möglichkeit, so das typische Beispiel ist halt der Social Graft, 01:00:23.630 --> 01:00:23.710 ja. 01:00:24.190 --> 01:00:26.030 Weiß nicht, wie viele Leute das implementieren, aber. 01:00:26.590 --> 01:00:31.470 Naja, gut, ich meine, also Twitter und Co., die basteln ja auch irgendwas, 01:00:31.550 --> 01:00:33.950 was diese Grafen halt gerade abspeichern kann. 01:00:34.030 --> 01:00:37.390 Also für bestimmte Sachen bräuchte man es dann halt. 01:00:38.590 --> 01:00:41.230 Ja, gerade in so einer Richtung ist das schon so ein bisschen so ein bisschen so. 01:00:41.390 --> 01:00:42.910 Genau, es nimmt immer eh. 01:00:43.150 --> 01:00:46.030 Genau, es nimmt halt halt die Arbeit, ab es macht bei vielen relationalen Systemen, 01:00:46.110 --> 01:00:50.510 heißt es halt so, gib mir alle Freunde von Andreas, flup, kriegst einen Haufen Freunde zurück und dann gehst 01:00:50.510 --> 01:00:53.150 du zum ersten Freund und sagst, gib mir die Freunde von dem, flup. 01:00:53.230 --> 01:00:55.070 Und du musst halt ewig hin und her reden. 01:00:55.150 --> 01:00:58.830 Und bei den Grafen ist halt dieses Traversieren, also von einem Datensatz zum nächsten, 01:00:58.910 --> 01:01:03.710 zum nächsten, zum nächsten, ist quasi die bevorzugte Art, über Daten zu navigieren, 01:01:03.790 --> 01:01:04.830 bei diesen Graf-Datenbanken. 01:01:05.070 --> 01:01:08.030 Und die werden da auch extrem, extrem schnell bei, was man so liest. 01:01:08.110 --> 01:01:11.790 Also ich habe es mal mit Neo4j, was eine, kommen wir vielleicht später noch dazu versucht, 01:01:11.870 --> 01:01:15.630 und die sollen also wirklich irgendwie Millionen von diesen pro Sekunde durchhauen können von diesen 01:01:15.630 --> 01:01:16.430 Traversierungen. 01:01:16.510 --> 01:01:20.670 Also da kannst du durch deine Daten recht schnell rennen, ohne dass du permanent mit dem Server groß 01:01:20.670 --> 01:01:22.270 austauschen musst und Overhead hast. 01:01:22.350 --> 01:01:29.150 Ja, also ich glaube, durch diese Graphendarstellung intern ist das ja im Endeffekt auch sowas 01:01:29.150 --> 01:01:34.510 wie ein impliziter impliziter Cache oder ein impliziter Index, 01:01:34.750 --> 01:01:39.950 dass man dann praktisch sagt, okay, ich möchte jetzt die Freunde von den Freunden von den Freunden von einer 01:01:39.950 --> 01:01:46.350 Person, dann kann man das relativ schnell mit einem Aufwasch durchtravasieren und muss dann nicht erst suchen, 01:01:46.430 --> 01:01:50.510 ja, mit wem ist der jetzt alles befreundet und so weiter, weil man hat das im Endeffekt schon implizit in der 01:01:50.510 --> 01:01:51.470 Datenstruktur mit eingebaut. 01:01:51.950 --> 01:01:55.390 Oder die typische Ahnentafeln sind Beispiel für Grafdatenbanken. 01:01:55.470 --> 01:01:57.550 Und ich habe noch eins im Kopf, was mir gerade nicht einfällt. 01:01:58.350 --> 01:02:02.190 Ja, da können wir vielleicht ja nachher, wenn wir mal über die Datenbanken selber reden, drauf kommen. 01:02:03.630 --> 01:02:07.070 Es ist natürlich jetzt, wenn wir jetzt gleich zu den Datenbanken kommen, 01:02:07.230 --> 01:02:12.750 also manche Datenbanken lassen sich da nicht in eins direkt reinschieben, 01:02:12.830 --> 01:02:16.830 sondern sind irgendwie so eine Mischung aus einem dieser vier, haben wir jetzt vorgestellt, 01:02:16.910 --> 01:02:19.550 vielleicht gibt es ja noch welche und wir wissen sie jetzt bloß gerade nicht. 01:02:19.630 --> 01:02:21.630 Die vier haben wir jetzt einfach mal aufgenommen. 01:02:22.670 --> 01:02:26.910 Und ja, also die mixen sich auch untereinander. 01:02:26.990 --> 01:02:31.630 So NoSQL-Datenbank heißt nicht, es muss nur eine reine Graf-Datenbank sein, 01:02:31.710 --> 01:02:35.950 es muss nur ein reiner Key-Value-Store sein, wie wir ja schon vorhin gesagt haben, 01:02:36.030 --> 01:02:39.790 Key-Value-Store kann ich auch mit der MySQL-Datenbank abbilden, wenn ich das dann möchte. 01:02:40.510 --> 01:02:44.350 Also nicht, dass ihr denkt, nur weil wir das jetzt hier so eingeteilt haben, 01:02:44.430 --> 01:02:49.550 ist das der Weisheit letzter Schluss, weil NoSQL ist halt alles irgendwie und alles ein bisschen. 01:02:49.870 --> 01:02:52.430 Ja, und die Grenzen sind halt auch extrem schwimmend. 01:02:52.510 --> 01:02:58.030 Also ja, also die nähern sich mit der Zeit auch einander an und gucken sich gegenseitig Features ab und so. 01:02:58.110 --> 01:03:03.630 Deshalb ist diese Unterteilung jetzt auch nur irgendwie für den Moment gültig und könnte in zwei Jahren schon 01:03:03.630 --> 01:03:04.510 ganz anders draus sein. 01:03:05.150 --> 01:03:10.510 Um diese NoSQL-Datenbanken zu verstehen, gibt es eine Menge, 01:03:10.670 --> 01:03:12.430 ja, wie sagt man so schön, Papers. 01:03:12.510 --> 01:03:17.470 Also Leute, die sich wissenschaftlich darüber ausgelassen haben, wie könnte man das dann so machen. 01:03:17.710 --> 01:03:22.270 Sehr bekannt sind da wahrscheinlich Google und Amazon in der Richtung. 01:03:22.590 --> 01:03:23.390 Unter anderem, ja. 01:03:23.710 --> 01:03:26.990 Die sollen ja große Systeme haben, wo sie eventuell sowas benutzen können. 01:03:27.470 --> 01:03:28.270 Bräuchten sowas, ja. 01:03:28.750 --> 01:03:32.350 Wissen ja, die wenigstens, dass Amazon nicht auf einem einzigen MySQL-Server läuft, ne? 01:03:33.150 --> 01:03:35.550 Also auf so einem Notebook im Keller. 01:03:35.710 --> 01:03:36.270 Richtig. 01:03:37.790 --> 01:03:38.990 Haben die bestimmt mal angefangen. 01:03:39.630 --> 01:03:45.230 Die haben früher auf riesen HP-UX-Kisten, die nennen sich Superdomes mit BeaWebLogic Server und 01:03:45.230 --> 01:03:46.670 Oracle-Datenbanken rumgespielt. 01:03:46.990 --> 01:03:47.710 Gesundheit. 01:03:49.470 --> 01:03:50.110 Superdome. 01:03:51.630 --> 01:03:54.830 Erinnere mich so ein bisschen an Mad Max, Thunder Dome, Two Men Enter, One Man Leaves. 01:03:55.230 --> 01:03:55.630 Superdome. 01:03:56.350 --> 01:03:59.790 Interne Redundanzen und das sind schon relativ große Trümmer. 01:03:59.950 --> 01:04:02.510 Ja, das sind dann halt auch so mit vorgoldenen Kanten so. 01:04:02.830 --> 01:04:04.990 HP Ux, HP steht ja für High Prices. 01:04:06.030 --> 01:04:08.830 HP ist High Prices, HP UX ist High Prices, Unix. 01:04:10.270 --> 01:04:10.910 Richtig. 01:04:11.150 --> 01:04:11.390 Ja. 01:04:11.630 --> 01:04:16.670 Genau, auf jeden Fall, da gibt es, wie du gerade gesagt hast, da gibt es die und die haben alle mal 01:04:16.750 --> 01:04:20.190 freundlicherweise so ein bisschen aufgeschrieben, was sie sich denn dabei denken überhaupt, 01:04:20.270 --> 01:04:21.630 dass sie da so Systeme bauen. 01:04:21.870 --> 01:04:24.030 Bedeutet, die haben da dieses Papers gemacht. 01:04:24.190 --> 01:04:28.830 Und ich weiß nicht, angefangen, war es der Anfang des Stonebreaker-Paper? 01:04:28.990 --> 01:04:30.910 Ich glaube, das war eins der ersten, das war glaube ich 2001. 01:04:31.230 --> 01:04:35.710 Genau, hieß irgendwie The End of an Architectural Era und dann irgendwie it's time for a re-implementation 01:04:35.710 --> 01:04:35.950 oder so. 01:04:36.270 --> 01:04:41.950 Auf jeden Fall, da hat sich dieser Stonebreaker mal so die typischen Systeme angeschaut, 01:04:42.190 --> 01:04:49.150 die Data Warehousing machen und die alle auch noch recht auf so relationalen Modellen basiert waren. 01:04:49.710 --> 01:04:52.910 Und da hat er sich einfach mal überlegt, ist das überhaupt sinnvoll? 01:04:52.990 --> 01:04:56.990 Weil wir wollen hier, wir haben echt Unmengen an Daten und wir brauchen spezielle Systeme, 01:04:57.150 --> 01:05:01.470 um die, die da performant uns Reports rausgenerieren können, zum Beispiel. 01:05:01.710 --> 01:05:04.350 Oder die sie Daten performant speichern können. 01:05:05.310 --> 01:05:08.670 Und da hat er sich halt dann mal angeschaut, was gibt es denn da schon? 01:05:08.750 --> 01:05:11.710 Und hat sich dann mal gedacht, ja, wie würde ich denn das jetzt selber implementieren, 01:05:11.790 --> 01:05:16.190 wenn ich nicht dieses Constraint hätte, dass ich sage, muss jetzt irgendwie so auf meine alten Systeme 01:05:16.190 --> 01:05:17.070 abgebildet werden. 01:05:17.150 --> 01:05:18.350 Dann hatte ich glaube ich diesen, was war es? 01:05:18.510 --> 01:05:19.630 C-Store hieß es, glaube ich. 01:05:19.790 --> 01:05:24.590 Das hieß zuerst, C-Store ist dann danach zu Volt DB umbenannt. 01:05:24.750 --> 01:05:26.270 Genau, Volt DB ist jetzt irgendwie das kommerzielle. 01:05:26.670 --> 01:05:27.710 H-Store hieß es, glaube ich. 01:05:27.950 --> 01:05:29.790 H-Store, ja, kann gut sein. 01:05:29.870 --> 01:05:32.270 Auf jeden Fall hat er sich da was Eigenes überlegt und hat herausgekommen, 01:05:32.350 --> 01:05:34.190 so, oh, ich bin hundertmal so schnell wie die. 01:05:34.270 --> 01:05:35.470 Das ist eine komische Sache. 01:05:35.630 --> 01:05:37.470 Und das war so ein bisschen das Paper, wo er. 01:05:38.270 --> 01:05:42.110 Das Paper beschreibt so ein bisschen, was war denn bisher so und warum macht es vielleicht Sinn, 01:05:42.190 --> 01:05:45.470 wenn wir da mal drüber nachdenken, ob das überhaupt noch so Sinn macht für unsere Aufgaben. 01:05:45.950 --> 01:05:52.670 Also das Paper beschreibt halt auch vor allem, was sich jetzt seit den 70er Jahren geändert hat in 01:05:52.670 --> 01:05:54.030 Anforderungen für Datenbanken. 01:05:54.190 --> 01:05:56.750 Ich muss gestehen, das kommt mir so ein bisschen wie Galileo mit dem Ei vor, 01:05:56.830 --> 01:05:59.790 der das Ei auf den Kopf gestellt hat und wo er dann in seinem Paper feststellt, 01:05:59.870 --> 01:06:01.470 dass nicht alles Bankenmondversicherungen sind. 01:06:01.710 --> 01:06:02.750 Genau, letzten Endes. 01:06:04.830 --> 01:06:08.510 In der Informatik wird ja auch irgendwie alle zehn Jahre eine neue Sau durchs Dorf getrieben. 01:06:08.750 --> 01:06:12.590 Objektorientierung war die letzte große, die funktioniert jetzt bisher noch ganz gut für uns, glaube ich. 01:06:14.590 --> 01:06:16.830 Richtig, jetzt kommt halt funktionale Programmierung, wo die Leute sagen, 01:06:16.910 --> 01:06:21.070 ja, Objektorientierung ist gut, aber wir haben jetzt zu viele Cores und hier geht alles kaputt und so. 01:06:21.310 --> 01:06:24.350 Und das war halt auch so die Idee von diesem Stonebreaker-Paper. 01:06:24.430 --> 01:06:26.190 So, Datenbank bisher ist ja schon cool, aber. 01:06:26.590 --> 01:06:28.670 Der kannte sich auch richtig damit aus, sehe ich gerade. 01:06:28.990 --> 01:06:35.070 Also man muss dazu sagen, dieser Stonebreaker, der hat auch bei Ingress mitgearbeitet und später bei der 01:06:35.070 --> 01:06:36.110 Postgres-Datenbank. 01:06:36.190 --> 01:06:40.190 Das heißt, der kannte sich auch in der relationalen Datenbankwelt extrem gut aus, 01:06:40.270 --> 01:06:41.870 auch was die Implementierung angeht. 01:06:42.110 --> 01:06:44.830 Richtig, und da ist ja schön, dass er weiß, von was er redet. 01:06:44.990 --> 01:06:45.470 Genau. 01:06:45.710 --> 01:06:47.950 Genau, das war so der Anfang. 01:06:48.030 --> 01:06:50.590 Und dann kamen ja noch so die großen Implementierungen. 01:06:50.670 --> 01:06:51.550 Was gab es denn da? 01:06:51.790 --> 01:06:54.270 Genau, also wie hat jetzt Amazon gemacht? 01:06:55.150 --> 01:07:00.670 Amazon Dynamo ist da der das Schlagwort. 01:07:00.910 --> 01:07:07.230 Ja, es ist halt einfach, Amazon beschreibt da so ein bisschen ihr System, wie sie denn. 01:07:07.710 --> 01:07:10.750 Also ist eigentlich sehr komisch, weil das ist eigentlich schon das Kernsystem, 01:07:10.910 --> 01:07:12.030 das sie da implementiert haben. 01:07:12.430 --> 01:07:15.150 Die zeigen jedem eigentlich, wie sie ihre Datenbanken so aufbauen. 01:07:15.310 --> 01:07:20.350 Und das Gute ist, dass die halt so gute Leute haben, dass andere Leute das nicht so anständig 01:07:20.350 --> 01:07:22.030 nachimplementieren können, wahrscheinlich. 01:07:24.030 --> 01:07:26.270 Aber ist ja ein guter Gedanke, dass man es mal raustrickt. 01:07:26.350 --> 01:07:29.310 Und ich meine, das ist ja tatsächlich wissenschaftlich gut gemacht. 01:07:29.550 --> 01:07:32.510 Genau, da muss man sich ja mal richtig Gehirnschmalz reinstecken. 01:07:32.750 --> 01:07:33.790 Mal losgelöst von der Wiki. 01:07:33.950 --> 01:07:35.630 Die Geschichte Amazon ist schon echt cool, ne? 01:07:35.710 --> 01:07:39.070 Die stellen alle Daten frei zur Verfügung, du kannst da frei drauf zugreifen. 01:07:39.710 --> 01:07:42.350 Du darfst die Sachen einfach weiterverwenden, das ist schon relativ cool. 01:07:42.670 --> 01:07:44.270 Klar, und sie bieten natürlich auch Services drauf an. 01:07:44.350 --> 01:07:48.350 Also Amazon ist ja, ich weiß nicht, die machen wahrscheinlich immer noch ein bisschen mehr Geld mit ihrem 01:07:48.350 --> 01:07:50.510 Bücherverkaufen als ein bisschen gar nicht. 01:07:52.430 --> 01:07:55.950 Doch, dafür noch wesentlich mehr noch als mit Server-Hosting. 01:07:56.670 --> 01:07:59.470 Alle Start-ups verwenden die halt, die verlangen da nicht so wenig Geld für. 01:07:59.710 --> 01:08:00.430 Das ist im Verhältnis. 01:08:01.310 --> 01:08:02.270 Ich verstehe nicht warum. 01:08:02.430 --> 01:08:03.310 Entschuldigung, bitte. 01:08:03.950 --> 01:08:10.670 Aber im Verhältnis dazu, was die als Handelsunternehmen einen Umsatz machen, ist das noch nichts. 01:08:10.830 --> 01:08:13.870 Wir können in zehn Jahren nochmal drüber reden, dann kann ich mir das durchaus vorstellen, 01:08:13.950 --> 01:08:16.270 wenn sie den Teil nicht abgestoßen haben oder irgendeinen davon. 01:08:16.590 --> 01:08:18.190 Umsatz und Gewinn ist halt so. 01:08:18.430 --> 01:08:22.430 Also die sind schon relativ, also der leistungsfähigste Online-Händler, 01:08:22.510 --> 01:08:24.270 den es weltweit so gibt, muss man ganz klar sagen. 01:08:24.670 --> 01:08:26.910 Inklusive der ganzen Infrastruktur, die dahinter hängt. 01:08:27.070 --> 01:08:33.070 Das ist ja jetzt nicht nur, dass die von der Informatikern eine Menge Know-how haben und das auch gut 01:08:33.070 --> 01:08:35.950 umsetzen, sondern die haben auch eine unglaubliche Infrastruktur. 01:08:37.390 --> 01:08:42.350 Und dieses Hosten ist tatsächlich ja nur ein Abfallprodukt zurzeit. 01:08:42.830 --> 01:08:43.710 Also am Anfang. 01:08:44.350 --> 01:08:47.710 Jetzt vielleicht nicht mehr so, aber vor einem Jahr oder so war das ja, 01:08:48.030 --> 01:08:51.870 ja, wir haben so viel Zeug rumzustehen, wissen nicht, was wir damit machen sollen. 01:08:53.310 --> 01:08:54.190 Ist ja eigentlich eine gute Idee. 01:08:54.270 --> 01:08:58.190 Du kaufst jetzt so ein Storage-System von EMC oder von wem auch immer und das kostet dich eine Million, 01:08:58.270 --> 01:08:59.070 sage ich jetzt mal. 01:08:59.230 --> 01:09:01.390 Und du kriegst jetzt die zehnfache Menge für 5 Millionen. 01:09:01.470 --> 01:09:03.470 Und du sagst, ich brauche aber nicht einen zehnfachen Platz. 01:09:03.550 --> 01:09:05.150 Was mache ich denn jetzt mit dem restlichen Speicher? 01:09:05.310 --> 01:09:06.830 Ach, den vermiete ich mal für kleines Geld. 01:09:06.910 --> 01:09:10.990 Das ist doch eigentlich gar nicht doof gedacht letzten Endes. 01:09:11.070 --> 01:09:14.270 Ja, wobei, da gab es noch nicht auf InfoQ, ich muss mal schauen, ob ich den Link noch finde, 01:09:14.350 --> 01:09:15.870 da redet einer drüber, wie das alles angefangen hat. 01:09:15.950 --> 01:09:18.670 Das war wohl nicht ganz so, dass es echt nur Abfall war, sondern die haben sich da gedacht, 01:09:18.830 --> 01:09:23.870 also ihr Problem war halt von Amazon, wir haben Unmengen an Daten und Unmengen an Leute, 01:09:23.950 --> 01:09:25.630 die auf diese Daten täglich einprügeln. 01:09:25.790 --> 01:09:32.510 Also nicht so wie bei einer Bank, dass da, ich sag mal, ja, da suchst halt deinen Kontoauszug raus und die 01:09:32.510 --> 01:09:34.590 hatten wirklich tausende Requests pro Sekunde. 01:09:34.670 --> 01:09:37.630 Gut, bei einer Bank wahrscheinlich mit Transaktionen und so auch ähnlich, 01:09:37.710 --> 01:09:42.110 aber sie hatten halt das Problem und hatten das Problem, dass sie einfach da Unmengen an Server für hinstellen 01:09:42.110 --> 01:09:44.990 mussten und die Daten irgendwie verwalten. 01:09:45.070 --> 01:09:48.270 Und da hat sich dann irgendwann gelohnt, dass sie einfach sehr intelligente Leute da hingesetzt haben. 01:09:48.350 --> 01:09:52.510 Ist auch schön, Amazon ist so eine Engineering Company, also die sind ähnlich wie Google, 01:09:52.590 --> 01:09:57.070 halt nicht so von, ich sag mal, BWL getrieben, sondern die machen technisch gute Lösungen und deswegen 01:09:57.070 --> 01:10:00.510 verkaufen die auch so viele Sachen, weil es halt einfach ist und einfach mal klappt. 01:10:00.750 --> 01:10:06.190 Und die haben halt mit diesem Amazon Dynamo ein 01:10:06.510 --> 01:10:11.470 Datenspeicherungssystem geschrieben, das 01:10:14.030 --> 01:10:17.790 ihr Problem, ihre Problemdomäne schön abgebildet hat, nämlich ein sehr großes, 01:10:17.870 --> 01:10:21.870 sehr verteiltes System, global verteilt, also nicht nur im selben Datacenter, 01:10:22.110 --> 01:10:27.790 sondern auch über Datacenter hinweg in anderen Kontinenten und die haben da was geschrieben, 01:10:27.950 --> 01:10:29.470 das damit gut umgehen kann. 01:10:30.590 --> 01:10:32.110 Ja, und Ausfallsicher auch noch? 01:10:32.270 --> 01:10:38.430 Und ja genau, also alle diese Sachen halt halt recht gut abdeckt und das ist so, 01:10:38.590 --> 01:10:41.070 ich weiß jetzt nicht, inwiefern wir stark auf Dynamo eingehen sollen, 01:10:41.150 --> 01:10:42.430 so die Implementierungsdetails. 01:10:42.830 --> 01:10:46.910 Ja, aber ich würde schön wir vielleicht mal ein bisschen, weil später haben wir auch noch Datenbanken, 01:10:46.990 --> 01:10:47.950 die da drauf aufbauen. 01:10:48.190 --> 01:10:54.350 Genau, also so ein paar Worte dazu noch, also dass er die Datensätze immer mehrfach speichert zum Beispiel. 01:10:55.070 --> 01:10:58.430 Ja, genau, also das ist halt, es ist ein verteiltes System, bedeutet, 01:10:58.510 --> 01:11:04.110 da ist generell ist es so, dass Amazon Consistent Hashing benutzt in dem System. 01:11:04.190 --> 01:11:05.470 Das ist vielleicht so die erste Sache. 01:11:05.630 --> 01:11:09.550 Die benutzen ein virtuelles Netz quasi. 01:11:09.630 --> 01:11:15.150 Bedeutet, sie haben Unmengen an Servern und Daten und die musst du ja irgendwie logisch anordnen, 01:11:15.390 --> 01:11:16.670 damit du die wiederfinden kannst. 01:11:16.750 --> 01:11:21.470 Du kannst ja nicht alle Server so, ich sag mal, flach in eine Textdatei schreiben und dann da immer permanent 01:11:21.470 --> 01:11:22.110 durchrödeln. 01:11:22.190 --> 01:11:23.070 So hat es ja im Internet. 01:11:23.390 --> 01:11:24.110 Die kannst du schon machen, aber. 01:11:24.350 --> 01:11:26.030 Genau, es ist ja so ähnlich wie die Hostdatei. 01:11:26.110 --> 01:11:28.430 Du kannst natürlich das gesamte Internet, alle DNS-Eintrag gehende, 01:11:28.510 --> 01:11:30.750 deine Hostsdatei reinschreiben auf deinem lokalen Rechner. 01:11:30.910 --> 01:11:31.470 Das geht. 01:11:31.710 --> 01:11:34.270 Ist aber nicht so sonderlich performant und besonders wenn du anfängst, 01:11:34.350 --> 01:11:38.030 das zu managen, da kommen dann halt Leute auf die Idee, mach mal DNS. 01:11:38.350 --> 01:11:43.950 Und Amazon hat auch sowas ähnliches wie DNS quasi, nur dass sie da sowas, 01:11:44.110 --> 01:11:47.310 also einen Verteilungsmechanismus für diese flachen Informationen. 01:11:47.470 --> 01:11:49.150 Das nennen sie Consistent Hashing. 01:11:49.790 --> 01:11:54.350 Bedeutet die, ähm, jedes Datum, 01:11:54.430 --> 01:11:59.950 also jedes Stück Daten, das in dem System drin ist, von diesem Stück kannst du sagen, 01:12:00.110 --> 01:12:01.950 wo es in dem System sein sollte. 01:12:02.190 --> 01:12:06.190 Bedeutet, es ist, äh, jedem wird Hashing-Begriff sein, MD5-Sharon, sowas in der Art. 01:12:06.350 --> 01:12:12.190 Bedeutet, wenn du einen eindeutigen Namen hast, kannst du das hashen und über das Hashen wird quasi in Dynamo 01:12:12.190 --> 01:12:16.110 festgelegt, wo die Daten denn jetzt hin sollen. 01:12:16.350 --> 01:12:22.510 Bedeutet, du kannst dann sagen, aha, der will den Weinöffner irgendwie, keine Ahnung, Expensio kaufen. 01:12:22.670 --> 01:12:27.150 Und dieser Weinöffner hat eine spezielle ID und also eine ganz einfache, 01:12:27.310 --> 01:12:29.870 also wahrscheinlich wird es nicht so implementiert, aber ganz einfach, 01:12:30.030 --> 01:12:34.510 können die dann sagen, ja, wenn er das Bild zu Expensio will, dann muss das auf diesem Server sein, 01:12:34.590 --> 01:12:36.910 weil Expensio diesen Namen hat oder diese ID. 01:12:36.990 --> 01:12:39.550 Das heißt irgendwie, das ist Artikelnummer 12359. 01:12:39.630 --> 01:12:39.790 Genau. 01:12:39.950 --> 01:12:46.430 Und 12359 hashen wir, muss auf Server 5 sein, irgendwie in Rechenzentrum 1, 01:12:46.670 --> 01:12:48.270 Rack 2, Server 3. 01:12:48.510 --> 01:12:48.670 Genau. 01:12:49.150 --> 01:12:53.550 Und sowas können die halt machen, so Rack-Aware das Ganze verteilen, dass sie. 01:12:53.870 --> 01:12:55.310 Heißt aber, das muss aber jeder Anfrage machen. 01:12:55.390 --> 01:12:59.870 Also es kommt eine Anfrage rein, der Hash wird berechnet und dann weiß der, oh, das muss der Server rechnen. 01:13:00.110 --> 01:13:04.430 Richtig, das ist eben, es gibt wenig Sachen in Formatik, die man halt nicht durch Indirektion lösen kann. 01:13:04.670 --> 01:13:08.110 Bedeutet, du hast halt diese Anfrage und dann gibt es einen, also es gibt nicht nur einen, 01:13:08.190 --> 01:13:11.230 sondern der repliziert sich dann auch wieder, aber es gibt so Metadaten-Server, 01:13:11.310 --> 01:13:13.310 die dir sagen, deine Anfrage ist da hinten. 01:13:13.470 --> 01:13:17.790 Und das mag zwar etwas ineffizient sein, weil bei MySQL sage ich halt hier, 01:13:17.870 --> 01:13:19.470 das ist mein Server und da soll das hin. 01:13:19.550 --> 01:13:23.470 Aber wenn du halt irgendwie rein zufällig mal 10.000 Server rumstehen hast, 01:13:23.550 --> 01:13:26.430 wird es ein bisschen problematisch, wenn du nicht jemanden hast, der weiß, 01:13:26.590 --> 01:13:27.950 wo das ganze Zeug ist. 01:13:28.190 --> 01:13:34.510 Und über dieses Hashing, das kannst du dann im Grunde jede Node weiß, 01:13:34.670 --> 01:13:37.710 wo alles andere sein sollte, weil jede Node das System drin hat. 01:13:37.790 --> 01:13:42.670 Bitte du fragst deinen Server, du, gib mir doch mal den Weinöffnerpreis aktuell. 01:13:42.830 --> 01:13:47.310 Und der schaut sich dann an, so Weinöffnerpreis, Weinöffnerpreis bin ich gar nicht für zuständig, 01:13:47.390 --> 01:13:48.910 aber ich weiß ja, wer für zuständig ist. 01:13:49.470 --> 01:13:54.030 Der fragt dann eben seine Nachbarn und das ist auch alles nicht unbedingt eindeutig, 01:13:54.190 --> 01:14:00.190 sondern man weiß halt, aha, das fängt mit 195 an, das sollte ungefähr in der Gegend von meinem Kumpel sein, 01:14:00.350 --> 01:14:02.030 der da irgendwie sich befindet. 01:14:02.190 --> 01:14:07.070 Und dieser freundliche andere Server sagt dann, ah, rein zufällig hat sich das geändert, 01:14:07.150 --> 01:14:08.270 aber ich weiß, wer es hat. 01:14:08.910 --> 01:14:10.430 Das System kennt sich selber. 01:14:10.510 --> 01:14:10.750 Genau. 01:14:10.990 --> 01:14:11.950 Das ist ganz praktisch. 01:14:12.110 --> 01:14:15.070 Und dann wird es hier immer so hübsch weiter geroutet und kommt wieder zurück. 01:14:15.150 --> 01:14:18.350 Und du als Programmierer musst gar nicht wissen, wo sich das alles befindet. 01:14:18.510 --> 01:14:19.790 Das ist das Schöne daran. 01:14:20.030 --> 01:14:23.630 Die klatschen das einfach in die schöne weite Welt und es kommt dann auch zu dir zurück. 01:14:23.710 --> 01:14:29.070 Und alles, was im System in diesem Dynamo passiert, ist im Grunde diese Dynamo-Magie über dieses Consistent 01:14:29.070 --> 01:14:31.390 Hashing, die bauen sich dann so einen lustigen Ring und die wissen dann, 01:14:31.470 --> 01:14:33.150 wer der rechte und linke Nachbar ist. 01:14:33.310 --> 01:14:37.470 Und wenn da jemand Neues dazukommt, dann macht man das quasi wie einer doppelt verkehrten Liste. 01:14:37.630 --> 01:14:43.790 Kannst du dann einfach jemanden einfügen und dann weiß der, aha, ich bin jetzt zwischen irgendwie 195 und 198, 01:14:43.950 --> 01:14:47.070 bedeutet, ich sollte mir mal irgendwie Daten, die dazwischen sind, versuchen anzueignen, 01:14:47.150 --> 01:14:48.750 weil die logisch bei mir sein müssen. 01:14:48.990 --> 01:14:53.070 Ja, ich glaube, diese Geschichte mit dem Ring, da könnte man noch ein bisschen drauf eingehen, 01:14:53.310 --> 01:14:57.390 weil im Endeffekt dieses Consistent Hashing, das basiert alles auf dem Prinzip, 01:14:57.550 --> 01:15:02.990 dass man einen sowas wie eine Quersumme, ein Hash generiert von einem Key, 01:15:03.070 --> 01:15:04.590 auf den man zugreifen will. 01:15:04.750 --> 01:15:07.950 Und diese Hashes, die sind alle in einem Ring angeordnet. 01:15:08.030 --> 01:15:12.910 Und wenn man dann jetzt so diesen Hash erzeugt, dann braucht man sich den kompletten Hash angucken und gucken, 01:15:12.990 --> 01:15:17.470 wo ist denn der jetzt genau aus, sondern man kann sich anhand dieses Hash-Algorithmus schon denken, 01:15:17.630 --> 01:15:23.070 ich gucke mir jetzt irgendwie nur mal die ersten fünf Zeichen an und weiß dann anhand dieser ersten fünf 01:15:23.070 --> 01:15:26.110 Zeichen schon, in welchem Bereich die ungefähr liegen und weiß dann, 01:15:26.350 --> 01:15:30.350 wo ich da hingreifen muss im Netzwerk. 01:15:30.670 --> 01:15:31.230 Genau. 01:15:32.030 --> 01:15:35.390 Das ist ja ähnlich, ich meine, das verwenden wir ja auch so in der normalen Welt, 01:15:35.470 --> 01:15:36.110 das ist ja auch recht normal. 01:15:36.190 --> 01:15:37.310 Postleitzahlen zum Beispiel. 01:15:37.390 --> 01:15:40.830 Wenn die Postleitzahl mit 1 beginnt, weißt du, dass die nicht in Baden-Württemberg liegen wird. 01:15:41.390 --> 01:15:42.670 Das ist ja in Hin und Umgebung. 01:15:42.910 --> 01:15:48.750 Richtig, das ist so eine kontextsensitive Geschichte, nur dass wir halt dieses Postleitzahlen-Prinzip bei 01:15:48.750 --> 01:15:51.070 Dynamo auf quasi alle Daten anwenden können. 01:15:51.150 --> 01:15:53.310 Dass alle wissen grob, wo das sein sollte. 01:15:53.550 --> 01:15:56.910 Und das ist ja auch, keine Ahnung, wenn du einen Hammer willst, dann gehst halt zum Baumarkt. 01:15:56.990 --> 01:15:58.510 Das ist halt so ein Kontext, der in diesem. 01:15:58.990 --> 01:15:59.950 Nicht zum Blumenhändler. 01:16:00.190 --> 01:16:02.110 Richtig, der bei diesem Item mit drin ist. 01:16:02.350 --> 01:16:02.670 Genau. 01:16:03.150 --> 01:16:03.550 Richtig, oder? 01:16:04.830 --> 01:16:06.110 Und deswegen hat Amazon sowas gemacht. 01:16:06.270 --> 01:16:08.270 Also egal was du willst, es gibt es bei Amazon. 01:16:08.350 --> 01:16:09.470 Und Amazon weiß wo. 01:16:09.950 --> 01:16:11.230 Und das ist dieses Dynamo. 01:16:11.390 --> 01:16:13.070 Ich sag mal, das ist so der Grundprinzip. 01:16:13.150 --> 01:16:16.750 Und die haben natürlich irgendwie Vektorclocks, die sie da implementieren, 01:16:16.830 --> 01:16:20.670 um irgendwie die Abfragen schön zu halten und und und. 01:16:21.070 --> 01:16:22.270 Und es skaliert halt schön mit, ne? 01:16:22.350 --> 01:16:25.550 Ich kann so eine neue Pizzabox irgendwo reinschieben und kann sagen, 01:16:25.630 --> 01:16:28.190 hier, nimm mal den Server auch noch dazu und dann. 01:16:28.590 --> 01:16:29.230 Richtig, das ist so. 01:16:29.550 --> 01:16:32.750 Ändert sich der Hash irgendwie und irgendwie ist so drin plötzlich. 01:16:33.150 --> 01:16:35.390 Vielleicht technisch wird es oft so gemacht, dass sie sich einfach anschauen, 01:16:35.470 --> 01:16:38.750 auf welcher Mac-Adresse laufe ich denn gerade oder irgendwas, was ist denn mein Server? 01:16:38.830 --> 01:16:42.750 Also du startest die Software und die Software schaut sich den eigenen Server an und denkt sich, 01:16:42.910 --> 01:16:47.790 ja, okay, das ist genau, das ist so, das ist meine Umgebung, in der ich gerade laufe. 01:16:47.870 --> 01:16:52.350 Bedeutet, ich baue mir so eine ID zusammen, die ID musst du dann halt entsprechend zufällig generieren, 01:16:52.430 --> 01:16:58.430 dass du dein System, ich sag mal, schön abdeckst, nicht, dass da irgendwie 90% von dem Ring irgendwie links 01:16:58.430 --> 01:17:04.190 unten sind quasi und einer alles andere haben muss, sondern die bauen sich da so eine ID, 01:17:04.430 --> 01:17:07.870 setzen sich irgendwo rein und sorgen dann auch tatsächlich selber dafür, 01:17:07.950 --> 01:17:10.190 dass sie die Daten kriegen, die zu ihnen sollten. 01:17:10.590 --> 01:17:15.630 Bedeutet, da kommt ein neuer Server rein, du sagst ihm, hey, du musst ihm echt nur einen anderen Server im 01:17:15.630 --> 01:17:18.270 System sagen und eventuell ein Passwort ist das System hat oder so. 01:17:18.350 --> 01:17:22.830 Und du sagst dann, das ist übrigens auch einer in deinem Ring und der fragt dann denen so, 01:17:22.910 --> 01:17:23.790 hey, wie ist denn dein Name? 01:17:23.870 --> 01:17:27.230 Und kannst du mir vielleicht mal ein paar andere sagen, so bildlich gesprochen jetzt mal. 01:17:27.310 --> 01:17:28.670 Und der sagt dann, ja klar, hier. 01:17:28.750 --> 01:17:32.910 Und dann weiß er, okay, dann bin ich jetzt, hallo, ich bin dein neuer Nachbar und dein neuer Nachbar. 01:17:33.150 --> 01:17:34.430 Gib mir mal Daten, gib mir mal so ein Daten. 01:17:34.510 --> 01:17:34.670 Richtig. 01:17:34.910 --> 01:17:38.590 Und die sagen dann, ach super, weil ich habe jetzt noch, wenn du zwischen mir und dem anderen willst, 01:17:38.670 --> 01:17:40.910 ich habe dann ein paar Daten, die jetzt nicht mehr so wirklich zu mir gehören, 01:17:41.070 --> 01:17:41.870 hier hast du, ne? 01:17:41.950 --> 01:17:42.030 Genau. 01:17:42.190 --> 01:17:45.070 Und du kannst auch so, du kannst das natürlich auch schon redundant machen, 01:17:45.150 --> 01:17:48.510 dass du sagst, du hast jetzt auch immer noch die Daten von deinen beiden Nachbarn, 01:17:48.670 --> 01:17:50.350 logisch gesehen, die neben dir sind. 01:17:50.510 --> 01:17:54.590 Bedeutet, wenn an einen Server Hops geht, dann kann das auch passieren, so, oh, mein Nachbar ist weg. 01:17:54.750 --> 01:17:58.510 Gut, ich habe jetzt noch seine Daten, aber das wäre jetzt ein bisschen viel, wenn ich das alles machen müsste. 01:17:58.670 --> 01:18:02.190 Bedeutet das, ja, das ist immer so ein bisschen, das blutet so aus. 01:18:02.350 --> 01:18:03.550 Ich weiß nicht, wie man es sagen kann. 01:18:03.950 --> 01:18:04.750 Aber es ist eine coole Lösung. 01:18:05.150 --> 01:18:05.950 Ist eine total coole Lösung. 01:18:06.030 --> 01:18:08.030 Ist wie wenn du mit Wasserfarben Punkte auf dem Blatt machst. 01:18:08.110 --> 01:18:12.830 Das irgendwie verteilt sich alles so um diesen Punkt und dann gibt es so, ja, die gehen alle so einander über. 01:18:12.990 --> 01:18:15.710 Und das ist was, was Amazon Dynamo automatisch macht. 01:18:15.870 --> 01:18:19.470 Bedeutet, wenn du einen neuen Server reinmachst, dann tust du nur die Pizza-Box rein, 01:18:19.550 --> 01:18:22.430 startest deinen Prozess, ein Kommando und alles andere ist völlig automatisch, 01:18:22.510 --> 01:18:23.550 Loadbalancing, alles. 01:18:23.950 --> 01:18:26.430 Wenn wir hier von Pizza-Box reden, wir meinen so einen Server. 01:18:27.390 --> 01:18:29.230 Nur mal öfter ins Rack cheating. 01:18:29.630 --> 01:18:30.830 Server im Rack, genau. 01:18:30.990 --> 01:18:33.150 Ich wollte das nur nochmal gesagt haben. 01:18:33.470 --> 01:18:38.110 Die sind 19 Zoll breit, das sind rund 50 Zentimeter und ungefähr zweieinhalb Zentimeter. 01:18:38.430 --> 01:18:38.510 Richtig. 01:18:39.310 --> 01:18:40.190 Deswegen heißen die Pizza-Box. 01:18:40.430 --> 01:18:42.190 Was eine anständige Pizza-Box auch haben sollte. 01:18:42.430 --> 01:18:42.510 Genau. 01:18:42.670 --> 01:18:43.150 Auf jeden Fall. 01:18:43.390 --> 01:18:43.710 Richtig. 01:18:44.190 --> 01:18:44.590 Genau. 01:18:44.750 --> 01:18:46.590 Und das ist Amazon Dynamo. 01:18:46.750 --> 01:18:49.390 Ist so, haben die gemacht, ist eine super Sache. 01:18:49.550 --> 01:18:51.390 Gibt es viele Open Source-Produkte, die da drauf aufbauen? 01:18:51.550 --> 01:18:51.950 Kommen wir gleich zu? 01:18:52.110 --> 01:18:52.590 Kommen wir gleich dazu. 01:18:52.830 --> 01:18:55.630 Genau, dann den zweiten großen, der da in der Sache viel macht. 01:18:55.950 --> 01:18:57.310 Da gibt es noch Google. 01:18:57.630 --> 01:19:00.270 Die haben irgendwie auch mal gedacht, hey, wir haben Daten. 01:19:01.150 --> 01:19:01.790 Wir haben viele Server. 01:19:02.030 --> 01:19:04.510 Wir haben viele Server und benutzt uns alle Daten. 01:19:04.830 --> 01:19:10.590 Das ist auch vor allem ein Produkt, was das tatsächlich gebraucht hat, und zwar Google Earth bzw. 01:19:10.910 --> 01:19:11.790 Google Maps. 01:19:12.270 --> 01:19:19.150 Da haben die extrem viele Geodaten, also Kartendaten und Satellitenbilder in unterschiedlichen Auflösungen und 01:19:19.150 --> 01:19:24.670 die müssen die jetzt irgendwie weltweit verfügbar machen und zwar schnell und effizient und so verteilt, 01:19:24.830 --> 01:19:27.790 dass es halt auch im Endeffekt ausfallssicher ist. 01:19:28.030 --> 01:19:34.270 Und die haben da im Endeffekt dann halt auch überlegt, was haben wir denn schon so an Infrastruktur und huch, 01:19:34.510 --> 01:19:37.630 die haben schon ein verteiltes Dateisystem, das Google FS. 01:19:38.670 --> 01:19:44.350 Die haben schon einen Dienst, mit dem er so Locking und so weiter, unsere Metadatenverwaltung betreiben kann, 01:19:44.430 --> 01:19:45.070 das ist Chubby. 01:19:45.310 --> 01:19:49.870 Und haben sie gedacht, hey, wir bauen doch auf Basis dieser Dienste, 01:19:49.950 --> 01:19:52.590 die eh schon implementiert sind, jetzt ein Datenbanksystem. 01:19:52.750 --> 01:19:54.830 Und das war dann im Endeffekt Google Big Table. 01:19:55.310 --> 01:19:57.390 Das benutzt das, wie vorhin schon angesprochene, 01:19:58.230 --> 01:19:59.750 Column Store-Datenmodell. 01:19:59.830 --> 01:20:05.510 Das heißt, ich habe da ja also verschachtelte Key-Value-Pare, 01:20:05.830 --> 01:20:07.030 die man anlegen kann. 01:20:07.510 --> 01:20:13.990 Und die haben das halt im Endeffekt so implementiert, dass die so viel wie möglich an die bereits bestehende 01:20:13.990 --> 01:20:15.030 Infrastruktur anlegen. 01:20:15.110 --> 01:20:21.670 Also das heißt, die kümmern sich nicht um die Redundanz der Daten oder um die globale oder netzwerkmäßige 01:20:21.670 --> 01:20:25.190 Verteilung der Daten, sondern das übernimmt das Daten das File-System, 01:20:25.270 --> 01:20:26.870 auf dem sie das Speichern für die. 01:20:28.310 --> 01:20:33.350 Und genauso Geschichten wie Logging und so weiter übernimmt halt auch nicht selbst, 01:20:33.430 --> 01:20:40.150 sondern das übernimmt dann im Endeffekt dieser Chubby-Service, den die da halt auch schon intern hatten, 01:20:40.550 --> 01:20:41.750 übernimmt das für die. 01:20:42.150 --> 01:20:42.630 Was ist denn? 01:20:43.990 --> 01:20:44.790 Locking. 01:20:46.790 --> 01:20:52.070 Das ist im Endeffekt die Geschichte mit, ich möchte jetzt eine gewisse Art von 01:20:52.950 --> 01:20:58.230 Datensicherheit gewährleisten, dass da nicht irgendwie auf eine Datei zwei Leute gleichzeitig zuschreiben, 01:20:58.390 --> 01:21:00.230 zugreifen, lesen können sie ja. 01:21:01.270 --> 01:21:06.070 Und da wird im Endeffekt, wenn einer anfängt zu schreiben, wird dann jetzt im Endeffekt eine, 01:21:06.310 --> 01:21:12.230 wenn man jetzt von relational Datenbank ausgeht, entweder eine Datenbank oder eine Tabelle oder irgendwie nur 01:21:12.230 --> 01:21:16.150 die Zeile in der Tabelle, die wird dann im Endeffekt gesperrt für andere Schreibzugriffe, 01:21:16.470 --> 01:21:19.430 bis der eine jetzt mit dem Schreiben fertig ist und die wird dann wieder freigegeben. 01:21:19.670 --> 01:21:24.230 Und dieses übers Netzwerk zu verteilen, haben die dann halt im Endeffekt diesen Chubby-Service, 01:21:24.470 --> 01:21:25.590 der denen das abnimmt. 01:21:26.230 --> 01:21:27.270 War natürlich eine blöde Frage. 01:21:28.390 --> 01:21:29.350 Normale Datenbanken auch. 01:21:29.590 --> 01:21:29.830 Richtig. 01:21:30.150 --> 01:21:36.470 Und MySQL mit Esam sperrt auf Tabellenebene und Esam sperrt auf Datensatzebene. 01:21:36.710 --> 01:21:39.910 Genau, ist auch, wenn man in der Discom-Frankto vorbeiläuft, die haben auch ein wunderschönes Locking. 01:21:40.230 --> 01:21:41.910 Stehen da alle an und warten, bis sie mal ran dürfen. 01:21:41.990 --> 01:21:42.150 Genau. 01:21:42.390 --> 01:21:44.070 Das ist Locking, meine Herren, ne? 01:21:44.150 --> 01:21:47.510 Weil wenn alle auf einmal gehen, versaut deine Daten nur. 01:21:47.990 --> 01:21:48.310 Genau. 01:21:49.030 --> 01:21:50.470 Um als Niveau zu senken. 01:21:51.030 --> 01:21:52.230 Soviel zum Thema. 01:21:52.470 --> 01:21:55.990 Genau, und vorher, also Google Big Table, wie du gerade gesagt hast, 01:21:56.150 --> 01:21:59.190 Column Store, Amazon Dynamo, hast du ja gesagt, du bist ein Key-Value-Store. 01:21:59.270 --> 01:22:05.510 Also da hast du halt einen Key, den du da irgendwie hast und du kannst natürlich durch den Key auch wieder 01:22:05.510 --> 01:22:11.430 irgendwie ein Datenschema quasi in den Key bauen, dass du dann irgendwie den Key speziell nennst, 01:22:11.510 --> 01:22:17.350 irgendwie, keine Ahnung, Picture-Doppelpunkt, Food-Doppelpunkt und dann irgendwas. 01:22:17.670 --> 01:22:20.150 Gut, das ist dann halt alles relativ viel Anwendungslogik. 01:22:20.470 --> 01:22:21.670 Richtig, genau, das wäre ein Anwendungslogisch. 01:22:21.830 --> 01:22:24.070 Big Table hat halt noch ein bisschen mehr im Datenschema drin. 01:22:24.230 --> 01:22:24.630 Genau. 01:22:24.870 --> 01:22:29.910 Dann noch was anderes, was wir sicher gleich brauchen werden und was auch von Google, 01:22:29.990 --> 01:22:31.510 glaube ich, ist, MapReduce. 01:22:31.830 --> 01:22:33.110 Da haben sie sogar ein Patent drauf. 01:22:33.270 --> 01:22:33.910 Da haben die ein Patent. 01:22:33.990 --> 01:22:34.070 Echt? 01:22:35.590 --> 01:22:36.550 Die sind da nicht so, die sagen dann. 01:22:36.710 --> 01:22:37.350 Macht mal Leute. 01:22:37.670 --> 01:22:38.230 Die sind da nicht so. 01:22:38.390 --> 01:22:41.270 Ja, also wird gerade ganz oft benutzt und hört man auch ständig irgendwie, 01:22:41.350 --> 01:22:46.710 wenn man solche, immer wenn es um Datenbanken oder um effizient irgendwas suchen oder sonst wie geht, 01:22:47.110 --> 01:22:49.990 dann MapReduce, was ist denn MapReduce? 01:22:50.230 --> 01:22:51.430 Genau, da gab es, ähm. 01:22:52.870 --> 01:22:53.590 Ja, egal. 01:22:54.710 --> 01:23:00.870 Da gab es, also das MapReduce-Paper, das kam glaube ich 2006 raus. 01:23:01.350 --> 01:23:08.070 Da geht es weniger konkret um Datenbanksysteme, sondern mehr um verteiltes Berechnen und 01:23:08.070 --> 01:23:10.070 verteiltes Verarbeiten von Daten. 01:23:10.470 --> 01:23:17.350 Und ja, im Endeffekt greift es Konzepte der funktionalen Programmierung auf und da gibt es zwar 01:23:17.510 --> 01:23:23.830 oft so Map- und Reduce-Funktionen, mit denen man Daten weiterverarbeiten kann. 01:23:23.910 --> 01:23:30.790 Also einmal hat man Map, man hat jetzt zum Beispiel eine Liste von Daten und da wendet man auf jedes einzelne 01:23:30.790 --> 01:23:36.790 Element dieser Daten wendet man jetzt einen Algorithmus an, der jedes Mal genau gleich läuft und deshalb auch 01:23:36.790 --> 01:23:38.230 in parallel ablaufen kann. 01:23:38.310 --> 01:23:42.310 Und das war dann die Map-Funktion und mit der Reduce-Funktion zieht man sich im Endeffekt die Daten raus, 01:23:42.390 --> 01:23:43.830 die einem wirklich interessieren. 01:23:43.990 --> 01:23:50.790 Und die kann man dann zum Schluss im Endeffekt wieder zusammenziehen und hat dann dadurch einen 01:23:51.750 --> 01:23:56.710 Baukasten, mit dem man sich Algorithmen schreiben kann, 01:23:56.950 --> 01:24:01.190 die auf extrem große Datenmengen extrem verteilt angewendet werden können. 01:24:01.270 --> 01:24:07.670 Das heißt, dieser Map-Schritt und dieser Reduce-Schritt, die können beide problemlos auf irgendwie 01:24:07.670 --> 01:24:12.710 100.000 Servern gleichzeitig ausgeführt werden, ohne dass die sich jetzt in die Quere kommen, 01:24:12.870 --> 01:24:17.910 weil die Datensätze an sich pro Datensatz immer nur von einer Maschine bearbeitet werden. 01:24:18.230 --> 01:24:23.910 Und so können die halt im Endeffekt ihren Suchindex aufbauen, irgendwie Volltextsuche über diverse Webseiten 01:24:23.910 --> 01:24:28.310 und so weiter machen, ohne dass die jetzt Probleme haben, 01:24:28.630 --> 01:24:33.030 das irgendwie nett in den Griff zu kriegen von der Komplexität her. 01:24:33.270 --> 01:24:38.470 Ist ja auch, was oft bei Linux oder Unix gemacht wird, so ein Cut-Grap-Set. 01:24:38.630 --> 01:24:43.510 Das sind alles auch so funktionale Bestandteile und mit Cut, das ist halt vergleichbar mit Map, 01:24:43.670 --> 01:24:48.230 sag ich mal, du sagst dann im Cut-Stern.txt, bedeutet, ich nehme alle TXT-Dateien. 01:24:48.390 --> 01:24:51.350 Was aus dem Cut rauskommen wird, sind alle TXT-Dateien. 01:24:51.430 --> 01:24:53.510 So P mal Daumen oder Find von mir aus. 01:24:53.590 --> 01:24:55.350 Dann kommt wirklich nur Dateiname raus. 01:24:55.510 --> 01:24:57.430 Und dann kannst du von mir aus noch ein Grab machen. 01:24:57.590 --> 01:24:59.990 Dann kannst du sagen, das ist dann quasi die Reduce-Phase. 01:25:00.150 --> 01:25:03.830 Jetzt, wo ich alles habe in der Liste, was ich mir eigentlich anschauen will, 01:25:03.990 --> 01:25:05.750 was will ich denn genau anschauen? 01:25:06.150 --> 01:25:09.270 Da kommt halt das Rede, äh, das Reduce drüber oder das Scrap oder so. 01:25:09.350 --> 01:25:11.750 Und dann fliegt am Ende die Daten raus, die du haben willst. 01:25:12.310 --> 01:25:16.070 Dann kann ich es in der Map-Phase, meistens wird ja irgendwas zusammengezählt zum Beispiel. 01:25:16.310 --> 01:25:17.110 Ja, kannst du auch. 01:25:17.750 --> 01:25:22.790 Gib mir mal alle Worte von allen Datenbanken, was weiß ich, oder die Zahl, 01:25:22.870 --> 01:25:25.750 die da drin steht in dem und dem Fall. 01:25:26.630 --> 01:25:29.750 Und dann die Reduce-Funktion ist, zähle jetzt alles zusammen, was du daraus gezahlt hast. 01:25:30.070 --> 01:25:34.470 Oder lass es jetzt mal konkret sein, wenn Google für Webseiten ihren Score berechnen will, 01:25:34.550 --> 01:25:38.710 dann interessiert die halt vor allem auch ausgehende Links von Webseiten, 01:25:38.790 --> 01:25:40.390 die jetzt auf andere Webseiten zeigen. 01:25:40.470 --> 01:25:43.910 Und gerade sowas lässt sich mit Map-Reduce halt extrem elegant abbilden. 01:25:44.070 --> 01:25:47.350 Und das Schöne an der Geschichte ist, die haben ein Framework dafür, 01:25:47.430 --> 01:25:50.550 was diese ganze Verteilung und dieses ganze Management übernimmt. 01:25:50.710 --> 01:25:57.510 Und die Entwickler müssen sich dann im Endeffekt gar nicht um so Dinge wie Threads und Netzwerkverteilung und 01:25:57.510 --> 01:26:02.710 diese ganzen Geschichten kümmern, weil die im Endeffekt nur diese Map-Funktion und diese Reduce-Funktion 01:26:02.710 --> 01:26:06.870 implementieren müssen und der Rest wird dann von dem Framework außenrum erledigt. 01:26:07.030 --> 01:26:09.590 Genau, so ein beliebtes Open Source Framework ist von Yahoo! 01:26:09.750 --> 01:26:13.110 Ursprünglich ist das Hadoop, das jetzt auch unter Apache-Lizenz steht. 01:26:13.350 --> 01:26:17.510 Ist nicht nett zum Einrichten, aber okay zum Arbeiten. 01:26:17.590 --> 01:26:22.630 Also du musst dann halt irgendwie, keine Ahnung, HDFS, das verteilte Dateisystem, 01:26:22.710 --> 01:26:26.150 dann packst du da irgendwie HBase drüber und über HBase packst du noch einen Locking-Service und einen 01:26:26.150 --> 01:26:28.870 Jobtrecker und einen Do-Tracker und dann kannst du MapReduce machen. 01:26:29.190 --> 01:26:36.150 Also wie vorhin schon beschrieben, bei Big Table ist das halt im Endeffekt bei MapReduce 01:26:36.150 --> 01:26:39.990 genauso, dass die halt schon viel Infrastruktur benutzt haben, die die intern haben. 01:26:40.150 --> 01:26:44.630 Und Hadoop hat halt jetzt versucht, diese Infrastruktur gleich noch mit zu implementieren. 01:26:44.790 --> 01:26:49.830 Das heißt, die haben auch noch gleich ein verteiltes Dateisystem, eine verteilte Datenbank darüber, 01:26:49.910 --> 01:26:54.310 einen Locking-Demon und so weiter, haben die halt alles mit implementiert und das muss man halt im Endeffekt 01:26:54.310 --> 01:26:57.350 dann auch noch alles einrichten, wenn man dann so ein Hadoop-Cluster aufsetzen kann. 01:26:57.430 --> 01:26:57.510 Genau. 01:26:57.670 --> 01:27:01.430 Dafür ist nachher zum Skalieren und Jobs schreiben eigentlich eine recht angenehme Sache. 01:27:01.670 --> 01:27:05.350 Ist halt schon ein bisschen, ja, muss man seine Trade-offs machen. 01:27:05.430 --> 01:27:11.990 Also ich würde niemanden raten, Hadoop einzurichten, der irgendwie nur irgendwie 25 Datensätze hat und das 01:27:11.990 --> 01:27:14.710 gerne parallel bearbeiten will, weil da brauchst du mehr Zeit zum Einrichten, 01:27:14.790 --> 01:27:17.110 als das dann irgendwie von Hand selber zu frickeln. 01:27:17.430 --> 01:27:19.750 Das Ganze macht ja generell nur bei Riesendatenbeständen Sinn. 01:27:19.990 --> 01:27:20.630 Genau, richtig. 01:27:21.270 --> 01:27:24.390 Ich meine auch Cassandra, diese ganze Management- äh, nicht bei Cassandra, 01:27:24.470 --> 01:27:28.950 äh, bei Dynamo, diese ganze Management-Ebene mit dem Hashing und den ganzen Sachen, 01:27:29.030 --> 01:27:33.910 das macht auch nur Sinn, wenn man wirklich tatsächlich extrem viele Server hat und dann auch so Dinge wie 01:27:33.910 --> 01:27:37.670 Redundanz einfach braucht, weil irgendwie bei 10.000 Servern ist die Wahrscheinlichkeit, 01:27:37.830 --> 01:27:40.470 dass da mal eine Maschine ausfallen wird, relativ hoch. 01:27:40.710 --> 01:27:46.150 Genau, das ist eben so ein Beispiel von einem NoSQL-System, das explizit auf große Datenmengen und einfache 01:27:46.150 --> 01:27:47.510 Skalierbarkeit ausgelegt ist. 01:27:47.670 --> 01:27:51.030 Nicht so einfach für den einzelnen Programmierer, wenn das nur für seinen eigenen Server will. 01:27:51.190 --> 01:27:51.430 Richtig. 01:27:51.590 --> 01:27:53.350 Da muss man dann halt was anderes nehmen. 01:27:54.070 --> 01:27:59.590 Als nächstes, da gibt es noch was, was ganz interessant ist, weil wir gehen gerade auch wieder ein bisschen 01:27:59.590 --> 01:28:02.390 weg erstaunlicherweise von dem, was Hadoop macht. 01:28:02.470 --> 01:28:09.110 Hadoop geht ja quasi durch all meine Daten durch, von oben nach unten und 01:28:09.990 --> 01:28:11.190 das schön parallel. 01:28:11.270 --> 01:28:13.510 Bedeutet, ich bekomme das schon recht schnell parallel hin. 01:28:13.750 --> 01:28:18.390 Das Problem ist, wenn jetzt jemand eine Suchanfrage stellt, zum Beispiel in Google, 01:28:18.790 --> 01:28:22.470 dann wird diese Suchanfrage nicht unbedingt durch MapReduce gemacht, 01:28:22.550 --> 01:28:27.350 weil das ist zwar schön, dass die 100.000 Server haben, aber die müssen alle immer noch durch ein bisschen 01:28:27.350 --> 01:28:30.470 Daten durchgehen und es dauert einfach zu lange für Real-Time-Systeme. 01:28:30.630 --> 01:28:35.910 Gerade der Begriff Real-Time, der Pleity hier, das Sven, schreibt ja auch gerade eine Thesis zu dem Thema, 01:28:36.230 --> 01:28:39.030 den wird es wahrscheinlich freuen, dass es da so viel Neues gibt. 01:28:39.670 --> 01:28:44.230 Gerade im Real-Time-Bereich gibt es auch viele Sachen, die jetzt ein bisschen mehr Richtung Streaming gehen. 01:28:44.870 --> 01:28:51.190 Und Dremel ist von Google ein Framework oder ein 01:28:51.990 --> 01:28:57.270 System, das ermöglicht, diese, ich nenne es mal schon, 01:28:57.670 --> 01:28:59.990 WebScale-Datasets interaktiv zu analysieren. 01:29:00.710 --> 01:29:03.830 Das, was wir bisher, die Stärke von bisher den relationalen Systemen, 01:29:03.910 --> 01:29:09.670 dass wir da mit Indexen arbeiten und dass wir da quasi beliebige Anfragen stellen müssen, 01:29:09.750 --> 01:29:11.990 die wir nicht vorher irgendwie vorformuliert haben. 01:29:12.710 --> 01:29:19.670 Das versucht Dremel auf eine Large-Scale-Umgebung zu bringen, über tausende CPUs und Petabytes an Daten 01:29:19.990 --> 01:29:26.710 und ist so ein bisschen quasi ein Add-on zu MapReduce, das so eine Art verteilten 01:29:26.710 --> 01:29:29.110 Index irgendwie implementiert. 01:29:29.510 --> 01:29:34.870 Das ist, diese B Plus-Bäume zu verteilen, ist ja eine machbare Sache, 01:29:35.030 --> 01:29:40.630 aber gerade das Problem ist eben, du kannst den, der Baum hat eine gewisse Struktur, 01:29:40.710 --> 01:29:44.070 aber du hast jetzt auch eine gewisse Struktur in deinen Daten, wo die liegen und die passt eventuell nicht 01:29:44.070 --> 01:29:44.870 richtig überein. 01:29:45.350 --> 01:29:51.430 Und die benutzen sogenannte Multile-Level-Execution Trees und auch so ein Column-Layout, 01:29:52.070 --> 01:29:53.350 wie sie es halt benutzen. 01:29:54.390 --> 01:29:58.390 Und das ist vielleicht, jemand, den es interessiert, der kann sich da mal das Paper durchlesen. 01:29:58.550 --> 01:30:00.870 Dremel ist so ein System, das das auch ermöglicht. 01:30:01.030 --> 01:30:05.110 Genau, wenn wir dann schon gleich bei Dremel sind, dann kannst du auch gleich noch Percolator, 01:30:05.270 --> 01:30:06.630 kann man sich dann auch gleich noch durchlesen. 01:30:06.710 --> 01:30:12.710 Auch irgendwas von Google, was in diese Richtung geht, irgendwas auf Basis von Big Table und Suche und sowas. 01:30:12.790 --> 01:30:17.190 Also die sind so in einem Atemzug irgendwie veröffentlicht worden, sollte man sich beide mal angucken. 01:30:17.350 --> 01:30:19.190 Ist übrigens auch eine Kaffeemaschine, der Perculator. 01:30:19.910 --> 01:30:20.870 Oder Dremel ein Werkzeug. 01:30:22.310 --> 01:30:23.190 Eine Kaffeemaschine, ne? 01:30:23.990 --> 01:30:25.110 Der Big Table ist ein großer Tisch. 01:30:25.350 --> 01:30:28.870 Aber wo wir jetzt gerade bei Live waren, also nochmal zurück zu MapReduce, 01:30:29.350 --> 01:30:33.910 da wollte ich noch anbringen, also diese Daten werden im Normalfall vorberechnet und über einen gewissen 01:30:33.910 --> 01:30:37.990 Zeitraum einfach generiert, irgendwie jede Nacht oder einmal in der Woche oder sonst irgendwas. 01:30:38.150 --> 01:30:39.270 Aber das wird nicht live gemacht. 01:30:39.350 --> 01:30:41.750 Das heißt, wenn man jetzt irgendwie eine Google eine Suche eingibt, 01:30:41.910 --> 01:30:46.390 dann läuft da kein MapReduce-Cluster los und fangt an, Daten zu durchsuchen, 01:30:46.470 --> 01:30:51.750 sondern das wird schon vorberechnet und die Daten werden dann, also die berechneten Daten werden dann wiederum 01:30:51.750 --> 01:30:53.990 auch vorgehalten als Cache. 01:30:54.310 --> 01:31:00.310 Genau, so wie ich es verstanden habe, dieses Dremel ist dann quasi so eine Art Map-Reduce immer laufen lassen 01:31:00.550 --> 01:31:04.390 und jedes Mal, wenn der was Neues, quasi einen MapReduce-Durchgang fertig hat, 01:31:04.470 --> 01:31:06.630 kann der diesen Dremel aktualisieren, so eine Art Streaming. 01:31:06.950 --> 01:31:09.510 Gibt es ja auch, Yahoo hat jetzt dieses S4, heißt es glaub. 01:31:09.750 --> 01:31:13.750 Also jetzt kommen auch immer mehr in diesem Real-Time-Web-Zeug kommen auch immer mehr Streaming-Dienste, 01:31:13.910 --> 01:31:14.470 die Daten einfach noch. 01:31:15.190 --> 01:31:16.230 Vorsichtig bitte mit Real-Time. 01:31:16.310 --> 01:31:19.990 Ihr meint tatsächlich mit Echtzeit-Anfragen, du stellst eine Anfrage und kriegst sofort das Ergebnis. 01:31:20.150 --> 01:31:24.230 Und Real-Time normalerweise heißt, dass du eine definierte Antwortzeit hast und dass die unter allen Umständen 01:31:24.310 --> 01:31:24.870 mal eingehalten kannst. 01:31:25.030 --> 01:31:25.510 Genau, nee, nee. 01:31:25.590 --> 01:31:28.950 Also das ist das andere Real-Time, nicht das alte und embedded Real-Time, 01:31:29.030 --> 01:31:30.310 sondern dieses neue Hippe-Ral-Time-War. 01:31:30.470 --> 01:31:35.270 Also wenn man Real-Time-Kurner einsetzen, dass der eine definierte Antwortzeit hat und die unter allen 01:31:35.270 --> 01:31:36.950 Systembedingungen immer einhalten kann. 01:31:37.110 --> 01:31:38.470 Ja, und die versuchen halt. 01:31:38.790 --> 01:31:42.150 Ganz wichtig für medizinische Werkzeuge, dass das Ding auch wirklich an der Stelle schneidet, 01:31:42.230 --> 01:31:43.110 wo es schneiden soll. 01:31:43.830 --> 01:31:45.190 Gar keine so schlechte Idee. 01:31:45.670 --> 01:31:49.590 Weil wenn das erst fünf Sekunden später irgendwo schneidet, ist man halt vielleicht. 01:31:49.990 --> 01:31:51.270 Ist der Patient vielleicht tot oder so? 01:31:52.070 --> 01:31:56.550 Bei Netzwerken macht das Token Ring zum Beispiel, aber da hat das nämlich tatsächlich noch seine Bewandnis, 01:31:56.630 --> 01:31:57.830 aber das ist wieder was anderes richtig. 01:31:57.910 --> 01:32:02.070 Ich wollte eine Partition gerade noch sagen, dass Partitionen natürlich auch von kommerziellen oder 01:32:03.990 --> 01:32:05.910 konventionellen Datenbanksystemen verstanden werden. 01:32:06.070 --> 01:32:08.710 Auch partitionierte Indexe. 01:32:08.790 --> 01:32:11.670 Und da merkt man, dass sich die Scheibe auch wieder zurückdreht, weil man sieht, 01:32:11.750 --> 01:32:14.630 dass man so ganz ohne die alten Funktionen nicht mehr loskommen muss. 01:32:15.110 --> 01:32:17.350 Es gibt auch nicht so viel Neues, das gab es sich ja alles schon mal, 01:32:17.430 --> 01:32:20.310 aber jetzt setzt man es halt, merkt man halt, dass man gewisse Algorithmen, 01:32:20.390 --> 01:32:23.750 die es schon gab, für was einsetzen kann, was jetzt auch Sinn macht. 01:32:23.990 --> 01:32:27.270 Man muss ja auch sagen, dass es früher die Aufgabe war, einen großen Trümmer zu haben, 01:32:27.590 --> 01:32:30.550 der irgendwie eine Riesendatenbank verwaltet und jetzt ist halt die Aufgabe, 01:32:30.790 --> 01:32:33.510 hey, so viele Pizzaboxen sind viel, viel billiger als ein großer Trümmer, 01:32:33.590 --> 01:32:34.150 also mach mal die Tür. 01:32:34.470 --> 01:32:37.030 Es geht auch teilweise auch fast nicht mehr anders, weil du halt echt, 01:32:37.110 --> 01:32:40.310 du kannst nicht so viele Prozessoren in eine Maschine reinstecken. 01:32:40.550 --> 01:32:44.390 Also wenn Google irgendwie, keine Ahnung, 10.000 Server hat, es ist schwer, 01:32:44.470 --> 01:32:47.590 10.000 Prozessoren irgendwo reinzustecken in den großen, oder? 01:32:48.310 --> 01:32:53.670 So ein Mainframe, ich glaube, auf einer so einer kleinen sind da irgendwie schon mal 16 oder 64 oder so. 01:32:53.910 --> 01:32:56.630 Ja, aber 10.000 bezahlt das rein. 01:32:58.070 --> 01:32:58.950 Das ist eine andere Frage. 01:32:59.270 --> 01:33:03.510 Du kriegst aber auch mit der Kühlung irgendwann nicht mehr hin, 10.000 Rechendinger auf einem Klotz zu 01:33:03.510 --> 01:33:04.550 behalten, der so groß ist. 01:33:05.030 --> 01:33:07.830 Naja, um der Wahrheit die Ehre zu geben, wenn ich 10.000 Rechner habe, 01:33:07.910 --> 01:33:09.350 dann benutze ich auch ein bisschen Platz. 01:33:10.790 --> 01:33:13.190 Ja, Platz, klar, aber es ist halt das in einzustecken, wird dann halt. 01:33:13.510 --> 01:33:14.710 Benutze ich auch ein bisschen Kühlung. 01:33:15.350 --> 01:33:15.750 Natürlich. 01:33:16.870 --> 01:33:17.990 Aber es geht halt noch verteilt. 01:33:18.390 --> 01:33:20.550 Besser verteilen als jetzt so eine Riesenmaschine. 01:33:20.710 --> 01:33:25.270 Also ein großer Rechner, der unendlich viele Prozessoren hat, da glühen die Kommunikationsleitungen zwischen 01:33:25.270 --> 01:33:26.870 den Prozessoren, dass es physikalisch gar nicht macht. 01:33:27.190 --> 01:33:29.110 Ja, deswegen, die müssen das jetzt halt so machen. 01:33:29.190 --> 01:33:32.310 Also ich denke, keine Ahnung, was ist denn so eine große, ich weiß gar nicht, 01:33:32.470 --> 01:33:34.470 wie groß wäre denn so Oracle oder DB2-Installationen? 01:33:35.110 --> 01:33:39.910 Der größte Trümmer, mit dem ich zu tun habe, habe 128 Cores und irgendwie 512 GB RAMO. 01:33:40.070 --> 01:33:43.830 Ja, richtig, da fängt halt Google an zu gähnen, weil irgendwie die haben dann halt mal irgendwie 10.000 01:33:43.830 --> 01:33:47.190 Rechner mit jeweils vier Cores oder zwei Cores oder das nur ein sein. 01:33:47.430 --> 01:33:51.030 Aber die müssen halt Systeme bauen, die auch über 10.000 gut kommunizieren. 01:33:51.110 --> 01:33:51.670 Ja, definitiv. 01:33:51.910 --> 01:33:55.270 Das ist halt irgendwo, wenn du da irgendwann hinkommst, da lohnt sich dann gar nicht mehr nachzufragen, 01:33:55.350 --> 01:33:56.550 ob es das schon jemand gemacht hat. 01:33:57.350 --> 01:34:00.870 Ist euch eigentlich mal aufgefallen, dass die Webseiten von Datenbankherstellern die langsamsten sind, 01:34:01.030 --> 01:34:01.830 die es so was gibt. 01:34:03.510 --> 01:34:06.070 Ja, da sollten wir mal drüber nachdenken. 01:34:06.470 --> 01:34:06.710 Genau. 01:34:07.030 --> 01:34:10.310 Sie sollten da vielleicht mal ein bisschen gucken, was du da optimieren können. 01:34:10.710 --> 01:34:11.590 Caching einschalten. 01:34:12.950 --> 01:34:14.630 Oder eine schnelle Datenbank drunter legen. 01:34:15.590 --> 01:34:16.790 Das ist enorm schlechte Werbung. 01:34:16.870 --> 01:34:17.270 Entschuldigung. 01:34:17.430 --> 01:34:20.550 Ja, komm, bei Paper 1 gibt es vielleicht noch, weil Cup hat man ja schon. 01:34:20.710 --> 01:34:23.350 Ja, also zu Cup gibt es auch in Paper, das kann man sich auch mal durchlesen. 01:34:23.510 --> 01:34:25.430 Richtig, und dann gibt es noch Cassandra. 01:34:25.590 --> 01:34:26.070 Cassandra. 01:34:26.390 --> 01:34:28.550 Aber das ist ein Cassandra ist so. 01:34:28.710 --> 01:34:33.590 Cassandra ist so mehr oder weniger ein Hybrid aus Amazon Dynamo und Google Big Table. 01:34:33.910 --> 01:34:37.110 Und gibt es dazu sonst noch was zu sagen? 01:34:37.750 --> 01:34:40.470 Es ist auch ein Column Store, wo benutzt halt intern, ja. 01:34:40.870 --> 01:34:41.270 Es ist ein. 01:34:41.430 --> 01:34:43.350 Cassandra ist was, was ihr auch runterladen könnt. 01:34:43.670 --> 01:34:45.350 Dynamo und Big Table könnt ihr nicht runterladen. 01:34:45.430 --> 01:34:49.270 Genau, ich wollte gerade sagen, jetzt kommen wir eigentlich zum eigentlichen Thema dieser Sendung, 01:34:49.350 --> 01:34:51.750 nämlich OSQL-Datenbanken. 01:34:51.990 --> 01:34:53.510 Und eine davon war Cassandra. 01:34:53.750 --> 01:34:57.910 Genau, also Cassandra ist tatsächlich eine Open Source Implementierung von Facebook, 01:34:57.990 --> 01:34:58.790 wurde die mal geschrieben. 01:34:58.950 --> 01:35:01.190 Steht mittlerweile, glaube ich, unter Apache-Lizenz, richtig? 01:35:01.750 --> 01:35:02.310 Ja, genau. 01:35:02.950 --> 01:35:09.190 Und das ist tatsächlich eins der Papers, wo es auch eine Open Source Implementierung dazu gibt. 01:35:10.390 --> 01:35:11.350 Facebook ist lieb! 01:35:11.590 --> 01:35:16.310 Die kann man sich angucken und kann die benutzen und kann damit glücklich sein. 01:35:16.390 --> 01:35:18.790 Also engineeringtechnisch, Facebook gibt da echt viel raus, was wir machen. 01:35:18.870 --> 01:35:19.750 Das ist ganz nett von denen. 01:35:19.830 --> 01:35:21.030 Haben auch einen super Engineering-Blog. 01:35:21.670 --> 01:35:22.150 Java, ne? 01:35:24.390 --> 01:35:26.070 Du bezahlst es nur mit deinen Daten, aber gut. 01:35:26.230 --> 01:35:26.790 Ja, ja, genau. 01:35:27.990 --> 01:35:30.710 Nur weil du diese Datenbank einsetzt, heißt es ja nicht, dass du richtig. 01:35:30.790 --> 01:35:32.470 Ja, die Technik sein machst. 01:35:33.430 --> 01:35:33.830 Genau. 01:35:34.310 --> 01:35:38.230 Was man da sagen muss, Cassandra ist so ein bisschen die nette, ich habe ja erzählt, 01:35:38.470 --> 01:35:43.910 wie komisch es ist, Hadoop einzurichten, weil du da für HFS-Dingens da, 01:35:44.070 --> 01:35:47.990 also dieses verteilt Dateisystem einrichten muss, darauf Age-Base einsetzen. 01:35:48.070 --> 01:35:51.590 Und Cassandra ist so ein bisschen die, weil sie auch rausgewunden haben, 01:35:51.670 --> 01:35:56.790 dass keiner Bock hat, ein verteiltes Dateisystem aufzusetzen, nur weil er eine verteilte Datenbank machen 01:35:56.790 --> 01:36:00.390 will, weil das halt eine echt unangenehme Angelegenheit ist und viel zu warten. 01:36:00.710 --> 01:36:04.310 Ich versuche das auch gerade, ein verteiltes Dateisystem durchzusetzen. 01:36:04.550 --> 01:36:07.590 Und dann weißt du ja, warum das vielleicht so sich Leute denken, ja, 01:36:07.670 --> 01:36:09.510 ich würde es kein Einsetzen, aber wir haben gar nicht so viele Leute, 01:36:09.590 --> 01:36:10.950 die sich nachher warten können. 01:36:11.030 --> 01:36:13.910 Und Cassandra ist so ein bisschen auch der versucht, das einfach zu halten. 01:36:14.070 --> 01:36:20.470 Bedeutet, Cassandra ist im Grunde der Locking-Server, der die Datenbank und das verteilte 01:36:20.470 --> 01:36:24.950 Dateisystem in einem ist ganz nett, 01:36:25.110 --> 01:36:29.910 was das angeht, performance-technisch recht gut, wird eingesetzt von, 01:36:30.150 --> 01:36:31.110 was war es denn alles? 01:36:31.190 --> 01:36:34.630 Ich glaube von Reddit und Dick, die benutzen beide Cassandra. 01:36:35.190 --> 01:36:36.710 Und Facebook auf jeden Fall und entwickelt. 01:36:36.950 --> 01:36:40.070 Genau, Facebook hat es entwickelt, ich weiß nicht, wie viel, die Kommitten, 01:36:40.230 --> 01:36:42.070 glaub ich, sogar noch zum Open Source ein bisschen, aber. 01:36:42.550 --> 01:36:45.510 Facebook setzt das, soweit ich weiß, für die Inbox-Suche ein. 01:36:45.830 --> 01:36:46.790 Genau, richtig. 01:36:47.670 --> 01:36:51.350 Ja, und das ist halt auch so einer dieser Column-Stores, den es da gibt. 01:36:51.430 --> 01:36:54.150 Wie gesagt, HBase, was dann auf Big Table basiert. 01:36:54.310 --> 01:36:57.350 Also HBase, da hat sich einfach jemand Big Table durchgelesen und hat gesagt, 01:36:57.510 --> 01:37:03.270 ich habe ein Wochenende Zeit, ich mache das mal in Java und das hat dann sicher auch Jahre gedauert, 01:37:03.350 --> 01:37:04.150 bis das fertig war. 01:37:06.710 --> 01:37:08.550 Warum geht mir jetzt gerade SM durch den Kopf? 01:37:08.950 --> 01:37:10.150 Sado Maso oder? 01:37:10.630 --> 01:37:10.790 Genau. 01:37:12.070 --> 01:37:13.270 Aber eher Maso, oder? 01:37:13.750 --> 01:37:14.950 Ja, letzter. 01:37:15.830 --> 01:37:20.150 Richtig, und das ist halt, ja, die setzen dann halt auch, sagen dann ja. 01:37:20.550 --> 01:37:23.910 Wir hätten aber auch gerne ein verteiltes Dateisystem drunter, so wie ich das verstanden habe. 01:37:23.990 --> 01:37:24.310 Ja, genau. 01:37:24.390 --> 01:37:28.870 Und dafür haben sie dann nochmal das verteilte Dateisystem nachimplementiert nach dem Google FS, 01:37:28.950 --> 01:37:31.670 also nach dem GFS-Paper und haben das halt auch mal wieder so. 01:37:32.230 --> 01:37:34.230 Das HDFS war es dann, glaube ich. 01:37:34.390 --> 01:37:35.270 Ist das nicht HFS? 01:37:35.350 --> 01:37:36.470 Nee, HFS war was anderes. 01:37:38.470 --> 01:37:39.350 Und das aktuelle Trause. 01:37:41.910 --> 01:37:42.790 Ihr wollt gerade sagen, ja. 01:37:43.110 --> 01:37:43.830 HFS Plus. 01:37:44.310 --> 01:37:45.750 Ja, genau, HDFS. 01:37:45.910 --> 01:37:52.310 Genau, das sind so zwei Column-Stores, die wir also dieses freakige multidimensionale Hash-Dingen. 01:37:53.190 --> 01:37:55.190 Also das sind so endlich skalieren. 01:37:55.510 --> 01:37:56.710 Age und Hash und. 01:37:57.110 --> 01:37:57.830 Bingo, ja. 01:37:58.390 --> 01:37:58.710 Richtig. 01:37:58.870 --> 01:38:00.790 Genau, das sind so zwei Column-Stores. 01:38:01.670 --> 01:38:05.830 Man wird als Mensch, ich muss es, also ich muss mir die alle mal anschauen oder hab die alle irgendwie meine 01:38:05.910 --> 01:38:08.550 Masterthesis mal so beliebtäugt. 01:38:08.790 --> 01:38:10.950 Und dieser Column Store, der ist nicht intuitiv. 01:38:11.190 --> 01:38:12.310 Alle anderen sind recht intuitiv. 01:38:12.550 --> 01:38:17.670 Column Store musste erstmal dein Gehirn so ein bisschen drum drumrum knoten und so, ah, jetzt. 01:38:18.710 --> 01:38:23.670 Und dann macht es auch halbwegs Sinn, aber also ich fand es ja eine der unangenehmeren zum Zusammenarbeiten. 01:38:23.830 --> 01:38:25.030 Aber skaliert echt schön. 01:38:25.110 --> 01:38:31.350 Also Cassandra gerade hat auch so das ganze automatische Failover und du kannst recht genau einstellen, 01:38:31.510 --> 01:38:36.950 welche Columns du wie vorhalten willst und sagen, ja, die sollen mindestens auf sechs Servern sein und das 01:38:36.950 --> 01:38:37.910 sind wichtige Daten. 01:38:37.990 --> 01:38:41.830 Erst wenn sechs Server sagen, ja, diese Daten haben wir, dann akzeptiere ich die. 01:38:42.070 --> 01:38:45.190 Und du kannst dann auch sagen, irgendwie, die Daten sind völlig unwichtig, 01:38:45.270 --> 01:38:48.310 da verteil die schön, dass es schnell wird, aber es reicht, wenn ein Server sagt, 01:38:48.470 --> 01:38:49.110 ja, hier. 01:38:49.590 --> 01:38:51.110 Das ist Cassandra. 01:38:52.150 --> 01:38:53.270 Ist ein Column Store. 01:38:53.430 --> 01:38:55.510 HBase auch ein Column Store. 01:38:56.150 --> 01:39:00.070 Also viele verwenden, also es ist immer so ein Hin und Her, gerade wenn du so Präsentationen von Unternehmen 01:39:00.070 --> 01:39:02.710 anschaust, dann sagen halt viele, ja, nee, wir haben jetzt doch HBase verwendet, 01:39:02.870 --> 01:39:04.550 weil Performance und bla. 01:39:05.670 --> 01:39:09.670 Cassandra ist einfacher, HBase, eventuell ein bisschen schneller noch. 01:39:10.230 --> 01:39:11.750 Sind aber beide ein bisschen freaky. 01:39:12.230 --> 01:39:12.630 Genau. 01:39:12.950 --> 01:39:14.950 Get freaky, get freaky. 01:39:15.990 --> 01:39:16.470 Gott. 01:39:17.590 --> 01:39:18.870 Document Store. 01:39:20.230 --> 01:39:22.230 Nee, Data Structure Store. 01:39:23.830 --> 01:39:24.710 Bestimme ich jetzt einfach mal. 01:39:25.030 --> 01:39:25.990 Data Structure Store. 01:39:27.030 --> 01:39:27.830 Ich weiß nicht, Redis. 01:39:27.910 --> 01:39:28.390 Das ist halt so. 01:39:28.550 --> 01:39:29.590 Will jemand anders mal reden? 01:39:29.910 --> 01:39:31.830 Ja, Redis habe ich auch schon ein bisschen was mitgemacht. 01:39:32.230 --> 01:39:34.550 Ich verwechselt immer komischerweise Redis und RIAC. 01:39:35.990 --> 01:39:36.710 Die hören mit R an. 01:39:37.030 --> 01:39:38.790 Fängt beides mit R an Redis. 01:39:39.190 --> 01:39:43.910 Redis ist im Endeffekt angefangen als In-Memory Store für 01:39:44.710 --> 01:39:45.430 Datenstrukturen. 01:39:46.230 --> 01:39:52.070 Eigentlich ist es ein Key-Value-Store, allerdings mit der Underung, 01:39:52.470 --> 01:39:55.350 dass die Values auch Datenstrukturen sein können. 01:39:55.510 --> 01:39:59.350 Das heißt, man kann jetzt halt hier jetzt einen Key, der kann jetzt direkt auf eine Value zeigen, 01:39:59.430 --> 01:40:05.910 der kann aber auch auf einen Array, also eine Liste von Values zeigen oder auf eine Map also weitere 01:40:05.910 --> 01:40:07.110 Key-Value-Parer zeigen. 01:40:07.270 --> 01:40:07.430 Richtig. 01:40:07.590 --> 01:40:10.870 Aber der Trick ist bei dem Ganzen, dass Redis jetzt nicht nur der reine Key-Values da ist, 01:40:10.950 --> 01:40:13.110 wo ich nur sagen kann, gib mir den Key und er sagt, okay. 01:40:13.270 --> 01:40:15.510 Sondern Redis hat echt Datenstrukturen. 01:40:15.670 --> 01:40:19.670 Er hat zum Beispiel Sets, also ein Hash zum Beispiel, du kannst zwei, oder nimm zwei Arrays. 01:40:19.750 --> 01:40:24.950 Du hast zwei Arrays, das sind einmal irgendwie alle Benutzer und einmal benutzer, die Admins sind. 01:40:25.590 --> 01:40:28.310 Kannst du ja machen, ist eigentlich eine recht nette Sache. 01:40:28.950 --> 01:40:33.590 Redis bietet dir generell, also erstmal alles hat Redis-Treiber so ziemlich, 01:40:33.670 --> 01:40:35.750 also jede Programmiersprache kann da irgendwie drauf zugreifen. 01:40:35.910 --> 01:40:39.350 Redis ist unglaublich schnell, also es ist so eins der schnellsten Sachen, 01:40:39.430 --> 01:40:42.390 die du machen kannst, weil er halt recht einfache Datenstrukturen hat. 01:40:42.550 --> 01:40:45.990 Und Redis bietet dir zum Beispiel so Sachen wie Push und Pop an. 01:40:46.630 --> 01:40:49.510 Bedeutet Push und Pop, wenn man so einen Stapel speichern, einen Stack hat, 01:40:49.590 --> 01:40:51.830 da kannst du halt irgendwas drauf pushen, dann fällt es oben drauf, 01:40:51.990 --> 01:40:53.910 kannst du Pop sagen und dann kannst du es wieder wegnehmen. 01:40:54.070 --> 01:40:56.150 Das ist, wenn du Ques baust, zum Beispiel ganz nett. 01:40:56.230 --> 01:40:59.510 Wenn du so eine verteilte Queue hast, also wo du deine Jobs reinwirfst, 01:40:59.830 --> 01:41:03.350 dein Job kann dann zum Beispiel, wenn du einen Webcrawler baust, ist dein Job halt die URL, 01:41:03.430 --> 01:41:04.550 die er besuchen soll. 01:41:05.510 --> 01:41:10.790 Und du kannst dann halt sagen, gut, ich habe einen Server, da ist Redis drauf und alle anderen kleinen Server, 01:41:10.870 --> 01:41:13.670 die eigentlich nichts machen, außer Daten aus dem Netz holen, ein bisschen crawlen, 01:41:13.910 --> 01:41:15.670 die holen sich von Redis die Daten. 01:41:15.750 --> 01:41:19.910 Und bevor du da jetzt großartig komplexe Sachen in MySQL oder sowas implementierst, 01:41:20.070 --> 01:41:23.830 hast du einfach Redis, hast standardmäßig schon ein Array drin, ein verteiltes Array, 01:41:23.990 --> 01:41:25.910 wo die Leute atomar drauf zugreifen können. 01:41:25.990 --> 01:41:28.070 Also der macht auch das ganze Locking und so für dich. 01:41:28.150 --> 01:41:33.270 Und dann kannst du halt Pop sagen und auf einmal kriegst du was und kannst damit arbeiten und kannst sicher 01:41:33.270 --> 01:41:37.030 sein, dass das niemand anders denselben Job bearbeiten wird. 01:41:37.590 --> 01:41:43.030 Die bieten aber auch so Sachen wie, keine Ahnung, Pop und push dieses Ding dann gleichzeitig in eine neue 01:41:43.030 --> 01:41:44.390 Liste und die neue Liste ist diese. 01:41:44.550 --> 01:41:46.950 Da kannst du dann zum Beispiel so, wenn du auch gerade eine Queue baust, 01:41:47.110 --> 01:41:52.630 dann kannst du halt sagen, gib mir das Element und tu es mal in die Inbearbeitung Cue rein. 01:41:53.030 --> 01:41:57.190 Und Redis bietet dir halt atomare Befehle für all diese Sachen. 01:41:57.270 --> 01:42:01.590 Er bietet dir auch Sachen, wie ich vorher diese zwei Arrays hatte, er bietet dir Intersections und Unions. 01:42:01.670 --> 01:42:04.710 Die heißen auf Deutsch dann Schnittmengen und. 01:42:05.190 --> 01:42:06.230 Intersections, Schnittmengen. 01:42:06.390 --> 01:42:08.470 Schnittmengen und Kreuzung und Vereinigung. 01:42:09.270 --> 01:42:12.790 Mathe-Zeugs, was in diesem generellen, wie heißt denn das Feld? 01:42:13.030 --> 01:42:13.750 Das ist Mengenmengen. 01:42:13.990 --> 01:42:14.870 Mengenlehre, genau. 01:42:15.110 --> 01:42:17.030 Mengenlehre bietet er die halt auch an. 01:42:17.270 --> 01:42:23.990 Bedeutet, du kannst da total schnell sagen, wenn du irgendwie rein zufällig eine so Abfragen wie von SQL, 01:42:24.070 --> 01:42:28.550 die typischen irgendwie Select, Stern from Users, where nehmen gleich oder keine Ahnung, 01:42:28.630 --> 01:42:30.470 where Hometown gleich Stuttgart oder so. 01:42:30.550 --> 01:42:33.990 Dann kannst du einfach ein Array machen, Stuttgart, Bewohner von Stuttgart, 01:42:34.150 --> 01:42:37.510 tust die da alle rein und machst ein zweites Array, irgendwie, keine Ahnung, 01:42:37.670 --> 01:42:44.470 Gehaltsklasse über 50.000 Euro und Redis kann dir auf dem Server nativ einfach alle Elemente zurückgeben, 01:42:44.790 --> 01:42:46.470 die in beiden gleichzeitig drin sind. 01:42:46.630 --> 01:42:47.590 Sauschnell. 01:42:48.150 --> 01:42:52.470 Und du kannst da jetzt nicht sagen, gib mir alle Leute zurück. 01:42:52.550 --> 01:42:56.870 Oder ja, kannst du wahrscheinlich auch jetzt in der Zwischenzeit, aber Redis bietet dir halt echt so ganz 01:42:56.870 --> 01:43:01.670 einfache Datenstrukturen, Hashes, Arrays und bietet dir total coole Methoden an. 01:43:02.230 --> 01:43:03.590 Ja, Flydy, vielleicht. 01:43:03.910 --> 01:43:08.550 Ja, ich glaube, das Interessante daran ist, dass man tatsächlich auch eigene atomare Operationen auf der 01:43:08.550 --> 01:43:09.990 Datenbank definieren kann. 01:43:10.150 --> 01:43:11.990 Das heißt, ich habe jetzt irgendwie. 01:43:13.590 --> 01:43:15.750 Eine Transaktion, wie das früher hieß, zum Beispiel. 01:43:15.910 --> 01:43:18.950 Das sind ja auch nur eine atomare Operationen, die aus mehreren zusammengesetzt ist. 01:43:19.270 --> 01:43:25.910 Also ich möchte jetzt einen Datensatz einfach eine Veränderung von dem Datensatz auf viele anwenden. 01:43:26.070 --> 01:43:31.270 Und dann kann ich schon sagen, okay, ich definiere das jetzt hier und die Datenbank kümmert sich dann darum, 01:43:31.350 --> 01:43:33.670 dass es in einem Rutsch abgearbeitet wird. 01:43:33.830 --> 01:43:34.390 Atomark. 01:43:34.470 --> 01:43:35.110 Okay, gut. 01:43:35.990 --> 01:43:37.110 Können normale Datenbanken auch. 01:43:37.350 --> 01:43:37.670 Ja, genau. 01:43:37.750 --> 01:43:41.990 Das ist es eben, es ist eine der wenigen Key-Value-Stores, die das können oder eine der wenigen NeuesQL, 01:43:42.070 --> 01:43:42.790 die Transaktionen bieten. 01:43:43.030 --> 01:43:47.030 Und das, was du gerade mit Intersections meintest, das macht eine Join-letzten Endes auch. 01:43:47.350 --> 01:43:48.150 Richtig, genau. 01:43:48.310 --> 01:43:52.870 Nur das, also man muss halt sagen, dieser Redis-Kerl, der ist einfach so nett, der ist irgendein Italiener. 01:43:53.110 --> 01:43:54.150 Wir machen das, weil es nett ist. 01:43:55.510 --> 01:44:00.390 Der Typ ist so ein italienischer Programmierer und er kann unglaublich gutes und schönes C schreiben. 01:44:00.470 --> 01:44:06.310 Also es ist wunderschöner C-Code und sauschnell, extrem effizient, der kennt sich mit Datenstrukturen aus wie 01:44:06.310 --> 01:44:07.110 kein zweiter. 01:44:08.470 --> 01:44:13.750 Ja, also wir haben, da gab, wir haben in den Shownotes auch einen Blogpost, wo es um die Redis-Interns geht. 01:44:13.910 --> 01:44:20.230 Und da ist mal in so zweieinhalb Bildschirmseiten erklärt, wie denn das ganze System so aufgebaut ist und was 01:44:20.230 --> 01:44:23.990 die einsetzen, um Optimierung zu erreichen. 01:44:24.070 --> 01:44:26.790 Und das ist alles schon relativ elegant aufgebaut. 01:44:27.110 --> 01:44:31.830 Und auch so dieses Wire-Protokoll, was die sprechen, die sprechen ein ganz normales ASCII-Protokoll, 01:44:31.910 --> 01:44:35.830 was man irgendwie zur Not auch mit einem Telnet als Socket Shell bedienen kann. 01:44:35.990 --> 01:44:39.910 Und diese Operationen, die die da einsetzen, mit denen man auf den Daten arbeiten kann, 01:44:39.990 --> 01:44:41.430 die heißen halt auf dem Protokoll auch so. 01:44:41.510 --> 01:44:48.150 Da sagt man hier Push und Pop und irgendwie, dann gibt es noch Multi-Push und Multi-Pop und irgendwie Set and 01:44:48.230 --> 01:44:50.390 Change oder so oder Get und Change, irgendwie sowas. 01:44:50.950 --> 01:44:54.390 Auf jeden Fall ist das halt auch für einen Menschen relativ einfach verständlich, 01:44:54.470 --> 01:44:56.790 wenn man sich das Protokoll nur anguckt. 01:44:57.030 --> 01:45:01.030 Und darum gibt es wahrscheinlich auch so viele Treiber, weil es einfach trivial ist, sowas zu implementieren. 01:45:01.190 --> 01:45:05.990 Also jede Programmiersprache hat eigentlich einen und das, ja, es ist echt super. 01:45:06.150 --> 01:45:08.310 Was man auch noch sagen muss, ist, der Support ist grandios. 01:45:08.470 --> 01:45:11.670 Also ich habe gestern Abend einen Fehler festgestellt in der neuesten Entwicklerversion, 01:45:11.910 --> 01:45:16.550 hab' getwittert, ich glaube, irgendwie 10 Minuten später hat mir der Hauptentwickler gesagt, 01:45:16.630 --> 01:45:20.230 so ey, kannst du mir mal irgendwie noch eine E-Mail schreiben mit genauer E-Mail geschrieben und dann 01:45:20.230 --> 01:45:23.750 irgendwie 15 Minuten später gefixt und konnte das Zeug holen. 01:45:23.830 --> 01:45:29.030 Und echt eine große, schöne Community, aktive Mailingliste, treibe für alle Sprachen. 01:45:29.350 --> 01:45:31.350 Hatten wir Published Subscribe schon angesprochen? 01:45:31.430 --> 01:45:34.630 Nee, der, der, also genau, sag mal halt, also der kann jetzt nicht nur dieses einfache Zeug, 01:45:34.710 --> 01:45:36.070 sondern die haben jetzt total coole Sachen drin. 01:45:36.150 --> 01:45:39.350 Genau, die haben zum Beispiel ein Published Subscribe System, da kann man zum Beispiel sagen, 01:45:39.670 --> 01:45:45.590 gerade was der Marc jetzt erzählt hat, wir schreiben einen Crawler und der sucht URLs raus und haben dann 01:45:45.590 --> 01:45:50.230 wiederum weitere Crawler, die diese URLs wiederum abcrawlen zum Beispiel. 01:45:50.550 --> 01:45:53.510 Und dann kann man halt sagen, okay, man macht ein Published-Subscribe-System, 01:45:54.870 --> 01:45:59.350 man hat einen, der publisht neue URLs und die anderen subscribe, 01:45:59.510 --> 01:46:05.030 die abonnieren praktisch diese Änderungen, die da reingepusht werden und bekommen die dann halt auch immer 01:46:05.030 --> 01:46:05.590 zugeliefert. 01:46:05.670 --> 01:46:10.310 Und so kann man dann halt sagen, ja, die ganzen, die ganzen anderen Crawler, 01:46:10.390 --> 01:46:15.990 die dann diese URLs wieder entgegennehmen, um weiterzumachen, die können sich da halt einfach drauf 01:46:16.070 --> 01:46:18.470 registrieren und werden informiert, wenn es was Neues gibt. 01:46:18.550 --> 01:46:20.710 Und sonst muss man sich nicht drum kümmern. 01:46:20.790 --> 01:46:23.830 Man muss es halt auch nicht in seiner Applikationslogik implementieren, 01:46:24.310 --> 01:46:25.830 wenn man da die richtigen Schnittstellen führt. 01:46:25.910 --> 01:46:28.070 Richtig, ist ja, da gibt es in der Java-Welt gibt es so Sachen wie, 01:46:28.150 --> 01:46:31.910 keine Ahnung, ist ein bisschen mehr, aber so Sachen wie JMS zum Beispiel, 01:46:32.070 --> 01:46:34.150 Messaging-Systeme, die halt echt riesigengroß sind. 01:46:34.390 --> 01:46:40.550 Oder zum Beispiel APMQ oder RabbitMQ, ist glaube ich eine Implementierung von APMQ. 01:46:40.710 --> 01:46:41.990 Also es gibt so Queing-Systeme. 01:46:42.310 --> 01:46:48.950 MQ Series, MQ Series Series, genau, MSM, MSMQ und Beanstalk und was auch immer. 01:46:49.750 --> 01:46:53.430 Das ist eine relativ schlanke Java-Queuing-Geschichte, habe ich leider den Namen vergessen. 01:46:53.590 --> 01:46:56.870 Richtig, also ich habe es mir auch überlegt, ich habe ja so eine komische Thesis geschrieben, 01:46:56.950 --> 01:46:58.390 wo ich so einen Crawler da gebaut habe. 01:46:58.870 --> 01:47:02.070 Ich habe es jetzt nicht mit Publish Subscribe gemacht, aber Redis bietet halt auch Möglichkeiten, 01:47:02.310 --> 01:47:05.510 zum Beispiel einen Blocking-Pop zu machen. 01:47:05.750 --> 01:47:08.390 Bedeutet, da ist nichts in der Queue und wenn was in der Queue ist, 01:47:08.470 --> 01:47:11.910 also wenn nichts in der Que ist, warte, bis was reinkommt und holt es dir. 01:47:12.070 --> 01:47:14.870 Und das ist halt einfach nicht dieses, sind wir schon da, sind wir schon da, 01:47:14.950 --> 01:47:16.550 sind wir schon da, was so Kinder machen. 01:47:16.630 --> 01:47:22.150 Und das ist Pollen, genau, sondern du musst halt, du hast keinen Overhead, um auf Sachen zu warten. 01:47:22.310 --> 01:47:28.070 Und du kannst auch, wenn du was von ein System reinwirfst und du hast es komplett so Event getrieben, 01:47:28.150 --> 01:47:32.230 ist ja das Prinzip da aufgebaut, dann flutscht es einfach durch, ohne Wartezeiten, 01:47:32.310 --> 01:47:32.950 ohne Overhead. 01:47:33.190 --> 01:47:35.110 Und das macht MQ auch. 01:47:35.350 --> 01:47:35.590 Genau. 01:47:35.670 --> 01:47:40.310 Und das ist eben, wenn wir Datenbank, Datenstrukturserver sagen, das macht eben Redis, weil der halt so. 01:47:40.550 --> 01:47:42.150 Und das macht es halt auch extrem elegant. 01:47:42.230 --> 01:47:45.270 Also ich meine, gerade so Polling möchte man eigentlich, wo es geht, vermeiden. 01:47:45.350 --> 01:47:47.910 Also gerade darum schreibe ich da gerade eine Thesis drüber. 01:47:48.790 --> 01:47:53.590 Und also ja, wie gesagt, dieses Eventgetrieben ist einfach eigentlich das, 01:47:53.670 --> 01:47:57.830 wo man hin will, weil man möchte nicht dauernd nachfragen müssen, gibt es neue Daten, 01:47:57.910 --> 01:48:01.990 sondern man möchte jetzt hier neue Daten, ich nehme zu verarbeite weiter und ansonsten kann ich irgendwas 01:48:01.990 --> 01:48:02.550 Interessantes machen. 01:48:03.350 --> 01:48:04.790 Ich gibt zwei gute Anwendungsbeispiele dafür. 01:48:04.870 --> 01:48:09.030 Das eine ist diese Pushmail von BlackBerry und das Open Source Pono IMAP Idol. 01:48:11.910 --> 01:48:12.390 Richtig. 01:48:12.630 --> 01:48:17.670 Und was Redis, Pleiadi hast du gerade am Anfang erwähnt, das war am Anfang so in Memory die Geschichte, 01:48:17.750 --> 01:48:20.230 bedeutet Redis hat sein ganzes Zeug im Speicher gehalten. 01:48:20.550 --> 01:48:24.230 Du konntest da auch nicht mehr Daten reinpacken, als in Speicher gehören. 01:48:24.390 --> 01:48:28.790 Bei vielen Sachen wie Ques ist es gar nicht so wild, weil du hast echt nur teilweise eine URL oder so. 01:48:28.870 --> 01:48:30.870 Du kannst viele URLs in einen Speicher klatschen. 01:48:30.950 --> 01:48:33.350 Gibt es jemanden Gigabyte, da passt viel String rein. 01:48:34.390 --> 01:48:35.510 Ein Gigabyte sozusagen. 01:48:35.750 --> 01:48:37.670 Ja, quasi, quasi ja. 01:48:37.910 --> 01:48:42.150 Und da Redis alles sehr, sehr performant kodiert, ist das eine echt schöne Sache. 01:48:42.230 --> 01:48:44.710 Das Coole ist, Redis hat sich jetzt ein bisschen gemausert. 01:48:44.790 --> 01:48:49.510 Sie haben jetzt angefangen, so eine VM-Lösung zu schreiben, wo sie dann ein bisschen auch die Daten, 01:48:49.670 --> 01:48:52.310 also sie konnten die Daten schon immer persistieren. 01:48:52.470 --> 01:48:53.590 Also das haben sie schon immer gemacht. 01:48:53.830 --> 01:48:54.230 Dump-mäßig. 01:48:54.470 --> 01:48:56.950 So ein Dump, genau, musstest dann halt irgendwie, wenn er gecrasht ist, 01:48:57.030 --> 01:49:00.870 hast du dann halt neuer hochgefahren und halt gesagt, ja, alle konntest dann festlegen, 01:49:00.950 --> 01:49:04.550 irgendwie, das soll er alle fünf Sekunden oder wenn sich 100 Keys geändert haben oder wie auch immer. 01:49:05.190 --> 01:49:10.070 Dann haben sie das geändert und haben das so gemacht, dass du das so ein bisschen wie Swapping quasi. 01:49:10.230 --> 01:49:13.910 Nur haben sie gesagt, Swapping, das ist auch das Schöne, also der Typ kennt sie auch mit Betriebssystemen 01:49:13.910 --> 01:49:14.470 super aus. 01:49:14.630 --> 01:49:16.550 Viele haben gesagt, ja, kannst ja auch Swapping nehmen. 01:49:16.630 --> 01:49:20.230 Ist ja egal, hast du halt mehr Daten als im Speicherpassen, dein Betriebssystem scheffelt es heraus. 01:49:20.390 --> 01:49:23.910 Hat der sich das angeschaut und gesagt, so, ah nee, allein die Page-Tables, 01:49:23.990 --> 01:49:26.230 das sind ja viel zu groß und das ist völlig ineffizient. 01:49:26.390 --> 01:49:32.790 Hat er selber gebaut, VM, hat auch halbwegs funktioniert, war ihm jetzt aber ein bisschen zu naja, 01:49:32.870 --> 01:49:35.750 und jetzt was er Neues macht, ist, er macht jetzt ein Disk-Backend dafür. 01:49:35.910 --> 01:49:39.350 Bedeutet, er versucht immer noch alles, wenn es geht, im Speicher zu halten. 01:49:40.230 --> 01:49:46.550 Und das Ganze dann, wenn es nicht mehr in Speicher passt, quasi auf Dateisystemebene das Ganze abzulegen. 01:49:46.630 --> 01:49:50.310 Bedeutet, er hat dann irgendwie, macht halt, brauchst ein gutes Dateisystem drunter, 01:49:50.390 --> 01:49:53.830 aber Redis geht jetzt auch in die Richtung, dass du nach wie vor schnell bist, 01:49:53.990 --> 01:49:58.950 aber auch deine Daten, beliebig viel Daten im Grunde in deinen Server packen kannst. 01:49:59.110 --> 01:50:03.830 Das ist eine echt coole Sache, wenn ihr gerade schlanke Datenstrukturen, einen schnellen Server braucht. 01:50:05.110 --> 01:50:08.950 Ich glaube, wenn man da halt auch noch ein bisschen von Persistenz reden, 01:50:09.510 --> 01:50:12.470 was wir da vielleicht auch noch ansprechen könnten, wären Append-Ony-Log. 01:50:12.710 --> 01:50:14.310 Das hat ja Redis am Anfang auch gemacht. 01:50:14.390 --> 01:50:18.870 Ich habe auch mal in der Implementierung was rumgepatcht für Notechairs, 01:50:19.190 --> 01:50:23.750 die sowas implementiert hat und zwar, was man da macht, ist, man hält zwar alle Daten im Speicher, 01:50:23.830 --> 01:50:30.310 aber sobald eine Schreiboperation ist, hängt man die mit einem Eintrag in einer gewissen gewissen 01:50:30.310 --> 01:50:32.870 Datenstruktur an eine Datei ran. 01:50:33.190 --> 01:50:36.230 Und so muss man immer nur anhängen, anhängen, anhängen und dann kann man halt auch sagen, 01:50:36.390 --> 01:50:41.990 okay, ich, wenn die Platte gerade was zu tun hat und ich gerade nicht schreiben kann oder gerade schon einen 01:50:41.990 --> 01:50:46.150 Schreibvorgang läuft, dann kann ich die Daten zwischenpuffern und kann die dann in einem Rutsch rausschreiben. 01:50:46.310 --> 01:50:51.110 Und so hat man im Endeffekt dann halt den Vorteil, wenn man, wenn die Datenbank jetzt mal crashen sollte oder 01:50:51.110 --> 01:50:56.710 man möchte sie neu starten, dann kann man die runterfahren, kann sie wieder neu starten und beim Neustart muss 01:50:56.710 --> 01:51:02.070 ja zwar dieses komplette Pend-Only-Log wieder durchgehen, aber man hat dann im Endeffekt die Daten, 01:51:02.150 --> 01:51:06.230 die in der Datenbank zuvor gespeichert waren oder im Speicher vorgehalten waren, 01:51:06.310 --> 01:51:07.350 die hat man dann halt später wieder. 01:51:07.510 --> 01:51:08.870 Genauso macht das MQ Series. 01:51:10.790 --> 01:51:15.030 Die machen ja auch alle Datenbanken im Normalfall so diese Replay-Logs oder die ganzen Geschichten, 01:51:15.110 --> 01:51:18.310 wo du dann sagen kannst, wie oft da irgendwelche Sachen rausgeflasht werden müssen. 01:51:19.190 --> 01:51:20.550 Standard sogar jede Sekunde, ja, ja. 01:51:20.870 --> 01:51:22.710 Genau, und das konntest du bei Redis halt auch einstellen. 01:51:22.870 --> 01:51:23.990 Das war alles ganz nett. 01:51:24.310 --> 01:51:25.430 Wie gesagt, das ist ein. 01:51:25.830 --> 01:51:29.590 Wir haben jetzt mal Data Structure Store genannt, der einfach Datenstrukturen beinhaltet. 01:51:29.670 --> 01:51:30.550 Weil es ist jetzt. 01:51:30.790 --> 01:51:34.070 Er intern tut ja die alle als Strings ablegen. 01:51:34.630 --> 01:51:38.790 Er kann aber auch so Sachen wie Increment, also du kannst da auch Counter super implementieren, 01:51:38.870 --> 01:51:41.510 so verteilte Counter, wenn du irgendwie einen Hit-Counter hast oder so, 01:51:41.670 --> 01:51:45.110 wo dann irgendwie von 15 Quellen immer Leute hochzählen und runterzählen. 01:51:45.270 --> 01:51:48.070 Das ist ja ein Problem, wenn dann immer einer sagt, wie viel sind es denn gerade? 01:51:48.150 --> 01:51:51.350 Und dann sagt er, 150 und dann sagst du, ja, speichere mal 151. 01:51:51.590 --> 01:51:54.950 Und das Problem ist ja, wenn das fünf Leute gleichzeitig machen, wie viel sind es denn gerade? 01:51:55.030 --> 01:51:59.750 Dann sagt der fünfmal 150 und alle antworten dann so, ja, mach mal 151. 01:51:59.830 --> 01:52:04.550 Und der, ja, okay, von mir aus, fünf Leute haben eins dazugezählt und im Endeffekt ist eins dazugekommen. 01:52:04.710 --> 01:52:07.830 Das hat Redis auch geboten, also der hat dann immer diese Strings wieder geparst, 01:52:07.990 --> 01:52:11.910 hochgezählt und wieder gespeichert, alles in reinem C geschrieben, war eigentlich recht performant, 01:52:12.070 --> 01:52:13.190 erstaunlicherweise. 01:52:14.070 --> 01:52:15.830 Ja, Datenstrukturen. 01:52:16.150 --> 01:52:19.510 Das ist sowas Simples, Schnelles, echt super einzusetzen. 01:52:19.670 --> 01:52:22.870 Eins der wenigen Programme, die kein Punkt slash-Configure brauchen, 01:52:22.950 --> 01:52:25.190 sondern einfach nur ein Make, was ich gut finde. 01:52:25.350 --> 01:52:27.350 Runterladen, Make sagen, läuft. 01:52:27.590 --> 01:52:28.390 Ja, auf jeden Fall. 01:52:28.950 --> 01:52:29.910 Keine Abhängigkeiten. 01:52:29.990 --> 01:52:34.070 Also der Typ sagt auch, nee, ich mag Libraries nicht, die sind alle ineffizient und da musst du wieder so 01:52:34.070 --> 01:52:35.110 Sachen und das ist doof. 01:52:35.270 --> 01:52:36.950 Und der macht alles selber. 01:52:39.990 --> 01:52:41.670 Der macht alles selber, der ist aber auch saugut. 01:52:41.830 --> 01:52:44.310 Also an dem hängt das ganze Projekt, wenn der weg ist, hat man ein Problem. 01:52:44.470 --> 01:52:45.910 Okay, ein Busfaktor von 1, ja. 01:52:46.150 --> 01:52:46.470 Richtig. 01:52:46.870 --> 01:52:49.110 Der gute Busfaktor, der vom Bus überfahren wird. 01:52:49.350 --> 01:52:54.630 Genau, also der Busfaktor ist praktisch dieser Faktor, wie viele Leute dürfen vom Bus überfahren werden, 01:52:54.950 --> 01:52:57.190 bevor das Projekt irgendwie zugrunde geht. 01:52:57.430 --> 01:52:57.590 Richtig. 01:52:58.710 --> 01:53:00.390 Im Englischen heißt es übrigens Truck Factor. 01:53:00.950 --> 01:53:01.190 Genau. 01:53:01.350 --> 01:53:06.790 Der Redis, was noch, Verteilung haben wir vorhin gesprochen, bietet Redis eine Replikation an, Master Slave. 01:53:06.950 --> 01:53:10.070 Kannst du Read Slaves haben, aber keine Master Master Geschichten oder so. 01:53:10.230 --> 01:53:10.630 Ja, genau. 01:53:10.710 --> 01:53:12.790 Also sollen wir das kurz erklären, was da gemacht wird? 01:53:13.590 --> 01:53:18.070 Nee, Master Slave ist, glaube ich, klar, wir laufen hier sonst ein bisschen auf der Zeit raus. 01:53:18.550 --> 01:53:24.150 Okay, kommen wir zum nächsten, womit ich in der letzten Zeit relativ viel arbeite, ist MongoDB. 01:53:24.550 --> 01:53:27.030 Dabei handelt es sich um einen Document Store. 01:53:27.270 --> 01:53:29.590 Vielleicht der Name erstmal, weil der ist im Deutschen ein bisschen. 01:53:30.230 --> 01:53:30.390 Okay. 01:53:30.790 --> 01:53:31.510 MongoDU! 01:53:31.750 --> 01:53:36.150 Also der Name MongoDB kommt vom englischen You-Mongus, 01:53:36.230 --> 01:53:42.310 was so viel wie enorm, riesig, ja, ich glaube, da gibt es noch ein Synonyme für die Spieler. 01:53:42.470 --> 01:53:43.350 Das ist da keine falschen. 01:53:44.230 --> 01:53:46.630 Also das hat nichts mit Beleidigung zu tun. 01:53:46.950 --> 01:53:48.710 Oder mit Krankheiten oder überhaupt nicht. 01:53:49.190 --> 01:53:52.710 Also es gab schon Vorschläge, das Ganze in MangoDB umzugehen. 01:53:53.190 --> 01:53:54.150 Ja, Mango. 01:53:55.750 --> 01:53:57.110 Okay, zurück zum Thema. 01:53:57.190 --> 01:54:04.150 Es handelt sich hierbei um einen Document Store, was da was darin gespeichert wird und was das System 01:54:04.150 --> 01:54:06.870 in der Lage ist zu verstehen, ist ein Format namens Bison. 01:54:08.070 --> 01:54:11.750 Das schreibt man BSUN. 01:54:12.870 --> 01:54:16.070 Ist irgendwie ein Akronym für Binary-Encoded JSON. 01:54:17.190 --> 01:54:22.630 Also im Endeffekt sind das semantisch gesehen in JSON strukturierte Daten, 01:54:22.870 --> 01:54:25.030 die man da in Dokumenten abspeichern kann. 01:54:25.190 --> 01:54:30.870 Und was das System eigentlich fast einzigartig macht, ist, es kann zum einen Ad hoc-Querys. 01:54:30.950 --> 01:54:35.430 Also man kann jetzt hier, auch wenn man da jetzt irgendwie keine Map-Reduce-Funktion oder keine Key-Value-Pare 01:54:35.670 --> 01:54:39.990 hat, kann man jetzt sagen, okay, gib mir jetzt alle Benutzer mit dem Namen, 01:54:40.390 --> 01:54:42.870 mit einem Namen der mit A anfängt zum Beispiel. 01:54:43.190 --> 01:54:47.030 Und das kann das System ad hoc über eine Kommandozeile oder direkt, 01:54:47.270 --> 01:54:49.270 wenn man da über Schnittstellen drauf geht. 01:54:49.350 --> 01:54:55.910 Und man kann dann im Endeffekt halt auch bestimmte Attribute von einem Dokument festlegen und da einen Index 01:54:55.910 --> 01:54:56.470 drauflegen. 01:54:57.030 --> 01:55:02.630 Vielleicht zum, wie das Zeug aussieht, weil das war für mich so der Ich SQL ist nicht so meine starke Seite, 01:55:02.710 --> 01:55:05.110 ich kann es ein bisschen, aber die Abfragen sind immer ein bisschen mühsam für mich. 01:55:05.590 --> 01:55:07.430 Und das ist mehr so prototyp-basiert, finde ich. 01:55:07.670 --> 01:55:11.190 Ja, das ist so relativ intuitiv, weil die Abfragesprache an sich ist, 01:55:11.590 --> 01:55:17.110 also alles, was MongoDB macht, wird in JSON bzw. 01:55:17.430 --> 01:55:18.710 in Beeson übertragen. 01:55:18.790 --> 01:55:21.670 Also das Wire-Protokoll ist zum Großteil Beeson. 01:55:22.470 --> 01:55:28.790 Die Abfragesprache selbst ist auch wieder Beeson, das heißt, ich baue mir da so ein Prototyp zusammen und hab 01:55:28.790 --> 01:55:33.990 da ein paar relativ einfache JavaScript-Funktionen, die man da drin verwenden kann. 01:55:34.070 --> 01:55:39.910 Und dann kann ich zum Beispiel sagen, gib mir jetzt was sagt man denn? 01:55:40.390 --> 01:55:44.230 Gib mir jetzt jeden Manager, der irgendwie mehr als 10.000 Euro im Monat verdient, zum Beispiel. 01:55:44.390 --> 01:55:51.110 Und dann kann man sagt man halt Managers.Find, Klammer auf, geschweifte Klammer auf und dann irgendwie 01:55:52.470 --> 01:55:59.030 Salary größer gleich 10.000 geschweifte Klammer zu, runde Klammer zu und dann schickt man das ab und das ist 01:55:59.030 --> 01:56:03.350 mir im Endeffekt dann, sieht aus wie eine JavaScript-Funktion, ist auch eine JavaScript-Funktion intern. 01:56:04.310 --> 01:56:10.790 Und das wird dann halt im Endeffekt abgefeuert und führt dann den Query aus und gibt einem die Daten wiederum 01:56:11.110 --> 01:56:12.310 in diesem Biesen-Format zu. 01:56:12.550 --> 01:56:15.270 Das ist schon eine komplexere, weil wir da jetzt schon einen größeren Operator haben. 01:56:15.350 --> 01:56:15.430 Genau. 01:56:15.590 --> 01:56:19.110 Es gibt so ganz einfache Sachen, echt, es ist wie eine Schablone, die du quasi rüberlegst. 01:56:19.190 --> 01:56:22.630 Also wenn du Leute haben willst, deren Name Andreas ist, dann baust du dir ein Dokument, 01:56:22.710 --> 01:56:24.790 wo nur Name Doppelpunkt Andreas drinsteht. 01:56:24.870 --> 01:56:31.270 Und was MongoDB machen wird, ist, er vergleicht einfach diese Schablone quasi mit allen anderen Dokumenten und 01:56:31.270 --> 01:56:32.710 gibt dir zurück, welche gleich aussehen. 01:56:32.870 --> 01:56:35.750 Genau, man kann dann halt in den Indizes auch zum Beispiel festlegen, 01:56:35.910 --> 01:56:40.390 dass bestimmte Werte eindeutig sein müssen, dass die nur einmal vorkommen dürfen, 01:56:40.470 --> 01:56:41.030 zum Beispiel. 01:56:41.110 --> 01:56:47.510 Also sowas wie eine User-ID wäre zum Beispiel was, was man irgendwie gerne so definiert. 01:56:47.830 --> 01:56:50.870 Man kann auch sagen, dass bestimmte Felder ein Autoinkrement haben. 01:56:50.950 --> 01:56:57.110 Das heißt, dass jedes Mal, wenn da was Neues eingefügt wird, ein Code auch gezählt wird. 01:56:57.910 --> 01:56:59.110 Das geht zum Beispiel auch. 01:56:59.190 --> 01:57:02.630 Und also was ich zum Beispiel mal implementiert habe, war so eine normale User-Daten, 01:57:02.790 --> 01:57:07.510 also User-Datenbank, in der man zum Beispiel sagt, okay, jemand meldet sich mit seinem Benutzer an, 01:57:07.670 --> 01:57:13.190 dann wird da und gibt bei der Anmeldung praktisch sein Username und ein Passwort ein und dann wird im 01:57:13.190 --> 01:57:18.870 Endeffekt der Username genommen, eine Anfrage gestellt, gib mir mal bitte den Datensatz von diesem User und 01:57:18.870 --> 01:57:21.990 dann ein Hash über das Passwort generiert und die beiden Hashes, also der Hash, 01:57:22.070 --> 01:57:26.550 der User von dem Passwort, was der User eingegeben hat, plus der Hash des Passworts, 01:57:26.630 --> 01:57:28.950 was in der Datenbank hinterlegt, ist verglichen und dann entschieden, 01:57:29.030 --> 01:57:30.070 ob er jetzt rein darf oder nicht. 01:57:30.150 --> 01:57:31.750 So was zum Beispiel relativ trivial. 01:57:31.990 --> 01:57:36.790 Da muss man sagen, MongoDB ist eine der Datenbanken, der NoSQL-Datenbank, 01:57:36.870 --> 01:57:39.110 die sehr nahe an SQL rankommt, von dem, was sie können. 01:57:39.190 --> 01:57:42.310 Der einzige Unterschied ist, dass die keine Tabellen und Spalten verwenden, sondern Dokumente. 01:57:42.470 --> 01:57:42.870 Genau. 01:57:43.030 --> 01:57:48.630 Und also was mir daran extrem gut gefällt, ich programmiere zum einen in dem Projekt, 01:57:48.710 --> 01:57:54.470 in dem ich gerade arbeite, serversitiges JavaScript und das benutzt als internes Objektformat JSON. 01:57:54.630 --> 01:57:58.470 So, jetzt habe ich JSON in meiner Datenbank, habe JSON in meiner Programmiersprache und habe auch noch JSON 01:57:58.550 --> 01:57:59.590 als Query Language. 01:57:59.750 --> 01:58:05.350 Das heißt, ich habe im Endeffekt eigentlich nie gezwungen, zwischen meinen Sprachen zu wechseln, 01:58:05.430 --> 01:58:07.990 sondern kann immer im Endeffekt dasselbe Format benutzen. 01:58:09.750 --> 01:58:13.990 Genau, und was anderes, was halt auch bei der Entwicklung extrem hilft, 01:58:14.070 --> 01:58:19.110 ist, die Daten, die ich da drin speichere, die Dokumente, die sind relativ variabel. 01:58:19.190 --> 01:58:21.830 Das heißt, ich kann auch irgendwie so, wenn mir jetzt einfällt, hoch, 01:58:21.910 --> 01:58:26.790 ich habe da ein Attribut vergessen, dann kann ich das einfach anhängen und alle Daten, 01:58:26.870 --> 01:58:31.030 die in Zukunft gespeichert werden, haben halt dieses Attribut mit drin und alle Daten, 01:58:31.190 --> 01:58:34.150 die ich davor gespeichert habe, die haben dieses Attribut halt nicht. 01:58:34.550 --> 01:58:40.390 Und die kommen dann halt im Endeffekt als Null aus der Datenbank und da muss ich halt eine Applikationslogik 01:58:40.390 --> 01:58:41.990 entsprechend damit umgehen können. 01:58:42.070 --> 01:58:44.870 Ja, du kannst ja auch einmal so einen Clean-Up-Job schreiben, der sich einfach alle holt, 01:58:44.950 --> 01:58:47.990 die dieses Dingens nicht haben, dieses Element, und das eben entsprechend behandelt. 01:58:48.470 --> 01:58:51.830 Du hast da jetzt sowas wie ein Auto-Table bei relational Datenbanken werden. 01:58:52.150 --> 01:58:57.190 Richtig, genau, nur dass der da halt quasi, ich sag mal, 01:58:57.270 --> 01:59:00.390 du kannst dann mehr Logik da reinbringen, die du nicht in SQL kodieren musst und sagst, 01:59:00.630 --> 01:59:04.470 gib mir alle alten und dann gehst du da drüber und speicherst halt immer das Neue rein. 01:59:04.870 --> 01:59:08.550 Was MongoDB auch relativ cool macht, ist, es ist ziemlich performant. 01:59:09.750 --> 01:59:15.990 Heißt, es hält auch relativ viele, vor allem Schreiboperationen im Speicher vor und flascht die dann irgendwie 01:59:15.990 --> 01:59:18.790 nur in regelmäßigen Abständen auf die Platte. 01:59:19.830 --> 01:59:23.590 Hat dann halt im Endeffekt den Vorteil, wenn man extrem viele Schreiboperationen hat, 01:59:24.070 --> 01:59:28.710 dann kann man das ziemlich schnell bewerkstelligen. 01:59:28.950 --> 01:59:32.310 Und es bietet so ein Feature, das nennt sich Autoshading, das heißt, 01:59:32.390 --> 01:59:38.870 ich kann jetzt bestimmte Dokumente oder bestimmte Typen von Dokumenten über einen 01:59:39.590 --> 01:59:44.230 Cluster von mehreren Servern verteilen und kann dann sagen, okay, ich habe jetzt hier User-ID, 01:59:45.270 --> 01:59:51.910 A bis D und E bis F und kann die halt im Endeffekt dann so gestückelt 01:59:52.470 --> 01:59:55.350 auf meine einzelnen Datenbankserver verteilen. 01:59:55.670 --> 01:59:58.550 Und das geht so halbautomatisch mit MongoDB. 01:59:58.790 --> 02:00:02.630 Ja, ist nur ein bisschen, also wesentlich mehr Arbeit als zum Beispiel den ganzen Dynamo- und 02:00:02.710 --> 02:00:03.590 B-Table-basierten. 02:00:04.110 --> 02:00:04.670 Aber es geht. 02:00:04.830 --> 02:00:09.790 Und man muss auch sagen, MongoDB, sie sind sehr, sehr nahe vom Leistungsumfang an normalen Datenbanken. 02:00:09.870 --> 02:00:12.510 Also du musst trauerweise auch selber deine Indexe festlegen. 02:00:12.590 --> 02:00:13.870 Also, aber du hast auch Indexe. 02:00:14.030 --> 02:00:14.910 Dafür hat man die auch, ja. 02:00:15.070 --> 02:00:19.070 Genau, also du verwenden da auch einen B Plus-Baum wie, keine Ahnung, MySQL, alle. 02:00:19.230 --> 02:00:19.870 Ja, im Grunde. 02:00:19.950 --> 02:00:20.030 Alle. 02:00:20.350 --> 02:00:20.750 Ja, eigentlich alle. 02:00:21.150 --> 02:00:21.230 Genau. 02:00:21.390 --> 02:00:24.590 Was MongoDB halt besonders macht, ist, dass die ein recht junges Projekt ist. 02:00:24.670 --> 02:00:27.710 Das bedeutet, die haben gesagt, ja, wir sind jetzt nicht 15 Jahre alt, 02:00:28.190 --> 02:00:32.350 sondern wir machen das Ganze mal neu von Grund auf mit modernen Programmiersprachen. 02:00:32.430 --> 02:00:34.190 Ist ein C ⁇ geschrieben, glaub, komplett. 02:00:34.510 --> 02:00:35.550 Also ja, moderner Programm-Sprache-Sprache. 02:00:37.870 --> 02:00:40.350 Ja, ich sag mal, vom Konzept her, es ist objektorientiert. 02:00:40.430 --> 02:00:42.990 Das ist schon mal schöner, als wenn du so eine C-basierte Datenbank hast, 02:00:43.070 --> 02:00:45.950 wo dann halt echt von der Größe her irgendwann ein Problem wird, das zu managen. 02:00:46.110 --> 02:00:53.070 Ja, sagen wir es mal so, sie implementieren es mit aktuellem Stand der Technik und mit modernen 02:00:53.390 --> 02:00:56.750 Algorithmen und so weiter und benutzen dazu halt C ⁇ . 02:00:57.070 --> 02:00:58.510 Also ob C ⁇ jetzt moderner oder nicht? 02:00:58.910 --> 02:01:04.190 Ja, das ist eigentlich eine der schnellsten Sprachen, die noch zumindest halbwegs objektorientiert sind. 02:01:04.270 --> 02:01:04.590 Ja. 02:01:04.910 --> 02:01:05.550 Genau. 02:01:06.750 --> 02:01:08.270 Und Diaspora nutzt das. 02:01:08.430 --> 02:01:08.510 Echt? 02:01:08.830 --> 02:01:10.110 Ja, Diaspora nutzt es zum Beispiel. 02:01:10.430 --> 02:01:12.350 Genau, ich wollte gerade auch fragen, wer nutzt es noch? 02:01:12.510 --> 02:01:17.230 Also ein großer Nutzer von MongoDB ist unter anderem Foursquare. 02:01:17.790 --> 02:01:24.510 Da weiß ich es, die hatten, haben mittlerweile drei Server auf EC2 02:01:24.590 --> 02:01:27.950 Large, also bei Amazon, mit jeweils 64 GB RAM. 02:01:28.990 --> 02:01:35.870 Als sie nur noch zwei hatten, gab es da mal so ein Problem, dass das Autoshading aus dem Ruder 02:01:35.870 --> 02:01:42.110 gelaufen ist und dann die eine Maschine mehr Daten hatte als RAM verfügbar war und die andere Maschine weniger 02:01:42.270 --> 02:01:48.190 und so musste die eine Maschine dann die ganze Zeit swappen und hat dann halt das System so ein bisschen 02:01:48.190 --> 02:01:48.670 runtergezogen. 02:01:48.910 --> 02:01:51.390 Man muss auch sagen, MongoDB ist noch sehr im Umbruch. 02:01:51.470 --> 02:01:54.190 Also ich habe das damals mir für die Thesis angeschaut und also das, 02:01:54.270 --> 02:01:57.790 was ich am Anfang vorgefunden habe, war sechs Monate später was komplett anderes, 02:01:57.950 --> 02:02:00.270 was Probleme angeht, was Performance-Schwächen angeht. 02:02:00.350 --> 02:02:03.550 Also die optimieren sehr viel rum, sind unglaublich hilfbereit. 02:02:03.630 --> 02:02:06.590 Also es gibt einen IOC-Channel, wo du die Programmierer von dem Ding drin findest, 02:02:06.670 --> 02:02:10.350 mindestens vier Stück, werden von der Firma gesponsert, TenGen heißen die. 02:02:10.430 --> 02:02:14.190 Die machen so ein bisschen Consulting in dem Bereich, aber sponsern halt auch volle Kanne, 02:02:14.270 --> 02:02:17.870 vier Programmierer oder so für MongoDB oder das ist ihr Produkt im Grunde. 02:02:18.030 --> 02:02:19.710 Es ist komplett Open Source. 02:02:20.750 --> 02:02:25.550 Sie haben ein schönes Bug-Tracking-System, Jira, kannst du als deine Bugs eintragen, 02:02:25.630 --> 02:02:27.310 die werden dann auch schön bearbeitet. 02:02:29.070 --> 02:02:30.910 Es, äh, was war denn noch alles? 02:02:31.150 --> 02:02:35.790 Sie haben Treiber für alles, viele selber hergestellt, aber es gibt als echt wieder für alles. 02:02:35.870 --> 02:02:40.190 Also für .NET, Java, es gibt für JavaScript, Lua, Node.js, 02:02:40.510 --> 02:02:43.070 Ruby, Python, Pearl, schieß mich tot. 02:02:43.310 --> 02:02:45.870 Ja, also es gibt Treiber für so ziemlich alles. 02:02:46.270 --> 02:02:52.110 Und also was ich auch bei der Entwicklung extrem schön finde, ist, man kann extrem schnell mitstarten. 02:02:52.190 --> 02:02:56.750 Man kompiliert das Teil einmal, installiert das und dann läuft es. 02:02:56.990 --> 02:02:57.630 Genau, man kann. 02:02:57.870 --> 02:03:02.350 Okay, dann lässt man es irgendwie mal auf Localhost laufen, später kann man dann auch Username and Passwort 02:03:02.350 --> 02:03:07.150 definieren, aber im Endeffekt den Rash, den man so anlegt, das wird eigentlich dann über die API erledigt und 02:03:07.150 --> 02:03:11.150 man muss dann halt im Endeffekt nicht mehr großartig an irgendwelchen Config-Files oder sonst irgendwas 02:03:11.230 --> 02:03:11.310 machen. 02:03:11.470 --> 02:03:14.430 Es gibt aber auch eine Konsole, die halbwegs angenehm ist, wo man da noch rein kann. 02:03:14.750 --> 02:03:16.430 Der Konsolenbefehl heißt Mongo. 02:03:16.990 --> 02:03:19.950 Auch nicht beleidigen gemeint, ist einfach so. 02:03:20.350 --> 02:03:22.990 Genau, was es noch gibt, ist MongoDB bietet auch MapReduce. 02:03:23.070 --> 02:03:28.510 Also du kannst deine Anfragen in Map-Reduce stellen und sie bieten sowas wie Stored Procedures heißt 02:03:28.510 --> 02:03:33.230 wahrscheinlich am ehesten in alten RDBMS-System im originalen RDBMS-System. 02:03:33.550 --> 02:03:38.030 Sie bieten dir an, Funktionen zu definieren und die auf dem Server auszuführen in JavaScript. 02:03:38.350 --> 02:03:39.470 Der ist eine Start-Procedure. 02:03:39.630 --> 02:03:44.510 Genau, also wenn du wenn du weißt, ich will all meine Daten manipulieren und eventuell willst du nicht alle 02:03:44.510 --> 02:03:47.230 Daten über deine Netzwerkleitung zu dir pushen und dann wieder raus, 02:03:47.390 --> 02:03:50.750 gerade wenn du zum Beispiel ein Produktionssystem hast, auf dem du das leider machen musst, 02:03:50.910 --> 02:03:55.230 dann willst du eventuell nicht sechs Terabyte oder 6 Gigabyte Daten über die Leitung schicken, 02:03:55.390 --> 02:03:57.630 bearbeiten und wieder zurückschicken, weil das dauert ewig. 02:03:57.790 --> 02:04:01.790 Kannst du in JavaScript, wenn du willst, gut, du kannst nämlich auf dem Server einfach was starten, 02:04:01.870 --> 02:04:04.590 aber du kannst auch in JavaScript eine Funktion hinschicken und sagen, 02:04:04.750 --> 02:04:08.590 mach mal das und dann benutzt der seine, was benutzt du denn Spider-Monkey oder? 02:04:08.750 --> 02:04:09.230 Spider-Monkey? 02:04:09.310 --> 02:04:15.230 Also die Mozilla-JavaScript-VM und jagt es dann einfach mal überall durch und dann kannst du da deine 02:04:15.310 --> 02:04:19.070 beliebigen Änderungen machen, was ganz interessant ist. 02:04:19.310 --> 02:04:22.590 Genau, also dieses Map-Reduce, was wir vorhin schon angesprochen hatten, 02:04:22.830 --> 02:04:27.230 da werden die Map- und die Reduce-Funktion da genauso in JavaScript definiert und es wird dann im Endeffekt 02:04:27.230 --> 02:04:33.950 auf dem Server ausgeführt und man kann damit sowas wie Joins bei relationalen Datenbanksystemen 02:04:33.950 --> 02:04:35.310 nachbauen mit Map-Reduce. 02:04:35.630 --> 02:04:41.710 Man muss halt auch überlegen, Joins sind so eine Sache, das gibt es viele in der MongoDB-Mailing-List, 02:04:41.790 --> 02:04:42.830 die übrigens auch super ist. 02:04:42.990 --> 02:04:46.350 Viele Leute kommen da so an und sagen, ja, wie würde ich denn jetzt eine Join-Implementierung? 02:04:46.430 --> 02:04:49.630 Und dann kommen die Leute so an, so, hast du dein Zeug etwa in Tabellen gespeichert? 02:04:49.710 --> 02:04:52.750 Und ja so, ja, das sind Dokumente hier, keine Tabellen. 02:04:52.910 --> 02:04:56.190 Das ist immer so eine Sache, du musst beim Schemadesign echt umdenken. 02:04:56.510 --> 02:05:00.990 Da gibt es auch wunderbare Webcasts von denen, Schemadesign mit MongoDB, 02:05:01.070 --> 02:05:04.750 super Präsentationen drüber, wie du deine Daten anordnen sollst. 02:05:04.830 --> 02:05:08.750 Der Sinn ist, all deine Daten sollten in einem, also wenn du, keine Ahnung, 02:05:08.910 --> 02:05:12.910 eine Person hast, dann sollte in der Person drinstehen, keine Ahnung, 02:05:13.150 --> 02:05:16.910 Geburtsort Stuttgart, steht in der Person drin, weil es sind Personendaten. 02:05:17.310 --> 02:05:21.070 Bei relationalen Systemen machst du es ja so, dass du das normalerweise halt eine weitere Tabelle hast, 02:05:21.230 --> 02:05:25.310 die alle Geburtsorte hat und noch eine Zwischentabelle, die die zwei verknüpft. 02:05:25.470 --> 02:05:27.870 Und das ist eben da nicht so, weil du echt Dokumente speicherst. 02:05:28.670 --> 02:05:33.310 Also man muss dann halt dazu sagen, die Informationen, die sind dann halt auch tatsächlich redundant 02:05:33.310 --> 02:05:33.630 verhalten. 02:05:33.950 --> 02:05:36.510 Also wenn man jetzt irgendwie mehrere Orte hat, wo Leute wohnen können, 02:05:36.590 --> 02:05:38.430 dann gibt es die halt in jedem Dokument. 02:05:38.830 --> 02:05:43.390 Aber heutzutage hat man dann immer so das Problem mit den Datenmengen. 02:05:43.550 --> 02:05:48.030 Gut, Problem ist halt, wenn man dann irgendwie rausfinden will, welche Leute wohnen dann alle. 02:05:48.350 --> 02:05:53.070 Ja, oder wenn man Änderungen in, also wenn sich zum Beispiel jetzt mal eine Postlehrzahl ändern würde, 02:05:53.150 --> 02:05:56.030 müsste man das halt in jedem Dokument tun und nicht nur in einer Tabelle. 02:05:56.270 --> 02:05:56.510 Richtig. 02:05:56.990 --> 02:05:58.510 Ich geb mir mal eine Liste aller Geburtsorte. 02:05:59.070 --> 02:06:00.430 Da kannst du eine Query machen, das geht ja. 02:06:00.510 --> 02:06:01.710 Du müsstest dann halt um das Performance. 02:06:02.590 --> 02:06:05.710 Du läufst ein Tablescan durch die gesamte Datenbank durch. 02:06:06.670 --> 02:06:08.910 Wenn man ein Index, wenn du eine P-Tree hast, dann hast du. 02:06:09.310 --> 02:06:11.230 Oder dann hast du wieder relational, letzten Endes. 02:06:11.470 --> 02:06:13.310 Nö, dann hast du nur einen Index über diesem Dingens. 02:06:13.470 --> 02:06:16.910 Das Schöne am Index ist ja alle Final, also bei dem B Plus-Baum, alle Keys, 02:06:17.150 --> 02:06:20.270 die im Grunde die finalen Dinger sind, stehen ganz unten im Baum drin. 02:06:20.430 --> 02:06:24.110 Bedeutet, der kann einfach alle Blätter abgrasen und hat alle Keys automatisch. 02:06:24.430 --> 02:06:28.350 Aber wie gesagt, man muss Indexe selber machen, das ist ein bisschen nervig teilweise. 02:06:28.670 --> 02:06:33.310 Der kombiniert die Indexe auch noch nicht so elegant wie relationale Datenbanken. 02:06:33.470 --> 02:06:38.430 Bedeutet, du kannst Composite-Indexe machen, bedeutet, du hast dann irgendwie Name, 02:06:38.670 --> 02:06:42.350 Alter Geburtsort und mit diesem Index kannst du aber blöderweise auch nur abfragen, 02:06:42.430 --> 02:06:45.950 gib mir alle Leute, die Jürgen heißen, älter als 25 sind aus Stuttgart. 02:06:46.030 --> 02:06:49.790 Nicht aber Jürgen heißen, aus Stuttgart sind und älter als 25. 02:06:49.950 --> 02:06:52.430 Da gibt es noch ein bisschen Probleme intern. 02:06:52.910 --> 02:06:56.590 Genau, also wenn man dann jetzt halt auch so sagt, okay, man legt jetzt einen Index fest, 02:06:56.990 --> 02:07:02.990 der irgendwie auf Name, Geburtsort und Alter geht, dann gilt der halt nicht nur für den Namen. 02:07:03.070 --> 02:07:04.990 Also für den Namen muss man dann halt wiederum extra. 02:07:05.230 --> 02:07:05.550 Doch, gilt? 02:07:05.710 --> 02:07:06.030 Ja, gilt. 02:07:06.110 --> 02:07:06.190 Okay. 02:07:06.270 --> 02:07:06.990 Haben sie geändert mal. 02:07:07.230 --> 02:07:08.270 Okay, dann hat sich das mittlerweile gemacht. 02:07:08.510 --> 02:07:09.950 Richtig, wie gesagt, sowas ändert sich. 02:07:10.030 --> 02:07:12.910 Und vielleicht noch so ein paar Namen, weil wir reden jetzt schon lange über MongoDB. 02:07:12.990 --> 02:07:17.150 Wer es noch einsetzt, Shutterfly, Foursquare, Bitly, SourceForge zum Beispiel, 02:07:17.230 --> 02:07:19.630 für die ganzen Projektpages und Downloadpages. 02:07:19.870 --> 02:07:25.550 Die New York Times benutzt es, Examiner.com, WordNick ist was großes, 02:07:25.630 --> 02:07:28.910 Share This, dieser typische Share This-Button, die alle in WordPress einbinden, 02:07:28.990 --> 02:07:33.150 wo du dann drüber gehst und dann sind irgendwie kommt so ein JavaScript-Pop-Up-Ding aufreddet und so. 02:07:33.230 --> 02:07:38.910 Die benutzen das, GitHub benutzt es, Collegehumor, Justin.tv, 02:07:39.790 --> 02:07:44.030 Discas zum Beispiel, SugarCare, M, Hashrocket, 02:07:44.190 --> 02:07:44.670 bla bla bla. 02:07:44.910 --> 02:07:45.310 Also viele. 02:07:45.630 --> 02:07:46.590 Ich glaube, da erkennt man ein Schema. 02:07:46.990 --> 02:07:49.070 Also die haben, die haben ja so eine Seite, da sind irgendwie, keine Ahnung, 02:07:49.150 --> 02:07:50.510 wahrscheinlich 100 Companies drin. 02:07:50.830 --> 02:07:53.870 Man kann es in Produktion schon einsetzen, man muss aber auch sich drum kümmern. 02:07:54.670 --> 02:07:59.630 Also gut, ich setze das jetzt halt in meinem Hobbyprojekt ein, weil ich habe da jetzt nicht irgendwie einen 02:07:59.630 --> 02:08:01.790 Manager, der mir vorgibt, was ich da jetzt einsetzen soll. 02:08:01.870 --> 02:08:04.590 Und dann kann man halt im Endeffekt, wenn dann mal was kaputt geht, 02:08:04.670 --> 02:08:10.670 ist man selber schuld und ja, aber durchaus ein nettes System und macht Spaß damit zu arbeiten. 02:08:10.830 --> 02:08:12.910 Vielleicht noch GridFS, man kann Dateien speichern drücken. 02:08:13.150 --> 02:08:13.470 Genau. 02:08:13.950 --> 02:08:16.590 Also jetzt gerade ein konkreter Anwendungsfall, wir programmieren ja hier, 02:08:16.670 --> 02:08:21.630 also Felix, der heute nicht da sein kann, wir programmieren ja da an Mediengewitter und was wir da in Zukunft 02:08:21.630 --> 02:08:26.750 tatsächlich planen, sind die Bild.de Punktde, ja, das wird demnächst auch wieder umbenannt und egal. 02:08:27.550 --> 02:08:32.990 Jedenfalls diese Bilder, die wir da ausliefern, die werden dann früher oder später auch mal in MongoDB, 02:08:33.070 --> 02:08:39.630 in einem GridFS abgespeichert, sodass wir die direkt mit Metadaten in der Datenbank verknüpfen können. 02:08:39.710 --> 02:08:46.030 Das heißt, ich sage mir, sag der Datenbank, hey, hol mir mal dieses Bild mit diesen Dateinamen raus und dann 02:08:46.030 --> 02:08:50.590 hängen da in einem weiteren Dokument, was an dem Bild dranhängt, schon die Metadaten dran und wir müssen die 02:08:50.590 --> 02:08:55.550 nicht erst noch aufwendig verknüpfen, sondern wir können die einfach so direkt aus der Datenbank rausziehen 02:08:55.870 --> 02:09:01.230 und haben da vor allem auch keine Probleme mit irgendwie Zugriffsrechten auf Dateisystemebene oder keine 02:09:01.230 --> 02:09:07.310 Probleme mehr, wenn wir, sagen wir mal, eine hohe Last haben und die Datenbank auf einen extra Server 02:09:07.310 --> 02:09:12.190 verlagern müssen, dann haben wir da halt auch keine Probleme mit, weil wir die Bilder so oder so aus dieser 02:09:12.190 --> 02:09:17.550 Datenbank rausholen und dann von mehreren Application-Servern darauf auch theoretisch zugreifen können. 02:09:17.710 --> 02:09:20.990 Da vielleicht noch die Anmerkung des Byson das verwenden. 02:09:21.230 --> 02:09:24.430 Das ist jetzt nicht nur JSON, sondern die haben da auch Sachen wie zum Beispiel Binärdaten. 02:09:24.510 --> 02:09:28.190 Deswegen können die, du kannst also, wenn du eine Person hast, kannst du da ein Bild in die Datenbank 02:09:28.190 --> 02:09:28.670 reinmachen. 02:09:28.830 --> 02:09:33.390 Nicht irgendwie extra halten, sondern die können es effizient binär kodieren oder nicht als Base64 oder so 02:09:33.390 --> 02:09:36.670 einen Gefrickel, sondern echt binär in der Datenbank, braucht nicht so viel Platz. 02:09:36.910 --> 02:09:41.390 Und sie können auch zum Beispiel Sachen wie ein Datum. 02:09:41.550 --> 02:09:44.190 Soweit ich weiß, JSON hat kein Konzept von Datumsfeldern. 02:09:44.350 --> 02:09:49.150 Kannst ein Timestampers Integer oder so, aber die haben ein Datum, wo sie auch Operationen elegant drauf 02:09:49.230 --> 02:09:49.630 machen können. 02:09:49.790 --> 02:09:54.750 Also es gibt in JavaScript bei JSON diesen ISO-String. 02:09:54.910 --> 02:09:57.790 Also es gibt da irgendwie eine ISO-Definition, wie man ein Datum repräsentiert, 02:09:57.870 --> 02:10:01.710 aber das ist intern gesehen auch nur ein String, der dann wieder gepasst werden muss. 02:10:01.870 --> 02:10:03.230 Richtig, und die machen das halt schnell gut. 02:10:03.710 --> 02:10:07.870 Ja, MongoDB, lustige Sache, lohnt sich auf jeden Fall, das würde ich also auch so jedem empfehlen, 02:10:07.950 --> 02:10:12.750 der einfach was Schnelles haben will, was immer noch einfach ist und aber doch noch sehr generisch einsetzbar. 02:10:12.830 --> 02:10:14.510 Vielleicht so die Einstiegsdroge, sag ich mal. 02:10:14.750 --> 02:10:16.670 Die Einstiegsdroge von NoSQL, genau. 02:10:17.230 --> 02:10:20.590 Und auch vielleicht, wenn man bis jetzt nur mit relationalen Datenbanken gearbeitet hat, 02:10:20.670 --> 02:10:23.950 kann man da eigentlich auch relativ viel von dem Wissen, was man da gesammelt hat, 02:10:24.030 --> 02:10:24.910 auch wiederverwenden. 02:10:25.150 --> 02:10:25.310 Ja. 02:10:25.790 --> 02:10:26.270 So ein bisschen. 02:10:26.510 --> 02:10:28.590 Auch eine super Doku, also echt beste Doku von allen. 02:10:29.310 --> 02:10:30.190 Dokumentation ist gut. 02:10:30.270 --> 02:10:35.310 Es gibt auch noch ein Wiki, wo dann noch so Kochrezepte für bestimmte Problemlösungen mit beschrieben sind. 02:10:35.630 --> 02:10:36.830 Kann man sich auch angucken. 02:10:38.430 --> 02:10:38.670 Gutes. 02:10:39.070 --> 02:10:45.470 Dann genau, einen, den man wahrscheinlich auch schon öfter gehört hat, Couch.db, auch so ein Document Store. 02:10:45.710 --> 02:10:46.430 Ja, ja, ja. 02:10:46.830 --> 02:10:47.870 Document Key Value. 02:10:48.750 --> 02:10:49.870 Kann man sich durchstreiten. 02:10:50.110 --> 02:10:51.470 Mit MapReduce auf jeden Fall. 02:10:51.710 --> 02:10:52.510 Mit MapReduce. 02:10:53.550 --> 02:10:53.950 Genau. 02:10:54.350 --> 02:10:57.070 Also vielleicht zur Klarifizierung, warum ich so komisch mache. 02:10:57.310 --> 02:11:00.590 CouchDB speichert Daten als JSON-String intern. 02:11:00.830 --> 02:11:04.510 Das Gute ist, CouchDB versteht JSON intern. 02:11:05.310 --> 02:11:06.510 Man kann sich drum streiten. 02:11:06.590 --> 02:11:10.910 Im Grunde gibt er den nur einen, ja, also es wird als Textstring gespeichert, 02:11:10.990 --> 02:11:14.430 was nicht die effizienteste Art der Speicherung ist, soweit ich weiß, 02:11:14.590 --> 02:11:16.110 aber würde ich behaupten. 02:11:16.350 --> 02:11:19.790 Aber CouchDB versteht JSON-nativ, kann also auch auf den Daten operieren. 02:11:20.030 --> 02:11:26.830 Also sagt man es mal so, Unterschied zu MongoDB, was tatsächlich intern diese Daten schon versteht, 02:11:27.310 --> 02:11:31.790 macht Couch.db folgendes, es speichert einen String in der Datenbank und wenn es dann, 02:11:32.030 --> 02:11:36.110 wenn dann dieser String irgendwie verarbeitet oder interpretiert werden soll, 02:11:36.750 --> 02:11:42.350 lädt er sich den String aus seinem Store und führt den oder parst den mit Hilfe der integrierten 02:11:42.350 --> 02:11:44.030 JavaScript-Runtime, die die mit drin haben. 02:11:44.270 --> 02:11:45.230 Auch ein Spider-Monkey. 02:11:45.630 --> 02:11:48.910 Oder es gibt auch schon so eine Möglichkeit, V8 reinzukompilieren von Google, 02:11:48.990 --> 02:11:50.670 aber also Spider-Monkey ist die offizielle. 02:11:51.390 --> 02:11:52.670 Richtig, CoachDP. 02:11:52.750 --> 02:11:53.950 Ist so ein HTTP. 02:11:54.110 --> 02:11:55.150 Die machen alles HTTP. 02:11:55.470 --> 02:11:55.950 Genau, das ist doch gut. 02:11:56.110 --> 02:11:56.990 Jeder spricht HTTP. 02:11:57.230 --> 02:12:00.830 Genau, MongoDB übrigens war so auch so ein binäres Protokoll, also nicht stressed oder so, 02:12:00.910 --> 02:12:07.710 sondern wie gesagt, die verwenden eigentlich dieses Beason in Binärrepräsentation auch über die Leitung 02:12:08.190 --> 02:12:10.910 mit ein bisschen Management-Zeug außenrum. 02:12:11.070 --> 02:12:15.310 Aber eigentlich ist das relativ plain, das Format, was die halt auch intern der Daten machen. 02:12:15.550 --> 02:12:19.870 Genau, aber also CouchDB ist so relax, it's CouchDB oder so. 02:12:19.950 --> 02:12:20.990 Also kennt man. 02:12:21.070 --> 02:12:23.390 Es ist ein HTTP-Get-Request, wenn du Daten willst. 02:12:24.270 --> 02:12:26.510 Und dann dadurch lässt sich es jeder Programmiersprache ansprechen, 02:12:27.070 --> 02:12:30.590 weil HTTP-Bibliotheken gibt es eigentlich so für so ziemlich alles. 02:12:30.910 --> 02:12:34.750 Da kannst du sogar Cobold benutzen wahrscheinlich und einfach mal auf deine CouchTB zugreifen. 02:12:34.910 --> 02:12:39.390 Ja, und das Schöne ist halt auch, wenn man HTTP benutzt, kann man halt auch auf die HTTP-Infrastruktur, 02:12:39.470 --> 02:12:40.910 die man so kennt, zurückgreifen. 02:12:40.990 --> 02:12:43.630 Man kann da irgendwie ein Caching-Proxy zum Beispiel davor setzen. 02:12:43.870 --> 02:12:50.190 Oder man kann den Load Balancer davor setzen, der einem dann im Endeffekt Anfragen auf diverse Server routet. 02:12:50.350 --> 02:12:52.830 Richtig, Master-Master-Replikationen können die nämlich super. 02:12:53.070 --> 02:12:53.390 Genau. 02:12:53.550 --> 02:12:55.390 Also da sind sie echt groß drin. 02:12:56.430 --> 02:13:03.070 Was es tatsächlich auch gibt, sind dann so mal so Ansätze, sowas für Desktop-PCs zu 02:13:03.070 --> 02:13:08.350 installieren und dann praktisch mit einem Master im Internet zu replizieren. 02:13:08.510 --> 02:13:13.710 So dass man jetzt zum Beispiel bestimmte Informationen, die man unterwegs dabei haben will, 02:13:13.790 --> 02:13:15.550 einfach immer auf seinem Laptop hat. 02:13:15.790 --> 02:13:18.350 Und wenn man dann mal Internet hat, dann kann der das auch synchronisieren. 02:13:18.590 --> 02:13:20.990 Ubuntu One zum Beispiel macht das, soweit ich weiß. 02:13:21.710 --> 02:13:26.430 Genau, das macht auch Lotus Notes und der Chefentwickler von Crouch.tb ist ein Cheftentwickler von Nodes 02:13:26.430 --> 02:13:26.670 gewesen. 02:13:26.830 --> 02:13:31.390 Genau, der hat mal lange Zeit bei IBM gearbeitet und hat da an dem Backend für Lotus Nodes gearbeitet und 02:13:31.390 --> 02:13:34.590 wollte dann was Eigenes machen, hat sich dann, glaube ich, mal so ein Ja-Urlaub genommen. 02:13:34.670 --> 02:13:35.710 Ja, das ist das ganze Internet. 02:13:35.870 --> 02:13:39.390 Oder beziehungsweise hat seine ganzen Ersparnisse geopfert und hat dann angefangen, 02:13:39.470 --> 02:13:40.590 dieses System zu implementieren. 02:13:40.670 --> 02:13:46.430 Erst in C ⁇ , hat dann gemerkt, oh, funktioniert nicht so ganz, und hat das Ganze dann nochmal in Erlang, 02:13:46.510 --> 02:13:49.470 hat Erlangen gelernt und hat dann im Endeffekt das Ganze in Erlangen neu geschrieben. 02:13:49.710 --> 02:13:52.830 War auch, ich glaube, er wollte zuerst irgendwie ein verteiltes Dateisystem implementieren, 02:13:52.990 --> 02:13:56.270 so Cross-Plattformen, hat aber rausgefunden, dass es in der Windows total krätzig ist und hat sich gedacht, 02:13:56.350 --> 02:13:57.630 nee, mach mal eine Datenbank. 02:13:57.790 --> 02:14:03.950 Und Damien Katz ist der Entwickler mit Katz, der da sehr viel Passion hat und auch Erlang irgendwie in einer 02:14:03.950 --> 02:14:06.670 Woche Erlang genannt hat und da Supercode raushaut. 02:14:06.750 --> 02:14:07.790 Das ist also ganz, ganz krass. 02:14:08.030 --> 02:14:14.350 Also der ist auch total begeistert dabei und später ist dann wieder IBM auf ihn zugegekommen und hat gefragt, 02:14:14.430 --> 02:14:18.030 hat dann so nachgefragt, ob sie denn das Projekt sponsern können. 02:14:18.350 --> 02:14:24.590 Und dann hat er gemeint, ja, wenn wir es denn unter die Apache-Lizenz stellen und das ist jetzt seit seit ein 02:14:24.590 --> 02:14:30.910 paar Monaten ist das jetzt ein offizielles Apache-Projekt und war vorher ein Apache Incubator-Projekt. 02:14:31.070 --> 02:14:31.390 Genau. 02:14:32.030 --> 02:14:34.910 Vielleicht eine Sache, die es ja Incubator heißt in dem Zusammenhang, 02:14:34.990 --> 02:14:36.270 dass es erst geprüft wird, ob es kurz ist. 02:14:36.350 --> 02:14:38.830 Ja, genau, ob es länger existiert, ob es genügend Entwickler sind. 02:14:38.910 --> 02:14:42.830 Und ein Bootcamp quasi, wo sie auch beigebracht kriegen, was Apache denn überhaupt bedeutet, die macht. 02:14:43.150 --> 02:14:48.110 Also wenn man jetzt ein Projekt als Apache-Projekt anmelden will, 02:14:48.430 --> 02:14:51.470 dann hat man erst so eine Incubator-Phase, wo dann erst nachgeguckt wird, 02:14:51.550 --> 02:14:55.710 ob das ganze Projekt läuft, ob das weiterkommt, ob die ganzen Entwickler dabei bleiben und so weiter. 02:14:55.950 --> 02:14:59.790 Und wenn sich das dann alles bewährt hat, dann wird es ein offizielles Apache-Projekt. 02:15:00.030 --> 02:15:05.230 Was CouchDB sehr interessant macht, ist die Art, wie sie Daten bereitstellen, 02:15:05.390 --> 02:15:07.230 die, ich sag mal, aufbereitet sind. 02:15:07.310 --> 02:15:09.870 Wir kennen das ja aus normalen Datenmarken, da gibt es ja auch Views. 02:15:10.110 --> 02:15:15.150 Ein View ist ja quasi nur, man sagt, so ein Kochrezept, ich hätte gerne meine Daten so und so dargestellt. 02:15:15.310 --> 02:15:19.390 Folgendes Feld soll daher kommen, folgendes Feld soll daher kommen und dann baust du das quasi zusammen. 02:15:19.630 --> 02:15:23.230 Und Couch.db benutzt intern sehr viel Map-Reduce. 02:15:23.710 --> 02:15:27.950 Wie wir vorher schon erwähnt haben, was MapReduce ist, CouchDB benutzt es dazu, 02:15:28.510 --> 02:15:30.910 um diese Views zu generieren. 02:15:30.990 --> 02:15:35.070 Und das Schöne ist, da dieses Map-Reduce ja eine atomare Operation ist, 02:15:35.550 --> 02:15:40.990 kannst du jedes Mal, wenn ein Dokument hinzukommt, einfach für dieses Dokument diesen Map-Reduce-Vorgang 02:15:40.990 --> 02:15:44.910 ausführen und kannst es quasi zu deinem Ergebnis hinzuaddieren. 02:15:45.150 --> 02:15:49.070 Bedeutet, du hast da Views, die automatisch konsistent sind. 02:15:49.310 --> 02:15:55.390 Bedeutet du, wenn du weißt, wie deine Daten aussehen sollen, also was du aus deinen Daten rausholen willst, 02:15:55.630 --> 02:15:58.110 sagst du einfach, machst du ein Design-Dokument, sagst, das ist mein Map, 02:15:58.190 --> 02:16:01.790 das ist mein Reduce und zusammen soll dieser View heißen, irgendwie, 02:16:02.030 --> 02:16:05.710 wie viele User haben diesen Monat meinen Blog besucht oder so. 02:16:05.790 --> 02:16:07.310 Also was ganz einfaches. 02:16:07.470 --> 02:16:12.110 Und jedes Mal, wenn du dann per HTTP Get auf diesen View zugreifst, 02:16:12.830 --> 02:16:17.390 weiß der, aha, das letzte Mal, also CouchDB hat auch so einen Append-Only-Ansatz, 02:16:17.470 --> 02:16:20.350 bedeutet, der weiß dann, das letzte Mal, als mir auf jemanden auf mich zugegriffen hat, 02:16:20.430 --> 02:16:21.950 das war irgendwie bei Revision 6000. 02:16:22.110 --> 02:16:26.910 Ich bin jetzt bei 7000, bedeutet, ich nehme alle von 6 bis 7.000, jag die durch Map-Reduce durch, 02:16:27.070 --> 02:16:30.190 habe einen aktualisierten View, du kannst es natürlich auch irgendwie automatisiert machen, 02:16:30.270 --> 02:16:33.070 sagst dann alle 100 Änderungen machst das oder so. 02:16:33.550 --> 02:16:38.030 Auf jeden Fall bietet CouchDB da die Möglichkeit, Views, beliebige Views eigentlich, 02:16:38.110 --> 02:16:41.710 die du zusammenbaust, wie du willst, persistent zu halten. 02:16:41.870 --> 02:16:45.950 Und du hast quasi keinerlei Overhead, um auf die Views zuzugreifen. 02:16:46.030 --> 02:16:50.110 Du hast nur einmal Overhead beim Insert, also jeder Insert aktualisiert halt deinen View, 02:16:50.270 --> 02:16:53.150 bedeutet viele Views, gehen auch langsam auf die Insert-Performance, 02:16:53.470 --> 02:16:58.990 aber da ist CouchDB eh recht schnell und ist eine recht nette Sache. 02:16:59.070 --> 02:17:03.070 Du kannst natürlich auch live die MapReduce-Task laufen lassen, dann dauert es halt eine Weile. 02:17:03.870 --> 02:17:07.070 Ja, das ist so eine ganz geschickte Sache. 02:17:07.710 --> 02:17:08.910 Auch in JavaScript übrigens. 02:17:09.230 --> 02:17:10.430 JavaScript oder Erlang. 02:17:10.750 --> 02:17:12.670 Also das ist auch zum ersten Mal, als ich da Erlangen geschrieben habe, 02:17:12.830 --> 02:17:17.550 MapReduce in Couch.db und die bieten, ja, sind ganz nette Leute eigentlich, 02:17:17.710 --> 02:17:20.030 auch IRC, recht große Community. 02:17:21.390 --> 02:17:23.470 Und das ist so eine interessante Sache. 02:17:23.630 --> 02:17:27.310 Was cool bei CouchDB ist, ich weiß nicht, Futon hat da jemand von euch mal mit rumgespielt? 02:17:28.110 --> 02:17:30.190 Das ist so ein Framework für Couch Apps, oder? 02:17:30.270 --> 02:17:34.190 Äh, nee, Futon ist die Administrationsoberfläche. 02:17:34.510 --> 02:17:39.870 Es auch läuft in Couch.db, das ist ja das Coole in CouchDB, dass du Sachen in Couch.db hosten kannst. 02:17:39.950 --> 02:17:46.110 Du kannst da per HTTP drauf zugreifen und die machen das komplette JavaScript ein HTML halt. 02:17:46.270 --> 02:17:50.510 Bedeutet, du bekommst HTML raus, dann läuft ein bisschen JavaScript und das ist ein echt schickes 02:17:50.510 --> 02:17:51.230 Admin-Interface. 02:17:51.310 --> 02:17:55.470 Vergleichbar mit PHP MySQL-Admin-Dingens. 02:17:55.630 --> 02:17:56.350 PHP MyAdmin. 02:17:56.510 --> 02:18:00.590 PHP MyAdmin so für MySQL, liefern die das halt auch mit. 02:18:00.670 --> 02:18:03.790 Da kannst du dann so Sachen sagen wie du kannst schauen, ob deine Replikation noch läuft, 02:18:03.950 --> 02:18:09.150 du kannst irgendwie ein Compact starten, das ist das Einzige, was ein bisschen an CouchDB nervt. 02:18:09.230 --> 02:18:13.070 Da der dieses Append-Ony-Zeug macht, hängt der immer Sachen hinten dran. 02:18:13.230 --> 02:18:18.270 Bedeutet, wenn du was löschst, dann nimmt ihr das einfach irgendwo vorne aus seinem Inhaltsverzeichnis raus, 02:18:18.350 --> 02:18:22.510 aber die Daten sind bei dir immer noch auf der Platte, bis das jemand defragmentiert quasi und aufräumt. 02:18:23.150 --> 02:18:26.030 Das war so der Grund, warum ich CouchDB leider nicht weiternehmen konnte, 02:18:26.110 --> 02:18:29.950 weil ich habe so schnell da Daten reingeschrieben, dass diese lahme virtualisierte I.O. 02:18:30.110 --> 02:18:32.270 auf Amazon nicht mehr nachkam mit Kompacten. 02:18:32.670 --> 02:18:36.430 Oder so am Tag war es dann 30 GB, am nächsten 40, und ich so, okay, 02:18:36.510 --> 02:18:40.510 Compact, am nächsten 50 und Compact ist bei 10%, am nächsten 60 GB, 02:18:40.830 --> 02:18:42.430 Compact ist bei 20 Prozent. 02:18:42.670 --> 02:18:43.630 Der kam nicht mehr nach. 02:18:43.710 --> 02:18:45.470 Das ist so ein bisschen eine nervige Geschichte. 02:18:45.950 --> 02:18:47.870 Kann man wahrscheinlich auch schaden und verteilen und so weiter. 02:18:48.030 --> 02:18:51.950 Ja, dieses Kompacten, das Problem ist halt, wenn man so ein Append-Ony-Log schreibt, 02:18:52.030 --> 02:18:54.510 da werden dann natürlich auch Löschvorgänge reingeschrieben. 02:18:54.670 --> 02:18:58.750 Und das heißt, es kann jetzt sein, ich habe einen Datenbank, äh einen Datensatz, 02:18:58.830 --> 02:19:04.110 den habe ich einmal in die Datenbank reingeschrieben, habe den zehnmal geändert und dann wieder gelöscht. 02:19:04.350 --> 02:19:09.550 Und dann ist der halt immer noch, also dieses Eintragen, 02:19:09.630 --> 02:19:13.950 dieses Ändern und die und zusätzlich noch dieses Löschen ist dann halt immer noch in diesem Append-Ony-Log 02:19:14.030 --> 02:19:14.110 drin. 02:19:14.510 --> 02:19:16.030 Das heißt, zehnmal der komplette Datensatz. 02:19:16.430 --> 02:19:21.790 Genau, und dieses Compacten macht im Endeffekt nichts anderes als diese Einträge von Datensätzen, 02:19:21.870 --> 02:19:25.550 die so oder so nicht mehr existieren oder irgendwelche Operationen, 02:19:25.630 --> 02:19:29.230 die schon lange wieder hinfällig sind, einfach zu entfernen. 02:19:29.470 --> 02:19:32.990 Das coole ist auch, du hast eine Versionierung eingebaut, nicht als Versionierung benutzen. 02:19:33.070 --> 02:19:37.470 Also praktisch gesehen ist es eine, aber die Code-CB-Invictor sagen, könnte sich jederzeit ändern. 02:19:37.630 --> 02:19:41.310 Aber also so, du kannst zumindest nachschauen, wenn da irgendwas zerfetzt hat, 02:19:41.390 --> 02:19:43.950 was waren das letzte Versionen von dem Dokument. 02:19:44.110 --> 02:19:46.590 Und kannst es aktuell sogar noch wiederherstellen, aber. 02:19:46.910 --> 02:19:49.390 Aber das ärgerliche ist halt die Synchronisation und die Recovery. 02:19:49.710 --> 02:19:53.870 Wenn das Ding einmal ausgefallen ist, dann stellt es den Datensatz halt auch wieder viermal her. 02:19:54.750 --> 02:19:57.390 Ja, das läuft das ganze Lock durch von vorne bis hinten. 02:19:58.270 --> 02:20:00.830 Nein, ich glaube, die haben mehr so eine, die haben ein Inhaltsverzeichnis, 02:20:00.990 --> 02:20:02.670 das dann halt auf die entsprechende Stelle verweist. 02:20:02.750 --> 02:20:09.630 Der sagt dann halt, aktuell ist Revision 6000 und 20 Mal zwischendurch geändert und zum Schluss 02:20:09.630 --> 02:20:12.110 gelöscht, dann wird es halt beim Replay 20 mal geändert und zum Beispiel. 02:20:12.350 --> 02:20:14.030 Ja, es gibt kein Replay bei dem Ganzen. 02:20:14.810 --> 02:20:16.570 Bleibt so auf der Platte, das ist das Komische. 02:20:16.650 --> 02:20:19.690 Also, die haben einen atomaren Index, soweit ich das weiß. 02:20:19.770 --> 02:20:25.290 Und die sagen dann halt, keine Ahnung, Paul Müller, der Datensatz, der befindet sich gerade an Position 6000. 02:20:25.450 --> 02:20:26.250 Es ist eine Datei. 02:20:26.410 --> 02:20:31.930 Bedeutet, er kann einfach den F-Seek angeben, also die Position, den Offset. 02:20:32.410 --> 02:20:37.530 Und wenn du das änderst, dann schreibt er das hinten ran und die atomare Operation ist dann einfach diesen 02:20:37.530 --> 02:20:38.250 Link umzubiegen. 02:20:38.330 --> 02:20:38.970 Ah, verstehe. 02:20:39.050 --> 02:20:39.210 Okay. 02:20:39.530 --> 02:20:41.690 Und bedeutet, der hat immer die aktuelle Version. 02:20:41.770 --> 02:20:44.890 Das Schlimmste, was passieren kann, ist, du verlierst den letzten Eintrag. 02:20:45.050 --> 02:20:46.330 Das ist das Geile an dem Ganzen. 02:20:46.490 --> 02:20:51.210 Nämlich, wenn er was auf die Platte schreibt, aber nicht mehr diesen atomaren Inhaltsverzeichnis um Kopiererei 02:20:51.210 --> 02:20:54.970 macht, dann hast du diesen Eintrag verloren, aber alles andere ist immer konsistent. 02:20:55.210 --> 02:21:01.930 Ist eine super Sache, also dass keinerlei inkonsistente Daten, kein FSCK oder wie es MyICE macht, 02:21:02.010 --> 02:21:04.810 wo es dann halt ewig durchrödelt am Anfang nach einem Crash. 02:21:05.610 --> 02:21:07.050 Das ist eine ganz coole Sache. 02:21:07.210 --> 02:21:10.090 Das Geile ist, Backups, du kannst alles einfach wegkopieren. 02:21:10.250 --> 02:21:14.570 Ist ja völlig egal, du ist ja nur ein Filsystem-Snapshot oder Filsystem-Snapshots gehen zum Beispiel auch, 02:21:14.650 --> 02:21:18.490 wenn du ZFS hast oder auf Amazon S3 bietet Snapshots an. 02:21:18.650 --> 02:21:23.050 Du kannst zu jedem Zeitpunkt ein Snapshot, genau, LVM, du kannst zu jedem Zeitpunkt ein Snapshot machen und 02:21:23.050 --> 02:21:24.890 hast eine konsistente Version von deinen Daten. 02:21:25.290 --> 02:21:27.690 Immer, die sind auch recht billig dadurch quasi. 02:21:29.130 --> 02:21:30.330 Ist alles recht simpel. 02:21:30.410 --> 02:21:32.810 Also Backup einfach wegkopieren, nicht viel machen. 02:21:32.890 --> 02:21:36.570 Deswegen, das versuchen sie so ein bisschen zur Simplizität. 02:21:37.050 --> 02:21:42.570 Und Master Slave-Replikation soll wohl auch Master Master auch. 02:21:42.730 --> 02:21:43.290 Master Master Master. 02:21:44.730 --> 02:21:46.570 Bei Replikationen soll das Ding wohl auch ganz gut gehen. 02:21:46.730 --> 02:21:46.970 Genau. 02:21:47.050 --> 02:21:50.570 Und was eine Sache noch vielleicht am Ende ist nette ist, sie haben einen Changes-Feed. 02:21:50.650 --> 02:21:54.890 Bedeutet, sie haben eine Möglichkeit, sich quasi in die Replikation reinzuhängen und mitzukriegen, 02:21:54.970 --> 02:21:56.170 sobald eine Änderung kommt. 02:21:56.250 --> 02:22:02.090 Da gibt es so Sachen wie Elasticsearch, ist so eine Volltext-Suche oder es gibt irgendwie Couch Lucine, 02:22:02.330 --> 02:22:05.290 Lucine auf CouchDB, Lucine ist auch so ein Volltext-Suchdienst. 02:22:05.690 --> 02:22:06.490 Auch ein Apache-Projekt? 02:22:06.650 --> 02:22:07.850 Ja, auch ein Apache-Projekt. 02:22:08.010 --> 02:22:12.970 Die können sich da quasi, also Elasticsearch zumindest kannst du in diesen Changes-Feed ranhängen und dann 02:22:12.970 --> 02:22:16.010 quasi als Replikationspartner auftreten. 02:22:16.170 --> 02:22:20.010 Und du kannst dann quasi jede Änderung live an deine Suchengine weitergeben. 02:22:20.170 --> 02:22:23.690 CouchDB selber kannst zwar über Map Reduce machen und kann auch Views machen, 02:22:23.770 --> 02:22:27.450 aber wenn du halt wirklich Add-hoc-Querys willst, dann bist du besser beraten, 02:22:27.530 --> 02:22:31.050 irgendwas zu nehmen, wie zum Beispiel Lucine, das da echt für spezialisiert ist. 02:22:31.370 --> 02:22:36.650 Und du hängst dir in den Changes-Feed ran, der normalerweise für Replikation gedacht ist, 02:22:36.730 --> 02:22:40.570 und kriegst alle Änderungen sofort live in dein Suchsystem rein und kannst dann quasi, 02:22:40.650 --> 02:22:44.650 obwohl CouchDB selber keine Suche bietet, recht leicht eine Suche aufschalten. 02:22:44.890 --> 02:22:46.890 Was eine ganz angenehme Sache ist eigentlich. 02:22:46.970 --> 02:22:48.570 Also es ist echt ein schickes Konzept. 02:22:48.730 --> 02:22:52.090 Kannst dann auch deinen Suchserver irgendwo anders machen, der muss dann nicht auf dem selben System sein. 02:22:52.170 --> 02:22:55.050 Das bedeutet, deine Datenbank und deine Suche sind völlig unterschiedlich. 02:22:55.130 --> 02:22:58.890 Du kannst deine Datenbank abschalten und neu starten und deine Suche funktioniert immer noch. 02:22:58.970 --> 02:23:00.330 Das ist eine ganz coole Sache. 02:23:01.850 --> 02:23:03.770 Okay, kommen wir zum nächsten oder? 02:23:04.170 --> 02:23:05.770 Dann hat der CouchCaps schon angesprochen. 02:23:05.850 --> 02:23:06.650 Achso, ups, CouchCaps. 02:23:06.890 --> 02:23:07.290 Ja gut, dann ist es ja auch. 02:23:08.330 --> 02:23:10.010 Ich meine, ergibt sich eigentlich, man hat irgendwie. 02:23:11.370 --> 02:23:15.290 Man hat eine Web-Schnittstelle und man kann da drauf mit JavaScript drauf zugreifen, 02:23:15.370 --> 02:23:20.730 da bietet es sich einfach an, dass man auch komplette Applikationen im Browser laufen lässt, 02:23:20.810 --> 02:23:26.170 die dann diese, also in JavaScript, die dann diese Schnittstelle, diese HTTP-Schnittstelle nutzen, 02:23:26.250 --> 02:23:27.210 um an ihre Daten zu kommen. 02:23:27.290 --> 02:23:33.050 Genau, CouchGB ist auch dein Web-Server, ist ein Erlangen geschriebener Mopsy-Web, Mopsy-Web, keine Ahnung. 02:23:33.210 --> 02:23:38.410 Ist ein Erlangen-Web-Server, der auch sehr, sehr elegant per EPO und so, also es skaliert auch super. 02:23:38.650 --> 02:23:40.970 Kannst dir sogar recht viel Hits mit wegstecken und. 02:23:41.370 --> 02:23:43.370 Ich glaube, Oracle hat ja auch mal so ein ähnliches. 02:23:43.770 --> 02:23:44.490 Ja, halt richtig. 02:23:45.210 --> 02:23:47.770 HTML-DB, ich glaube, später hieß es, muss ich mal nachgucken. 02:23:47.930 --> 02:23:50.730 Ja, da haben sie auch Datenbanken, also HTML direkt von der Datenbank. 02:23:51.050 --> 02:23:51.770 Genau, Apex. 02:23:52.570 --> 02:23:52.970 Richtig. 02:23:53.050 --> 02:23:54.010 Und das ist nett. 02:23:54.090 --> 02:23:55.850 Es gibt einen Blog oder so, Blogging-Engine. 02:23:55.930 --> 02:23:59.130 Also nichts Großes bisher, aber es ist eine nette Spielerei, weil du halt echt, 02:23:59.210 --> 02:24:03.130 du bist nur HTML und JavaScript und das kann dein Browser und dann brauchst du keinen Web-Server und keine 02:24:03.130 --> 02:24:05.770 Datenbank und keine Anwendungen, sondern alles da drin quasi. 02:24:05.930 --> 02:24:11.450 Ja, oder andersrum, man hat eigentlich nur eine Datenbank und da ist der Webserver schon mit drin. 02:24:12.410 --> 02:24:17.290 Ja, ist halt auch alles Rest, also mit Put-Post, Get-Delete, nicht nur dieses typische Get und Post, 02:24:17.370 --> 02:24:18.650 sondern auch irgendwie alles. 02:24:18.890 --> 02:24:19.130 Alles. 02:24:19.370 --> 02:24:20.010 VolksTB. 02:24:20.170 --> 02:24:21.850 Nächstes wäre ein Key-Value-Store, glaube ich. 02:24:22.250 --> 02:24:27.610 Genau, jetzt kommen wir zu den Key-Value-Stores und ich würde sagen React und React ist, 02:24:27.690 --> 02:24:28.970 glaube ich, von Bashau, ne? 02:24:29.130 --> 02:24:29.450 Richtig? 02:24:30.650 --> 02:24:34.970 Auch so eine Firma, aber die machen auch ein Open Source Produkt. 02:24:35.610 --> 02:24:37.210 Also das ist Reag. 02:24:38.090 --> 02:24:41.770 Bieten natürlich auch ringsrum so ein paar kommerzielle Varianten davon an, 02:24:41.930 --> 02:24:45.930 noch so eine Enterprise, so ähnlich wie das MySQL, ja auch mal gemacht hat, 02:24:46.010 --> 02:24:49.210 immer noch macht so irgendwie. 02:24:50.330 --> 02:24:52.490 Ja, Key Value Store, Reak. 02:24:52.810 --> 02:24:53.130 Richtig. 02:24:53.610 --> 02:24:54.010 Soll ich wieder? 02:24:55.610 --> 02:24:56.330 Ich habe viel Reak. 02:24:56.730 --> 02:24:57.850 Du hast viel Reak gemacht, ja. 02:24:58.250 --> 02:24:59.850 Wie gesagt, du hast sie alle mal durchgetestet. 02:25:01.050 --> 02:25:05.290 Ich habe so eine Thesis geschrieben, ich skaliere auch noch Crawlerbout und da musste ich mir alle anschauen, 02:25:05.370 --> 02:25:06.570 deswegen rede ich so viel. 02:25:07.130 --> 02:25:08.730 Deswegen haben wir dich eingeladen im Übrigen. 02:25:09.050 --> 02:25:09.610 Super. 02:25:10.250 --> 02:25:14.330 Genau, React ist basiert auf Amazon Dynamo, ist also ein Key-Value, 02:25:14.570 --> 02:25:19.770 also wird so quasi eine Open Source Implementierung Plus Plus, also ein bisschen mehr steckt dahinter. 02:25:20.010 --> 02:25:24.090 Ist ein Key-Value-Store-Reiner, bietet euch also nicht die Möglichkeit, 02:25:24.410 --> 02:25:29.370 so Sachen zu machen wie, keine Ahnung, erhöht mal einen Counter oder sowas in der Art. 02:25:30.170 --> 02:25:33.690 Was React aber super macht, ist echt die Skalierung. 02:25:33.850 --> 02:25:37.050 React ist echt ähnlich wie Cassandra vom Prinzip. 02:25:37.210 --> 02:25:41.690 Neue Node anmachen, sagen, da sind deine Kumpels, geht danach alles völlig automatisch, 02:25:41.770 --> 02:25:48.330 wenn du bei Cassandra noch irgendwie Java-typisch irgendwie eine Million Zeilen XML konfigurieren muss. 02:25:48.890 --> 02:25:52.330 Java ist ja eigentlich eine Sprache, die XML in Stack Traces umwandelt. 02:25:52.410 --> 02:25:53.450 Wissen die wenigsten aber. 02:25:54.170 --> 02:25:54.730 Genau. 02:25:54.890 --> 02:25:56.250 Und Reag ist halt. 02:25:56.730 --> 02:25:59.690 Dieses nicht, ich schaffe in ja richtige Reihenfolge auszugeben, dann gucken wir mal dazu. 02:26:00.650 --> 02:26:07.290 Auf jeden Fall Reag ist so eine Key-Value-Store-Lösung, die extrem, extrem einfach zu administrieren ist. 02:26:07.930 --> 02:26:09.850 Failover, alles super drin. 02:26:11.130 --> 02:26:14.970 Bietet auch ein HTTP-Interface, erstaunlicherweise. 02:26:15.370 --> 02:26:20.730 Bietet aber auch so Sachen wie Protocol Buffers und Apache Afro, also auch so verschiedene Arten darauf 02:26:20.730 --> 02:26:22.410 zuzugreifen, aber HTTP geht auch. 02:26:22.570 --> 02:26:24.970 Nicht die performanteste Art, muss man auch dazu sagen bei dem Ganzen. 02:26:25.290 --> 02:26:26.890 Aber dafür dann wieder aus allen Programmiersprachen. 02:26:27.130 --> 02:26:27.530 Eben. 02:26:27.690 --> 02:26:32.650 Und React bietet auch die Möglichkeit an, so MapReduce zum Beispiel auszuführen. 02:26:32.970 --> 02:26:36.810 Kann es auch wieder in Erlang und in JavaScript machen, so wie ich mich daran erinnern kann. 02:26:36.970 --> 02:26:37.690 Doch, ja. 02:26:37.850 --> 02:26:39.050 Ich hoffe, ich sage nichts Falsches. 02:26:39.450 --> 02:26:42.570 Doch, also es ist schon Erlang geschrieben und JavaScript geht auf jeden Fall. 02:26:42.810 --> 02:26:43.770 Erlang bin ich auch. 02:26:44.810 --> 02:26:51.690 Was cool ist, React hat jetzt in letzter Zeit auch noch ein Add-on dazu veröffentlicht namens 02:26:51.690 --> 02:26:54.250 Reac Search und das hilft euch. 02:26:55.530 --> 02:26:59.850 Ein Suchdienst, also Volltextsuche geht ja da, würde da auch wieder nur über MapReduce oder so gehen, 02:26:59.930 --> 02:27:02.890 weil sie keine Indexe intern haben, die ihr beeinflussen könnt. 02:27:03.370 --> 02:27:07.610 Und das React Search ist quasi ein Add-on, dass ihr auch eine Suche skalieren könnt. 02:27:07.690 --> 02:27:12.410 Bedeutet, die haben API kompatibel zu Lucene oder Solar, 02:27:12.490 --> 02:27:17.770 also die zwei Apache-Suchprojekte, die Volltextsuche ermöglichen, haben die auch eine Suche gebaut, 02:27:18.890 --> 02:27:22.490 die du quasi auf deinen Server aufsetzen kannst. 02:27:22.650 --> 02:27:25.850 Ist eine recht coole Sache, weil dann auch deine Suche auf einmal skaliert. 02:27:25.930 --> 02:27:29.610 Also Suchen zu skalieren, Elasticsearch ist so ein Produkt, das das macht. 02:27:30.570 --> 02:27:34.970 Apache Solar ist auch was, das es macht, wobei das auch schon mehr so ein bisschen ein Pain ist. 02:27:35.050 --> 02:27:40.650 Und die skalieren also transparent sowohl deine Suche als auch deine Datenbank und benutzen dafür auch 02:27:40.650 --> 02:27:45.370 dieselben dasselbe Daten-Backend, was ich glaube noch einen recht guten Vorteil finde. 02:27:45.450 --> 02:27:52.410 Weil sobald du eben sowas benutzt wie, keine Ahnung, Lucine oder Elasticsearch, 02:27:52.570 --> 02:27:54.490 hältst du deine Daten im Grunde zweifach vor. 02:27:54.570 --> 02:27:58.810 Einmal in deiner Suche, weil er darüber Indexe bauen muss und dann auch in deiner Datenbank, 02:27:58.890 --> 02:28:02.170 weil du die auch gerne persistent und high performant verfügbar hättest. 02:28:02.570 --> 02:28:09.530 Und React ist insofern ganz cool, dass die beides Open Source gemacht haben und dass du dann unter Windows, 02:28:09.610 --> 02:28:14.650 Linux, Mac quasi dein React-Server mit deinem React Search zusammen kombinieren kannst. 02:28:14.890 --> 02:28:19.770 Sie sind, was die Skalierbarkeit angeht, ein bisschen besser als Cassandra, 02:28:19.930 --> 02:28:21.850 was so die Balancing-Geschichten angeht. 02:28:22.010 --> 02:28:28.330 Cassandra macht es mehr so in, ja, ich sag mal, wenn man das so als Diagramm sieht, 02:28:28.410 --> 02:28:32.330 ist es so abschnittsweise definiert. 02:28:32.490 --> 02:28:37.370 Also die machen das nicht so flüssig ineinander überlaufend, sondern mehr so in Hopplern. 02:28:37.530 --> 02:28:41.370 So wupp und es wird skaliert, äh, wird geload balanced. 02:28:41.450 --> 02:28:45.530 Also dann die Datenverteilung ist in React ein bisschen, ich sag mal, eleganter als man. 02:28:47.290 --> 02:28:50.970 Man hat gewisse Schnellwerte und wenn dann irgendwie die Daten über diesen Schwellwert rausgehen, 02:28:51.050 --> 02:28:53.050 dann wird auf den Server weiter skaliert. 02:28:53.290 --> 02:28:56.650 Und React macht es etwas, ich sag mal, smoother. 02:28:57.130 --> 02:29:01.210 Ja, also was ich auch gehört habe, ist, dass die beim runterskalieren auch besser sein sollen. 02:29:01.290 --> 02:29:05.610 Das heißt, wenn man jetzt merkt, okay, ich habe jetzt eigentlich zu viele Server in meinem Cluster, 02:29:05.690 --> 02:29:06.650 ich bräuchte die gar nicht alle. 02:29:06.810 --> 02:29:11.370 Ja, so nach Lastspitze, wenn auf einmal so ganz viel dazu kommt, Server hoch und auf einmal macht keiner mehr 02:29:11.450 --> 02:29:11.530 was. 02:29:11.770 --> 02:29:13.370 Ein beste Beispiel, wir hatten jetzt gerade Weihnachten. 02:29:13.530 --> 02:29:17.130 Weihnachten kaufen extrem viele Leute viele Sachen online. 02:29:17.530 --> 02:29:22.490 Da kann man sagen, okay, jetzt über die Weihnachtszeit, dann schiebe ich irgendwie mal 10% mehr Server in mein 02:29:22.490 --> 02:29:27.530 Cluster und danach baue ich die wieder ab und ich glaube, das geht in React auch besser als in Cassandra zum 02:29:27.530 --> 02:29:27.770 Beispiel. 02:29:28.090 --> 02:29:29.370 Genau, das ist auch so eine Sache. 02:29:29.450 --> 02:29:30.330 Also sie sind vergleichbar. 02:29:30.410 --> 02:29:32.410 React ist Key Value Cassandra Column Store. 02:29:32.570 --> 02:29:36.570 React ist so ein bisschen mein Liebling, was Skalierbarkeit angeht, weil er echt total einfach ist. 02:29:36.890 --> 02:29:42.250 Sie haben auch ein super Wiki, sie haben wieder Screencast ohne Ende, so Schemadesign mit React und so alles. 02:29:42.410 --> 02:29:45.450 Sind irgendwie vergleichbar mit MongoDB auch von der Community, viele Leute. 02:29:45.690 --> 02:29:49.530 Aber es steht eine Firma dahinter und MongoDB auch TenGen hier halt. 02:29:50.250 --> 02:29:54.810 Aber bei Apache, äh ne, bei Cassandra ist es nicht so, ne? 02:29:54.890 --> 02:29:59.130 Ja, weil es Facebook und es ist auch nicht sind, aber da steht keine eine Firma dahinter. 02:29:59.450 --> 02:30:01.290 Auch in Apache-Projekten steht ja keiner dahinter. 02:30:01.370 --> 02:30:02.650 Das ist ja auch so ein Community. 02:30:02.970 --> 02:30:07.610 Mit einem IOCG, es muss halt hoffen, dass einer da ist, bei MongoDG in React, für jemand bezahlt, der da ist. 02:30:07.850 --> 02:30:11.610 Bei React gibt es halt die Firma, die auch eine Enterprise-Version davon anbietet. 02:30:11.690 --> 02:30:14.650 Bei der Enterprise-Version ist zum Beispiel sowas. 02:30:15.450 --> 02:30:22.250 Nee, es gibt bei der Enterprise-Version auch ein extra Frontend nochmal Management-Gebiet. 02:30:23.050 --> 02:30:26.090 Management-Frontend-HTTP, wo du drauf kommst und dann irgendwie so. 02:30:27.530 --> 02:30:29.530 Also da gibt es halt nochmal eine extra Version. 02:30:30.410 --> 02:30:34.170 React schreibt auch auf die Festplatte alles oder lebt er nur im. 02:30:34.490 --> 02:30:37.850 Ja, nee, nee, also die schreiben alle bis auf Redis eigentlich alles auf die Festplatte. 02:30:38.730 --> 02:30:42.490 Und da kannst du auch bei React wieder einstellen, wie und wie oft und überhaupt. 02:30:42.570 --> 02:30:44.410 Also es ist alles auch recht konfigurierbar, glaube ich. 02:30:44.570 --> 02:30:45.770 Also schön schnell verteilen. 02:30:45.930 --> 02:30:51.290 Genau, schön schnell verteilen, schön skalierbar, gut, jetzt mit React Search auch durchsuchbar, 02:30:51.370 --> 02:30:52.810 was sehr beeindruckend ist. 02:30:53.610 --> 02:30:58.730 Und ist ein bisschen von der Performance langsamer als natürlich so Sachen wie MongoDB. 02:30:59.530 --> 02:31:04.810 Also im Single-Node-Betrieb zumindest, im Multinote-Betrieb ist es dann wahrscheinlich auch wieder, 02:31:04.970 --> 02:31:06.090 gibt sich wahrscheinlich dann auch so ein bisschen. 02:31:06.250 --> 02:31:07.850 Es kommt dann darauf an, wie viele Server man dann hat. 02:31:07.930 --> 02:31:14.810 Also MongoDB ist da jetzt eher so auf, wenn man jetzt mal so eine Handvoll Server oder mal so ein kleiner 02:31:14.890 --> 02:31:20.730 zweistelliger Bereich und ich glaube, React ist dann eher so für die größeren Geschichten gedacht. 02:31:21.130 --> 02:31:24.090 Und das ist auch, also sie sind auch nicht so schlecht jetzt Single-Side, 02:31:24.250 --> 02:31:26.730 also wenn du nur einen Server hast, kannst du halt auch React drauf einsetzen. 02:31:26.810 --> 02:31:29.850 Also sie sind immer noch sehr schnell im Gegensatz zu allen anderen Sachen, 02:31:29.930 --> 02:31:35.210 die so ein bisschen, ich sag mal, MySQL-mäßig daherkommen für so simple Key-Value-Sachen. 02:31:36.250 --> 02:31:41.210 Ja, sie sind, haben ganz interessante Sachen, Post- und Pre- und Post-Commit-Hooks. 02:31:41.370 --> 02:31:45.050 Also jedes Mal, wenn du Daten reinspeicherst, kannst du dir auch aussuchen, 02:31:45.210 --> 02:31:48.010 ob du da noch eine gewisse Funktion laufen lassen willst. 02:31:48.170 --> 02:31:50.970 Also jedes Mal, wenn einer irgendwie einen neuen Benutzer da reinschreibt, 02:31:51.050 --> 02:31:54.250 kannst du noch eine Funktion laufen lassen, die dann irgendwie noch irgendwas anderes anlegt. 02:31:54.490 --> 02:31:55.770 Logik in der Datenbank, ja. 02:31:56.250 --> 02:31:57.610 Dann trägt einen normalen Datenbank. 02:31:58.090 --> 02:32:01.050 Richtig, es ist die Frage, ob man das haben will oder nicht, weil dann musst du, 02:32:01.290 --> 02:32:04.410 hast du wieder deine Logik verteilt, obwohl du ja. 02:32:04.650 --> 02:32:06.650 Je nachdem, manche brauchen es, manche nicht. 02:32:06.970 --> 02:32:09.210 Du kannst auch natürlich alles wieder konfigurieren. 02:32:09.370 --> 02:32:13.610 Schöne Sache, HTTP, React. 02:32:14.170 --> 02:32:14.410 Schön. 02:32:14.970 --> 02:32:18.170 Dann noch ein Key Value Store, auf den wir jetzt aber nicht groß eingehen. 02:32:18.490 --> 02:32:22.010 Memcache DB kann man sich einfach mal angucken, auch so ein Memca-State. 02:32:22.250 --> 02:32:24.250 Das Einfachste, was man machen kann mit Key-Value Store. 02:32:24.330 --> 02:32:26.170 Also Memcache ist String rein, string raus, Ende. 02:32:26.410 --> 02:32:29.930 Genau, eigentlich nur ein reiner Caching-Layer, der nur, also wie der Name schon sagt, 02:32:30.010 --> 02:32:31.370 im Speicher vorgehalten wird. 02:32:31.690 --> 02:32:38.570 Memcache DB verbindet das Ganze noch mit, glaube ich, einer Berkeley DB und ist dann auch in der Lage, 02:32:38.650 --> 02:32:39.610 das Ganze per Student abzuhalten. 02:32:39.770 --> 02:32:42.410 Der einzige Vorteil, es gibt für Memcache, das ist ein eigenes Protokoll, 02:32:42.570 --> 02:32:43.930 aber da gibt es auch für alles wieder in Libraries. 02:32:44.170 --> 02:32:44.330 Genau. 02:32:44.490 --> 02:32:50.090 Also wo das zum Beispiel extrem eingesetzt wird, sind so Geschichten wie zum Beispiel bei Facebook oder so, 02:32:50.170 --> 02:32:51.770 wo man wirklich viele Daten cachen muss. 02:32:52.090 --> 02:32:54.970 Ich glaube, die hatten von Ubuntu-User oder so. 02:32:55.610 --> 02:33:00.250 Also die hatten vor, ich glaube, zwei oder drei Jahren hatten die mal mehrere Terabyte, 02:33:00.330 --> 02:33:04.650 ich glaube 32 Terabyte oder so in Memcache einfach im Speicher liegen. 02:33:04.890 --> 02:33:06.650 Da sieht man schon, was das für Datenmengen sind. 02:33:07.450 --> 02:33:08.090 Krass, krass. 02:33:08.170 --> 02:33:08.650 Okay, dann. 02:33:09.050 --> 02:33:09.690 Das letzte, ne? 02:33:09.930 --> 02:33:14.170 Ja, das letzte, wo ich jetzt auch nicht groß drauf eingehen würde, weil wir ja dazu letztens schon einen 02:33:14.170 --> 02:33:16.170 Podcast hatten, nämlich die Grafdatenbanken. 02:33:16.730 --> 02:33:17.370 Können wir ja verlieren. 02:33:17.610 --> 02:33:17.850 Genau. 02:33:18.330 --> 02:33:21.850 Vielleicht noch die Sachen, die es gibt, Neo4j zum Beispiel, das sind eine Java-basierte, 02:33:21.930 --> 02:33:26.570 da gibt es für ja, war ein bisschen komisch, weil das war ursprünglich hatten sie keinen echten Web-Server, 02:33:26.650 --> 02:33:28.410 sondern du hast die in deinem Programm benutzt. 02:33:28.570 --> 02:33:30.490 Bedeutet von außen nicht zugreifbar richtig. 02:33:30.650 --> 02:33:35.530 Jetzt haben sie einen REST-Server, die Libraries so ein bisschen, naja, geht so. 02:33:35.610 --> 02:33:38.810 Also für Ruby gibt es eine, die funktioniert mit JRuby und es gibt eine, 02:33:38.890 --> 02:33:43.930 die halt dieses REST benutzt, aber ja, weniger als zum Beispiel React oder MongoDB oder Redis. 02:33:44.250 --> 02:33:47.290 Ist bei GrafTB so ähnlich, also du kannst auch per REST irgendwie, aber. 02:33:47.770 --> 02:33:49.210 Bei GraphTB wird es, glaube ich, noch weniger. 02:33:49.530 --> 02:33:53.290 Und Anbindung auch nur an PHP und Java, äh PHP und .NET. 02:33:54.010 --> 02:33:54.650 Und Java. 02:33:54.810 --> 02:33:55.530 Und Java. 02:33:55.690 --> 02:33:57.530 Gut, stimmt, du hast es letztes gehört, ne? 02:33:58.090 --> 02:33:59.690 Also vor zwei Stunden oder so. 02:34:00.250 --> 02:34:00.490 Okay. 02:34:00.730 --> 02:34:02.170 Wunderbar vorbereitet, sehr gut. 02:34:02.890 --> 02:34:08.250 Da nochmal den extra Podcast hören, wer sich mit Graft-Datenbanken ein bisschen näher beschäftigen will. 02:34:08.570 --> 02:34:13.930 Okay, das würde ich sagen, war so mal unser Überblick über die 02:34:14.170 --> 02:34:17.050 NoSQL-Datenbanken, die es so gibt. 02:34:18.090 --> 02:34:19.610 Was kann ich jetzt damit machen? 02:34:19.850 --> 02:34:20.410 Bräuchte es? 02:34:20.650 --> 02:34:22.650 Ich meine, Einsatzgebiete, wir hatten sie ja vorher schon besprochen. 02:34:24.330 --> 02:34:29.770 Also, wenn ihr eine Web-Applikation baut, auf jeden Fall mal NoSQL-Datenbanken angucken und nicht gleich auf. 02:34:30.330 --> 02:34:30.810 Nicht immer. 02:34:30.970 --> 02:34:33.290 Es sind natürlich, die werden noch nicht so oft angeboten beim Hosting. 02:34:33.530 --> 02:34:36.010 Oft kriegst du halt deine MySQL-Datenbank so mit dazu beim Hosten. 02:34:36.490 --> 02:34:38.570 Wenn du einen eigenen Server hast, du sparst umspielen. 02:34:38.810 --> 02:34:43.050 Du sparst dir viel Arbeit und Code, wenn du teilweise deine Objekte nicht noch irgendwie sehr realisierst und 02:34:43.050 --> 02:34:43.930 nachher wieder zurück. 02:34:44.090 --> 02:34:48.250 Und du hast auch so Sachen wie SQL-Injections, die gehen dann halt einfach nicht, weil du kein SQL hast. 02:34:48.490 --> 02:34:49.130 Gut, dafür kann man. 02:34:49.530 --> 02:34:50.970 Du hast irgendwie JavaScript-Injections. 02:34:51.210 --> 02:34:51.450 Ja, genau. 02:34:51.770 --> 02:34:56.570 JavaScript-Injections, also man sollte trotzdem die Eingaben, 02:34:57.210 --> 02:34:59.130 die vom Benutzer leben, immer validieren. 02:34:59.370 --> 02:35:03.770 Ja, wobei die JavaScript-Injections sind ja auch, die bauen du sich ja nicht normalerweise aus Strings 02:35:03.850 --> 02:35:05.290 zusammen, die haben ja schon ein bisschen was gelernt. 02:35:05.450 --> 02:35:05.530 Genau. 02:35:05.770 --> 02:35:11.450 Also nicht per se sicherer, aber ich sag mal, blöde Fehler passieren nicht so oft. 02:35:12.010 --> 02:35:15.370 Ja, also es gibt mittlerweile, glaube ich, zumindest für MongoDB Firmen, 02:35:15.450 --> 02:35:18.410 die sich da auf Hosting spezialisiert haben, falls man das einsetzen möchte. 02:35:19.210 --> 02:35:20.570 Da kann ich mal einen Link raussuchen. 02:35:20.810 --> 02:35:24.490 Gibt es gerade wenn du Ruby machst bei, wie heißen sie, die wurden von Salesforce gekauft, 02:35:24.570 --> 02:35:26.250 dieser Ruby ist Hosting-Dienst. 02:35:26.730 --> 02:35:27.690 Achso, du meinst. 02:35:28.170 --> 02:35:30.330 Ich will immer Nagios sagen, aber das ist nicht Nagios. 02:35:30.410 --> 02:35:30.650 Das ist. 02:35:31.290 --> 02:35:32.810 Mir liegt es auf der Zunge. 02:35:33.610 --> 02:35:34.650 Das ist raus. 02:35:38.490 --> 02:35:39.450 Ah, verdammt. 02:35:39.610 --> 02:35:40.170 Salesforce. 02:35:40.730 --> 02:35:42.010 Also Salesforce hat es gekauft. 02:35:42.330 --> 02:35:43.690 Ich weiß auch, wen du meinst. 02:35:46.010 --> 02:35:46.970 Ja, egal. 02:35:47.290 --> 02:35:47.610 Ja. 02:35:48.490 --> 02:35:49.450 Fällt uns nicht ein. 02:35:50.330 --> 02:35:50.650 Heroku. 02:35:50.810 --> 02:35:51.450 Heroku, genau. 02:35:51.850 --> 02:35:53.050 Heroku gibt es auch was gratis dann. 02:35:56.170 --> 02:35:57.290 Genau, wozu kann man es noch. 02:35:57.450 --> 02:36:02.810 Also Speziallösungen wie Redis können wir dann für Caching und Event-Queuing und so Geschichten einsetzen. 02:36:03.930 --> 02:36:08.330 Es ist, ich glaube, generell sollte man einfach da sagen, hier irgendwie auf Englisch heißt es Horses for 02:36:08.330 --> 02:36:13.050 Courses, auf Deutsch, irgendwie jedem Töpfchen sein Deckelchen, jedem Tierchen sein Pläsierchen. 02:36:13.930 --> 02:36:19.530 Nicht nur, man sollte immer das richtige Werkzeug für den Job haben und MySQL ist nicht immer das Richtige. 02:36:19.770 --> 02:36:23.850 Es gibt viele NeusQL-Sachen, wenn ihr einen eigenen Server habt, spart es euch eventuell viel Zeit und 02:36:23.850 --> 02:36:26.410 Administrationsaufwand, sowas zu benutzen. 02:36:27.370 --> 02:36:29.050 Ist auf jeden Fall mal ein Blick wert. 02:36:29.130 --> 02:36:33.610 Es gibt, man muss aber auch sagen, nicht immer versuchen, alles automatisch irgendwie auf NeusQL zu quetschen, 02:36:33.770 --> 02:36:36.410 sondern es gibt Sachen, da ist einfach MySQL sowas. 02:36:36.650 --> 02:36:38.250 Genau, wenn ihr eine Bank seid zum Beispiel. 02:36:38.810 --> 02:36:40.330 Dann nehmt ihr MySQL ein. 02:36:42.170 --> 02:36:43.770 Das haben wir nicht gesagt. 02:36:44.330 --> 02:36:45.050 Doch, doch. 02:36:46.250 --> 02:36:47.130 Ich will Unterhaltung. 02:36:47.530 --> 02:36:51.770 Wie gesagt, also ich glaube, da ist einfach sinnvoll, dann zu gucken, 02:36:51.850 --> 02:36:58.490 was habe ich für Anwendungsfälle und was habe ich vor Voraussetzungen und dann zu entscheiden, 02:36:58.570 --> 02:36:59.450 was nimmt man denn jetzt an. 02:36:59.530 --> 02:37:02.810 Ja, auch gerade eben, es gibt jetzt ja auch immer wieder dieses Polyglot Persistence, 02:37:02.890 --> 02:37:04.170 heißt es jetzt, nimm deinen Datenschrank. 02:37:04.250 --> 02:37:07.130 Es gibt auch bei Polyglot Programming, nimm eine Sprache, die dafür gemacht ist. 02:37:07.290 --> 02:37:11.130 Nicht immer alles in Java, nicht immer alles in MySQL oder PHP in MySQL, 02:37:11.210 --> 02:37:17.050 sondern mach auch mal was mit, keine Ahnung, JavaScript und Erlang und sonst was. 02:37:17.770 --> 02:37:24.250 Ja, heißt im Endeffekt, nimm das Werkzeug, was du zur, also nimm für diese Dinge, 02:37:24.330 --> 02:37:26.170 die du tun willst, das richtige Werkzeug. 02:37:26.250 --> 02:37:26.330 Genau. 02:37:26.650 --> 02:37:30.970 Und dafür guckst du dir vorher an und deswegen hör dir erst den Podcast ja an und selbst den Überblick hast, 02:37:31.050 --> 02:37:31.130 genau. 02:37:31.610 --> 02:37:32.570 Aber beherrsche es auch. 02:37:32.970 --> 02:37:35.770 Genau, und selbst wenn du es nicht benutzt im Endeffekt, es hilft dir eventuell, 02:37:35.850 --> 02:37:38.170 selbst wenn du MySQL benutzt, Probleme einfach mal anders zu sehen, 02:37:38.250 --> 02:37:41.610 weil du einfach ein anderes Hintergrundwissen hast und sagst, ah ja, 02:37:41.690 --> 02:37:45.130 wir würden das ja nicht so machen, vielleicht wäre das ja doch besser und es dann vielleicht auch dein 02:37:45.130 --> 02:37:46.490 Datenschirm an MySQL anders macht. 02:37:46.650 --> 02:37:48.010 Das erweitert ein bisschen den Horizont. 02:37:48.090 --> 02:37:50.250 Ich glaube, das kann man sagen, auch wenn man diese Papers mal liest, 02:37:50.410 --> 02:37:56.010 das hilft einem auch, andere Datenbanksysteme, also oder relationale Datenbanksysteme im Speziellem zu 02:37:56.010 --> 02:37:56.330 verstehen. 02:37:56.570 --> 02:37:56.810 Genau. 02:37:57.210 --> 02:37:59.130 Das haben wir alles in die Shownotes gepackt. 02:37:59.210 --> 02:38:02.090 Also das ist wahrscheinlich diesmal auch eine richtige Fundgrube. 02:38:02.170 --> 02:38:07.770 Da kann man sich mal durchklicken, durchsurfen und noch ein paar sehr interessante Sachen lesen. 02:38:09.130 --> 02:38:11.370 Auch selbst wenn man nicht durch alles durchsteigt. 02:38:11.530 --> 02:38:14.250 Also diese Papers sind schon verdauliche Kost. 02:38:14.410 --> 02:38:16.410 Also manche muss man wahrscheinlich fünfmal lesen. 02:38:16.570 --> 02:38:19.450 Im Zweifelsfall mehrmals lesen und dann mal ein bisschen sacken lassen. 02:38:19.610 --> 02:38:22.330 Manchmal kommt es dann auch unter der Dusche, ah, das hat er gemeint. 02:38:23.050 --> 02:38:25.210 Ja, und das Coolste, alles gratis. 02:38:25.610 --> 02:38:31.290 Was wir heute vorgestellt haben, die sind alle eigentlich alle Open Source und alle frei verfügbar und da 02:38:31.290 --> 02:38:33.770 kommt keiner, der will eine Lizenz für 20.000 Euro von euch. 02:38:33.930 --> 02:38:38.010 Ja, oder wenn man irgendwie Oracle ischt, dann irgendwie so 2 Millionen oder so, 02:38:38.090 --> 02:38:40.490 keine Ahnung, was deren größte Lizenz kostet. 02:38:40.650 --> 02:38:41.930 Aber viel auf jeden Fall. 02:38:42.890 --> 02:38:46.730 Und ihr braucht auch kein Mainframe vom IBM für richtig. 02:38:47.050 --> 02:38:52.410 Genau, also im Zweifelsfall reichen dann ein paar Pizzaboxen oder wie es so schön heißt, Commodity Hardware. 02:38:53.530 --> 02:38:54.410 Bingo. 02:38:55.210 --> 02:38:56.170 Und ja. 02:38:56.570 --> 02:38:59.530 So, Dirk, haben wir dich überzeugt? 02:38:59.770 --> 02:39:01.290 Oder haben die zwei dich überzeugt? 02:39:01.370 --> 02:39:04.170 Ich habe ja nicht, ich bin ja nur die Stimme aus dem Off. 02:39:05.210 --> 02:39:06.970 Na, es kommt auf das Anwendungsgebiet an. 02:39:07.290 --> 02:39:11.370 Also wenn du bestimmt das Cup-Theorem mal so im Hinterkopf behältst, 02:39:11.450 --> 02:39:16.250 es gibt halt Sachen, wo du sicher Daten brauchst und da kommst du, würde ich mich bei NoSQL nicht so gut 02:39:16.250 --> 02:39:16.970 aufgehoben fühlen. 02:39:17.370 --> 02:39:21.770 Und es gibt Sachen, wo ich, wo ich, ähm, na, wie soll ich das sagen? 02:39:22.970 --> 02:39:27.610 Wo ich schnell und unkompliziert was ausliefern muss und das sind NoSQL-Datenbank ganz weit vorne. 02:39:27.930 --> 02:39:34.090 Also ich denke gerade bei so Web-Applikationen, äh, Social Networks und so weiter. 02:39:34.970 --> 02:39:39.690 Wenn man sowas mal bauen will, lohnt sich auf jeden Fall mal ein Blick in die Richtung. 02:39:40.890 --> 02:39:42.810 Gut, dann würde ich sagen, klappe zu. 02:39:42.970 --> 02:39:43.370 Schön war's. 02:39:43.610 --> 02:39:44.250 Affe tot. 02:39:45.130 --> 02:39:45.770 Lang haben wir denn? 02:39:46.010 --> 02:39:46.890 Ist das schon dunkel draußen? 02:39:46.970 --> 02:39:48.490 Weiß ich nicht, sehe ich nicht, ist zu dunkel hier. 02:39:49.130 --> 02:39:49.610 Ähm. 02:39:49.850 --> 02:39:51.370 Vielen Dank, dass ihr da wart. 02:39:51.530 --> 02:39:54.890 Ich weiß noch nicht, wann wir die nächste Binärgewittersendung aufnehmen. 02:39:55.050 --> 02:39:56.650 Wird so ein bisschen unregelmäßig wahrscheinlich. 02:39:56.730 --> 02:39:58.890 Unsere Themenliste ist total lang. 02:39:59.130 --> 02:40:00.650 Ich glaube, die können wir auch mal veröffentlichen. 02:40:01.050 --> 02:40:03.130 Gibt es ja schon so einen Ausblick, wenn du irgendwie gerade mal zwei, 02:40:03.210 --> 02:40:05.210 drei erwähnen kannst, dass der mundwässrig wird. 02:40:05.530 --> 02:40:07.610 Dass der mundwässrig wird, okay, aber wir haben echt. 02:40:10.170 --> 02:40:12.250 Also, ich glaube, die veröffentlichen wir mal. 02:40:12.330 --> 02:40:16.490 Also wir haben von verteilte Dateisysteme, was man hier schön gleich anschließen könnte. 02:40:16.650 --> 02:40:21.050 IT Security, IPv6, Home Server, 02:40:21.210 --> 02:40:26.250 NAS, Virtualisierung, Home Theater PCs, Webtechnologien, 02:40:26.810 --> 02:40:29.610 HTML5, mobile Betriebssysteme. 02:40:29.770 --> 02:40:34.410 Naja, auch so Python, Ruby, alle Welten, Programmierparameter. 02:40:34.570 --> 02:40:39.930 Java, UMTS, Sicherheitsprobleme, Open Source und Film, 02:40:40.090 --> 02:40:44.730 Spiele, Maillisten und E-Mail-Men für Anhänger, äh, für Anfänger, 02:40:44.890 --> 02:40:45.370 für Anhänger. 02:40:45.530 --> 02:40:47.130 Für Anfänger ist ein Hörervorschlag. 02:40:47.450 --> 02:40:47.850 Alternativen. 02:40:50.170 --> 02:40:54.170 Also die Themenliste wird auch immer länger, aber es wird unregelmäßig, 02:40:54.250 --> 02:40:56.570 ich weiß nicht, wann wir die Leute hier immer zusammenkriegen. 02:40:56.810 --> 02:41:01.610 Also das kann ein bisschen sein, aber wenn ihr uns Kritik gebt, ich wollte jetzt nicht sagen gute Kritik, 02:41:01.690 --> 02:41:06.090 wenn ihr uns auf jeden Fall Kritik und Ansporn gebt, hier dieses Format weiterzumachen. 02:41:08.170 --> 02:41:08.490 Ja, genau. 02:41:08.730 --> 02:41:08.890 Richtig. 02:41:09.210 --> 02:41:10.410 Packt sie in die Kommentare auf. 02:41:10.650 --> 02:41:13.210 Auf Twitter gibt es auch einen Twitter-Account, Binär-Gewitter, ne? 02:41:13.290 --> 02:41:13.370 Genau. 02:41:13.610 --> 02:41:13.850 Binar. 02:41:14.410 --> 02:41:15.450 Binär-Gewitter. 02:41:15.690 --> 02:41:17.130 Wir haben einen auf dem Beta-Account. 02:41:17.530 --> 02:41:18.330 Ja, genau. 02:41:18.570 --> 02:41:20.250 Also macht was, dass wir. 02:41:20.810 --> 02:41:23.370 Wir haben jetzt alle Hunger, weil das so lang dauert oder wir haben alle kein Geld. 02:41:23.610 --> 02:41:24.730 Wir brauchen jetzt Essen. 02:41:25.210 --> 02:41:26.730 Genau, das kaufen wir immer von Flutter. 02:41:30.730 --> 02:41:31.290 Korrekt. 02:41:31.370 --> 02:41:35.370 Also, wünsche euch einen schönen Abend und eine frohe Zeit. 02:41:35.450 --> 02:41:39.930 Und danke an ihr, die hier wart und danke an die Zuhörer. 02:41:40.090 --> 02:41:41.370 Danke, dass du uns eingeladen hast. 02:41:41.850 --> 02:41:42.570 Auf Wiedersehen. 02:41:42.810 --> 02:41:43.130 Und tschüss. 02:41:45.290 --> 02:41:51.690 Das war eine Sendung von Radio Tux, herausgegeben im Jahr 2011 unter 02:41:51.690 --> 02:41:54.650 Creative Commons by Non-Commercial Sharealike. 02:41:55.370 --> 02:41:57.850 Leader sind eventuell anders lizenziert. 02:41:58.570 --> 02:42:01.610 Mehr Infos auf radiotux.de 02:42:05.770 --> 02:42:12.730 Unterstützt von Open Coffee B Linux, Tarent und Fair Trade Software.