Was wissen Sie über das CAP-Theorem? Verteilte Systeme sind heutzutage allgegenwärtig und bieten Unternehmen mehr betriebliche Flexibilität. Aber wie funktionieren sie wirklich und was sind die Grenzen dieses architektonischen Ansatzes? Lesen Sie unseren Artikel, um mehr zu erfahren. Auf dem Markt erscheinen ständig neue, fortschrittlichere Lösungen für Unternehmen. Sie sind komplexer und ermöglichen es Benutzern, verschiedene Arten von Informationen oder Dateien effizienter auszutauschen. Sie haben sicherlich bemerkt, dass moderne Anwendungen in der Regel webbasiert sind (wir benötigen Netzwerkzugriff, um sie nutzen zu können) und sehr oft global ausgeführt werden. Daher benötigen sie fortschrittliche Lösungen, um eine niedrige Latenz und Datenkonsistenz zu gewährleisten. Eine große Anzahl digitaler Produkte basiert heute auf verteilten Systemen. Natürlich ist kein verteiltes System völlig fehlerfrei. Bei dieser Art von Lösung müssen wir uns unterschiedlichen Herausforderungen stellen. Erlauben Sie uns, Ihnen das CAP-Theorem zu erklären.
Traditionelles System — Einzelverpackung
Das CAP-Theorem bezieht sich auf verteilte Systeme. Lassen Sie uns jedoch zunächst erklären, wie sich dieser architektonische Ansatz von dem traditionellen unterscheidet. In einem zentralisierten System gibt es einen zentralen Server (Master genannt), mit dem ein oder mehrere Client-Nodes (Slaves) verbunden sind. Es verwendet eine Client-Server-Architektur, bei der Clients Anfragen an den Hauptserver senden und dieser antwortet. Der Hauptvorteil dieses Ansatzes besteht darin, dass er sehr einfach einzurichten, zu sichern, zu aktualisieren und zu warten ist (indem die Verbindung zwischen einem Master und einem Slave hinzugefügt oder entfernt wird). Das größte Risiko ist die Instabilität des Systems und die Möglichkeit eines einzelnen Ausfalls — jedes Problem, das den Hauptserver betrifft, kann zum Ausfall des gesamten Systems führen. Vertikale Skalierung ist die einzige Option zum Hinzufügen von Ressourcen, was ebenfalls eine enorme Einschränkung darstellt. Das Hinzufügen einer größeren Box ist ab einem bestimmten Limit nicht mehr möglich - es könnte eine Last geben, die einfach zu hoch ist, als dass eine einzelne Maschine sie bewältigen könnte.
Architektur traditioneller zentralisierter Systeme
Wenn es um die Speicherung von Daten geht, ist ein herkömmliches System der einfachste Weg, um die ACID-Prinzipien zu erreichen (EINTomizität, CKonsistenz, ICHAbgeschiedenheit, DHaltbarkeit) — das Konzept, auf dessen Grundlage relationale Datenbanken aufgebaut werden. Der Begriff ACID bedeutet „alles oder nichts“ — eine Abfolge von Operationen, die diesen Prinzipien entspricht, wird Transaktion, was wiederum als ein einzelnes behandelt wird Einheit — es gelingt oder scheitert komplett, dazwischen gibt es nichts. Alle Daten an einem Ort (auf dem Master-Server) zu haben, garantiert, dass die Datenbank in einem harmonischen Zustand bleibt. Dieses zentralisierte System lebt dann in einer Welt von standardmäßig konsistent.
Ein verteiltes System — es gibt keinen Chef
Nach dem Eintritt in das Zeitalter der schnellen Internetentwicklung änderten sich unsere Geschäftsanforderungen drastisch und relationale Datenbanken reichten nicht mehr aus, um den Speicherbedarf komplexer Systeme zu decken. Nicht nur die Datenkonsistenz ist das Hauptanliegen, auch Verfügbarkeit, Leistung und Skalierbarkeit sind heute ebenso wichtig. Die besten Ingenieure auf unserem Planeten mussten clevere Lösungen entwickeln, unter denen verteilte Systeme große Popularität erlangt haben (und das CAP-Theorem bezieht sich speziell auf verteilte Datenspeicher). Sie basieren auf der Idee, dass es nicht mehr einen Chef gibt, der Verantwortung an sein Team delegiert, sondern dass jedes Mitglied die Macht hat, Entscheidungen zu treffen. Technisch gesehen ist ein verteiltes System eine Sammlung unabhängiger Knoten an verschiedenen Orten, die miteinander verbunden sind und Informationen austauschen. Es funktioniert wie ein einziges logisches Datennetzwerk und sieht für den Endbenutzer so aus, als wäre es ein einziger Computer, während hinter den Kulissen der gesamte Zustand des Systems über mehrere Knoten hinweg repliziert wird.
Architektur verteilter Systeme
Einige der größten Vorteile eines verteilten Systems sind:
- Skalierbarkeit — es ist möglich, sowohl die vertikale als auch die horizontale Skalierung zu nutzen, indem jedem Knoten Rechenressourcen hinzugefügt oder zusätzliche Knoten mit dem Netzwerk verbunden werden (der zweite ist fast unbegrenzt)
- Fehlertoleranz — falls ein oder mehrere Knoten ausfallen, ist das gesamte System stabil — läuft und läuft — da immer einige Knoten verfügbar sind, die den Benutzern zur Verfügung stehen
- Leistung — Die Komponenten des Systems teilen sich Ressourcen und werden gleichzeitig ausgeführt, wodurch es möglich ist, die gesamte Arbeitslast auf allen Knoten auszugleichen
Komplizierter wird es, wenn es um das Speichern von Daten geht. Bei einem verteilten System ist es ziemlich schwierig, einen Konsens zu erzielen. Wenn neue Datensätze in die Datenbank geschrieben werden, muss man entscheiden, wann sie als abgeschlossen betrachtet werden sollen — ob die Daten auf einem Knoten bestehen bleiben oder erst, nachdem sie überall repliziert wurden. Das bringt uns in eine Welt, in der Konsistenz ist eine Wahl.
Das CAP-Theorem in Big Data
Das CAP-Theorem wurde im Jahr 2000 von Dr. Eric Brewer erstellt. Es bezieht sich auf verteilte Systeme und besagt, dass Konsistenz, Verfügbarkeit, und Partitionstoleranz, nur zwei von drei können erreicht werden (alle drei Dimensionen kann man sich eigentlich eher als Bereiche als als boolesche Werte vorstellen).
Graphische Darstellung des CAP-Theorems
Konzentrieren wir uns zunächst auf die Partitionstoleranz. Partitionstoleranz bedeutet im CAP-Theorem, dass ein System auch dann weiterfunktioniert, wenn ein Netzwerkausfall zwischen zwei oder mehr Knoten auftritt. Beachten Sie, dass sich das CAP-Theorem nur auf verteilte Systeme bezieht. Partitionierung ist daher ein Muss. Wir können also entweder Verfügbarkeit und Partitionstoleranz (ein AP-System) oder Konsistenz und Partitionstoleranz (ein CP-System) garantieren, aber sowohl Konsistenz als auch Verfügbarkeit (CA) zu haben, ist niemals eine Option. Die Entwurfsprinzipien des CAP-Theorems besagen, dass, wenn wir Verfügbarkeit der Konsistenz vorziehen, jeder Knoten weiterhin Anfragen ohne Fehler bedient, aber es gibt keine Garantie dafür, dass eine Antwort die neuesten Schreibvorgänge enthält. Im anderen Fall erhält jede Anfrage die neuesten Daten, aber es kann zu einem Fehler kommen, wenn sie den Kontakt zu anderen Replikaten verliert, und es entsteht eine Latenzstrafe.
Abhilfe kommt vom Himmel — Datenmanagement in der Cloud
Kann das Datenbankproblem des CAP-Theorems irgendwie gelöst werden? Cloud-Anbieter bieten verschiedene moderne Datenspeicherlösungen für den Umgang mit CAP-Kompromissen an, um die Vorteile hoch skalierbarer Datenspeicher nutzen zu können. Es gibt keine einzige magische Lösung, da die Dimensionen der Optimierung sehr unterschiedlich sind. Wir können zwischen einer Reihe von Diensten wählen, von denen jeder für eine bestimmte Arbeitslast optimiert ist. Schauen wir uns einige Beispiele an.
Google Cloud - Cloud Spanner - Konsistenz
Spanner ist eine globale SQL-Datenbank, die in Google Cloud angeboten wird. Es ist technisch gesehen ein CP-System, was bedeutet, dass es immer für Konsistenz sorgt. Es verwendet TrueTime (eine Funktion, die verteilte Uhr verwendet, um Transaktionen Zeitstempel zuzuweisen), die es Benutzern ermöglicht, global konsistente Lesevorgänge in der gesamten Datenbank durchzuführen, ohne Schreibvorgänge zu blockieren. Spanner behauptet jedoch auch, eine Verfügbarkeit von fast 100% zu erreichen — um genau zu sein, besser als „5 9s“ (99,999%). Aus diesem Grund behauptet Spanner vernünftigerweise, tatsächlich ein „effektives CA-System“ zu sein.
Amazon Web Services — Dynamo — Verfügbarkeit
Dynamo ist ein hochverfügbares Key-Value-Speichersystem, das in Amazon Web Services verwendet wird und so konzipiert ist, dass es für verschiedene Amazon-Angebote ein „Always-on“ -Erlebnis bietet. Amazon S3 (Objektspeichersystem) basiert beispielsweise auf den Kernfunktionen von Dynamo, um Skalierungsanforderungen und Zuverlässigkeitsanforderungen zu erfüllen. Die Verfügbarkeit kann hier durch Einbußen bei der Konsistenz erreicht werden (mithilfe des sogenannten „Eventualkonsistenzmodells“ — alle Updates erreichen irgendwann in der Zukunft alle Replikate).
Microsoft Azure - Cosmos DB - triff deine Wahl
Cosmos DB ist eine weltweit verteilte NoSQL-Datenbank, die von Microsoft in der Azure-Cloud angeboten wird. Benutzer können eines von fünf vordefinierten Konsistenzmodellen wählen. Jedes von ihnen gibt unterschiedliche Raten für die CAP-Felder an. Zur Auswahl stehen: Stark (bevorzugt Daten) Konsistenz vor allem anderen), Eingeschränkt-staatenlos, Sitzung, Konsistentes Präfix, und Eventuell (hier Verfügbarkeit ist der Gewinner). Diese Optionen machen das Dilemma von einer „0-1“ -Wahl zu einem breiten Spektrum an Möglichkeiten, die auf die Bedürfnisse der Kunden zugeschnitten sind. Wenn Ihr Unternehmen nach einer modernen Datenspeicherlösung sucht, die allen Benutzern ein schnelles und responsives Erlebnis bietet, zögern Sie nicht kontaktiere uns. Wir helfen Ihnen, die Herausforderungen des Datenmanagements zu bewältigen und das Beste aus Ihrem System herauszuholen. Weitere Informationen zu Data Engineering finden Sie in unserem Blog:
- Testgetriebene Entwicklung in Python mit Pytest
- Was ist Datenbankdenormalisierung? Vor- und Nachteile sowie Beispiele
- Definition der Datenpipeline — Design und Prozess
Bibliographie:
- Brauer, Eric. Spanner, TrueTime und das CAP-Theorem. 2017.
- Decandia Giuseppe, Hastorun Deniz, Jampani Madan, u.a. Dynamo: Amazons hochverfügbarer Key-Value Store. Überprüfung der ACM SIGOPS-Betriebssysteme, 41 (6), 205-220. 2007.
- Dimitrowitsch, Slavik. Architektur II: Verteilte Datenspeicher | Amazon Web Services. 2015: https://aws.amazon.com/blogs/startups/distributed-data-stores-for-mere-mortals/
- Microsoft. Entwickeln Sie moderne Apps mit Big Data auf globaler Ebene. 2017. https://www.arbelatech.com/insights-resources/white-papers/build-modern-apps-with-big-data-at-a-global-scale
