In den letzten Jahren entstanden verschiedene Open-SourceSysteme, die mit fundamentalen Konzepten und Regeln relationaler Datenbanksysteme brachen, um die Verwaltung von Daten in speziellen Einsatzbereichen zu optimieren. Die wesentlichen Gru¨nde fu¨r die Entwicklung dieser so genannten NoSQL-Systeme sind jedoch nicht SQL oder das relationale Datenbankmodell, sondern sie ist auf die Implementierung relationaler Datenbanksysteme zuru¨ckzufu¨hren. Der Beitrag verdeutlicht durch eine Gegenu¨berstellung von Oracle Real Application Cluster, IBM DB2 PureScale und MySQL Cluster die gegensa¨tzlichen Implementierungen relationaler Clusterlo¨sungen. An die Motivation der NoSQL-Produkte sowie einen U¨ berblick ihrer Zielstellung, Vor- und Nachteile schließt sich das Aufzeigen von Mo¨glichkeiten an, um Konzepte und Implementierungen beider Welten miteinander zu verbinden und so die Vorzu¨ge zu vereinen.
H.2.4 [Database Management]: Systems—Parallel databases ; H.3.5 [Database Management]: Systems and Software—Distributed systems
1.
2.
Die Charakteristika zu verarbeitender Daten bei Web-Anwendungen fu¨hren zu folgenden Kern-Herausforderungen an zu verwendende Datenbanksysteme bzw. Datenspeicher.
Performance und Skalierbarkeit kennzeichnen die bedeutendsten Herausforderungen. Die damit verbundene Verringerung der Latenzzeit in Web-Anwendungen steht ha¨ufig in direktem Zusammenhang mit der Nutzerzufriedenheit und ist insbesondere in Bereichen wie Suchmaschinen oder dem E-Commerce-Sektor von essentieller Bedeutung. Die Performance resultiert aus der Grundperformance fu¨r Anfragen und der Verarbeitungsgeschwindigkeit fu¨r steigende Datenvolumina, welche allgemeinhin als Skalierbarkeit bezeichnet wird. Eine zunehmende Datenmenge kann hierbei die Dauer von Aufgaben, die Anzahl der Aufgaben oder beides erho¨hen. Die Skalierbarkeit eines Rechensystems kann durch den Einsatz leistungsfa¨higerer Hardware (vertikale Skalierbarkeit) oder durch das Verteilen der Aufgaben auf weitere Rechenressourcen (horizontale Skalierbarkeit) erzielt werden. Die Vorga¨nge mu¨ssen jeweils transparent zur Anwendung geschehen.
Ausfallsicherheit ist fu¨r jedes zentrale (Datenverarbeitungs-)System eine wesentliche Herausforderung, um Nutzern dauerhafte Verfu¨gbarkeit zu bieten. Neben ungeplanten Ausfa¨llen eines Systems in Folge von Hardwaredefekten oder Systemfehlern mu¨ssen auch geplante Ausfa¨lle – beispielsweise zur Aktualisierung des Systems – vermieden werden. Beide Ausfallarten ko¨nnen erheblichen wirtschaftlichem Schaden durch Kundenverlust oder Po¨nalen bei Verstoß gegen Service Level Agreements nach sich ziehen. Um Hochverfu¨gbarkeit zu erreichen, sollten Single Points of Failure (SPoF) in einem System vermieden sowie binnen kurzer Zeit und automatisiert auf jegliche Art von Fehlern reagiert werden.
Schemaflexibilit¨at bezeichnet den Verzicht auf ein vordefiniertes und stets omnipra¨sentes Datenbankschema, um den Umgang mit Datenbanken und -speichern flexibler zu gestalten. Dies ermo¨glicht die ada¨quate Verwaltung semistrukturierter und dokumenten-orientierter Daten, die nicht zuletzt aufgrund von Web-Standards und Auszeichnungssprachen wie XML oder RDF in Web-Anwendungen weit verbreitet sind. Schemaflexibilita¨t spielt des Weiteren eine wichtige Rolle bei der Konsolidierung von heterogenen Nutzerdaten innerhalb eines Systems.
Kosten: Fu¨r viele Betreiber von Web-Anwendungen ist der Einsatz kostengu¨nstiger Hard- und Software eine Grundvoraussetzung. Lizenz-, Support- und Administrationskosten fu¨r Datenbanksysteme sowie die Anschaffungs-, Administrations- und Betriebskosten von Datenbankservern machen meist einen nicht unerheblichen Teil der IT-Gesamtaufwendungen aus. Aus diesem Grund wird fu¨r Unternehmen die Nutzung von kostengu¨nstigen Cloud-Services oder -Storages stets lukrativer. Entsprechend sollte ein geeignetes Lizenzierungskonzept angeboten und der Einsatz auf Commodity-Servern unterstu¨tzt werden.
Fu¨r viele Provider ist die Antwortzeit der
Web-Anwendung derart wichtig, dass sie Einschra¨nkungen der
Datenkonsistenz in Kauf nehmen oder gar auf die Realisierbarkeit
des Definierens von Konsistenzsicherungen verzichten, wenn
diese einen Performance-Overhead mit sich bringen. Dies ist
bemerkenswert, denn es kennzeichnet einen wahrnehmbaren
Wandel der Anforderungen an Datenbanksysteme. In
klassischen Unternehmensanwendungen stellt die Forderung nach
Datenkonsistenz die oberste Pra¨misse dar und ist
unentbehrlich. Die Herausforderung besteht hierbei im Wesentlichen in
der Optimierung der Performance. Dementgegen
verdeutlichen die obigen Herausforderungen, dass die Hauptaufgaben
vermehrt in der Optimierung der Antwortzeit oder nach [
Abbildung 1: Architektur von Oracle RAC (nach
[
Horizontale Skalierbarkeit und Hochverfu¨gbarkeit unter Einsatz kostengu¨nstiger Hardware bilden nach Abschnitt 2 die wesentlichen Herausforderungen an die Speicherung und Verarbeitung der Daten von Web-Anwendungen. Beinahe alle relationalen Datenbanksysteme bieten Mittel, um ihre Systeme vor Ausfa¨llen und Datenverlust in diversen Fehlerszenarien zu schu¨tzen und eine hohe Verfu¨gbarkeit zu erzielen. Sie bieten fu¨r dieses Ziel neben Sicherungs- und Wiederherstellungsmo¨glichkeiten von Datenbanken verschiedene Techniken zur Replikation. Zumeist erkennen sie ein Problem jedoch erst beim erfolglosen Datenzugriff statt unmittelbar nach dem Auftreten und erfordern im Fehlerfall einen manuellen Eingriff zum Umleiten auf das Replikat. Zudem sind die Replikate bei einigen Systemen ausschließlich im Fehlerfall einsetzbar und dienen im Normalbetrieb nicht der Lastbalancierung. Im Folgenden werden die Eckpunkte vorherrschender Hochverfu¨gbarkeitslo¨sungen gegenu¨bergestellt, die diese Ma¨ngel nicht aufweisen und zudem horizontale Skalierbarkeit in Mehrrechnersystemen ermo¨glichen. 3.1
Oracle Real Application Cluster (RAC) ermo¨glicht bis zu
100 Datenbankinstanzen einen parallelen Zugriff auf
denselben Datenbestand und realisiert somit eine
Shared-DiskArchitektur. Wie Abbildung 1 verdeutlicht, greifen die
Application Server und Web Server u¨ber eine gemeinsame
Service-Schnittstelle auf das System zu, die u.a. der
Lastbalancierung dient. Sa¨mtliche Dateien fu¨r Daten, Verwaltung
und Konfigurationsparameter werden auf einem
clusterfa¨higen Storage-System gespeichert und sind von allen Servern
les- und schreibbar. Lediglich die Undo- und Redo-Logs
bilden eine Ausnahme: Sie werden stets von der Besitzerinstanz
geschrieben und ko¨nnen nur von deren Nachbarinstanzen
gelesen werden, um die Besitzerinstanz bei einem Ausfall
automatisch wiederherstellen zu ko¨nnen. Der Ausfall eines
Knotens wird durch eine Heartbeat-Netzwerkverbindung in
ku¨rzester Zeit erkannt. Extended Distance Cluster bietet durch
Abbildung 2: Architektur von IBM DB2 PureScale
(nach [
Oracle RAC bietet Skalierbarkeit durch das Hinzufu¨gen
neuer Nodes, einen automatischen Lastausgleich und die
parallelisierte Ausfu¨hrung von Operationen auf mehreren
Servern. Fu¨r den parallelen Zugriff mehrerer Instanzen auf
denselben Datenbestand nutzt Oracle im Falle einer
Datenmodifikation den Global Cache Service (GCS), um zu bestimmen,
in welchen lokalen Knotencaches die betroffenen Blo¨cke
liegen bzw. ob sie sich gegebenenfalls bereits auf dem
StorageSystem befinden. Nachdem die Position bekannt ist, werden
die Blo¨cke durch ein In-Memory-Blockinventar (Global
Resource Directory, GRD) und Global Enqueue Service auf
aktive Schreibsperren und weitere wartende Instanzen gepru¨ft,
um anschließend eigene Schreibsperren zu setzen, die
wiederum im GRD vermerkt und anderen Nodes bekannt gemacht
werden. Die verwendeten Komponenten werden unter dem
Begriff Cache Fusion zusammengefasst und ermo¨glichen
zudem beim Datenzugriff das direkte Versenden von Daten
zwischen Buffer-Caches verschiedener Nodes. Oracle RAC
vermeidet somit Cache-Koha¨renz und ein SPoF durch einen
globalen Cache, jedoch auf Kosten von sehr viel
Kommunikation.[
Das Design der IBM-Clusterlo¨sung DB2 pureScale basiert auf der Architektur des bewa¨hrten Parallel Sysplex fu¨r System z1. Sie ermo¨glicht durch eine Shared-Disk-Architektur den gemeinsamen Zugriff von bis zu 128 Datenbankservern auf einen gemeinsamen Datenbestand, der durch IBMs General Parallel File System zur Verfu¨gung gestellt wird. Die Abbildung 2 zeigt, dass der Cluster neben den Datenbankservern aus Cluster Facilities (CF) besteht. Um einen SPoF zu verhindern, ist diese Komponente meist doppelt ausgelegt. Sie kann ein eigensta¨ndiges System sein oder auf einem Clusterknoten betrieben werden. Die CF ermo¨glicht die zentrale Verwaltung der Sperren (Global Lock Table, GLT) und 1Auf eine gesonderte Beschreibung des Parallel Sysplex wird aufgrund analoger Konzepte verzichtet.
Abbildung 3: Architektur von MySQL Cluster (nach
[
Ein integrierter Watchdog-Prozess u¨berwacht permanent die Verfu¨gbarkeit sa¨mtlicher Knoten. Wird der Ausfall eines Knotens bemerkt, stehen bis zum Instanzneustart lediglich die momentan von diesem Knoten aktualisierten Tupel nicht zur Verfu¨gung. Logs werden im Gegensatz zu Oracle RAC auf den gemeinsamen Festspeicher geschrieben und sind fu¨r die Recovery von anderen Knoten lesbar. 3.3
MySQL Cluster basiert im Gegensatz zu den Lo¨sungen
von IBM und Oracle auf einer Shared-Nothing-Architektur,
weshalb die bis zu 255 Datenknoten nicht parallel auf einen
gemeinsamen Datenbestand zugreifen, sondern jeder
Datenknoten einen Teil des Gesamtdatenbestands verwaltet. Die
Tabellen werden bei diesem Ansatz horizontal partitioniert.
MySQL Cluster stellt keine spezifischen Voraussetzungen an
zu verwendende Netzwerke oder Server und unterstu¨tzt
InMemory- als auch Festpeicher-Datenspeicherung. Auf das
System wird u¨ber vollwertige MySQL-Server zugegriffen. Sie
sind mit einer Schnittstelle zur NDB-Engine versehen und
werden zudem fu¨r verschiedene Funktionen wie Views,
Trigger oder Volltext-Indizes verwendet, die von der
NDB-Engine nicht unterstu¨tzt werden. Die Management-Server sind
fu¨r die Konfiguration des Clusters zusta¨ndig, wa¨hrend die
Datenknoten zur Speicherung der Daten und der
Verwaltung von Transaktionen dienen. Knoten, die deckungsgleiche
Inhalte verwalten, werden zu einer Datenknotengruppe
zusammengefasst, in der die synchrone Replikation der Knoten
dazu fu¨hrt, dass der Ausfall von Knoten keine aufwa¨ndige
Instanz -Wiederherstellung nach sich zieht. Somit mu¨ssen
Undo- und Redo-Dateien anderen Knoten nicht sichtbar
gemacht werden und das System ist verfu¨gbar, solange ein
Datenknoten je Gruppe erreichbar ist. Da beim Ausfall eines
Knotens die Aktualisierung einer zentralen Sperr- und
Pufferverwaltung nicht no¨tig ist, ko¨nnen sehr geringe
FailoverZeiten erzielt werden. Zudem werden asynchron Checkpoints
auf einen Festspeicher geschrieben, um auf den Ausfall
kompletter Gruppen reagieren zu ko¨nnen bzw. einen
SystemReboot zu ermo¨glichen. Durch den Einsatz der MySQL
Cluster Carrier Grade Edition kann Hochverfu¨gbarkeit durch die
Realisierung geografischer Replikation erzielt werden.[
Die vorgestellten Datenbankcluster ermo¨glichen
Skalierbarkeit sowohl durch Einsatz leistungssta¨rkerer Server als
auch durch das Hinzufu¨gen weiterer Server. Trotz
verschiedener Realisierungen verfu¨gen sie u¨ber effiziente
Strategien fu¨r die wesentlichen Herausforderungen im Kontext der
Skalierbarkeit: Logging, Locking und die Verwaltung von
Zwischenspeichern[
Alle Systeme bieten hohe Ausfallsicherheit bis hin zu Unterstu¨tzung einer Disaster-Recovery u¨ber die Anbindung entfernter Standby-Systeme. Serverausfa¨lle werden beinahe unmittelbar erkannt, die Wiederherstellung ist in ku¨rzester Zeit mo¨glich und fu¨hrt kaum zu wenig Einschra¨nkungen. Wa¨hrend bei Oracle RAC im Fehlerfall bis zum Neuaufbau des CGS fu¨r einen Augenblick keine Datenmodifikation durchgefu¨hrt werden ko¨nnen, stehen bei DB2 PureScale die vom ausgefallenen Knoten aktuell vera¨nderten Daten bis zur InstanzWiederherstellung nicht zur Verfu¨gung. MySQL Cluster besitzt durch den Shared-Nothing-Ansatz in Verbindung mit synchroner Replikation der In-Memory-Daten im Fehlerfall kaum Einschra¨nkungen.
Die wesentlichen Nachteile von Oracle RAC und DB2 pureScale bestehen im Kontext der Anforderungen in Abschnitt 2 vor allem in den enormen Kosten fu¨r Lizenzen, spezielle Hardware und Wartung im Vergleich zu MySQL Cluster. Insbesondere sind hier der vor Ausfa¨llen zu schu¨tzende Shared Storage, das Cluster-Dateisystem sowie leistungsstarke Netzwerke fu¨r die Clusterkommunikation und Cache Fusion bzw. die Cluster Acceleration Facilities zu nennen. Oracle RAC wurde zudem in den vergangenen Jahren um diverse Features erga¨nzt, die zu einer System-Komplexita¨t fu¨hrten, die eine intensive Einarbeitungszeit unabdingbar macht.
Ein wesentlicher Vorteile von Oracle RAC und DB2 pureScale ist hingegen die einfache Migration von Anwendungen auf die Clustersysteme, da keine A¨ nderung des Anwendungscodes notwendig ist. Da die NDB-Engine von MySQL Cluster nur einen Teil der Funktionen von InnoDB und MyISAM unterstu¨tzt, mu¨ssen fehlende Funktionalita¨ten auf die MySQL-Server ausgelagert werden, um deren Performance und Verfu¨gbarkeit manuell gesorgt werden muss. Daher bietet sich der MySQL Cluster vor allem in Szenarien mit einer Vielzahl simpler Anfragen und hohen Latenz- und Verfu¨gbarkeitsanforderungen an, wa¨hrend die Einsatzmo¨glichkeiten von Oracle RAC und DB2 pureScale kaum begrenzt sind. 4.
In den letzten Jahren gewinnen so genannte NoSQL-Systeme zur Verwaltung von Daten zunehmend an Bedeutung. Einige Kritikpunkte bei der Verwendung relationaler (Cluster-)Systeme in der Welt der Services regten Unternehmen zur Eigenentwicklung von Systemen zur Datenspeicherung und -verarbeitung an, die bewusst auf Merkmale relationaler DBMS verzichten, um sich auf einen Anwendungsfall zu spezialisieren. Ausgehend von den technischen Beschreibungen von Systemen bekannter Internetgro¨ßen entstanden im Laufe der letzten Jahre eine Vielzahl von Open-SourceSystemen. Diese kopierten, kombinierten und erweiterten die Konzepte der Ausgangssysteme mit dem Ziel, den Anforderungen der Unternehmen gerecht zu werden. Der Begriff ”tcNehmeorSewQbeLies“setueahmlstfa”imNssotAtauollfnzjleeyingSeeQnSyLv“sotneamuAseglteuelnrendgatw.tiDivredansinzZuziewrliesdlcaihetseioenrnu¨aSblyelsni-Datenbanksystemen und nicht in deren Ablo¨sung. 4.1
Mangels einer anerkannten Definition des Begriffs ”NoSQL“ werden im Folgenden entsprechend der in Abschnitt 2 beschriebenen Herausforderungen die wesentlichen Zielstellungen der NoSQL-Systeme zusammengefasst, wobei diese als Obermenge der Ziele jedes einzelnen NoSQL-Systems zu sehen sind.
Performance, Skalierbarkeit: Untersuchungen wie [
• Consistency: Zu jedem Zeitpunkt sehen alle Knoten denselben Datenbestand. • Availability: Knoten ko¨nnen Datenbesta¨nde jederzeit schreiben und lesen. • Partition tolerance: Das System arbeitet trotz einer
Zerteilung in Teilsysteme weiter.
Wa¨hrend relationale Datenbanksysteme stets auf die Wahrung der Konsistenz bestehen und dies zur Beeintra¨chtigung der Performance und Skalierbarkeit nach sich zieht, verfolgen viele NoSQL-Systeme den im Abschnitt 2 aufgefassten Ansatz, strenge Konsistenzforderungen zugunsten der Performance aufzugeben.
Ausfallsicherheit: Ein Großteil der NoSQL-Systeme bietet hervorragende Replikations- und Failovertechniken, um Ausfa¨lle von Knoten innerhalb einer Shared-Nothing-Architektur zu kompensieren, indem das System vor Datenverlust geschu¨tzt und der laufende Betrieb minimal beeinflusst wird.
Schemaflexibilit¨at: NoSQL-Systeme verdeutlichen, dass
neben dem relationalen Datenbankmodell andere
Datenmodelle existieren, die Daten gema¨ß ihrer Eigenschaften
ad¨aquat speichern, ohne sie in ein fixes Datenbankschema zu
fu¨gen. Fu¨r einfache, schemafreie Daten bieten
Key-ValueStores die Mo¨glichkeit, mehrattribute Objekte anhand eines
eindeutigen Schlu¨ssels zu speichern und abzufragen.
Dokumenten-basierte Systeme erlauben zudem das Speichern
komplexerer Inhalte wie verschachtelte Daten und bieten durch
leistungsfa¨higere Abfragesprache beispielsweise das Suchen
auf beliebigen Attributen. Wide-Column-Stores vereinen
hingegen Vorzu¨ge des Relationenmodells mit Funktionalita¨ten
wie flexiblen Schemata und Versionierung. Diese
Datenmodelle werden beispielweise durch die Graphen-DBS erga¨nzt.
Die Komplexita¨t des Datenmodells spiegelt sich meist in der
zur Verfu¨gung gestellten Programmierschnittstelle bzw.
Abfragesprache wieder, es existieren fu¨r die Datenmodelle kaum
standardisierte Notationen und standardisierte, deskriptive
Sprachen. Entsprechend ihrer Zielstellung bieten sie ha¨ufig
auf REST basierende Schnittstellen.[
Kosten: Das Gros der Systeme wird als Open Source und mit wenigen Nutzungseinschra¨nkungen zur Verfu¨gung gestellt. Die Installation und Verwendung der Systeme ist meist unkompliziert. Zudem ist ha¨ufig ein Betrieb auf gu¨nstigen Commodity Servern mo¨glich, da Einschra¨nkungen bezu¨glich der zu verwendenen Hardware kaum vorhanden sind und gela¨ufige Betriebssysteme unterstu¨tzt werden. 4.2
NoSQL-Datenspeicher sind hervorragend geeignet, um kostengu¨nstig skalierbare und hochverfu¨gbare Datenspeicherung und -verarbeitung in einem begrenzten Anwendungsfall bereitzustellen. Aus Sicht dieser Systeme sind die gro¨ßten Hu¨rden beim Einsatz relationaler Systeme fu¨r Web-Applikationen nicht das relationale Datenbankmodell, ACID oder gar SQL. So zeigen aktuelle Entwicklungen im Bereich relationaler Datenbanksysteme wie VoltDB2 oder HyPer3, dass diese Merkmale eine lineare Skalierbarkeit nicht zwingendermaßen ausschließen. Im Zentrum der Beanstandungen stehen hingegen die Tatsachen, dass keine bewa¨hrten parallelen und hochverfu¨gbaren Open Source RDBMS existieren und die Implementierung bewa¨hrter relationaler DBMS ha¨ufig keine hinreichende Skalierbarkeit zula¨sst.
Die Spezialisierung der NoSQL-Systeme auf eine wenige
Anwendungsgebiet verwehrt in vielen Fa¨llen den Einsatz
bei sich a¨ndernden Anforderungen, wie beispielsweise dem
Wunsch komplexer Abfragen auf Daten bei simplen
Datenmodellen. Bei der Nutzung eines relationalen DBMS wa¨ren
hierbei kaum A¨ nderungen vonno¨ten, wa¨hrend ein
NoSQLSystem angepasst oder gar ausgetauscht werden muss. Ein
Austausch gestaltet sich zudem schwierig, da es den
Systemen an standardisierten Notationen und Schnittstellen
mangelt. Zudem werden statt deskriptiven Sprachen je nach
Datenmodell meist Low-Level-Abfragesprachen verschiedenen
2http://voltdb.com/
3http://www3.in.tum.de/research/projects/HyPer/
Komplexita¨ts- und Ma¨chtigkeitsgrades genutzt, was aus Sicht
des Programmierers ein Fortschritt, aus Sicht eines
Datenba¨nklers aber durchaus als Ru¨ckschritt gesehen werden kann
[
Relationale Datenbanksysteme bieten aufgrund jahrelanger Forschung und Entwicklung u.a. eine enorme Verbreitung und Bekanntheit, ein ausgereiftes mathematisches Fundament, die Datenbanksprache SQL und nicht zuletzt zugesicherte Transaktionseigenschaften durch ACID. Auf der anderen Seite existieren NoSQL-Systeme, deren Verbreitung sich in der Regel auf wenige Web-Anwendungen beschra¨nkt. Charakterisiert durch die in Abschnitt 4 zusammengefasste Eigenschaften sowie die verwendeten Konzepte, weisen sie zum Teil Zielstellungen auf, die sich deutlich von der Zielstellung klassischer relationaler Datenbanksysteme unterscheidet.
Eine Verbindung von Konzepten und Implementierungen relationaler Datenbanksysteme und NoSQL Data Stores kann dazu genutzt werden, die Vorteile beider Welten zu vereinen. Im Folgenden werden mo¨gliche Ansa¨tze zur Vereinigung anhand stellvertrender Beispiele vorgestellt. 5.1
NoSQL-Systeme wurden in der Regel fu¨r ein spezielles
Anwendungsgebiet entwickelt. Durch eine Erweiterung der
Systeme kann ihr Einsatzbereich vergro¨ßert werden, wodurch sie
die Aufmerksamkeit von mehr Unternehmen auf sich ziehen
ko¨nnen. Somit wird neben der Erweiterung der
Funktionalita¨t auch die Bekanntheit des Produkts gesteigert. Ein
Beispiel fu¨r diesen Ansatz ist das Produkt Hive[
Hybride Systeme wie HadoopDB[
Der Abschnitt 4 verdeutlicht, dass die bewa¨hrten
fundamentalen Konzepte hinter dem relationalen
Datenbankmodell mit Anforderungen wie enormer Skalierbarkeit vereinbar
sind, es hierzu jedoch einer Anpassung der von System R
abstammenden Architektur bedarf. Die Implementierungen
von DBMS mu¨ssen sich durch geeignete
Konfigurationsmo¨glichkeiten weit mehr als bisher an verschiedene
Einsatzzwecke anpassen lassen. Realisiert werden kann dies
beispielsweise durch die Ausnutzung der Austauschbarkeit von
Komponenten in modularen DBMS-Architekturen wie [
Ein mo¨glicher Ansatzpunkt dieses Konzepts ko¨nnte das Anbieten einer wahlweisen Speicherung auf langsamen, persistenten Festspeichern oder im schnellen, flu¨chtigen Arbeitsspeicher oder einer kombinierten Lo¨sung sein, was bereits in einigen Systemen wie dem in Abschnitt 3.3 beschriebenen MySQL Cluster mo¨glich ist. Hierdurch bieten sich entsprechend der Charakteristika und des Umfang der zu speichernden Daten sowie den Zugriffseigenschaften verschiedene Einsatzmo¨glichkeiten. Orthogonal kann wahlweise eine spaltenoder zeilenbasierte Speicherung angeboten werden, um sowohl im OLTP- als auch im OLAP-Bereich u¨berzeugende Leistungskennzahlen zu erzielen. Fu¨r die Implementierung bieten einige Systeme bereits verschiedene Storage-Engines innerhalb eines Systems.
Auch die Transaktionsverwaltung relationaler
Datenbanksysteme bietet sich bezu¨glich einer Erweiterung an, indem
neben den harten Anforderungen von ACID und den heute
wa¨hlbaren Isolationsszenarien weitere
Transaktionskonzepte mit schwa¨cheren Anforderungen integriert werden und
Administratoren die Wahl des Transaktionskonzepts
u¨berlassen wird. Aus Sicht des in Abschnitt 4 angesprochenen
CAP-Theorems ko¨nnten je nach Konfiguration des Systems
verschiedene CAP-Eigenschaften erfu¨llt werden und somit
das Datenbanksystem an verschiedene Einsatzzwecke
angepasst werden. Die Realisierung kann beispielsweise u¨ber ein
autonomes Modul zur Transaktionsverwaltung in einer
modularen DBMS-Architektur gema¨ß [
In diesem Beitrag wurde die Notwendigkeit adaptierbarer flexibler RDBMS-Implementierungen aufgezeigt. Als Grundlage diente der Vergleich von Oracle RAC, IBM DB2 PureScale und MySQL Cluster. Er verdeutlichte, dass die Hersteller zum Erreichen des Ziels eines horizontal skalierbaren und hochverfu¨gbaren Clusterdatenbanksystems gema¨ß verschiedener Implementierungsansa¨tze verfahren. Wa¨hrend Oracle RAC und IBM DB2 PureScale sich durch gute Lastbalancierung, effizientes Logging, Locking und Caching sowie einfache Migration von Anwendungen auf die Clustersysteme hervorheben, ist MySQL Cluster vor allem durch geringe Anspru¨che bezu¨glich der verwendeten Hardware und unkomplizierte Fehlerbehandlung aufgrund der Shared-Nothing-Architektur gekennzeichnet.
NoSQL Data Stores stellen vermehrt eine Alternative zu RDBMS dar, die Systeme sind jedoch meist auf den Einsatz in wenigen Anwendungsgebieten limitiert. Zudem mangelt es ihnen an Standardisierung und vor allem die Low-LevelAbfragesprachen sind aus Sicht der Datenbankforschung als Ru¨ckschritt zu werten.
Durch die Verknu¨pfung bewa¨hrter Konzepte und Implementierungen der RDBMS mit Ansa¨tzen der NoSQL-Bewegung ko¨nnen Vorteile beider Welten vereint werden. Die Erweiterung eines NoSQL-Systems fu¨hrt nicht nur zu zusa¨tzlichen Funktionalita¨ten, sondern steigert zudem die Bekanntheit und ero¨ffnet neue Einsatzbereiche. Eine weitere Mo¨glichkeit stellt eine Kombination von RDBMS- und NoSQLImplementierungen in Form eines hybriden Systems dar, wovon bereits wenige Beispiele existieren. Als Mittel der Wahl zur Vereinigung von Konzepten relationaler Datenbanksysteme und NoSQL-Systeme zeichnen sich jedoch aus Sicht des Autors flexible RDBMS-Implementierungen ab, die sich gezielter als in aktuellen Systemen an verschiedene Einsatzzwecke anpassen lassen. Als mo¨gliche Ansatzpunkte wurden die Implementierung verschiedener Storage-Engines und weiterer Transaktionskonzepte vorgeschlagen.