CAP-Theorem

Das CAP-Theorem oder Brewers Theorem besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig die drei Eigenschaften Consistency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz) zu garantieren.

Eigenschaften

Veranschaulichung des CAP-Theorems

Laut dem CAP-Theorem kann ein verteiltes System zwei der folgenden Eigenschaften gleichzeitig erfüllen, jedoch nicht alle drei.

Konsistenz (C consistency)

Die Konsistenz der gespeicherten Daten. In verteilten Systemen mit replizierten Daten muss sichergestellt sein, dass nach Abschluss einer Transaktion auch alle Replikate des manipulierten Datensatzes aktualisiert werden. Diese Konsistenz sollte nicht verwechselt werden mit der Konsistenz der ACID-Transaktionen, die nur die innere Konsistenz eines Datenbestandes betrifft.

Verfügbarkeit (A availability)

Die Verfügbarkeit im Sinne akzeptabler Antwortzeiten. Alle Anfragen an das System werden stets beantwortet.

Partitionstoleranz (P partition tolerance)

Die Ausfalltoleranz der Rechner-/Servernetze. Das System arbeitet auch weiter, wenn es partitioniert wird, d. h., wenn Knoten nicht mehr miteinander kommunizieren können (z. B., um die Daten untereinander konsistent zu halten). Dies kann durch den Verlust von Nachrichten, den Ausfall einzelner Netzknoten oder den Abbruch von Verbindungen im Netz (der Partition des Netzes) auftreten.

Da nur zwei dieser drei Anforderungen in verteilten Systemen gleichzeitig vollständig erfüllt sein können, wird das CAP-Theorem oft als Dreieck visualisiert, bei dem eine konkrete Anwendung sich auf eine der Kanten einordnen lässt. Dies ist jedoch ungenau. Da sich das CAP-Theorem auf verteilte Systeme bezieht, ist eine Auswahl ohne Partitionstoleranz nicht Teil der Betrachtung. Die Interpretation ist somit eher, dass man sich im Falle einer Netzwerkpartitionierung (also in einem Fehlerfall, der nicht die gewünschte Systemausführung beschreibt) zwischen der Konsistenz der Daten und der Verfügbarkeit des Systems entscheiden muss.

Die System-Eigenschaften C, A und P können dabei als graduelle Größen gesehen werden, d. h. die Verfügbarkeit ist hoch, wenn das System schnell antwortet, und gering, wenn das System langsam antwortet. In Hinblick auf die Konsistenz bedeutet das, dass diese entweder sofort sichergestellt ist (bei strikter Konsistenz) oder erst nach einem gewissen Zeitfenster der Inkonsistenz („BASE“-Prinzip (= Basically Available, Soft state, Eventual consistency) vieler NoSQL-Datenbanken).

Geschichte

Das Theorem entstand im Jahr 2000 als eine Vermutung des Informatikers Eric Brewer an der University of California, Berkeley beim Symposium on Principles of Distributed Computing (PODC). Im Jahr 2002 veröffentlichten Seth Gilbert und Nancy Lynch vom MIT einen axiomatischen Beweis von Brewers Vermutung, und etablierten diese somit als Theorem.

Beispiele

AP – Domain Name System (DNS) oder Cloud Computing

Das Domain Name System ist der Internet-Dienst, mit dem symbolische Hostnamen wie de.wikipedia.org zu numerischen IP-Adressen zur TCP/IP-Kommunikation aufgelöst werden.

Das DNS fällt in die Kategorie AP. Die Verfügbarkeit ist extrem hoch, ebenso Toleranz gegenüber dem Ausfall einzelner DNS-Server. Allerdings ist die Konsistenz nicht immer sofort gegeben: es kann mitunter Tage dauern, bis ein geänderter DNS-Eintrag an die gesamte DNS-Hierarchie propagiert ist und damit von allen Clients gesehen wird.

Cloud-Plattformen setzen auf eine horizontale Skalierung, das heißt die Last wird auf viele Knoten verteilt, die aus billiger, nicht unbedingt ausfallsicherer Hardware bestehen (können). Daher muss eine Cloud-Anwendung zwingend Toleranz gegenüber dem Ausfall einzelner Knoten zeigen können. Eine hohe Verfügbarkeit wird auch gefordert. Daraus folgt, dass eine Cloud-Anwendung (zumindest in großen Teilen) auch in die Kategorie AP fällt. Beispiele für Web-Anwendungen, die nicht auf strenge Konsistenz angewiesen sind, wären Social-Media-Sites wie Twitter oder Facebook; wenn einzelne Nachrichten nicht bei allen Nutzern gleichzeitig eintreffen, ist dadurch die prinzipielle Funktion des Dienstes nicht beeinträchtigt.

Da eine strenge Konsistenz wegen des CAP-Theorems hier nicht mehr gewährleistet werden kann, eine völlig inkonsistente Datenhaltung aber auch nicht gewünscht ist, muss man sich mit schwächeren Konsistenzbedingungen abfinden. Als Gegenstück zum ACID-Prinzip der relationalen Datenbanken setzen viele NoSQL-Datenbanken auf das BASE-Prinzip: Basically Available, Soft State, Eventual consistency. Eventual consistency lässt sich sinngemäß gut mit „schlussendlicher Konsistenz“ übersetzen, das heißt: das System ist nach Ablauf einer gewissen (möglichst kurzen) Zeitspanne der Inkonsistenz wieder in einem konsistenten Zustand.

CA – Relationales Datenbank Management System (RDBMS)

Die relationalen Datenbanken wie DB2 oder Oracle streben vor allem Konsistenz an.

Ein RDBMS-Cluster fällt meistens in die Kategorie CA. Sie streben vor allem Verfügbarkeit und Konsistenz aller Knoten an. Da sie meistens mit hochverfügbaren Netzwerken und Servern betrieben werden, müssen sie nicht unbedingt gut mit einer Partitionierung umgehen können. Wie oben erwähnt, sind C, A und P graduelle Größen.

CP – Banking-Anwendungen

Für verteilte Finanzanwendung wie z. B. Geldautomaten ist die Konsistenz der Daten oberstes Gebot: Ein abgehobener Geldbetrag muss zuverlässig auch auf der Kontenseite abgebucht werden, eingezahltes Geld muss auf dem Konto erscheinen. Diese Anforderung muss auch bei Störungen im Datenverkehr sichergestellt werden (Partitionstoleranz).

Gegenüber der Konsistenz und der Partitionstoleranz ist die Verfügbarkeit zweitrangig (CP): Bei Netzwerkstörungen soll ein Geldautomat oder ein anderer Service eher nicht verfügbar sein als inkorrekte Transaktionen abzuwickeln.

Siehe auch

• Fallacies of Distributed Computing, gängige Irrtümer bei der verteilten Datenverarbeitung

Weblinks

• Seth Gilbert, Nancy Lynch: Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services (Memento vom 23. Juli 2014 im Internet Archive) (PDF; 124 kB)
• CAP Twelve Years Later: How the „Rules“ Have Changed
• Technische Hochschule Köln: CAP-Theorem, Lexikon des eLearning-Datenbank-Portals