Eine Einführung in “Eventuelle Konsistenz”
In einer perfekten Welt würde die Internet-Computerumgebung aus einem einzigen gigantischen Rechner und einer Festplatte bestehen, auf der alle Daten gespeichert sind, ohne dass man sich Sorgen um eventuelle Hardwarefehler oder Datenverlust zu machen braucht.
Selbstverständlich ist unsere Computerwelt nicht perfekt. Miteinander verbundene Computerumgebungen verteilen die Anforderungen an viele verschiedene Rechner, Netzwerke und Speichersysteme.
Im Fehlerfall werden Daten auf mehreren Speichereinheiten gesichert oder repliziert. Diese Speichereinheiten werden auch als Knotenpunkte (engl. Nodes) bezeichnet. Beim Entwerfen neuer Datenbankanwendungen, müssen Entwickler berücksichtigen, wie konsistent Daten für den Benutzer verfügbar sind.
Die Eventuelle Konsistenz (engl. Eventual Consistency) ist ein Designmodell, bei dem die Verarbeitungsgeschwindigkeit (Latenz) Vorrang vor der Datenkonsistenz hat (unabhängig davon, ob die Daten genau auf allen Knoten repliziert werden oder nicht). Starke Konsistenz (engl. Strong Consistency) hingegen favorisiert konsistente Datenlieferung auf Kosten von Systemverfügbarkeit.
Welches Modell in Frage kommt, hängt im Endeffekt davon ab, um welche Datenbank es sich handelt und wie die Daten verwendet werden sollen. Laut dem CAP-Theorem kann eine verteilte Datenbank maximal zwei der drei Eigenschaften, also Konsistenz, Verfügbarkeit und Ausfalltoleranz (eng. Partition Tolerance) aufweisen. Das “eventuelle Konsistenz” Modell ist dementsprechend für manche Anwendungen akzeptabel. Für manche Anwendungen, wie zum Beispiel Finanzdienstleistungen oder die Analyse von Streaming-Daten ist eventuelle Konsistenz allerdings nicht vorgesehen.
Was ist das CAP Theorem?
An den Anfängen der elektronischen Datenverarbeitung wurden alle Vorgänge auf einer einzelnen CPU oder einem Großrechner ausgeführt. Die Client-Server-Architektur trennte zwar die Benutzerknoten von der Back-End-Verarbeitung dennoch erbrachte ein einziger Prozessor die gesamte Rechenarbeit.
Dementgegen wird bei sogenannten Verteilten Systemen der Verarbeitungsaufwand auf mehrere gleichzeitig arbeitenden Prozessoren verteilt, wobei auch Netzwerkgeräte und Speichersysteme ins Spiel kommen. Verteiltes Rechnen wird dadurch ermöglicht, dass mehrere Computersysteme miteinander verknüpft werden, um die Verarbeitungsleistung, die Geschwindigkeit und die Redundanz zu verbessern. Sollte in diesem Fall eine CPU (oder Knoten) ausfallen, wird der Prozess durch einen anderen Knoten mit konsistenten und korrekten Daten weiterverarbeitet oder abgeschlossen.
Das CAP-Theorem (auch bekannt als Brewer’s Theorem, benannt nach Professor Eric Brewer von der UC Berkeley, der das Konzept im Jahr 1998 erstmals vorgestellte) besagt, dass es Kompromisse zwischen Datenkonsistenz, Verfügbarkeit und Partitionstoleranz gibt. Konsistenz bedeutet, dass Benutzer auf allen Knoten gleichzeitig dieselben Daten sehen können. Verfügbarkeit bedeutet, dass das System bei einem Knotenausfall weiterhin ungestört läuft. Partitionstoleranz bedeutet, dass Knoten bei einem Systemausfall weiterhin funktionieren. In manchen Fällen ist es notwendig, dass dem Benutzer präsentierten Daten auf allen Knoten identisch sind. Dieses Konzept wird als Starke Konsistenz bezeichnet. Diese ist z.B. bei Finanztransaktionen die Norm.
Der Nachteil einer starken Konsistenz ist die Zeit, die alle Knoten benötigen, um Daten zu replizieren und als „konsistenter“ Datensatz verfügbar zu sein. Wenn Priorität die Datenverfügbarkeit ist, werden die Daten möglicherweise nicht auf allen Knoten gleichzeitig aktualisiert. Die Verfügbarkeit ist schneller, aber der Kompromiss ist die Datengenauigkeit. Dieses Modell wird als Eventuelle Konsistenz bezeichnet. Nicht finanzielle Website-Updates auf Domain-Name-Servern (DNS) sind ein typisches Beispiel für dessen Anwendung.
Wenn Ihr Datenziel Konsistenz und Verfügbarkeit ist, ist die Verwendung einer relationalen Datenbank (SQL, MySQL, Postgres, MsSQL) angesagt. Wenn Konsistenz und Partitionstoleranz erwünscht sind, ist eine nicht relationale (NoSQL) Datenbank wie MongoDB, Redis, oder CouchBase möglicherweise anzuwenden. Wenn es sich um Konsistenz und Verfügbarkeit handelt, kommen CouchBase, Cassandra und Amazon DynamoDB in Frage. Beachten Sie, dass sich die Datenbankmerkmale im Laufe der Zeit verschieben können.
Hintergrund zur Eventuellen Konsistenz
Die Eventuelle Konsistenz ist ein Modell der verteilten Datenverarbeitung, bei dem Geschwindigkeit oder geringe Latenz gegenüber dem Risiko, veraltete Daten anzuzeigen, im Vordergrund steht. Es ist ein schwaches Modell in dem Sinne, dass es eine geringe Latenz gegenüber der Konsistenz betont.
Daten werden schließlich „konsistent“ angezeigt, sobald alle replizierten Knoten auf dem neuesten Stand sind. Das Aktualisieren von Domain Name Services (DNS) ist ein Beispiel für ein eventuelles Konsistenzmodell. DNS-Updates können je nach Beliebtheit der Domain im Internet von einigen Minuten bis zu 24 Stunden in Anspruch nehmen. Die Tatsache, dass der DNS nicht sofort aktualisiert wird, ist für die Anwendung nicht kritisch und verspricht Verfügbarkeit über Konsistenz.
Anwendungen, die einzelne Schlüssel über eine große geografische Region aktualisieren, werden mithilfe des späteren Konsistenzmodells erstellt. Nehmen wir eine Social-Media-Anwendung als Beispiel. Diese fordert die Leser dazu auf, einen Beitrag mit einem „Like“ zu versehen. Ein Benutzer in Schweden klickt “Like” und diese Statusänderung wird weltweit übertragen. Zum selben Zeitpunkt macht ein mexikanischer Benutzer das Gleiche. Die Statusänderung wird schließlich auf dem schwedischen Benutzerkonto aktualisiert. Da dieses Update keine wesentliche Änderung darstellt, ist das System leicht verfügbar und wichtiger als die Datenkonsistenz. Diese Änderungen des Datenstatus sind typisch für viele Cloud-basierte Anwendungen, die Datenbanken auf Hunderten, wenn nicht Tausenden von Servern auf der ganzen Welt aktualisieren. Die Erwartung, diese Systeme verfügbar und reaktionsschnell zu halten, ist wichtiger als die konsistente Darstellung von Daten.
Nicht relationale Datenbanken (NoSQL) sind aus vielen Gründen eine beliebte Wahl für Anwendungen mit Eventueller Konsistenz. Diese Datenbanken speichern nicht strukturierte Daten im JSON-Dokumentformat im Unterschied zu den strukturierten Zeilen und Spalten, die in strukturierten (SQL) Datenbanken verwendet werden. Beliebte NoSQL-Datenbanken sind MongoDB, Cassandra und HBase.
Eventuelle Konsistenz gegen Starke Konsistenz
Bei der Wahl zwischen Eventueller Konsistenz und Starker Konsistenz müssen Entwickler ermitteln, welches Modell den Benutzerbedürfnissen und den Anwendungsanforderungen ihrer Benutzer entspricht.
Wenn Sie eine Cloud-basierte Anwendung mit viel Flexibilität benötigen, bietet die eventuelle Konsistenz eine geringe Latenz und leichte Verfügbarkeit für eine qualitativ hochwertige webbasierte Benutzererfahrung. Die Eventuelle Konsistenz wird auch dann bevorzugt, wenn es sich um Daten handelt, welche nur unregelmäßig aktualisiert werden. Die Adresse in Ihrem online Benutzerprofil ist ein gutes Beispiel dafür. Es kann Minuten dauern, bis diese als Update konsistent verfügbar ist. Diese Verzögerung ist nicht unbedingt erwünscht allerdings wird die Leistung der Anwendung dadurch keinerlei beeinflusst.
Das sogenannte BASE-Konsistenzmodell wird für Anwendungen mit eventueller Konsistenz weiträumig akzeptiert. Das Akronym BASE steht für:
BA – Basically Available – die Datenbank ist grundsätzlich verfügbar.
S – Soft-State – Datenreplikation muss nicht unbedingt konsistent sein.
E - Eventual Consistency - Sobald ein Schreibvorgang abgeschlossen ist, werden die Schreibvorgänge von anderen Knoten eventuell abgeschlossen.
Datenbanken mit BASE-Konsistenz bevorzugen Verfügbarkeit gegenüber Datenkonsistenz und sind weniger streng als das ACID-Modell.
Beim Starken Konsistenz Modell ist die Datenkonsistenz das Allerwichtigste. Finanztransaktionen sind ein hervorragendes Beispiel dafür. Wenn Sie Geld auf Ihr Online-Banking-Konto einzahlen und dann zu Ihrer Zweigstelle fahren, möchten Sie an beiden Standorten den gleichen Kontostand sehen. Möglicherweise dauert es einige Minuten, bis sich die Daten über das Netzwerk replizieren und alle Rechner im Banksystem aktualisieren, jedoch ist die Genauigkeit der angezeigten Daten am wichtigsten. Hätte man in dem Fall das Eventuelle Konsistenz Modell verwendet, würde z.B. die mobile App einen anderen Kontostand aufweisen als in der Filiale und man würde sich verständlicherweise fragen woran die Unstimmigkeit liegt. Die Konsistenz wird durch eingeschränkte Lese- und Schreibvorgänge erreicht, während die verschiedenen Knoten die Datenbanken aktualisieren. Der Preis für die Datenkonsistenz ist eine hohe Latenz, aber in diesem Fall gibt es keine Alternative. Die Transaktionsdaten müssen korrekt sein.
Strukturierte (SQL) Datenbanken sind die beste Wahl für Anwendungen mit starker Konsistenz. Wenn eine Transaktion stattfindet, werden alle Netzwerkknoten gesperrt, bis die richtigen Daten dem Benutzer angezeigt werden. SQL-Datenbanken müssen die Anforderungen des ACID-Konsistenzmodells entsprechen.
Das Akronym ACID steht für
Atomic – die Transaktion besteht aus mehreren Vorgängen, und alle Transaktionen müssen erfolgreich sein.
Consistent – nachdem die Transaktion abgeschlossen ist, muss die Datenbank in einem konsistenten Zustand sein.
Isolation – mehrere Transaktionen können gleichzeitig stattfinden jedoch muss jede davon isoliert sein.
Durable – das Ergebnis der Transaktion ist dauerhaft.
Das ACID-Modell stellt sicher, dass die Daten konsistent sind und jederzeit korrekt angezeigt werden.
Die Eventuelle Konsistenz im Streaming
Die eventuelle Konsistenz funktioniert für verteilte Anwendungen, bei denen Verfügbarkeit oberste Priorität hat und Datenänderungen nicht auf allen Knoten konsistent angezeigt werden. Bei Datenstreams jedoch ist die Eventuelle Konsistenz kein bevorzugtes Modell, da sich der Datenfluss ständig ändert. Bei eventueller Konsistenz würde dies ungenaue Ergebnisse bedeuten, da die Daten inkonsistent sind und ständig aktualisiert werden müssen.
Für Ergebnisse mit geringer Latenz ist die Verwendung einer Streaming-Datenbank die bessere Wahl. Streaming-Datenbanken überprüfen häufig den Datenfluss und aktualisieren die Datenbankergebnisse, wenn sich diese Werte ändern. Da es sich bei Streaming-Datenbanken um relationale SQL-Tabellen handelt, ist eine die Starke Konsistenz in die Gleichung integriert, die konsistente und genaue Ergebnisse liefert, sobald sich die Daten ändern.
Fazit
Bei Datenkonsistenzmodellen, welche auf dem CAP-Theorem basieren, sollen noch beim Entwerfen von verteilten Anwendungen Konsistenz, Verfügbarkeit und Partitionstoleranz in Betracht gezogen werden. Entwickler müssen entscheiden, welches Modell zu ihrem Anwendungsfall passt. Starke Konsistenzmodelle erfordern, dass Benutzer Daten auf allen Netzwerkknoten konsistente abrufen können.
Eventuelle Konsistenzmodelle schlagen vor, dass Daten angezeigt werden, einige Knoten jedoch später geupdatet werden, solange alle Informationen schließlich aktualisiert werden. Entwickler müssen auch den Datenbanktyp berücksichtigen. SQL- oder relationale Datenbanken eignen sich gut für Modelle mit starker Konsistenz.
Nicht relationale (NoSQL) Datenbanken, die nicht strukturierte Daten verwalten, sind häufig eine gute Wahl für das Eventuelle Konsistenz Modell. Die eventuelle Konsistenz ist für das Streaming von Datenanwendungen nicht zu empfehlen. Da sich der Datenfluss ständig ändert, geben die NoSQL-Datenbanken einen konsistenten Fluss ungenauer Daten zurück. Das Streaming von SQL-Datenbanken kann eine starke Konsistenz mit genauen Ergebnissen und einer Verfügbarkeit mit geringer Latenz bieten.
