Datenbanken Online Lexikon TH Köln, Campus Gummersbach
Aktuelle Änderungen - Suchen:

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]

Bandbreite der Konsistenz von ACID bis BASE
Bandbreite der Konsistenz von ACID bis BASE

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).

ACID-Konsistenz mit Sperren und Wartezeiten
ACID-Konsistenz mit Sperren und Wartezeiten

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-Konsistenz ohne Sperren und ohne Wartezeiten
BASE-Konsistenz ohne Sperren und ohne Wartezeiten

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:

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