Was weißt du über das CAP-Theorem? Verteilte Systeme sind heutzutage allgegenwärtig und bieten Unternehmen mehr operative Flexibilität. Aber wie funktionieren sie wirklich und was sind die Einschränkungen dieses architektonischen Ansatzes? Lies unseren Artikel, um mehr zu erfahren.
Neue, fortschrittlichere Lösungen für Unternehmen erscheinen ständig auf dem Markt. Sie sind komplexer und ermöglichen es den Nutzern, verschiedene Arten von Informationen oder Dateien effizienter zu teilen. Du hast sicherlich bemerkt, dass moderne Anwendungen meist web-based sind (wir brauchen Netzwerkzugang, um sie zu nutzen) und sehr oft global laufen. Sie benötigen also fortschrittliche Lösungen, um low latency und data consistency zu gewährleisten. Viele digitale Produkte basieren heute auf distributed systems. Natürlich ist kein distributed system völlig fehlerfrei. Mit dieser Art von Lösung müssen wir uns verschiedenen Herausforderungen stellen. Lass uns dir das CAP-Theorem erklären.
Traditional system – single box
Das CAP-Theorem bezieht sich auf distributed systems, aber zunächst wollen wir erklären, wie sich dieser architektonische Ansatz vom traditionellen unterscheidet. In einem zentralisierten System gibt es einen zentralen Server (genannt master), 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 ist, dass er sehr einfach einzurichten, zu sichern, zu aktualisieren und zu warten ist (durch Hinzufügen oder Entfernen der Verbindung zwischen master und slave). Das größte Risiko ist die Instabilität des Systems und die Möglichkeit eines single point of failure – jedes Problem, das den Hauptserver betrifft, kann dazu führen, dass das gesamte System ausfällt. Vertical scaling als einzige Option, Ressourcen hinzuzufügen, ist ebenfalls eine große Einschränkung. Das Hinzufügen einer größeren Maschine ist nach einer bestimmten Grenze nicht mehr möglich – es kann eine Last geben, die für eine einzelne Maschine einfach zu groß ist.
Architecture of traditional centralized systems
Wenn es um die Speicherung von Daten geht, ist ein traditionelles System der einfachste Weg, um die ACID principles (Atomicity, Consistency, Isolation, Durability) zu erreichen – das Konzept, auf dem relationale Datenbanken aufgebaut sind. Der Begriff ACID bedeutet „alles oder nichts“ – eine Sequenz von Operationen, die diese Prinzipien erfüllt, wird als transaction bezeichnet, die wiederum als eine einzige Einheit behandelt wird – sie ist entweder vollständig erfolgreich oder vollständig fehlgeschlagen, es gibt nichts dazwischen. Wenn sich alle Daten an einem Ort (auf dem master server) befinden, ist garantiert, dass die database in einem harmonischen Zustand bleibt. Dieses zentralisierte System lebt also standardmäßig in einer Welt der consistency.
A distributed system – there is no boss
Mit dem rasanten Internetwachstum haben sich unsere Geschäftsanforderungen drastisch verändert, und relationale Datenbanken reichten nicht mehr aus, um die Speicherbedürfnisse komplexer Systeme zu erfüllen. Nicht nur data consistency ist das Hauptanliegen, sondern auch availability, performance und scale sind heute ebenso wichtig. Die besten Ingenieure mussten clevere Lösungen finden, unter denen distributed systems große Popularität erlangten (und das CAP-Theorem bezieht sich speziell auf distributed data stores). Sie basieren auf der Idee, dass es keinen boss mehr gibt, der Aufgaben delegiert, sondern jedes Mitglied die Macht hat, Entscheidungen zu treffen. Technisch gesehen ist ein distributed system eine Sammlung von independent nodes, die an verschiedenen Standorten platziert sind, miteinander verbunden sind und Informationen teilen. Es funktioniert als ein einziges logical data network und erscheint dem Endnutzer wie ein Computer, während im Hintergrund der gesamte state des Systems über mehrere nodes repliziert wird.
Architecture of distributed systems
Einige der größten Vorteile von distributed systems sind:
- Scalability – es ist möglich, sowohl vertical als auch horizontal scaling zu nutzen, indem compute resources zu jedem node hinzugefügt oder additional nodes zum Netzwerk hinzugefügt werden (letzteres ist nahezu unbegrenzt)
- Fault tolerance – wenn ein oder mehrere nodes ausfallen, bleibt das gesamte System stable – up and running – da immer einige nodes verfügbar sind, um die users zu bedienen
- Performance – die Komponenten des Systems teilen sich resources und laufen concurrently, was es ermöglicht, die gesamte workload auf alle nodes zu verteilen
Komplizierter wird es, wenn es um die Speicherung von Daten geht. In einem distributed system ist es ziemlich schwierig, consensus zu erreichen. Beim Schreiben neuer records in die database muss entschieden werden, wann dies als complete gilt – wenn die data auf einem node gespeichert ist oder erst, wenn sie überall repliziert wurde. Das führt uns in eine Welt, in der consistency eine Wahl ist.
The CAP Theorem in Big Data
Das CAP-Theorem wurde im Jahr 2000 von Dr. Eric Brewer entwickelt. Es bezieht sich auf distributed systems und besagt, dass von consistency, availability und partition tolerance nur zwei von drei erreicht werden können (alle drei Dimensionen können tatsächlich eher als ranges denn als booleans betrachtet werden).
Graphical representation of CAP Theorem
Konzentrieren wir uns zunächst auf partition-tolerance. Partition-tolerance im CAP-Theorem bedeutet, dass ein System auch dann weiterarbeitet, wenn ein network failure zwischen zwei oder mehr nodes auftritt. Beachte, dass das CAP-Theorem nur für distributed systems gilt, daher ist partitioning ein Muss. Wir können also entweder availability und partition-tolerance (AP system) oder consistency und partition-tolerance (CP system) garantieren, aber sowohl consistency als auch availability (CA) sind nie gleichzeitig möglich.
CAP theorem system design principles besagen, dass, wenn wir availability über consistency stellen, jeder node weiterhin queries ohne Fehler bedient, aber es gibt keine Garantie, dass die response die neuesten writes enthält. Im anderen Fall erhält jede request die neuesten data, aber es kann zu einem error kommen, wenn der Kontakt zu anderen replicas verloren geht, und wir haben eine latency penalty.
Remedies come from the sky – data management in the cloud
Kann das Datenbankproblem des CAP-Theorems irgendwie gelöst werden? Cloud providers bieten verschiedene moderne data storage solutions an, um mit den CAP tradeoffs umzugehen und die Vorteile von highly scalable data stores zu nutzen. Es gibt keine einzige magische Lösung, da die dimensions for optimization sehr unterschiedlich sind. Wir können aus einer Reihe von services wählen, von denen jede für eine bestimmte workload optimiert ist. Schauen wir uns einige Beispiele an.
Google Cloud – Cloud Spanner – consistency
Spanner ist eine globale SQL database, die in Google Cloud angeboten wird. Technisch gesehen ist es ein CP system, was bedeutet, dass es immer consistency bietet. Es verwendet TrueTime (ein feature, das eine distributed clock nutzt, um transactions timestamps zuzuweisen), das es Nutzern ermöglicht, globally consistent reads über die gesamte database hinweg durchzuführen, ohne writes zu blockieren. Spanner behauptet jedoch auch, fast 100% availability zu erreichen – genauer gesagt, besser als ‘5 9s’ (99,999%). Deshalb behauptet Spanner vernünftigerweise, tatsächlich ein ‘effectively CA’ system zu sein.
Amazon Web Services – Dynamo – availability
Dynamo ist ein high availability key-value storage system, das in Amazon Web Services verwendet wird und entwickelt wurde, um ein ‘always-on’ experience für verschiedene Amazon-Angebote zu bieten. Amazon S3 (object storage system) basiert beispielsweise auf den core features von Dynamo, um scaling needs und reliability requirements zu erfüllen. Availability kann hier durch das Opfern von consistency erreicht werden (durch das sogenannte ‘eventual consistency model’ – alle updates erreichen schließlich irgendwann alle replicas).
Microsoft Azure – Cosmos DB – take your choice
Cosmos DB ist eine global verteilte NoSQL database, die von Microsoft in der Azure cloud angeboten wird. Users können eines von fünf pre-defined consistency models wählen – jedes bietet unterschiedliche rates für die CAP’s fields. Die Optionen sind: Strong (stellt data consistency über alles), Bounded-stateless, Session, Consistent prefix und Eventual (hier gewinnt availability). Diese Optionen machen das Dilemma von einer ‘0-1’-Entscheidung zu einem breiten Spektrum an Möglichkeiten, die auf die Bedürfnisse der Kunden zugeschnitten sind.
Wenn dein Unternehmen eine moderne data storage solution sucht, die allen users eine schnelle und reaktionsschnelle Erfahrung bietet, zögere nicht, uns zu kontaktieren. Wir helfen dir, data management challenges zu meistern und das Beste aus deinem System herauszuholen.
Die zukunft des data engineering trends fur 2025
Data warehouse vs data lake vs lakehouse vergleich
Neues uberarbeitetes ui in airflow 2-0
