=Paper=
{{Paper
|id=None
|storemode=property
|title=Verbindung relationaler Datenbanksysteme und NoSQL-Produkte
|pdfUrl=https://ceur-ws.org/Vol-733/paper_goebel.pdf
|volume=Vol-733
|dblpUrl=https://dblp.org/rec/conf/gvd/Gobel11
}}
==Verbindung relationaler Datenbanksysteme und NoSQL-Produkte==
https://ceur-ws.org/Vol-733/paper_goebel.pdf
Verbindung relationaler Datenbanksysteme und
NoSQL-Produkte
Ein Überblick
Andreas Göbel
Friedrich-Schiller Universität Jena
Lehrstuhl für Datenbanken und Informationssysteme
Ernst-Abbe-Platz 2
07743 Jena, Germany
andreas.goebel@uni-jena.de
KURZFASSUNG 1. EINLEITUNG
In den letzten Jahren entstanden verschiedene Open-Source- Die zunehmende Verbreitung von Unternehmensnetzwer-
Systeme, die mit fundamentalen Konzepten und Regeln rela- ken, globalen Netzwerken wie dem Internet und mobilen
tionaler Datenbanksysteme brachen, um die Verwaltung von Endgeräten gepaart mit dem Wunsch vieler Unternehmen
Daten in speziellen Einsatzbereichen zu optimieren. Die we- nach Globalisierung führt vermehrt zur Nutzung zentraler
sentlichen Gründe für die Entwicklung dieser so genannten (Datenbank-)Services für eine Vielzahl von Nutzern. Die un-
NoSQL-Systeme sind jedoch nicht SQL oder das relationale ter dem Begriff Web 2.0 zusammengefassten Entwicklungen
Datenbankmodell, sondern sie ist auf die Implementierung ermöglichen zunehmend Interaktion und Verknüpfungen in
relationaler Datenbanksysteme zurückzuführen. Der Beitrag Netzwerken, was sowohl die Gestalt als auch die Menge der
verdeutlicht durch eine Gegenüberstellung von Oracle Re- Daten auffallend beeinträchtigt. So werden Inhaber erfolg-
al Application Cluster, IBM DB2 PureScale und MySQL reicher Web-Anwendungen mit beachtlichen Datenmengen
Cluster die gegensätzlichen Implementierungen relationaler konfrontiert, die das Datenaufkommen in klassischen Anwen-
Clusterlösungen. An die Motivation der NoSQL-Produkte dungen um ein Vielfaches übersteigen können.
sowie einen Überblick ihrer Zielstellung, Vor- und Nachteile Relationale Datenbanksysteme sind zentraler Bestandteil
schließt sich das Aufzeigen von Möglichkeiten an, um Kon- des Software-Stacks vieler Unternehmen und Behörden. Mit-
zepte und Implementierungen beider Welten miteinander zu tels der Verbindung eines mathematischen Fundaments, der
verbinden und so die Vorzüge zu vereinen. Gewährleistung der ACID-Eigenschaften und der standardi-
sierten deskriptiven Abfragesprache SQL stellen sie die Ver-
fügbarkeit, Korrektheit und Auswertbarkeit der Unterneh-
Kategorien und Themenbeschreibung mensdaten sicher. Der vorliegende Beitrag motiviert, warum
H.2.4 [Database Management]: Systems—Parallel data- Betreiber vieler Web-Anwendungen trotz der auf der Hand
bases ; H.3.5 [Database Management]: Systems and Soft- liegenden Vorteile bewährter relationaler Produkte Eigenent-
ware—Distributed systems wicklungen propietärer Spezialsysteme zur Datenverwaltung
vorantreiben, die bewusst auf wesentliche Merkmale relatio-
naler Systeme verzichten.
Allgemeine Bestimmungen Nach einer Gegenüberstellung relevanter Implementierung
Theory, Design, Reliability relationaler Clusterdatenbanken werden die Herausforderun-
gen und Einschränkungen der zu dem Schlagwort NoSQL zu-
sammengefassten Systeme herausgearbeitet, einige aktuelle
Stichworte Entwicklungen zur Verbindungen von NoSQL und RDBMS
Parallel Databases, NoSQL, Postrelational, Hybrid zusammengefasst und die Notwendigkeit flexiblerer Imple-
mentierungen relationaler Datenbanksysteme aufgezeigt.
2. HERAUSFORDERUNGEN
Die Charakteristika zu verarbeitender Daten bei Web-An-
wendungen führen zu folgenden Kern-Herausforderungen an
zu verwendende Datenbanksysteme bzw. Datenspeicher.
Performance und Skalierbarkeit kennzeichnen die be-
deutendsten Herausforderungen. Die damit verbundene Ver-
ringerung der Latenzzeit in Web-Anwendungen steht häu-
fig in direktem Zusammenhang mit der Nutzerzufriedenheit
und ist insbesondere in Bereichen wie Suchmaschinen oder
23rd GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 31.05.2011 - 03.06.2011, Obergurgl, Austria. dem E-Commerce-Sektor von essentieller Bedeutung. Die
Copyright is held by the author/owner(s). Performance resultiert aus der Grundperformance für Anfra-
31
gen und der Verarbeitungsgeschwindigkeit für steigende Da-
tenvolumina, welche allgemeinhin als Skalierbarkeit bezeich-
net wird. Eine zunehmende Datenmenge kann hierbei die
Dauer von Aufgaben, die Anzahl der Aufgaben oder beides
erhöhen. Die Skalierbarkeit eines Rechensystems kann durch
den Einsatz leistungsfähigerer Hardware (vertikale Skalier-
barkeit) oder durch das Verteilen der Aufgaben auf weitere
Rechenressourcen (horizontale Skalierbarkeit) erzielt werden.
Die Vorgänge müssen jeweils transparent zur Anwendung ge-
schehen.
Ausfallsicherheit ist für jedes zentrale (Datenverarbei-
tungs-)System eine wesentliche Herausforderung, um Nut-
zern dauerhafte Verfügbarkeit zu bieten. Neben ungeplanten
Ausfällen eines Systems in Folge von Hardwaredefekten oder
Systemfehlern müssen auch geplante Ausfälle – beispielswei-
se zur Aktualisierung des Systems – vermieden werden. Bei-
de Ausfallarten können erheblichen wirtschaftlichem Scha-
den durch Kundenverlust oder Pönalen bei Verstoß gegen
Service Level Agreements nach sich ziehen. Um Hochverfüg-
barkeit zu erreichen, sollten Single Points of Failure (SPoF)
Abbildung 1: Architektur von Oracle RAC (nach
in einem System vermieden sowie binnen kurzer Zeit und
[12])
automatisiert auf jegliche Art von Fehlern reagiert werden.
Schemaflexibilität bezeichnet den Verzicht auf ein vor-
definiertes und stets omnipräsentes Datenbankschema, um 3. RELATIONALE DATENBANKCLUSTER
den Umgang mit Datenbanken und -speichern flexibler zu Horizontale Skalierbarkeit und Hochverfügbarkeit unter
gestalten. Dies ermöglicht die adäquate Verwaltung semi- Einsatz kostengünstiger Hardware bilden nach Abschnitt 2
strukturierter und dokumenten-orientierter Daten, die nicht die wesentlichen Herausforderungen an die Speicherung und
zuletzt aufgrund von Web-Standards und Auszeichnungs- Verarbeitung der Daten von Web-Anwendungen. Beinahe al-
sprachen wie XML oder RDF in Web-Anwendungen weit le relationalen Datenbanksysteme bieten Mittel, um ihre Sys-
verbreitet sind. Schemaflexibilität spielt des Weiteren eine teme vor Ausfällen und Datenverlust in diversen Fehlersze-
wichtige Rolle bei der Konsolidierung von heterogenen Nut- narien zu schützen und eine hohe Verfügbarkeit zu erzielen.
zerdaten innerhalb eines Systems. Sie bieten für dieses Ziel neben Sicherungs- und Wiederher-
stellungsmöglichkeiten von Datenbanken verschiedene Tech-
Kosten: Für viele Betreiber von Web-Anwendungen ist niken zur Replikation. Zumeist erkennen sie ein Problem je-
der Einsatz kostengünstiger Hard- und Software eine Grund- doch erst beim erfolglosen Datenzugriff statt unmittelbar
voraussetzung. Lizenz-, Support- und Administrationskos- nach dem Auftreten und erfordern im Fehlerfall einen ma-
ten für Datenbanksysteme sowie die Anschaffungs-, Admi- nuellen Eingriff zum Umleiten auf das Replikat. Zudem sind
nistrations- und Betriebskosten von Datenbankservern ma- die Replikate bei einigen Systemen ausschließlich im Fehler-
chen meist einen nicht unerheblichen Teil der IT-Gesamt- fall einsetzbar und dienen im Normalbetrieb nicht der Last-
aufwendungen aus. Aus diesem Grund wird für Unterneh- balancierung. Im Folgenden werden die Eckpunkte vorherr-
men die Nutzung von kostengünstigen Cloud-Services oder schender Hochverfügbarkeitslösungen gegenübergestellt, die
-Storages stets lukrativer. Entsprechend sollte ein geeignetes diese Mängel nicht aufweisen und zudem horizontale Skalier-
Lizenzierungskonzept angeboten und der Einsatz auf Com- barkeit in Mehrrechnersystemen ermöglichen.
modity-Servern unterstützt werden.
3.1 Oracle Real Application Cluster
Für viele Provider ist die Antwortzeit der Web-Anwen-
Oracle Real Application Cluster (RAC) ermöglicht bis zu
dung derart wichtig, dass sie Einschränkungen der Daten-
100 Datenbankinstanzen einen parallelen Zugriff auf den-
konsistenz in Kauf nehmen oder gar auf die Realisierbarkeit
selben Datenbestand und realisiert somit eine Shared-Disk-
des Definierens von Konsistenzsicherungen verzichten, wenn
Architektur. Wie Abbildung 1 verdeutlicht, greifen die Ap-
diese einen Performance-Overhead mit sich bringen. Dies ist
plication Server und Web Server über eine gemeinsame Ser-
bemerkenswert, denn es kennzeichnet einen wahrnehmbaren
vice-Schnittstelle auf das System zu, die u.a. der Lastba-
Wandel der Anforderungen an Datenbanksysteme. In klassi-
lancierung dient. Sämtliche Dateien für Daten, Verwaltung
schen Unternehmensanwendungen stellt die Forderung nach
und Konfigurationsparameter werden auf einem clusterfähi-
Datenkonsistenz die oberste Prämisse dar und ist unentbehr-
gen Storage-System gespeichert und sind von allen Servern
lich. Die Herausforderung besteht hierbei im Wesentlichen in
les- und schreibbar. Lediglich die Undo- und Redo-Logs bil-
der Optimierung der Performance. Dementgegen verdeutli-
den eine Ausnahme: Sie werden stets von der Besitzerinstanz
chen die obigen Herausforderungen, dass die Hauptaufgaben
geschrieben und können nur von deren Nachbarinstanzen ge-
vermehrt in der Optimierung der Antwortzeit oder nach [3]
lesen werden, um die Besitzerinstanz bei einem Ausfall auto-
gar in der Minimierung der (Hardware-)Kosten und Erhö-
matisch wiederherstellen zu können. Der Ausfall eines Kno-
hung des Konsistenzniveaus bei gegebenen Performance-Vor-
tens wird durch eine Heartbeat-Netzwerkverbindung in kür-
gaben zu sehen ist.
zester Zeit erkannt. Extended Distance Cluster bietet durch
32
Abbildung 2: Architektur von IBM DB2 PureScale
(nach [9])
eine Systemspiegelung auf ein aktives System innerhalb we-
niger Kilometer das Reagieren auf Fehlerszenarien, die zum Abbildung 3: Architektur von MySQL Cluster (nach
Ausfall des kompletten Clusters führen. Oracle Data Guard [10])
ermöglicht darüber hinaus das Spiegeln auf ein weiter ent-
ferntes Standby-System zur Realisierung einer Disaster Re-
covery.[12, 5] des Caches (Group Buffer Pool, GBP), wodurch analog zum
Oracle RAC bietet Skalierbarkeit durch das Hinzufügen GRD und GCS des Oracle RAC die Informationen der Da-
neuer Nodes, einen automatischen Lastausgleich und die pa- tenblöcke verwaltet und allen Servern zur Verfügung gestellt
rallelisierte Ausführung von Operationen auf mehreren Ser- werden. Die Server sind untereinander sowie mit der CF mit-
vern. Für den parallelen Zugriff mehrerer Instanzen auf den- tels eines Hochleistungsnetzwerks verbunden, welches einen
selben Datenbestand nutzt Oracle im Falle einer Datenmodi- direkten Fernzugriff auf den Arbeitsspeicher (RDMA) in we-
fikation den Global Cache Service (GCS), um zu bestimmen, nigen Mikrosekunden ermöglicht. Bei einem Schreibvorgang
in welchen lokalen Knotencaches die betroffenen Blöcke lie- ermöglicht diese schnelle Verbindung das synchrone Aktua-
gen bzw. ob sie sich gegebenenfalls bereits auf dem Storage- lisieren der zentralen Sperrtabelle in Form von Zeilen- und
System befinden. Nachdem die Position bekannt ist, werden Seitensperren und des zentralen wie auch anderer relevanter
die Blöcke durch ein In-Memory-Blockinventar (Global Re- Caches. Beim Lesevorgang eines Nodes wird nach erfolgloser
source Directory, GRD) und Global Enqueue Service auf ak- Suche im lokalen Cache im GBP nach den Blöcken gesucht.
tive Schreibsperren und weitere wartende Instanzen geprüft, Werden die Daten vom Festspeicher in den lokalen Cache
um anschließend eigene Schreibsperren zu setzen, die wieder- geladen, wird dies ebenfalls dem GBP bekannt gemacht. [9,
um im GRD vermerkt und anderen Nodes bekannt gemacht 6]
werden. Die verwendeten Komponenten werden unter dem Ein integrierter Watchdog-Prozess überwacht permanent
Begriff Cache Fusion zusammengefasst und ermöglichen zu- die Verfügbarkeit sämtlicher Knoten. Wird der Ausfall eines
dem beim Datenzugriff das direkte Versenden von Daten Knotens bemerkt, stehen bis zum Instanzneustart lediglich
zwischen Buffer-Caches verschiedener Nodes. Oracle RAC die momentan von diesem Knoten aktualisierten Tupel nicht
vermeidet somit Cache-Kohärenz und ein SPoF durch einen zur Verfügung. Logs werden im Gegensatz zu Oracle RAC
globalen Cache, jedoch auf Kosten von sehr viel Kommuni- auf den gemeinsamen Festspeicher geschrieben und sind für
kation.[12, 5] die Recovery von anderen Knoten lesbar.
3.2 IBM DB2 PureScale 3.3 MySQL Cluster
MySQL Cluster basiert im Gegensatz zu den Lösungen
Das Design der IBM-Clusterlösung DB2 pureScale basiert
von IBM und Oracle auf einer Shared-Nothing-Architektur,
auf der Architektur des bewährten Parallel Sysplex für Sys-
weshalb die bis zu 255 Datenknoten nicht parallel auf einen
tem z1 . Sie ermöglicht durch eine Shared-Disk-Architektur
gemeinsamen Datenbestand zugreifen, sondern jeder Daten-
den gemeinsamen Zugriff von bis zu 128 Datenbankservern
knoten einen Teil des Gesamtdatenbestands verwaltet. Die
auf einen gemeinsamen Datenbestand, der durch IBMs Ge-
Tabellen werden bei diesem Ansatz horizontal partitioniert.
neral Parallel File System zur Verfügung gestellt wird. Die
MySQL Cluster stellt keine spezifischen Voraussetzungen an
Abbildung 2 zeigt, dass der Cluster neben den Datenbank-
zu verwendende Netzwerke oder Server und unterstützt In-
servern aus Cluster Facilities (CF) besteht. Um einen SPoF
Memory- als auch Festpeicher-Datenspeicherung. Auf das
zu verhindern, ist diese Komponente meist doppelt ausge-
System wird über vollwertige MySQL-Server zugegriffen. Sie
legt. Sie kann ein eigenständiges System sein oder auf einem
sind mit einer Schnittstelle zur NDB-Engine versehen und
Clusterknoten betrieben werden. Die CF ermöglicht die zen-
werden zudem für verschiedene Funktionen wie Views, Trig-
trale Verwaltung der Sperren (Global Lock Table, GLT) und
ger oder Volltext-Indizes verwendet, die von der NDB-En-
1
Auf eine gesonderte Beschreibung des Parallel Sysplex wird gine nicht unterstützt werden. Die Management-Server sind
aufgrund analoger Konzepte verzichtet. für die Konfiguration des Clusters zuständig, während die
33
Datenknoten zur Speicherung der Daten und der Verwal- MySQL-Server ausgelagert werden, um deren Performance
tung von Transaktionen dienen. Knoten, die deckungsgleiche und Verfügbarkeit manuell gesorgt werden muss. Daher bie-
Inhalte verwalten, werden zu einer Datenknotengruppe zu- tet sich der MySQL Cluster vor allem in Szenarien mit ei-
sammengefasst, in der die synchrone Replikation der Knoten ner Vielzahl simpler Anfragen und hohen Latenz- und Ver-
dazu führt, dass der Ausfall von Knoten keine aufwändige fügbarkeitsanforderungen an, während die Einsatzmöglich-
Instanz -Wiederherstellung nach sich zieht. Somit müssen keiten von Oracle RAC und DB2 pureScale kaum begrenzt
Undo- und Redo-Dateien anderen Knoten nicht sichtbar ge- sind.
macht werden und das System ist verfügbar, solange ein Da-
tenknoten je Gruppe erreichbar ist. Da beim Ausfall eines 4. NOSQL-BEWEGUNG
Knotens die Aktualisierung einer zentralen Sperr- und Puf- In den letzten Jahren gewinnen so genannte NoSQL-Sys-
ferverwaltung nicht nötig ist, können sehr geringe Failover- teme zur Verwaltung von Daten zunehmend an Bedeutung.
Zeiten erzielt werden. Zudem werden asynchron Checkpoints Einige Kritikpunkte bei der Verwendung relationaler (Clus-
auf einen Festspeicher geschrieben, um auf den Ausfall kom- ter-)Systeme in der Welt der Services regten Unternehmen
pletter Gruppen reagieren zu können bzw. einen System- zur Eigenentwicklung von Systemen zur Datenspeicherung
Reboot zu ermöglichen. Durch den Einsatz der MySQL Clus- und -verarbeitung an, die bewusst auf Merkmale relatio-
ter Carrier Grade Edition kann Hochverfügbarkeit durch die naler DBMS verzichten, um sich auf einen Anwendungsfall
Realisierung geografischer Replikation erzielt werden.[10, 11, zu spezialisieren. Ausgehend von den technischen Beschrei-
5] bungen von Systemen bekannter Internetgrößen entstanden
im Laufe der letzten Jahre eine Vielzahl von Open-Source-
3.4 Bewertung Systemen. Diese kopierten, kombinierten und erweiterten die
Die vorgestellten Datenbankcluster ermöglichen Skalier- Konzepte der Ausgangssysteme mit dem Ziel, den Anfor-
barkeit sowohl durch Einsatz leistungsstärkerer Server als derungen der Unternehmen gerecht zu werden. Der Begriff
auch durch das Hinzufügen weiterer Server. Trotz verschie- NoSQL“ umfasst all jene Systeme und wird inzwischen übli-
”
dener Realisierungen verfügen sie über effiziente Strategi- cherweise als Not only SQL“ ausgelegt. Das Ziel dieser Sys-
”
en für die wesentlichen Herausforderungen im Kontext der teme besteht im Aufzeigen von Alternativen zu relationalen
Skalierbarkeit: Logging, Locking und die Verwaltung von Datenbanksystemen und nicht in deren Ablösung.
Zwischenspeichern[13]. Im Gegensatz zum Shared-Nothing-
Ansatz von MySQL Cluster basieren Oracle RAC und DB2 4.1 Zielstellungen
pureScale auf einer Shared-Disk-Architektur und benötigen Mangels einer anerkannten Definition des Begriffs NoS-
”
wegen ihrer nahen Knotenkopplung schnelle Kommunikation QL“ werden im Folgenden entsprechend der in Abschnitt 2
mittels Hochleistungsnetzwerken. Diese ist für die aufwändi- beschriebenen Herausforderungen die wesentlichen Zielstel-
ge Kommunikation der Sperr- und Cachingverwaltung bei lungen der NoSQL-Systeme zusammengefasst, wobei diese
gegebener Performance notwendig. als Obermenge der Ziele jedes einzelnen NoSQL-Systems zu
Alle Systeme bieten hohe Ausfallsicherheit bis hin zu Un- sehen sind.
terstützung einer Disaster-Recovery über die Anbindung ent- Performance, Skalierbarkeit: Untersuchungen wie [14]
fernter Standby-Systeme. Serverausfälle werden beinahe un- zeigen, dass die Performance moderner RDBMS in verschie-
mittelbar erkannt, die Wiederherstellung ist in kürzester Zeit denen Bereichen um ein Vielfaches übertroffen werden kann.
möglich und führt kaum zu wenig Einschränkungen. Wäh- Als Grund wird vor allem die nach wie vor auf System R
rend bei Oracle RAC im Fehlerfall bis zum Neuaufbau des basierende und stets erweiterte Architektur gesehen, wel-
CGS für einen Augenblick keine Datenmodifikation durchge- che in der Client-Server-Welt hervorragende Dienste leistet,
führt werden können, stehen bei DB2 PureScale die vom aus- für die Welt der Services und die verschiedenden Leistungs-
gefallenen Knoten aktuell veränderten Daten bis zur Instanz- und Kapazitätsverhältnisse von Prozessoren, Fest- und Ar-
Wiederherstellung nicht zur Verfügung. MySQL Cluster be- beitsspeicher jedoch neuer Architekturansätze bedarf [16].
sitzt durch den Shared-Nothing-Ansatz in Verbindung mit Das Hauptziel der meisten NoSQL-Datenspeicher ist das
synchroner Replikation der In-Memory-Daten im Fehlerfall Erreichen linearer horizontaler Skalierbarkeit zur Verarbei-
kaum Einschränkungen. tung riesiger Datenmengen. Sie nutzen hierfür überwiegend
Die wesentlichen Nachteile von Oracle RAC und DB2 pu- Shared-Nothing-Architekturen in Verbindung mit horizonta-
reScale bestehen im Kontext der Anforderungen in Abschnitt ler Partitionierung der Daten. Das im Jahre 2002 bewiesene
2 vor allem in den enormen Kosten für Lizenzen, spezielle Eric Brewers CAP-Theorem besagt, dass nur zwei der drei
Hardware und Wartung im Vergleich zu MySQL Cluster. folgenden Eigenschaften eines verteilten Systems erfüllt sein
Insbesondere sind hier der vor Ausfällen zu schützende Sha- können [4].
red Storage, das Cluster-Dateisystem sowie leistungsstarke • Consistency: Zu jedem Zeitpunkt sehen alle Knoten
Netzwerke für die Clusterkommunikation und Cache Fusion denselben Datenbestand.
bzw. die Cluster Acceleration Facilities zu nennen. Oracle
RAC wurde zudem in den vergangenen Jahren um diverse • Availability: Knoten können Datenbestände jederzeit
Features ergänzt, die zu einer System-Komplexität führten, schreiben und lesen.
die eine intensive Einarbeitungszeit unabdingbar macht.
• Partition tolerance: Das System arbeitet trotz einer
Ein wesentlicher Vorteile von Oracle RAC und DB2 pu-
Zerteilung in Teilsysteme weiter.
reScale ist hingegen die einfache Migration von Anwendun-
gen auf die Clustersysteme, da keine Änderung des Anwen- Während relationale Datenbanksysteme stets auf die Wah-
dungscodes notwendig ist. Da die NDB-Engine von MySQL rung der Konsistenz bestehen und dies zur Beeinträchtigung
Cluster nur einen Teil der Funktionen von InnoDB und My- der Performance und Skalierbarkeit nach sich zieht, verfol-
ISAM unterstützt, müssen fehlende Funktionalitäten auf die gen viele NoSQL-Systeme den im Abschnitt 2 aufgefassten
34
Ansatz, strenge Konsistenzforderungen zugunsten der Per- Komplexitäts- und Mächtigkeitsgrades genutzt, was aus Sicht
formance aufzugeben. des Programmierers ein Fortschritt, aus Sicht eines Daten-
Ausfallsicherheit: Ein Großteil der NoSQL-Systeme bie- bänklers aber durchaus als Rückschritt gesehen werden kann
tet hervorragende Replikations- und Failovertechniken, um [2]. Insbesondere der Verzicht einiger NoSQL-Systeme auf
Ausfälle von Knoten innerhalb einer Shared-Nothing-Archi- die Gewährleistung der ACID-Eigenschaften führt dazu, dass
tektur zu kompensieren, indem das System vor Datenverlust ein Großteil von Unternehmen den Einsatz dieser Systeme
geschützt und der laufende Betrieb minimal beeinflusst wird. ausschließen wird.
Schemaflexibilität: NoSQL-Systeme verdeutlichen, dass
neben dem relationalen Datenbankmodell andere Datenmo- 5. VERBINDUNG BEIDER WELTEN
delle existieren, die Daten gemäß ihrer Eigenschaften ad-
Relationale Datenbanksysteme bieten aufgrund jahrelan-
äquat speichern, ohne sie in ein fixes Datenbankschema zu
ger Forschung und Entwicklung u.a. eine enorme Verbrei-
fügen. Für einfache, schemafreie Daten bieten Key-Value-
tung und Bekanntheit, ein ausgereiftes mathematisches Fun-
Stores die Möglichkeit, mehrattribute Objekte anhand eines
dament, die Datenbanksprache SQL und nicht zuletzt zu-
eindeutigen Schlüssels zu speichern und abzufragen. Dokum-
gesicherte Transaktionseigenschaften durch ACID. Auf der
enten-basierte Systeme erlauben zudem das Speichern kom-
anderen Seite existieren NoSQL-Systeme, deren Verbreitung
plexerer Inhalte wie verschachtelte Daten und bieten durch
sich in der Regel auf wenige Web-Anwendungen beschränkt.
leistungsfähigere Abfragesprache beispielsweise das Suchen
Charakterisiert durch die in Abschnitt 4 zusammengefass-
auf beliebigen Attributen. Wide-Column-Stores vereinen hin-
te Eigenschaften sowie die verwendeten Konzepte, weisen
gegen Vorzüge des Relationenmodells mit Funktionalitäten
sie zum Teil Zielstellungen auf, die sich deutlich von der
wie flexiblen Schemata und Versionierung. Diese Datenmo-
Zielstellung klassischer relationaler Datenbanksysteme un-
delle werden beispielweise durch die Graphen-DBS ergänzt.
terscheidet.
Die Komplexität des Datenmodells spiegelt sich meist in der
Eine Verbindung von Konzepten und Implementierungen
zur Verfügung gestellten Programmierschnittstelle bzw. Ab-
relationaler Datenbanksysteme und NoSQL Data Stores kann
fragesprache wieder, es existieren für die Datenmodelle kaum
dazu genutzt werden, die Vorteile beider Welten zu vereinen.
standardisierte Notationen und standardisierte, deskriptive
Im Folgenden werden mögliche Ansätze zur Vereinigung an-
Sprachen. Entsprechend ihrer Zielstellung bieten sie häufig
hand stellvertrender Beispiele vorgestellt.
auf REST basierende Schnittstellen.[15]
Kosten: Das Gros der Systeme wird als Open Source 5.1 Erweiterungen von NoSQL-Produkten
und mit wenigen Nutzungseinschränkungen zur Verfügung
NoSQL-Systeme wurden in der Regel für ein spezielles An-
gestellt. Die Installation und Verwendung der Systeme ist
wendungsgebiet entwickelt. Durch eine Erweiterung der Sys-
meist unkompliziert. Zudem ist häufig ein Betrieb auf güns-
teme kann ihr Einsatzbereich vergrößert werden, wodurch sie
tigen Commodity Servern möglich, da Einschränkungen be-
die Aufmerksamkeit von mehr Unternehmen auf sich ziehen
züglich der zu verwendenen Hardware kaum vorhanden sind
können. Somit wird neben der Erweiterung der Funktionali-
und geläufige Betriebssysteme unterstützt werden.
tät auch die Bekanntheit des Produkts gesteigert. Ein Bei-
4.2 Bewertung spiel für diesen Ansatz ist das Produkt Hive[17], welches das
NoSQL-System Hadoop um die deskriptive, SQL-ähnliche
NoSQL-Datenspeicher sind hervorragend geeignet, um kos-
Sprache HiveQL erweitert und Schnittstellen in Form ei-
tengünstig skalierbare und hochverfügbare Datenspeicherung
nes CLIs, einer Web-Gui und JDBC/ODBC bietet. Zudem
und -verarbeitung in einem begrenzten Anwendungsfall be-
schafft es durch komplexe Analysen und das Absetzen von
reitzustellen. Aus Sicht dieser Systeme sind die größten Hür-
Ad-hoc-Abfragen die Voraussetzung, Hadoop für Data Ware-
den beim Einsatz relationaler Systeme für Web-Applikatio-
housing zu nutzen.
nen nicht das relationale Datenbankmodell, ACID oder gar
SQL. So zeigen aktuelle Entwicklungen im Bereich relationa- 5.2 Hybridsystem
ler Datenbanksysteme wie VoltDB2 oder HyPer3 , dass diese
Hybride Systeme wie HadoopDB[1] führen zu einem Kom-
Merkmale eine lineare Skalierbarkeit nicht zwingendermaßen
promiss zwischen zwei unterschiedlichen Produktwelten und
ausschließen. Im Zentrum der Beanstandungen stehen hin-
erschaffen dabei Produkte mit neuen Funktionalitäten. Das
gegen die Tatsachen, dass keine bewährten parallelen und
Open-Source-Produkt HadoopDB kombiniert MapReduce in
hochverfügbaren Open Source RDBMS existieren und die
Form der Implementierung Hadoops sowie Hive und Post-
Implementierung bewährter relationaler DBMS häufig kei-
greSQL, wobei das System bereits mit anderen Datenbank-
ne hinreichende Skalierbarkeit zulässt.
systemen getestet wurde. HadoopDB kann sowohl SQL-An-
Die Spezialisierung der NoSQL-Systeme auf eine wenige
fragen als auch MapReduce-Jobs entgegennehmen und bie-
Anwendungsgebiet verwehrt in vielen Fällen den Einsatz
tet den Zugriff auf Hadoops verteiltes Dateisystem HDFS
bei sich ändernden Anforderungen, wie beispielsweise dem
oder alternativ auf ein Datenbanksystem wie PostgreSQL
Wunsch komplexer Abfragen auf Daten bei simplen Daten-
an. In der Folge sind Nutzer durch die Verwendung von Ha-
modellen. Bei der Nutzung eines relationalen DBMS wären
doopDB in der Lage, mittels SQL auf ein Shared-Nothing-
hierbei kaum Änderungen vonnöten, während ein NoSQL-
DBMS zuzugreifen.
System angepasst oder gar ausgetauscht werden muss. Ein
Austausch gestaltet sich zudem schwierig, da es den Syste- 5.3 Anpassung von RDBMS
men an standardisierten Notationen und Schnittstellen man-
Der Abschnitt 4 verdeutlicht, dass die bewährten funda-
gelt. Zudem werden statt deskriptiven Sprachen je nach Da-
mentalen Konzepte hinter dem relationalen Datenbankmo-
tenmodell meist Low-Level-Abfragesprachen verschiedenen
dell mit Anforderungen wie enormer Skalierbarkeit vereinbar
2
http://voltdb.com/ sind, es hierzu jedoch einer Anpassung der von System R
3
http://www3.in.tum.de/research/projects/HyPer/ abstammenden Architektur bedarf. Die Implementierungen
35
von DBMS müssen sich durch geeignete Konfigurationsmög- von bereits wenige Beispiele existieren. Als Mittel der Wahl
lichkeiten weit mehr als bisher an verschiedene Einsatzzwe- zur Vereinigung von Konzepten relationaler Datenbanksys-
cke anpassen lassen. Realisiert werden kann dies beispielswei- teme und NoSQL-Systeme zeichnen sich jedoch aus Sicht
se durch die Ausnutzung der Austauschbarkeit von Kompo- des Autors flexible RDBMS-Implementierungen ab, die sich
nenten in modularen DBMS-Architekturen wie [7] oder die gezielter als in aktuellen Systemen an verschiedene Einsatz-
Implementierung von adaptierbaren DBMS-Komponenten. zwecke anpassen lassen. Als mögliche Ansatzpunkte wurden
Ein möglicher Ansatzpunkt dieses Konzepts könnte das die Implementierung verschiedener Storage-Engines und wei-
Anbieten einer wahlweisen Speicherung auf langsamen, per- terer Transaktionskonzepte vorgeschlagen.
sistenten Festspeichern oder im schnellen, flüchtigen Arbeits-
speicher oder einer kombinierten Lösung sein, was bereits in 7. LITERATUR
einigen Systemen wie dem in Abschnitt 3.3 beschriebenen [1] A. Abouzeid, K. Bajda-Pawlikowski, D. Abadi,
MySQL Cluster möglich ist. Hierdurch bieten sich entspre- A. Silberschatz, and A. Rasin. HadoopDB: an
chend der Charakteristika und des Umfang der zu speichern- architectural hybrid of MapReduce and DBMS
den Daten sowie den Zugriffseigenschaften verschiedene Ein- technologies for analytical workloads. In VLDB ’09,
satzmöglichkeiten. Orthogonal kann wahlweise eine spalten- pages 922–933. VLDB Endowment, 2009.
oder zeilenbasierte Speicherung angeboten werden, um so-
[2] D. J. DeWitt and M. Stonebraker. MapReduce: A
wohl im OLTP- als auch im OLAP-Bereich überzeugende
major step backwards, 2008.
Leistungskennzahlen zu erzielen. Für die Implementierung
[3] D. Florescu and D. Kossmann. Rethinking cost and
bieten einige Systeme bereits verschiedene Storage-Engines
performance of database systems. SIGMOD Rec.,
innerhalb eines Systems.
38:43–48, June 2009.
Auch die Transaktionsverwaltung relationaler Datenbank-
systeme bietet sich bezüglich einer Erweiterung an, indem [4] S. Gilbert and N. Lynch. Brewer’s conjecture and the
neben den harten Anforderungen von ACID und den heute feasibility of consistent, available, partition-tolerant
wählbaren Isolationsszenarien weitere Transaktionskonzep- web services. SIGACT News, 33:51–59, June 2002.
te mit schwächeren Anforderungen integriert werden und [5] T. Grebe. Gruppendynamik – Oracle Real Application
Administratoren die Wahl des Transaktionskonzepts über- Cluster vs. MySQL Cluster. databasepro, (6):46–63,
lassen wird. Aus Sicht des in Abschnitt 4 angesprochenen 2010.
CAP-Theorems könnten je nach Konfiguration des Systems [6] IBM. Transparent Application Scaling with IBM DB2
verschiedene CAP-Eigenschaften erfüllt werden und somit pureScale. Technical report, IBM, 2009.
das Datenbanksystem an verschiedene Einsatzzwecke ange- [7] F. Irmert, M. Daum, and K. Meyer-Wegener. A new
passt werden. Die Realisierung kann beispielsweise über ein approach to modular database systems. In EDBT
autonomes Modul zur Transaktionsverwaltung in einer mo- Workshop der SETMDM ’08, pages 40–44, New York,
dularen DBMS-Architektur gemäß [8] erfolgen. NY, USA, 2008. ACM.
[8] F. Irmert, C. P. Neumann, M. Daum, N. Pollner, and
K. Meyer-Wegener. Technische Grundlagen für eine
6. ZUSAMMENFASSUNG laufzeitadaptierbare Transaktionsverwaltung. In BTW
In diesem Beitrag wurde die Notwendigkeit adaptierbarer ’09, pages 227–236, Münster, Germany, 2009.
flexibler RDBMS-Implementierungen aufgezeigt. Als Grund- [9] A. Maslo. Unendliche Weiten – IBM DB2 pureScale
lage diente der Vergleich von Oracle RAC, IBM DB2 PureS- für Power Systems. databasepro, (1):82–86, 2010.
cale und MySQL Cluster. Er verdeutlichte, dass die Herstel- [10] MySQL. Hochverfügbarkeitslösungen von MySQL –
ler zum Erreichen des Ziels eines horizontal skalierbaren und Ein Überblick über die Hochverfügbarkeitslösungen
hochverfügbaren Clusterdatenbanksystems gemäß verschie- von MySQL. Technical report, MySQL AB, 2007.
dener Implementierungsansätze verfahren. Während Oracle [11] Oracle. MySQL Cluster 7.0 & 7.1: Architektur und
RAC und IBM DB2 PureScale sich durch gute Lastbalan- neue Funktionen. Technical report, Oracle, Inc., 2010.
cierung, effizientes Logging, Locking und Caching sowie ein- [12] Oracle. Oracle Real Application Clusters
fache Migration von Anwendungen auf die Clustersysteme Administration and Deployment Guide, 11g Release 2.
hervorheben, ist MySQL Cluster vor allem durch geringe Technical report, Oracle Corporation, 2010.
Ansprüche bezüglich der verwendeten Hardware und unkom-
[13] M. Stonebraker. The NoSQL Discussion has nothing
plizierte Fehlerbehandlung aufgrund der Shared-Nothing-Ar-
to do with SQL. Blog-Eintrag, 2010.
chitektur gekennzeichnet.
[14] M. Stonebraker, C. Bear, U. Çetintemel,
NoSQL Data Stores stellen vermehrt eine Alternative zu
M. Cherniack, T. Ge, N. Hachem, S. Harizopoulos,
RDBMS dar, die Systeme sind jedoch meist auf den Einsatz
J. Lifter, J. Rogers, and S. Zdonik. One size fits all -
in wenigen Anwendungsgebieten limitiert. Zudem mangelt
Part 2: benchmarking results. In In CIDR, 2007.
es ihnen an Standardisierung und vor allem die Low-Level-
Abfragesprachen sind aus Sicht der Datenbankforschung als [15] M. Stonebraker and R. Cattell. Ten Rules for Scalable
Rückschritt zu werten. Performance in Simple Operation“ Datastores.
”
Durch die Verknüpfung bewährter Konzepte und Imple- Communications of the ACM, 2010.
mentierungen der RDBMS mit Ansätzen der NoSQL-Bewe- [16] M. Stonebraker, S. Madden, D. J. Abadi,
gung können Vorteile beider Welten vereint werden. Die Er- S. Harizopoulos, N. Hachem, and P. Helland. The end
weiterung eines NoSQL-Systems führt nicht nur zu zusätzli- of an architectural era (it’s time for a complete
chen Funktionalitäten, sondern steigert zudem die Bekannt- rewrite). In VLDB ’07, pages 1150–1160. VLDB
heit und eröffnet neue Einsatzbereiche. Eine weitere Mög- Endowment, 2007.
lichkeit stellt eine Kombination von RDBMS- und NoSQL- [17] A. Thusoo. Hive - A Petabyte Scale Data Warehouse
Implementierungen in Form eines hybriden Systems dar, wo- using Hadoop. Technical report, Facebook Inc., 2009.
36