Zehntausende Web-Services verwenden relationale Datenbanken, um Daten zu speichern und auszulesen. Im Vergleich zu modernen Konzepten können relationale Datenbanken als wichtigster Stellvertreter für traditionelle Technologien'' bezeichnet werden. Wenn man als Entwickler zu Seiten wie Google.com, Facebook.com, Amazon.com, Digg.com, Ebay.com, Yahoo.com, Twitter.com oder Dawanda.com surft, wird meist angenommen, dass eine verteilte relationale Datenbank verwendet wird. Die Annahme ist zu 50% richtig, jedoch ist die Datenhaltung meist nicht relational. Diese Großunternehmen verwalten mehrere hundert Gigabytes, bis hin zu 100.000 Gigabyte an Daten, und mussten in den letzten sechs Jahren Lösungen finden, um erfolgreich diese riesigen Datenmengen zu beherrschen. Google erfand vor ca. sieben Jahren ein Verfahren, um Datenmengen im Petabytebereich zu beherrschen. Facebook entwickelte selbst eine Datenbanktechnologie, um die Posteingänge von Benutzern verfügbar zu machen, Twitter.com adaptiert diese Technologie für andere Zwecke. Amazon.com entwickelte Dynamo'', um Hochverfügbarkeit für deren weltgrößte E-Commerce Plattform zu schaffen. Diese und andere Eigenentwicklungen entstanden aus der Notwendigkeit heraus, riesige Datenmengen bzw. Datenbanken hoch verfügbar, konsistent und skalierbar zu machen. Seit den letzten drei Jahren sind alternative Open-Source-Implementierungen'' dieser Entwicklungen entstanden. Die Veröffentlichung der Konzepte und Technologien führten zu einer ganzen Bewegung namens NoSQL''. Sind diese Konzepte vorteilhafter, um eine bessere und für Entwickler einfachere Skalierung, Abfragemöglichkeit und Datenkonsistenz in einem hochverfügbaren Datenbanksystem, zu gewährleisten? Wie werden komplexe Abfragen in modernen und traditionellen verteilten Systemen gemacht und wie werden diese ausgeführt? Speziell stellt sich die Frage, ob das MapReduce Verfahren ein vollständiger Ersatz für SQL ist. Für welche Einsatzzwecke sind beide besonders gut geeignet und für welche weniger? Ausgewählte Konzepte moderner, verteilter Datenbanksysteme sind zentrale Bestandteile dieser Arbeit. Dazu werden die Eigenschaften Verfügbarkeit, Konsistenz und Skalierbarkeit in den verteilten Systemen ausführlicher beschrieben, um zu analysieren, ob gegenüber relationalen Datenbanken Vorteile und Nachteile dieser Eigenschaften existieren. Ergebnisse dieser Aufgabenstellung sollen Chancen und Risiken von modernen Datenbanken aufdecken. Key-Value-Stores sind die einfachsten Vertreter moderner Datenbanken. Riak'' wird in dieser Arbeit als Implementierung moderner Konzepte benutzt. MySQL'' soll als Vertreter für relationale Datenbanken verwendet werden da dieser Vertreter eine weit verbreitete Open-Source-Implementierung von relationalen Datenbanken ist. Andere Datenbankkonzepte/Datenbanken werden in dieser Arbeit nicht behandelt. Dazu zählen unter anderem objektorientierte, objektrelationale, hierarchische, spaltenorientierte und graphenorientierte Datenbankformen, sowie Repräsentanten von relationalen Datenbanken, wie db2'', Sybase'' oder Oracle'', da diese nicht Open-Source sind. Das konsistente Hashfunktionsverfahren wird zuerst kurz erläutert, um theoretische Grundlagen für die Implementierung moderner und traditioneller Skalierungsmethoden zu legen. Danach werden, im Kontext moderner Datenbanktechnologien, wichtige theoretische Konzepte zur Skalierung erläutert. Dazu werden die drei wichtigsten Eigenschaften verteilter Systeme definiert und in Zusammenhang gebracht (Verfügbarkeit, Konsistenz und Partitionstoleranz). Dementsprechend wird das Prinzip letztendliche Konsistenz'' vorgestellt, welches eine zentrale Rolle bei modernen verteilten Systemen darstellt. Weiterhin wird das MapReduce-Verfahren konzeptionell vorgestellt. Es wird aus zwei Perspektiven betrachtet: Filterung von Daten durch benutzerdefinierte Funktionen anhand eines Beispiels und in diesem Zusammenhang die Ausführung des Verfahrens in verteilten Systemen. Implementierungen dieser theoretischen Ansätze werden in diesem Kapitel aufgelistet. Eine detaillierte Beschreibung von Key-Value-Stores'' (KVS) wird im nächsten Kapitel bereitgestellt. KVS sind die einfachste Form von modernen Datenbanken, an denen sich die grundlegenden Konzepte abstrakt beschreiben lassen. Riak'' ist ein wichtiger Vertreter für moderne Datenbanken und KVS. Die theoretischen Grundlagen der drei zentralen Eigenschaften verteilter System werden an dieser direkten Implementierung gefestigt und erweitert. Dem folgt eine kurze Vorstellung von relationalen Datenbanken. Dabei wird ausschließlich auf Möglichkeiten zur Skalierung eingegangen. Im letzten Kapitel werden zuerst beide Datenbanktechnologien hinsichtlich der Skalierung, Konsistenz, Verfügbarkeit und Komplexität verglichen. Weiterhin findet ein Vergleich zwischen MapReduce und SQL bzw. benutzerdefinierten Funktionen'' anhand von Einsatzmöglichkeiten, Stabilität und Komplexität statt. Der Vergleich von MySQL und Riak erfolgt durch eine Analyse der Abfragemöglichkeiten mittels Stored Procedures und MapReduce anhand mehrerer Beispiele. Hierbei sollen die zentralen Fragestellungen beantwortet werden. Abschließend werden die Ergebnisse zusammengefasst und bewertet.

Textprobe: Kapitel 2.2, Brewer’s Theorem und ‘letztendliche Konsistenz’: Letztendliche Konsistenz ist dann von großer Bedeutung, wenn ein hochverfügbarer Datenbankservice bereitgestellt werden soll. Wenn die Daten in einem verteilten System redundant gespeichert sind und es eine Verzögerung bei der asynchronen Replikation gibt, dann ist es möglich, dass eine Anfrage an eine dieser Replikationen einen nicht aktuellen Wert zurückliefert. Welche Chancen und Risiken bietet letztendliche Konsistenz bei genau diesem Szenario? Wenn ein System starke Konsistenz unterstützt, dann wird der geschriebene Wert garantiert zurückgegeben. Bei einer schwachen Konsistenz wird dies nicht garantiert. Dann ist es nicht vorhersehbar, wann eindeutig der veränderte Wert von jedem Knoten ausgegeben wird. ‘Die letztendliche Konsistenz ist eine Form von schwacher Konsistenz, bei welcher das Datenbanksystem garantiert, dass, wenn keine weiteren Veränderungen an dem Objekt vorgenommen werden, das System letztendlich und von jeder Serverinstanz den richtigen Wert zurückgibt.’ Wenn kein Fehler auftritt kann die Zeit, bis das System einen konsistenten Zustand erreicht hat, bestimmt werden. Das erfolgt anhand Eigenschaften wie Kommunikationsverzögerungen, Systemlast und Anzahl der Serverinstanzen. Eines der berühmtesten Systeme dieser Art ist z.B. das Domain Name System (DNS). Welche Möglichkeiten existieren, um mit inkonsistenten Verhalten umzugehen? Wenn ein Algorithmus einen Wert schreibt, dann muss es Möglich sein, dass dieser Prozess auch den veränderten Wert wieder zurückgibt und niemals den alten (‘lies-was-du-schreibst (RYW-)Konsistenz’. In Kapitel 3.4 wird die RYW-Konsistenz näher beschrieben. Praktisch kann dies mit ‘Session-Konsistenz’ umgesetzt werden. Ein Prozess greift innerhalb einer Sitzung auf die Datenbank zu. Solange die Sitzung existiert, wird die ‘RYW-Konsistenz” garantiert. Wenn diese Sitzung aufgrund eines Fehlers terminiert, dann wird eine neue Sitzung eröffnet, welche keine Überlappungen mit anderen Sitzungen garantiert. Durch eine Versionierung der Datensätze ist eine ‘Monotonic read consistency’ gleichbleibende Lese-Konsistenz) möglich, hierbei gibt ein Prozess immer die letzte Version eines Wertes zurück, niemals einen älteren. Bei einer gleichbleibenden Schreib-Konsistenz ‘Monotonic write consistency’ wird garantiert, dass ein Prozess, welcher eine Serialisierung vornehmen soll, diese auch eigenständig durchführt und kein anderer. ‘Viele dieser Eigenschaften können kombiniert werden, z.B. ‘gleichbleibende Lese- mit sitzungsbasierter Konsistenz’. Aus praktischer Sicht sind ‘gleichbleibende-Lese-Konsistenz’ und ‘RYW Konsistenz’ die wichtigsten Vertreter in einem ‘letztendliche Konsistenz’-System.’. Diese zwei Prinzipien machen es für Entwickler einfacher, Applikationen zu entwickeln. Die Datenbank kann ihre Konsistenz aufweichen und hohe Verfügbarkeit bieten. Es gibt viele verschiedene Szenarios und Kombinationen, die auf unterschiedliche Anwendungen zugeschnitten sein können. An Kompromissen führt jedoch kein Weg vorbei. Inkonsistenz muss bei verteilten Systemen akzeptiert werden. Die Lese- und Schreibgeschwindigkeit ist unter hoch konkurrierenden Bedingungen, zu langsam. Partitionstoleranz kann aufgrund der Fehlertoleranz entscheidend dazu beitragen. Ob diese Kompromisse gemacht werden können, hängt stark von der jeweiligen Applikation ab. In jedem Fall muss sich der Entwickler darüber im Klaren sein, dass diese Konsistenzansprüche von der Datenbank ausgehen und diese bei einer Entwicklung beachten. ‘Verbesserungen wie ‘sitzungsbasierende Konsistenz’ oder ‘gleichbleibende Lese-Konsistenz’ geben dem Entwickler bessere Werkzeuge, um mit ‘letztendlicher Konsistenz’ zu arbeiten.’ Ein bestimmter Fall beschreibt eine Webseite, bei der die Absicht besteht, dem Benutzer eine von ihm akzeptierte Konsistenz zu gewährleisten. Dabei muss das ‘inkonsistente Zeitfenster’ kleiner sein als das zu erwartende ‘Neuladen’ der Seite sein. Dabei kann eine Konsistenz hergestellt werden, bevor ein neuer Lesezugriff höchstwahrscheinlich erfolgt. Wenn z.B. ein Facebookbenutzer eine Nachricht an jemand schreibt, dann kann die Nachricht im ‘Browser-Speicher’ (Javascript) zwischengespeichert werden, bis diese Nachricht in der Datenbank persistent gemacht wurde. Die gesendete Nachricht erscheint vorrübergehend im Postausgang, doch ist sie noch nicht ‘gespeichert’ und an den Empfänger übermittelt. Die kurze Zeitspanne erlaubt es der asynchronen Verteilung dem Benutzer ein jederzeit konsistenten Service zu simulieren, bis die Speicherung in einem ‘letztendliche Konsistenz System’ wirklich erfolgt ist. Der Web-Service einer Bank, um z.B. Überweisungstransaktionen durchzuführen, benötigt eine starke Konsistenz. Angenommen es befindet sich eine relationale Datenbank auf dem Server, ‘dann verbringt die Datenbank mehr Zeit damit zu entscheiden, auf welchen Server geschrieben werden soll und in welcher Reihenfolge der Bearbeitungsprozess stattfindet als mit dem eigentlichen Schreibprozess.’ Der Service in einem verteilten System ist dann nicht verfügbar. Dieser Kompromiss muss für diese Art von Web-Service akzeptiert werden. Ein Webshop führt keine Geldtransfers durch, der Kompromiss, die ‘Verfügbarkeit einzuschränken’, kann nicht gemacht werden, denn in der Zeit können andere Kunden keine Artikel bestellen. Bei einem hochfrequentierten Webshop entstehen sonst Umsatzeinbußen. ‘Es wird akzeptiert, dass, wenn zwei Kunden denselben Artikel bestellen, einer davon eine nachträgliche Stornierung erhält.’ Wenn z.B. zwei Kunden bei einem Webshop denselben Artikel bestellen und nur ein einziger verfügbar ist, dann bekommt der Käufer, der vielleicht nur eine Sekunde später auf ‘Bestellen’ geklickt hat eine Stornierung. Das ist ein Kompromiss um Verfügbarkeit gegenüber Konsistenz vorzuziehen. Vorsorglich kann die Lieferzeit verändert werden, wenn nur noch wenige Bestände von einem Artikel vorhanden sind. Wenn zwei Kunden sich gegenseitig ‘kongruieren’, dann freut sich der eine Kunde, weil er den Artikel sofort zugeschickt bekommt und der andere weiß von der langen Wartezeit im Voraus. Wenn die Zeitspanne, bis eine Konsistenz letztendlich wieder erreicht ist, gering bleibt, dann gehen viele diesen Kompromiss ein und akzeptieren eine vorübergehende Inkonsistenz. Amazon behauptet, dass ‘nur eine Steigerung der Antwortlatenz um 0.1 einen Umsatzrückgang von 1% nach sich zieht’. Google sagt aus, dass ‘eine Suchergebnisliste, welche nur 0.5 Sekunden zu spät ausgeliefert wird, einen Datendurchsatzrückgang von 0.2 % nach sich zieht.’

• nosql

• riak

• mapreduce

• consistent hashing

• eventually consistent

• Datenbank

• Datenbankabfrage

Nils M. Petersohn B.Sc., wurde 1983 in Leipzig geboren. Bereits während des Abiturs belegte der Autor zahlreiche Ihm in Deutschland und in Amerika verfügbaren Informatikkurse. Das Studium der Wirtschaftsinformatik befriedigte seine Wissbegierde nicht und er entschied sich, zu einem Studium der reinen Informatik, welches er im Herbst 2010 erfolgreich beendete. Mehr als ein Dutzend industrieller Softwareprojekte prägten seinen Erfahrungsschatz ausgiebig während des Studiums. So entstanden in den letzten 4-5 Jahren mehrere geschäftskritische Anwendungen die u.a. auf performante Datenhaltung basieren.