Anwendungsorientierte Evaluation dokumentenorientierter

Fachhochschule Aachen
Campus Jülich
Fachbereich Medizintechnik und Technomathematik
Scientific Programming
Anwendungsorientierte Evaluation dokumentenorientierter
Datenbanksysteme
Seminararbeit von Robin Landsmann
Aachen, den 15. Dezember 2013
Inhaltsverzeichnis
1. Einleitung und Motivation...................................................................................................4
1.1 Einleitung.....................................................................................................................4
1.2 Der Istzustand..............................................................................................................4
1.3 Motivation.....................................................................................................................5
1.4 Ziel der Arbeit...............................................................................................................5
2. Einführung in Datenbanken...............................................................................................7
2.1 Eigenschaften einer Datenbanken..............................................................................7
2.2 Datenbankmodelle in der Übersicht............................................................................7
2.2.1 Hierarchische Datenbanken.................................................................................8
2.2.2 Netzwerkdatenbanken..........................................................................................8
2.2.3 Objektorientierte Datenbanken.............................................................................8
2.2.4 Relationale Datenbanken.....................................................................................9
2.2.4.1 Das Konsistenzmodell ACID.......................................................................10
2.2.5 Objektrelationale Datenbanken..........................................................................10
2.3 Normalisierung...........................................................................................................10
2.3.1 Erste Normalform................................................................................................11
2.3.2 Zweite Normalform.............................................................................................11
2.3.3 Dritte Normalform...............................................................................................12
2.4 Folgen der Normalisierung für die antibodies-online GmbH.....................................13
3. Einführung in NoSQL.......................................................................................................14
3.1 NoSQL Grundlagen...................................................................................................15
3.2 Das CAP Theorem.....................................................................................................15
3.2.1 Konsistenzmodelle.............................................................................................16
3.2.2 Map/Reduce.......................................................................................................17
3.2.3 Multiversion Concurrency Control......................................................................18
3.2.4 REST..................................................................................................................19
3.3 NoSQL Systeme........................................................................................................19
3.3.1 Wide Column Stores..........................................................................................19
3.3.2 Key/Value-Systeme............................................................................................20
3.3.3 Graphdatenbanken.............................................................................................20
4. Dokumentenorientierte Datenbanken..............................................................................21
4.1 CouchDB....................................................................................................................21
4.1.1 Datenmodell.......................................................................................................21
4.1.2 Map/Reduce und Views.....................................................................................22
4.1.3 Replikation..........................................................................................................22
4.1.4 Skalierbarkeit......................................................................................................22
4.1.5 Zugriffskontrolle..................................................................................................22
4.2 MongoDB...................................................................................................................23
4.2.1 Datenmodell.......................................................................................................23
4.2.2 Map/Reduce.......................................................................................................24
4.2.3 Replikation..........................................................................................................24
4.2.4 Skalierbarkeit......................................................................................................24
4.2.5 Zugriffskontrolle..................................................................................................25
4.3 Multimodel-Datenbanken...........................................................................................25
4.3.1 OrientDB.............................................................................................................25
4.3.1.1 Datenmodell................................................................................................25
4.3.1.2 Map/Reduce................................................................................................25
4.3.1.3 Replikation...................................................................................................26
4.3.1.4 Zugriffskontrolle...........................................................................................26
5. Fazit..................................................................................................................................27
1. Einleitung und Motivation
Diese Arbeit behandelt das Thema anwendungsorientierte Evaluation dokumentenorientierter Datenbanksysteme am Fallbeispiel der antibodies-online GmbH. Hierzu werden
kurz der Ist-Zustand und die Motivation beschrieben, gefolgt von einer allgemeinen Einführung in Datenbanken und den Begriff NoSQL. Dann werden dokumentenorientierte Datenbanken im Detail behandelt. Zum Abschluss werden mehrere Datenbanksysteme
beschrieben und miteinander verglichen.
1.1 Einleitung
Für einen Onlineshop ist es wichtig Produktdaten stets aktuell, vollständig und für den
Kunden möglichst übersichtlich bereit zu stellen. Die Produktdaten werden in einer Datenbank gespeichert, die das Shopsystem mit allen Informationen versorgt.
Die Daten müssen jedoch zuerst einmal in die Datenbank eingespeist und im Regelfall
vorher noch aufbereitet werden. Hierbei ist es enorm wichtig, dass es nicht zu Ausfällen im
Shop oder für den Kunden spürbaren Ladezeitverzögerungen kommt, wenn Produktdaten
bearbeitet werden, da dies zu Frustration im Einkaufserlebnis des Kunden führt und dieser
den Einkauf abbrechen kann.
Die antibodies-online GmbH ist ein Onlinemarktplatz für Forschungsantikörper mit über
einer Millionen verfügbaren Produkten von mehr als 130 Herstellern. Sie stellt keine eigenen Produkte her, sondern ist ein reiner Reseller im Bereich der biologischen Forschung.
1.2 Der Istzustand
Momentan gibt es eine MySQL-Datenbank in der alle Daten des Onlineshops verwaltet
werden. Es liegen zur Zeit etwa 1,6 Millionen Produkte in acht Produktkategorien vor, die
über 100 Produktattribute beinhalten können. Allen Produkten liegt, ungeachtet der Kategorie das selbe Schema zugrunde. Die Datenbank befindet sich in der dritten Normalform1.
Für ein Update, wenn beispielsweise ein Hersteller aktuellere Informationen liefert, müssen die Produktdaten des betreffenden Herstellers in Dateien exportiert werden, da die
Bearbeitung durch Mitarbeiter mit externen Programmen erfolgt. Die aktuellen Informationen werden mit den Neuen verglichen und bei Bedarf aktualisiert. Danach werden die
aktualisierten Informationen wieder importiert. Sowohl Im- als auch Exporte werden über
1
Nähere Behandlung im Kapitel Normalisierung
4
CSV-Dateien (Comma-seperated value) realisiert. Dies ist nötig, da ein Format benötigt
wird, das sowohl von den Bearbeitungsprogrammen, als auch von den Bearbeitern gelesen werden kann. Durch die hohe Anzahl an Produktattributen kommt es zu langen Ladezeiten beim bereitstellen der Exporte2, die die Bearbeitung verzögern.
1.3 Motivation
Die Kontrolle über die Produktdaten soll künftig in den Händen der Mitarbeiter liegen, die
diese bearbeiten. Die Datenlage soll nicht mehr vom Shopsystem abhängig sein. Das
neue System soll den Mitarbeitern einen schnellen Zugriff auf die Daten ermöglichen. Es
soll nicht zu Verzögerungen im Bearbeitungsprozess kommen, weil Mitarbeiter auf Daten
warten müssen. Durch das separate System soll die Last auf den Live-Server gemindert
werden, da von diesem keine Exporte mehr bereitgestellt werden müssen. Zudem sollen
Metainformationen zu Produkten gespeichert werden können, die für den Kunden nicht
von Bedeutung sind, sondern nur der Klassifizierung für die Mitarbeiter dienen und somit
auch nicht an die Shop-Datenbank ausgeliefert werden müssen.
Zudem soll es eine Versionierungsmöglichkeit geben, um nachvollziehen zu können, wann
und wie ein Produktdatensatz verändert oder gelöscht wurde und dies Rückgängig
gemacht werden kann.
Da die Produktdaten bei der antibodies-online GmbH aus heterogenen Quellen in verschiedenen Dateiformaten geliefert werden, die stellenweise inhaltliche Fehler aufweisen
und diese sich in einer Datei mit 10-Tausenden Datensätzen nicht finden lassen, ist es
kaum zu vermeiden, dass fehlerhafte Daten bereitgestellt werden. Das System muss eine
Möglichkeit bereit stellen, solche Fehler schnell zu finden und zu beheben.
Das System soll ebenfalls eine Möglichkeit für ein Monitoring bieten, mit dem die Qualität
der Daten geprüft werden kann. Die Regeln der Prüfung werden durch Mitarbeiter festgelegt und eingetragen.
Um Mitarbeitern, die nicht am Bearbeitungsprozess beteiligt sind, die Möglichkeit zu bieten, auf Produktdaten zuzugreifen, soll es eine Möglichkeit geben, das System zu replizieren.
1.4 Ziel der Arbeit
Ziel der Arbeit ist es zu evaluieren, ob eine dokumentenorientierte Datenbank die Möglichkeit bietet, den in der Motivation beschriebenen Anforderungen zu genügen. Zusätzlich
2
Siehe Kapitel Normalisierung
5
soll das System benannt werden, das im Fallbeispiel der antibodies-online GmbH das
Beste ist.
6
2. Einführung in Datenbanken
Um die Problemstellung der Arbeit und den Ist-Zustand der anitbodies-online GmbH besser zu verstehen, wird im Folgenden beschrieben, worum es sich bei einer Datenbank
handelt, sowie einige Datenbankmodelle mit ihren Eigenschaften vorgestellt.
2.1 Eigenschaften einer Datenbank
"Eine Datenbank ist eine strukturierte Sammlung von Daten"[KM01 ]. Diese Aussage hat
keinen Hohen Informationsgehalt, beschreibt jedoch hinreichend, um was es sich bei einer
Datenbank handelt. Zudem sagt sie explizit aus, was eine Datenbank nicht ist: Eine
unstrukturierte Datei oder Dateiensammlung. Theoretisch reicht also schon eine strukturierte Textdatei aus, um als Datenbank bezeichnet zu werden. In der Praxis ist dies nicht
der Fall, da es eine der grundlegenden Eigenschaften von Datenbanken ist, dass eine
Umstellung der Anwendung, die mit den Daten arbeitet, keine Änderungen an den Daten
nach sich ziehen soll. Auch der umgekehrte Fall, dass Programme die mit einer Datenbank arbeiten keiner oder nur minimaler Änderungen bedarf, falls sich die Daten ändern.
Bei einer Textdatei als Datengrundlage muss für jede Änderung in der Datei die Zugriffsmethode angepasst werden. Entsprechend widerspricht das dem genannten Grundgedanken.
Eine weitere Möglichkeit Informationen zu speichern bieten XML-Dateien. Hier ist in der
Regel keine Änderung der Zugriffsmethoden nötig, wenn sich der Datenbestand ändert.
Für größere Datenmengen ist das speichern in XML-Dateien jedoch unpraktisch, sodass
eine XML-Datei als Datengrundlage für ein Anwendungsprogramm vorrangig dort eingesetzt werden wo kleine Datenmengen gespeichert werden müssen, und kein komplexes
Datenbanksystem benötigt wird. Ein Anwendungsbeispiel sind hier Apps für Smartphones.
Programme und Anwendungen die mit größeren Datenmengen arbeiten setzen daher auf
SQL-Datenbanken und Datenbanksysteme . SQL steht für Structed Query Language und
ist eine simple Abfragesprache, mit der mit wenigen Befehlen Datensätze gelesen, bearbeitet und gelöscht werden können. Die Informationen können hierbei im DBMS in unterschiedlicher Form gespeichert werden. Baumstrukturen sind hierbei die gängigsten.
2.2 Datenbankmodelle in der Übersicht
Es gibt verschiedene Formen von Datenbanken. Relationale SQL-Datenbanken sind durch
vielfältige Anwendungsmöglichkeiten und einfache Bedienung am weitesten verbreitet.
7
Außerdem gibt es noch einige andere Datenbankformen, die auf spezielle Anforderungen
zugeschnitten sind und daher nur in ihren speziellen Gebieten eingesetzt werden. Zu diesen gehören unter Anderen hierarchische Datenbanken, objektorientierte Datenbanken
und Netzwerkdatenbanken, deren Funktion hier nur kurz erläutert werden.
2.2.1 Hierarchische Datenbanken
Das hierarchische Datenbankmodell ist eines der ältesten Datenbankmodelle. Es bildet die
Datensätze in einer Baumstruktur ab, sodass jeder Datensatz genau einen Vorgänger hat.
Der Nachteil dieser Struktur ist, dass eine Verknüpfung der Daten über mehrere Ebenen
hinweg oder mit anderen Bäumen nicht möglich ist. Das bekannteste hierarchisch organisierte Datenbanksystem ist IMS/DB von IBM.
2.2.2 Netzwerkdatenbanken
Das Netzwerkdatenbankmodell wurde von der selben Organisation wie die Programmiersprache COBOL entwickelt und ist entsprechend stark von ihr geprägt.
Im Modell selber, herrschen keine strengen Hierarchien, Datensätze können mehrere Vorgänger und Nachfolger haben. Es kann, anders als im hierarchischen Datenbankmodell
mehrere Wurzeln geben, dadurch gibt es meist mehrere Suchwege einen bestimmten
Datensatz zu finden.
Zusätzlich zu dieser verzweigten Datenstruktur sieht das Modell drei verschiedene Datenbanksprachen für die verschiedenen Aufgaben vor. Eine Schema Data Description Language, die die Form der Daten beschreibt, eine Subschema Data Description Language,
die Metainformationen über die Daten liefert, und eine Data Manipulation Language, die
das Lesen und Schreiben der Daten übernimmt.
Bekannte Netzwerkdatenbanksysteme sind UDS (Universal Databank System, Siemens)
und DMS(Database Management System, Sperry Univac).
Als aktuellen Nachfolger der Netzwerkdatenbank kann man die Graphdatenbanken 3
bezeichnen.
2.2.3 Objektorientierte Datenbanken
Wie der Name schon sagt, werden die Daten beim Objektorientierten Datenbanksystem in
Form von Objekten, wie sie aus Programmiersprachen wie Java bekannt sind, gespeichert. Nicht zu verwechseln mit serialisierten Objekten! Auch die Methoden des Objekts
3
Siehe Kapitel Graphdatenbanken
8
werden gespeichert. Der Vorteil dieses Modells ist, dass es keiner weiteren Datenbanksprache bedarf, sondern die Anwendung kann direkt mit der Datenbank kommunizieren.
2.2.4 Relationale Datenbanken
In relationalen Datenbanken stehen die Daten in einer Beziehung (Relation) zueinander.
Die Daten selber werden in Form von Tupel von Attributen nach einem festgelegten Schema gespeichert. Die Tupel der einzelnen Datensätze werden wie in Tabelle 1 zu sehen in
Tabellen zusammengefasst.
AutoNr
Hersteller
Modell
Farbe
1337
Ferrari
F-50
Rot
1337
Ferrari
F-50
Schwarz
4711
Mercedes
SLS
Schwarz
42
Ferrari
Enzo
Rot
Tabelle 1: Beispiel Attribute
Die Eigenschaften, die ein Objekt, hier im Beispiel das Auto, hat, sind durch das Relationsschema festgelegt. So auch die Relationen mehrerer Objekte untereinander. Dabei gibt es
mehrere Arten von Beziehungen, 1:n, 1:1 oder auch m:n.
Der Einfachheit halber wird davon ausgegangen, dass jedes Auto nur einen Besitzer hat,
ein Besitzer aber mehrere Autos besitzen kann. Dann sieht die Relation zwischen Auto
und Besitzer wie folgt aus:
Abbildung 1: Beispiel Relation
Man spricht dann bei Auto und Besitzer von Entitätentypen oder Entitäten.
Jedes Objekt im Relationsschema wird durch eine Reihe von Attributen eindeutig
bestimmt. Diese nennt man Primär- oder Schlüsselattribute.
Angesprochen werden relationale Datenbanken meist über eine SQL-Sprache, deren
Grundlage die Relationsalgebra bildet. Neben einfachen Abfragen einzelner Objekte oder
Werte, lassen sich auch Mengen von Objekten zu einer Menge zusammenfassen, Ergebnismengen Filtern oder Maxima und Minima bestimmen. Welche Funktionen zusätzlich
noch bereit gestellt werden hängt vom gewählten Datenbankmanagementsystem ab.
9
2.2.4.1 Das Konsistenzmodell ACID
Relationalen Datenbanken liegt das sogenannte ACID-Konsistenzmodell zugrunde. ACID
steht für Atomicity Consistency Isolation Durability. Das heißt eine Datenbanktransaktion
hat immer diese Eigenschaft. Jede Transaktion ist atomar, das heißt auch wenn eine
Transaktion aus mehreren Befehlen besteht, die nacheinander ausgeführt werden, gilt sie
erst dann als fertig, wenn alle Befehle fehlerfrei abgearbeitet sind. Kommt es während der
Befehlskette zu Fehlern, werden die Daten automatisch in den Zustand zurückversetzt,
der vor den ersten Befehl herrschte. Die Isolation bedeutet, jeder zu bearbeitende Datensatz wird während der Transaktion für andere Zugriffe gesperrt. Die Daten müssen Dauerhaft sein, es muss also gewährleistet sein, dass bei einem Programmabsturz während
einer Transaktion entweder der Ursprungszustand hergestellt wird oder die Transaktion
erneut komplett durchgeführt wird. Eine Änderung der Daten muss konsistent sein, man
kann also nicht zwischen den einzelnen Stadien der Transaktion hin und herwechseln.
2.2.5 Objektrelationale Datenbanken
Das objektrelationale Datenbankmodell versucht das relationale und das objektorientierte
Modell miteinander zu verbinden. Es erweitert das relationale Modell um die Möglichkeit
objektorientierte Methoden und Datentypen zu verwenden. Hierzu wird häufig über eine
bestehende relationale Datenbank eine objektorientierte Zugriffsschicht gesetzt, die es
dem Entwickler ermöglicht seine Daten als Objekte zu behandeln.
2.3 Normalisierung
Normalisierung beschreibt die Aufteilung einzelner Schemata (Tabellen) eines relationalen
Datenbankschemas in mehrere Schemata um Redundanz zu vermeiden. So wird vermieden, dass in einem Datenbestand, beispielsweise eine Adressänderung in einer Kundendatenbank, inkonsistente Daten entstehen wenn ein Datensatz geändert wird, der zweite
aber nicht, etwa wenn es die Tabellen Rechnungs- und Lieferadressen gibt.
Zudem wird bei großen Datenmengen Speicherplatz gespart, da eine Information wie Marke eines Autos nur einmal gespeichert werden muss und nicht für jedes Objekt.
Es gibt mehrere Grade der Normalisierung, die mit aufsteigender Zahl einen immer stärker
werdenden Redundanzschutz bieten.
Um einen kompletten Datensatz zu erhalten werden die Daten aus den einzelnen Tabellen
über einen Zusammenfassungsbefehl (Join), zu einem Objekt gebündelt.
10
2.3.1 Erste Normalform
In der ersten Normalform muss jedes Attribut das in der Relation vorkommt einen atomaren Wertebereich haben und die Relation muss frei von Wiederholungen sein.
In Tabelle 2 beinhaltet die Spalte Modell das Modell und den Hersteller und die Spalte Farbe enthält eine Menge von Farben.
AutoNr
Modell
Farbe
1337
Ferrari F-50
Rot, Schwarz
4711
Mercedes SLS
Schwarz
42
Ferrari Enzo
Rot
Tabelle 2: Negativbeispiel erste Normalform
Das Feld Modell wird, wie in Tabelle 3 zu sehen, in Hersteller und Modell aufgeteilt um die
Informationen zu separieren. Zusätzlich wird der Datensatz mit zwei Farben in zwei eigenständige Datensätze mit jeweils nur einer Farbe aufgeteilt.
AutoNr
Hersteller
Modell
Farbe
1337
Ferrari
F-50
Rot
1337
Ferrari
F-50
Schwarz
4711
Mercedes
SLS
Schwarz
42
Ferrari
Enzo
Rot
Tabelle 3: Positivbeispiel erste Normalform
2.3.2 Zweite Normalform
Eine zweite Normalform liegt dann vor, wenn die Daten in erster Normalform sind und
jedes nicht-Schlüsselattribut von allen Schlüsselattributen abhängig ist.
Der Primärschlüssel dieser Relation in Tabelle 4 setzt sich aus AutoNr und Farbe zusammen, da diese ein Auto im Beispiel eindeutig charakterisieren. Die Eigenschaften Hersteller und Modell sind jedoch nur von der AutoNr abhängig, nicht von der Farbe.
AutoNr
Hersteller
Modell
Farbe
1337
Ferrari
F-50
Rot
1337
Ferrari
F-50
Schwarz
4711
Mercedes
SLS
Schwarz
42
Ferrari
Enzo
Rot
Tabelle 4: Negativbeispiel zweite Normalform
11
In Tabelle 5 sieht man, dass das Attribut AutoNr nun ein Fremdschlüssel ist, der auf eine
weitere Tabelle verweist, die die Farbe enthält.
AutoNr
Hersteller
Modell
AutoNr
Farbe
1337
Ferrari
F-50
1337
Rot
4711
Mercedes
SLS
1337
Schwarz
42
Ferrari
Enzo
4177
Schwarz
42
Rot
Tabelle 5: Positivbeispiel zweite Normalform
2.3.3 Dritte Normalform
Eine dritte Normalform liegt dann vor, wenn die Daten in erster Normalform sind und es
kein nicht-Schlüsselattribut gibt, das von einem Schlüsselattribut transitiv abhängig ist.
Transitive Abhängigkeit bedeutet, dass es eine Unterabhängigkeit gibt, bei der durch einen
nicht-Schlüsselkandidaten eine Abhängigkeit entsteht, sodass der Schlüsselkandidat von
einem anderen Attribut abhängig wird.
Als Formel veranschaulicht, wird die Transitive Abhängigkeit wie folgt dargestellt:
( P 1 → A1)∧( A1 → A2 )⇒(P 1 → A2 )
Im Beispiel aus Tabelle 6 ergibt sich durch die Herstellerangabe eine transitive Abhängigkeit: Die Autonummer ist durch das Modell transitiv vom Hersteller abhängig.
AutoNr
Hersteller
Modell
1337
Ferrari
F-50
4711
Mercedes
SLS
42
Ferrari
Enzo
Tabelle 6: Negativbeispiel dritte Normalform
Diese Abhängigkeit lässt sich durch ein Aufteilen in einzelne Tabellen, wie in Tabelle 7 zu
sehen, wieder lösen.
AutoNr
HerstellerNr
Modell
HerstellerNr
HerstellerName
1337
31415
F-50
31415
Ferrari
4711
27182
SLS
27182
Mercedes
42
31415
Enzo
Tabelle 7: Positivbeispiel dritte Normalform
12
2.4 Folgen der Normalisierung für die antibodies-online GmbH
In den bisherigen Beispielen wurden die Tabellen immer in maximal 2 Tabellen aufgeteilt.
Durch die hohe Anzahl an Produktattributen gibt es in der Datenbank der antibodies-online
GmbH über 100 dieser Tabellen, die alle Informationen zu einem einzelnen Produkt enthalten können. Um alle Informationen für ein Produkt zu erhalten müssen über 100 Tabellen abgefragt und zusammengefasst werden.
Die Abfrage eines Attributes dauert ca. eine Millisekunde. Bei einem Produkt mit 100 Attributen dauert die Abfrage entsprechend ca. 100 Millisekunden. Für die Exporte müssen
mehrere tausend Produktdatensätze gelesen werden, sodass sich die Anzahl der Anfragen und somit auch die Lesedauer um diesen Faktor erhöht. Hinzu kommt noch die Dauer
die das System braucht um die CSV-Datei zu erstellen. Dies sorgt für Verzögerungen bei
der Bearbeitung von Produktdaten, da Mitarbeiter häufig warten müssen, bis alle Datensätze gelesen und in die benötigte Datei geschrieben wurden. Eine Denormalisierung der
Daten ist keine Lösung des Problems, da die Tabelle der verwendeten MySQL-Datenbank
die Dateigrößenrestriktion überschreiten würde.
Um diesem Problem zu entgehen wird eine andere Art von Datenbank benötigt.
13
3. Einführung in NoSQL
Der Begriff NoSQL tauchte erstmals Ende der 1990er Jahre auf[EFHBB11], der große
Schub kam aber erst Anfang der 2000er, mit dem Web 2.0 und dem Versuch große Datenmengen im hohen Gigabyte bzw. Terabyte Bereich zu verwalten[EFHBB11]. Erste Vorreiter
der aktuellen Systeme gab es bereits in den 80ern, jedoch mit wesentlich kleineren Datenmengen. Ein Beispiel aus dieser Zeit ist Lotus Notes. Ab 2006 entstanden dann die heutigen Systeme wie Couch DB, Voldemort, Hypertable, Cassandra, Redis usw. . NoSQL stellt
keine radikale Abwendung zu relationalen Systemen dar, sondern bedeutet Not only SQL.
Das Buch „NoSQL“ bietet folgende Definition für NoSQL, bei der sich die Autoren auch auf
andere Quellen beziehen: „Unter NoSQL wird eine neue Generation von Datenbanken
verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen :“[EFHBB11]
1. Das Datenmodell ist nicht relational
2. Das System ist auf verteilte und horizontale Skalierbarkeit ausgelegt
3. Das System ist Open Source
4. Das System ist nur schwach Schemagebunden oder sogar Schemafrei
5. Das System unterstützt eine einfache Datenreplikation
6. Das System stellt eine einfache API zur Verfügung
7. Das System basiert auf einem andern Konsistenzmodell als ACID
Jeder dieser Punkte kann diskutiert werden, da NoSQL einen Denkansatz in Bezug auf
Datenbanken beschreibt und keine Formel ist.
Zum ersten Punkt lässt sich sagen, dass NoSQL das relationale System nicht als ungültig
oder schlecht beschreibt. Vielmehr ist NoSQL ein alternativer Denkansatz für bestimmte
Problemstellungen, sodass diese nicht umständlich in ein relationales System gebracht
werden müssen, wenn sie mit einem anderen Datenbankmodell einfacher in den Griff zu
bekommen sind.
Punkt zwei bezieht sich auf das Speichern und Verwalten extrem großer Datenmengen im
Tera- oder sogar Petabyte Bereich. Hier reicht normale Hardware nicht mehr aus und die
Daten müssen auf mehrere Systeme verteilt werden. Datenbanksysteme die sich nicht auf
solche Datenmengen spezialisieren können NoSQL Datenbanken sein, ohne sich auf
mehrere Systeme zu verteilen.
Selbst die Autoren sehen den dritten Punkt als umstritten an .Auch Amazon SimpleDB ist
14
ein NoSQL-System obwohl es nicht Open Source ist. Dieser Punkt beruht darauf, dass in
der Industrie oft viel Geld für Datenbanksysteme ausgegeben wird, die dennoch ein gegebenes Problem nicht ideal lösen.
Mit dem vierten Punkt greifen die Autoren eine feste Anforderung an Datenbanken des
Web 2.0 auf. Bei einer Schemaänderung muss nicht die komplette Datenbank an dieses
angepasst werden, sondern der alte Datenbestand kann im laufenden Betrieb in das neue
Format überführt werden.
Punkt fünf ergibt sich aus der Forderung nach horizontaler Skalierbarkeit, um beim Ausfall
eines Systems ein Backup zu haben. NoSQL Systeme die den zweiten Punkt nicht oder
nur teilweise erfüllen, erfüllen meistens auch den fünften nicht. Läuft die Datenbank nicht
auf einem verteilten System schließt dies eine Replikationsmöglichkeit jedoch nicht aus.
Die Forderung nach einer einfachen API aus Punkt 6, sagt nicht aus, dass SQL keine einfache, aber dennoch mächtige Abfragesprache ist. Vielmehr wir hier eine API gefordert,
die zum System passt, für Laien einfach zu bedienen ist, und auch nicht so mächtig sein
muss wie SQL. Je nach Anwendungsgebiet variiert die Komplexität und Mächtigkeit einer
NoSQL-API.
Die Eigenschaften des in Punkt sieben geforderten Konsistenzmodells und die damit verbundenen Folgen werden in den Folgenden Kapiteln näher beschrieben.
3.1 NoSQL Grundlagen
Um das System von NoSQL Datenbanken zu verstehen müssen zuerst einige Begriffe
definiert und erklärt werden. Einige davon gehören zum traditionellen Umgang mit Datenbanken, andere beziehen sich speziell auf nicht relationale Datenbanken.
3.2 Das CAP Theorem
Im Jahr 2000 Stellte Prof. Eric Brewer auf der PODC2000 sein CAP Theorem vor. CAP
steht für:
• Consistency: Die Daten einer Transaktion müssen nach der Durchführung genauso Konsistent sein wie davor. Entweder wird eine Transaktion komplett durchgeführt oder gar
nicht. Auch bei einer Datenbank die auf mehreren Systemen verteilt laufen, muss sichergestellt sein, dass eine Änderung der Daten auf allen Systemen gleichzeitig abläuft.
15
• Availability: Die Verfügbarkeit der Daten muss zu jeder Zeit gegeben sein. Im Bezug auf
eine Datenbank mit verteilten Systemen bedeutet dies, dass die übrigen Systeme weiterhin Daten liefern müsse, wenn eins ausfällt.
• Partition Tolerance: Bei verteilten Datenbanken kann es vorkommen, dass ein Datensatz
auf den Systemen in einem Inkonsistenten Zustand ist. Die kann zum Beispiel an einem
kaputten Datenkabel liegen. Das System muss gewährleisten dass bei einer Anfrage an
die Server beide Systeme den richtigen Datensatz zurückliefern.
Brewers Cap Theorem besagt, dass bei Skalierten Datenbanksystemen immer nur zwei
dieser drei Punkte gewährleistet werden können. 2002 wurde diese Theorie am MIT
bewiesen[OK12]. Es ergeben sich drei mögliche Verteilungen der Punkte:
• Availability und Consistency (AC): „Darunter fallen die meisten Relationalen Datenbanksysteme“[OK12]. Die Daten sind zu jeden Zeitpunkt Verfügbar und Konsistent.
• Availability und Partition Tolerance (AP): Die Daten sind zu jeden Zeitpunkt Verfügbar
und das System arbeitet auch, wenn der Kommunikationsweg zwischen einzelnen
Datenbanken des Systems nicht funktioniert.
• Consistency und Partition Tolerance (CP): Die Daten sind immer Konsistenz und das
System arbeitet auch, wenn der Kommunikationsweg zwischen einzelnen Datenbanken
des Systems nicht funktioniert, jedoch kann es dazu kommen, dass die Datenbank während einer Replikationsphase nicht verfügbar ist.
3.2.1 Konsistenzmodelle
Da zur Zeit der Entstehung relationaler Datenbanken Anwendungsgebiete wie beispielsweise Bank- und Kontodaten im Fokus lagen, hatte die Konsistenz der Daten oberste Priorität . Es kommt also nur eine Datenbank mit den CAP-Eigenschaften AC oder CP in Frage.
Mittlerweile gibt es Clustersysteme, bei denen eine Datenbank als Master fungiert und als
Backup mehrere Klone aufweist, um bei einem Systemausfall weiterhin Daten bereitstellen
zu können. Konsistenz der Daten würde hier heißen, dass zu jedem Zeitpunkt von allen
Systemen die gleichen Daten geliefert werden. Ändert sich also ein Datensatz auf dem
Mastersystem, kann dieser erst von den Klonen gelesen werden, nachdem diese repliziert
16
wurden. Bei Onlineshops reicht schon eine minimale Wartezeit im Bestellprozess aus, um
einen Kunden zu verärgern oder im schlimmsten Fall sogar den Bestellvorgang abbrechen
zu lassen und sich eine Alternative zu suchen. Es muss also Gewährleistet sein, dass die
Daten immer verfügbar sind.[WWW1] Es kommt also nur eine Datenbank mit den CAPEigenschaften AC oder AP in Frage.
Basierend auf den Erkenntnissen des CAP Theorems wird ein Konsistenzmodell entwickelt, dass den Gegensatz zum ACID System darstellt. Es nennt sich BASE (Basically
Available, Soft State, Eventually Consistent). Bei diesem System steht die Verfügbarkeit
der Daten im absoluten Fokus. Konsistenz spielt zwar eine wichtige, aber dennoch untergeordnete Rolle. Es wird davon ausgegangen, dass die Konsistenz durch Replikationszyklen erreicht wird, also nicht unmittelbar nach jeder Transaktion, aber nach einem gewissen Zeitfenster der Inkonsistenz. Die Dauer dieses Zeitfenster kann dabei je nach System,
Konfiguration und Anwendungsbereich variieren.
Dennoch sind nicht alle Datenbanksysteme entweder komplett ACID oder komplett BASE
gebunden, sondern es gibt einen fließenden Übergang zwischen diesen beiden Gegensätzen. Relationale Systeme liegen hierbei sehr nah an der ACID Variante, während die meisten NoSQL Systeme sich eher in Richtung BASE orientieren[EFHBB11].
3.2.2 Map/Reduce
Map/Reduce hat seine Ursprünge in Funktionale Programmiersprachen wie LISP 4 und
ML5, die speziell auf parallelisiertes arbeiten ausgelegt sind. Dadurch dass alle Datensätze
unabhängig von einander betrachtet werden können, ist eine Parallelisierung des Prozesses und somit eine Geschwindigkeitsoptimierung möglich.
Mit der map()-Funktion wird hier eine Funktion auf jedes Element der Liste angewandt und
die dadurch modifizierte Liste zurückgegeben. Das folgende Beispiel orientiert sich wieder
am Beispieldatensatz der Autos aus Kapitel 2. Es sollen alle Autos der Firma Mercedes
ausgegeben werden:
Function(doc){
if(doc.Marke == „Mercedes“){
emit(doc.Modell, doc.Farbe)
}
}
4
5
List Processing
Meta Language
17
Beim Aufruf der Funktion wird diese auf alle Dokumente angewandt. Es wird geprüft ob
das Dokument ein Attribut „Marke“ mit dem Wert „Mercedes“ besitzt. Wenn ja wir ein KeyValue-Objekt mit dem Key Modell und der Farbe als Value ausgegeben
Die Ausgabe sieht entsprechend wie folgt aus:
{SLS, Schwarz}
Die map() Funktion entspricht hier dem SELECT...FROM...WHERE Statement von SQL.
Die reduce()-Funktion filtert die Ausgabeliste und Reduziert somit die Ausgabe. Im folgenden Beispiel wird die Anzahl der Autos, die das Ergebnis der eben angewandte map()Funktion enthält, ausgegeben:
Function(keys, values){
return sum(values)
}
Die Ausgabe ist eine 1, da die Ergebnismenge nur ein Auto enthält. Wäre die map()-Funktion mit Ferrari gelaufen, wäre die Ausgabe eine 3. Die reduce()-Funktion entspricht hier
den Aggregat-Funktionen von SQL.
Durch die Parallelisierbarkeit der Funktionen ist es möglich Ergebnismengen schnell zu
Filtern und die Datenbank zu durchsuchen. Bei einem System, das mit einem Thread läuft,
wird bei einer Suche in 60.000 Datensätzen jeder Datensatz nacheinander geprüft. Ein
System, das für die gleiche Anfrage sechs Threads zur Verfügung hat, ist auch etwa sechs
mal schneller, da jeder Thread nur 10.000 Datensätze prüfen muss.
"Entwickelt wurde das Map/Reduce-Framework 2004 bei Google Inc."[EFHBB11], jedoch
sind mittlerweile eine Vielzahl weiterer Frameworks dieser Art entstanden.
3.2.3 Multiversion Concurrency Control
Die meisten SQL-Systeme verhindern, dass auf einen Datensatz zugegriffen wird, der
gerade Teil einer Transaktion ist, in dem eine Sperre auf den entsprechenden Datensatz
gelegt wird. Bei parallel arbeitenden Systemen kann es durch diese Sperre jedoch zu Verzögerungen kommen. Dadurch greifen einige NoSQL-Systeme auf MVCC (Multiversion
Concurrency Control) zurück. Das heißt Daten werden nicht gesperrt, sondern es wird bei
der Bearbeitung eine Versionierung erstellt, die Konflikte erkennt und im Konfliktfall die
einzelnen, parallel gelaufenen Transaktionen zurückgerollt und erneut gestartet werden
können.
18
3.2.4 REST
Representational State Transfer „gilt als die Basis für die Skalierbarkeit des World Wide
Web von einem einzelnen kleinen Server am CERN im Jahre 1990 zum weltumspannenden Netzdienst mit Milliarden von Nutzern heutzutage"[EFHBB11]. REST hat keine feste
Definition, sondern ist eher ein Entwurfsmuster für eine vertikale Skalierung von Datenverteilung, also der Verteilung auf viele Heterogene Systeme anstatt eines einzelnen überdimensionierten Systems.
Der REST-Ansatz im Bezug auf Datenbanken beschreibt also die Verteilung der Daten auf
verschiedene Server, die zu einem Cluster zusammengefasst werden. Erklärt wird dies im
folgenden am Beispiel von HTTP.
Die Bausteine des Konzeptes sind dabei Ressourcen, Operationen und Links.
Ressourcen sind in diesem Zusammenhang die Endpunkte, die das System adressiert.
Dies kann beispielsweise ein HTML-Dokument sein. Ressourcen werden über einen Uniform Resource Identifier eindeutig adressiert.
Operationen werden immer auf einer Resource ausgeführt. Am Beispiel HTTP wären unter
anderem GET, PUT, POST oder DELETE Operationen die zum Beispiel auf einem HTMLDokument angewendet werden können.
Die letzte Komponente im REST/HTTP-System sind die Links. Erst mit ihnen wird aus
einer Ansammlung von Ressourcen ein Netz. Sie verbinden die einzelnen Ressourcen miteinander und können Operationen enthalten.
3.3 NoSQL Systeme
Es gibt mehrere Kategorien von NoSQL Systemen. Jede Kategorie hat Eigenschaften die
sie von anderen unterscheidet, oft gibt es auch Systeme die Eigenschaften aus mehr als
einer dieser Kategorien aufweisen. Die Kategorien werden hier nur kurz beschrieben. Im
folgenden Kapitel wird gesondert auf dokumentenorientierte Datenbanksysteme eingegangen.
3.3.1 Wide Column Stores
Die Wide Column Systeme erinnern an Exel-Tabellen, haben aber den großen Unterschied, dass beliebig viele Schlüssel auf beliebig viele Key/Value-Paare angewendet werden können. Spalten können mit beliebigen Key/Value-Paaren erweitert werden. Es entsteht also eine Tabelle deren Felder aus verschachtelten Arrays besteht, die selber noch-
19
mal Tabellen dieser Form enthalten können. Die einzelnen Key/Value-Listen können dann
selber nochmal in Clustersysteme unterteilt sein.
3.3.2 Key/Value-Systeme
In Key/Value Systemen oder Key/Value Stores werden die Daten meist durch ein leichtes
Schema aus Schlüsseln und werten definiert. „Ein Wert ist immer einem bestimmten
Schlüssel zugeordnet, der aus einer strukturierten oder willkürlichen Zeichenkette bestehen kann. Diese Schlüssel können in Namensräume sowie in Datenbanken aufgeteilt werden. Die Werte (auch Values genannt) des Systems können neben Strings auch Listen,
Sets oder Hashes enthalten“[WWW2].
3.3.3 Graphdatenbanken
Graphdatenbanken bestehen aus einem Graphen der die Struktur der Daten beschreibt.
Sie sind der moderne Nachfolger der Netzwerkdatenbanken. Einsatz finden sie häufig
dort, wo Informationen unterschiedlichster Art miteinander verknüpft werden müssen: Etwa
im Smartphonebereich bei dem Geodaten via Social Networks an Freunde geknüpft werden[EFHBB11]. Graphdatenbanken implementieren einige Algorithmen, die zur effizienten
Suche von Informationen oder deren Verknüpfung eingesetzt werden können. Bekannte
Pfadsuchalgorithmen wie Dijksta gehören genauso dazu wie Map/Reduce-Algorithmen um
nur bestimmte Teile des Graphen zu betrachteten. In der Regel repräsentieren die Knoten
des Graphen ein Objekt und die Kanten die diese Verbinden verschiedene Arten von Relationen. So lässt sich eine Graphdatenbank mit einem Aufwand, der mit der Anzahl der
Kanten pro Knoten wächst, in ein relationales System überführen.
20
4. Dokumentenorientierte Datenbanken
Dokumentenorientierte Datenbanken speichern Daten nicht in Tabellen, sondern in Dokumenten. Die Dokumente enthalten eine Ansammlung von Schlüsseln mit dazugehörigen
Werten. Das Schema der Daten wird nicht definiert. Es werden in der Regel keine echten
Anwenderdokumente gespeichert. Die Datenbank legt die Dokumente zusammen mit der
zugehörigen ID ab. So können Dokumente durch ändern der Werte oder hinzufügen von
Feldern bearbeitet werden. „Typische Dokumentenstrukturen sind JSON oder
XML“[OK12].
4.1 CouchDB
CouchDB steht für „Cluster of unreliable commodity hardware Data Base“ und wird seit
2005 von Damien Katz entwickelt. Katz war Senior-Entwickler von Lotus Notes (heute IBM
Notes)[WWW3], einem dokumentenorientierten Datenbanksystem mit starker E-MailAnbindung. Von 2008 bis 2009 setzte er seine vorher privat geführte Arbeit, bei IBM fort,
bis er mit einigen anderen Entwicklern das Unternehmen Relaxed Inc. gründete, welches
sich mittlerweile „CouchOne“ nennt. CouchDB ist seit November 2008 offizielles Apache-Projekt.
"CouchDB orientieren sich an Googles BigTable und damit auch an der Zugriffsmöglichkeit
auf Daten mittels Map/Reduce sowie am Dokumentenmanagement-Framework Lotus
Notes."[EFHBB11].
CouchDB bietet zur Konfiguration das Web-Interface Futon. Hiermit lassen sich Berechtigungen verteilen, Dokumente erstellen, oder Abfragen ausführen. CouchDB vefügt über
eine RESTful HTTP API sowie eine Plugin-Architektur für viele Programmiersprachen.
CouchDB ist für viele Plattformen verfügbar. Sowohl Windows Plattformen, als auch Linux
Distributionen und Mac OS werden unterstützt. Zusätzlich werden Systeme für mobile
Geräte entwickelt.
4.1.1 Datenmodell
CouchDB ist eine schemafreie, dokumentenorientierte Datenbank, bei der die Daten in
JSON-Strukturen abgelegt werden. Die Dokumente werden in Form von B-Bäumen abgelegt und über Dokumenten-IDs adressiert. Zudem werden sie mit einer Revisions-ID
gespeichert, die sich bei jeder Änderung des Dokuments erhöht. Dies ermöglicht Konflikterkennung durch MVCC.
21
Gespeichert werden die Daten im JSON-Format. JSON besteht aus einer Liste von kommaseparierten Key/Value Paaren, wobei der Wert wieder auf eine andere Eigenschaft verweisen kann. Mit den JSON-Dokumenten lassen sich durch Verschachtelungen von
Key/Value-Paaren beliebig komplexe Strukturen und Abhängigkeiten erreichen, ohne vorher aufwendig ein Schema definieren zu müssen.
Die Dokumente bilden das Äquivalent zu den Tupeln in relationalen Datenbanken.
[EFHBB11]. JSON besitzt folgende Basistypen: Objekt, Array, Zeichenkette, Zahlen, Boolsche Werte und NULL.
4.1.2 Map/Reduce und Views
Views sind Abbildungen von Daten die ein vom Anwender definiertes Kriterium erfüllen.
Die Daten werden gelesen und gefiltert, sodass nur die Daten angezeigt werden die das
definierte Kriterium erfüllen. Bei CouchDB werden Views dynamisch zur Laufzeit erzeugt.
Views werden in speziellen design documents definiert und können über Datenbankinstanzen wie normale Dokumente repliziert werden. Views werden in den design documents
per JavaSkript-Funktionen und mittels Map/Reduce-Algorithmen erstellt.
4.1.3 Replikation
CouchDB unterstützt das Replizieren auf mehrere Systeme, mit dem Bidirektionalem Konfliktmanagement. CouchDB ist mit dem Gedanken entwickelt worden, dass nicht immer
alle Systeme erreichbar sind. Sollte ein Gerät bei der Replikation nicht erreichbar sein, so
wird die Synchronisation erfolgen, sobald das System wieder erreichbar ist. Hierbei werden auftretende Konflikte vom Konfliktmanagement erkannt und die aktuellere Datenversion ausgewählt. Diese kann durch Anwendung einer gewünschten Revision überschrieben
werden. Zudem bietet CouchDB die Möglichkeit über Filter nur partielle Replikationen vorzunehmen.
4.1.4 Skalierbarkeit
CouchDB bietet keine Möglichkeit zur Skalierung der Daten, jedoch gibt es Open Source
Frameworks mit denen eine Möglichkeit zur Skalierung geschaffen werden kann.
4.1.5 Zugriffskontrolle
CouchDB bietet drei Rechteverteilungen an. Eine für Administratoren, eine lesende, und
eine schreibende. Administratoren können Accounts anlegen und Rechte vergeben.
22
4.2 MongoDB
"MongoDB ist ein Open Source-Project, hinter dem das Unternehmen 10gen Aus New
York steht."[EFHBB11]. Abgeleitet ist der Name vom englischen Wort humongous, dass
übersetzt riesig bedeutet.
Dieser Name ist eine Anspielung auf die großen Datenmengen die mit MongoDB gespeichert und verwaltet werden können. Hauptziel von MongoDB ist der Datendurchsatz, also
möglichst große Datenmengen in möglichst kurzer Zeit. Dabei hilft auch, dass MongoDB in
C++ geschrieben wurde. Eine Stärke von MongoDB ist das Journaling, eine von relationalen Datenbanken entliehene Eigenschaft, die bei einem Absturz des Systems alle nicht
beendeten Transaktionen erneut ausführt. Transaktionen in MongoDB sind immer Atomar.
MongoDB bietet eine API für die meisten Programmiersprachen wie C++, C#, Java, PHP,
Ruby, Perl und weitere Sprachen, sowie eine RESTful HTTP API.
MongoDB ist für alle gängigen Betriebssysteme sowohl in einer 32-Bit- als auch einer 64Bit-Version verfügbar.
4.2.1 Datenmodell
Unter MongoDB werden die Dokumente im BSON Format gespeichert, einen binären
JSON Format, "das um einige Datentypen erweitert wurde"[EFHBB11].
MongoDB ist eine schemafreie Datenbank. Das Schema eines Dokuments wird beim Einfügen zur Laufzeit erzeugt. Die Datenbank unterteilt sich in sogenannte Collections, die mit
den Tabellen in relationalen Datenbanken verglichen werden können. Der Vorteil hierbei
ist, dass nicht alle Dokumente in der Collection das selbe Schema aufweisen müssen.
MongoDB bietet die Möglichkeit, die Größe dieser Collections zu beschränken.
Jedoch weisen diese Capped-Collections genannten Collections zwei wesentliche
Beschränkungen auf: Dokumente in dieser Collection können nicht gelöscht werden und
nur dann verändert werden, wenn sich die Größe des Dokuments nicht ändert. Ist die festgelegte maximale Größe überschritten, werden Dokumente nachdem first-in-first-out Prinzip dem Alter nach entfernt, also das älteste Dokument immer zuerst.
Die Dokumente sind das Äquivalent zu den Tupeln relationaler Datenbank. Sie verhalten
sich wie assoziative Arrays, die beispielsweise aus Skript sprachen wie PHP bekannt sind.
Somit ist es möglich, auf einfache Weise Dokumente ineinander zu verschachteln.
Eine weitere Beschränkung von MongoDB, ist die Begrenzung der Größe eines Doku23
ments im BSON Format auf maximal vier MB. Größere Dateien werden mit dem sogenannten GridFS Algorithmus in mehrere kleinere Dateien aufgeteilt.
4.2.2 Map/Reduce
Da MongoDB über eine sehr mächtige Abfragesyntax verfügt, kann größtenteils auf den
Einsatz von Map/Reduce verzichtet werden, da API bereits mit SQL vergleichbare Befehle
liefert. Auch für dynamische abfragen bietet MongoDB einen vergleichbaren Funktionsumfang im Bereich der Filterung und Selektion wie SQL. Zusätzlich bietet MongoDB eine
eigene Implementierung des Map/Reduce-Algorithmus an. Dies ermöglicht mit MongoDB
abfragen durchzuführen, die in SQL mit einem GROUP BY gelöst würden.[EFHBB11] Die
mit Map/Reduce Aufträge werden mit JavaSkript formuliert.
4.2.3 Replikation
In Sachen Replikationen bietet MongoDB ebenfalls mehrere Lösungen an. Im Allgemeinen
kann von einem Master aus auf beliebig viele Slaves reproduziert werden. Client-Anfragen
werden hierbei grundsätzlich nur an den Master gestellt. Nun bietet MongoDB die Möglichkeit den Master manuell oder automatisch zu bestimmen. Im manuellen Modus muss
jedoch ein Administrator im Falle eines Ausfalls des Masters einen neuen bestimmen.
4.2.4 Skalierbarkeit
Da MongoDB die horizontale Skalierbarkeit nativ unterstützt, ist es "möglich, mit einem
einzelnen Server zu beginnen und diesen später zu einem Cluster auszubauen"
[EFHBB11]. Die Verteilung der Daten erfolgt auf Ebene der Collections, bei dem durch
geeignete Wahl der Schlüssel dafür gesorgt wird, dass alle Dokumente aus einer Collection auch auf dem gleichen Server gespeichert werden. Die aufgeteilten Pakete, deren
maximale Größe konfigurierbar ist, werden als Chunks bezeichnet. Die einzelnen Server
nennt man Shards. Die Verwaltung der einzelnen Server übernehmen ein oder mehrere
Config-Server. Zudem gibt es noch einen Routingserver, der alle Client-Anfragen entgegennimmt und die geforderten Datensätze von den einzelnen Shards holt und diese dann
ausliefert. Natürlich kann ein MongoDB Server auch nur aus einem Rechner bestehen.
Hier werden die Aufgaben der verschiedenen Server von einzelnen Prozessen übernommen.
24
4.2.5 Zugriffskontrolle
MongoDB bietet zwei Rollenmodelle: Vollzugriff und lesenden Zugriff.
4.3 Multimodell-Datenbanken
Multimodelldatenbanken sind Datenbanken die Konzepte mehrerer NoSQL-Systeme in
sich vereinen. Da im Zuge dieser Arbeit mehrere dokumentenorientierte Systeme miteinander verglichen werden sollen, und Multimodel-Datenbanken auch Aspekte der dokumentenorientierten Datenbank Systeme beinhalten, sollten diese nicht vernachlässigt werden. Als Vertreter der Multimodel-Datenbanken wird OrientDB gewählt.
4.3.1 OrientDB
OrientDB ist eine Multimodelldatenbank die sowohl Eigenschaften von Graphdatenbanken, Key/Value Stores, objektorientierten und dokumentenorientierten Datenbanken aufweist. Ursprünglich wurde OrientDB 1999, bzw. sein erster Vorläufer von Luca Garulli in
C++ geschrieben, später jedoch komplett in Java übersetzt. Sie findet sich unter der
OpenSource-Liznez Apache 2.0. OrientDB besitzt mehrere APIs, unter anderem Java und
JavaScript sowie eine http basierte RESTful API. Auf der eigenen Homepage, wird OrientDB als Document-Graph DBMS vorgestellt, ein Hybridsystem aus dokumentenorientierter Datenbank und Graphdatenbank. Haupteinsatzgebiet, sind stark vernetzte Daten,
deren Struktur und Daten häufig und schnell geändert werden müssen.[EFHBB11]
4.3.1.1 Datenmodell
Generell liefert OrientDB seine Anfragen im JSON-Format zurück. Durch die flexible und
vielseitige API lässt sich auf die verschiedenen Datenmodelle zugreifen, bei denen das
dokumentenorientierte Modell die Basis bildet. Das Graphenmodell nutzt einen Objectwrapper um die Daten aus den Dokumenten zu lesen und in diese zu schreiben. Intern
realisiert OrientDB die Verteilung der Dokumente über eine eigene URL-Syntax.
Mit OrientDB ist es möglich ein Schema für die Daten zu definieren, oder Dokumente
schemafrei zu erstellen. Sogar ein Mix aus schemafreien und schemagebundenen Dokuementen ist möglich.
4.3.1.2 Map/Reduce
OrientDB bietet keine Möglichkeit Map/Reduce Algorithmen zu implementieren.
25
4.3.1.3 Replikation
OrientDB bietet eine simple Möglichkeit zur Replikation, die vollständig automatisch
abläuft. Einmal eingerichtet, wird ein Master-Server automatisch replizieren, sobald er ein
Signal von einem Slave erhält. Wird der Slave vom Netz getrennt, wird dieser nach Neustart auf Konsistenz geprüft und erneut synchronisiert. Konflikte werden hierbei durch Versions-IDs erkannt.
4.3.1.4 Zugriffskontrolle
OrientDB bietet ein aus SQL-Datenbanken bekanntes Rollensystem zur Vergabe von
Rechten an. Primär gibt es den root-User, der anfangs als Administrator eingestellt ist.
Durch ihn können neue Nutzer angelegt werden und deren Rechte nach zwei Prinzipien
vergeben werden. Zum einen gibt es die Allow-all-but Methode, bei der Einschränkungen
gemacht werden, was der Nutzer nicht sehen, bzw. tun darf. Und dann das Gegenteil, eine
Deny-all-but, bei der ausgewählt werden muss, welche Rechte der Nutzer besitzt.
26
5. Fazit
Eine native Versionierung der Daten bietet keins der Systeme. Mit den Collections von
MongoDB lässt sich aber einfach eine Versionierung implementieren. Dazu muss für jedes
Dokument eine Collection erstellt werden und bei einer Änderung des Dokuments eine
neue Version mit einer Revisionsnummer angelegt werden. Die anderen Systeme bieten
eine solche Möglichkeit nicht.
Ein Monitoring der Daten lässt sich über die Map/Reduce Funktionen von MongoDB und
CouchDB realisieren. Mit diesem können Fehler gefunden werden, und einem Bearbeiter
direkt die entsprechenden Datensätze geliefert werden. Da OrientDB kein Map/Reduce
Funktionen unterstützt ist die Möglichkeit eines Monitorings nicht gegeben.
Eine Möglichkeit zur Replikation der Daten wird von allen Systemen geboten.
Eine horizontale Skalierung unterstützen alle Systeme, mit der Einschränkung, dass bei
CouchDB auf externe Software zurückgegriffen werden muss. Dadurch können beispielsweise Konsistenzchecks der Daten auf verteilten Systemen laufen.
Alle Systeme bieten eine Möglichkeit Dokumente schemalos zu erstellen. Dadurch ist es
möglich Informationen zu einem Datensatz zu speichern, die nicht an die Shopdatenbank
übertragen werden. Die freie Wahl der Felder biete die Möglichkeit einen festen Attributsatz im Anwendungsprogramm zu definieren, das mit dem Schema der MySQL-Datenbank übereinstimmt. Zusätzlich können weitere Felder für beliebige Metainformationen
angelegt werden.
Bei der Wahl des Systems spielen noch andere Faktoren als die aus der Motivation eine
Rolle. Beispielsweise ob es einen Kommerziellen Support für das System gibt, falls es zu
Problemen kommt. OrientDB bietet momentan noch eine sehr geringe Nutzerbasis, sowie
ein recht kleines Entwicklerteam. Außerdem ist die Dokumentation nicht immer aktuell.
[EFHBB11] Dennoch wird ein kommerzieller Support beim Kauf einer Enterprise Version
des Datenbanksystems angeboten. Für MongoDB wird ebenfalls ein kommerzieller Support beim Kauf einer Enterprise Version angeboten. Für CouchDB gibt es keinen kommerziellen Support.
Auch die Geschwindigkeit ist ein wichtiger Faktor, da Wartezeiten minimiert werden sollen.
Benchmarks zeigen, dass MongoDB große Datenmengen schneller verarbeiten kann als
CouchDB[WWW4]. Zudem wird CouchDB mit zunehmender Datenmenge langsamer[WWW5].
Somit ist für das Fallbeispiel der antibodies-online GmbH eine dokumentenorientierte
27
Datenbank eine Möglichkeit alle in der Motivation beschriebenen Anforderungen zu erfüllen. MongoDB ist das geeignetste System.
28
Literaturverzeichnis
KM01 : Gregor Kuhlmann, Friedrich Müllmerstadt, SQL Der Schlüssel zu Relationalen
Datenbanken, 2001ISBN: 3499600633
EFHBB11: Stefan Edlich, Achim Friedland, Jens Hampe, Benjamin Brauer, Markus
Brückner, NoSQL, 2011ISBN: 9783446427532
OK12: Oliver Kurowski, NoSQL Einführung, ISBN: 978-3-86802-410-4
WWW1: http://econsultancy.com/de/blog/10936-site-speed-case-studies-tips-and-tools-forimproving-your-conversion-rate (aufgerufen am: 13. Dezember 2013)
WWW2: http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/KeyValueSysteme (aufgerufen
am: 13. Dezember 2013)
WWW3: http://www-03.ibm.com/software/products/en/ibmnotes/ (aufgerufen am: 13.
Dezember 2013)
WWW4: https://gist.github.com/ihower/268512 (aufgerufen am: 13. Dezember 2013)
WWW5: http://debuggable.com/posts/couchdb-insert-benchmarks:4a4365e2-9d04-41709f88-2de34834cda3 (aufgerufen am: 13. Dezember 2013)
Abbildungsverzeichnis
Abbildung 1: Beispiel Relation...............................................................................................9
Tabellenverzeichnis
Tabelle 1: Beispiel Attribute....................................................................................................9
Tabelle 2: Negativbeispiel erste Normalform.......................................................................11
Tabelle 3: Positivbeispiel erste Normalform.........................................................................11
Tabelle 4: Negativbeispiel zweite Normalform.....................................................................11
Tabelle 5: Positivbeispiel zweite Normalform.......................................................................12
Tabelle 6: Negativbeispiel dritte Normalform.......................................................................12
Tabelle 7: Positivbeispiel dritte Normalform.........................................................................12
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema Anwendungsorientierte
Evaluation dokumentenorientierter Datenbanksysteme selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die
anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind
und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studienoder Prüfungsleistung war.
Name: Robin Landsmann
Aachen, den 15. Dezember
Unterschrift der Studentin / des Studenten