Haben Sie schon einmal eine Anzeige für einen Landschaftsgärtner, Maler oder einen anderen Handwerker gesehen, die mit der Überschrift beginnt: „Billig, schnell und gut – such dir zwei aus“? Das CAP-Theorem wendet eine ähnliche Art von Logik auf verteilte Systeme an.
Ein verteiltes System ist ein Netz, das Daten auf mehr als einem Knoten (Physical Machines oder Virtual Machines) 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.
Bleiben Sie mit dem Think-Newsletter über die wichtigsten – und faszinierendsten – Branchentrends in den Bereichen KI, Automatisierung, Daten und mehr auf dem Laufenden. Weitere Informationen finden Sie in der IBM Datenschutzerklärung.
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:
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 – jeder Replikatsatz kann nur einen primären Knoten haben, der alle Schreibvorgänge 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, 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.
Erstellen und verwalten Sie intelligente Streaming-Datenpipelines über eine intuitive grafische Benutzeroberfläche, die eine nahtlose Datenintegration in Hybrid- und Multicloud-Umgebungen ermöglicht.
Watsonx.data ermöglicht es Ihnen, Analysen und KI mit all Ihren Daten zu skalieren, unabhängig davon, wo sie sich befinden, und zwar über einen offenen, hybriden und kontrollierten Datenspeicher.
Erschließen Sie den Wert von Unternehmensdaten mit IBM Consulting® und bauen Sie ein erkenntnisgesteuertes Unternehmen auf, das Ihnen geschäftliche Vorteile verschafft.
