Entwickler: In deiner Session geht es um Eventual Consistency. Was ist das?

Susanne Braun: Eventual Consistency ist eine bestimmte Eigenschaft von verteilten Systemen, die Daten redundant auf verschiedenen Knoten vorhalten, um beispielsweise bestimmte Qualitätsziele wie Verfügbarkeit oder Resilienz zu realisieren. Eventual Consistency bedeutet, dass diese Replikate die meiste Zeit keinen identischen Zustand haben werden, da Updates nur asynchron propagiert werden. Die Zustände der Systeme „konvergieren“ aber aufeinander zu. Eventual Consistency garantiert hier aber lediglich, dass sobald es für einen längeren Zeitraum keine neuen Updates gab, die Replikate „letztendlich“ einen identischen Zustand haben werden.

(Der Begriff wurde in den 90ern von Doug Terry eingeführt. Eventual Consistency ist nur eine von sehr vielen Arten von sogenannter schwacher Konsistenz.)

Entwickler: Welche Gefahren ergeben sich aus diesem Ansatz für verteilte Datenbanken?
Susanne Braun: Dadurch, dass Updates nur asynchron propagiert werden, sind keine weitreichenden Isolations-Garantien wie globale Serialisierbarkeit möglich. Nebenläufigkeitsanomalien können also nicht ausgeschlossen werden und müssen von der Anwendung behandelt werden. So müssen auch Konflikte, die aufgrund von konkurrierenden Schreibzugriffen jederzeit auftreten können, im Nachhinein aufgelöst werden. Bei simplen Strategien zur Konfliktbehandlung, wie Last-Writer-Wins kann es in jedem Fall zu Lost Updates kommen. Möchte man Lost Updates und andere Nebenläufigkeitsanomalien vermeiden, muss man sich im Vorfeld überlegen, wie man im Konflikt stehende Versionen eines Datensatzes im Nachhinein wieder mergen kann. Je nach Fachlichkeit kann die Merge-Logik beliebig komplex werden. Es gibt aber auch Domänen, wo das sehr gut funktionieren kann, wenn man bereit ist bestimmte Tradeoff-Entscheidungen zu treffen. Ein gutes Positiv-Beispiel dafür ist der Shopping-Card-Service von Amazon. Im Endeffekt hat es meiner Meinung nach sehr viel mit der Fachlichkeit zu tun, ob Eventual Consistency besser oder schlechter für eine bestimmte Anwendung geeignet ist.

(Die erste Datenbank, die nur Eventual Consistency konnte und zunächst keine ACID-Transaktionen angeboten hat, war übrigens DynamoDB von Amazon. J)

Entwickler: Wie kann Domain Driven Design hier unterstützen?

Susanne Braun: Domain-Driven Design fokussiert sich sehr stark auf die Fachlichkeit und sagt, dass man zunächst die Komplexität, die in der Domäne des Nutzers schon inhärent vorhanden ist, in den Griff bekommen sollte. Da wir uns als Software-Architekten und Entwickler also sowieso schon sehr intensiv damit auseinandersetzen müssen und die Fachlichkeit sehr genau verstehen müssen, ist es natürlich auch naheliegend in diesem Zusammenhang über angepasste Konsistenzmodelle nachzudenken. Deren grundsätzliche Anwendbarkeit ist, wie ich schon sagte, teilweise sehr stark von der Fachlichkeit abhängig. Ich entwickele im Rahmen meiner Doktorarbeit Design Guidelines, die sich speziell mit Daten-intensiven Systemen mit heterogenen Konsistenzanforderungen befassen. Diese Guidelines bauen erstmal grundsätzlich auf der DDD-Philosophie auf. Zum einen, weil sie von Natur aus sehr gut zueinander passen und zum anderen, weil DDD in der Praxis sehr verbreitet ist.

Entwickler: Welche Konsistenzmodelle können verfolgt werden?

Es gibt mindestens ein Dutzend verschiedene Formen von schwacher Konsistenz

Susanne Braun: Grundsätzlich unterscheidet man starke Konsistenz von schwacher Konsistenz. Starke Konsistenz kann man im Allgemeinen nur in nicht-verteilten Systemen erreichen, die keine Daten replizieren. Bei starker Konsistenz sieht man immer die letzten Updates. Bei schwacher Konsistenz kann es eben sein, dass die Daten veraltet sind, wenn man bei einem Replikat landet, das noch nicht alle Updates empfangen oder eingespielt hat. Es gibt ein paar wenige Ausnahmen. Zum Beispiel ist die Google-Datenbank Spanner trotz Replikation stark konsistent. Es gibt mindestens ein Dutzend verschiedene Formen von schwacher Konsistenz. Eventual Consistency ist dabei nur eine von vielen. Als Forscher ist es durchaus anspruchsvoll den Überblick zu behalten. Neben Eventual Consistency ist kausale Konsistenz noch als ein wichtiger Vertreter von schwacher Konsistenz zu nennen. Daneben gibt es noch verschiedene Session-Garantien für schwache Konsistenz-Modelle wie beispielsweise Read-Your-Writes, die in der Praxis von Bedeutung sind.

Entwickler: Was sind die gravierendsten Unterschiede zwischen BASE- und ACID-Transaktionen?

Susanne Braun; Eric Brewer hat BASE als Gegenentwurf zu ACID vorgeschlagen. Er hat in diesem Zusammenhang gefordert, die Isolationsgarantien (Serialisierbarkeit, Repeatable Read, …) von ACID-Transaktionen und starker Konsistenz für Qualitätsziele wie Verfügbarkeit und Performance aufzugeben. Das „C“ in ACID-Consistency steht übrigens nicht für starke Konsistenz, sondern dafür, dass der Datenbestand in sich konsistent ist. Also dafür, dass insbesondere alle Domänen-Invarianten zu jedem Zeitpunkt erfüllt sind. Die ACID-Konsistenz wird bei ACID-Transaktionen eben genau über die Isolationsgarantien und die Atomaritätseigenschaft sichergestellt (unter der Voraussetzung, dass Transaktionsprogramme an sich korrekt implementiert sind). Bei BASE gibt es normalerweise keine Transaktionen in dem Sinne. Als Ersatz für verteilte, bzw. globale Transaktionen ist in den letzten Monaten das Saga-Pattern insbesondere bei Microservice-Architekturen populär geworden. Sagas wurden in den 80ern für langlaufende Transaktionen und Prozesse entwickelt und sind eine bestimmte Form von geschachtelten Transaktionen. Für jede geschachtelte Sub-Transaktion einer Saga (bis auf die letzte) muss eine Kompensationstransaktion implementiert werden.

Entwickler: Wann würdest du Entwickler-Teams zu Eventual Consistency raten?

Susanne Braun: Wenn sie sich vorher mit dem Thema eingehender beschäftigt haben, sich über die zusätzliche Komplexität und Pitfalls informiert haben – zum Beispiel, indem sie in meine Guidelines (eine überarbeite Version wird zeitnah bereitgestellt) geschaut haben – und genau wissen, worauf sie sich einlassen: Bei guter Vorbereitung und der richtigen Domäne muss man keine Angst zu haben.