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