BASE und Konsistenzmodelle

Zusammenfassung

BASE (Basically Available, Soft State, Eventually Consistent) ist das Konsistenzparadigma verteilter Systeme und weicht die strikten ACID-Eigenschaften zugunsten von Verfuegbarkeit und Skalierbarkeit auf. Das CAP-Theorem von Eric Brewer besagt, dass ein verteiltes System von Consistency, Availability und Partition tolerance nur zwei Eigenschaften gleichzeitig garantieren kann. Zwischen strikter Konsistenz und Eventual Consistency liegt ein Spektrum abgeschwaechter Konsistenzmodelle (Monotonic Reads/Writes, Read-your-writes, Session, Causal), das je nach Anwendungsfall den Trade-off zwischen Verfuegbarkeit und Konsistenz feinjustiert.

Kernkonzepte

BASE (Basically Available, Soft State, Eventually Consistent)

BASE ist das Konsistenzparadigma verteilter Systeme und bewusst als Gegenstueck zu ACID formuliert. Basically Available: Das System ist meistens verfuegbar, auch wenn Daten leicht veraltet sein koennen. Soft State: Daten sind nicht sofort auf allen Knoten konsistent, der Zustand kann sich auch ohne externen Input aendern. Eventually Consistent: Das System wird irgendwann ueber alle Knoten hinweg konsistent, sofern keine neuen Updates erfolgen. BASE priorisiert also Verfuegbarkeit und Skalierbarkeit ueber sofortige Konsistenz.

BASE weicht ACID auf: lieber immer verfuegbar und irgendwann konsistent als sofort konsistent aber manchmal unerreichbar.

CAP-Theorem (Brewer)

Formuliert von Eric Brewer (2000): Ein verteiltes shared-data System kann von den drei Eigenschaften Consistency (alle Clients sehen die gleiche aktuelle Version), Availability (jede Anfrage erhaelt eine Antwort) und Partition Tolerance (System funktioniert trotz Netzwerkausfaellen zwischen Knoten) nur zwei gleichzeitig garantieren. In der Praxis ist P bei verteilten Systemen nicht verhandelbar, daher waehlt man zwischen CP und AP. Man spricht auch von einem CAP-Dilemma.

You may have any two - Consistency, Availability, Partition tolerance: nur zwei davon gleichzeitig moeglich.

Eventual Consistency

Schwaechste Stufe im Konsistenzspektrum: Clients sehen neue Daten eventuell verzoegert. Das Wort eventual bedeutet irgendwann konsistent - Replikate gleichen sich ohne weitere Updates im Laufe der Zeit an. Zwischen dem Schreibvorgang und der Angleichung aller Replikate existiert ein Zeitfenster der Inkonsistenz. Typisch fuer Systeme wie DNS, viele NoSQL-Datenbanken oder Web-Caches.

Eventually = irgendwann: alle Knoten werden konsistent, aber nicht sofort.

Spektrum der Konsistenzmodelle

Zwischen strikter Konsistenz (Strong Consistency) und Eventual Consistency existiert ein ganzes Spektrum von Zwischenstufen: Eventual, Monotonic Reads/Writes (zeitlich geordnete Reihenfolge), Read-your-writes (Client sieht eigene Schreibvorgaenge), Session Consistency (clientzentrierte Garantien innerhalb einer Session), Causal Consistency (kausal zusammenhaengende Operationen in gleicher Reihenfolge) und schliesslich strikte Konsistenz. Je weiter rechts, desto strenger die Garantie, aber desto geringer die Verfuegbarkeit.

Links schwach und verfuegbar, rechts strikt und konsistent - je nach Anwendungsfall waehlt man die Stufe.

ACID vs. BASE Trade-off

ACID (Atomicity, Consistency, Isolation, Durability) ist das klassische Transaktionsmodell fuer relationale, meist zentrale Datenbanken. BASE ist das Pendant fuer verteilte Systeme wie NoSQL-DBs. ACID priorisiert Korrektheit ueber Verfuegbarkeit, BASE genau andersherum. In verteilten Umgebungen mit Netzwerkpartitionen ist strikte ACID-Semantik schwer haltbar - daher lockert man Isolation und Consistency zugunsten von Skalierbarkeit und Ausfallsicherheit.

ACID = Saeure = strikt und zentral, BASE = Base = weich und verteilt.

Read-your-writes und Session Consistency

Read-your-writes verknuepft die Schreibvorgaenge eines Clients mit dessen kausalabhaengigen Lesevorgaengen: was ich selbst geschrieben habe, sehe ich beim naechsten Lesen garantiert. Session Consistency vereint diese clientzentrierten Garantien in einer zusammenhaengenden Session der Anwendungsebene. Beide bleiben jedoch client-/sessionzentriert - andere Clients koennen die Aenderung noch verzoegert sehen.

Read-your-writes: ich sehe was ich schreibe - Session Consistency: waehrend meiner Session bleibt es konsistent.

Causal Consistency

Alle kausal zusammenhaengenden Operationen werden von allen Prozessen global in derselben Reihenfolge gesehen. Wenn Ereignis A vor B stattfand und B von A abhaengt, wird niemand B vor A beobachten. Nicht kausal verbundene Operationen koennen jedoch in unterschiedlicher Reihenfolge sichtbar sein. Staerker als Session, schwaecher als strikte Konsistenz.

Ursache vor Wirkung: alle sehen kausal verbundene Aktionen in der richtigen Reihenfolge.

Zeitfenster der Inkonsistenz

In BASE-Systemen bezeichnet dies die Zeit zwischen einem Schreibvorgang auf einem Knoten und der Angleichung aller Replikate. Waehrend dieses Fensters koennen unterschiedliche Clients unterschiedliche Werte sehen. Die Laenge des Fensters haengt von Netzwerklatenz, Replikationsstrategie und Systemlast ab. Anwendungen muessen mit diesem Fenster umgehen koennen.

Kurzzeitige Inkonsistenz ist der Preis fuer hohe Verfuegbarkeit in verteilten Systemen.

Wichtige Details

BASE steht fuer Basically Available, Soft State, Eventually Consistent und ist das Gegenstueck zu ACID in verteilten Systemen.
Das CAP-Theorem wurde von Eric Brewer im Jahr 2000 formuliert und besagt: Consistency, Availability und Partition tolerance - nur zwei davon gleichzeitig moeglich.
In verteilten Systemen ist Partition Tolerance nicht verhandelbar, daher waehlt man in der Praxis zwischen CP (konsistent) und AP (verfuegbar).
CA-Systeme sind klassische Single-Site-Datenbanken oder DB-Cluster ohne Netzwerkpartitionierung (z.B. relationale DBMS mit Zwei-Phasen-Commit).
AP-Systeme sind z.B. Web-Caches und DNS - hohe Verfuegbarkeit auf Kosten kurzzeitiger Inkonsistenz.
CP-Systeme sind verteilte Datenbanken mit pessimistischen bzw. verteilten Sperren, die Minderheits-Partitionen bei Ausfall vom Netz nehmen.
Das Konsistenzspektrum reicht von Eventual (schwach) ueber Monotonic Reads/Writes, Read-your-writes, Session, Causal bis Strong Consistency (strikt).
Eventual Consistency: Replikate gleichen sich ohne weitere Updates im Zeitverlauf an - es entsteht ein Zeitfenster der Inkonsistenz.
Read-your-writes garantiert clientzentriert, dass ein Client seine eigenen Schreibvorgaenge immer liest, auch wenn Replikate global noch veraltet sind.
Causal Consistency ist staerker als Session Consistency: alle Prozesse sehen kausal verbundene Operationen global in derselben Reihenfolge.

Beispiele

BASE bei einem Online-Shop

Ein grosser Web-Shop nutzt ein verteiltes System mit Replikation. Kunde A aktualisiert seinen Warenkorb auf Knoten N1. Sekundenbruchteile spaeter liest Kunde A den Warenkorb ueber Knoten N2 (der noch nicht synchronisiert ist) und sieht kurzzeitig den alten Zustand. Nach wenigen Millisekunden ist die Aenderung auch auf N2 sichtbar - Eventual Consistency.

t0: Client -> N1: write(Warenkorb, Artikel_X)
t1: N1 committed lokal, Antwort an Client (Basically Available)
t2: Client -> N2: read(Warenkorb) -> alter Stand (Soft State)
t3: N1 -> N2: Replikation der Aenderung
t4: Client -> N2: read(Warenkorb) -> neuer Stand (Eventually Consistent)

CAP-Dilemma bei Netzwerkpartition

Zwei Knoten N1 und N2 sind durch Netzwerkausfall getrennt (Partition). Ein Client schreibt Wert X=5 auf N1. Ein anderer Client liest X von N2. Das System muss entscheiden: Entweder N2 antwortet mit dem alten Wert (Availability, aber keine Consistency) oder N2 verweigert die Antwort (Consistency, aber keine Availability).

Ausgangslage: X=3 auf N1 und N2
Netzwerk zwischen N1 und N2 bricht ab
Client1 -> N1: write(X, 5) -> OK
Client2 -> N2: read(X)
  Variante AP: -> 3 (verfuegbar, aber inkonsistent)
  Variante CP: -> Fehler/Timeout (konsistent, aber nicht verfuegbar)

Read-your-writes-Konsistenz erkennen

Ein Nutzer postet einen Kommentar in einem sozialen Netzwerk. Nach dem Absenden lae die Seite neu und der Nutzer erwartet, seinen eigenen Kommentar zu sehen. Read-your-writes garantiert, dass ein Client immer seine eigenen Schreibvorgaenge lesen kann, selbst wenn andere Clients die Aenderung noch nicht sehen.

Client C: write(post, Hallo) -> N1
N1 -> Client C: OK
Client C: read(post) -> muss Hallo zurueckliefern (auch wenn ueber N2 gelesen)
Client D (parallel): read(post) -> darf noch alten Zustand sehen

Eventual Consistency Ablauf

Drei Replikate haben unterschiedliche Staende nach einem Schreibvorgang. Ohne weitere Updates gleichen sich die Replikate im Laufe der Zeit an. Der Zeitraum bis zur Angleichung heisst Zeitfenster der Inkonsistenz.

t0: R1=A, R2=A, R3=A
t1: write(B) auf R1
     R1=B, R2=A, R3=A -> Inkonsistenz
t2: R1 -> R2 propagiert
     R1=B, R2=B, R3=A
t3: R1 -> R3 propagiert
     R1=B, R2=B, R3=B -> Eventually Consistent

Visualisierung

FAQ

Was bedeutet das S in BASE genau?

Soft State bedeutet, dass Daten nicht sofort auf allen Knoten konsistent sind. Der Systemzustand kann sich auch ohne externen Input im Zeitverlauf aendern, weil die Replikation im Hintergrund weiterlaeuft und Zustaende zwischen Knoten angleicht.

Warum kann man nach dem CAP-Theorem nicht alle drei Eigenschaften gleichzeitig haben?

In einem verteilten System kann jederzeit eine Netzwerkpartition auftreten. Waehrend einer Partition muss man sich entscheiden: entweder antwortet das System weiter (Availability), dann kann es aber ueberholte Daten liefern, oder das System verweigert die Antwort (Consistency). Partition Tolerance ist in verteilten Systemen praktisch nicht verhandelbar, daher ist die reale Wahl meist zwischen CP und AP.

Ist BASE das Gegenteil von ACID?

Ja, BASE ist bewusst als sprachlicher Gegenpol zu ACID konzipiert (Saeure vs. Base). ACID setzt auf strikte Konsistenz, BASE weicht diese zugunsten von Verfuegbarkeit und Skalierbarkeit auf. In verteilten Systemen mit hoher Last (z.B. Web-Scale) ist BASE oft die pragmatischere Wahl.

Was ist der Unterschied zwischen Eventual und Causal Consistency?

Eventual Consistency garantiert nur, dass alle Replikate irgendwann uebereinstimmen, ohne Reihenfolge. Causal Consistency ist strikter: alle kausal zusammenhaengenden Operationen werden von allen Prozessen in gleicher Reihenfolge gesehen. Ein Kommentar wird also nie vor dem zugehoerigen Post sichtbar.

Was ist Session Consistency?

Session Consistency vereint mehrere clientzentrierte Garantien (Monotonic Reads, Monotonic Writes, Read-your-writes) innerhalb einer zusammenhaengenden Client-Session. Solange der Client in derselben Session bleibt, sieht er ein konsistentes Bild seiner eigenen Aktionen. Ausserhalb der Session gelten diese Garantien nicht.

Welche CAP-Kombination waehlt man wann?

CA: klassische Single-Site DBs oder DB-Cluster ohne Partitionen (z.B. relationale DBMS). CP: verteilte Datenbanken mit strengen Konsistenzanforderungen (z.B. Bankensysteme, Zwei-Phasen-Commit). AP: Web-Caches, DNS, viele NoSQL-Systeme mit Fokus auf hohe Verfuegbarkeit.

Wo ordnet sich Monotonic Reads im Spektrum ein?

Monotonic Reads liegt zwischen Eventual Consistency und Read-your-writes. Es erzwingt eine zeitlich geordnete Lesereihenfolge: wenn ein Client einmal Version V2 gesehen hat, darf er nie wieder V1 sehen. Replikate von vergangenen Daten werden verworfen. Umgesetzt meist ueber Zeitstempel.

Was bedeutet Basically Available konkret?

Das System antwortet fast immer auf Anfragen, auch bei Teilausfaellen von Knoten. Die Antwort ist aber nicht garantiert die aktuellste Version der Daten. Statt einer Fehlermeldung bekommt der Nutzer moeglicherweise leicht veraltete Daten - aber ueberhaupt eine Antwort.

Pruefungsfragen

0 von 12 Fragen beantwortet