Einsatz von NoSQL-Datenbanken in modernen Webapplikationen Masterthesis

Transkript

1 Einsatz von NoSQL-Datenbanken in modernen Webapplikationen Masterthesis Medien und Kommunikation vorgelegt von: Andreas Hofstetter Abgabedatum: Erstbetreuer: Zweitbetreuer: Prof. Dr. Volker Sänger Prof. Dr. Tom Rüdebusch

2 Inhaltsverzeichnis Inhaltsverzeichnis 1. Einleitung 5 2. Grundlagen relationaler Datenbanken Relationales Datenmodell Normalisierung SQL Transaktionen Grundlegende Techniken und Theorien Skalierung CAP-Theorem BASE REST Map/Reduce NoSQL-Konzepte Key-Value-Datenbanken Redis Datenmodell Schnittstellen Dokumentenorientierte Datenbanken CouchDB Datenmodell Schnittstellen Spaltenorientierte Datenbanken HBase Datenschema Andreas Hofstetter Masterthesis 2011/12 1

3 Inhaltsverzeichnis Schnittstellen Graphendatenbanken Neo4j Datenmodell Schnittstellen Einsatz in Web-Applikationen Funktionen Benutzerverwaltung Profil Livesearch Freundschaften Pinnwand Implementierung mit MySQL Datenschema Redis Datenschema Benutzerverwaltung Authentifizierung Livesearch Friends Profil Pinnwand Fazit CouchDB Datenschema Benutzerverwaltung Authentifizierung Livesearch Friends Profil Pinnwand Fazit Andreas Hofstetter Masterthesis 2011/12 2

4 Inhaltsverzeichnis 5.5. HBase Datenschema Benutzerverwaltung Authentifizierung Livesearch Friends Profil Pinnwand Fazit Neo4J Datenschema Benutzerverwaltung Authentifizierung Livesearch Friends Profil Pinnwand Fazit Fazit 109 Abkürzungsverzeichnis Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Quellcodeverzeichnis Eidesstattliche Erklärung I II VII VIII IX XIII A. Anhang i A.1. Social_Rest A.2. Social_CouchDB i iv Andreas Hofstetter Masterthesis 2011/12 3

5 Inhaltsverzeichnis A.3. Social_Redis A.4. Social_HBase A.5. Social_Neo4j v x xii Andreas Hofstetter Masterthesis 2011/12 4

6 1. Einleitung 1. Einleitung Unter NoSQL versteht man eine Sammlung von Technologien und Konzepten, welche sich von dem traditionellen Konzept der relationalen Datenbank in unterschiedlichen Weisen abgrenzen. Frühere Deutungen des Namens wurden als kein SQL interpretiert, wobei die Abfragesprache SQL stellvertretend für das relationale Datenbankkonzept als solches gesehen werden soll. Später wurde jedoch die Bezeichnung Not Only SQL (nicht nur SQL) verbreiteter, da auch in NoSQL- Technologien teilweise relationale Konzepte implementiert wurden. Einige der unter NoSQL fallenden Konzepte sind weitaus älter als der Begriff NoSQL selbst, rückten jedoch erst mit dem steigenden Interesse an alternativen Datenbanksystemen ins Rampenlicht. [Edlich11] Populär wurde diese Bewegung unter anderem durch den stetigen Wandel der Anforderungen an Webanwendungen, welche relationale Datenbanken wie MySQL oder Oracle Database nicht mehr ausreichend erfüllen können. Die Social Media Plattform Facebook hat beispielsweise nach eigenen Angaben über 800 Millionen aktive Benutzer [Facebook12], welche täglich vier Terabyte an Daten produzieren[fondermann10]. Diese wachsende Zahl an Zugriffen und die immer größer werdenden Datenmengen zwangen populäre Anbieter verschiedener Webangebote eigene Lösungen zu entwickeln, um den speziellen Anforderungen gerecht werden zu können. So entwickelten zum Beispiel Google das spaltenorientierte Datenbank-Management-System (DBMS) Big Table und Facebook Cassandra um ihre Dienste weiterhin anbieten zu können. Mit dieser Arbeit soll der praktische Einsatz von NoSQL-Systemen erläutert und die Stärken und Schwächen der jeweiligen Konzepte aufgezeigt werden. Dadurch soll erkenntlich gemacht werden, für welchen Anwendungsfall sich ein bestimmtes Andreas Hofstetter Masterthesis 2011/12 5

7 1. Einleitung Konzept eignet und welche Position es im Vergleich zum relationalen Datenbankkonzept annimmt. Zu Beginn soll eine Einweisung in die Grundlagen von relationalen Datenbanken gegeben werden, um die für die anschließende Ausarbeitung notwendigen Begriffe verständlich zu machen. Darauf folgend wird der Begriff NoSQL genauer erklärt und es werden grundlegende Technologien vorgestellt, welche im NoSQL-Umfeld eingesetzt werden. Im weiteren Verlauf werden die vier verbreitetsten Konzepte erläutert und jeweils ein Vertreter vorgestellt. Hier soll die Arbeitsweise und die Einsatzgebiete der Datenbank-Management-Systemen aufgezeigt werden. Abschließend wird auf den Einsatz von NoSQL-Datenbanken in einer modernen Webapplikation eingegangen. Hierzu wird zunächst eine Social-Media-Plattform auf Basis von PHP und MySQL entwickelt. In den darauf folgenden Kapiteln werden dann schrittweise einzelne Funktionen mit Vertretern von NoSQL umgesetzt. Dadurch soll anhand eines konkreten Beispiels der Einsatz in Webanwendungen gezeigt und zu relationalen Datenbanken abgegrenzt werden. Andreas Hofstetter Masterthesis 2011/12 6

8 2. Grundlagen relationaler Datenbanken 2. Grundlagen relationaler Datenbanken Bevor auf die Besonderheiten der verschiedenen NoSQL-Datenbanken eingegangen werden kann, sollen kurz die grundlegenden Eigenschaften von herkömmlichen relationalen Datenbanksystemen erläutert werden. Dazu soll zunächst das relationale Datenmodell gezeigt werden. Anschließend wird auf einen der wichtigsten Mechanismen relationaler Datenbanken, die Transaktion, sowie auf die systemübergreifende Datenbanksprache SQL eingegangen. Im folgenden Abschnitt werden nicht sämtliche Eigenschaften relationaler Datenbanken behandelt. Es wird lediglich auf Punkte eingegangen, die für die anschließende Gegenüberstellung mit NoSQL-Systemen relevant sind Relationales Datenmodell Durch ein Datenmodell werden Daten und deren Beziehungen untereinander auf strukturierte und formale Weise beschrieben. [Meier10] Relationale Datenbanksysteme basieren auf einem 1970 von E.F. Codd [Codd70] entwickelten Konzept, welches mit den Zielen entwickelt wurde, eine Datenunabhängigkeit zu gewährleisten und Redundanz zu vermeiden. Nach diesem Konzept werden die zu speichernden Informationen als mathematische Relationen beschrieben. Eine Datenbank setzt sich aus einer Menge von Relationen zusammen. Darstellen lässt sich eine Relation in Form einer Tabelle. Eine Zeile entspricht einem realen Objekt oder Konzept, wie beispielsweise einer Person oder deren Adresse. Jede Spalte repräsentiert einen bestimmten Datenwert, wobei alle Werte einer Spalte den gleichen Datentyp besitzen müssen. Für Andreas Hofstetter Masterthesis 2011/12 7

9 2. Grundlagen relationaler Datenbanken das Beispiel einer Personen-Relation können das zum Beispiel der Name, das Alter oder das Geschlecht einer Person sein. Im relationalen Modell wird eine Zeile auch als Tupel und eine Spalte als Attribut bezeichnet. Beschreiben lässt sich eine Relation durch ein Relationsschema. Ein Relationsschema besteht jeweils aus seinem Relationsnamen und einer Liste von Attributen. Listing 2.1 zeigt das Relationsschema für eine Personen-Relation. In Tabelle 2.1 wird die Relation entsprechend als Tabelle dargestellt.[elmasri09] Listing 2.1: Beispiel eines Relationsschemas 1 PERSON (Name, Geschlecht, Alter) ID Name Geschlecht Alter 1 Hans Hauser männlich 44 2 Manuela Müller weiblich 23 3 Kathrin Koch weiblich 35 Tabelle 2.1.: Darstellung einer Relation als Tabelle Beziehungen werden durch Referenzen zwischen zwei Relationen abgebildet. Um eine Referenz abzubilden, werden Primär- und Fremdschlüssel verwendet. Ein Primärschlüssel ist eine Menge von Attributen, durch die ein Tupel eindeutig identifiziert werden kann. Die Attribute werden in der Darstellung gekennzeichnet, indem der Spaltenname unterstrichen wird. Fremdschlüssel sind Attribute, welche den Primärschlüssel einer anderen Relation beinhalten. Dabei existieren drei verschiedene Typen von Beziehungen. Diese werden als 1:1-, 1:n- und n:m-beziehungen bezeichnet. Bei einer 1:1-Beziehung ist jeder Datensatz mit genau einem anderen Datensatz verbunden. 1:n bedeutet, dass ein bestimmter Datensatz mit beliebig vielen anderen Datensätzen verbunden ist. Bei n:m-beziehungen kann jeder Datensatz mit beliebig vielen anderen Datensätzen verbunden sein. Anders als bei einer 1:n-Beziehung kann allerdings der referenzierte Datensatz ebenfalls beliebige weitere Beziehungen zu anderen Datensätzen aufweisen. [Elmasri09] Andreas Hofstetter Masterthesis 2011/12 8

10 2. Grundlagen relationaler Datenbanken 2.2. Normalisierung Ein Hauptziel des relationalen Datenmodells liegt in der Vermeidung von Redundanzen, also dem mehrfachen Vorkommen eines Inhaltes. Um dies zu erreichen wird ein Datenschema normalisiert, indem die Tabellenstruktur der Datenbank optimiert wird. Der Grund, warum Redundanzen vermieden werden sollten, liegt im daraus resultierenden höheren Wartungsaufwand und der Fehleranfälligkeit. Bei Änderungen eines Datensatzes müssten an mehreren Stellen Änderungen vorgenommen werden. Dies birgt die Gefahr, dass nicht alle benötigten Änderungen berücksichtigt werden und so Anomalien im Datenbestand auftreten können. In Tabelle 2.2 wird die resultierende Redundanz in einer nicht normalisierten Tabelle gezeigt. In diesem Beispiel wird Tabelle 2.1 erweitert, um zusätzlich Telefonnummern abspeichern zu können. Da jede Person mehrere Telefonnummern besitzen kann, muss für jede Nummer ein eigener Datensatz angelegt werden. Dadurch kommen die Attribute Name, Geschlecht und Alter mehrfach für eine Person vor. ID Name Geschlecht Alter Typ Telefonnummer 1 Hans Hauser Männlich 44 Mobil Hans Hauser Männlich 44 Festnetz Manuela Müller Weiblich 23 Geschäftlich Manuela Müller Weiblich 23 Festnetz Kathrin Koch Weiblich 35 Festnetz Tabelle 2.2.: Nicht normalisierte Tabelle Um dies zu umgehen, werden die Telefonnummern in eine separate Tabelle ausgelagert. Tabelle 2.3 zeigt dieses Szenario. Sie enthält das Attribut person, welches den Primärschlüssel einer Person beinhaltet. Es handelt sich demnach um einen Fremdschlüssel, mit dessen Hilfe eine 1-n-Beziehung zur Tabelle personen hergestellt wird. Person Typ Nummer 1 Mobil Festnetz Geschäftlich Festnetz Festnetz Tabelle 2.3.: Separate Tabelle mit Telefonnummern Andreas Hofstetter Masterthesis 2011/12 9

11 2. Grundlagen relationaler Datenbanken Die Normalisierung bringt jedoch auch Nachteile mit sich. Das Datenschema wird komplexer und somit auch das Abfragen der gespeicherten Daten. Da zusammengehörende Inhalte auf mehrere Tabellen verteilt abgelegt werden, müssen diese bei einer Abfrage wieder verbunden werden. Man spricht hierbei von Joins. Gerade bei Datenbanken mit hohem Datenaufkommen - was bei Webanwendungen häufig der Fall ist - führt dies zu inakzeptablen Reaktionszeiten. Daher wird in der Praxis oft gezielt denormalisiert, also bewusst Redundanz hinzugefügt, um performantere Abfragen zu ermöglichen. [Geisler09] 2.3. SQL Eine der Stärken von relationalen Datenbanksystemen liegt in der standardisierten Datenbanksprache SQL. Diese bildet die Schnittstelle zu einer relationalen Datenbank und ermöglicht sämtliche Operationen, von der Administration bis hin zur Abfrage der Daten. Die meisten RDBMS verwenden abweichende Dialekte des Standards, indem der ANSI-Standard oft um zusätzliche proprietäre Funktionen erweitert wird. Dennoch bleibt die Basis der Dialekte identisch. So ist es beispielsweise möglich eine Anwendung, welche für Microsoft SQL Server entwickelt wurde, mit wenigen bis keinen Änderungen auf ein anderes RDBMS wie zum Beispiel Oracle Database zu portieren. Listing 2.2 zeigt eine Abfrage zu dem oben genannten Beispiel mit Personendaten. Bei dieser Abfrage wird in der ersten Zeile notiert, dass der Name und das Alter ausgegeben werden sollen. Mit FROM wird die gewünschte Tabelle ausgewählt. In diesem Beispiel ist dies die Tabelle person. Soll sich die Abfrage über mehrere Tabellen erstrecken, können hier kommagetrennt weitere Tabellennamen angegeben werden. Mit der letzten Zeile werden die Datensätze anhand einer Bedingung gefiltert. Mit der Bedingung in diesem Beispiel sollen nur weibliche Personen berücksichtigt werden. Andreas Hofstetter Masterthesis 2011/12 10

12 2. Grundlagen relationaler Datenbanken Listing 2.2: Name und Alter aller weiblichen Personen 1 SELECT name, alter 2 FROM personen 3 WHERE geschlecht = "weiblich"; Wie bereits erwähnt werden in relationalen Datenbanken die Daten in verschiedenen Tabellen gespeichert, welche über Relationen miteinander verbunden sind. Häufig ist es der Fall, dass nicht nur die Daten einer einzelnen Tabelle abgefragt werden sollen, sondern dass auch dazugehörende Informationen mit ausgegeben werden müssen. Dazu behilft man sich in SQL mit Joins. Ein Join löst die Beziehungen mehrerer Tabellen mit Hilfe der Primär- und Fremdschlüssel auf und erzeugt so ein einheitliches Ergebnis. Listing 2.3 zeigt ein einfaches Beispiel eines Joins über zwei Tabellen. Hier werden die Tabellen personen und telefon miteinander verbunden und alle Telefonnummern zusammen mit den jeweiligen Namen ausgegeben. Listing 2.3: Join über zwei Tabellen 1 SELECT personen.name, telefon.nummer 2 FROM personen, telefon 3 WHERE personen.id = telefon.person; Neben dem einfachen Ausgeben von Daten ermöglicht SQL noch zusätzlich Funktionen, um Daten vor der Ausgabe zu transformieren. Dazu gehören unter anderem Stringfunktionen, die es ermöglichen die Ausgabe zusätzlich zu formatieren, sowie Aggregatfunktionen, die Berechnungen über eine Datenmenge durchführen können. Listing 2.4 zeigt den Einsatz der Aggregatfunktion avg(), welche den Durchschnitt einer Ergebnismenge ermittelt. In diesem Beispiel wird das Durchschnittsalter aller Personen in der Datenbank ausgegeben. Listing 2.4: Ausgabe des Durchschnittsalters aller Personen 1 SELECT avg(alter) 2 FROM personen; Der Vorteil dieser Datenbanksprache liegt in ihrer Flexibilität. Anfragen können nach Bedarf erstellt werden. Bei der Erstellung des Schemas muss also nicht be- Andreas Hofstetter Masterthesis 2011/12 11

13 2. Grundlagen relationaler Datenbanken rücksichtigt werden, wie die Daten später abgefragt werden. Man spricht hier auch von Ad-Hoc-Abfragen. [Elmasri09] 2.4. Transaktionen Die Transaktion ist eine Kernfunktion der meisten DBMS. Dabei handelt es sich um das Zusammenfassen von SQL-Statements zu einer logischen Verarbeitungseinheit. Ziel ist es, Nebenläufigkeitsprobleme wie inkonsistente Datenbestände durch konkurrierende Zugriffe zu verhindern Gerade bei Webanwendungen greifen viele Benutzer gleichzeitig auf die Anwendung zu, wodurch häufig konkurrierende Schreib- und Lesezugriffe auf einen bestimmten Datensatz erfolgen können. Dies kann zu falschen Resultaten und Inkonsistenzen in der Datenbanken führen. In RDBMS weisen Transaktionen vier grundlegende Eigenschaften auf, welche durch das Akronym ACID zusammengefasst werden. ACID steht für Atomacity (Atomarität), Consistency (Konsistenz), Isolation (Isolation) und Durability (Dauerhaftigkeit). Atomacity Atomarität bedeutet, dass sämtliche Operationen durchgeführt werden müssen. Tritt ein Fehler bei einer Teiloperation auf, muss die gesamte Transaktion abgebrochen und bereits durchgeführte Operationen rückgängig gemacht werden. Consistency Nach Beendigung der Transaktion muss in der Datenbank ein konsistenter Zustand herrschen. Das heißt, dass alle anschließenden Operationen auf einem Datensatz ausschließlich den aktuellen Stand erhalten dürfen. Isolation Parallel ablaufende Transaktionen dürfen sich nicht gegenseitig beeinflussen. Wird innerhalb einer Transaktion ein Datensatz verändert kann keine andere Transaktion darauf zugreifen, bis die erste Transaktion beendet ist. Andreas Hofstetter Masterthesis 2011/12 12

14 2. Grundlagen relationaler Datenbanken Durability Wenn eine Transaktion erfolgreich abgeschlossen wird, werden sämtliche betroffene Daten dauerhaft in der Datenbank gespeichert. [Elmasri09] Andreas Hofstetter Masterthesis 2011/12 13

15 3. Grundlegende Techniken und Theorien 3. Grundlegende Techniken und Theorien Im folgenden Kapitel werden Techniken und Konzepte vorgestellt, welche häufig im NoSQL-Umfeld eingesetzt werden und dessen Verständnis für den Einsatz von NoSQL-Systemen relevant sind. Die vorgestellten Komponenten werden nicht ausschließlich im NoSQL-Bereich eingesetzt und sind teilweise auch in relationalen Datenbanksystemen zu finden Skalierung Ist eine Anwendung erfolgreich, steigen auch die Zugriffszahlen und somit der Ressourcenbedarf der Hardware. Wie sich die Anwendung auf den veränderten Ressourcenverbrauch anpassen lässt, wird durch die Skalierung beschrieben. Es werden zwei grundlegende Methoden der Skalierung unterschieden - die vertikale Skalierung und die horizontale Skalierung. Beim vertikalen Skalieren, auch Scale-up bezeichnet, wird der steigenden Hardwareanforderung entgegengewirkt, indem die vorhandene Hardware aufgerüstet oder durch leistungsstärkere Server ersetzt wird. Beim horizontalen Skalieren oder Scale-down wird die Gesamtlast auf mehrere Instanzen verteilt. Steigt die Last, werden zusätzliche Server in den vorhandenen Rechenclustern hinzugefügt um den Anstieg auszugleichen. Aus wirtschaftlicher Sicht ist die horizontale Variante vorzuziehen. So kann mit kostengünstiger Hardware das Unternehmen gestartet werden und bei Erfolg mit weiteren günstigen Servern erweitert werden. Außerdem können die Ressourcen so nahezu beliebig an die Anforderungen angepasst werden. Bei einer vertikalen Skalierung hingegen wird auch mit modernster Technik irgendwann die Grenze des technisch Möglichen in Bezug auf Speicherplatz, RAM oder CPU erreicht. Andreas Hofstetter Masterthesis 2011/12 14

16 3. Grundlegende Techniken und Theorien Um wirtschaftlich auf steigende Anforderungen reagieren zu können, muss demnach die einzelne Datenbankinstanz zu einem verteilten System werden. Mit einigen RDBMS ist es möglich einzelne Instanzen zu replizieren oder den gesamten Datenbestand auf mehrere Instanzen zu verteilen. Allerdings ist dies nur mit erheblichen Anpassungen in der Anwendung möglich. Zusätzlich sind einige grundlegende Funktionen wie die Transaktionssicherheit oder die Möglichkeit, SQL- Abfragen über mehrere Tabellen durchzuführen, nicht oder nur eingeschränkt möglich. [Otto12] 3.2. CAP-Theorem Wie bereits erwähnt liegt eine der Hauptanforderungen relationaler Datenbanksysteme in der Gewährleistung der Konsistenz. In Unternehmungen mit geschäftskritischen Daten, wie es beispielsweise im Bankenwesen der Fall ist, ist dies auch unbedingt erforderlich. Problematisch wird diese Anforderung allerdings, wenn die anfallende Datenmenge eine Größe erreicht, in der eine horizontale Skalierung nicht mehr abzuwenden ist. Die Gewährleistung der Konsistenz über mehrere verteilte Datenbankinstanzen hinweg, ist mit relationalen System in der Praxis mit erheblichem Wartungs- und Entwicklungsaufwand verbunden. Zusätzlich erreicht so die Reaktionszeit des Systems einen Wert, der für Webanwendungen in einem nicht mehr akzeptablen Bereich liegt. Über dieses Problem berichtete Eric Brewer im Jahr 2000 in seinem Vortrag Towards Robust Distributed Systems über seine Forschungen mit verteilten Systemen. [Brewer00] Das Ergebnis der Forschung zeigt, dass in verteilten Anwendungen drei konkurrierende Ziele existieren. Die Konsistenz (Consistency), Verfügbarkeit (Availability) und Ausfalltoleranz (Partition Tolerance). Consistency Eine verteilte Datenbank, welche dieser Anforderung entspricht, besitzt nach dem Abschluss einer Transaktion einen konsistenten Zustand in allen Teilknoten des verteilten Systems. Das bedeutet, dass, sobald eine Instanz einen Schreibzugriff durchführt, alle anderen Instanzen anschließend auf diesen neuen Wert zugreifen Andreas Hofstetter Masterthesis 2011/12 15

17 3. Grundlegende Techniken und Theorien Abbildung 3.1.: Kriterien des CAP-Theorems Quelle: Eigene Anfertigung nach [CouchDBDoku] müssen. Dies hat zur Folge, dass nach Schreibzugriffen alle Clusterknoten aktualisiert werden müssen, bevor weitere Zugriffe auf die geänderten Ressourcen möglich sind. Mit wachsender Clustergröße und Anzahl an Zugriffen führt dies zu einem Anstieg der anfallenden Last und der Reaktionszeit. Availability Mit Verfügbarkeit ist die Reaktionszeit der Anwendung gemeint. Ob eine Anwendung im Sinne des CAP-Theorems als verfügbar einzuordnen ist, hängt davon ab, ob die Reaktionszeit in einem vom Benutzer akzeptierbaren Bereich liegt. Inwieweit eine Reaktionszeit akzeptiert wird, hängt von der Art der Anwendung und dem anzusprechenden Anwenderkreis ab. Partition Tolerance Die Ausfalltoleranz beschreibt das Verhalten der verteilten Anwendung, falls ein Knoten oder die Verbindung zwischen zwei Knoten ausfällt. Ist eine Anwendung ausfalltolerant, darf ein solcher Vorfall nicht zum kompletten Ausfall des Systems führen. [Edlich11] Andreas Hofstetter Masterthesis 2011/12 16

18 3. Grundlegende Techniken und Theorien Nach dem CAP-Theorem kann eine verteilte Anwendung lediglich zwei dieser konkurrierenden Ziele einhalten. Wie in Abbildung 3.1 dargestellt erfüllen relationale Datenbanken die Ziele der Konsistenz und der Ausfalltoleranz. Die meisten NoSQL- Systeme verfügen über eine mögliche Konsistenz beziehungsweise Eventual Consistency. Dieser Bereich legt die Ziele auf eine Gewährleistung der Ausfallsicherheit und der Verfügbarkeit. [CouchDBDoku12] 3.3. BASE Als Reaktion auf die im CAP-Theorem erkannten Probleme in verteilten Datenbanksystemen entstand ein alternatives Konsistenzmodell. Dieses Modell legt anders als das klassische Modell ACID den Schwerpunkt auf die Verfügbarkeit. Der Name des Modells setzt sich wie bei ACID aus seinen Kriterien zusammen. Das Modell trägt den Namen BASE und steht für Basically Available, Soft State und Eventually Constistent. [Pritchett08] In BASE wird Konsistenz als ein Übergangsprozess betrachtet. Das heißt, dass ein konsistenter Zustand nicht direkt nach Beendigung einer Transaktion vorhanden sein muss, sondern erst nach einer gewissen Zeit. Dies bedeutet jedoch auch, dass mit vorübergehender Inkonsistenz zu rechnen ist. Man spricht dabei von Eventual consistency. Wie lange es dauern kann, bis der Zustand der Konsistenz erreicht wird, hängt von mehreren Faktoren ab. Dies sind bspw. Anzahl oder Reaktionszeit der replizierten Knoten. Dabei ist es wichtig, dass dies bei kritischen Stellen in der Anwendung berücksichtigt wird, damit gegebenenfalls auf vorübergehende inkonsistente Zustände reagiert werden kann. [Edlich11] 3.4. REST REST beschreibt ein Architekturmodell, welches auf dem Web-Protokoll HTTP basiert. REST steht für Representational State Transfer und wurde erstmals im Jahre Andreas Hofstetter Masterthesis 2011/12 17

19 3. Grundlegende Techniken und Theorien 2000 in der Dissertation von Roy Thomas Fielding erwähnt. Der Vorteil dieser Architektur liegt darin, eine einheitliche Schnittstelle für unterschiedlichste Komponenten bereit zu stellen. [Fielding00] Grundgedanke des Konzeptes ist es, die Ressourcen einer Anwendung mittels einer URI eindeutig zu identifizieren. Im Datenbankbereich besteht eine solche Ressource aus einem Datensatz. Operationen mit den Ressourcen lassen sich über HTTP-Requests ausführen. Dabei werden die vier HTTP-Methoden CREATE, POST, PUT und DELETE verwendet, um Operationen wie Datenabfragen oder Datenmanipulationen durchführen zu können. So befindet sich bspw. hinter der URI der Datensatz einer Person mit der ID 1. Wird ein HTTP-Request mit der Methode GET auf diese URI durchgeführt, wird der Datensatz in einer bestimmten Formatierung ausgegeben. Mittels DELETE kann der Eintrag aus der Datenbank entfernt werden. Änderungen können bspw. durch einen POST-Request erfolgen in dem die neuen Daten als POST-Parameter an den Server geschickt werden. Mit der PUT-Methode wird erlaubt, neue Ressourcen beziehungsweise Datensätze anzulegen. Inwiefern die einzelnen Methoden verwendet werden und wie die Rückgabe der Anwendung aufgebaut ist, hängt von der jeweiligen Implementierung des REST-Services ab. Diese Schnittstellen-Architektur hat den Vorteil, dass jeder beliebige HTTP-fähige Client diese Schnittstelle verwenden kann. Verwendet demnach ein Datenbanksystem eine solche Schnittstelle, kann das System unabhängig von der im Projekt verwendeten Programmiersprache eingesetzt werden. [Tilkov09] 3.5. Map/Reduce Eines der wichtigsten Kriterien der meisten NoSQL-Vertreter liegt in der effizienten Verarbeitung großer Datenmengen im Tera- oder gar Petabyte-Bereich. Dazu entwickelte 2004 die Google Inc. ein Datenverarbeitungsmodell zur nebenläufigen Berechnung solcher Datenaufkommen in Computerclustern. Benannt wurde diese Technologie als Map/Reduce und wird in verschiedenen NoSQL-Systemen eingesetzt. Andreas Hofstetter Masterthesis 2011/12 18

20 3. Grundlegende Techniken und Theorien Abbildung 3.2.: Ablauf des Map/Reduce-Verfahrens Quelle: [Edlich11] Das Verarbeitungsmodell wird in zwei Funktionen aufgeteilt, welche nacheinander durchgeführt werden. Diese zwei Funktionen, nach denen das Verfahren benannt wurde, heißen Map und Reduce. Im ersten Schritt wird die Map-Funktion durchgeführt. Sie wird für jeden Eintrag in der Datenbank aufgerufen und bekommt den Datensatz und eine eindeutige ID als Parameter übergeben. Die Map-Funktion filtert und transformiert diese Daten und generiert Key-Value-Paare als Zwischenergebnisse. Ein Key-Value-Paar ist ein Konstrukt aus einem Schlüssel - dem Key, mit dem das Paar eindeutig identifiziert werden kann - und einem Wert, also der eigentlichen Information. Nachdem die Map-Funktionen abgeschlossen worden sind, beginnt die Reduce- Phase. Die Reduce-Funktion erhält die von der Map-Funktion erstellten Key-Value- Paare und verarbeitet diese weiter. Dabei wird die Reduce-Funktion für jeden vorhandenen Schlüssel im Zwischenergebnis ausgeführt. Übergeben wird dieser Funktion zum einen der Schlüssel und zum anderen ein Array, welches sämtliche Werte enthält, die zum aktuellen Schlüssel zugewiesen worden sind. Die Reduce- Funktion dient meist dazu, Berechnungen und Aggregationen über den Datenbestand durchzuführen. Listing 3.1 zeigt das abgewandelte Beispiel aus dem ursprünglichen Paper von Dean und Ghemawat. Für dieses Beispiel wurden die Map/Reduce-Funktionen mit Andreas Hofstetter Masterthesis 2011/12 19

21 3. Grundlegende Techniken und Theorien der Skriptsprache JavaScript implementiert. Ziel ist es, aus einer Reihe von unterschiedlichen Texten die Häufigkeit der einzelnen Wörter zu ermitteln. Dabei wird für jedes Textobjekt in der Datenbank die Map-Funktion durchgeführt. Übergeben werden die beiden Parameter key und value. Bei key handelt es sich um den Identifikator des Dokuments und bei value um den Textinhalt als String. Im ersten Schritt wird der Fließtext in ein Array umgewandelt, indem der Text bei jedem Leerzeichen geteilt wird. Anschließend wird über das Array iteriert und für jedes Wort im Text ein Key-Value-Paar erzeugt. Der Schlüssel bildet jeweils das aktuelle Wort. Der Wert ist für jedes Paar identisch und enthält einen Zähler mit dem Wert 1. Der zweite Schritt ist die Reduce-Funktion. Diese Funktion wird für jedes vorkommende Wort durchgeführt und gibt die Summe der von der Map-Funktion erstellten Werte aus. Listing 3.1: Map-Funktion 1 function map(key, value) { 2 // key: document name 3 // value: document contents 4 words = value. split (" "); 5 for (var i = 0; i < words.length; i ++) { 6 emit(words[i ], 1); // Ausgabe eines Key-Value-Paares 7 } 8 } Listing 3.2: Reduce-Funktion 1 function reduce(key, values){ 2 // key: a word 3 // values: list of counts 4 var result = 0; 5 for (var i = 0; i < values.length; i ++) { 6 result = result + parseint(words[i ]) ; // Zähler summieren 7 } 8 emit( result ) ; // Endergebnis ausgeben 9 } Der Grund warum mit Map/Reduce solch große Datenmengen performant abgearbeitet werden können, liegt darin, dass die Prozesse parallelisiert durchgeführt Andreas Hofstetter Masterthesis 2011/12 20

22 3. Grundlegende Techniken und Theorien werden. Das heißt, dass in einem Computercluster, also einer Menge von vernetzten Computern, jede Recheneinheit einen Teil der Daten gleichzeitig abarbeiten kann. Somit verteilt sich die Last gleichmäßig auf mehrere Instanzen. Ermöglicht wird dies durch die Anlehnung an funktionale Sprachen. Dadurch entstehen in der Ausführung keine Seiteneffekte, was bedeutet, dass keine Map-Funktion von dem Zustand oder Ergebnis einer anderen Map-Funktion abhängig ist. [Dean04] Andreas Hofstetter Masterthesis 2011/12 21

23 4. NoSQL-Konzepte 4. NoSQL-Konzepte Der Begriff NoSQL wurde ursprünglich von Carlo Strozzi als Bezeichnung für ein von ihm entwickeltes Datenbankmanagementsystem verwendet. Anders als bei der aktuellen Verwendung des Begriffs war hier jedoch ein bestimmtes relationales System gemeint. Zu anderen RDBMS unterscheidet sich Strozzis System, indem es auf die herkömmliche Abfragesprache SQL verzichtet und stattdessen eine eigene API verwendet, welche auf eine Reihe von CLI-ähnlichen Befehlen zurückgreift. [Strozzi12] Als Bezeichnung für nicht-relationale Datenbanksysteme wurde es erstmals von Johan Oskarsson im Mai 2009 verwendet. Dabei wurde NoSQL als Titel einer Konferenz verwendet, welche die kürzlich entstandenen, für den verteilten Einsatz entwickelten Datenbanksysteme wie HBase, Cassandra oder CouchDB thematisierte.[oskarsson12] Es existiert keine strikte Definition, die aussagt, welche Arten von Datenbanksystemen unter diesen Begriff fallen und welche nicht. Das NoSQL-Archiv, das eine Sammlung von Dokumenten und Links über dieses Thema zur Verfügung stellt, hat versucht, mit Hilfe der NoSQL-Community Kriterien zu erstellen. Anhand dieser Kriterien soll die Kategorisierung von NoSQL-Systemen vereinheitlicht werden. Das Archiv hat sieben Kriterien veröffentlicht, die ein Datenbankmanagementsystem aufweisen sollte, um als NoSQL-System eingestuft zu werden. [NoSqlArchive12] In der deutschen Übersetzung von Stefan Edlich wird unter NoSQL eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigt: [Edlich11] Andreas Hofstetter Masterthesis 2011/12 22

24 4. NoSQL-Konzepte Das zugrunde liegende Datenmodell ist nicht relational. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet. Das NoSQL-System ist Open Source. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation. Das System bietet eine einfache API. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde. Der Vermerk, dass lediglich einige der Punkte berücksichtigt werden müssen, deutet darauf hin, dass auch diese Definition nicht als absolutes Ausschlusskriterium zu verstehen ist. Kaum ein Datenbankmanagementsystem erfüllt sämtliche sieben Kriterien. So ist der Übergang zwischen traditionellen und NoSQL-Systemen wie in Abbildung 4.1 dargestellt fließend. Zumal in dieser Definition auch Eigenschaften miteinbezogen werden, die nicht auf technischen Eigenschaften beruhen. So werden auch das Alter des Projekts ( neue Generation ) und die Lizenz ( Open Source ) berücksichtigt. Daher lässt sich der Begriff NoSQL weiter in zwei Bereiche unterteilen. Es wird zwischen Kern-NoSQL-Systemen und Soft-NoSQL-Systemen, auch nachgelagerte Systeme genannt, unterschieden. Zuden Kernsystemen werden vor allem die Systeme gezählt, welche durch die neuen Anforderungen der modernen Webanwendungen entstanden sind. Dazu gehören vier verschiedene Datenbank-Konzepte, welche im darauf folgenden Kapitel detaillierter beschrieben werden. Bei diesen Konzepten handelt es sich um dokumentenorientierte Datenbanken, spaltenorientierte Datenbanken, Key-Value Datenbanken und Graphendatenbanken. Als nachgelagerte NoSQL-Systeme werden unter anderem Objekt- und XML- Datenbanken bezeichnet, welche in den 90er Jahren als Alternative zu relationalen Datenbanken entwickelt wurden. Diese Systeme weisen zwar meist einige der NoSQL-Kriterien auf, werden allerdings nicht zum Kernbereich gezählt, da sie vor Andreas Hofstetter Masterthesis 2011/12 23

25 4. NoSQL-Konzepte dem Web 2.0 entstanden sind und somit nicht wie in der Definition verlangt zur neuen Generation von Datenbanksystemen gehören.[edlich11] In den anschließenden Kapiteln dieser Arbeit liegt die Betrachtung ausschließlich auf Systemen, welche als Kern-NoSQL-Systeme bezeichnet werden. Abbildung 4.1.: Kategorisierung von Datenbanksystemen Quelle [Edlich11] Andreas Hofstetter Masterthesis 2011/12 24

26 4. NoSQL-Konzepte 4.1. Key-Value-Datenbanken Das erste vorgestellte Konzept ist auch eines der ältesten Datenbank-Konzepte, welches bereits seit den 70er Jahren im Einsatz ist. Das Key-Value-Konzept ist also deutlich älter als der Begriff NoSQL. Die meisten Key-Value-basierten DBMS entstanden allerdings erst durch das Aufkommen von Web 2.0-Anwendungen. Key-Value-Datenbanken zeichnen sich durch ihr einfaches Datenschema ab, indem sämtliche Inhalte in Key-Value-Paaren abgelegt werden. Der Key beziehungsweise Schlüssel ist ein Identifikator, meist in Form einer Zeichenkette oder eines Binärcodes, mit dessen Hilfe sich ein Datensatz eindeutig bestimmen lässt. [JansenRedis12] Ein Value beziehungsweise Wert stellt die eigentlich abzuspeichernde Information dar. Dabei kann es sich abhängig vom verwendeten DBMS um einfache Datentypen wie beispielsweise Zeichenketten und Zahlen, aber auch um komplexe Objekte und Listen handeln. Eine Key-Value-Datenbank lässt sich demnach als eine einzelne Tabelle mit zwei Spalten darstellen. Die erste Spalte bildet den Schlüssel, nach dem die Tabelle durchsucht wird und die zweite Spalte enthält die zu speichernden Werte. Dabei gilt es zu beachten, dass der Zugriff auf die Daten ausschließlich über den Schlüssel erfolgen kann. Nach einem Value kann nicht gesucht werden. Die Daten in einer Key-Value-Datenbank sind relationslos. Das bedeutet, dass keine Abhängigkeiten zwischen einzelnen Datensätzen existieren. Diese simple und unabhängige Struktur ermöglicht ein einfaches Skalieren bei großen Datenmengen auf mehreren physikalischen Instanzen. [Edlich11] Ein gebräuchliches Einsatzgebiet von Key-Value-Datenbanken ist das Cachen, also das temporäre Zwischenspeichern, von Daten. Dabei werden Daten, die zuvor aus einer relationalen Datenbank abgefragt worden sind, für eine gewisse Zeit in einer Key-Value-Datenbank abgelegt. Bei wiederholenden Anfragen erfolgt dann der Lesezugriff auf die Key-Value-Datenbank anstelle der relationalen Datenbank. Der Vorteil hierbei ist, dass einige Key-Value-Datenbanksysteme ihren Datenbestand teilweise oder vollständig im Hauptspeicher des Servers ablegen können. Dadurch werden sehr schnelle Zugriffe ermöglicht und somit die Reaktionszeit der Andreas Hofstetter Masterthesis 2011/12 25

27 4. NoSQL-Konzepte Anwendung erhöht. Zusätzlich lassen sich Abfragen in Key-Value-Datenbanken in der Regel ressourcensparender durchführen, wodurch auch die CPU-Last des Servers drastisch sinken kann.[oraclememcached10] Diese Varianten werden Hauptspeicherdatenbanken oder In-Memory-Datenbanken (IMDB) genannt. Es existiert Key Values Name Hans Hauser Alter 42 Geschlecht männlich Tabelle 4.1.: Tabellarische Darstellung von Key-Value-Paaren eine große Anzahl an verschiedenen Key-Value-Datenbanken. Zu den bekanntesten Vertretern dieser Gattung zählen Redis und das aus dem Memcached-Projekt entstandene Membase. Ersteres wird im folgenden Abschnitt näher betrachtet und dient zur Entwicklung der exemplarischen Webanwendung Redis Das in ANSI C geschriebene Projekt begann 2009 als Ein-Mann-Projekt und wird seit 2010 vom Virtualisierungsspezialist VMWare weiterentwickelt. Redis ist unter der New-BSD Lizenz verfügbar und kann ausschließlich unter UNIX-Systemen verwendet werden. Der Name Redis ist eine Abkürzung und steht für Remote Dictionary Server. Eine Redis-Installation kann in zwei unterschiedlichen Modi betrieben werden. Im standardmäßigen Snapshotting Mode befinden sich sämtliche Daten im RAM, welche zu bestimmten Zeitpunkten auf der Festplatte persistent gesichert werden. So werden schnelle Zugriffszeiten wie bei reinen In-Memory-Datenbanken ermöglicht. Bei einem Systemabsturz kann jedoch ein bestimmter Teil der Daten reproduziert werden. Beim Append Only File Mode werden sämtliche Schreibvorgänge unmittelbar auf der Festplatte abgelegt, was sich allerdings negativ auf die Zugriffszeiten auswirkt. Dafür werden alle Daten dauerhaft gespeichert. [Edlich11] Andreas Hofstetter Masterthesis 2011/12 26

28 4. NoSQL-Konzepte Datenmodell Trotz dieses simplen Datenkonzeptes ermöglichen moderne Key-Value-Datenbankmanagementsysteme wie Redis komplette Webanwendungen auf ihrer Basis zu entwickeln. Dies wird ermöglicht, da Redis komplexe Datentypen wie Sets und Listen als Werte unterstützt. Zusätzlich ist ein einheitliches Konzept für den Aufbau der Schüssel notwendig, um verschiedene Arten von Datensätzen zu unterscheiden. Tabelle 4.2 zeigt die Daten für eine Person mit Telefonnummern. Key Values person:1:name Hans Hauser person:1:alter männlich person:1:geschlecht 42 person:1:telefon [1, 2] name:hans_hauser:id 1 telefon:1:typ mobil telefon:1:nummer telefon:2:typ Festnetz telefon:2:nummer Tabelle 4.2.: Personenbeispiel mit Redis Ein Key besteht jedes Mal aus mehreren Bestandteilen, die durch einen Doppelpunkt getrennt werden. Der Schlüssel für den Namen einer Person, in diesem Beispiel person:1:name, besitzt drei Komponenten. Er beginnt mit dem Präfix person, welcher angibt, dass es sich bei dem aktuellen Datensatz um eine Information einer Person handelt. In diesem Beispiel sollen neben Personendaten auch Informationen über Telefonnummern gespeichert werden. Da Redis alle Daten in einer einzelnen Tabelle ablegt, müssen die unterschiedlichen Datenarten über das Schema des Schlüssels deutlich gemacht werden. Dies ist beispielsweise beim Schlüssel telefon:1:typ zu sehen. Der zweite Bestandteil ist der eindeutige Identifikator einer Person. Anhand dieses Wertes lassen sich die Daten verschiedener Personen voneinander unterscheiden. Dieser Identifikator ist mit dem Primärschlüssel einer Tabelle in relationalen Datenbanken zu vergleichen. Der dritte und letzte Parameter name bestimmt die eigentliche Eigenschaft, welche der Datensatz enthält. In diesem Fall der vollständige Name einer Person. Andreas Hofstetter Masterthesis 2011/12 27

29 4. NoSQL-Konzepte Da die Values der Datenbank nicht durchsucht werden können, müssen manche Daten sowohl als Schlüssel als auch als Wert gespeichert werden. Der Schlüssel name:hans_hauser:id ermöglicht auch über den Personennamen die Personen-ID abzufragen. Existiert keine umgekehrte Speicherung, ist es nicht möglich, nach diesem Wert zu suchen. Das aktuelle Beispiel ermöglicht demnach nicht, anhand des Alters oder des Geschlechts auf Personen zu schließen. Der Doppelpunkt hat keine besondere Funktion. Er dient lediglich dazu die Bestandteile des Schlüssels sichtbar zu trennen. Es kann jedes beliebige Zeichen dafür verwendet werden. Voraussetzung ist allerdings, dass die Anwendung konsequent die Schlüssel nach dem gleichen Schema konstruiert. Redis bietet keine Kontrollfunktion zur Validierung von Schlüsseln. Beziehungen können erzeugt werden, indem der Schlüssel beziehungsweise ein Teil des Schlüssels als Wert eines anderen Datensatzes gespeichert wird. Die Auflösung der Beziehung kann allerdings nur auf Anwendungsebene erfolgen, indem in zwei Schritten zunächst der benötigte Schlüssel und erst anschließend der eigentlich gewünschte Wert abgefragt wird. 1-m Beziehungen werden mittels Sets oder Listen erzeugt. Diese Datentypen bestehen aus mehreren einzelnen Werten, wobei in einer Liste, anders als in einem Objekt, die Werte geordnet ablegt sind. In Tabelle 4.2 ist dies bei Schlüssel person:1:telefon zu sehen. Hier werden in einem Set die Identifikatoren der Telefonnummern einer Person abgelegt. Soll die Beziehung aufgelöst werden, ermittelt die Anwendung also zuerst über das Set die einzelnen Telefon-IDs, um anschließend die jeweiligen Schlüssel für die Telefondatensätze zu erstellen und die Werte abzufragen. Sollen also beispielsweise alle Telefonnummer der Person ermittelt werden, sind in diesem Beispiel drei Abfragen nötig. [RedisDocumentation12] Schnittstellen Die API besteht aus einem eigens entwickelten Protokoll auf Basis von TCP/IP. Die Schnittstelle umfasst in der Version 2.4 insgesamt 125 Kommandos. Darunter Andreas Hofstetter Masterthesis 2011/12 28

30 4. NoSQL-Konzepte befinden sich neben Kommandos für CRUD-Operationen auch Befehle, um den Server zu konfigurieren und Verbindungen aufzubauen. Eine grafische Benutzeroberfläche ist in der Installation nicht enthalten. Um mit dem Datenbanksystem zu interagieren, wird jedoch ein kommandozeilenbasiertes Programm mitgeliefert. Ein gewöhnlicher Telnet-Client reicht aber ebenfalls aus, um Operationen durchführen zu können. Für den Einsatz innerhalb einer Anwendung stehen Client-Bibliotheken für 24 Programmiersprachen zur Verfügung. Mit Listing 4.1 wird die Kommunikation mit Hilfe eines Telnet-Clients aufgezeigt. Bei Zeilen, die mit > beginnen handelt es sich um die Rückgabe des Servers. Im ersten Schritt wird eine Verbindung zum Server mit der IP über Port 6379 hergestellt. Anschließend können die Redis-Kommandos abgesetzt werden. In diesem Beispiel wird zuerst mit SET ein neues Key-Value-Paar erzeugt. Der Befehl benötigt zunächst zwei Argumente, den Schlüsselnamen und die Anzahl der Bytes, die der Wert benötigen wird. Abschließend muss der zu speichernde Wert eingegeben werden. Im Erfolgsfall wird +OK zurückgegeben. Mit dem zweiten Kommando wird mittels GET der zuvor eingetragene Wert abgefragt. Der Rückgabewert besteht aus zwei Zeilen. In der ersten Zeile wird der Speicherbedarf in Bytes angegeben, in der zweiten wird der Wert unformatiert ausgegeben. Listing 4.1: API-Zugriff über Telnet 1 telnet > Verbindungsaufbau SET person:1:name 11 5 Hans Hauser 6 > +OK 7 8 GET person:1:name 9 > $10 10 > Hans Hauser Eine vollständige Übersicht aller verfügbaren Kommandos ist in der offiziellen Website aufgeführt. [RedisCommands12] Andreas Hofstetter Masterthesis 2011/12 29

31 4. NoSQL-Konzepte 4.2. Dokumentenorientierte Datenbanken Dokumentenorientierte Datenbanken legen, wie der Name verrät, die zu speichernden Daten als Dokumente ab. Als Dokument wird ein in einer beliebigen Syntax beschriebenes, schemaloses Datenkonstrukt bezeichnet. Darunter können auch Vertreter der XML-Datenbanken gezählt werden, insofern die Datenbeschreibung schemalos und unstrukturiert erfolgt. Schemalos bedeutet, dass im Vorfeld keine Aussagen getroffen werden müssen wie ein Datenobjekt aufgebaut ist. Es existieren keine Pflichtattribute und jedes Objekt kann zu einer beliebigen Zeit um beliebige Werte erweitert oder verringert werden. Auch die Länge eines Wertes kann frei variieren. Dies bedeutet zum einen mehr Flexibilität in der Datenbank und zum anderen aber auch mehr Verantwortung für die Anwendung, da diese so für die Wahrung der Datenintegrität zuständig ist. Ein Dokument ermöglicht es, komplexere Strukturen in einem Objekt zu speichern. Selbst für umfangreichere Anwendungen kann dies bedeuten, dass für einen Datensatz, welcher in einer relationalen Datenbank auf mehrere Tabellen verteilt abgelegt werden muss, ein Dokument ausreicht, um die Informationen zu speichern. Dadurch werden ressourcenhungrige Joins über mehrere Tabellen hinfällig. [JansenCouchDB12] Die Anzahl der bisher entwickelten dokumentenorientierten Datenbanken ist verhältnismäßig gering. Zwei etablierte Systeme heißen MongoDB und CouchDB, wobei letzteres im folgenden Abschnitt näher betrachtet werden soll CouchDB Das in Erlang geschriebene Projekt wird seit 2005 entwickelt und ist unter der Apache 2.0 Lizenz verfügbar. Es lässt sich auf nahezu allen relevanten Systemen wie bspw. Linux, Windows und Apple Mac OS installieren. Der Name CouchDB ist die Abkürzung für Cluster of unreliable commodity hardware Data Base und weist auf das Hauptziel des Projektes hin, ein replizierbares und ausfallsicheres Datenbanksystem zu entwickeln. Das Logo mit dem Untertitel relax soll auf einen weiteren Vorsatz der Entwickler hinweisen, den Einstieg und den Umgang mit dem System Andreas Hofstetter Masterthesis 2011/12 30

32 4. NoSQL-Konzepte möglichst einfach zuhalten, indem etablierte und verbreitete Technologien eingesetzt werden. CouchDB richtet sich wie die meisten NoSQL-Systeme nach den BASE-Kriterien und ermöglicht so lediglich eine Eventual Consistency. [Gull11] Datenmodell 1 { Als Datenformat-Syntax wird JSON verwendet. JSON wurde ursprünglich als Datenaustauschformat für die browserseitige Skriptsprache JavaScript entwickelt und ist mittlerweile im gesamten Webumfeld weit verbreitet. Listing 4.2 zeigt das aus dem zweiten Kapitel bekannte Beispiel für Personen mit Telefonnummern als ein JSON-formatiertes Objekt. Ein JSON-Objekt wird stets durch geschweifte Klammern eingeschlossen. Innerhalb des Objektes werden kommagetrennt beliebig viele Key-Value-Paare angegeben. Der Wert eines solchen Paares kann wiederum aus einem geschachtelten JSON-Objekt oder einem Array von Werten bestehen. Diese werden durch eckige Klammern gekennzeichnet. Listing 4.2: JSON-formatieres Datenobjekt 2 "_id" : "eindeutiger_wert" 3 "_rev" : "1-12a34ff65a7ec9b8" 4 "Name" : "Hans Hauser", 5 "Geschlecht" : "männlich", 6 "Alter" : 44, 7 "Telefon" : [ 8 { 9 "Typ" : "mobil", 10 "Nummer" : }, 12 { 13 "Typ" : "festnetz", 14 "Nummer" : } 16 ] 17 } Die beiden Schlüssel _id und _rev stellen besondere Attribute in einem CouchDB- Dokument dar. Das Attribut _id dient wie ein Primärschlüssel in einer relationalen Andreas Hofstetter Masterthesis 2011/12 31

33 4. NoSQL-Konzepte 1 { Tabelle als eindeutiger Identifikator. Das heißt, dass dieser Wert in der gesamten Datenbank nur einmalig vorkommen darf. Das Attribut _rev dient der Versionierung und besteht aus einer fortlaufenden Nummer und dem MD5-Hash des Dokumentes. Wird ein Wert in einem Dokument geändert oder ein neues Attribut hinzugefügt, wird das gesamte Dokument als neue Version abgespeichert. Dabei generiert CouchDB automatisch einen neuen Wert für das Attribut _rev. Anhand dieses Wertes kann das System mögliche Fehler durch konkurrierende Zugriffe erkennen und fehlerhafte Schreibvorgänge verhindern. Dieses Verfahren wird als Multi-Version-Concurreny-Control (MVCC) bezeichnet. [Gull11] Beziehungen zwischen Daten können über zwei Arten erzeugt werden. Die erste Methode ist bereits in Listing 4.2 mit dem Key Telefon zu sehen. Hier werden durch ein Array mehrere geschachtelte Dokumente mit Telefondaten abgelegt. Dadurch wird eine 1-zu-m Beziehung abgebildet. Eine andere Möglichkeit zeigt Listing 4.3. Hier werden für die Telefonnummern eigenständige Dokumente erzeugt und im Personendokument über den Identifikator referenziert. Eine Auflösung einer solchen Beziehung kann jedoch lediglich auf Anwendungsebene erfolgen und nicht wie bei relationalen Tabellen über Joins verwirklicht werden. [CouchDBEntityRelationship12] Listing 4.3: Beziehungen über eigenständige Dokumente 2 "_id" : "eindeutiger_wert" 3 "_rev" : " " 4 "Name" : "Hans Hauser", 5 "Geschlecht" : "männlich", 6 "Alter" : 44, 7 "Telefon" : ["tel_1", "tel_2"] 8 } 9 { 10 "_id" : "tel_1" 11 "_rev" : " " 12 "Typ" : "mobil", 13 "Nummer" : } Andreas Hofstetter Masterthesis 2011/12 32

34 4. NoSQL-Konzepte 15 { 16 "_id" : "tel_2" 17 "_rev" : " " 18 "Typ" : "festnetz", 19 "Nummer" : } Schnittstellen Zur direkten Interaktion und Konfiguration wird von Haus aus eine umfangreiche und webbasierte grafische Oberfläche namens Futon mitgeliefert. Futon bietet neben der Möglichkeit Datenbanken und Dokumente zu erstellen und zu verwalten, auch die Möglichkeit Map/Reduce-Funktionen zu implementieren, zu testen und abzuspeichern. Abbildung 4.2.: MapReduce mit Futon erstellen Quelle: eigene Anfertigung Andreas Hofstetter Masterthesis 2011/12 33

35 4. NoSQL-Konzepte 1 { Abbildung 4.2 zeigt den Editor, welcher das Erstellen vom Map/Reduce-Funktionen erlaubt. Dazu werden zwei Eingabefelder bereitgestellt, in denen die beiden Funktionen implementiert werden können. Im unteren Bereich wird das Ergebnis der Prozedur ausgegeben. Die über Futon erstellten Map/Reduce-Funktionen können anschließend abgespeichert und von anderen Schnittstellen verwendet werden. Eine Map/Reduce-Prozedur wird in CouchDB ebenso wie Daten als JSON-Dokument abgespeichert. Diese besonderen Dokumente werden als Design-Dokumente bezeichnet. In Listing 4.4 wird ein solches Design-Dokument gezeigt. In diesem Beispiel filtert die Map-Funktion alle Personen raus, welche jünger als 18 Jahre alt sind, und gibt das Objekt mit einem Zähler aus. Die Reduce-Funktion summiert anschließend diese Zähler, um die Anzahl der volljährigen Personen in der Datenbank zu ermitteln. Dieses GUI ermöglicht gerade Einsteigern einen komfortablen Umgang mit dem System und dem Map/Reduce-Konzept. Auch bei der API setzt CouchDB auf ein verbreitetes Konzept. CouchDB verwendet, wie einige andere NoSQL-Vertreter auch, das auf HTTP basierende REST als Schnittstelle. Somit kann CouchDB von jeder Programmiersprache eingesetzt werden, welche es ermöglicht, HTTP-Anfragen durchzuführen. Listing 4.4: Als Design-Dokument gespeicherte Map/Reduce-Methode 2 "_id": "_design/age2", 3 "_rev": "1-1b7a64e67f4d0af4b126af591d2eb8b7", 4 "language": "javascript", 5 "views": { 6 "age": { 7 "map": "function(doc) {\n 8 if(doc.item && doc.age >= 18) {\n 9 emit(doc.item, 1);\n 10 }\n }\n", 11 "reduce": "function(keys, values) {\n 12 return sum(values);\n 13 }\n\n" 14 } 15 } 16 } Andreas Hofstetter Masterthesis 2011/12 34

36 4. NoSQL-Konzepte Listing 4.5 zeigt den vollständigen HTTP-Request, um aus der Datenbank namens person das Dokument mit der ID 1 zu erhalten. Die Anfrage wurde mit Hilfe des Programms curl durchgeführt. Hervorzuheben ist die Anweisung GET /person/1. Hier wird zuerst der HTTP-Befehl und somit die Aktion, welche vom Datenbankmanagementsystem durchgeführt werden soll, bestimmt. Durch GET wird angegeben, dass nach einer Rückgabe von gespeicherten Dokumenten verlangt wird. Die anschließende Pfadangabe verweist auf ein bestimmtes Objekt. Zuerst wird die Datenbank, in diesem Fall person, und anschießend die ID des gewünschten Dokuments ausgewählt. Listing 4.5: HTTP-Request für eine Abfrage über REST 1 GET /person/1 HTTP/1.1 2 User Agent: curl/ (amd64 pc win32) libcurl/ Host: : Accept: * /* Die darauf folgende Rückgabe wird in Listing 4.6 aufgeführt. Das eigentliche Dokument befindet sich im Body des HTTP-Requests. Es handelt sich um das in Listing 4.2 gezeigte Beispiel für die Person Hans Hauser. Trotz der Content-Type- Anweisung text/plain gibt CouchDB stets ein JSON-formatiertes Objekt zurück. Eine ausführliche Übersicht aller unterstützen Operationen ist in der offiziellen Dokumentation zu finden. [Anderson10] Listing 4.6: HTTP-Response für eine Abfrage über REST 1 HTTP/ OK 2 Server: CouchDB/ (Erlang OTP/R13B) 3 Etag: "1-0309b6ef49487a ac480931c2" 4 Date: Wed, 11 Jan :42:39 GMT 5 Content Type: text/plain;charset=utf 8 6 Content Length: Cache Control: must revalidate 8 9 {"_id":"1","_rev":"1-0309b6ef49487a ac480931c2","name":"hans Hauser","Geschlecht ":"m\u00e4nnlich","alter":44,"telefon":[{"typ":"mobil","nummer": },"typ":" Festnetz","Nummer": }]} Andreas Hofstetter Masterthesis 2011/12 35

37 4. NoSQL-Konzepte Eine offizielle Client-Bibliothek, welche die REST-Kommunikation transparent und somit die Verwendung der Schnittstelle vereinfacht, existiert nicht. Jedoch wurden für einige Sprachen Bibliotheken von der Community entwickelt und veröffentlicht, wie zum Beispiel PHPillow für PHP oder CouchREST für Ruby. In welcher Art und Weise diese Projekte weiterentwickelt werden, lässt sich nicht mit Sicherheit sagen. Deshalb und um auf die Eigenschaften der CouchDB-Schnittstelle besser eingehen zu können, wurde in dieser Arbeit auf die Verwendung der oben beschriebenen Bibliotheken verzichtet und eine selbst entwickelte Bibliothek verwendet. Andreas Hofstetter Masterthesis 2011/12 36

38 4. NoSQL-Konzepte 4.3. Spaltenorientierte Datenbanken Spaltenorientierte Datenbanken, auch Wide Column Stores genannt, speichern die Daten, ähnlich wie bei relationale Datenbanken, in Tabellen. Der Unterschied liegt allerdings darin, dass ein Datensatz nicht eine neue Zeile darstellt, sondern eine Spalte beziehungsweise eine Gruppe von Spalten. Der Vorteil liegt hier in der Art, wie die Daten physikalisch auf dem Datenträger organisiert werden können. Bei spaltenorientieren Datenbanken werden die Datensätze nach ihren Spalten gruppiert abgelegt. Bei Abfragen bei denen Operationen wie das Ermitteln einer Summe oder eines Durchschnittes auf einzelne Attribute ausgeführt wird, ermöglicht diese Organisation der Daten eine deutlich effizienteres Verfahren. In diesem Bereich gibt es eine Vielzahl von verschiedenen Implementierungen, die sich zum Teil stark voneinander unterscheiden. Zu den bekanntesten zählen Amazon SimpleDB, HBase und das von Facebook entwickelte Cassandra. Für die zu entwickelnde Webanwendung wird HBase eingesetzt, auf welches im folgenden Abschnitt eingegangen wird HBase Bei dem 2006 gestarteten Projekt handelt es sich um eine freie Nachbildung der von Google veröffentlichten Spezifikation zum Datenbanksystem BigTable. [BigTable12] Ziel der HBase-Entwickler war es, ein Datenbanksystem speziell für verteilte Anwendungen zu entwickeln. Dies wird dadurch deutlich, dass HBase ein Teil des Hadoop- Projektes ist. [Hadoop12] Hadoop ist eine Sammlung von Projekten, die zusammen ein Framework zur Entwicklung von verteilten Infrastrukturen bildet. Neben HBase zählt ebenso das verteilte Dateisystem HDFS und eine Map/Reduce-Implementierung zum Framework. Andreas Hofstetter Masterthesis 2011/12 37

39 4. NoSQL-Konzepte HBase wurde in Java entwickelt und kann daher plattformunabhängig eingesetzt werden. Vertrieben wird es unter der Apache Version 2 Lizenz Datenschema In HBase besitzt jeder Datensatz einen eindeutigen Schlüssel, der Row-Key, nach dem der Datenbestand einer Tabelle sortiert ist und mit dessen Hilfe ein bestimmter Datensatz identifiziert werden kann. Ein Datensatz besteht aus einer beliebigen Anzahl von Spalten (Columns), welche die zu speichernden Daten beinhalten. Es existieren keine Datentypen, alle Werte werden als ein Array aus Bytes abgelegt. Die Typisierung in einen bestimmten Datentyp muss auf der Ebene der Anwendung erfolgen. Zusammengehörende Spalten lassen sich mittels Column Families gruppieren. Column Families sind ein wichtiger Bestandteil für die Verteilbarkeit der Datenbank und beeinflussen die physikalische Speicherung der Daten. Daten einer Column Family werden auf demselben Server abgelegt, wobei unterschiedliche Column Families eines Datensatzes über verschiedene Instanzen hinweg verteilt ablegt sein können. Für jeden geänderten Wert enthält eine Spalte eine Kopie des alten Wertes, welcher sich über einen Zeitstempel identifizieren lässt. Durch dieses Zeitstempelverfahren kann HBase konkurrierende Zugriffe erkennen und Fehlern entgegenwirken. Die Daten einer HBase-Datenbank lassen sich demnach als Key-Value-Paar darstellen, wobei der Key eine Kombination aus Row-Key, Column Family, Column und dem Zeitstempel ist. Welche Column Families eine Tabelle besitzt, muss beim Erstellen der Tabelle angegeben werden. Innerhalb einer Column Familie können allerdings beliebige Key- Value-Paare eingefügt werden. Tabelle 4.3 zeigt das Datenschema für das bereits verwendete Beispiel für Personen und Telefonnummer. In diesem Beispiel werden zwei Column Families angelegt. Zum einen Person für Informationen zur Person und zum anderen Telefon für die Telefondaten. Die Telefondaten bilden Key-Value-Paare, wobei der Key aus dem Typ, also beispielsweise Festnetz, und der Value aus der Telefonnummer besteht. Andreas Hofstetter Masterthesis 2011/12 38

40 4. NoSQL-Konzepte Row Column Families Person Telefon 1 Person:Name Telefon:Typ = <Nummer> Person:Geschlecht Person:Alter Tabelle 4.3.: Tabellarische Darstellung des Datenschemas Beziehungen werden wie bei CouchDB erzeugt, indem mehrere Daten geschachtelt abgespeichert werden oder die ID einer Spalte als Referenz in einem anderen Datensatz abgespeichert wird. Aber auch hier lässt sich die Beziehung nur auf Anwendungsebene auflösen Schnittstellen Für HBase existieren mehrere verschiedene Schnittstellen, um mit dem Datenbanksystem zu kommunizieren. Zum einen existieren mehrere in Java implementierte Klassen, welche es erlauben, HBase in Java-Projekte zu integrieren. Zum anderen wurden unterschiedliche programmiersprachen-unabhängige APIs entwickelt, um HBase als Datenbank-Server betreiben zu können. Allerdings werden zum Teil zusätzliche Anwendungen aus dem Hadoop-Framework vorausgesetzt. Im folgenden Abschnitt werden die wichtigsten Schnittstellen vorgestellt. REST In der HBase-Installation enthalten ist der REST-Server Stargate, welcher ebenfalls Bestandteil des Hadoop-Projektes ist. Listing 4.7 zeigt den HTTP-Request, um den Datensatz mit dem Row-Key 1 aus der Tabelle person zu erhalten. In Listing 4.8 ist die Rückgabe dargestellt. Jeder gespeicherte Wert besteht aus drei Teilen. Zum einen timestamp, welcher einen UNIX-Zeitstempel mit dem Zeitpunkt der letzten Änderung enthält und zum anderen column, welcher den Spaltenname inklusive Column Familie angibt. Der letzte Wert hat ein Dollarzeichen als Schlüssel. Dabei handelt es sich um die eigentlich gespeicherte Information. Zu beachten gilt, dass HBase die Daten als Base64-codierter String übergibt. Hinter dem Wert SGFucyBIYXVzZXI verbirgt sich beispielsweise der Name Hans Hauser. Andreas Hofstetter Masterthesis 2011/12 39

41 4. NoSQL-Konzepte Listing 4.7: Abfrage eines Datensatzes mittels REST 1 GET /social/john@example.org HTTP/1.1 2 User Agent: curl/ (amd64 pc win32) libcurl/ Host: localhost: Accept: application /json Listing 4.8: Ausgabe des REST-Requests 1 HTTP/ OK 2 Content Type: application/json 3 Transfer Encoding: chunked 4 5 {"Row":[ 6 { 7 "key":" MQ==", 8 "Cell ": 9 [ 10 { 11 "timestamp": , 12 "column":" aw5mbzpmaxjzdg5hbwu =", 13 "$ ":" SGFucyBIYXVzZXI==" 14 }, 15 { 16 "timestamp": , 17 "column":"aw5mbzpsyxn0bmftzq==", 18 "$ ":" RG9l" 19 } 20 } 21 ] 22 } Anders als bei CouchDB ist das verwendete Datenformat nicht fest vorgeschrieben. Über den HTTP-Header Accept lässt sich das gewünschte Ausgabeformat festlegen. In Listing 4.7 wurde durch den Mime-Type application/json angegeben, dass JSON verwendet werden soll. Ändert man diesen Parameter in text/xml, wird die Rückgabe, wie in Listing 4.9 dargestellt, als XML-Dokument zurückgegeben. Weitere zulässige Mime-Types sind application/x-protobuf und application/octetstream. Andreas Hofstetter Masterthesis 2011/12 40

42 4. NoSQL-Konzepte Listing 4.9: Ausgabe des REST-Requests mit geändertem Mime-Type 1 HTTP/ OK 2 Content Type: text/xml 3 Content Length: <?xml version="1.0" encoding="utf 8" standalone="yes"?> 6 <CellSet> 7 <Row key="mq=="> 8 <Cell timestamp=" " column="aw5mbzpmaxjzdg5hbwu="> SGFucyBIYXVzZXI==</Cell> 9 <Cell timestamp=" " column="aw5mbzpsyxn0bmftzq==">rg9l</cell> 10 </Row> 11 </CellSet> Thrift Als Alternative zu REST ermöglicht HBase auch einen Zugriff über Thrift. Thrift ist ein von der Apache Foundation entwickeltes Framework, um programmiersprachenübergreifende Schnittstellen zu entwickeln. Dabei wird einmalig der Service vom Entwickler in einer Meta-Sprache beschrieben. Anschließend kann dann Thrift daraus für unterschiedliche Programmiersprachen eine Client-Bibliothek erstellen. Thrift ist ebenfalls in der Grundinstallation von HBase vorhanden und kann ohne zusätzliche Installationen eingesetzt werden. In den folgenden Listings wird der Einsatz der Thrift-Bibliothek in PHP demonstriert. Zuerst wird ein neuer Datensatz hinzugefügt. Dies geschieht über sogenannte Mutations. Dabei werden zuerst mit den als Array vorhandenen Daten mehrere Mutation-Instanzen erzeugt. Anschließend wird mit mutaterow() der Datensatz angelegt. Als Parameter erhält diese Methode zuerst den Tabellennamen, dann die ID unter der der Datensatz abgelegt werden soll und zuletzt ein Array mit den Mutation-Instanzen. Wird mutaterow() eine vorhandene ID übergeben, werden die Daten überschrieben. In Listing 4.10 wird das Alter der Person geändert, die restlichen Daten bleiben unverändert. Andreas Hofstetter Masterthesis 2011/12 41

43 4. NoSQL-Konzepte Das Abfragen von Datensätzen wird durch die getrow()-methoden ermöglicht. Allerdings ist hier wieder nur ein Zugriff über die exakte Spalten-ID möglich. Listing 4.10: Datensatz mit Thrift anlegen 1 $client = new HbaseClient( $protocol ); 2 $mutations = array( 3 new Mutation( array( 4 'column' => "info:name", 5 'value' => 'Hans Hauser' 6 ) ), 7 new Mutation( array( 8 'column' => "info:alter", 9 'value' => '20' 10 ) ), 11 new Mutation( array( 12 'column' => "info:geschlecht", 13 'value' => 'männlich' 14 ) ) 15 ) ; $client >mutaterow( $table, $rowid, $mutations ); Listing 4.11: Datensatz mit Thrift ändern 1 $client = new HbaseClient( $protocol ); 2 $mutations = array( 3 new Mutation( array( 4 'column' => "info:alter", 5 'value' => '40' 6 ) ) 7 ) ; 8 9 $client >mutaterow( $table, $rowid, $mutations ); 1 $client = new HbaseClient( $protocol ); 2 $client >getrow( $table, "2" ); Listing 4.12: Datensatz mit Thrift abfragen Andreas Hofstetter Masterthesis 2011/12 42

44 4. NoSQL-Konzepte Map/Reduce Um komplexere Abfragen durchführen zu können, gibt es die Möglichkeit, Map/Reduce- Prozeduren zu verwenden. Allerdings ist Map/Reduce nicht Bestandteil der HBase- Installation und muss nachträglich hinzugefügt werden. Hive Hive bietet eine zusätzliche Abstraktionsschicht für Map/Reduce-Prozeduren. Dabei werden Abfragen mit der SQL-ähnlichen Sprache HiveQL erstellt. Hive transformiert anschließend die mit HiveQL erstellten Statements in eine Map/Reduce- Prozedur. Ziel von Hive ist es, den Einsatz von Map/Reduce zu vereinfachen und dynamisch generierte Ad-Hoc-Abfragen zu ermöglichen. In Listing 4.13 wird mit Hilfe von HiveQL die Anzahl aller Personen in der Datenbank ermittelt. Um Hive nutzen zu können, muss dies ebenfalls zusätzlich installiert werden. [George11] Listing 4.13: Anzahl der Personen über HiveQL ermitteln 1 SELECT count( * ) FROM personen; Andreas Hofstetter Masterthesis 2011/12 43

45 4. NoSQL-Konzepte 4.4. Graphendatenbanken Graphendatenbanken sind für spezielle Anwendungsfälle entworfen worden, bei denen die Beziehungen zwischen den Datensätzen eine große Rolle spielt und eine Navigation zwischen den Knoten ermöglicht werden soll. Ein Anwendungsfall wäre beispielsweise geografische Daten mit Verkehrsnetzen, wie es bei einem Navigationssystem zu finden ist. Dort kann mit Hilfe der Datenbank der kürzeste Weg oder auch alle möglichen Wege zwischen zwei Positionen ermittelt werden. Ein Beispiel für moderne Webanwendungen wären soziale Netzwerke. Dort spielen die Beziehungen zwischen den einzelnen Nutzern eine große Rolle und bilden die Grundlage einiger Funktionen. So können beispielsweise Pfade zwischen zwei nicht befreundeten Personen ermittelt werden und im Anschluss daran angezeigt werden, über welche anderen Benutzer sich diese Personen kennen könnten. Solche Anwendungsfälle lassen sich auch mit relationalen Datenbanken umsetzen. Allerdings nur unter Zuhilfenahme äußerst Join-intensiver Abfragen, die sich bei steigender Komplexität der Beziehungen und Datenaufkommen nur sehr zeitintensiv ausführen lassen. Graphendatenbanken kommen demnach da zum Einsatz, wo große Mengen an komplex vernetzten Daten performant verarbeitet werden müssen. [JansenNeo4j12] Das nun vorgestellte Datenbanksystem trägt den Titel Neo4j. Weitere nennenswerte Vertreter sind das von Google entwickelte Pregel oder FlockDB, welches vom Microblogging-Dienst Twitter veröffentlicht wurde Neo4j Das hier vorgestellte graphenorientierte DBMS trägt den Namen Neo4j. Das in Java implementierte Projekt wurde 2003 gestartet und ist seit Anfang 2010 in der Version 1.0 erhältlich. Bei Neo4j handelt es sich wie bei den meisten NoSQL-Systemen um Open-Source- Software. Allerdings wird auch eine erweiterte Version unter kommerzieller Lizenz Andreas Hofstetter Masterthesis 2011/12 44

46 4. NoSQL-Konzepte vertrieben, welche zusätzlichen Support und Funktionen bietet. Die freie Community- Version ist unter der GPLv3 Lizenz erhältlich. Aufgrund der Implementierung in Java kann Neo4j plattformunabhängig sowohl auf Windows, Linux oder Mac OS Betriebssystemen verwendet werden. Neo4j kann einerseits als eigenständiger Server betrieben werden, welcher über eine REST-Schnittstelle erreichbar ist. Alternativ kann das Projekt jedoch auch direkt in eine Java-Anwendung integriert werden. Eine Besonderheit stellt Neo4j deswegen dar, weil es sich um das einzige hier aufgeführte NoSQL-System handelt, welches eine vollständige ACID-Unterstützung bietet. [JansenNeo4j12] Datenmodell In Graphendatenbanken werden die Daten in Knoten und Kanten gespeichert. Knoten repräsentieren ein bestimmtes Objekt, zu dem Informationen gespeichert werden sollen. Dabei wird für jeden neuen Datensatz ein Knoten erzeugt. Die eigentlichen Informationen des Objektes werden innerhalb des Knotens als Key-Value- Paare abgelegt. Diese Daten sind an kein vordefniertes Schema gebunden. Das heißt, dass jeder Knoten unterschiedliche und beliebig viele Key-Value-Paare besitzen kann. Kanten stellen die Beziehung zwischen zwei Knoten dar. Dabei besitzt jede Kante einen gewissen Typ, der aussagt, in welcher Form die beiden Knoten in Beziehung stehen. Kanten können, genau wie Knoten, zusätzliche Informationen in Form von Key-Value-Paaren enthalten, welche ebenfalls an kein festes Schema gebunden sind. In Abbildung 5.10 ist das Beispiel für Personen mit Telefonnummern dargestellt. Die Ovale stellen jeweils einen bestimmten Knoten dar. Die Pfeile symbolisieren die Kanten, also die Beziehungen zwischen zwei Knoten. Der Pfeil zeigt an, dass es sich um gerichtete Beziehungen handelt. Einer Beziehung ist immer ein Typ zugewiesen. In diesem Beispiel sind beide Kanten vom Typ hat_telefon. Wird nach einem bestimmten Pfad oder Knoten gesucht, können über den Typ die möglichen Verbindungen selektiert werden. In Neo4j werden alle Knoten gleich behandelt. Um die unterschiedlichen Datentypen dennoch trennen zu können, kann den Knoten ein zusätzliches Key-Value- Andreas Hofstetter Masterthesis 2011/12 45

47 4. NoSQL-Konzepte Abbildung 4.3.: Beispieldaten in Graphendatenbanken Paar hinzugefügt werden, welchem ein Knotentyp zugewiesen wird. Anhand dieses Wertes kann dann in der Abfrage von Knoten oder in der Anwendung eine Trennung stattfinden. Im aktuellen Beispiel wird dies durch den Key Nodetyp umgesetzt. Mögliche Werte könnten hier person oder telefon sein. Eine weitere Komponente in Neo4j sind Indizes. Ein Index wird verwendet um einen Knoten oder eine Kante anhand von bestimmten Eigenschaften zu finden. Soll es im oberen Beispiel möglich sein, Knoten anhand des Namens oder der Telefonnummer zu identifizieren, ist für jede der beiden Eigenschaften ein Index nötig. Dabei muss, sobald ein neuer Knoten angelegt ist, der zu suchende Wert dem Index hinzugefügt werden. Eine Suche anhand eines Key-Value-Paares eines Objektes ohne Index ist nicht möglich. [Neo4jDokumentation12] Schnittstellen In der Installation enthalten ist eine umfangreiche webbasierte Benutzerschnittstelle, welche es ermöglicht, Daten anzulegen beziehungsweise zu bearbeiten und auch den Server zu konfigurieren. Durch eine integrierte Konsole lassen sich komplexe Abfragen testen und durch Hilfsmittel leichter erstellen. Zusätzlich bietet es auch, wie in Abbildung 4.4 zu sehen, eine visuelle Darstellung der Kanten und Knoten in der Datenbank. Andreas Hofstetter Masterthesis 2011/12 46

48 4. NoSQL-Konzepte Abbildung 4.4.: Darstellung von Beziehungen im Web-Interface Wird Neo4j als alleinstehender Server betrieben, kann über REST auf die Datenbank zugegriffen werden. In Listing 4.14 wird der HTTP-Request gezeigt, welcher den Knoten mit der ID 5 abfragt. In Listing 4.15 ist die Antwort des Server zu sehen. Neo4j setzt wie CouchDB ebenfalls auf JSON als Datenaustauschformat. Anders als bei CouchDB werden jedoch nicht nur die eigentlichen Daten zurückgegeben, sondern auch zusätzliche Informationen über den Knoten. Die Daten des Knotens befinden sich unterhalb des Schlüssels data. Sämtliche andere Werte sind Verweise auf weitere Ressourcen des Knotens. Der Key outgoing_relationships beinhaltet zum Beispiel die URI um sämtliche ausgehende Beziehungen abzufragen. Listing 4.14: Beispiel einer Knotenabfrage über REST 1 GET /db/data/node/5 HTTP/1.1 2 User Agent: curl/ (amd64 pc win32) libcurl/ Host: localhost: Accept: * / * Listing 4.15: Ergebnis der REST-Abfrage 1 HTTP/ OK 2 Content Length: Content Encoding: UTF 8 4 Content Type: application/json 5 Access Control Allow Origin: * 6 Server: Jetty (6.1.25) 7 Andreas Hofstetter Masterthesis 2011/12 47

49 4. NoSQL-Konzepte 8 { 9 "outgoing_relationships" : " http :// localhost:7474/db/data/node/5/relationships/out", 10 "data" : { 11 "Name" : "Hans Hauser", 12 "Geschlecht" : "männlich", 13 "Nodetype" : "Person", 14 " Alter " : "42" 15 }, 16 "traverse" : " http :// localhost:7474/db/data/node/5/traverse/{returntype}", 17 " all_typed_relationships " : " http :// localhost:7474/db/data/node/5/relationships/ all /{ list & types}", 18 "property" : " http :// localhost:7474/db/data/node/5/properties/{key}", 19 " self " : " http :// localhost:7474/db/data/node/5", 20 "properties" : " http :// localhost:7474/db/data/node/5/properties", 21 "outgoing_typed_relationships" : " http :// localhost:7474/db/data/node/5/relationships/out/{ list & types}", 22 "incoming_relationships" : " http :// localhost:7474/db/data/node/5/relationships/ in ", 23 "extensions" : { }, 24 " create_relationship" : " http :// localhost:7474/db/data/node/5/relationships", 25 "paged_traverse" : " http :// localhost:7474/db/data/node/5/paged/traverse/{returntype}{?pagesize,leasetime}", 26 " all_relationships " : " http :// localhost:7474/db/data/node/5/relationships/ all ", 27 "incoming_typed_relationships" : " http :// localhost:7474/db/data/node/5/relationships/ in/{ list & types}" 28 } Soll ein Knoten nicht anhand der ID sondern eines Indexes ermittelt, werden muss der GET-Parameter geändert werden. Listing 4.16 ermittelt alle Knoten, die den Namen Hans Hauser besitzen. Die Bedingung der Abfrage wird mit dem Parameter Query übergeben. Dieser Parameter besteht aus einem String mit einem oder mehreren Bedingungen in Form von Key-Value-Paaren. Über verschiedene Schlüsselwörter wie AND oder OR lassen sich mehrere Bedingungen kombinieren und die Suche verfeinern. Listing 4.16: Beispiel einer Indexsuche 1 GET /db/data/index/node/person?query=firstname:johannes%20and%20lastname:bauer HTTP /1.1 2 User Agent: curl/ (amd64 pc win32) libcurl/ Andreas Hofstetter Masterthesis 2011/12 48

50 4. NoSQL-Konzepte 3 Host: localhost: Accept:application/json Listing 4.17: Ergebnis der Indexsuche 1 HTTP/ OK 2 Content Length: Content Encoding: UTF 8 4 Content Type: application/json 5 Access Control Allow Origin: * 6 Server: Jetty (6.1.25) 7 8 [ { 9 "outgoing_relationships" : " http :// localhost:7474/db/data/node/1/relationships/out", 10 "data" : { 11 " " : "Johannes Bauer @example.org", 12 "lastname" : "Bauer", 13 "firstname" : "Johannes", 14 "password" : "pass" 15 }, 16 "traverse" : " http :// localhost:7474/db/data/node/1/traverse/{returntype}", 17 " all_typed_relationships " : " http :// localhost:7474/db/data/node/1/relationships/ all /{ list & types}", 18 "property" : " http :// localhost:7474/db/data/node/1/properties/{key}", 19 " self " : " http :// localhost:7474/db/data/node/1", 20 "properties" : " http :// localhost:7474/db/data/node/1/properties", 21 "outgoing_typed_relationships" : " http :// localhost:7474/db/data/node/1/relationships/out/{ list & types}", 22 "incoming_relationships" : " http :// localhost:7474/db/data/node/1/relationships/ in ", 23 "extensions" : { }, 24 " create_relationship" : " http :// localhost:7474/db/data/node/1/relationships", 25 "paged_traverse" : " http :// localhost:7474/db/data/node/1/paged/traverse/{returntype}{?pagesize,leasetime}", 26 " all_relationships " : " http :// localhost:7474/db/data/node/1/relationships/ all ", 27 "incoming_typed_relationships" : " http :// localhost:7474/db/data/node/1/relationships/ in/{ list & types}" 28 } ] Listing 4.18 und 4.19 zeigen ein Beispiel für eine Traversierung. Durch eine Traversierung oder Traversal werden bei einer Suche Knoten anhand von Beziehungen Andreas Hofstetter Masterthesis 2011/12 49

51 4. NoSQL-Konzepte ermittelt. Dabei wird ein Startknoten angegeben, von dem die Suche ausgehen soll. Zusätzlich werden Bedingungen übergeben, die festlegen, welche Beziehungen eingeschlossen werden müssen. In diesem Beispiel werden alle Knoten abgefragt, welche zum Knoten mit der ID 1 durch den Typ hat_telefon in Beziehung stehen. Es werden demnach alle vorhandenen Telefonnummern der Person zurückgegeben. Listing 4.18: Beispiel einer Traversierung 1 POST /db/data/node/112804/traverse/node HTTP/1.1 2 User Agent: curl/ (amd64 pc win32) libcurl/ Host: localhost: Accept: * / * 5 Content Type:application/json 6 Content Length: 97 7 {"order ":" breadth_first ", " relationships ":{" direction ":" out", "type ":" IS_FRIEND"}, "max_depth ":"1"} Listing 4.19: Ergebnis der Traversierung 1 HTTP/ OK 2 Content Length: Content Encoding: UTF 8 4 Content Type: application/json 5 Access Control Allow Origin: * 6 Server: Jetty (6.1.25) 7 8 [ { 9 "outgoing_relationships" : " http :// localhost:7474/db/data/node/92253/relationships/out", 10 "data" : { 11 " " : "Eberhard Schubert @example.org", 12 "lastname" : "Schubert", 13 "firstname" : "Eberhard", 14 "password" : "pass" 15 }, 16 "traverse" : " http :// localhost:7474/db/data/node/92253/traverse/{returntype}", 17 " all_typed_relationships " : " http :// localhost:7474/db/data/node/92253/relationships/all/{ list & types}", 18 "property" : " http :// localhost:7474/db/data/node/92253/properties/{key}", 19 " self " : " http :// localhost:7474/db/data/node/92253", 20 "properties" : " http :// localhost:7474/db/data/node/92253/properties", Andreas Hofstetter Masterthesis 2011/12 50

52 4. NoSQL-Konzepte 21 "outgoing_typed_relationships" : " http :// localhost:7474/db/data/node/92253/relationships/out/{ list & types}", 22 "incoming_relationships" : " http :// localhost:7474/db/data/node/92253/relationships/in", 23 "extensions" : { }, 24 " create_relationship" : " http :// localhost:7474/db/data/node/92253/relationships", 25 "paged_traverse" : " http :// localhost:7474/db/data/node/92253/paged/traverse/{returntype}{? pagesize,leasetime}", 26 " all_relationships " : " http :// localhost:7474/db/data/node/92253/relationships/all ", 27 "incoming_typed_relationships" : " http :// localhost:7474/db/data/node/92253/relationships/in/{ list & types}" 28 }, 29 / *... * / 30 { 31 "outgoing_relationships" : " http :// localhost:7474/db/data/node/77063/relationships/out", 32 "data" : { 33 " " : "Wolfgang Krause @example.org", 34 "lastname" : "Krause", 35 "firstname" : "Wolfgang", 36 "password" : "pass" 37 }, 38 "traverse" : " http :// localhost:7474/db/data/node/77063/traverse/{returntype}", 39 " all_typed_relationships " : " http :// localhost:7474/db/data/node/77063/relationships/all/{ list & types}", 40 "property" : " http :// localhost:7474/db/data/node/77063/properties/{key}", 41 " self " : " http :// localhost:7474/db/data/node/77063", 42 "properties" : " http :// localhost:7474/db/data/node/77063/properties", 43 "outgoing_typed_relationships" : " http :// localhost:7474/db/data/node/77063/relationships/out/{ list & types}", 44 "incoming_relationships" : " http :// localhost:7474/db/data/node/77063/relationships/in", 45 "extensions" : { }, 46 " create_relationship" : " http :// localhost:7474/db/data/node/77063/relationships", 47 "paged_traverse" : " http :// localhost:7474/db/data/node/77063/paged/traverse/{returntype}{? pagesize,leasetime}", 48 " all_relationships " : " http :// localhost:7474/db/data/node/77063/relationships/all ", 49 "incoming_typed_relationships" : " http :// localhost:7474/db/data/node/77063/relationships/in/{ list & types}" 50 } ] Andreas Hofstetter Masterthesis 2011/12 51

53 5. Einsatz in Web-Applikationen 5. Einsatz in Web-Applikationen In diesem Kapitel soll gezeigt werden, wie die vorgestellten Datenbanksysteme im Web-Umfeld eingesetzt werden können. Zu diesem Zweck wird eine exemplarische Webanwendung entwickelt. Die Anwendung wird zunächst mit herkömmlichen Datenbank-Technologien erstellt, um anschließend die Funktionalität mit NoSQL- Systemen nachzubilden. Damit sollen Stärken und Schwächen, sowie die Einsatzgebiete der jeweiligen NoSQL-Systeme offengelegt werden. Ebenfalls soll auf den praxisorientierten Einsatz der Schnittstellen der jeweiligen Systeme eingegangen werden. Für die Implementierung der Anwendung dient zunächst die für Webapplikationen verbreitete Kombination aus PHP und MySQL. Bei PHP handelt es sich um eine serverseitige Skriptsprache zur dynamischen Erstellung von Websites. Es ist die am weitesten verbreitetste Sprache für diesen Zweck.[w3techs12] Da später die Datenerhaltungsschicht ausgetauscht wird, soll die Anwendung nach der Model- View-Controller-Architektur aufgebaut werden. Dadurch wird ermöglicht, dass beim anschließenden Umstieg auf NoSQL-Datenbanken nur die Datenerhaltung, also die Model-Implementierung, ausgetauscht werden muss. Die restlichen Komponenten der Anwendung bleiben unverändert. Um diese System-Architektur umzusetzen wird das Zend-Framework eingesetzt. Verwendet wird das Zend Framework, welches eine integrierte MVC-Unterstützung bietet. [Zend12] Als Vertreter der relationalen Datenbanken wird MySQL in der Version 5.1 verwendet. MySQL wurde zunächst 1994 vom schwedischen Unternehmen MYSQL AB entwickelt, welches 2008 von Sun Microsystems aufgekauft wurde. Seit 2010 wird MySQL von der Oracle Corporation vertrieben. Zurzeit steht MySQL sowohl unter proprietärer als auch unter der freien GPL Lizenz zur Verfügung. [Kersken07] Andreas Hofstetter Masterthesis 2011/12 52

54 5. Einsatz in Web-Applikationen Abbildung 5.1.: Screenshot der Social-Media Anwendung Als Anwendungsbeispiel soll eine Social Media Plattform dienen. Social Media Anwendungen wie Facebook oder Twitter gehören zu den meist besuchten Websites weltweit [Alexa12]. Eine solche Anwendung bietet außerdem eine Vielzahl von verschiedenen Funktionen und ermöglicht so eine umfangreiche Gegenüberstellung der verschiedenen Datenbanktechnologien Funktionen Im folgenden Abschnitt sollen nun die einzelnen Funktionen der Anwendung beschrieben werden Benutzerverwaltung Sinn und Zweck einer Social Media Anwendung ist es, möglichst vielen Benutzern eine Plattform zur Verfügung zu stellen, in der sich die Anwender vernetzen und miteinander kommunizieren können. Eine grundlegende Funktion hierbei ist die Authentifizierung, indem ein User durch Benutzername und Passwort eindeutig identifiziert und vom System erkannt werden kann. Als Benutzername dient in diesem Beispiel die -Adresse des Benutzers, da diese von vornherein eindeutig einer Person zugewiesen werden kann. Die Herausforderung liegt hier in der hohen Anzahl der Benutzer. Erfolgreiche Plattformen haben meist mehrere Millionen Benutzereinträge, welche beim Authentifizierungsversuch in kurzer Zeit durchlaufen werden müssen. Andreas Hofstetter Masterthesis 2011/12 53

55 5. Einsatz in Web-Applikationen Abbildung 5.2.: HTML-Formular zum Bearbeiten des Steckbriefs Profil Außerdem soll ein Benutzer über Social Media Anwendungen anderen Anwendern Informationen über sich preisgeben können. Hierzu dient ein Benutzerprofil in Form eines Steckbriefes. Dabei kann der Benutzer frei wählen, welche Eigenschaften der Steckbrief abfragen soll. So kann ein Benutzer die über ihn angezeigten Informationen frei gestalten. Diese generische Datenstruktur soll zeigen, wie flexibel das Datenschema der Systeme verwendet werden kann Livesearch Hat sich eine Person im sozialen Netzwerk angemeldet, muss dieser auch die Möglichkeit haben, andere Benutzer zu finden und selbst gefunden zu werden. Dazu wird eine Personensuche implementiert, die während der Eingabe des Suchbegriffes bereits die Datenbank nach möglichen Treffern durchsucht und dabei mögliche Personen vorschlägt. Hier kann wie bei der Authentifizierung die Anzahl der Benutzer problematisch werden. Zusätzlich entstehen dadurch sehr viele Anfragen an den Datenbank-Server. Diese müssen schnell verarbeitet werden, da die Ausgabe der Vorschläge direkt nach der Eingabe eines neuen Zeichens erfolgen soll. Andreas Hofstetter Masterthesis 2011/12 54

56 5. Einsatz in Web-Applikationen Abbildung 5.3.: Vorgeschlagene Personen durch die Live-Suche Bei einer solchen Suche wird zudem nicht nur nach exakten Treffern verlangt. Der Suchbegriff kann auch lediglich aus einem Teil des Namens bestehen. Wird beispielsweise nach Schm gesucht sind sowohl Schmidt als auch Schmieder übereinstimmende Werte. Man spricht hier von so genannten Wildcard-Suchen. Des Weiteren besteht in diesem Anwendungsfall die Problematik, dass die Eingabe aus unterschiedlichen Informationen, also Vornamen, Nachnamen oder einem vollständigen Namen bestehen kann Freundschaften Zentrale Funktion einer Social Community ist die Vernetzung von Freunden und Bekannten. Dabei soll es möglich sein Freundschaften abzubilden und anzuzeigen. Es soll ebenfalls möglich sein über die Freunde von eigenen Freunden weitere Kontakte zu finden. Dazu sollen auf der Profilseite eines Nutzers Verbindungen über mehrere Freundschaftsbeziehungen hinweg zwischen diesem und dem angemeldeten Benutzer angezeigt werden. Mit dieser Friend-of-a-Friend-Funktion werden alle möglichen Freundschaftspfade bis zum fünften Grad ermittelt und die Verbindungspunkte, also die befreundeten Nutzer, werden angezeigt. Für jeden Benutzer wird zusätzlich die Anzahl seiner Freunde ermittelt. Andreas Hofstetter Masterthesis 2011/12 55