CAP-Lehrsatz

menu icon

CAP-Lehrsatz

In diesem Leitfaden betrachten wir den CAP-Lehrsatz und dessen Relevanz bei der Entwicklung verteilter Anwendungen und Auswahl eines NoSQL- oder relationalen Datenspeichers.

Was ist der CAP-Lehrsatz?

Haben Sie schon einmal eine Anzeige für einen Landschaftsgärtner, Maler oder anderen Handwerker gesehen, die mit der Überschrift beginnt, „Billig, schnell und gut: Wählen Sie zwei“?

Der CAP-Lehrsatz wendet eine ähnliche Art Logik auf verteilte Systeme an - nämlich, dass ein verteiltes System nur zwei von drei gewünschten Eigenschaften liefern kann: Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz (das "C", ''A" und "P" in CAP).

Ein verteiltes System ist ein Netzwerk, in dem Daten auf mehreren Knoten (physische oder virtuelle Maschinen) gleichzeitig gespeichert sind. Da es sich bei allen Cloud-Anwendungen um verteilte Systeme handelt, ist es unerlässlich, den CAP-Lehrsatz zu verstehen, wenn Sie eine Cloud-Anwendung entwerfen, damit Sie ein Datenverwaltungssystem wählen können, das die Eigenschaften bietet, die Ihre Anwendung am meisten benötigt.

Der CAP-Lehrsatz wird auch Brewers-Lehrsatz genannt, da er erstmals von Professor Eric A. Brewer im Jahr 2000 in einem Vortrag über die verteilte Datenverarbeitung aufgestellt wurde. Zwei Jahre später veröffentlichten die MIT-Professoren, Seth Gilbert und Nancy Lynch einen Beweis für „Brewers Vermutung.“

Das „CAP“ im CAP-Lehrsatz, erklärt

Lassen Sie uns etwas ausführlicher auf die drei Eigenschaften verteilter Systeme eingehen, auf die sich der CAP-Lehrsatz bezieht.

Konsistenz

Konsistenz bedeutet, dass alle Clients die gleichen Daten zur gleichen Zeit sehen, egal mit welchem Knoten sie sich verbinden. Damit dies geschehen kann, 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“ angesehen 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 Arbeitsknoten im verteilten System geben für jede Anfrage eine gültige Antwort zurück, ohne Ausnahme.

Partitionstoleranz

Eine Partition ist eine Kommunikationsunterbrechung innerhalb eines verteilten Systems - eine verlorene oder vorübergehend verzögerte Verbindung zwischen zwei Knoten. Partitionstoleranz bedeutet, dass der Cluster trotz einer beliebigen Anzahl von Kommunikationsausfällen zwischen den Knoten im System weiterarbeiten muss.

CAP-Lehrsatz NoSQL-Datenbanktypen

NoSQL-Datenbanken (nicht relationale Datenbanken)sind ideal für verteilte Netzwerkanwendungen. Im Gegensatz zu ihren vertikal skalierbaren SQL (relationalen) Pendants sind NoSQL-Datenbanken horizontal skalierbar und vom Design her verteilt - sie können schnell über ein wachsendes Netzwerk skalieren, das aus mehreren miteinander verbundenen Knoten besteht. (Siehe „SQL vs. NoSQL-Datenbanken: Was ist der Unterschied?“ für weitere Informationen.)

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

  • CP-Datenbank: Eine CP-Datenbank bietet Konsistenz und Partitionstoleranz auf Kosten der Verfügbarkeit. Wenn eine Partition zwischen zwei beliebigen Knoten auftritt, muss das System den nicht konsistenten Knoten herunterfahren (d. h. nicht verfügbar machen), bis die Partition aufgelöst ist.
  • AP-Datenbank: Eine AP-Datenbank bietet Verfügbarkeit und Partitionstoleranz auf Kosten der Konsistenz. Wenn eine Partitionierung auftritt, bleiben alle Knoten verfügbar, aber diejenigen am falschen Ende einer Partitionierung geben möglicherweise eine ältere Version der Daten zurück als andere. (Wenn die Partition aufgelöst ist, synchronisieren die AP-Datenbanken normalerweise die Knoten neu, um alle Inkonsistenzen im System zu beheben.)
  • CA-Datenbank: Eine CA-Datenbank liefert Konsistenz und Verfügbarkeit über alle Knoten hinweg. Dies ist jedoch nicht möglich, wenn eine Partition zwischen zwei beliebigen Knoten im System vorhanden ist und daher keine Fehlertoleranz liefern kann.

Wir haben diesen Typ aus einem bestimmten Grund zuletzt aufgeführt - in einem verteilten System lassen sich Partitionen nicht vermeiden. Während wir also theoretisch über eine verteilte CA-Datenbank diskutieren können, kann eine verteilte CA-Datenbank für alle praktischen Zwecke nicht existieren. Das bedeutet jedoch nicht, dass Sie keine CA-Datenbank für Ihre verteilte Anwendung haben können, wenn Sie eine benötigen. Viele relationale Datenbanken, wie z. B. PostgreSQL, liefern Konsistenz und Verfügbarkeit und können mittels Replikation auf mehreren Knoten bereitgestellt werden.

MongoDB und der CAP-Lehrsatz (CP)

MongoDB ist ein beliebtes NoSQL-Datenbankmanagementsystem, das Daten als BSON-Dokumente (binär-JSON) speichert. Es wird häufig für Big-Data- und Echtzeitanwendungen verwendet, die an mehreren verschiedenen Standorten ausgeführt werden. Bezogen auf den CAP-Leitsatz ist MongoDB ein CP-Datenspeicher - Netzwerkpartitionen werden aufgelöst durch Erhaltung der Konsistenz, während bei der Verfügbarkeit Kompromisse eingegangen werden.

MongoDB ist ein Single-Master-System - jedes Replikatset (Link befindet sich außerhalb von IBM) kann nur einen Primärknoten haben, der alle Schreiboperationen empfängt. Alle anderen Knoten in der gleichen Replikatgruppe sind Sekundärknoten, die das Betriebsprotokoll des primären Knotens replizieren und auf ihren eigenen Dataset anwenden. Standardmäßig lesen Clients auch vom Primärknoten, aber sie können auch eine Lese-Vorgabe angeben, die es ihnen erlaubt, von Sekundärknoten zu lesen (der Link liegt außerhalb von IBM).

Wenn der Primärknoten nicht mehr verfügbar ist, wird der Sekundärknoten mit dem neuesten Operationsprotokoll als neuer Primärknoten gewählt. Sobald alle anderen Sekundärknoten zum neuen Master aufgeschlossen haben, ist der Cluster wieder verfügbar. Da Clients während dieses Intervalls keine Schreibanforderungen erstellen können, bleiben die Daten im gesamten Netzwerk konsistent.

Cassandra und der CAP-Lehrsatz (AP)

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 Netzwerk speichern können. Im Gegensatz zu MongoDB verfügt Cassandra jedoch über eine Masterless-Architektur und hat daher mehrere Ausfallpunkte statt eines einzigen.

Bezogen auf den CAP-Lehrsatz ist Cassandra eine AP-Datenbank -sie liefert Verfügbarkeit und Partitionstoleranz, kann aber nicht immer Konsistenz liefern. Da Cassandra keinen Master-Knoten hat, müssen alle Knoten kontinuierlich verfügbar sein. Cassandra bietet jedoch mögliche Konsistenz indem Clients zu jeder Zeit auf beliebige Knoten schreiben und Inkonsistenzen so schnell wie möglich ausgeglichen werden können.

Da Daten nur im Falle einer Netzpartition inkonsistent werden und Inkonsistenzen schnell behoben werden, bietet Cassandra eine "Reparatur"-Funktionalität (der Link befindet sich außerhalb von IBM), um den Knoten zu helfen, zu ihren Peers aufzuschließen. Die ständige Verfügbarkeit führt jedoch zu einem hochleistungsfähigen System, das in vielen Fällen den Kompromiss wert sein könnte.

Arbeiten mit Mikroservices

Microservices sind flexibel verbundene, unabhängig voneinander einsetzbare Anwendungskomponenten, die einen eigenen Stapelspeicher - einschließlich eigener Datenbank und eigenen Datenbankmodells - enthalten und über ein Netzwerk miteinander kommunizieren. Da Microservices sowohl auf Cloud-Servern als auch in On-Premises-Rechenzentren ausgeführt werden können, sind sie für Hybrid- und Multicloud-Anwendungen sehr beliebt geworden.

Das Verständnis des CAP-Lehrsatzes kann Ihnen helfen, die beste Datenbank zu wählen, wenn Sie eine Microservices-basierte Anwendung entwerfen, die von mehreren Standorten aus läuft. Wenn zum Beispiel die Fähigkeit, das Datenmodell schnell zu replizieren und horizontal zu skalieren, für Ihre Anwendung unerlässlich ist, Sie aber eine eventuelle (im Gegensatz zu einer strikten) Konsistenz tolerieren können, kann eine AP-Datenbank wie Cassandra oder Apache CouchDB Ihre Anforderungen erfüllen und Ihren Implementierung vereinfachen. Wenn Ihre Anwendung jedoch stark von der Datenkonsistenz abhängig ist - wie in einer eCommerce-Anwendung oder einem Zahlungsservice - können Sie sich für eine relationale Datenbank wie PostgreSQL entscheiden.

CAP-Lehrsatz und IBM Cloud

IBM bietet ein ganzes Spektrum von vollständig verwalteten Datenbankservices. Außer relationalen Datenbankmanagementsystemen können Sie auch MongoDB, Cloudant (ein anderer verteilter AP-Datenspeicher), Elasticsearch, etcd und andere Datenbanklösungen in IBM Cloud ausführen.

Um einen Einblick in unsere gesamte Datenbankauswahl zu erhalten (ohne jegliche Verpflichtung), melden Sie sich für eine IBMid an und erstellen Sie Ihr IBM Cloud-Konto.