Verbindung relationaler Datenbanksysteme undNoSQL-Produkte

Ein Überblick

Andreas GöbelFriedrich-Schiller Universität Jena

Lehrstuhl für Datenbanken und InformationssystemeErnst-Abbe-Platz 2

07743 Jena, Germanyandreas.goebel@uni-jena.de

KURZFASSUNGIn den letzten Jahren entstanden verschiedene Open-Source-Systeme, die mit fundamentalen Konzepten und Regeln rela-tionaler Datenbanksysteme brachen, um die Verwaltung vonDaten in speziellen Einsatzbereichen zu optimieren. Die we-sentlichen Grunde fur die Entwicklung dieser so genanntenNoSQL-Systeme sind jedoch nicht SQL oder das relationaleDatenbankmodell, sondern sie ist auf die Implementierungrelationaler Datenbanksysteme zuruckzufuhren. Der Beitragverdeutlicht durch eine Gegenuberstellung von Oracle Re-al Application Cluster, IBM DB2 PureScale und MySQLCluster die gegensatzlichen Implementierungen relationalerClusterlosungen. An die Motivation der NoSQL-Produktesowie einen Uberblick ihrer Zielstellung, Vor- und Nachteileschließt sich das Aufzeigen von Moglichkeiten an, um Kon-zepte und Implementierungen beider Welten miteinander zuverbinden und so die Vorzuge zu vereinen.

Kategorien und ThemenbeschreibungH.2.4 [Database Management]: Systems—Parallel data-bases ; H.3.5 [Database Management]: Systems and Soft-

ware—Distributed systems

Allgemeine BestimmungenTheory, Design, Reliability

StichworteParallel Databases, NoSQL, Postrelational, Hybrid

23rd GI-Workshop on Foundations of Databases (Grundlagen von Daten-banken), 31.05.2011 - 03.06.2011, Obergurgl, Austria.Copyright is held by the author/owner(s).

1. EINLEITUNGDie zunehmende Verbreitung von Unternehmensnetzwer-

ken, globalen Netzwerken wie dem Internet und mobilenEndgeraten gepaart mit dem Wunsch vieler Unternehmennach Globalisierung fuhrt vermehrt zur Nutzung zentraler(Datenbank-)Services fur eine Vielzahl von Nutzern. Die un-ter dem Begriff Web 2.0 zusammengefassten Entwicklungenermoglichen zunehmend Interaktion und Verknupfungen inNetzwerken, was sowohl die Gestalt als auch die Menge derDaten auffallend beeintrachtigt. So werden Inhaber erfolg-reicher Web-Anwendungen mit beachtlichen Datenmengenkonfrontiert, die das Datenaufkommen in klassischen Anwen-dungen um ein Vielfaches ubersteigen konnen.

Relationale Datenbanksysteme sind zentraler Bestandteildes Software-Stacks vieler Unternehmen und Behorden. Mit-tels der Verbindung eines mathematischen Fundaments, derGewahrleistung der ACID-Eigenschaften und der standardi-sierten deskriptiven Abfragesprache SQL stellen sie die Ver-fugbarkeit, Korrektheit und Auswertbarkeit der Unterneh-mensdaten sicher. Der vorliegende Beitrag motiviert, warumBetreiber vieler Web-Anwendungen trotz der auf der Handliegenden Vorteile bewahrter relationaler Produkte Eigenent-wicklungen propietarer Spezialsysteme zur Datenverwaltungvorantreiben, die bewusst auf wesentliche Merkmale relatio-naler Systeme verzichten.

Nach einer Gegenuberstellung relevanter Implementierungrelationaler Clusterdatenbanken werden die Herausforderun-gen und Einschrankungen der zu dem Schlagwort NoSQL zu-sammengefassten Systeme herausgearbeitet, einige aktuelleEntwicklungen zur Verbindungen von NoSQL und RDBMSzusammengefasst und die Notwendigkeit flexiblerer Imple-mentierungen relationaler Datenbanksysteme aufgezeigt.

2. HERAUSFORDERUNGENDie Charakteristika zu verarbeitender Daten bei Web-An-

wendungen fuhren zu folgenden Kern-Herausforderungen anzu verwendende Datenbanksysteme bzw. Datenspeicher.

Performance und Skalierbarkeit kennzeichnen die be-deutendsten Herausforderungen. Die damit verbundene Ver-ringerung der Latenzzeit in Web-Anwendungen steht hau-fig in direktem Zusammenhang mit der Nutzerzufriedenheitund ist insbesondere in Bereichen wie Suchmaschinen oderdem E-Commerce-Sektor von essentieller Bedeutung. DiePerformance resultiert aus der Grundperformance fur Anfra-

31

gen und der Verarbeitungsgeschwindigkeit fur steigende Da-tenvolumina, welche allgemeinhin als Skalierbarkeit bezeich-net wird. Eine zunehmende Datenmenge kann hierbei dieDauer von Aufgaben, die Anzahl der Aufgaben oder beideserhohen. Die Skalierbarkeit eines Rechensystems kann durchden Einsatz leistungsfahigerer Hardware (vertikale Skalier-barkeit) oder durch das Verteilen der Aufgaben auf weitereRechenressourcen (horizontale Skalierbarkeit) erzielt werden.Die Vorgange mussen jeweils transparent zur Anwendung ge-schehen.

Ausfallsicherheit ist fur jedes zentrale (Datenverarbei-tungs-)System eine wesentliche Herausforderung, um Nut-zern dauerhafte Verfugbarkeit zu bieten. Neben ungeplantenAusfallen eines Systems in Folge von Hardwaredefekten oderSystemfehlern mussen auch geplante Ausfalle – beispielswei-se zur Aktualisierung des Systems – vermieden werden. Bei-de Ausfallarten konnen erheblichen wirtschaftlichem Scha-den durch Kundenverlust oder Ponalen bei Verstoß gegenService Level Agreements nach sich ziehen. Um Hochverfug-barkeit zu erreichen, sollten Single Points of Failure (SPoF)in einem System vermieden sowie binnen kurzer Zeit undautomatisiert auf jegliche Art von Fehlern reagiert werden.

Schemaflexibilitat bezeichnet den Verzicht auf ein vor-definiertes und stets omniprasentes Datenbankschema, umden Umgang mit Datenbanken und -speichern flexibler zugestalten. Dies ermoglicht die adaquate Verwaltung semi-strukturierter und dokumenten-orientierter Daten, die nichtzuletzt aufgrund von Web-Standards und Auszeichnungs-sprachen wie XML oder RDF in Web-Anwendungen weitverbreitet sind. Schemaflexibilitat spielt des Weiteren einewichtige Rolle bei der Konsolidierung von heterogenen Nut-zerdaten innerhalb eines Systems.

Kosten: Fur viele Betreiber von Web-Anwendungen istder Einsatz kostengunstiger Hard- und Software eine Grund-voraussetzung. Lizenz-, Support- und Administrationskos-ten fur Datenbanksysteme sowie die Anschaffungs-, Admi-nistrations- und Betriebskosten von Datenbankservern ma-chen meist einen nicht unerheblichen Teil der IT-Gesamt-aufwendungen aus. Aus diesem Grund wird fur Unterneh-men die Nutzung von kostengunstigen Cloud-Services oder-Storages stets lukrativer. Entsprechend sollte ein geeignetesLizenzierungskonzept angeboten und der Einsatz auf Com-modity-Servern unterstutzt werden.

Fur viele Provider ist die Antwortzeit der Web-Anwen-dung derart wichtig, dass sie Einschrankungen der Daten-konsistenz in Kauf nehmen oder gar auf die Realisierbarkeitdes Definierens von Konsistenzsicherungen verzichten, wenndiese einen Performance-Overhead mit sich bringen. Dies istbemerkenswert, denn es kennzeichnet einen wahrnehmbarenWandel der Anforderungen an Datenbanksysteme. In klassi-schen Unternehmensanwendungen stellt die Forderung nachDatenkonsistenz die oberste Pramisse dar und ist unentbehr-lich. Die Herausforderung besteht hierbei imWesentlichen inder Optimierung der Performance. Dementgegen verdeutli-chen die obigen Herausforderungen, dass die Hauptaufgabenvermehrt in der Optimierung der Antwortzeit oder nach [3]gar in der Minimierung der (Hardware-)Kosten und Erho-hung des Konsistenzniveaus bei gegebenen Performance-Vor-gaben zu sehen ist.

Abbildung 1: Architektur von Oracle RAC (nach[12])

3. RELATIONALE DATENBANKCLUSTERHorizontale Skalierbarkeit und Hochverfugbarkeit unter

Einsatz kostengunstiger Hardware bilden nach Abschnitt 2die wesentlichen Herausforderungen an die Speicherung undVerarbeitung der Daten von Web-Anwendungen. Beinahe al-le relationalen Datenbanksysteme bieten Mittel, um ihre Sys-teme vor Ausfallen und Datenverlust in diversen Fehlersze-narien zu schutzen und eine hohe Verfugbarkeit zu erzielen.Sie bieten fur dieses Ziel neben Sicherungs- und Wiederher-stellungsmoglichkeiten von Datenbanken verschiedene Tech-niken zur Replikation. Zumeist erkennen sie ein Problem je-doch erst beim erfolglosen Datenzugriff statt unmittelbarnach dem Auftreten und erfordern im Fehlerfall einen ma-nuellen Eingriff zum Umleiten auf das Replikat. Zudem sinddie Replikate bei einigen Systemen ausschließlich im Fehler-fall einsetzbar und dienen im Normalbetrieb nicht der Last-balancierung. Im Folgenden werden die Eckpunkte vorherr-schender Hochverfugbarkeitslosungen gegenubergestellt, diediese Mangel nicht aufweisen und zudem horizontale Skalier-barkeit in Mehrrechnersystemen ermoglichen.

3.1 Oracle Real Application ClusterOracle Real Application Cluster (RAC) ermoglicht bis zu

100 Datenbankinstanzen einen parallelen Zugriff auf den-selben Datenbestand und realisiert somit eine Shared-Disk-Architektur. Wie Abbildung 1 verdeutlicht, greifen die Ap-plication Server und Web Server uber eine gemeinsame Ser-vice-Schnittstelle auf das System zu, die u.a. der Lastba-lancierung dient. Samtliche Dateien fur Daten, Verwaltungund Konfigurationsparameter werden auf einem clusterfahi-gen Storage-System gespeichert und sind von allen Servernles- und schreibbar. Lediglich die Undo- und Redo-Logs bil-den eine Ausnahme: Sie werden stets von der Besitzerinstanzgeschrieben und konnen nur von deren Nachbarinstanzen ge-lesen werden, um die Besitzerinstanz bei einem Ausfall auto-matisch wiederherstellen zu konnen. Der Ausfall eines Kno-tens wird durch eine Heartbeat-Netzwerkverbindung in kur-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 zumAusfall des kompletten Clusters fuhren. Oracle Data Guardermoglicht daruber hinaus das Spiegeln auf ein weiter ent-ferntes Standby-System zur Realisierung einer Disaster Re-covery.[12, 5]Oracle RAC bietet Skalierbarkeit durch das Hinzufugen

neuer Nodes, einen automatischen Lastausgleich und die pa-rallelisierte Ausfuhrung von Operationen auf mehreren Ser-vern. Fur den parallelen Zugriff mehrerer Instanzen auf den-selben Datenbestand nutzt Oracle im Falle einer Datenmodi-fikation den Global Cache Service (GCS), um zu bestimmen,in welchen lokalen Knotencaches die betroffenen Blocke lie-gen bzw. ob sie sich gegebenenfalls bereits auf dem Storage-System befinden. Nachdem die Position bekannt ist, werdendie Blocke durch ein In-Memory-Blockinventar (Global Re-source Directory, GRD) und Global Enqueue Service auf ak-tive Schreibsperren und weitere wartende Instanzen gepruft,um anschließend eigene Schreibsperren zu setzen, die wieder-um im GRD vermerkt und anderen Nodes bekannt gemachtwerden. Die verwendeten Komponenten werden unter demBegriff Cache Fusion zusammengefasst und ermoglichen zu-dem beim Datenzugriff das direkte Versenden von Datenzwischen Buffer-Caches verschiedener Nodes. Oracle RACvermeidet somit Cache-Koharenz und ein SPoF durch einenglobalen Cache, jedoch auf Kosten von sehr viel Kommuni-kation.[12, 5]

3.2 IBM DB2 PureScaleDas Design der IBM-Clusterlosung DB2 pureScale basiert

auf der Architektur des bewahrten Parallel Sysplex fur Sys-tem z1. Sie ermoglicht durch eine Shared-Disk-Architekturden gemeinsamen Zugriff von bis zu 128 Datenbankservernauf einen gemeinsamen Datenbestand, der durch IBMs Ge-neral Parallel File System zur Verfugung gestellt wird. DieAbbildung 2 zeigt, dass der Cluster neben den Datenbank-servern aus Cluster Facilities (CF) besteht. Um einen SPoFzu verhindern, ist diese Komponente meist doppelt ausge-legt. Sie kann ein eigenstandiges System sein oder auf einemClusterknoten betrieben werden. Die CF ermoglicht die zen-trale Verwaltung der Sperren (Global Lock Table, GLT) und

1Auf eine gesonderte Beschreibung des Parallel Sysplex wirdaufgrund analoger Konzepte verzichtet.

Abbildung 3: Architektur von MySQL Cluster (nach[10])

des Caches (Group Buffer Pool, GBP), wodurch analog zumGRD und GCS des Oracle RAC die Informationen der Da-tenblocke verwaltet und allen Servern zur Verfugung gestelltwerden. Die Server sind untereinander sowie mit der CF mit-tels eines Hochleistungsnetzwerks verbunden, welches einendirekten Fernzugriff auf den Arbeitsspeicher (RDMA) in we-nigen Mikrosekunden ermoglicht. Bei einem Schreibvorgangermoglicht diese schnelle Verbindung das synchrone Aktua-lisieren der zentralen Sperrtabelle in Form von Zeilen- undSeitensperren und des zentralen wie auch anderer relevanterCaches. Beim Lesevorgang eines Nodes wird nach erfolgloserSuche im lokalen Cache im GBP nach den Blocken gesucht.Werden die Daten vom Festspeicher in den lokalen Cachegeladen, wird dies ebenfalls dem GBP bekannt gemacht. [9,6]

Ein integrierter Watchdog-Prozess uberwacht permanentdie Verfugbarkeit samtlicher Knoten. Wird der Ausfall einesKnotens bemerkt, stehen bis zum Instanzneustart lediglichdie momentan von diesem Knoten aktualisierten Tupel nichtzur Verfugung. Logs werden im Gegensatz zu Oracle RACauf den gemeinsamen Festspeicher geschrieben und sind furdie Recovery von anderen Knoten lesbar.

3.3 MySQL ClusterMySQL Cluster basiert im Gegensatz zu den Losungen

von IBM und Oracle auf einer Shared-Nothing-Architektur,weshalb die bis zu 255 Datenknoten nicht parallel auf einengemeinsamen Datenbestand zugreifen, sondern jeder Daten-knoten einen Teil des Gesamtdatenbestands verwaltet. DieTabellen werden bei diesem Ansatz horizontal partitioniert.MySQL Cluster stellt keine spezifischen Voraussetzungen anzu verwendende Netzwerke oder Server und unterstutzt In-Memory- als auch Festpeicher-Datenspeicherung. Auf dasSystem wird uber vollwertige MySQL-Server zugegriffen. Siesind mit einer Schnittstelle zur NDB-Engine versehen undwerden zudem fur verschiedene Funktionen wie Views, Trig-ger oder Volltext-Indizes verwendet, die von der NDB-En-gine nicht unterstutzt werden. Die Management-Server sindfur die Konfiguration des Clusters zustandig, wahrend die

33

Datenknoten zur Speicherung der Daten und der Verwal-tung von Transaktionen dienen. Knoten, die deckungsgleicheInhalte verwalten, werden zu einer Datenknotengruppe zu-sammengefasst, in der die synchrone Replikation der Knotendazu fuhrt, dass der Ausfall von Knoten keine aufwandigeInstanz -Wiederherstellung nach sich zieht. Somit mussenUndo- und Redo-Dateien anderen Knoten nicht sichtbar ge-macht werden und das System ist verfugbar, solange ein Da-tenknoten je Gruppe erreichbar ist. Da beim Ausfall einesKnotens die Aktualisierung einer zentralen Sperr- und Puf-ferverwaltung nicht notig ist, konnen sehr geringe Failover-Zeiten erzielt werden. Zudem werden asynchron Checkpointsauf einen Festspeicher geschrieben, um auf den Ausfall kom-pletter Gruppen reagieren zu konnen bzw. einen System-Reboot zu ermoglichen. Durch den Einsatz der MySQL Clus-ter Carrier Grade Edition kann Hochverfugbarkeit durch dieRealisierung geografischer Replikation erzielt werden.[10, 11,5]

3.4 BewertungDie vorgestellten Datenbankcluster ermoglichen Skalier-

barkeit sowohl durch Einsatz leistungsstarkerer Server alsauch durch das Hinzufugen weiterer Server. Trotz verschie-dener Realisierungen verfugen sie uber effiziente Strategi-en fur die wesentlichen Herausforderungen im Kontext derSkalierbarkeit: Logging, Locking und die Verwaltung vonZwischenspeichern[13]. Im Gegensatz zum Shared-Nothing-Ansatz von MySQL Cluster basieren Oracle RAC und DB2pureScale auf einer Shared-Disk-Architektur und benotigenwegen ihrer nahen Knotenkopplung schnelle Kommunikationmittels Hochleistungsnetzwerken. Diese ist fur die aufwandi-ge Kommunikation der Sperr- und Cachingverwaltung beigegebener Performance notwendig.Alle Systeme bieten hohe Ausfallsicherheit bis hin zu Un-

terstutzung einer Disaster-Recovery uber die Anbindung ent-fernter Standby-Systeme. Serverausfalle werden beinahe un-mittelbar erkannt, die Wiederherstellung ist in kurzester Zeitmoglich und fuhrt kaum zu wenig Einschrankungen. Wah-rend bei Oracle RAC im Fehlerfall bis zum Neuaufbau desCGS fur einen Augenblick keine Datenmodifikation durchge-fuhrt werden konnen, stehen bei DB2 PureScale die vom aus-gefallenen Knoten aktuell veranderten Daten bis zur Instanz-Wiederherstellung nicht zur Verfugung. MySQL Cluster be-sitzt durch den Shared-Nothing-Ansatz in Verbindung mitsynchroner Replikation der In-Memory-Daten im Fehlerfallkaum Einschrankungen.Die wesentlichen Nachteile von Oracle RAC und DB2 pu-

reScale bestehen im Kontext der Anforderungen in Abschnitt2 vor allem in den enormen Kosten fur Lizenzen, spezielleHardware und Wartung im Vergleich zu MySQL Cluster.Insbesondere sind hier der vor Ausfallen zu schutzende Sha-red Storage, das Cluster-Dateisystem sowie leistungsstarkeNetzwerke fur die Clusterkommunikation und Cache Fusionbzw. die Cluster Acceleration Facilities zu nennen. OracleRAC wurde zudem in den vergangenen Jahren um diverseFeatures erganzt, die zu einer System-Komplexitat fuhrten,die eine intensive Einarbeitungszeit unabdingbar macht.Ein wesentlicher Vorteile von Oracle RAC und DB2 pu-

reScale ist hingegen die einfache Migration von Anwendun-gen auf die Clustersysteme, da keine Anderung des Anwen-dungscodes notwendig ist. Da die NDB-Engine von MySQLCluster nur einen Teil der Funktionen von InnoDB und My-ISAM unterstutzt, mussen fehlende Funktionalitaten auf die

MySQL-Server ausgelagert werden, um deren Performanceund Verfugbarkeit manuell gesorgt werden muss. Daher bie-tet sich der MySQL Cluster vor allem in Szenarien mit ei-ner Vielzahl simpler Anfragen und hohen Latenz- und Ver-fugbarkeitsanforderungen an, wahrend die Einsatzmoglich-keiten von Oracle RAC und DB2 pureScale kaum begrenztsind.

4. NOSQL-BEWEGUNGIn den letzten Jahren gewinnen so genannte NoSQL-Sys-

teme zur Verwaltung von Daten zunehmend an Bedeutung.Einige Kritikpunkte bei der Verwendung relationaler (Clus-ter-)Systeme in der Welt der Services regten Unternehmenzur Eigenentwicklung von Systemen zur Datenspeicherungund -verarbeitung an, die bewusst auf Merkmale relatio-naler DBMS verzichten, um sich auf einen Anwendungsfallzu spezialisieren. Ausgehend von den technischen Beschrei-bungen von Systemen bekannter Internetgroßen entstandenim Laufe der letzten Jahre eine Vielzahl von Open-Source-Systemen. Diese kopierten, kombinierten und erweiterten dieKonzepte der Ausgangssysteme mit dem Ziel, den Anfor-derungen der Unternehmen gerecht zu werden. Der Begriff

”NoSQL“ umfasst all jene Systeme und wird inzwischen ubli-cherweise als

”Not only SQL“ ausgelegt. Das Ziel dieser Sys-

teme besteht im Aufzeigen von Alternativen zu relationalenDatenbanksystemen und nicht in deren Ablosung.

4.1 ZielstellungenMangels einer anerkannten Definition des Begriffs

”NoS-

QL“ werden im Folgenden entsprechend der in Abschnitt 2beschriebenen Herausforderungen die wesentlichen Zielstel-lungen der NoSQL-Systeme zusammengefasst, wobei dieseals Obermenge der Ziele jedes einzelnen NoSQL-Systems zusehen sind.

Performance, Skalierbarkeit: Untersuchungen wie [14]zeigen, dass die Performance moderner RDBMS in verschie-denen Bereichen um ein Vielfaches ubertroffen werden kann.Als Grund wird vor allem die nach wie vor auf System Rbasierende und stets erweiterte Architektur gesehen, wel-che in der Client-Server-Welt hervorragende Dienste leistet,fur die Welt der Services und die verschiedenden Leistungs-und Kapazitatsverhaltnisse von Prozessoren, Fest- und Ar-beitsspeicher jedoch neuer Architekturansatze bedarf [16].Das Hauptziel der meisten NoSQL-Datenspeicher ist dasErreichen linearer horizontaler Skalierbarkeit zur Verarbei-tung riesiger Datenmengen. Sie nutzen hierfur uberwiegendShared-Nothing-Architekturen in Verbindung mit horizonta-ler Partitionierung der Daten. Das im Jahre 2002 bewieseneEric Brewers CAP-Theorem besagt, dass nur zwei der dreifolgenden Eigenschaften eines verteilten Systems erfullt seinkonnen [4].

• Consistency: Zu jedem Zeitpunkt sehen alle Knotendenselben Datenbestand.

• Availability: Knoten konnen Datenbestande jederzeitschreiben und lesen.

• Partition tolerance: Das System arbeitet trotz einerZerteilung in Teilsysteme weiter.

Wahrend relationale Datenbanksysteme stets auf die Wah-rung der Konsistenz bestehen und dies zur Beeintrachtigungder Performance und Skalierbarkeit nach sich zieht, verfol-gen viele NoSQL-Systeme den im Abschnitt 2 aufgefassten

34

Ansatz, strenge Konsistenzforderungen zugunsten der Per-formance aufzugeben.Ausfallsicherheit: Ein Großteil der NoSQL-Systeme bie-

tet hervorragende Replikations- und Failovertechniken, umAusfalle von Knoten innerhalb einer Shared-Nothing-Archi-tektur zu kompensieren, indem das System vor Datenverlustgeschutzt und der laufende Betrieb minimal beeinflusst wird.Schemaflexibilitat:NoSQL-Systeme verdeutlichen, dass

neben dem relationalen Datenbankmodell andere Datenmo-delle existieren, die Daten gemaß ihrer Eigenschaften ad-aquat speichern, ohne sie in ein fixes Datenbankschema zufugen. Fur einfache, schemafreie Daten bieten Key-Value-Stores die Moglichkeit, mehrattribute Objekte anhand eineseindeutigen Schlussels zu speichern und abzufragen. Dokum-enten-basierte Systeme erlauben zudem das Speichern kom-plexerer Inhalte wie verschachtelte Daten und bieten durchleistungsfahigere Abfragesprache beispielsweise das Suchenauf beliebigen Attributen. Wide-Column-Stores vereinen hin-gegen Vorzuge des Relationenmodells mit Funktionalitatenwie flexiblen Schemata und Versionierung. Diese Datenmo-delle werden beispielweise durch die Graphen-DBS erganzt.Die Komplexitat des Datenmodells spiegelt sich meist in derzur Verfugung gestellten Programmierschnittstelle bzw. Ab-fragesprache wieder, es existieren fur die Datenmodelle kaumstandardisierte Notationen und standardisierte, deskriptiveSprachen. Entsprechend ihrer Zielstellung bieten sie haufigauf REST basierende Schnittstellen.[15]Kosten: Das Gros der Systeme wird als Open Source

und mit wenigen Nutzungseinschrankungen zur Verfugunggestellt. Die Installation und Verwendung der Systeme istmeist unkompliziert. Zudem ist haufig ein Betrieb auf guns-tigen Commodity Servern moglich, da Einschrankungen be-zuglich der zu verwendenen Hardware kaum vorhanden sindund gelaufige Betriebssysteme unterstutzt werden.

4.2 BewertungNoSQL-Datenspeicher sind hervorragend geeignet, um kos-

tengunstig skalierbare und hochverfugbare Datenspeicherungund -verarbeitung in einem begrenzten Anwendungsfall be-reitzustellen. Aus Sicht dieser Systeme sind die großten Hur-den beim Einsatz relationaler Systeme fur Web-Applikatio-nen nicht das relationale Datenbankmodell, ACID oder garSQL. So zeigen aktuelle Entwicklungen im Bereich relationa-ler Datenbanksysteme wie VoltDB2 oder HyPer3, dass dieseMerkmale eine lineare Skalierbarkeit nicht zwingendermaßenausschließen. Im Zentrum der Beanstandungen stehen hin-gegen die Tatsachen, dass keine bewahrten parallelen undhochverfugbaren Open Source RDBMS existieren und dieImplementierung bewahrter relationaler DBMS haufig kei-ne hinreichende Skalierbarkeit zulasst.Die Spezialisierung der NoSQL-Systeme auf eine wenige

Anwendungsgebiet verwehrt in vielen Fallen den Einsatzbei sich andernden Anforderungen, wie beispielsweise demWunsch komplexer Abfragen auf Daten bei simplen Daten-modellen. Bei der Nutzung eines relationalen DBMS warenhierbei kaum Anderungen vonnoten, wahrend ein NoSQL-System angepasst oder gar ausgetauscht werden muss. EinAustausch gestaltet sich zudem schwierig, da es den Syste-men an standardisierten Notationen und Schnittstellen man-gelt. Zudem werden statt deskriptiven Sprachen je nach Da-tenmodell meist Low-Level-Abfragesprachen verschiedenen

2http://voltdb.com/3http://www3.in.tum.de/research/projects/HyPer/

Komplexitats- und Machtigkeitsgrades genutzt, was aus Sichtdes Programmierers ein Fortschritt, aus Sicht eines Daten-banklers aber durchaus als Ruckschritt gesehen werden kann[2]. Insbesondere der Verzicht einiger NoSQL-Systeme aufdie Gewahrleistung der ACID-Eigenschaften fuhrt dazu, dassein Großteil von Unternehmen den Einsatz dieser Systemeausschließen wird.

5. VERBINDUNG BEIDER WELTENRelationale Datenbanksysteme bieten aufgrund jahrelan-

ger Forschung und Entwicklung u.a. eine enorme Verbrei-tung und Bekanntheit, ein ausgereiftes mathematisches Fun-dament, die Datenbanksprache SQL und nicht zuletzt zu-gesicherte Transaktionseigenschaften durch ACID. Auf deranderen Seite existieren NoSQL-Systeme, deren Verbreitungsich in der Regel auf wenige Web-Anwendungen beschrankt.Charakterisiert durch die in Abschnitt 4 zusammengefass-te Eigenschaften sowie die verwendeten Konzepte, weisensie zum Teil Zielstellungen auf, die sich deutlich von derZielstellung klassischer relationaler Datenbanksysteme un-terscheidet.

Eine Verbindung von Konzepten und Implementierungenrelationaler Datenbanksysteme und NoSQL Data Stores kanndazu genutzt werden, die Vorteile beider Welten zu vereinen.Im Folgenden werden mogliche Ansatze zur Vereinigung an-hand stellvertrender Beispiele vorgestellt.

5.1 Erweiterungen von NoSQL-ProduktenNoSQL-Systeme wurden in der Regel fur ein spezielles An-

wendungsgebiet entwickelt. Durch eine Erweiterung der Sys-teme kann ihr Einsatzbereich vergroßert werden, wodurch siedie Aufmerksamkeit von mehr Unternehmen auf sich ziehenkonnen. Somit wird neben der Erweiterung der Funktionali-tat auch die Bekanntheit des Produkts gesteigert. Ein Bei-spiel fur diesen Ansatz ist das Produkt Hive[17], welches dasNoSQL-System Hadoop um die deskriptive, SQL-ahnlicheSprache HiveQL erweitert und Schnittstellen in Form ei-nes CLIs, einer Web-Gui und JDBC/ODBC bietet. Zudemschafft es durch komplexe Analysen und das Absetzen vonAd-hoc-Abfragen die Voraussetzung, Hadoop fur Data Ware-housing zu nutzen.

5.2 HybridsystemHybride Systeme wie HadoopDB[1] fuhren zu einem Kom-

promiss zwischen zwei unterschiedlichen Produktwelten underschaffen dabei Produkte mit neuen Funktionalitaten. DasOpen-Source-Produkt HadoopDB kombiniert MapReduce inForm der Implementierung Hadoops sowie Hive und Post-greSQL, wobei das System bereits mit anderen Datenbank-systemen getestet wurde. HadoopDB kann sowohl SQL-An-fragen als auch MapReduce-Jobs entgegennehmen und bie-tet den Zugriff auf Hadoops verteiltes Dateisystem HDFSoder alternativ auf ein Datenbanksystem wie PostgreSQLan. In der Folge sind Nutzer durch die Verwendung von Ha-doopDB in der Lage, mittels SQL auf ein Shared-Nothing-DBMS zuzugreifen.

5.3 Anpassung von RDBMSDer Abschnitt 4 verdeutlicht, dass die bewahrten funda-

mentalen Konzepte hinter dem relationalen Datenbankmo-dell mit Anforderungen wie enormer Skalierbarkeit vereinbarsind, es hierzu jedoch einer Anpassung der von System Rabstammenden Architektur bedarf. Die Implementierungen

35

von DBMS mussen sich durch geeignete Konfigurationsmog-lichkeiten weit mehr als bisher an verschiedene Einsatzzwe-cke anpassen lassen. Realisiert werden kann dies beispielswei-se durch die Ausnutzung der Austauschbarkeit von Kompo-nenten in modularen DBMS-Architekturen wie [7] oder dieImplementierung von adaptierbaren DBMS-Komponenten.Ein moglicher Ansatzpunkt dieses Konzepts konnte das

Anbieten einer wahlweisen Speicherung auf langsamen, per-sistenten Festspeichern oder im schnellen, fluchtigen Arbeits-speicher oder einer kombinierten Losung sein, was bereits ineinigen Systemen wie dem in Abschnitt 3.3 beschriebenenMySQL Cluster moglich ist. Hierdurch bieten sich entspre-chend der Charakteristika und des Umfang der zu speichern-den Daten sowie den Zugriffseigenschaften verschiedene Ein-satzmoglichkeiten. Orthogonal kann wahlweise eine spalten-oder zeilenbasierte Speicherung angeboten werden, um so-wohl im OLTP- als auch im OLAP-Bereich uberzeugendeLeistungskennzahlen zu erzielen. Fur die Implementierungbieten einige Systeme bereits verschiedene Storage-Enginesinnerhalb eines Systems.Auch die Transaktionsverwaltung relationaler Datenbank-

systeme bietet sich bezuglich einer Erweiterung an, indemneben den harten Anforderungen von ACID und den heutewahlbaren Isolationsszenarien weitere Transaktionskonzep-te mit schwacheren Anforderungen integriert werden undAdministratoren die Wahl des Transaktionskonzepts uber-lassen wird. Aus Sicht des in Abschnitt 4 angesprochenenCAP-Theorems konnten je nach Konfiguration des Systemsverschiedene CAP-Eigenschaften erfullt werden und somitdas Datenbanksystem an verschiedene Einsatzzwecke ange-passt werden. Die Realisierung kann beispielsweise uber einautonomes Modul zur Transaktionsverwaltung in einer mo-dularen DBMS-Architektur gemaß [8] erfolgen.

6. ZUSAMMENFASSUNGIn diesem Beitrag wurde die Notwendigkeit adaptierbarer

flexibler RDBMS-Implementierungen aufgezeigt. Als Grund-lage diente der Vergleich von Oracle RAC, IBM DB2 PureS-cale und MySQL Cluster. Er verdeutlichte, dass die Herstel-ler zum Erreichen des Ziels eines horizontal skalierbaren undhochverfugbaren Clusterdatenbanksystems gemaß verschie-dener Implementierungsansatze verfahren. Wahrend OracleRAC und IBM DB2 PureScale sich durch gute Lastbalan-cierung, effizientes Logging, Locking und Caching sowie ein-fache Migration von Anwendungen auf die Clustersystemehervorheben, ist MySQL Cluster vor allem durch geringeAnspruche bezuglich der verwendeten Hardware und unkom-plizierte Fehlerbehandlung aufgrund der Shared-Nothing-Ar-chitektur gekennzeichnet.NoSQL Data Stores stellen vermehrt eine Alternative zu

RDBMS dar, die Systeme sind jedoch meist auf den Einsatzin wenigen Anwendungsgebieten limitiert. Zudem mangeltes ihnen an Standardisierung und vor allem die Low-Level-Abfragesprachen sind aus Sicht der Datenbankforschung alsRuckschritt zu werten.Durch die Verknupfung bewahrter Konzepte und Imple-

mentierungen der RDBMS mit Ansatzen der NoSQL-Bewe-gung konnen Vorteile beider Welten vereint werden. Die Er-weiterung eines NoSQL-Systems fuhrt nicht nur zu zusatzli-chen Funktionalitaten, sondern steigert zudem die Bekannt-heit und eroffnet neue Einsatzbereiche. Eine weitere Mog-lichkeit stellt eine Kombination von RDBMS- und NoSQL-Implementierungen in Form eines hybriden Systems dar, wo-

von bereits wenige Beispiele existieren. Als Mittel der Wahlzur Vereinigung von Konzepten relationaler Datenbanksys-teme und NoSQL-Systeme zeichnen sich jedoch aus Sichtdes Autors flexible RDBMS-Implementierungen ab, die sichgezielter als in aktuellen Systemen an verschiedene Einsatz-zwecke anpassen lassen. Als mogliche Ansatzpunkte wurdendie Implementierung verschiedener Storage-Engines und wei-terer Transaktionskonzepte vorgeschlagen.

7. LITERATUR[1] A. Abouzeid, K. Bajda-Pawlikowski, D. Abadi,

A. Silberschatz, and A. Rasin. HadoopDB: anarchitectural hybrid of MapReduce and DBMStechnologies for analytical workloads. In VLDB ’09,pages 922–933. VLDB Endowment, 2009.

[2] D. J. DeWitt and M. Stonebraker. MapReduce: Amajor step backwards, 2008.

[3] D. Florescu and D. Kossmann. Rethinking cost andperformance of database systems. SIGMOD Rec.,38:43–48, June 2009.

[4] S. Gilbert and N. Lynch. Brewer’s conjecture and thefeasibility of consistent, available, partition-tolerantweb services. SIGACT News, 33:51–59, June 2002.

[5] T. Grebe. Gruppendynamik – Oracle Real ApplicationCluster vs. MySQL Cluster. databasepro, (6):46–63,2010.

[6] IBM. Transparent Application Scaling with IBM DB2pureScale. Technical report, IBM, 2009.

[7] F. Irmert, M. Daum, and K. Meyer-Wegener. A newapproach to modular database systems. In EDBTWorkshop der SETMDM ’08, pages 40–44, New York,NY, USA, 2008. ACM.

[8] F. Irmert, C. P. Neumann, M. Daum, N. Pollner, andK. Meyer-Wegener. Technische Grundlagen fur einelaufzeitadaptierbare Transaktionsverwaltung. In BTW’09, pages 227–236, Munster, Germany, 2009.

[9] A. Maslo. Unendliche Weiten – IBM DB2 pureScalefur Power Systems. databasepro, (1):82–86, 2010.

[10] MySQL. Hochverfugbarkeitslosungen von MySQL –Ein Uberblick uber die Hochverfugbarkeitslosungenvon MySQL. Technical report, MySQL AB, 2007.

[11] Oracle. MySQL Cluster 7.0 & 7.1: Architektur undneue Funktionen. Technical report, Oracle, Inc., 2010.

[12] Oracle. Oracle Real Application ClustersAdministration and Deployment Guide, 11g Release 2.Technical report, Oracle Corporation, 2010.

[13] M. Stonebraker. The NoSQL Discussion has nothingto do with SQL. Blog-Eintrag, 2010.

[14] M. Stonebraker, C. Bear, U. Cetintemel,M. Cherniack, T. Ge, N. Hachem, S. Harizopoulos,J. Lifter, J. Rogers, and S. Zdonik. One size fits all -Part 2: benchmarking results. In In CIDR, 2007.

[15] M. Stonebraker and R. Cattell. Ten Rules for ScalablePerformance in

”Simple Operation“ Datastores.

Communications of the ACM, 2010.

[16] M. Stonebraker, S. Madden, D. J. Abadi,S. Harizopoulos, N. Hachem, and P. Helland. The endof an architectural era (it’s time for a completerewrite). In VLDB ’07, pages 1150–1160. VLDBEndowment, 2007.

[17] A. Thusoo. Hive - A Petabyte Scale Data Warehouseusing Hadoop. Technical report, Facebook Inc., 2009.

36