← Dashboard

Kapitel 08 · Datenbanken

BASE-Konsistenz

Zusammenfassung

BASE (Basically Available, Soft State, Eventually Consistent) ist das Konsistenzparadigma verteilter Systeme und weicht die strikten ACID-Eigenschaften zugunsten von Verfügbarkeit 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 abgeschwächter Konsistenzmodelle (Monotonic Reads/Writes, Read-your-writes, Session, Causal), das je nach Anwendungsfall den Trade-off zwischen Verfügbarkeit und Konsistenz feinjustiert.

Kernkonzepte

BASE (Basically Available, Soft State, Eventually Consistent)

BASE ist das Konsistenzparadigma verteilter Systeme und bewusst als Gegenstück zu ACID formuliert. Basically Available: Das System ist meistens verfügbar, auch wenn Daten leicht veraltet sein können. Soft State: Daten sind nicht sofort auf allen Knoten konsistent, der Zustand kann sich auch ohne externen Input ändern. Eventually Consistent: Das System wird irgendwann über alle Knoten hinweg konsistent, sofern keine neuen Updates erfolgen. BASE priorisiert also Verfügbarkeit und Skalierbarkeit über sofortige Konsistenz.

BASE weicht ACID auf: lieber immer verfügbar 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 erhält eine Antwort) und Partition Tolerance (System funktioniert trotz Netzwerkausfällen zwischen Knoten) nur zwei gleichzeitig garantieren. In der Praxis ist P bei verteilten Systemen nicht verhandelbar, daher wählt 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 möglich.

Eventual Consistency

Schwächste Stufe im Konsistenzspektrum: Clients sehen neue Daten eventuell verzögert. 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 für 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 Schreibvorgänge), Session Consistency (clientzentrierte Garantien innerhalb einer Session), Causal Consistency (kausal zusammenhängende Operationen in gleicher Reihenfolge) und schliesslich strikte Konsistenz. Je weiter rechts, desto strenger die Garantie, aber desto geringer die Verfügbarkeit.

Links schwach und verfügbar, rechts strikt und konsistent - je nach Anwendungsfall wählt man die Stufe.

ACID vs. BASE Trade-off

ACID (Atomicity, Consistency, Isolation, Durability) ist das klassische Transaktionsmodell für relationale, meist zentrale Datenbanken. BASE ist das Pendant für verteilte Systeme wie NoSQL-DBs. ACID priorisiert Korrektheit über Verfügbarkeit, 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 = Säure = strikt und zentral, BASE = Base = weich und verteilt.

Read-your-writes und Session Consistency

Read-your-writes verknüpft die Schreibvorgänge eines Clients mit dessen kausalabhängigen Lesevorgängen: was ich selbst geschrieben habe, sehe ich beim nächsten Lesen garantiert. Session Consistency vereint diese clientzentrierten Garantien in einer zusammenhängenden Session der Anwendungsebene. Beide bleiben jedoch client-/sessionzentriert - andere Clients können die Änderung noch verzögert sehen.

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

Causal Consistency

Alle kausal zusammenhängenden Operationen werden von allen Prozessen global in derselben Reihenfolge gesehen. Wenn Ereignis A vor B stattfand und B von A abhängt, wird niemand B vor A beobachten. Nicht kausal verbundene Operationen können jedoch in unterschiedlicher Reihenfolge sichtbar sein. Stärker als Session, schwächer 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. Während dieses Fensters können unterschiedliche Clients unterschiedliche Werte sehen. Die Länge des Fensters hängt von Netzwerklatenz, Replikationsstrategie und Systemlast ab. Anwendungen müssen mit diesem Fenster umgehen können.

Kurzzeitige Inkonsistenz ist der Preis für hohe Verfügbarkeit in verteilten Systemen.

Wichtige Details

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 später liest Kunde A den Warenkorb über Knoten N2 (der noch nicht synchronisiert ist) und sieht kurzzeitig den alten Zustand. Nach wenigen Millisekunden ist die Änderung 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 Schreibvorgänge lesen kann, selbst wenn andere Clients die Änderung 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 Stände 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

CAP-Theorem: Nur zwei von drei C Consistency A Availability P Partition tolerance CA RDBMS, Single-Site CP Banken, 2PC AP DNS, NoSQL BASE-Akronym als Datenbank-Stapel B Basically Available meist erreichbar A (basically) Available antwortet trotz Teilausfall S Soft State Zustand ändert sich im Hintergrund E Eventually Consistent irgendwann konsistent Spektrum der Konsistenzmodelle Schwache Konsistenz Höhere Verfügbarkeit Strikte Konsistenz Geringere Verfügbarkeit Eventual Consistency DNS, NoSQL Monotonic Reads/Writes Zeitstempel Read-your- writes Client sieht sich Session Consistency pro Session Causal Consistency Ursache-Wirkung Strong Consistency ACID, 2PC

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 ändern, weil die Replikation im Hintergrund weiterläuft und Zustände 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. Während einer Partition muss man sich entscheiden: entweder antwortet das System weiter (Availability), dann kann es aber überholte 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 (Säure vs. Base). ACID setzt auf strikte Konsistenz, BASE weicht diese zugunsten von Verfügbarkeit 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 übereinstimmen, ohne Reihenfolge. Causal Consistency ist strikter: alle kausal zusammenhängenden Operationen werden von allen Prozessen in gleicher Reihenfolge gesehen. Ein Kommentar wird also nie vor dem zugehörigen Post sichtbar.

Was ist Session Consistency?

Session Consistency vereint mehrere clientzentrierte Garantien (Monotonic Reads, Monotonic Writes, Read-your-writes) innerhalb einer zusammenhängenden 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 wählt 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 Verfügbarkeit.

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 über Zeitstempel.

Was bedeutet Basically Available konkret?

Das System antwortet fast immer auf Anfragen, auch bei Teilausfällen von Knoten. Die Antwort ist aber nicht garantiert die aktuellste Version der Daten. Statt einer Fehlermeldung bekommt der Nutzer möglicherweise leicht veraltete Daten - aber überhaupt eine Antwort.

Prüfungsfragen

0 von 12 Fragen beantwortet