EINLEITUNG

Die zunehmende Verbreitung von Unternehmensnetzwerken, globalen Netzwerken wie dem Internet und mobilen Endgeräten gepaart mit dem Wunsch vieler Unternehmen nach Globalisierung führt vermehrt zur Nutzung zentraler (Datenbank-)Services für eine Vielzahl von Nutzern. Die unter dem Begriff Web 2.0 zusammengefassten Entwicklungen ermöglichen zunehmend Interaktion und Verknüpfungen in Netzwerken, was sowohl die Gestalt als auch die Menge der Daten auffallend beeinträchtigt. So werden Inhaber erfolgreicher Web-Anwendungen mit beachtlichen Datenmengen konfrontiert, die das Datenaufkommen in klassischen Anwendungen um ein Vielfaches übersteigen können.

Relationale Datenbanksysteme sind zentraler Bestandteil des Software-Stacks vieler Unternehmen und Behörden. Mittels der Verbindung eines mathematischen Fundaments, der Gewährleistung der ACID-Eigenschaften und der standardisierten deskriptiven Abfragesprache SQL stellen sie die Verfügbarkeit, Korrektheit und Auswertbarkeit der Unternehmensdaten sicher. Der vorliegende Beitrag motiviert, warum Betreiber vieler Web-Anwendungen trotz der auf der Hand liegenden Vorteile bewährter relationaler Produkte Eigenentwicklungen propietärer Spezialsysteme zur Datenverwaltung vorantreiben, die bewusst auf wesentliche Merkmale relationaler Systeme verzichten.

Nach einer Gegenüberstellung relevanter Implementierung relationaler Clusterdatenbanken werden die Herausforderungen und Einschränkungen der zu dem Schlagwort NoSQL zusammengefassten Systeme herausgearbeitet, einige aktuelle Entwicklungen zur Verbindungen von NoSQL und RDBMS zusammengefasst und die Notwendigkeit flexiblerer Implementierungen relationaler Datenbanksysteme aufgezeigt. Für viele Provider ist die Antwortzeit der Web-Anwendung derart wichtig, dass sie Einschränkungen der Datenkonsistenz in Kauf nehmen oder gar auf die Realisierbarkeit des Definierens von Konsistenzsicherungen verzichten, wenn diese einen Performance-Overhead mit sich bringen. Dies ist bemerkenswert, denn es kennzeichnet einen wahrnehmbaren Wandel der Anforderungen an Datenbanksysteme. In klassischen Unternehmensanwendungen stellt die Forderung nach Datenkonsistenz die oberste Prämisse dar und ist unentbehrlich. Die Herausforderung besteht hierbei im Wesentlichen in der Optimierung der Performance. Dementgegen verdeutlichen die obigen Herausforderungen, dass die Hauptaufgaben vermehrt in der Optimierung der Antwortzeit oder nach [3] gar in der Minimierung der (Hardware-)Kosten und Erhöhung des Konsistenzniveaus bei gegebenen Performance-Vorgaben zu sehen ist.

HERAUSFORDERUNGENDie

Oracle Real Application Cluster

MySQL ClusterMySQL

NOSQL-BEWEGUNG

In den letzten Jahren gewinnen so genannte NoSQL-Systeme zur Verwaltung von Daten zunehmend an Bedeutung. Einige Kritikpunkte bei der Verwendung relationaler (Cluster-)Systeme in der Welt der Services regten Unternehmen zur Eigenentwicklung von Systemen zur Datenspeicherung und -verarbeitung an, die bewusst auf Merkmale relationaler DBMS verzichten, um sich auf einen Anwendungsfall zu spezialisieren. Ausgehend von den technischen Beschreibungen von Systemen bekannter Internetgrößen entstanden im Laufe der letzten Jahre eine Vielzahl von Open-Source-Systemen. Diese kopierten, kombinierten und erweiterten die Konzepte der Ausgangssysteme mit dem Ziel, den Anforderungen der Unternehmen gerecht zu werden. Der Begriff " NoSQL" umfasst all jene Systeme und wird inzwischen üblicherweise als " Not only SQL" ausgelegt. Das Ziel dieser Systeme besteht im Aufzeigen von Alternativen zu relationalen Datenbanksystemen und nicht in deren Ablösung.

Zielstellungen

Mangels einer Definition des Begriffs "

NoS-QL" werden im Folgenden entsprechend der in Abschnitt 2 beschriebenen Herausforderungen die wesentlichen Zielstellungen der NoSQL-Systeme zusammengefasst, wobei diese als Obermenge der Ziele jedes einzelnen NoSQL-Systems zu sehen sind.

Performance, Skalierbarkeit: Untersuchungen wie [14] zeigen, dass die Performance moderner RDBMS in verschiedenen Bereichen um ein Vielfaches übertroffen werden kann. Als Grund wird vor allem die nach wie vor auf System R basierende und stets erweiterte Architektur gesehen, welche in der Client-Server-Welt hervorragende Dienste leistet, für die Welt der Services und die verschiedenden Leistungsund Kapazitätsverhältnisse von Prozessoren, Fest-und Arbeitsspeicher jedoch neuer Architekturansätze bedarf [16]. Das Hauptziel der meisten NoSQL-Datenspeicher ist das Erreichen linearer horizontaler Skalierbarkeit zur Verarbeitung riesiger Datenmengen. Sie nutzen hierfür überwiegend Shared-Nothing-Architekturen in Verbindung mit horizontaler Partitionierung der Daten. Das im Jahre 2002 bewiesene Eric Brewers CAP-Theorem besagt, dass nur zwei der drei folgenden Eigenschaften eines verteilten Systems erfüllt sein können [4].

• Consistency: Zu jedem Zeitpunkt sehen alle Knoten denselben Datenbestand.

• Availability: Knoten können Datenbestände jederzeit schreiben und lesen.

• Kosten: Das Gros der Systeme wird als Open Source und mit wenigen Nutzungseinschränkungen zur Verfügung gestellt. Die Installation und Verwendung der Systeme ist meist unkompliziert. Zudem ist häufig ein Betrieb auf günstigen Commodity Servern möglich, da Einschränkungen bezüglich der zu verwendenen Hardware kaum vorhanden sind und geläufige Betriebssysteme unterstützt werden.

Bewertung

NoSQL-Datenspeicher sind hervorragend geeignet, um kostengünstig skalierbare und hochverfügbare Datenspeicherung und -verarbeitung in einem begrenzten Anwendungsfall bereitzustellen. Aus Sicht dieser Systeme sind die größten Hürden beim Einsatz relationaler Systeme für Web-Applikationen nicht das relationale Datenbankmodell, ACID oder gar SQL. So zeigen aktuelle Entwicklungen im Bereich relationaler Datenbanksysteme wie VoltDB 2 oder HyPer 3 , dass diese Merkmale eine lineare Skalierbarkeit nicht zwingendermaßen ausschließen. Im Zentrum der Beanstandungen stehen hingegen die Tatsachen, dass keine bewährten parallelen und hochverfügbaren Open Source RDBMS existieren und die Implementierung bewährter relationaler DBMS häufig keine hinreichende Skalierbarkeit zulässt.

Die Spezialisierung der NoSQL-Systeme auf eine wenige Anwendungsgebiet verwehrt in vielen Fällen den Einsatz bei sich ändernden Anforderungen, wie beispielsweise dem Wunsch komplexer Abfragen auf Daten bei simplen Datenmodellen. Bei der Nutzung eines relationalen DBMS wären hierbei kaum Änderungen vonnöten, während ein NoSQL-System angepasst oder gar ausgetauscht werden muss. Ein Austausch gestaltet sich zudem schwierig, da es den Systemen an standardisierten Notationen und Schnittstellen mangelt. Zudem werden statt deskriptiven Sprachen je nach Datenmodell meist Low-Level-Abfragesprachen verschiedenen 2 http://voltdb.com/ 3 http://www3.in.tum.de/research/projects/HyPer/ Komplexitäts-und Mächtigkeitsgrades genutzt, was aus Sicht des Programmierers ein Fortschritt, aus Sicht eines Datenbänklers aber durchaus als Rückschritt gesehen werden kann [2]. Insbesondere der Verzicht einiger NoSQL-Systeme auf die Gewährleistung der ACID-Eigenschaften führt dazu, dass ein Großteil von Unternehmen den Einsatz dieser Systeme ausschließen wird.

VERBINDUNG BEIDER WELTEN

Relationale Datenbanksysteme bieten aufgrund jahrelanger Forschung und Entwicklung u.a. eine enorme Verbreitung und Bekanntheit, ein ausgereiftes mathematisches Fundament, die Datenbanksprache SQL und nicht zuletzt zugesicherte Transaktionseigenschaften durch ACID. Auf der anderen Seite existieren NoSQL-Systeme, deren Verbreitung sich in der Regel auf wenige Web-Anwendungen beschränkt. Charakterisiert durch die in Abschnitt 4 zusammengefasste Eigenschaften sowie die verwendeten Konzepte, weisen sie zum Teil Zielstellungen auf, die sich deutlich von der Zielstellung klassischer relationaler Datenbanksysteme unterscheidet.

Eine Verbindung von Konzepten und Implementierungen relationaler Datenbanksysteme und NoSQL Data Stores kann dazu genutzt werden, die Vorteile beider Welten zu vereinen. Im Folgenden werden mögliche Ansätze zur Vereinigung anhand stellvertrender Beispiele vorgestellt.

Erweiterungen von NoSQL-Produkten

NoSQL-Systeme wurden in der Regel für ein spezielles Anwendungsgebiet entwickelt. Durch eine Erweiterung der Systeme kann ihr Einsatzbereich vergrößert werden, wodurch sie die Aufmerksamkeit von mehr Unternehmen auf sich ziehen können. Somit wird neben der Erweiterung der Funktionalität auch die Bekanntheit des Produkts gesteigert. Ein Beispiel für diesen Ansatz ist das Produkt Hive [17], welches das NoSQL-System Hadoop um die deskriptive, SQL-ähnliche Sprache HiveQL erweitert und Schnittstellen in Form eines CLIs, einer Web-Gui und JDBC/ODBC bietet. Zudem schafft es durch komplexe Analysen und das Absetzen von Ad-hoc-Abfragen die Voraussetzung, Hadoop für Data Warehousing zu nutzen.

Hybridsystem

Hybride Systeme wie HadoopDB [1] führen zu einem Kompromiss zwischen zwei unterschiedlichen Produktwelten und erschaffen dabei Produkte mit neuen Funktionalitäten. Das Open-Source-Produkt HadoopDB kombiniert MapReduce in Form der Implementierung Hadoops sowie Hive und Post-greSQL, wobei das System bereits mit anderen Datenbanksystemen getestet wurde. HadoopDB kann sowohl SQL-Anfragen als auch MapReduce-Jobs entgegennehmen und bietet den Zugriff auf Hadoops verteiltes Dateisystem HDFS oder alternativ auf ein Datenbanksystem wie PostgreSQL an. In der Folge sind Nutzer durch die Verwendung von Ha-doopDB in der Lage, mittels SQL auf ein Shared-Nothing-DBMS zuzugreifen.

Anpassung von RDBMS

Der Abschnitt 4 verdeutlicht, dass die bewährten fundamentalen Konzepte hinter dem relationalen Datenbankmodell mit Anforderungen wie enormer Skalierbarkeit vereinbar sind, es hierzu jedoch einer Anpassung der von System R abstammenden Architektur bedarf. Die Implementierungen von DBMS müssen sich durch geeignete Konfigurationsmöglichkeiten weit mehr als bisher an verschiedene Einsatzzwecke anpassen lassen. Realisiert werden kann dies beispielsweise durch die Ausnutzung der Austauschbarkeit von Komponenten in modularen DBMS-Architekturen wie [7] oder die Implementierung von adaptierbaren DBMS-Komponenten.

Ein möglicher Ansatzpunkt dieses Konzepts könnte das Anbieten einer wahlweisen Speicherung auf langsamen, persistenten Festspeichern oder im schnellen, flüchtigen Arbeitsspeicher oder einer kombinierten Lösung sein, was bereits in einigen Systemen wie dem in Abschnitt 3.