DB-EnginesCrateDB bannerEnglish
Deutsch
Informationen zu relationalen und NoSQL DatenbankmanagementsystemenEin Service von solid IT

Enzyklopädie > Artikel

CAP Theorem

Das CAP Theorem beschreibt eine Eigenheit von verteilten Datenbanksystemen.

Das Theorem besagt, dass in einem verteilten System maximal zwei der folgenden drei Eigenschaften gewährleistet werden können:

  • Consistency (Konsistenz).
    Das System ist im Sinne des CAP Theorems konsistent, wenn alle Knoten des verteilten Systems zu jedem Zeitpunkt die gleichen Daten sehen. Als Gegensatz zu Eventual Consistency wird der hier verwendete Konsistenzbegriff auch Immediate Consistency oder starke Konsistenz genannt.
  • Availability (Verfügbarkeit).
    Das System ist verfügbar, wenn es auf alle Anfragen antwortet.
  • Partition tolerance (Partitionstoleranz).
    Das System ist partitionstolerant, wenn es bei einer Unterbrechung der Kommunikation mit einem Teil der Knoten noch funktionstüchtig bleibt.

Ein System, welches alle drei Eigenschaften erfüllen sollte, müsste demnach bei einer Unterbrechung der Verbindung zwischen Knoten die separierten Knoten verfügbar halten, also auf Anfragen reagieren, und zwar konsistent reagieren. Wenn nun Daten auf einem der Knoten geändert werden, können offenbar nicht alle restlichen Knoten konsistent gehalten werden, da ja manche Knoten von den andern Knoten aus nicht mehr erreichbar sind. Das System kann nun entweder inkonsistent oder gar nicht reagieren, müsste also entweder C oder A aufgeben.

Je nachdem, welche der Eigenschaften gewährleistet werden, spricht man von CP, AP oder CA Systemen.

  • CP Syteme reagieren auf eine Netzwerkpartitionierung, indem sie auf vollständige Verfügbarkeit verzichten. Der Teil des Netzwerkes, der konsistent gehalten werden kann, bleibt verfügbar, der Rest nicht. C und P bleiben erfüllt, A ist nicht erfüllt. Sobald die Verbindungen zwischen den Knoten wiederhergestellt ist, wird bei den zuvor nicht verfügbaren Knoten zunächst die Konsistenz wiederhergestellt, erst dann antworten sie auch wieder auf Anfragen.
  • AP Systeme reagieren auf eine Netzwerkpartitionierung, indem sie auf vollständige Konsistenz verzichten. Alle Teile des Netzwerks reagieren auf Anfragen, aber die Antworten sind nicht notwendigerweise konsistent. Nach Ende der Verbindungsunterbrechung wird die Konsistenz wiederhergestellt.
    Viele AP Systeme gehen noch einen Schritt weiter, und verzichten auch im Normalbetrieb (d.h. ohne Netzwerkpartitionierung) auf Konsistenz, und begnügen sich aus Performancegründen mit Eventual Consistency.
  • CA Systeme versuchen Konsistenz und Verfügbarkeit gleichermaßen sicherzustellen, aber nachdem in einem verteilten System auch sie eine Netzwerkpartitionierung natürlich nicht ausschließen können, sind sie in diesen Fällen letztlich genauso gezwungen eine Priorisierung zwischen C und A zu treffen. Eine Klassifizierung in CA Systeme ergibt somit nur in einem nicht-verteilten System Sinn, dort hat der Begriff Netzwerkpartitionierung aber keine Bedeutung.

Das CAP Theorem in der Praxis

Die oben beschriebene Klassifizierung ist eine idealisierte Darstellung. In der Praxis verschwimmen die Grenzen, denn es ist natürlich auch möglich Mischformen zwischen CP and AP Systemen zu erstellen. Das sind Systeme, die je nach Situation unterschiedlich zwischen C und A entscheiden.

Auch der Begriff der Netzwerkpartitionierung birgt praktische Probleme. Zunächst ist nicht unbedingt gewährleistet sein, dass das System in diesem Fall einheitlich reagiert. Manche Knoten haben vielleicht keine Kenntnis über eine Verbindungsunterbrechung, und können auch nicht informiert werden.

Außerdem wird in der Praxis eine Verbindungsunterbrechung durch die Überschreitung von Timeouts erkannt, davon müssen aber nicht alle Knoten gleichermaßen betroffen sein. Ein System mit einer schlechten Netzwerkverbindung ist in einem Zwischenzustand.

Nutzen des CAP Theorems

Obwohl eine allzu strenge Auslegung des CAP Theorems an Grenzen stößt, beschreibt es doch einen wichtigen Sachverhalt, nämlich die Notwendigkeit zwischen diesen unterschiedlichen Anforderungen, insbesondre zwischen C und A, abzuwägen, und einen für die jeweilige Anwendung idealen Kompromiss zu finden.

Das kann schon bei der Auswahl des geeigneten DBMS seinen Niederschlag finden, und viele der verteilten Systeme erlauben es auch für einzelne Datenbank­operationen mit unterschiedlichen Strategien der Konsistenzsicherung vorzugehen, so dass man sich auch innerhalb einer Applikation von Fall zu Fall in einem anderen Bereich der CAP Restriktionen befindet.



Featured Products

Redis logo

Start now with Redis Cloud
Secure, highly available Redis as a serverless, hosted, fully managed cloud service.
Sign up here.

Neo4j logo

Get your step-by-step guide comparing RDBMS to graph databases, including data models, query languages, and deployment strategies.

Couchbase logo

SQL + JSON + NoSQL.
Power, flexibility & scale.
All open source.
Get started now.

AllegroGraph logo

Graph Database Leader for AI Knowledge Graph Applications - The Most Secure Graph Database Available.
Free Download

Präsentieren Sie hier Ihr Produkt