• Anzeigen
• Bearbeiten
• Versionen
• Druckansicht

BASE

Das Akronym BASE steht für Basically Available, Soft State, Eventually Consistent und findet in NoSQL-Systemen verbreitet Einsatz. Die geänderten Anforderungen an Anwendungen im Web2.0-Zeitalter sowie die Erkenntnisse des CAP-Theorems und der Notwendigkeit, Daten mit verteilten Datenbanksystemen zu verarbeiten, motivieren diesen neuen, optimistischen Konsistenzbegriff, der gänzlich ohne Sperren auskommt.

Sperren sind in mehrfacher Hinsicht problematisch:

• Sind zu ändernde Datensätze durch eine Transaktion gesperrt, so sind sie für die Dauer der Sperrung für andere Transaktionen nicht zugreifbar, womit unberechenbar lange Wartezeiten verbunden sein können.
• In verteilten Datenbanksystemen mit replizierten Daten,
  • verlängern sich die Zeitspannen der Sperrung für eine Transaktion zusätzlich noch um die Zeitspanne für die Replikation der Datenänderung auf die übrigen relevanten Datenbankserver.
  • ist schon die Übereinkunft über das Setzen einer Sperre äußerst aufwendig und fehleranfällig.
  • Sperren sind aufwendig, weil die übrigen Server über den Wunsch einer Sperrung informiert werden müssen. Die verschiedenen Server können diesen Wunsch zustimmen oder auch ablehnen. Stimmen sie im einfachsten Fall zu, so muss dies dem initiierenden Server mitteilt werden. Dieser wartet auf ausreichend viele zustimmende Antworten und setzt die Sperre und informiert anschließend wieder die übrigen Server über die gesetzten Sperren. Zu bedenken ist dabei, dass die gesamte Kommunikation per Nachrichten über das Netz geschickt werden müssen. Ein analoger Aufwand muss betrieben werden, wenn die Sperrung aufgehoben wird.

Technisch gelingt es, den konkurrierenden Zugriff auf Datensätze mittels des MVCC-Verfahrens (Multiversion Concurrency Control) auch ohne Sperren zu koordinieren.

Nach dem Verständnis von BASE wird die Konsistenz der Daten als ein Zustand betrachtet, der irgendwann erreicht wird. Das ist die Idee des Eventually Consistent. Es wird damit in Kauf genommen, dass bis zum Erreichen dieser Konsistenz, die Daten inkonsistent in der DB gespeichert sind. Im Kontext von NoSQL muss also darauf geachtet werden, dass der Begriff Konsistenz im richtigen Zusammenhang verwendet wird. Hier ist nicht die bei RDBMS bezeichnete Integrität von Daten gemeint, sondern allein die Korrektheit des Inhalts des abzuspeichernden Datensatzes. Aus diesem Grund ist auch der Bereich Konsistenz aus dem Transaktionskonzept ACID?, und damit das gesamte Prinzip, schwer auf NoSQL - DBS zu übertragen, denn dort wird mit "Consistency" (des Akronyms ACID?) eben die Integrität betrachtet. Vor allem im Kontext der Transaktionskonzepte ist die „sprachlich holprige Konstruktion“ [1] von "Consistency" (des Akronyms BASE) richtig einzuordnen, das im Übrigen weniger der Definition, als mehr des prägnanten Gegenbegriffs zu ACID? wegen entstanden ist. [vgl. 1] Dabei sind alle Datensemantiken, die nicht strikt ACID? entsprechen, BASE. [vgl. 2]

Auch wenn BASE und ACID? auf den ersten Blick sehr unterschiedliche, eigentlich schon gegensätzliche Positionen beschreiben, so sind sie doch eher als zwei Enden eines Konsistenzspektrums zu betrachten, wie die nebenstehende Abbildung "Bandbreite der Konsistenz von ACID bis BASE" zeigt. Der Übergang ist durchaus fließend. Es gibt Systeme, die sowohl ACID? wie auch BASE als Konsistenzmodell implementiert haben. Oder, wie die nachfolgend aufgelisteten Konsistenzmodelle noch zeigen werden, es gibt unterschiedlich Auffassungen von Konsistenz in BASE, die mehr oder weniger weit von ACID? entfernt sind.

Die Punkte kennzeichnen Formen der Implementierung der jeweiligen Konsistenzkonzepte. Auffällig ist, dass im relationalen ACID-Bereich? die schwarzen Punkte doch sehr nah beieinander liegen, sich die Implementierungen also sehr ähneln, während im NoSQL-Umfeld die Spannweite von sogenannten BASE-Implementierungen (gelbe Punkte) doch sehr stark variieren.

Die nun folgenden beiden Abbildungen visualisieren die Unterschiede bei den ACID?- und den BASE-Transaktionen. Solange wie bei Transaktion TransA nur lesend zugegriffen wird, sind auch beide Ansätze gleich unproblematisch hinsichtlich der Antwortzeiten (Availability des CAP-Theorems).

Die Abbildung "ACID-Konsistenz mit Sperren und Wartezeiten" zeigt die Wartezeiten bei den Transkationen TransC und TransD, die lesend auf die von Trans B gesperrten Daten zugreifen möchten, und erst nach Transaktionsende eine Antwort an den Anwender zurückliefern können. Und genau diese Zeitspanne wird sehr schnell vom Anwender als zu lang empfunden, so dass er den Anbieter wechselt und damit können die Zeiten als geschäftsgefährdend bezeichnet werden.

BASE-Ansätze gehen mit dem MVCC-Konzept ganz andere Wege. Wie die Abbildung "BASE-Konsistenz ohne Sperren und ohne Wartezeiten" bei der TransB zeigt, wird bei Datenänderungen eine neue Version dieses Datensatzes erzeugt. Solange diese neue Version noch nicht auf allen Datenbanksystemen repliziert ist, wird während dessen bei lesenden Transaktionen TransC, TransD auf den alten Zustand zugegriffen.

Bewertungsmerkmale für BASE-Konsistenzmodelle

Da die NoSQL-Systeme in der Regel von großen Unternehmen wie Amazon, Google, etc. zur Lösung eigener Probleme entwickelt wurden, bietet sich nun bei den verschiedenen NoSQL-Systemen eine entsprechende Bandbreite an BASE-Lösungen mit sehr verschieden starken Konsistenzeigenschaften an.

Vorab sei der Begriff der kausalen Abhängigkeit erklärt. Kausale Abhängigkeit meint, dass, wenn Prozess A den Wert X schreibt und anschließend Prozess B den Wert X liest und den Wert Y schreibt, dann ist Prozess B/Wert X kausal abhängig von Prozess A/Wert Y (gleichgültig, ob dem so ist). Es ist hier zulässige Schlussfolgerung: B benötigt also X, um Y zu berechnen.

• Causal Consistency
  ist bei Transaktionen in verteilten DB-Systemen gegeben, wenn auch bei sehr enger zeitlicher Nähe der Prozesse A und B auf allen replizierten Knoten sichergestellt ist, dass B den von A geschriebenen Wert X liest bevor Y geschrieben wird.
  Diese Eigenschaft ist in ihrer Strenge mit den ACID-Anforderungen? vergleichbar.
• Read-your-write Consistency
  stellt einen Spezialfall der Causal Consistency dar. Es ist sichergestellt, dass ein Prozess, der selbst einen Datensatz manipuliert hat, bei nachfolgenden Anfragen keine ältere Version liest, als die von ihm selbst geschriebene Version.
• Session Consistency
  meint, dass, solange eine Session existiert, die Read-Your-Write Consistency sichergestellt wird. Bei Prozessende können also alle Verwaltungsinformationen gelöscht werden. Damit stellt dies eine sehr umsetzungsorientierte Variante dar.
• Monotonic Read Consistency
  stellt sicher, dass, wenn ein Prozess einen Wert eines Datenbankobjekts gelesen hat, er bei jeder zeitlich nachfolgenden Leseoperation keine älteren Versionen dieses Objekts erhält.
• Monotonic Write Consistency
  Alle Schreiboperationen eines Prozesses werden garantiert serialisiert ausgeführt, d.h. in der Reihenfolge, wie sie der Prozess angestoßen hat. Dies stellt quasi eine Minimalanforderung dar, da sonst nichtdeterministische Ergebnisse bei den Anwendungen auftreten, die sehr schwierig zu handhaben sind.

Es obliegt der Verantwortung der Entwickler zu analysieren, zu bewerten und zu entscheiden, welche Merkmale für welche Anwendung notwendig bzw. sinnvoll sind. Diese Merkmale sind ein Entscheidungskriterium für oder gegen ein NoSQL-DBS. Wenn das NoSQL-DBS die geforderten Merkmale nicht bietet, dann obliegt es dem Entwicker, diese selbst in der Anwendung zu programmieren. Dies stellt für einen Entwickler, der bislang nur mit relationalen Systemen gearbeitet hat, einen dramatischen Perspektivwechsel dar.

Quellen:

• Edlich, Friedland, Hampe, Brauer: „NoSQL – Einstieg in die Welt der nichtrelationalen Web2.0- Anwendungen“, Hanser-Verlag, 2010, ISBN 978-3-446-42355-8
• [1] solidIT DB-Engines; 2013; Enzyklopädie Artikel BASE; http://db-engines.com/de/article/BASE, 24.06.13
• [2] Armando Fox, Steven D. Gribble, Yatin Chawathe, Eric A. Brewer, Paul Gauthier; 1997; Cluster-Based Scalable Network Services, BASE Semantics, Seite 3; http://www.cs.berkeley.edu/~brewer/cs262b/TACC.pdf

Weiterführende Literatur:

• Frey, M.: „Etablierte Datenmodelle der NoSQL-Familie und ihre spezifischen Eigenschaften im Kontext von Cloud-Datenbanken“, Bachelorarbeit, FH Köln, Institut für Informatik, 08/2010
• Kossmann, D., Kraska T.: „Data Management in the Cloud: Promises, State- of-the-art and Open Questions“, in „Datenbanken und Cloud-Computing“, Datenbank Spektrum, Band 10 Heft 3, Springer-Verlag, 12.2010, S. 121-129

Weiterführende Links:

• Edlich, St.: Your Ultimate Guide to the Non - Relational Universe!, Stand 23.03.2011

Kategorie: Neue DB-Entwicklungen , Grundlagen, NoSQL, B