Sie kennen bestimmt das Prinzip „Billig, schnell, gut – wählen Sie zwei“.

Das CAP-Theorem wendet eine ähnliche Logik auf verteilte Systeme an. Es besagt, dass ein verteiltes System nur zwei der drei gewünschten Merkmale Konsistenz, Verfügbarkeit und Ausfalltoleranz erfüllen kann.

Ein verteiltes System ist ein Netz, das Daten auf mehr als einem Knoten (physische oder virtuelle Maschinen) gleichzeitig speichert. Da es sich bei allen Cloud-Anwendungen um verteilte Systeme handelt, ist es für das Entwerfen einer solchen Anwendung essenziell, das CAP-Theorem zu verstehen. Denn so können Sie ein Datenverwaltungssystem mit den Eigenschaften wählen, die für Ihre Anwendung am wichtigsten sind.

Das CAP-Theorem wird auch Brewers Theorem genannt, da es erstmals von Professor Eric A. Brewer in einem Vortrag über verteilte Datenverarbeitung im Jahr 2000 aufgestellt wurde. Zwei Jahre später veröffentlichten der MIT-Professor Seth Gilbert und die MIT-Professorin Nancy Lynch einen Beweis für „Brewer’s Conjecture“.

Schauen wir uns die drei Merkmale verteilter Systeme, auf die sich das CAP-Theorem bezieht, genauer an.

Konsistenz

Konsistenz bedeutet, dass alle Clients zur gleichen Zeit dieselben Daten sehen, unabhängig davon, mit welchem Knoten sie verbunden sind. Dazu müssen Daten, die auf einen Knoten geschrieben werden, sofort an alle anderen Knoten im System weitergeleitet oder repliziert werden, bevor der Schreibvorgang als „erfolgreich“ gewertet wird.

Verfügbarkeit

Verfügbarkeit bedeutet, dass jeder Client, der eine Datenanfrage stellt, eine Antwort erhält, auch wenn ein oder mehrere Knoten ausgefallen sind. Anders ausgedrückt: Alle funktionierenden Knoten im verteilten System geben ausnahmslos eine gültige Antwort auf jede Anfrage zurück.

Ausfalltoleranz bzw. Partitionstoleranz

Bei einer Partition handelt es sich um eine Kommunikationsunterbrechung innerhalb eines verteilten Systems – um eine abgebrochene oder temporär verzögerte Verbindung zwischen zwei Knoten. Partitionstoleranz bedeutet, dass der Cluster trotz beliebig vieler Kommunikationsausfälle zwischen den Knoten im System weiterarbeiten muss.

NoSQL-Datenbanken sind ideal für verteilte Netzanwendungen. Im Gegensatz zu ihren vertikal skalierbaren (relationalen) SQL-Gegenstücken sind NoSQL-Datenbanken horizontal skalierbar und von vornherein verteilt. Sie sind in einem wachsenden Netz, das aus mehreren vernetzten Knoten besteht, schnell skalierbar. (Weitere Informationen finden Sie unter „SQL vs. NoSQL-Datenbanken: Was ist der Unterschied?“.)

Heutzutage werden NoSQL-Datenbanken anhand der zwei CAP-Merkmale, die sie unterstützen, klassifiziert:

• CP-Datenbank: Eine CP-Datenbank bietet Konsistenz und Partitionstoleranz, jedoch keine Verfügbarkeit. Wenn eine Partition zwischen zwei beliebigen Knoten auftritt, muss das System den nicht konsistenten Knoten herunterfahren (d. h. ihn nicht mehr verfügbar machen), bis die Partition behoben ist.
  
  
• AP-Datenbank: Eine AP-Datenbank bietet Verfügbarkeit und Ausfalltoleranz, jedoch keine Konsistenz. Wenn eine Partition auftritt, bleiben alle Knoten verfügbar, doch diejenigen am falschen Ende einer Partition geben möglicherweise eine ältere Datenversion zurück als andere. (Wenn die Partition behoben ist, synchronisieren die AP-Datenbanken die Knoten in der Regel neu, um alle Inkonsistenzen im System zu beheben.)
  
  
• CA-Datenbank: Eine CA-Datenbank bietet Konsistenz und Verfügbarkeit auf allen Knoten. Dies ist jedoch nicht möglich, wenn zwischen zwei beliebigen Knoten im System eine Partition auftritt. Deshalb hat eine CA-Datenbank keine Fehlertoleranz.

Wir haben den CA-Datenbanktyp aus einem bestimmten Grund zuletzt aufgeführt: In einem verteilten System können Partitionen nicht vermieden werden. Verteilte CA-Datenbanken sind zwar rein theoretisch möglich, doch nicht für die Praxis geeignet.Das bedeutet jedoch nicht, dass Sie keine CA-Datenbank für Ihre verteilte Anwendung verwenden können, wenn Sie eine benötigen.Viele relationale Datenbanken wie PostgreSQL bieten Konsistenz und Verfügbarkeit und können mittels Replikation auf mehreren Knoten bereitgestellt werden.

MongoDB ist ein beliebtes NoSQL-Datenbankmanagementsystem, das Daten als BSON- bzw. Binary JSON-Dokumente speichert. Es wird häufig für Big-Data- und Echtzeitanwendungen verwendet, die an mehreren verschiedenen Standorten ausgeführt werden. In Bezug auf das CAP-Theorem ist MongoDB ein CP-Datenspeicher – er behebt Netzpartitionen, indem er die Konsistenz aufrechterhält und gleichzeitig Kompromisse bei der Verfügbarkeit eingeht.

MongoDB ist ein Single-Master-System – jede Replikatgruppe (Link befindet sich außerhalb von ibm.com) kann nur einen Primärknoten haben, der alle Schreiboperationen empfängt. Alle anderen Knoten in derselben Replikatgruppe sind sekundäre Knoten, die das Operationsprotokoll des primären Knotens replizieren und es auf ihr eigenes Dataset anwenden. Standardmäßig lesen Clients auch vom primären Knoten, können aber auch eine Lesepräferenz haben (Link befindet sich außerhalb ibm.com), die es ihnen ermöglicht, von sekundären Knoten zu lesen.

Wenn der Primärknoten nicht mehr verfügbar ist, wird der Sekundärknoten mit dem aktuellsten Operationsprotokoll als neuer Primärknoten ausgewählt. Sobald alle anderen sekundären Knoten mit dem neuen Master gleichziehen, ist der Cluster wieder verfügbar. Da Clients während dieses Intervalls keine Schreibanforderungen stellen können, bleiben die Daten im gesamten Netz konsistent.

Apache Cassandra ist eine Open Source-NoSQL-Datenbank, die von der Apache Software Foundation verwaltet wird. Es handelt sich um eine Wide Column-Datenbank, mit der Sie Daten in einem verteilten Netz speichern können. Im Gegensatz zu MongoDB verfügt Cassandra jedoch über eine Masterless-Architektur, sodass es nicht nur einen einzigen, sondern mehrere Fehlerquellen gibt.

In Bezug auf das CAP-Theorem ist Cassandra eine AP-Datenbank – sie bietet Verfügbarkeit und Ausfalltoleranz, kann aber nicht immer Konsistenz bereitstellen. Da Cassandra keinen Master-Knoten hat, müssen alle Knoten kontinuierlich verfügbar sein. Cassandra bietet jedoch sukzessive Konsistenz, indem sie es Clients ermöglicht, jederzeit auf beliebige Knoten zu schreiben und Inkonsistenzen so schnell wie möglich auszugleichen.

Da Daten nur im Falle einer Netzpartition inkonsistent werden und Inkonsistenzen schnell behoben werden, bietet Cassandra eine „Reparatur“-Funktionalität, die es den Knoten ermöglicht, mit den anderen Knoten gleichzuziehen. Die ständige Verfügbarkeit führt jedoch zu einem hochleistungsfähigen System, das in vielen Fällen diesen Kompromiss wert sein kann.

Microservices sind flexibel verbundene, unabhängig voneinander bereitstellbare Anwendungskomponenten, die ihren eigenen Stack – einschließlich ihrer eigenen Datenbank und ihres eigenen Datenbankmodells – verwenden und über ein Netz miteinander kommunizieren. Da Sie Microservices sowohl auf Cloud-Servern als auch in On-Premises-Rechenzentren einsetzen können, erfreuen sie sich bei Hybrid- und Multicloud -Anwendungen großer Beliebtheit.

Ein gutes Verständnis des CAP-Theorems kann Ihnen bei der Auswahl der passenden Datenbank helfen, wenn Sie eine auf Microservices basierte Anwendung entwerfen, die von mehreren Standorten aus läuft. Wenn beispielsweise die Fähigkeit, das Datenmodell schnell zu iterieren und horizontal zu skalieren, für Ihre Anwendung unerlässlich ist, Sie aber eine sukzessive (im Gegensatz zu strikter) Konsistenz tolerieren können, kann eine AP-Datenbank wie Cassandra oder Apache CouchDB Ihre Anforderungen erfüllen und Ihre Bereitstellung vereinfachen . Andererseits könnte eine relationale Datenbank wie PostgreSQL die richtige Wahl für Sie sein, wenn Ihre Anwendung stark von Datenkonsistenz abhängt, wie etwa eine E-Commerce-Anwendung oder ein Zahlungsdienst.