#91 Konsistent, Verfügbar, Ausfalltolerant oder Performant: Das CAP- und PACELC-Theorem in verteilten Systemen

Konsistent, Verfügbar und Ausfalltolerant: Wähle zwei - Das CAP-Theorem

Stellt euch vor, ein Handwerker könnte die Dienstleistung schnell, günstig und in hoher Qualität leisten. Wäre dies nicht ein Traum? Leider sind alle drei Eigenschaften in der Realität nicht möglich. Und genau so geht es uns mit dem CAP-Theorem in verteilten Systemen mit Datenhaltung. Speziell im aktuellen Zeitalter mit Cloud Computing, horizontaler Skalierung, weltweiter Verfügbarkeit spielt das CAP-Theorem eine essentielle Rolle.

Wie soll sich dein System verhalten, wenn die Netzwerk-Verbindung zwischen deinen Compute-Knoten ausfällt? Muss die Datenhaltung konsistent bleiben? Oder sind Inkonsistenzen für eine gewisse Zeit OK, dafür hat die Verfügbarkeit eine höhere Priorität? Um diesen Konflikt geht es in dieser Episode.

Bonus: Auf GCP kannst du deine Compute-Instanz auf maximal 12 TB SSD Disk (ohne Netzwerk-Storage) aufstocken.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:16) Das CAP-Theorem

(00:03:37) Verteilte Systeme, Datenhaltung und State

(00:08:17) Was ist das CAP-Theorem?

(00:09:52) Info/Werbung

(00:11:15) Was ist das CAP-Theorem?

(00:13:10) Das C in CAP: Consistency

(00:15:12) Das A in CAP: Availability

(00:16:16) Das P in CAP: Partition Tolerance

(00:18:55) Der Problemfall in verteilten Systemen

(00:20:41) Was bedeutet es, wenn ein verteiltes System alle drei Eigenschaften erfüllen würde

(00:22:56) Wo kommt das CAP-Theorem her? Das Brewer Theorem, ACID und BASE

(00:31:50) Ausprägung CP: Consistency und Partition Tolerance

(00:33:31) Ausprägung AP: Availability und Partition Tolerance

(00:36:34) Ausprägung AC: Availability und Consistency

(00:37:16) Das CAP-Theorem im Fehlerfall: PACELC

(00:41:07) Das CAP-Theorem und die Praxis

(00:43:00) MongoDB

(00:45:13) Cassandra

(00:46:36) Kubernetes

(00:49:38) Kafka

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:03 - 00:01:08)

Deine Datenbank skaliert nicht mehr? Hol dir doch einfach ein verteiltes Datenbanksystem. Das funktioniert doch heute alle schon out of the box. Habt ihr diesen Dialog auch schon einmal gehört? So oder so ähnlich? Wenn man dann aber genauer nachfragt, wie die verteilte Datenhaltung denn funktioniert, welche Kriterien erfüllt werden und wie sich das System bei einem Ausfall von Knoten verhält, wird es sehr oft sehr schnell leise. Und damit willkommen zu einer neuen Episode des Engineering Kiosks, dem deutschsprachigen Software-Engineering-Podcast mit Wolfgang Gassler und Andi Grunwald rund um die Themen Engineering Kultur, Open Source, Menschen, Technologie und allen anderen Bereichen, die damit in Verbindung stehen. Wir besprechen in dieser Episode anhand des CAP-Theorems die Schwierigkeit von verteilten Systemen. Und für alle, für die CAP ein alter Hut ist, wir sprechen auch über Buck Elk, die große Schwester vom CAP-Theorem, Aber auch über Konsistenzkriterien, Ausfalltoleranzen, verteilte COMIT-Protokolle und wie sich das Ganze auch abseits von Datenbanken auf verteilte Systeme auswirkt. Und wer wissen will, warum verteilte Systeme wie Handwerker sind, sollte auf jeden Fall weiterhören. Ich glaube, ich brauche nicht dazu sagen, dass dieser Vergleich von Andi kommt. Aber starten wir ins Thema und los geht's.

Andy Grunwald (00:01:15 - 00:01:25)

Willkommen zu einer neuen Episode vom Engineering Kiosk. Heute in einem etwas anderen Setup. Ich bin stimmlich etwas angeschlagen. Ich entschuldige mich jetzt schon mal, aber...

Wolfi Gassler (00:01:25 - 00:01:31)

Du klingst wie der Imam, der jetzt gerade im Hintergrund bei mir sein Gebet an die Leute weiterreicht.

Andy Grunwald (00:01:32 - 00:01:37)

Und lustigerweise höre ich das sogar durch dein Mikro. Wolfgang, wo bist du jetzt gerade?

Wolfi Gassler (00:01:37 - 00:01:44)

Jetzt gerade gemütlich auf 500 Höhenmeter, also fast wie in Innsbruck zwischen Bergen, aber im Kosovo.

Andy Grunwald (00:01:44 - 00:01:48)

Du bist da, wie sagt man so bei euch, auf Urlaub und nicht beruflich, richtig?

Wolfi Gassler (00:01:48 - 00:01:57)

Ja, Workation nennen wir es mal so. Ich genieße das Remote Setup zum Beispiel mit dir, aber auch den Kosovo.

Andy Grunwald (00:01:57 - 00:02:04)

Ich finde es auf jeden Fall super, dass du uns nicht hängen lässt, damit die Hörerinnen und Hörer jede Woche eine neue Episode Engineering Curse haben.

Wolfi Gassler (00:02:04 - 00:02:07)

Ja, haben wir ja gesagt, es gibt keinen Urlaub bei uns.

Andy Grunwald (00:02:07 - 00:02:13)

Ich bin gespannt, wann wir das erste Mal unsere eigene Regel brechen oder irgendwann selbst aufweichen oder ähnliches. Naja, schauen wir mal.

Wolfi Gassler (00:02:13 - 00:02:17)

Und heute haben wir wieder mal ein ordentliches technisches Thema, was sich ja viele gewünscht haben.

Andy Grunwald (00:02:17 - 00:02:27)

Über welches thema sprechen wir heute was geht dir gerade wirklich so hart auf die nerven beziehungsweise was kommunizierst du zurzeit öfter denn je mal wieder.

Wolfi Gassler (00:02:27 - 00:02:37)

Also eigentlich war das ja deine idee muss man sagen dieses thema weil übers theorem und die schwierigkeiten von verteilten datenbanken referiere ich eigentlich relativ selten muss ich zugeben.

Andy Grunwald (00:02:37 - 00:03:29)

Ich komme mit dem Thema des Cup Theorems in letzter Zeit immer und immer und immer häufiger in Berührung. Und das liegt unter anderem auch an meiner Arbeit. Ich arbeite mit Datenbanken, ich betreibe Datenbanken beruflich, weil ich bei einem Database-as-a-Service-Provider arbeite. Und das bedeutet natürlich auch, dass ab und zu manche Kunden Herausforderungen haben, beziehungsweise Kunden sind verantwortlich für Konfigurationen und ab und zu mal etwas nicht so läuft, wie es laufen soll. Und dann schaut man sich die ganze Sache an, und dann merkt man, die ganze Sache wurde falsch konfiguriert, vielleicht nicht ganz zu Ende gedacht, oder vielleicht, Achtung, wurde sich über das Cup-Theorem keine Gedanken gemacht. Denn viele Datenbanken implementieren viele Elemente des Cup-Theorems. Der Anwender muss trotzdem wissen, was er tut, und der Anwender muss trotzdem wissen, was er will, und der Anwender muss trotzdem entsprechend die ganze Thematik ordentlich konfigurieren.

Wolfi Gassler (00:03:30 - 00:03:50)

Naja, eigentlich kann ja eine Datenbank gar nichts implementieren. Vom CAP-Theorem ist ja ein Theorem, das quasi immer gültig ist. Aber bevor wir da mal in das Thema einsteigen, beginnen wir mal ganz grundsätzlich. Für alle, die das noch nie gehört haben, dieses CAP-Theorem, also wir befinden uns in der Welt der Datenbanken oder der Datenhaltung im weitesten Sinne.

Andy Grunwald (00:03:50 - 00:03:55)

Meines Erachtens nach sogar noch eine Ebene höher in den Bereich verteilte Systeme.

Wolfi Gassler (00:03:55 - 00:05:21)

Genau, aber es geht um das Speichern eines States. Also wenn man keinen State hat, braucht man sich darüber eigentlich keine Gedanken machen. Also wenn man nur irgendwelche stateless Services hat, die kann man einfach auf Nodes hochfahren, 10, 20, 30, killen, hochfahren, ist ganz egal. Aber sobald man natürlich irgendwelche Daten speichern will, ein State halten will, dann wird die ganze Sache schwierig. Und ich kann auch nur empfehlen, das möglichst weit nach hinten zu schieben. Also wenn man irgendwann mal in die Entscheidungsphase kommt, will ich jetzt eine verteilte Datenbank, eine verteilte Datenhaltung haben oder nicht? Wenn es irgendwie möglich ist, würde ich davon Abstand nehmen, weil es einfach extrem kompliziert wird mit der Zeit. Also das klassische Modell, was man ja ganz oft macht, wenn man jetzt so eine klassische Datenbank hat, MySQL, Postgres, dass man einfach das Ganze repliziert, dass man sagt, ich habe einen zweiten Server und alles, was auf den ersten Server auf dem Source geschrieben wird, wird auf der Replica am zweiten Server nachgezogen, mehr oder weniger synchron. Und alles, was schreibend ist, basiert dann am Source und alles, was lesend ist, kann auf beiden Servern basieren. Da hat man auch noch kein Problem, weil es kein verteiltes System ist. Ich verteile ja meine Daten eigentlich nur zum Lesen, aber schwierig wird natürlich das Ganze, wenn man den Schreibprozess verteilen will. Und das ist eigentlich der eigentliche Kern von dem Ganzen, beziehungsweise die Schwierigkeit, wenn man wirklich auf mehreren Servern schreiben will und die Daten wirklich verteilen will. Und da kommt man eigentlich relativ schnell im Problem.

Andy Grunwald (00:05:21 - 00:05:26)

Positives Wording, Wolfgang. Positiv. Wir haben keine Probleme, wir haben nur Herausforderungen.

Wolfi Gassler (00:05:26 - 00:06:13)

Genau, und da würde man meinen, dass dieses Diese Herausforderung, die es ja schon seit Ewigkeiten gibt, eigentlich gelöst wurde. Aber wenn man sich das Ganze ein bisschen ansieht, dann ist es eigentlich ein recht modernes Problem, weil früher hat man alles probiert synchron zu lösen. Das heißt, ich habe meine Datenbanken verteilt und habe dann synchron meine Verteilung durchgeführt. Das heißt, wenn ich jetzt irgendwo geschrieben habe auf einem Server, dann wurden synchron alle Knoten, alle Replikas nachgezogen. Wirklich in einem synchronen Kommit. Jeder, der Informatik studiert hat, hoffentlich hat wahrscheinlich mal das Zwei-Phasen-Kommit-Protokoll gehört. Andi, hast du es gelernt in deinem Studium? Oder war das erst nach dem Studium Abbruch gekommen als Thema?

Andy Grunwald (00:06:13 - 00:06:22)

Es war bestimmt drin in den Slides, aber wenn du mich jetzt fragst, biete bitte das Zwei-Phasen-Commit-Protokoll runter, dann muss ich ja sagen, wir sehen uns morgen.

Wolfi Gassler (00:06:22 - 00:06:53)

Das Zwei-Phasen-Commit-Protokoll ist ja total simpel, es ist ja nichts anderes als, ihr habt zwei Phasen, ich frage mal alle meinen Server, hey, darf ich dort schreiben? Und indem ich frage, sperren alle Server, Diese Zeile zum Beispiel in der Datenbank, das ist die erste Phase und wenn dann alle Server aufgezeigt haben, ja, ich habe gesperrt, ich habe gesperrt, ich habe gesperrt, dann kommt der Schreibzugriff, dann wird alles geschrieben, auf allen Servern wird geschrieben und dann wird wieder zurückgeliefert, okay, Commit beendet, alles ist geschrieben. Drum zwei Phasen Commit-Protokoll. Ist einfach synchrones Schreiben auf den verschiedenen Knoten.

Andy Grunwald (00:06:53 - 00:06:55)

Klingt aber relativ langsam, oder?

Wolfi Gassler (00:06:56 - 00:07:14)

Genau das ist das große Problem. Es ist halt super langsam, weil du musst auf alle Server warten. Jetzt wenn du einen Server hast, der ist zu langsam und du hast dann 5 Server, dann sind halt alle 5 Server gleich langsam. Das heißt, du hast eigentlich wenig Vorteile. Der einzige Vorteil ist, dass du halt überall lesen kannst. Lesen geht schnell, brauchst du nicht sperren. Aber beim Schreiben bist du natürlich genauso langsam.

Andy Grunwald (00:07:14 - 00:07:18)

Und warum muss ich dann immer direkt auf alle 5 Server mit dem 2-Phasen-Comet-Protokoll schreiben?

Wolfi Gassler (00:07:19 - 00:07:45)

Ja, 5 war jetzt nur ein Beispiel, aber wenn du halt die Daten 5 mal verteilst und du willst absolute Konsistenz haben, das heißt, alle Daten zu jedem Zeitpunkt müssen überall auf den 5 Servern gleich sein, weil dir das wichtig ist, dass dein Bankkonto zum Beispiel immer den gleichen Stand anzeigt und das Bankkonto ist halt aus Sicherheitsgründen auf 3 Servern gespeichert, da musst du sicherstellen, dass alle 3 Server immer den gleichen Kontostand haben und nicht dir irgendeinen zu hohen oder zu niedrigen Kontostand anzeigt.

Andy Grunwald (00:07:45 - 00:07:53)

Aber das gibt es ja heutzutage auch noch, ne? Also es gibt ja Datenbanksysteme, da kann ich auch Daten synchron schreiben. Auf mehreren Clustern sogar, auf mehreren Nodes, Entschuldigung.

Wolfi Gassler (00:07:53 - 00:08:16)

Natürlich, ist ganz klassisches System. Also kannst du machen, vor allem wenn die Geschwindigkeit nicht so relevant ist, ist das natürlich das einfachste System, weil das hundertprozentige, also mehr oder weniger hundertprozentige Sicherheit dir garantiert. Weil sogar in einem Split-Brain-Fall schaltet deine Datenbank einfach ab und ist halt nicht mehr da. ist auch eine gewisse Sicherheit. Dein Kontostand bleibt garantiert gleich, aber die Datenbank ist halt nicht mehr erreichbar.

Andy Grunwald (00:08:16 - 00:08:28)

Aber das, was du jetzt gerade beschreibst, da sind wir schon mitten drin im Cup-Theorem, beziehungsweise das, was du beschrieben hast, ist ein großer Teil davon. Und fangen wir mal an, da reinzugehen. Und ich möchte mit einem Vergleich starten, den eigentlich jeder kennt.

Wolfi Gassler (00:08:29 - 00:08:31)

Lass mir raten er hinkt aber na start mal los.

Andy Grunwald (00:08:31 - 00:08:57)

Der hinkt nicht der ist super und zwar ist es der typische handwerksvergleich ja ich habe ich beauftrage jemand der baut mir eine garage und natürlich möchte ich es günstig haben ich möchte es natürlich morgen haben schnell ja und natürlich in einer sehr hohen qualität. Das bedeutet billig, schnell und gut. Und was sagt der Handwerker zu mir? Ja, so wünsche ich das leider jeder, aber wählen Sie zwei. Und jetzt stellt sich natürlich die Frage, was wähle ich? Billig und schnell?

Wolfi Gassler (00:08:57 - 00:09:00)

Moment, billig und gut. Wie geht billig und gut?

Andy Grunwald (00:09:00 - 00:09:27)

Prinzipiell würde ich dir jetzt antworten, okay, dann ist es halt nicht schnell, aber du hast da auch schon wieder unglaublich was getroffen und zwar ist auch das also wie geht eigentlich billig und gut, aufs Cup-Theorem übertragbar und zwar mit der Partition Tolerance. Aber da kommen wir gleich zu, wenn wir da einmal sind. Generell gibt es aber bei diesen drei Möglichkeiten, wenn du zwei wählen solltest, gar keinen richtig oder falsch, denn es ist immer irgendwie ein Trade-Off.

Wolfi Gassler (00:09:27 - 00:09:50)

Ich bin ja ehrlich gesagt gar kein großer Fan von diesen Dreiecken, weil mir kommt immer vor, da hat man sich dann überlegt, so ein Dreieck wäre eigentlich extrem cool, wähle zwei und dann fangt man immer an, so etwas zu erfinden, weil auch beim Cup-Theorem, ich finde das hinkt auch teilweise ein bisschen oder es verstehen viele Leute falsch. Das ist, glaube ich, ein großes Problem. Aber Andi, erklär mal, was ist dieses C, A, P und wie sieht unser Dreieck denn aus?

Andy Grunwald (00:09:52 - 00:11:39)

Werbung. Das Cup-Theorem ist in verteilten und weltweit skalierten Systemen eine große Herausforderung. Diese Art von Skalierungsproblemen findest du auch bei unserem heutigen Episodensponsor Trivago aus Düsseldorf. Millionen von Reisenden weltweit verwenden die Hotelsuchmaschine auf über 50 Länderplattformen. Das System darunter ist technisch hochkomplex, die Preisanfragen und Marktplatz-Auktionen finden in Realtime statt, es sind genug Daten vorhanden, um mit Machine-Learning-Techniken das Produkt zu verbessern und die Plattform wird aus mehreren Cloud-Regionen weltweit ausgeliefert. Die Theorie des CAP-Theorems findet also in der Infrastruktur von Trivago wirklich Anwendung. Über 300 Tech-Professionals aus allen Richtungen arbeiten daran, das Produkt nach vorne zu bringen. Durch den großen und weltweiten Scale können auch kleine Änderungen durch Dich einen großen Impact auf die User und auf die Plattform haben. Wolfgang und ich waren selbst lange Zeit ein Teil des Teams. Dort haben wir auch unter anderem gelernt, datengetrieben zu arbeiten. AB-Testing sowie schnelle datengetriebene Entscheidungen sind einige der Grundbausteine von Trivago. Dadurch lässt sich sehr viel in kurzer Zeit ausprobieren. Nicht nur im Produkt, auch in der Infrastruktur. Wenn das für dich interessant klingt, werde doch mal Teil des Teams und bewirb dich noch heute. Interessante offene Positionen findest du unter careers.trivago.com.in. Initiativbewerbungen sind ebenfalls gern gesehen. Einfach die Bewerbung an joinusattrivago.com mit dem Treff-Engineering-Kiosk senden. Alle Infos findest du natürlich auch in den Show Notes. Werbung Ende. für die Leute, die im Wolfganggrad nicht folgen können. Also das CAP-Theorem wird geschrieben CAP. Das sind die Anfangsbuchstaben von Consistency, Availability und Partition Tolerance. Und visuell wird das oft dargestellt als Dreieck, wo du immer nur eine Kante des Dreiecks wählen sollst, damit du dann zwei dieser drei Attribute wählen kannst. Denn wähle zwei, es gibt keine drei.

Wolfi Gassler (00:11:40 - 00:11:43)

Also entweder C und A, C, P, AP.

Andy Grunwald (00:11:43 - 00:12:20)

Genau, und jetzt hat Wolfgang gerade gesagt, wie geht denn billig und gut? Und da kommen wir gleich zu, denn das ist auch die höchste Kritik an der Visualisierung des Cup-Theorems in einem Dreieck. Aber lasst uns erstmal beschreiben, was das Cup-Theorem überhaupt ist. Meines Erachtens nach gehört das zu den Grundlagen des Cloud Computings, beziehungsweise zum Design von Cloud-Anwendungen generell. Also das CAP-Theorem ist anwendbar in jedem verteilten System und Cloud-Anwendungen heutzutage sind verteilte Systeme durch unendliche Skalierungsmöglichkeiten. Aber aufgrund der Zusicherung dieser Flexibilität, die du in modernen Clouds hast, musst du halt immer einen Trade-off eingehen, also immer einen Kompromiss.

Wolfi Gassler (00:12:21 - 00:12:27)

Wobei wir natürlich nur von der Datenspeicherung sprechen. Also wenn du keine Daten speichern musst, keinen State halten musst, dann ist es irrelevant.

Andy Grunwald (00:12:28 - 00:12:34)

Das ist korrekt. Aber nennen wir mal fast eine Applikation, die heutzutage keine Daten mehr speichert. Ich glaube, mein Handy speichert mehr Daten.

Wolfi Gassler (00:12:34 - 00:12:44)

Als... Ja, und du hast natürlich sogar die Metadaten. In irgendeinem Kubernetes-Cluster zum Beispiel musst du ja die Metadaten auch konsistent irgendwo halten, was für Service läuft, wo und so weiter.

Andy Grunwald (00:12:45 - 00:13:11)

Generell ist die Kernaussage des CAP-Theorems, in einem verteilten System ist es unmöglich, alle drei Eigenschaften Konsistenz, Verfügbarkeit, also Availability und Partition Tolerance, also Ausfalltoleranz zu garantieren. Bis heute wurde noch kein Beweis dargelegt, dass ein verteiltes System streng konsistent, dauerhaft verfügbar und mit einer sehr hohen Ausfalltoleranz ausgestattet werden kann.

Wolfi Gassler (00:13:11 - 00:13:20)

Erklär mal die drei Begriffe, weil konsistent ist ja gerade in der Datenbankwelt ein Wort, was sehr gerne verwendet wird und in ganz unterschiedlichen Bereichen eigentlich.

Andy Grunwald (00:13:21 - 00:14:17)

Den meisten Leuten wird im Begriff Konsistenz auch der Begriff Transaktionen irgendwie in den Sinn kommen. Generell gilt es, dass in einem verteilten System mit replizierten Daten, dass es da sichergestellt werden muss, dass nach Abschluss einer Transaktion alle Replikate den Datensatz aktualisiert haben und den gleichen Datensatz zurückgeben. Das bedeutet, alle Clients sehen zum gleichen Zeitpunkt die gleichen Daten. Dann ist deine Datenhaltung in deinem verteilten System konsistent. Jetzt gibt es natürlich bei diesen ganzen NoSQL-Datenbanken und so weiter immer noch den Begriff eventual consistent, was bedeutet, nach einer gewissen Zeit, Replizierung, asynchrone Replizierung oder ähnliches, sind die Daten wieder konsistent. Das ist richtig. Das erfüllt aber nicht die Konsistenz-Eigenschaft des Kapp-Theorems, denn die Konsistenz-Eigenschaft des Kapp-Theorems sagt strenge Konsistenz und sie wird auch als starke Konsistenz oder als immediate consistency beschrieben.

Wolfi Gassler (00:14:18 - 00:14:58)

Also wenn wir eine klassische Replikation haben, wo es eine Source gibt und eine Replica, MySQL zum Beispiel, dann haben wir da keine harte Konsistenz, weil die Replica-Node kann immer hinterherhinken, teilweise Stunden unter Umständen. Die hat zwar einen konsistenten Datenbestand in sich, aber auf dem Source, der vielleicht sechs Stunden weiter ist sozusagen in der Zukunft, der hat natürlich einen anderen Datenstand als die Replica-Node, die sechs Stunden hinterherhinkt. Also da hast du keine richtige Konsistenz, aber beide Datenbanken sind natürlich in sich konsistent. Das schon, aber eben nicht den gleichen Datenstand. Also wir sprechen da wirklich vom konsistenten Datenstand auf allen Nodes.

Andy Grunwald (00:14:58 - 00:15:07)

Wenn ich jetzt aber eine einzelne MySQL-Node habe, also ein Server mit einer MySQL-Datenbank, ich mache da ein Insert, dann ist das ebenfalls konsistent, weil da gibt es.

Wolfi Gassler (00:15:07 - 00:15:13)

Ja nichts zu interpretieren. Da ist dann sowieso alles konsistent. Da ist ACID-Consistency, normale Consistency, da ist alles konsistent, klar.

Andy Grunwald (00:15:13 - 00:15:26)

Kommen wir zu den Buchstaben A, Availability. Auf deutsch Verfügbarkeit. Es wird übersetzt als die Verfügbarkeit im Sinne einer akzeptablen Antwortzeit.

Wolfi Gassler (00:15:26 - 00:15:27)

Whatever that means.

Andy Grunwald (00:15:28 - 00:16:04)

Whatever this means ist richtig. Fünf Sekunden halte ich nicht für akzeptabel, beziehungsweise die heutige Kundschaft hält das nicht mehr für akzeptabel. Aber es wird mehr oder weniger beschrieben als alle Anfragen, die an das System gestellt werden, werden stets beantwortet, auch wenn ein Server oder ein ganzes Datacenter ausfällt. Das bedeutet, alle Clients können zu jeder Zeit Lese- und Schreibzugriffe durchführen, die natürlich dann auch vom System beantwortet werden. Eine Antwort hier muss nicht immer eine erfolgreiche Antwort sein. Es kann auch ein Fehlerfall sein, solange die Applikation läuft und verfügbar ist. Das muss man natürlich sagen. Wenn du eine scheiß Anfrage machst und dein Programm mit einem Fehler reagiert, dann ist sie trotzdem verfügbar.

Wolfi Gassler (00:16:04 - 00:16:23)

Wichtig ist vielleicht auch, dass wir von Schreibzugriffen genauso sprechen. Es ist nicht nur rein Lesezugriffe, sondern auch Schreibzugriffe. Wenn man nur Lesezugriffe betrachtet, wäre natürlich die Welt schön einfach und simpel. Aber in der Realität haben wir natürlich auch Schreibzugriffe. So, und jetzt kommt dieses berühmte P oder B, wie wir Österreicher sagen, Partition Tolerance.

Andy Grunwald (00:16:23 - 00:16:25)

Wieso nennt ihr das B?

Wolfi Gassler (00:16:25 - 00:16:28)

Ja, bei uns ist alles B. BP ist ja alles das Gleiche.

Andy Grunwald (00:16:28 - 00:16:29)

BP ist ein Ölkonzern.

Wolfi Gassler (00:16:29 - 00:16:32)

Ja, siehst du, da ist auch BB, genau.

Andy Grunwald (00:16:32 - 00:17:08)

Nee, jetzt geht's eigentlich um das Wesentliche, worum auch immer so ein bisschen gezankt wird, und zwar ist das die Partition Tolerance beziehungsweise die Ausfalltoleranz. Da geht's wirklich um die Ausfalltoleranz der Rechner beziehungsweise Servernetze. Und wenn dein System Partition Tolerant ist, dann bedeutet das, dass das System auch weiterarbeitet, wenn es partitioniert wird. Das heißt, wenn Knoten nicht mehr miteinander kommunizieren können, um zum Beispiel Daten miteinander auszutauschen oder konsistent zu halten. Das bedeutet natürlich auch, dass das System weiterarbeiten muss, wenn einzelne Knoten nicht mehr miteinander kommunizieren können. Und das ist natürlich, ich sage mal, die hohe Kunst des Cloud Computings.

Wolfi Gassler (00:17:08 - 00:18:07)

Und genau da kommt eigentlich mein Punkt rein, dass sich da wieder irgendwer überlegt hat, damals der Brewer, der das veröffentlicht hat, dass man das in so einem Dreieck eigentlich vielleicht darstellen könnte, was ja eigentlich gar nicht so richtig ist, weil du wählst ja nicht eine der drei Ecken oder zwei der drei Ecken, sorry, sondern was du ja eigentlich mit dem Cap-Theorem sagst, ist im Falle einer Situation, wo du zwei Partitionen hast, also irgendeinen Ausfall, dann musst du zwischen Availability oder Consistency wählen. Also eigentlich ist es relativ vereinfacht, das Ganze auf einen Satz. Im Falle eines Ausfalls musst du eben wählen zwischen C oder A. Und eigentlich, du kannst nicht nur CP wählen, weil CP wäre der Fall eigentlich, wenn alles funktioniert. Also das ist eigentlich genau das, was du mit billig und gut gemeint hast. Also man kann eigentlich nicht alles wählen in diesem Dreieck. Drum würde ich das einfach immer runterbrechen auf den Satz im Falle von einem Ausfall, wo sie wählen Consistency oder Availability.

Andy Grunwald (00:18:07 - 00:18:56)

Du hast vollkommen recht, du hast genau die Kritik angebracht, die viele Leute beim Cup-Theorem an den Tag legen, dass man gar nicht alle Kanten des Dreiecks wählen kann, weil in einem verteilten System Partition Tolerance einfach nicht wegdenkbar ist. Partition Tolerance, Netzwerkausfälle, unreliable Netzwerk und so weiter. hast du einfach in der realen Welt, das ist einfach da. Und deswegen wird auch besagt, dass das CAP-Theorem eigentlich nur ein Trade-Off bezüglich Consistency und Availability ist, so wie du grad gesagt hast. Und deswegen der Handwerksvergleich grade, billig und gut, weiß ich jetzt nicht wirklich, ob's geht. Aber warum es eine Datenbank gibt, die sagt, wir sind verteilt, aber müssen keine Partition Tolerance unterstützen, dazu kommen wir später, weil wir gehen natürlich gleich auch noch mal ein bisschen in die Praxis. Und da versuchen wir, deinen Punkt mal ein bisschen zu widerlegen.

Wolfi Gassler (00:18:56 - 00:20:37)

Und ich glaube, das ist jetzt eben ganz wichtig, dieses CAP-Theorem, die eben zeigt, wie du am Anfang schon auch richtig erwähnt hast, es gibt keine Datenbank, die alles ermöglicht. Und viele Leute vergessen diese Problematik von verteilten Systemen. Die setzen eine Datenbank ein, die setzen eine verteilte Datenbank ein, setzen so einen Postgres Cluster auf, einen MySQL Cluster. denken sich, das funktioniert eh alles schön, das ist super sicher, wie meine Single Instance MySQL und denken aber nie an diesen Problemfall, wenn eben ein Ausfall ist in diesem KAP3-Eck, weil dann habe ich genau ein Problem und dann muss die Datenbank das handeln, teilweise muss ich es auch selber handeln, teilweise gibt es Konflikte und da gibt es dann meistens Probleme, die nicht mehr so einfach zu beheben sind. Und die Datenbank kann über ein Jahr super laufen und irgendwann hat sie dann dieses Problem und dann sind die meisten Leute überfordert, weil die nie daran gedacht haben, dass das irgendwo ein schweres Problem irgendwann einmal auftreten kann, weil die Datenbank managt ja alles selber im verteilten Betrieb. Aber in der Realität ist es eben so, dass genau, wenn man ein Problem hat, muss man plötzlich die ganzen Details verstehen, alles von der Architektur, wie läuft das? Und da hat man halt dann meistens diesen Stress. Und darum sehe ich das so als großes Problem an, dass man einfach so verteilte Datenbanken auf ein Problem wirft. Und MongoDB war damals der klassische Fall, wo alle gesagt haben, out of the box, es skaliert, es kann einfach draufwerfen. Und es haben viele die Rechnung dann später bezahlt, wie sie dann in Probleme gelaufen sind. Und das hängt gar nicht mit der MongoDB-Datenbank zusammen, vielleicht auch, aber ich glaube, es passiert mit jeder Datenbank. Wenn man halt diese ganzen Komplexitäten, die im Hintergrund da ablaufen, nicht versteht, dann wird man irgendwann in Probleme rennen, die wesentlich komplexer sind als bei einer Single Instance.

Andy Grunwald (00:20:37 - 00:21:19)

Wie MongoDB das Cup-Theorem umsetzt, beziehungsweise wofür MongoDB sich entschieden hat, da kommen wir gleich auch noch zu. Aber fühlen wir uns mal ganz kurz vor Augen, was es eigentlich bedeuten würde, wenn ein verteiltes System alle drei Eigenschaften erfüllen würde. Das würde bedeuten, dass bei einer Unterbrechung der Verbindung zwischen deinen Nodes, dass das System weiterhin antworten muss, also verfügbar ist. also auf anderen Orten reagieren muss, und zwar konsistent. Und jetzt kommt's. Und wenn nun Daten auf einer Node geändert werden, müsste theoretisch mit einer unterbrochenen Verbindung die Daten auf den anderen Nodes ebenfalls konsistent gehalten werden, was natürlich nicht funktioniert.

Wolfi Gassler (00:21:20 - 00:22:11)

Also man kann sich das ganz gut vorstellen, man hat zwei Datacenters, eines in Amerika, eines in Europa und die Leitung zwischen diesen Datacenters bricht. Dann willst du natürlich deinen europäischen Kunden weiterhin die Datenbank zur Verfügung stellen und deinen amerikanischen. Aber es ist ganz klar, wenn beide schreibend zugreifen, wirst du irgendwie ein Problem haben, wenn diese fette Leitung zwischen Amerika und Europa nicht mehr da ist. Egal wie viele Server hast, egal wie viele Replikationen du hast, egal wie oft du Daten doppelt irgendwo speicherst, du wirst dieses Split-Brain haben zwischen Europa und Amerika. Und genau das ist eigentlich dieses unlösbare Problem, was das CAP-Theorem auch beschreibt und wo es keine sinnvolle Lösung gibt, sofern du deinen europäischen Kunden und den amerikanischen Kunden weiterhin dein Service anbieten willst. Wenn du natürlich sagst, okay, in dem Fall ist mein Service nicht mehr verfügbar, dann ist es ja in Ordnung, aber das ist genau dieses Availability, was dann wegfällt.

Andy Grunwald (00:22:12 - 00:22:21)

Genau, weil das ist jetzt der harte Trade-Off. Wie entscheidest du dich, das System zu betreiben? Entweder inkonsistent oder gar nicht. Was gibst du also auf? Entweder Consistency oder Availability.

Wolfi Gassler (00:22:21 - 00:22:24)

Und so einfach ist die SCAP-Theorie. Schon alles erklärt.

Andy Grunwald (00:22:24 - 00:22:45)

Wahnsinn. Vielen Dank. Willkommen zu meinem Tech-Talk. Ich wünsche euch noch einen schönen Tag. Nee, der Clou ist ja, das hört sich alles jetzt total einfach an. Ja, klar, habe ich verstanden. So, und jetzt geht mal bitte zu euch in die Firma. Und jetzt sprecht mal mit euren Teamkollegen. Wie soll sich euer System in diesem Fehlerfall verhalten? Und ich gehe stark davon aus, du hast eine andere Meinung. als der Produktmanager, als seine Chefin und Co.

Wolfi Gassler (00:22:45 - 00:22:49)

Ja, aber Moment, wir haben doch einfach diesen Postgres Cluster installiert und er macht doch alles für uns.

Andy Grunwald (00:22:49 - 00:23:26)

Wir möchten nochmal in Erinnerung rufen, nicht nur bei Reed, sondern auch bei Ride Operations. Und das ist ja die Kündigsklasse. Aber ich bin immer ein Fan davon, wo kommt die Klamotte denn immer her? Ja, also ich meine, Cup Theorem, seit wann gibt's das? 70er, 80er, 60er? Nee, ist gar nicht so alt. Und zwar hat Eric Brewer, hat inzwischen auch mal bei Google gearbeitet, glaube ich. Ist Professor am MIT aktuell, glaube ich. Hat's erst im Jahr 2000 vorgestellt in der Keynote, beziehungsweise 1999 in dem Paper veröffentlicht. Also, das Kapitalismus ist noch gar nicht so alt. Irgendwie so 23 Jahre. Wow, hab ich mir gedacht. Auf jeden Fall ...

Wolfi Gassler (00:23:26 - 00:24:34)

Es ist ja schön, dass du immer mit der Historie ankommst, weil eigentlich würde man das ja von mir als Wissenschaftler erwarten. Auch vielleicht zu meiner Theorie, warum das erst so spät aufgekommen ist. Das Problem gibt's natürlich schon lange, muss man auch dazusagen. Es wurde halt nicht in dieser Form beschrieben. Aber man muss ja auch schauen, wenn man sich die Hardware so ansieht und was so bis in die 90er Jahren eigentlich passiert ist, dann war das halt meistens Mainframe-Systeme, alles auf einem System, möglichst synchron. Datenbanken wurden synchron, wie wir schon beschrieben haben, mit dem Zwei-Phasen-Commit einfach repliziert bzw. das Commit durchgeführt. Das heißt, es war alles eher so Single-Node-Architektur. Und erst in den 2000ern ist es eigentlich so langsam dieses ganze, ich will es jetzt nicht Cloud Computing nennen, aber Multithreading, das Verteilen über Nodes. Google hat damit angefangen, im großen Stile mit MapReduce dann auch das auf mehrere Knoten zu verteilen. Also diese ganze Verteilung im Sinne, wie wir es heute kennen in der Cloud, die ist eigentlich erst so in den späten 90ern bis 2000ern eigentlich überhaupt langsam aufgekommen. Und darum auch meine Vermutung, dass es dementsprechend spät so einen Anklang gefunden hat oder halt dementsprechend auch beschrieben wurde.

Andy Grunwald (00:24:34 - 00:25:00)

Ein weiterer Grund hat Eric Brewer bei der Vorstellung mitgegeben, und zwar sagte er, dass sich so um 1999, 2000 die ganze Forschung um verteilte Systeme eigentlich primär auf verteilte Berechnungen bezogen hat und nicht auf die verteilte Speicherung von Daten. Denn Berechnungen kann man immer wieder neu berechnen, auch wenn eine Node hops geht, aber ein persistenter Zustand in verteilten Systemen ist halt ein echt schwieriges Problem.

Wolfi Gassler (00:25:01 - 00:25:15)

Es war damals einfach keine Datenbank am Markt, die da irgendwie so ein Cluster oder sowas angeboten hat. Du hast da die großen Player mit DB2 auf ihren Mainframes gehabt, aber es war alles Single-Core-Architektur und alles vertikal skaliert.

Andy Grunwald (00:25:15 - 00:25:43)

Ich bin immer noch ein riesen Fan von IBM Mainframes und ich weiß inzwischen auch, dass ein IBM Mainframe auch ein Kubernetes betreiben kann und das nenne ich wirklich reale vertikale Skalierung. Weil ich würde gerne mal mit jemandem sprechen, der ein Kubernetes auf einem Mainframe betreibt, der muss ja mit Network Partitions eigentlich nichts mehr im Hut haben, oder? Ich meine, der muss ja das beste Leben haben, keine Netzwerkprobleme, alles super. Weil wie viel CPUs und wie viel RAM hat so ein Ding? So ein aktueller Z7, das ist schon ordentlich, glaube ich, oder?

Wolfi Gassler (00:25:43 - 00:25:51)

Viel, würde ich mal sagen, glaube ich zumindest. Also falls jemand übrigens irgendwen kennt, der sich sehr gut mit Mainframes auskennt, bitte unbedingt uns eine Message schicken.

Andy Grunwald (00:25:51 - 00:26:56)

Kommen wir zurück zur Geschichte. Und zwar Eric Brewer hat damals ganz stark an globalen Suchmaschinen und verteilten Webcaches gearbeitet. Und beide zählen halt zu dem Bereich der verteilten Systeme. Im Bereich der verteilten Systeme hast du ein System verteilt auf mehrere Nodes und was hast du da natürlich ein Netzwerk dazwischen und wie Werner Vogels schon gesagt hat, everything fails all the time. Somit hast du natürlich ein instabiles Netzwerk. Das bedeutet, Network Partitions hast du dauerhaft. Jetzt hast du aber das Problem, wenn du nämlich ein State hast, einen persistenten Zustand, den du auch behalten möchtest, dass du dein System halt, wie das CAP Theorem halt sagt, dich zwischen Consistency und Availability entscheiden musst. Im Jahr 2000 gab's dann eigentlich mehr oder weniger nur zwei, ich nenn's mal Begriffe. Und zwar auf der einen Seite ist das ACID, aus der klassischen relationalen Datenbankwelt, auf der anderen Seite ist das BASE. ACID, wir erinnern uns, damals aus der Uni oder aus dem Informatikunterricht, Transaktionen und so weiter. Atomar, konsistent, isoliert und dauerhaft.

Wolfi Gassler (00:26:56 - 00:26:59)

Hättest du das jetzt hinbekommen ohne Notes? Nee.

Andy Grunwald (00:27:01 - 00:27:10)

Aber ich meine, das muss ich auch nicht. Also ich meine, wie oft, ich habe noch nie irgendwie in letzter Zeit gesagt, ja hör mal, sorry, aber deine Operationen sind jetzt hier nicht Asset-konform.

Wolfi Gassler (00:27:11 - 00:27:48)

Also ich kann mich erinnern, ich war mal auf einer Konferenz und da war damals der Chefentwickler von dem neuen Datenbank-Storage-Format von MariaDB, ist schon lange her. Es hat auch damals noch anders geheißen, ich habe es leider vergessen, irgendwas mit A. Und er hatte im Vortrag ewig lang nach ACID gesucht, nach dem Vote, und hat gemeint, da gibt es ja dieses wissenschaftliche Zeug, was man da irgendwie so, dass es irgendwie beschreibt und so weiter. Und das Publikum hat ihm weiterhelfen müssen, weil er hat keine Ahnung von dieser wissenschaftlichen Annäherung gehabt. Es war für mich unverständlich, wie man Datenbanksysteme entwerfen kann, wirklich eine Storage Engine, ohne dass man ACID versteht, aber in dem Fall war es so.

Andy Grunwald (00:27:49 - 00:28:30)

Naja, ich glaube, Asset ist aus der Welt der relationalen Datenbanken nicht mehr wegzudenken, aber man muss sich den mal im Hinterkopf behalten, wenn wir von Asset reden und wenn wir auch von verteilten Systemen sprechen, dann tauschen wir eigentlich die Isolation und die Konsistenz gegen die Performance, weil Wie Wolfgang auch schon sagte, das konsistente Schreiben von Daten auf mehrere Nodes geht halt zulasten der Performance. Auf der anderen Seite hat es natürlich ein paar tolle Attribute, wie zum Beispiel, es ist halt wirklich stark konsistent, alles ist isoliert, alles, wenn etwas committed auf der Disk ist, dann ist das auch wirklich gespeichert. Hat natürlich auch ein paar Nachteile, wie zum Beispiel die Hochverfügbarkeit oder halt die schwierige Evolution deines Schemas oder ähnliches.

Wolfi Gassler (00:28:31 - 00:29:12)

Und ich glaube, das ist das große Problem, was viele dann auch bei der Verteilung vergessen oder bei der MongoDB, was es auch immer ist, da steht irgendwie Base und Eventually Consistent. Das heißt aber nicht, dass ich keine Daten zum Beispiel verlieren kann. Wenn mir da am Weg irgendwo ein Server wegbricht und es ist noch nicht sinnvoll repliziert worden, dann ist es nicht Eventually Consistent. dann ist es unter Umständen einfach weg, je nachdem wie die Implementierung ist, muss man auch dazu sagen, aber man muss da wirklich ins Detail gehen, um zu verstehen, wie funktioniert es und was wird da geschrieben und was eben nicht und wie sicher ist dann am Ende meine Datenbank. Also das ist nicht vergleichbar mit, wie gesagt, mit einer Single Instanz. Das muss man ganz klar sehen, auch wenn da Datenbank und sicher und alles drüber steht.

Andy Grunwald (00:29:13 - 00:29:40)

Und weil du schon von Verständnis gesprochen hast, schaffen wir jetzt mal ein bisschen Verständnis um den damaligen NoSQL-Hype. Weil damals, als die ersten NoSQL-Datenbanken hochkamen, gab's in der Regel immer nur ACID. Und das, was ACID für die Relationale Datenbank ist, ist Base für NoSQL-Datenbanken, beziehungsweise oft für NoSQL-Datenbanken. Base steht für Basically Available, Soft State, Eventually Consistent. Hört sich an wie ein Buzzword-Bingo. Kannst auch deine Hand heben, du hast den Pott gewonnen.

Wolfi Gassler (00:29:41 - 00:30:10)

Ich war zwar selber sehr froh, wie wir unsere Datenbank-Vorlesung, die wir gegeben haben in unserer Forschungsgruppe, erweitern haben können durch diesen Begriff BASE. Kommt immer cool. Neues Akronym. Kann man auch prüfen. In der Klausur. Ist immer ganz praktisch. Aber meiner Meinung nach ist es absolut Bullshit. Da ist irgendwer dahergekommen und hat gedacht, wir müssen jetzt irgendwas gegen ACID in die Welt setzen. BASE klingt cool. Säure und basisch. Ideal. Alles cool. Und hat sich, glaube ich, danach überlegt, was das eigentlich bedeutet.

Andy Grunwald (00:30:10 - 00:30:37)

Und es ist wirklich fast das Gegenteil wie ACID, wo ACID stark konsistent ist, legt BASE den Fokus auf Availability. Ungefähre Antworten sind okay. Man hat eine schwache Konsistenz, also man kriegt eventual consistent data nach einer Replikation oder ähnliches. Man hat gegebenenfalls überhaupt kein Schema. Siehe MongoDB, man speichert irgendwelches B.Json. Es ist halt einfach nur, ich sag mal, einfacher gehalten, dafür natürlich auch enorm performant.

Wolfi Gassler (00:30:38 - 00:31:04)

Und es ist nicht genau definiert, das ist ja auch das Problem. Also dieses ganze Basically Available ist ja auch nicht stark definiert. Bei ACID hast du eine ganz starke Definition, was bedeutet das ACID, was bedeuten die Buchstaben, was heißt es, wenn isoliert wird, was gibt es für Isolationslevels und so weiter. Bei BASE hast du das eigentlich kaum und darum ist es halt einfach so wieder ein Bingo-Wort, was mal erfunden wurde und meiner Meinung nach wenig Sinn macht.

Andy Grunwald (00:31:05 - 00:31:15)

Du sagst, dass das nicht definiert ist, ist ein Problem. Ich sage, für mich als NoSQL-Datenbank-Hersteller ist das eine, wie soll ich sagen, Möglichkeit. Da kann ich machen, was ich möchte.

Wolfi Gassler (00:31:15 - 00:31:28)

Es ist ein sehr komplexes Thema und ich glaube nicht, dass es mit vier Buchstaben in irgendeiner Form abgedeckt ist, weil es da eben so viele kleine Feinheiten gibt, wie sich Systeme in dieser verteilten Welt verhalten und weil das so komplex ist.

Andy Grunwald (00:31:28 - 00:32:10)

Okay, jetzt kann man aber sagen, Acid und Base, ich kann nur eins wählen. Ja, falsch. Eric Brewer hat damals gesagt, okay, Acid und Base, das ist kein entweder-oder, sondern das ist halt ein Spektrum. Und damals hat er gesagt, okay, wir stellen was Neues vor, wir stellen das Cup-Theorem vor, und das Cup-Theorem wird ab und zu auch Brewer-Theorem genannt. wo es wirklich das Spektrum ist zwischen Consistency, Availability und Partition Tolerances. Und wenn wir sagen, man kann nur zwei aus den drei Eigenschaften wählen, dann hat man natürlich gewisse Ausprägungen. Man kann zum Beispiel sagen, okay, mein System ist konsistent und toleriert Network Partitions. Das bedeutet natürlich auch, wenn die Konsistenz der Daten nicht mehr gewährleistet werden kann, ist das System nicht mehr verfügbar.

Wolfi Gassler (00:32:11 - 00:32:13)

Oder read-only zumindest.

Andy Grunwald (00:32:13 - 00:32:41)

Was laut Cup-Theorien dann auch nicht verfügbar ist, weil du keine Daten mehr schreiben könntest. Und oft als sehr High-Level-Beispiel, was ich eigentlich nicht so mag, aber irgendwie ist es halt wahr, werden oft Banking-Anwendungen angeführt. Denn wenn der Geldautomat die Konsistenz der Daten nicht mehr halten kann, dann wird der Geldautomat selbst halt nicht verfügbar gemacht, denn die Verfügbarkeit ist in diesem Sinne zweitrangig, denn die Konsistenz der Daten, der Finanzdaten, hat halt einfach höchste Priorität. Also wenn zum Beispiel eine Störung im Datenverkehr ...

Wolfi Gassler (00:32:41 - 00:32:43)

Warum findest du das Beispiel nicht so cool?

Andy Grunwald (00:32:43 - 00:32:48)

Ich find das, weil, ich weiß nicht, aber das wird immer angeführt.

Wolfi Gassler (00:32:48 - 00:32:52)

Vor allem bin ich mir gar nicht sicher, ob's wirklich stimmt im Hintergrund so.

Andy Grunwald (00:32:52 - 00:32:55)

Auch das, ich find, das ist zu high-level, dieses Beispiel.

Wolfi Gassler (00:32:56 - 00:33:15)

Also ich glaube, dass da wesentlich mehr Schritte schon dazwischen dann ablaufen und da selten auf die Datenbank committed wird in so einem Geldautomat, meiner Meinung nach. Aber es eignet sich zumindestens gut, um das darzustellen, wo es vielleicht Sinn machen würde, in was für einem Umfeld zumindestens würde es Sinn machen, die Datenbank einfach abzuschalten, bevor man Inkonsistenzen überhaupt erlaubt.

Andy Grunwald (00:33:16 - 00:34:07)

Wenn natürlich jetzt die Network Partition, also die Verbindung zwischen den Nodes wiederhergestellt ist, dann beginnt in der Regel, in der Praxis oft eine Art Replikation, dann wird die Konsistenz wiederhergestellt und danach wird das ganze System auch erstmal wieder für zum Beispiel jetzt hier Schreibzugriffe verfügbar gemacht. Die nächste Ausprägung wäre dann eigentlich die Availability und die Partition Tolerance. Und jetzt, finde ich, kommt ein richtig schönes Beispiel. Und zwar sind es entweder Caching-Systeme oder das DNS-System. Denn das DNS-System hat durch die Layer-Struktur eine enorm hohe Verfügbarkeit. Es ist also super tolerant gegen den Ausfall einzelner DNS-Server. Wenn jetzt einer der Root-Server ausfällt, so what? Die Daten sind 10.000 mal repliziert. Die Konsistenz ist aber nicht unbedingt gegeben, denn teilweise kann es halt Tage dauern, bis ein geänderter DNS-Eintrag in der ganzen Hierarchie propagiert ist. In der Praxis kommt es in der Regel nicht vor.

Wolfi Gassler (00:34:08 - 00:34:21)

Und du kannst vor allem nicht schreiben. Also meiner Meinung nach wäre das eigentlich ein falsches Beispiel, weil die Availability, hast du ja gesagt, nur schreibend. Und wenn der Server wegbricht, der die Zone ownt, kannst du eigentlich nichts mehr schreiben.

Andy Grunwald (00:34:21 - 00:34:24)

Aber eine Zone wird ja nicht nur von einem Server geownt oder von einem Cluster.

Wolfi Gassler (00:34:25 - 00:34:45)

Ja, du könntest trotzdem in Split-Brain, also in Split-Brain weniger, aber halt, dass deine Server, die die Zone verwalten, wegbrechen und dann hast du auf jeden Fall keine Availability mehr. Und das sind ja relativ wenig Server, zwei Server zum Beispiel oder so. Oder wenn das Netz eben weg ist, im Sinne von Split-Brain, dass die Netzwerkkonnection nach außen von deinem Datacenter weg ist, wo deine zwei Nameserver stehen.

Andy Grunwald (00:34:45 - 00:35:44)

Stimmt, aber ich hatte ja gerade gesagt, die ganze Sache ist halt ein Spektrum. Wenn man Availability bevorzugt über Konsistenz, dann sagt man eigentlich nur, dass man keine strenge Konsistenz erwartet, aber halt eine völlig inkonsistente Datenhaltung ist halt auch nicht erwünscht. Und da muss ich zugeben, passt das DNS-Beispiel dann schon wieder. Es wird auch oft irgendwie so Social Media, also moderne Cloud-Anwendungen als Beispiel angeführt, so Twitter oder Facebook. Denn wenn du deinen Tweet nicht schreiben kannst, interessiert es einen Großteil der Welt halt einfach nicht. Aber es ist für den Großteil der Welt besser, wenn das System verfügbar ist, anstatt dass die deinen Tweet lesen. Also das könnte man auch schon als RP-Availability und Partition Tolerance bezeichnen. Wenn halt nicht alle Nachrichten bei allen Nutzern gleichzeitig eingetroffen, eintrifft. Und ich meine, speziell in diesem Bereich AP fallen halt ziemlich viele NoSQL-Datenbanken, die sich halt als Eventual Consistent beschreiben. Und da sind wir wieder bei diesem Base, Basically, Available, Soft State, Eventual Consistent, die halt Availability über Konsistenz bevorzugen.

Wolfi Gassler (00:35:44 - 00:36:25)

Wobei natürlich auch da wieder so ein Asterix eigentlich dran ist, weil die gehen ja meistens nach irgendeinem Election-Verfahren und checken dann, wie groß ist der Cluster noch und wenn man dann kleiner als die Mehrheit ist, dann schaltet der Teil meistens ab. Also auch da wird das Split-Brain normal so in irgendeiner Form dann verhindert und es kann auch sein, dass dann Teile vom Cluster einfach sich abschalten, weil sie zu wenig sind und keine Connection mehr zur Mehrheit vom Cluster haben und dann ist der Teil eigentlich auch nicht mehr available. Also verschwimmt das Ganze natürlich auch immer drum. Wie gesagt, man muss wirklich ins Detail immer reingehen, was passiert, in was für einem konkreten Use Case. Und es gibt halt zahlreiche Szenarien, die da wirklich passieren können in so einer verteilten Welt.

Andy Grunwald (00:36:26 - 00:37:16)

Genau, bei dem, was du da ansprichst, sind wir natürlich im Bereich Quorum, wie viele Server hast du in deinem Cluster, wie viele Ausfälle kannst du akzeptieren und so weiter und so fort. Hängt natürlich sehr stark auch an der Konfiguration des jeweiligen Systems ab. Und der letzte Fall, da wo viele Leute sagen, geht eigentlich gar nicht, ist nämlich konsistent und verfügbar ohne Partition Tolerances. Was natürlich eine Frage aufwirft. Hä? Ich denke, wir sind in einem verteilten System. Genau! Und das ist nämlich die ganze Kritik an dieser ganzen Geschichte. Es geht halt nicht billig und gut, Und da werden halt oft irgendwie so Single-Site-Databases als Beispiel angeführt, also wirklich so MySQL, Postgre oder Oracle, die dann einfach gar kein Netzwerk haben oder halt auch nur eine asynchrone Replikation. Aber auf den sogenannten Followern, auf den Replikas kann man in der Regel ja nicht schreiben. Und deswegen hat man da eigentlich... Da ist halt die Frage, ist das eigentlich noch das Kapp-Theorem? Fällt das darauf zu? Ich weiß es nicht.

Wolfi Gassler (00:37:17 - 00:39:52)

Die andere Interpretation ist auch oft, dass man sagt, Consistency und Availability ist, wenn eben kein Ausfall passiert. Und da gibt es zum Beispiel auch ein anderes Theorem, was dann ungefähr zehn Jahre später auf den Markt gekommen ist, sage ich mal, von Daniel Abadie. Das war ein PhD von Michael Stonebreaker, der Postgres erfunden hat, dieser Professor. Und der hat eigentlich genau gesagt, CAP-Theorem, das bezieht sich eigentlich nur auf den negativen Fall, wenn es einen Ausfall gibt und beschreibt eigentlich nicht den Fall, wenn alles in Ordnung ist. Weil auch wenn alles in Ordnung ist, wenn deine verteilte Datenbank läuft, alle Network Connections aufrecht sind, du kannst kommunizieren in deinem Cluster, dann musst du trotzdem zwischen Latenz und Konsistenz wählen, beziehungsweise dich für eine oder die andere Richtung entscheiden, was dir wichtiger ist. Das heißt, wenn wir wieder zurückdenken an das Zwei-Phasen-Commit-Protokoll, wo du synchron committest, das heißt, du fragst jeden Server, bist du bereit zum Schreiben, jeder der aufzeigt und so weiter, wenn alle aufgezeigt haben, alle Server, dann darf geschrieben werden im Ende. Wenn man von dem weggeht, also das in irgendeiner Form asynchron macht, dann hast du ja automatisch Inkonsistenzen, weil wenn du sagst, du wartest nicht, bis alle Server geschrieben hat, bis du dein Commit beendest, deine Transaktion, dann gibt es da irgendwo Server draußen in deinem Cluster, Nodes, die vielleicht eine Sekunde hinterherhängen oder eine Millisekunde. Das heißt, du hast Inkonsistenzen. Und genau das beschreibt eigentlich dieses Buck-Elk, hat es der Abadi genannt, Theorem, also die ersten drei Buchstaben Buck, sind nur Cup umgedreht, weil es cooler klingt wahrscheinlich. Also das kommt vom Bug. Und das E steht für Else. Also wenn kein Netzwerkausfall ist, also wenn das Cup-Theorem nicht Anwendung findet, weil alles in Ordnung ist, dann musst du dich entscheiden zwischen Latenz oder Konsistenz. Also dieses LC. Das heißt Cup-Theorem, Else, LC. So ist das Bug-Elk aufgetrennt. Und das heißt eben einfach, dass du dich entscheidest, ist Latenz wichtiger oder Konsistenz und Datenbanken haben teilweise die Möglichkeit, moderne Datenbanken, dass du entscheidest, was ist dir wichtiger und das ist auch wieder ein Spektrum, aber du kannst es teilweise wirklich einstellen. Mir sind die Daten zu wichtig, mir ist die Konsistenz wichtiger, darum warte ich ein bisschen länger oder mir ist die Konsistenz nicht so wichtig, ich will lieber möglichst schnell sein, weil mir egal ist, wenn irgendwas ein paar Millisekunden hinterher hinkt, Solange das sicher alles abläuft, aber ich brauche nicht diese extrem hohe Konsistenz, die jetzt bei deinem Geldautomaten zum Beispiel bräuchte, wenn man das wieder als Beispiel bemüht.

Andy Grunwald (00:39:53 - 00:39:55)

Der Kollege hat aber auch nicht im Marketing gearbeitet mit der Abkürzung, oder?

Wolfi Gassler (00:39:55 - 00:39:57)

Buck Elk, klingt doch super.

Andy Grunwald (00:39:58 - 00:40:30)

Nee, aber das, was du sagst, ist eigentlich oft der Standard in vielen modernen Datenbanksystemen, wie zum Beispiel in Cassandra. In Cassandra kannst du pro einzelner Abfrage, pro einzelner Datenbankoperation bestimmen, nämlich das Konsistenzlevel. Und das Konsistenzlevel besagt dann natürlich auch, wie oft werden diese Daten auf wie viele verschiedene Knoten während meiner Operation geschrieben oder wie schnell kommt die Anfrage zurück. Und da ist nämlich ganz genau die praktische Umsetzung von deinem Pack-Elk-Konzept, Theorem, wie heißt das? Keine Ahnung. in die Praxis umgesetzt.

Wolfi Gassler (00:40:30 - 00:41:07)

Man kann ganz grob sagen, dass eigentlich die klassischen relationalen Datenbanksysteme wie MySQL, Postgres, aber sogar MongoDB eher auf Konsistenz gehen. Also die haben das SC und dann diese NoSQL-Datenbanken wie DynamoDB zum Beispiel oder auch Cassandra, die gehen da mehr auf Latency. Die akzeptieren das, dass eben was nicht Konsistenz ist, dafür aber super schnell gelesen werden kann oder halt geschrieben werden kann in der Datenbank. Gibt es auch im Wikipedia-Artikel vom Baccalc-Theorem gibt es so eine Tabelle, wo man genau sieht, was sind die Datenbanken auf der Bacc-Seite, also auf der CAP-Seite besser gesagt, und was sind sie auf der LC-Seite.

Andy Grunwald (00:41:08 - 00:42:20)

Ich meine, die Praxis ist natürlich noch mal ein anderes Paar Schuhe und lassen wir uns da jetzt ein bisschen einstellen. Und zwar, die meisten NOS-Gelddatenbanken sind in der Regel horizontal skalierbar, somit vom Design her natürlich verteilt. Und somit findet natürlich das Cup-Theorem seine Anwendung. Weil sie verteilt sind, sprechen wir von einem Verteiltensystem, somit sind Network Partitions erstmal schon mal gegeben. Jetzt ist aber der Begriff Network Partition auch schon recht schwierig, denn heißt das denn jetzt, alle Knoten sind wirklich voneinander abgeschnitten und können nicht mehr miteinander kommunizieren? oder können nur zwei knoten nicht mehr miteinander kommunizieren und der rest schon oder was ist eigentlich ein system mit einer schlechten netzwerkverbindung ist das dann in einem zwischenzustand also all das ist auch eine sehr sehr schwierige thematik ich meine deswegen gibt es ja auch unter anderem einen unglaublich talentierten und sehr berühmten informatiker a4 nennt er sich mit dem tool japson der eigentlich alle Datenbanken genau auf dieses Cup-Theorem, auf ihre Schreibkonsistenz und Co. testet. Der hat so ein mega Framework gebaut und wird auch bezahlt von den ganzen Datenbankherstellern, um wirklich zu gucken, okay, wo sind Race Conditions und so weiter. Der testet das ganze Cup-Theorem und ob die ganzen Marketing-Papers auch wirklich ihr Versprechen halten.

Wolfi Gassler (00:42:21 - 00:42:41)

Und der hat so in, glaube ich, jeder Datenbank schon irgendwelche Flaws gefunden. Und wie du richtig sagst, die Datenbankhersteller bezahlen den mittlerweile, dass der denen hilft, ihre Datenbank zu verbessern. Weil der hat noch in jeder Datenbank irgendwas rausgefunden und Situationen entdeckt, in denen dann eben irgendwas nicht konsistent ist oder Daten verloren gehen und so weiter.

Andy Grunwald (00:42:41 - 00:43:15)

Wir verlinken ein paar Blogposts und ein paar Tests, denn die ganzen Tests von MongoDB, Cassandra, Kafka und so weiter veröffentlicht er alle. Die verlinken wir in den Shownotes. Bevor ich wirklich tief das Cup-Theorem verstanden habe, habe ich viele dieser Blogposts nicht verstanden. Die sind sehr hart zu lesen, sie gehen sehr tief rein, sind aber unglaublich interessant. Aber du hattest gerade schon von MongoDB erwähnt, beziehungsweise schon ein paar Mal während dieser Episode. Wo befindet sich MongoDB aktuell im Cup-Theorem? Wo würdest du das einordnen? Favorisiert ist Consistency oder eher Availability?

Wolfi Gassler (00:43:16 - 00:43:22)

Also MongoDB ist Availability im CAP-Theorem und Consistency im Back-Elk.

Andy Grunwald (00:43:22 - 00:43:55)

Meines Erachtens nach stimmt das nämlich nicht. Meines Erachtens nach ist nämlich MongoDB Consistency und Partition-Tolerant, weil MongoDB selbst ein Single-Master-System hat und jedes Replica-Set nur auf einem Primärknoten liegt. Und somit sind Schreiboperationen, wenn der Primärknoten für ein Replikaset abstürzt, nicht mehr gegeben. Ich meine, der Sekundärknoten, die Replika, wird irgendwann zum neuen Primärknoten. Aber in der Zeit, bis das gegeben ist, bis der Sekundärknoten nicht zum neuen Master elektet wurde, ist das System nicht verfügbar. Zumindest auf diesem Replikaset.

Wolfi Gassler (00:43:55 - 00:44:06)

Ja, ich kann dir da jetzt auch wenig widersprechen. Ich kenn mich zu wenig aus wie MongoDB, wie schnell die Leader Election oder sonst irgendwas stattfindet. Aber ich glaub dir jetzt einfach mal. Auch wenn Wikipedia was anderes sagt, natürlich.

Andy Grunwald (00:44:07 - 00:44:51)

Ich meine, das Problem ist beim MongoDB, du hast natürlich solche Geschichten wie natürlich eine Read Preference, wo du die Availability einfordern kannst, aber die Konsistenz vernachlässigt. Dann hast du bei deinen Schreiboperationen das Setting Right Concern, wo du natürlich auch festlegen kannst, wie viele Notes den Datensatz geschrieben haben müssen. Also du merkst schon, ich glaube, du kannst den Fall je nach Design und Datenhaltung und Konfiguration deiner Datenbanken halt auch irgendwie für beide Sachen machen. Aber, wie auch schon am Anfang erwähnt, du musst genau wissen, was du tust. Du musst wissen, wann kannst du bei deinen lesenden Operationen auf Konsistenz verzichten? Wann kannst du bei einem möglichen Note Outage bei deinem Schreibzugriff auf Konsistenz verzichten oder auf Performance? Und da frage ich mich, wie viele Leute machen sich wirklich über diese Settings Gedanken?

Wolfi Gassler (00:44:51 - 00:45:13)

Ja und wie du schon gesagt hast, es hängt ja auch wirklich von der Anzahl der Knoten immer ab. Also was heißt denn Fall Tolerance? Die Fall Tolerance hat ja meistens auch eine Zahl irgendwo dran, wie viele Knoten können ausfallen. Die kannst du ja auch ändern unter Umständen und das hat dann natürlich auch dementsprechend Einfluss auf Availability, weil wenn dir ganz viele Knoten wegbrechen, einfach dann ist es klar, dann wirst du nie Availability haben, logisch.

Andy Grunwald (00:45:14 - 00:46:08)

Wenn wir uns Kassandra mal ansehen, Kassandra ist eigentlich nicht weit entfernt. In den Default Settings bevorzugen sie Availability über Consistent. Du kannst die ganze Sache aber auch mit geringerter Availability und höherer Konsistenz fahren. Denn Kassandra hat so eine tolle Geschichte wie ein sogenanntes Consistency Level. Und zwar kannst du jeder Operation, also Read oder Write, kannst du bei Kassandra mitgeben, okay, welches Consistency Level erwarte ich denn für diese Operation? Und das kann wirklich ... Bei einer Schreiboperation kannst du sagen, okay, schreibe das bitte auf das Quorum. Das bedeutet, wenn du wirklich ... Also, auf die Masse aller Nodes oder auf alle Nodes oder nur auf zwei Nodes oder auf eine Node. Also, du kannst wirklich ganz klar steuern, auf wie viele Nodes der Datensatz geschrieben werden soll, von wie vielen Nodes ich diesen lesen kann. Und umso höher natürlich dieses Consistency-Level gesetzt wird, desto mehr leidet natürlich die Verfügbarkeit der ganzen Thematik.

Wolfi Gassler (00:46:09 - 00:46:18)

Und das ist genau dieses LC Tradeoff bei BuckELC, das du dort einstellen kannst, wo du wirklich eben das dynamisch setzen kannst und das das wirklich beeinflusst.

Andy Grunwald (00:46:19 - 00:46:49)

Also wenn du jetzt drei Nodes hast in deinem Cassandra Cluster und du das Consistency Level auf drei gesetzt hast und eine Node fehlt, ist der Cluster halt nicht mehr verfügbar, aber konsistent. Also, mach dir halt Gedanken, was du für Daten speicherst, wie du die speicherst. Und dann hast du nämlich da auch eigentlich keine Probleme. Aber jetzt bist du natürlich der große Verfechter von, das CAP-Theorem ist nur für Datenbanken. Und ich sag, das CAP-Theorem ist für verteilte Systeme. Was sagst du denn zu Kubernetes und dem CAP-Theorem?

Wolfi Gassler (00:46:49 - 00:47:20)

Ja, für Kubernetes selbst ist es natürlich quasi egal, aber ich vermute auch, dass Kubernetes Metadaten irgendwo speichert. Und diese Metadaten musst du ja auch in irgendeiner Form verfügbar halten und verteilt verfügbar halten, sonst kann dir ja nie irgendein Node wegbrechen. Wenn dir der Node wegbricht, wo du alle Metadaten gespeichert hast, ist alles tot. Das wirst du ja auch verhindern. Das heißt, du musst die Daten irgendwie wieder verteilen. Ich vermute ja, Kubernetes hat das nicht neu erfunden. Ich vermute, die verwenden unter der Haube auch irgendein Datenhaltungssystem.

Andy Grunwald (00:47:20 - 00:47:24)

So viel ich weiß, nutzen die ETCD unten drunter. Eben.

Wolfi Gassler (00:47:24 - 00:47:29)

Ist ja sehr beliebt in der Welt. Super leichtgewichtige Datenbank, verteilte Datenbank.

Andy Grunwald (00:47:30 - 00:48:00)

Ich meine, im Endeffekt, Kubernetes ist designt und optimiert, hochverfügbare Workloads zu schedulen. Und auch wenn eine Kubernetes-Node halt nicht mehr zum Master kommunizieren kann, werden trotzdem noch User-Requests beantwortet. Die müssen dann nicht unbedingt konsistent sein von der Pod-Konfiguration, aber sie werden beantwortet. Und somit fällt Kubernetes eigentlich unter einen AP-System, also Favored Availability über Consistency.

Wolfi Gassler (00:48:00 - 00:48:16)

Natürlich, aber das hängt natürlich auch von den Services ab, die dort laufen haben, weil wenn die Services natürlich auf irgendeine Datenbank oder so zugreifen müssen oder irgendwas lesen müssen über das Netzwerk, dann sind sie zwar verfügbar, die Bots oder die Services, aber sie können halt keine sinnvollen Anfragen beantworten.

Andy Grunwald (00:48:17 - 00:48:54)

Ja, ja, klar, ich rede jetzt nur vom Kubernetes Kernsystem. Ich rede nicht von den Applikationen, die du auf Kubernetes hostest. Das ist natürlich ein wichtiger Punkt, den du erwähnst, denn für jede Applikation selbst musst du beurteilen, was du favorisierst. Und wenn du natürlich auf Kubernetes etwas favorisierst, was konsistent höher liegt als der Availability, dann musst du halt in einer Applikationsprobe gucken, wie du damit umgehst. Du kannst die beiden halt nicht irgendwie miteinander verheiraten und sagen, okay, Kubernetes ist available, meine Datenbank ist consistent, oder passt das, dann habe ich ein System mit allen drei. Das funktioniert halt jetzt so nicht, sondern du musst jedes System halt schon einzeln betrachten.

Wolfi Gassler (00:48:54 - 00:49:38)

Und du hast ja natürlich auch andere Datenhaltungssysteme darunter, wenn du ein verteiltes Filesystem hast, zum Beispiel irgendein ClusterFS zum Beispiel, dann hast du dann natürlich die gleichen Probleme, die du in der verteilten Welt oder in der verteilten Datenbankwelt hast, weil ob du jetzt eine Datei speicherst oder eine Tabelle speicherst, ist ja im Prinzip dasselbe. Also auch da wieder liegt extrem viel darunter. Darum ist meiner Meinung nach ja so ein verteiltes System, was auf Kubernetes mit verteilten Dateisystemen und vielleicht noch mit verteilten Datenbanken arbeitet, einfach super komplex, weil du halt auf ganz vielen Ebenen diese Verteilungsprobleme hast und die potenzieren sich dann natürlich dadurch und macht es super kompliziert, wenn du irgendwo ein Bug, irgendwo ein Problem hast, dann das Problem zu lösen. Da musst du schon ziemlich fit auf sehr vielen Ebenen sein.

Andy Grunwald (00:49:39 - 00:50:23)

Und kommen wir jetzt mal zu dem Flaggschiff, kommen wir mal zu Kafka. Wir haben die ganze Zeit davon gesprochen, dass eigentlich jedes verteilte System Partition Tolerance sein muss. Laut LinkedIn, dem Autor von Kafka, ist aber Kafka ein CA-System. Also es favort Consistency und Availability über Netzwerkpartitions. Und das ist natürlich recht interessant. Und zwar die Begründung ist, dass LinkedIn, Kafka im eigenen Datasetter laufen, wo sie natürlich das Netzwerk unter ihrer Kontrolle haben und natürlich dann ordentliche Netzwerkkomponenten nehmen, wo dann natürlich Network Partitions sehr rar sind. Die haben ja nicht unrecht. Wenn du alles unter deiner Kontrolle hast, kannst du natürlich auch die Qualität beeinflussen. Du kannst natürlich auch redundante Netzwerksysteme aufbauen.

Wolfi Gassler (00:50:24 - 00:50:40)

Nur halt auch jedes Teil kann irgendwie fehlen. Also wenn der Bagger deine Glasfaserleitung durchbricht und auf der anderen Seite irgendein anderes Hardware-Problem ist, dann hast du halt deine Redundanz auch nicht mehr am Ende. Die Redundanz hast du schon, aber du hast die Connection nicht mehr.

Andy Grunwald (00:50:40 - 00:50:46)

Ich hoffe, liegt inhaltlich kein Bagger im Datacenter. Aber was sonst wird schon im Bagger?

Wolfi Gassler (00:50:46 - 00:50:50)

Die haben ja auch mehrere Datacenter zwischen irgendwelchen Kontinenten oder sowas.

Andy Grunwald (00:50:50 - 00:52:30)

Ja richtig, aber die Kafka-Systeme werden ja nicht über Kontinente gespannt. Also dann hast du ja einzelne Systeme, die ja in sich dann immer noch konsistent sind und verfügbar. Also die Replikation ist dann eine andere Baustelle. Ähnlich wie bei Cassandra und bei MongoDB gibt es natürlich auch bei Kafka ein paar Settings, die das ganze CAP-Theorien beeinflussen. Und zwar sind das nämlich deine Minimum-In-Sync-Replikas. Das ist dein Replication-Faktor für deine Topics und für deine Partitions. Und das ist das sogenannte AXE-Setting von deinem Producer. Der Producer ist der Prozessor, der die Daten in den Kafka schreibt. Denn wenn der Replication-Faktor auf 3 gesetzt ist, das bedeutet du replizierst das Topic 3 mal insgesamt, das liegt auf 3 verschiedenen Nodes, deine Minimum-in-Sync-Replikas aber auf 1 gesetzt sind und die Node fliegt dir weg, dann hast du natürlich immer noch Datenverlust, somit bist du nicht mehr konsistent, weil deine Daten zwar von einer Note angenommen werden, auf eine Note geschrieben werden, aber dann über Eventual Consistency rüberrepliziert werden. Wenn du jetzt aber natürlich sagst, okay, der Prozess, der die Daten schreibt, ähnlich wie das sogenannte Consistency Level bei Cassandra oder die Write Concerns bei MongoDB, Wenn du sagst, okay, der Kafka-Cluster muss mir einen Hack geben, wenn das mindestens auf allen Nodes geschrieben ist, dann hast du natürlich Consistency, dann hast du natürlich deine Daten repliziert und somit auch verfügbar und dann ist die ganze Sache natürlich auch sicher. Aber das bedeutet natürlich auch mehrfachen Speicherplatz, Datenvorhaltung und da wissen wir alle, Cloud-Infrastruktur kann teuer sein, dann wird es natürlich auch teuer.

Wolfi Gassler (00:52:30 - 00:52:42)

Und ein Split-Brain kannst du ja trotzdem haben, weil es wird ja wieder irgendeinen Leader geben, der einen Bereich schreiben darf und dann kann dir das natürlich genauso wieder passieren mit einem Split-Brain, wenn ihr das irgendwo dazwischen wegbricht.

Andy Grunwald (00:52:42 - 00:53:36)

Logisch, da kommt dann das Setting der Unclean Leader Election zugute, was man natürlich auch mit sehr, sehr viel Vorsicht genießen sollte, aber das sind dann wiederum die Eigenheiten von Kafka. Also, ihr merkt schon, dass Amazon und Co. diese Datenbanken betreiben, macht schon Sinn, weil das ist sehr harter Tobak. Die Konfiguration der Datenbanken überlassen sie aber dem Kunden, denn Ihr habt jetzt schon an den drei Beispielen von MongoDB, Cassandra und Kafka gemerkt, die Datenbankanbieter wissen nicht, was ihr bevorzugt. Konsistenz oder Verfügbarkeit, das müsst ihr schon selbst entscheiden. Und ich habe schon sehr, sehr viele Teams gesehen, die sich über sowas gar keine Gedanken gemacht haben, aber Wenn die Festplatte mal kaputt ist, sich dann über Datenverlust wundern oder über nicht verfügbare Systeme. Und das finde ich dann immer schade, dass das immer im Nachgang auf die Agenda kommt. Weil das bedeutet, man möchte dann oft, oh Refactoring und ah, wie schaffe ich die Daten denn darüber und so weiter und so fort. Und dann ist immer der Stunk groß, sage ich mal.

Wolfi Gassler (00:53:36 - 00:53:50)

Und daher auch immer meine Empfehlung, kann man es nicht mit einem Singlesystem, wo ein Backup hintendran hängt, nicht auch machen. Und wenn mal was Schlimmes passiert mit der Datenbank, ist man eine Stunde offline. Reicht es nicht für die 95 Prozent aller Projekte auch aus.

Andy Grunwald (00:53:50 - 00:53:52)

Das ist aber nicht Hacker News Driven Development Wolfgang.

Wolfi Gassler (00:53:53 - 00:54:25)

Das stimmt. Ich habe gerade kürzlich mit jemanden gesprochen, der einen MySQL Cluster einsetzt und der hat auch gesagt, er hat seit Ewigkeiten Probleme und immer wieder crasht mal irgendwo was und es ist einfach super kompliziert, das Ganze zu maintainen. Dem ist halt der Single Node dann irgendwann zu schwach geworden. Aber meiner Meinung nach lieber in irgendeinen Hyperscaler nochmal 100 Euro investieren für eine größere Maschine und auf einer Single Instanz bleiben. Das kann wirklich viele Kopfschmerzen verhindern und jeder der mal in so Probleme gelaufen ist in der verteilten Welt weiß wovon ich spreche.

Andy Grunwald (00:54:25 - 00:54:47)

Viele Leute wollen es nicht hören, aber Vertikal skalieren ist eine Option und das geht inzwischen sehr, sehr, sehr groß. Lustiger Funfact, auf GCP kannst du mit SSDs eine Compute Node, also eine EC2 Instanz auf GCP auf 12 GB Storage bringen. ohne Netzwerkstorage zu nutzen. Das ist schon mal eine Hausnummer, oder?

Wolfi Gassler (00:54:47 - 00:54:48)

12 Gigabyte.

Andy Grunwald (00:54:48 - 00:55:00)

Terabyte, Entschuldigung, 12 Terabyte. Du kannst 12 Terabyte SSD-Discs in deine Compute-Note auf Google schopfen. Und wenn du dann ... Bis du erst mal Netzwerkstorage anfassen musst.

Wolfi Gassler (00:55:00 - 00:55:44)

Ja, und sogar Netzwerkstorage funktioniert ja sehr gut. Aber selten ist ja Storage das Problem bei Datenbanken. Sondern meistens ist es halt wirklich die Compute-Power. Aber auch da kann man viel dazukaufen. viel mit einem Single Node kompensieren und manchmal macht es auch einfach Sinn, haben wir auch schon öfters darüber gesprochen, mal vielleicht sich die Queries anzusehen, kann ich da noch irgendwo was optimieren, vielleicht habe ich da ein paar Queries, wenn ich die abende, habe ich plötzlich 70% weniger Load oder sowas auf meiner Datenbank, anstatt sich einen Cluster ins Haus zu holen und wirklich die Probleme damit zu haben. Weil, das kann ich euch garantieren, also wenn ihr bisher Datenbanken irgendwie als Einzelperson oder so gemaintaint habt, bei Clustern wird es dann wirklich schwierig, das als Einzelperson zu machen und überall noch die Ahnung zu haben.

Andy Grunwald (00:55:45 - 00:56:35)

Wir hoffen, euer Kopf raucht jetzt nicht. War schon sehr viel Theorie, war schon sehr viel C, A, P, E, Latency, Consistency. Im Marketing müssten die, glaube ich, auch noch mal alle anfangen. Aber das Einzige, was ihr euch merken müsst, Cup-Theorien. Entscheidet euch zwischen Consistency oder Availability. Macht euch Gedanken, wie euer System sich verhalten soll. Wenn ihr eine verteilte Datenbank wie Kafka, Cassandra, MongoDB oder ähnliches im Einsatz habt, fragt auch mal bei den Mädels und Jungs nach, die die betreiben, oder schaut euch die Topic-Konfiguration und eure Producer-Konfiguration an und eure Clients. Welche Settings ihr da eigentlich wählt. Bei MongoDB sind es Read and Read Preferences, Write Concern. Bei Cassandra ist es primär das Consistency-Level. Bei Kafka sind es die Producer-Axe, die Min-In-Sync-Replikas auf dem Topic und auf den Partitions und den Replication-Faktor auf dem Topic.

Wolfi Gassler (00:56:36 - 00:56:46)

Und fürs Bullshit-Bingo, ganz wichtig, jeder der sagt Cup, könnt ihr dann sagen, Cup betrachtet ja nur den negativen Fall, eigentlich ist Buck Elk das wahre und das muss man sich eigentlich anschauen.

Andy Grunwald (00:56:46 - 00:57:21)

Wir verlinken euch natürlich noch eine ganze Menge Links in den Shownotes, auch ein paar schöne Comics, wie man sich das Ganze ein bisschen vorstellen kann, auch warum Kafka unter anderem ein CA-System sein soll und kein Netzwerk Partitions haben sollte, haben wir auch schon erklärt, aber die offizielle geschriebene Erklärung verlinken wir völlig auch. Ich hoffe, ihr hört diese Episode nicht an dem Wochenende, weil das an dem Wochenende, finde ich, ein bisschen harter Tobak. Zumindest, wenn man da irgendwie mal noch einen Kater hat oder ähnliches von der Party von gestern. Aber nur gut. Kann natürlich auch euch mal wieder wach machen. Oder ihr nutzt das Einschlaf-Podcast. Das ist auch okay für uns.

Wolfi Gassler (00:57:21 - 00:57:27)

Einschlafen mit dem Engineering-Kiosk. In dem Sinne, eine gute Woche. Bis zur nächsten Episode.

Andy Grunwald (00:57:27 - 00:57:28)

Bis bald. Tschüss. Ciao.

Wolfi Gassler (00:57:31 - 00:57:41)

Und nicht vergessen, wenn du noch eine neue Herausforderung suchst, zum Beispiel in weltweit skalierten Systemen, klick mal auf den Link in den Shownotes zu Career-Seite von unserem Episodensponsor Trivago.