NoSQL-Datenbanken - Fakultät für Mathematik und Informatik

Friedrich-Schiller Universität Jena
Fakultät für Mathematik und Informatik
Lehrstuhl DBIS
Dozent: Prof. Dr. Klaus Küspert, Dipl. Inf. Andreas Göbel
Seminar: Software as a Service, Cloud-Computing und aktuelle
Entwicklungen
Semester: SoSe 2010
NoSQL-Datenbanken
Philipp Heinze
[email protected]
St. Jakob Str. 7
07743 Jena
Matrikelnr.: 98127
9. Juli 2010
Inhaltsverzeichnis
1 Einleitung
1
2 Grundlagen
1
2.1
Entstehung & Bedeutung des Begriffs NoSQL . . . . . . . . . . . . . . . . . . . .
1
2.2
Definition von NoSQL-DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2.3
Probleme der relationalen DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3 Wichtige Konzepte
3
3.1
CAP-Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.2
BASE-Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.3
Eventual-Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.4
MVCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
4 NoSQL-Systemkonzepte
4.1
Document-Store
4.2
Graph-Datenbank
4.3
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Key-Value-/Tupel-Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.3.1
Eventually consistent Key-Value Stores/Amazon Konzept . . . . . . . . .
8
4.3.2
Wide-Column-Store/BigTable Konzept . . . . . . . . . . . . . . . . . . . . 11
5 Ein Beispiel - Cassandra
13
6 RDBMS für die Cloud
14
7 Zusammenfassung
14
I
1
Einleitung
Mit dieser Ausarbeitung soll ein kurzer Überblick über die Entstehungsgeschichte und den
aktuellen Stand der NoSQL-Szene gegeben werden. Dies betrifft im Detail die aktuell vorherrschenden NoSQL-Systemansätze und einige wesentliche Datenbankkonzepte, die für Datenbanksysteme im Allgemeinen und NoSQL-Systeme im Speziellen von Bedeutung sind.
2
Grundlagen
2.1
Entstehung & Bedeutung des Begriffs NoSQL
Obwohl der Begriff NoSQL erst seit 2009 einem breiteren Spektrum von Informatikern geläufig
ist, gibt es ihn schon seit 1998. Entsprechende Datenbankmanagementsysteme (DBMS), die
die Definition erfüllen, sind noch älter, wie z. B. Berkeley-DB, die mit dem relationalen (sowie hierachischen- als auch Netzwerk-) Ansatz bricht, und 1994 veröffentlicht wurde. Damals
nannte Carlo Strozzi ein von ihm geschriebenes relationales DBMS ohne SQL Interface NoSQL.
Durch den Begriff NoSQL wollte er verdeutlichen, dass sein System kein SQL1 -Interface für
den Benutzer bot. Für die aktuelle NoSQL-Bewegung wäre jedoch aus heutiger Sicht Strozzis
der Begriff NoREL angebrachter gewesen, da nicht nur mit der Datenbanksprache SQL sondern meist auch mit den Ansätzen des relationalen Konzepts gebrochen wird. Ohnehin geriet
der Begriff wieder in Vergessenheit. Erst als Eric Evans 2009 für eine Konferenz über verteilte
Open-Source-DBMS einen Namen suchte und schließlich no:sql(east) fand, wurde NoSQL wieder bekannt. Emil Efrem schlug im Herbst 2009 als neue Bedeutung von NoSQL Not only SQL
vor, was in der Community heute auch weitestgehend akzeptiert wird.[Wik10b]
2.2
Definition von NoSQL-DBMS
Als NoSQL-Systeme zählen eine Vielzahl von unterschiedlichen Systemen und Konzepten. Eine recht gute Definition, was als NoSQL-System gesehen werden kann, findet man auf nosqldatabase.org[ND10], diese lautet:
Next Generation Databases mostly addressing some of the points: being non-relational,
distributed, open-source and horizontal scalable. The original intention has been modern web-scale databases. [...] Often more characteristics apply as: schema-free, easy
replication support, simple API, eventually consistent / BASE (not ACID), and
more. So the misleading term nosql“ [...] should be seen as an alias to something
”
like the definition above.
Ein DBMS wird demnach genau dann als NoSQL-System angesehen, wenn es mindestens eine
dieser Eigenschaften erfüllt: nicht relationales Modell, verteilt, horizontal skalierbar2 , schema1
Structured Query Language
Die Systemleistung kann im Gegensatz zum vertikalen Skalieren, bei dem z.B. der DBMS-Server aufgerüstet
werden muss, durch Hinzufügen neuer Einheiten gesteigert werden.
2
1
frei, einfache Replikation & API3 und eventually consistent/BASE. Open-Source als Merkmal
von NoSQL-DBM-Systemen zu sehen, ist in meinen Augen nicht angebracht, da Open-Source
allein noch kein Garant für NoSQL ist, wie MySQL oder PostgreSQL beweisen. Auf der anderen
Seite sind einige NoSQL-Systeme wie Googles BigTable oder Amazons Dynamo Closed-Source,
hier sind nur die zugrundeliegenden Konzepte bekannt.
2.3
Probleme der relationalen DBMS
Seit vielen Jahren ist das relationale Konzept das führende DBMS-Konzept. Dies liegt zum
einen daran, dass die relationalen Systeme im Bezug auf die Geschwindigkeit seit Jahren mit
den Netzwerk- und Hierarischen-DB Modellen mithalten können und zum anderen daran, dass
die Arbeit mit diesen Systemen einfacher vonstatten geht als zuvor. Der Benutzer ist nicht
länger Navigator, sondern beschreibt (deskriptiv) nur noch, welche Daten er haben bzw. welche
Operationen er ausführen möchte. Jedoch, nach Jahren der Dominanz bzw. der Alleinherrschaft
von RDBMS bei der Anschaffung neuer Systeme, rücken NoSQL-DBMS für Unternehmen einiger Branchen langsam weiter in den Vordergrund.
Einen Sprung in das Rampenlicht machten die NoSQL-Datenbanksysteme, wie bereits erwähnt,
im Jahr 2009. Die Frage ist, ob sich mit der erhöhten Aufmerksamkeit für NoSQL-Systeme
die Anforderungen an Datenbanken im allgemeinen geändert haben. Diese ist nicht eindeutig
zu beantworten. Seit Beginn von Heimcomputerisierung und Internet gibt es ein exponentielles
Wachstum des Datenaufkommens. Hier können RDBMS mit NoSQL-Systemen oftmals nicht
mehr mithalten, da ihre Konzepte und Implementierungen nicht dafür ausgelegt sind4 . Auf der
anderen Seite gibt es aber noch sehr viele Gebiete, in denen der Einsatz von RDBMS ideal oder
gar unvermeidbar ist. Die ersten beiden großen Firmen, die mit relationalen Systemen an ihre
Grenzen stießen, waren mit Sicherheit Google und Amazon. Während bei Google aufgrund der
geforderten Schemata und den nicht sinnvoll in statische Schemata pressbaren Webseiten die
relationalen DBMS an ihre Grenzen stießen, war es bei Amazon die fehlende Garantie für die
sofortige Anfragebeantwortung der Benutzer und die zentrale Verwaltung, die ein weiteres Verwenden von relationalen DBMS unmöglich oder sehr kostspielig machten[DHJ+ 07] [DHJ+ 07].
Beide haben ihrerseits effiziente Datenbanksysteme bzw. Datenspeicher entwickelt, die Anforderungen erfüllen, die relationale DBM-Systeme nicht erfüllen können. Es ist zu beobachten,
dass die relationalen Systeme über die Jahre einfach zu sehr überladen wurden, weshalb sie
gewisse Performanceanforderungen nicht mehr erfüllen können, wie im Fall von Amazon. Als
Beispiel für die Überladung seien die aus SQL heraus möglichen Systemaufrufe, die in vielen
Systemen möglich sind, genannt. Zu Beginn waren relationale DBMS für On-Line-TransactionProcessing konzipiert. Mit dem Aufkommen immer günstigerer Datenträger kamen schließlich
Data-Warehouses und mit diesen das On-Line-Analytical-Processing auf. Dies wurde von den
bestehenden Systemen unterstützt, ohne dabei entsprechende Veränderungen am Datenmodell
3
Application Programming Interface
RDBMS nutzen zumeist einen Shared-Disk-Ansatz zum Aufbau eines Mehrrechnersystems, wohingegen
NoSQL-Systeme oftmals auf Shared-Nothing setzen.
4
2
vorzunehmen5 . So wäre für Data-Warehouses eine tupelweise Speicherung der Daten sinnvoller,
da diese für Abfragen schneller ist, als die tupelweise Speicherung. Jedoch verfliegt der Vorteil,
sobald alle Attribute zurückgeliefert werden sollen. Da bei OLAP in der Regel aber von allen
Zeilen nur wenige Spalten angefragt werden, existiert hier ein deutlicher Vorteil[Hen08]. Heute
bieten zudem alle großen Datenbanksysteme native XML-Unterstützung an, die ebenfalls auf
dem alten Gerüst basiert. All diese Funktionalitäten kamen mit den Jahren teils durch Kundenwunsch, teils durch marktpolitische Überlegungen zu Systemen hinzu, die dafür primär nicht
konzipiert sind. Es ist zu erkennen, dass die relationalen Systeme ein immer breiteres Spektrum
abdecken und sich von ihren eigentlichen Kerngebieten entfernen. Eine Erklärung, warum dies
nicht zwangsläufig eine günstige Entwicklung ist, wurde bereits gegeben, eine andere wird später
mit dem CAP-Theorem geliefert.
3
Wichtige Konzepte
Bevor nun auf die aktuell wichtigsten NoSQL-Systemarten eingegangen wird, werden zuerst
einige wichtige Konzepte und Annahmen vorgestellt, die bedeutende Grundlagen für die Entwicklung von NoSQL Datenbanken darstellen.
3.1
CAP-Theorem
Das CAP-Theorem oder auch Brewer6 -Theorem, sagt aus, dass von den drei Eigenschaften
Consistency (dt. Konsistenz), Availability (dt. Verfügbarkeit) und Partition Tolerance (dt.
Partitionstoleranz) durch ein verteilt arbeitendes System jeweils nur zwei voll zu erfüllen sind.
Abbildung 1: Beispielsysteme, die unterschiedliche Eigenschaften erfüllen. Nach [Tha10]
Dabei bedeuten die einzelnen Eigenschaften folgendes:
• Consistency (dt. Konsistenz): Eine komplexe Operation, also eine Operation die aus vielen
Teiloperationen besteht, wird entweder ganz oder gar nicht ausgeführt, und die verursachten Veränderungen sind anschließend für alle folgenden Operationen komplett oder gar
5
6
Die großen drei, Oracle, DB2 und MS SQL-Server speichern alle tupelbasiert.
Nach Professor Eric Brewer von der University of California, Berkeley
3
nicht sichtbar. Ferner sehen alle Benutzer des Systems zu jeder Zeit die selben Daten. Der
Begriff Consistency ist hierbei etwas verwirrend, da tatsächlich die ACI-Eigenschaften von
ACID beschrieben werden.
• Availability (dt. Verfügbarkeit): Ein Knotenausfall führt nicht dazu, dass das Gesamtsystem nicht mehr 100% der Daten verfügbar hat, bzw. nicht mehr arbeitsfähig ist.
• Partition Tolerance (dt. Partitionstoleranz): Das System kann trotz willkürlichem Nachrichtenverlust zwischen zwei Teilsystemen weiterarbeiten. Dies bedeutet, dass trotz Teilung des Gesamtsystems in zwei Teile aufgrund eines Kommunikationsabbruchs, beide
Teile zumindest in Maßen weiterarbeiten können. So könnten z. B. nur noch lesende Zugriffe auf das System bearbeitet werden.
Die Beispielsysteme aus Abbildung 1 arbeiten wie folgt. Beispielsystem 1 besteht aus nur einem
Knoten, der die gesammten Daten hält. Beispielsystem 2 besteht aus zwei Knoten, die Daten
speichern, wobei jeder Knoten nur einen Teil der Daten hält und keine Replikation auch nur
von Teildaten stattfindet. System 3 besteht ebenfalls aus zwei Knoten. Hier hält jedoch jeder
Knoten alle Daten, womit eine vollständige Kopie des Datenbestandes vorliegt. Ferner findet
zwischen den beiden Knoten ein Datenaustausch statt um die beiden Datenbestände synchron
zu halten. Die Systeme sind durch die eben beschriebenen Eigenschaften in der Lage folgende
CAP-Eigenschaften zu erfüllen. Beispiel 1 erfüllt trivialerweise nur die Konsistenzeigenschaft,
da ein einzelner Systemknoten ohne Problem die Konsistenz der Daten garantieren kann. Ebenso einfach ist ersichtlich, dass das System keinesfalls die Verfügbarkeit und Partitionstoleranz
erfüllen kann. Beispiel 2 kann ebenfalls ohne Probleme die Konsistenzforderung erfüllen, da
beide Systemknoten für unterschiedliche Datenbestände zuständig sind. Daraus folgt jedoch im
gleichen Zug, dass das System nicht die Verfügbarkeitsanforderung erfüllt, da keine Datenreplikation stattfindet. Jedoch kann das System ohne Probleme eine ungewollte Partitionierung
verkraften, da beide Systemknoten eigenständig weiterarbeiten können. Beispiel 3 kann durch
die Datenreplikation die Verfügbarkeit erfüllen und auch die Partitionstoleranz ist gegeben, jedoch ist die Konsistenz nur durch intensive und ständige Synchronisation zu gewähren wodurch
im gleichen Atemzug aber wieder die Partitionstoleranz und Verfügbarkeit sinken.[Tha10]
Das Theorem ist ein zentraler Punkt im Bereich der Datenbanken insbesondere für NoSQLDatenbanken, da dadurch aufgezeigt wird das Datenbanksysteme klare Grenzen haben und
kein System alle Eigenschaften gleich gut erfüllen kann.
Einen axiomatischen Beweis des Theorems lieferten Seth Gilbert und Nancy Lynch[GL02].
Wie in Abbildung 2 zu erkennen ist, befinden sich relationale Systeme aufgrund ihrer ACIDEigenschaften7 zwischen Consistency und Partitiontolerance. Da sie die Konsistenzbedingung
erfüllen, ist nur eine der beiden anderen Eigenschaften noch voll und die andere nicht oder nur
ungenügend erfüllbar. In Zeiten des Web 2.0 soll ein Online-Service jedoch rund um die Uhr
verfügbar sein. Da für Webseiten wie facebook.com die beiden letzteren Eigenschaften wichtiger
7
Atomarität, Konsistenz, Isolation und Dauerhaftigkeit
4
Abbildung 2: CAP Eigenschaften und entsprechende Systeme. Nach [Bre10]
sind als die Konsistenz, wohlgemerkt dass Inkonsistenzen wenn überhaupt nur eine kurze Zeit
sichtbar bzw. überhaupt vorhanden sind, können folglich relationale DBMS sich nur schwer bis
gar nicht mit NoSQL-Datenbanken in diesen Bereich messen. Diese Ansicht vertreten freilich
nicht alle. So ist z.B. Michael Stonebraker8 der Meinung, dass es ausreichend wäre, Verfügbarkeit
und Konsistenz zu erfüllen[Sto10].
3.2
BASE-Eigenschaften
Basically Available, Soft State, Eventual Consistent (dt. grundsätzlich verfügbar, loser Zustand
und schlussendlich konsistent) ist ein Gegenkonzept zu ACID, basierend auf der Annahme, dass
Verzicht auf Strong Consistency und dafür ein größeres Augenmerk auf Verfügbarkeit eine enorme Steigerung der Skalierbarkeit ermöglicht[Pri08]. In diesem Konzept wird nicht gefordert, dass
die Datenbank nach einer Operation in einem konsistenten Zustand ist, es wird vielmehr davon
ausgegangen, dass die Datenbank aufgrund folgender Operationen wieder in einen konsistenten
Zustand überführt wird. Die Datenbank befindet sich somit in einem fließenden Wechsel zwischen konsistentem und inkonsistentem Zustand, es existiert somit nur eine lose Konsistenz.
Da die Konsistenz nur eine untergeordnete Rolle spielt, ist es hier ohne große Probleme möglich,
mehrere Duplikate“ einer Datenbank zu halten, die sich von Zeit zu Zeit asynchron synchro”
nisieren. Dadurch kann eine höhere Verfügbarkeit ermöglicht werden, da der Wegfall eines einzelnen Knotens nicht zum Totalausfall der darauf gespeicherten Daten führt.
3.3
Eventual-Consistency
Eventual-Consistency ( dt. schlussendlich konsistent) gehört in die Weak-Consistency (dt.
schwache Konsistenz) Kategorie. Dies bedeutet, dass nicht alle Benutzer des Systems zu jeder
Zeit dieselben (konsistenten) Daten sehen, sondern gewisse Vorbedingungen erfüllt sein müssen,
damit dies eintritt. Im Falle von Eventual-Consistency gibt es ein definiertes InconsistencyWindow, also ein Zeitfenster, in dem verschiedene Clients verschiedene Werte erhalten können.
8
Bedeutender Forscher im Bereich RDBMS aktuell Professor am MIT und Gründer von Ingres, PostgreSQL
uvm.
5
Solange keine Veränderungen durchgeführt werden, erhalten alle Clients die gleichen Daten. Dieser Konsistenzansatz hält im BASE Konzept Einzug. Eine mögliche Umsetzung von EventualConsistency wird später bei Amazon Dynamo erläutert.
3.4
MVCC
Das Multiversion-Concurrency-Control-Konzept ermöglicht es, dass lesende Zugriffe auf ein
Datenbankobjekt nie blockiert werden. Dazu wird für jedes Objekt ein Zeitstempel/eine Transaktions-ID mitgeführt. Zusätzlich erhält jede Transaktion ebenfalls einen Zeitstempel oder eine
Transaktions-ID. Eine Transaktion kann jedes Objekt lesen, das vor Transaktionsstart existierte.
Als Resultat erhält die TA die neueste Version, deren Stempel kleiner dem eigenen Transaktionszeitstempel ist. Der Lesestempel wird im Anschluss daran für dieses Objekt auf den TAZeitstempel gesetzt. Zusätzlich besitzt jedes Objekt einen Lesezeitstempel, der den Zeitstempel
der letzten Transaktion repräsentiert, die das Objekt gelesen hat. Will nun eine Transaktion
Ti ein Objekt O ändern, das in der Zwischenzeit von einer neuen Transaktion Tj gelesen wurde, wird die Transaktion neugestartet, da für den Lesestempel des Objektes O gilt: Ti < Tj .
Andernfalls wird eine neue Version des Objektes O von Ti geschrieben. Als neuen Zeitstempel
erhält diese den Zeitstempel der Transaktion Ti . Dieses Verfahren wird nicht nur unter NoSQLDatenbanken verwendet, sondern hat auch bereits in einige relationale DBMS wie Oracle und
Microsoft SQL-Server9 Einzug gehalten.[Wik10a]
4
NoSQL-Systemkonzepte
Aufgrund der Definition zählen zu NoSQL eine Vielzahl verschiedener Konzepte, wobei die
drei wichtigsten Key-Value-/Tupel-Store (Wide-Column-Store), Document-Store und GraphDatenbanken sind. Folgend soll zu den Genannten ein kurzer Überblick über das Konzept und
wichtige Vertreter gegeben werden.
4.1
Document-Store
Im Kontrast zu relationalen DBMS gibt es bei Document-Stores keine Tabellen mit festen Schemata, sondern nur Dokumente. In einer Datenbank werden Dokumente gespeichert, die nach
einem bestimmten Schema aufgebaut sind, dabei kann ein Dokument sowohl ein gewöhnliches
Tupel aus einem relationalen DBMS darstellen als auch eine ganze Tabelle (siehe CouchDB).
Wobei bei einigen Systemen wie mongoDB mittels Collections[Cho10] auch stärkere Gruppierungen möglich sind. Allerdings muss auch in diesen Collections keine Schematakonsistenz
herrschen. Die Dokumente werden z. B. in JSON, YAML und auch XML10 ausgetauscht und
gespeichert. Die Abfragesprachen sind meist einfach gehalten und bieten nur grundlegende Abfragemöglichkeiten, so fehlt z. B. die Möglichkeit, Joins zu realisieren. Die Skalierbarkeit dieser
9
Oracle unterstützt MVCC seit Version 7.x, MS SQL-Server seit Version 2005, wobei schon frühere Versionen
andere Verfahren mit vergleichbarer Funktionalität bieten.
10
JavaScript-Object-Notation, Yet-another-Markup-Language und Extensible-Markup-Language
6
Systeme schwankt von einfacher Replikation bei CouchDB[Cou10] bis hin zu komplexer ShardPartitionierung mit gleichzeitiger Replikation bei mongoDB[Mer10]. Bei beiden Systemen ist es
möglich mittels MapReduce Anfragen auf eine Vielzahl von Knoten zu verteilen.
Vertreter dieser Gruppe sind, neben den bereits genannten CouchDB und mongoDB, IBM Lotus Notes und Amazon SimpleDB. Ferner zählen im weiteren Sinne alle XML-Datenbanken zu
dieser Gruppe. Auch die großen drei Oracle, IBM und Microsoft11 bieten seit einiger Zeit native
XML-Unterstützung an. Während der Reifestatus der API bei den großen DBM-Systemen als
ausgereift angesehen werden darf, ist bei CouchDB und mongoDB im Bezug auf Funktionalität
und API noch viel Entwicklung feststellbar. Die Performance bei den relationalen Systemen
ist jedoch noch deutlich ausbaufähig. Es ist nicht bekannt, dass eine große Anwendung ausschließlich oder zum Großteil auf Document-Stores setzt. Jedoch findet CouchDB z. B. bei der
BBC und Ubuntu zur Synchronisation von Lesezeichen Verwendung. Ein möglicher zukünftiger
Anwendungsbereich ist die Synchronisation von mobilen Endgeräten, wo leichtgewichtige Datenspeicher gefordert sind. Document-Stores eignen sich, um (unstrukturierte) Daten zu speichern
und gleichzeitig sowohl eine gewisse Menge an Abfragemöglichkeiten sicher zu stellen als auch
eine hohe Skalierbarkeit zu erreichen.
4.2
Graph-Datenbank
Graph-Datenbanken speichern ihre Daten nicht wie relationale DBMS in Tabellen und nutzen
Fremdschlüssel oder Tabellen zur Abbildung von Beziehungen, sondern verwenden Knoten und
Kanten, die Graphen bilden. Dabei repräsentieren die Knoten die Objekte, also die Tupel aus
dem relationalen Schema, und die Kanten die Beziehungen untereinander. Der Graph stellt die
Menge der Objekte (Knoten) und deren Beziehungen (Kanten) untereinander dar und wird in
einem graphoptimalen Format gespeichert. Kanten können dabei, wie aus der Graphentheorie
bekannt, nur zwischen zwei Knoten existieren. Wenn dem Knoten ein Schema zugrundeliegt,
muss beim Löschen und Einfügen entsprechend beachtet werden, dass dieses nicht verletzt wird.
Z. B. dürfte in der Schemavorgabe, dass Rechnungen genau einem Kunden zugeordnet sind, kein
Kunde gelöscht werden, ohne vorher oder gleichzeitig all seine Kanten und auch Rechnungsknoten zu löschen. Wobei ein Modell für die Knoten nicht bei allen Graphdatenbanken gefordert
ist. Die Kanten können auch typisiert werden. Durch diese Typisierung von Knoten und Kanten ist es möglich, ein Objekt-Beziehungsgebilde aufzubauen, das den objektorientierten Ansatz
erfüllen kann12 . Es wäre somit zur Laufzeit möglich, neue Beziehungstypen zwischen zwei Objekten, die vorher nicht in Beziehung stehen konnten, einzuführen, ohne die Schemata oder
das Anwendungsprogramm wesentlich zu ändern. Eine einfache API ermöglicht es ferner von
den Knoten nur bestimmte Kanten zu ermitteln bzw. zwischen zwei Objekten die gemeinsamen
Beziehungen zu anderen Objekten zu erhalten. Damit sind Graphdatenbanken gut geeignet,
um z. B. semantische Beziehungen zwischen Objekten darzustellen, die sich tagtäglich ändern
11
12
Oracle mit Version 11g, IBM mit DB2 9 und pureXML und Microsoft mit MS SQL Server 2005
Dies ist nur möglich, wenn eine dynamische Typisierung möglich ist, wie z. B. bei InfoGrid V2.
7
können. Bei assoziativen Datensätzen sind sie im Vorteil gegenüber relationalen DBMS13 , wobei
der Vorteil verpufft, wenn dieselbe Operation auf einer Vielzahl von Knoten durchgeführt werden soll. Graphdatenbanken existieren seit geraumer Zeit14 und besitzen entsprechend eine recht
ausgereifte API mit teilweiser ACID-Unterstützung. Es existiert aber noch keine einheitliche Abfragesprache. Eine Abfragesprache für RDFs15 existiert mit SPARQL. Für die anderen Bereiche
wird gerade erst mit Gremlin ein möglicher Kandidat entwickelt[Neu10]. Jedoch fristen diese
DBMS weiterhin ein Nieschendasein. Dies könnte sich jedoch mit dem aufkommenden Web 3.0,
dem semantischen Web, ändern, da dort Beziehungen eine größere Bedeutung bekommen.[Inf10]
4.3
Key-Value-/Tupel-Store
Bei den Key-Value-Stores werden die Daten/Tupel ähnlich wie in den relationalen DBMS gehandhabt. Sie werden gruppiert gespeichert, wobei die so gruppierten Daten mehr oder weniger
einem Schema folgen können, wie bei BigTable. Auf die Tupel wird über einen Schlüssel zugegriffen, hinter dem sich genau ein Tupel versteckt. Dies bedeutet jedoch nur, dass genau ein
eindeutig identifizierbares Objekt gespeichert ist. Das z. B. wie bei BigTable durchaus mehrere
Versionen aufweisen kann. Bei Dynamo ist dies aufgrund der Eventual-Consistency Eigenschaft
ebenfalls möglich. Die einzigen notwendigen Funktionen sind insert, get und update auf Tupelebene.
4.3.1
Eventually consistent Key-Value Stores/Amazon Konzept
Wichtige Vertreter in diesem Gebiet sind Amazons Dynamo, Cassandra und Projekt Voldemort
[Vol10a], wobei die beiden Letzteren viele Ansätze aus dem Amazon-Dynamo-Paper[DHJ+ 07]
übernommen haben. Für Amazon war es enorm wichtig, dass ihre Dienste zu jeder Zeit voll
funktionsfähig sind [even] if disks are failing, network routes are flapping, or data centers are
”
being destroyed by tornados“[DHJ+ 07]. Deshalb ist es unerlässlich, dass alle Daten redundant
gespeichert werden und auch keine zentrale Verwaltung stattfindet, um einen Single-Point-ofFailure zu verhindern. All dies findet sich in Dynamo wieder. Zusätzlich ist Dynamo extrem
leichtgewichtig im Bezug auf die zur Verfügung stehenden Operationen. Es existieren lediglich
get- und set-Funktionen zum Lesen und Schreiben von Key-Value-Paaren (KVP).
Dynamo baut auf Consistent Hashing auf.16 Jeder Knoten in Dynamo erhält einen Key, der auf
dem Ring abgebildet wird, ein Beispiel ist in Abbildung 3 zu sehen. Typischerweise sind dabei
die Keys so gewählt, dass die Hashwerte gleichverteilt auf dem Ring liegen. Der Knoten speichert nun alle Keys, die im Hashbereich zwischen seinem Vorgängerknoten und sich selbst liegen.
Zusätzlich speichert ein Knoten Kopien der Keys seiner N Vorgängerknoten, da es Amazon be13
Die Geschwindigkeit kann dabei im Bereich drei bis vier Zehnerpotenzen höher als bei relationalen Systemen
sein[Neu10].
14
Neo4j existiert bereits seit dem Jahr 2000.
15
Resource-Description-Framework, für die Beschreibung von Resourcen(URIs)
16
Die Hashfunktionsausgabe bildet auf einen Ring ab, wobei der größte/letzte Hashwert an den kleinsten
angrenzt.
8
Abbildung 3: Möglicher Dynamo-Aufbau. Nach [DHJ+ 07]
sonders wichtig ist, dass keine Daten verloren gehen. Der Knoten A aus Abbildung 3 speichert
demnach primär alle KVP, die im Intervall i liegen. B und C halten Kopien des Intervalls i. Für
jedes Intervall gibt es eine Präferenzliste von Knoten, die angesprochen werden sollen. Der erste
Knoten in der Liste ist üblicherweise der sogenannte Koordinator, die folgenden N-1 Knoten
sind die Repliken. Um der Anforderung an eine einfache Skalierung mit gleichmäßiger Auslastung mittels heterogener Systeme zu entsprechen, kann ein physischer Knoten mehrere logische
Knoten besitzen. Dabei sind die logischen Knoten auf einem physischen Knoten üblicherweise
nicht zusammenhängend. So könnte ein physischer Knoten X z. B. die logischen Knoten A und
E halten.17
Da mehrere Knoten dieselben Daten speichern, aber nicht alle Knoten gleich den neuen Wert
halten müssen, muss eine Abstimmung über den korrekten Wert stattfinden, ein sogenanntes Quorum. Bei diesem Quorum, das aus dem Triple (N, R, W) besteht, handelt es sich um
Angaben, wieviele Knoten für eine erfolgreiche Aktion beteiligt sein müssen. Für Lesezugriffe
(Read) müssen R Knoten eine erfolgreiche Ausführung der Operation melden, für Schreibzugriffe (Write) müssen es W Knoten sein und insgesamt halten N Knoten ein KVP. Eine gängige
Belegung des Triples ist (3,2,2). Im originalen Quorum-Ansatz müssen die ersten Knoten, die für
das KVP zuständig sind, die jeweilige Operation ausführen. Für Abbildung 3 würde demnach
gelten, dass ein Wert der in i liegt auf A und B geschrieben werden muss, damit der Schreibvorgang als erfolgreich gilt. Da dies aber auch bei den kleinsten Systemausfällen zu Problemen
führt (so würde das System hängen sobald A oder B nicht erreichbar wären), verwendet Dynamo ein sogenanntes Sloppy Quorum, bei dem die ersten N gesunden“ Knoten die Operation
”
ausführen. Um nun eine Fragmentierung der Daten zu vermeiden, wird bei der Speicherung von
KVP auf einem eigentlich nicht zuständigen Knoten ein Hinted Handoff durchgeführt. Dabei
wird ein nachfolgender Knoten gefragt, ob er die Daten speichern würde. Wenn dieser zustimmt,
erhält er das KVP (Handoff ) und speichert es in einer getrennten lokalen Datenbank mit einen
Verweis (Hint) auf den eigentlichen Zielknoten. Der Knoten prüft nun von Zeit zu Zeit, ob der
eigentliche Empfänger wieder verfügbar ist. Wenn dem so ist, wird das KVP zurückgegeben, so
dass die Verfügbarkeits- und Dauerhaftigkeitsanforderungen erfüllt bleiben. Im Anschluss daran
17
Bei Amazon Dynamo sind die einzelnen physischen Knoten zudem auf verschiedene Rechenzentren verteilt.
9
löscht der Knoten das KVP aus seiner lokalen Datenbank. So würde z. B. bei nicht Erreichbarkeit von Knoten A der Knoten D die KVP von A übernehmen, solange dieser nicht erreichbar
ist.
Da üblicherweise nur eine Knotenteilmenge für ein gegebenes KVP einen Schreibvorgang auf
jeden Fall sofort durchführen muss und somit verschiedene Versionen vorhanden sein können,
muss das System erkennen, welche Version älter ist. Dazu erhält jedes KVP einen sogenannten
Vector Clock (VC). Dieser besteht aus Tupeln der Art (Knoten-ID, Versionsnummer), wobei
die Knoten-ID die ID des Koordinators darstellt. Wenn Knoten A nun ein neues Objekt O1
anlegen soll, erhält dieses als VC [(A,1)]. Das Objekt wird anschließend aktualisiert zu O2 . Dies
wird ebenfalls von A koordiniert, so ist dessen VC nun [(A,2)]. Aufgrund des Quorum-Systems
ist es möglich, dass auf einigen Repliken noch eine alte Objektversion liegt, diese kann einfach
aktualisiert werden, wenn alle Tupelversionsnummern kleiner oder gleich der aktuellen sind.
Nun wird erneut das Objekt aktualisiert, jedoch nicht von A sondern von B koordiniert, und
erhält als VC [(A,2),(B,1)]. Erfolgt nun sowohl über Knoten B als auch über Knoten C ein
erneuter gleichzeitiger Schreibzugriff, so entstehen zwei verschiedene Versionen des Objektes
namentlich [(A,2),(B,2)] auf Knoten B und [(A,2),(B,1),(C,1)] auf C. Wenn nun Knoten A die
beiden Versionen abfragt, stellt dieser fest, dass beide Versionen verschieden sind und führt
beide zusammen zur Version [(A,2),(B,2),(C,1)]. Es liegt dann an der Anwendung diese zusammengeführte Version zu überprüfen. Der eben beschriebene Ablauf ist in Abbildung 4 zu sehen.
Abbildung 4: Dynamo VectorClocks. Nach [DHJ+ 07]
Durch das Hinted Handoff entsteht ein weiteres Problem. Wenn A ausgefallen ist, ersetzt bei10
spielsweise Knoten D diesen. Wenn nun jedoch A wieder verfügbar ist, aber D zur selben Zeit
ausfällt, kann D die Daten nicht zurückspielen. Um das Problem zu vermeiden, besitzt jeder
Knoten für die Intervalle, die er betreut, sogenannte Merkle Trees 18 . Beim Start überprüft jeder
Knoten, ob er eine aktuelle Version hält. Dafür überprüft er zuerst seinen Wurzelhashwert mit
denen der anderen Knoten. Wenn diese übereinstimmen, hält er eine aktuelle Version. Wenn
der Hashwert nicht übereinstimmt, werden die Kindsknoten überprüft und bei Nichtübereinstimmung notfalls tiefer iteriert, bis die entsprechenden Stellen, die aktualisiert werden müssen,
lokalisiert sind. Für die entsprechenden Blätter werden dann die VCs verglichen, um die aktuellere Version zu ermitteln.
Um eine Veränderung in der Verteilung der Knoten bekanntzugeben, wird ein Gossip-Protokoll
verwendet. Das heißt, dass jeder Knoten mit allen anderen Knoten Nachrichten austauschen
kann und dies auch in unregelmäßigen Abständen tut, sodass Veränderungen mit der Zeit im
ganzen System ankommen. Die Verteilung der Keys erfolgt dann automatisch. Wenn nun z. B.
zwischen A und B ein neuer Knoten X eingefügt wird, bieten die Knoten B, C und D ihre
Keys aus den entsprechenden Bereichen an, die nach Akzeptanz von X übertragen werden und
anschließend von B, C und D gelöscht werden.[DHJ+ 07]
Das Konzept kann als ausgereift angesehen werden und wird auch erfolgreich eingesetzt. Allen
voran steht Amazon Dynamo, das zwar nicht öffentlich zur Verfügung steht, aber von Amazon
intern erfolgreich für z. B. die Shopping-Cart verwendet wird. Auch Cassandra wird bei facebook für die Posteingangssuche erfolgreich verwendet.
Mögliche Einsatzgebiete für diese Datenspeicher sind Anwendungen, die hochverfügbar sein
und gleichzeitig sehr geringe Latenzzeiten aufweisen sollen oder müssen. Das System ist nicht
geeignet, um komplexe Objekt-Beziehungsmodelle darzustellen, da es sich lediglich um ein KeyValue-Store handelt und nötige Integritätsbedingungen in die Anwendung ausgelagert werden
müssten.
4.3.2
Wide-Column-Store/BigTable Konzept
Hinter den Wide-Column-Store-Datenbanken verstecken sich superskalierbare, mit Petabyte von
Daten arbeitende, Datenbanken. Als Begründer dieses Ansatzes kann Google mit BigTable gesehen werden. Weitere frei verfügbare Vertreter sind HBase, Cassandra und Hypertable. Der
Aufbau ähnelt dem gewöhnlicher relationaler Systeme mit dem Unterschied, dass ein Schlüssel
auf beliebig viele Tupel“ zeigt. Dabei darf man ein Tupel nicht in dem aus relationalen Daten”
banken bekannten Sinn verstehen, denn eigentlich handelt es sich um verschiedene Versionen eines Tupels. In solch einem Tupel kann es praktisch beliebig viele19 sogenannte Column-Families
geben, in der beliebig viele Columns zusammengefasst werden.
Die Column Families werden über Schlüssel identifiziert. Nehmen wir nun an, die Tabelle
aus Abbildung 5 sei für die Indizierung von Webseiten gedacht. Eine Column-Family könn18
In den Blättern stehen die Hashwerte der Schlüssel der Einträge. Jeder Elternknoten enthält den Hashwert
seiner Kindsknoten.
19
Nach Ansicht der BigTable-Autoren sind es nicht mehr als einige Hundert.
11
Abbildung 5: Eine Webtabelle im BigTable-Format. Nach [CDG+ 06]
te dann z. B.: anchor:“ heißen. In ihr werden alle Verweise von einer Seite auf andere Seiten
”
gespeichert. Nun haben wir eine Seite mit der Adresse example.net indiziert, die Links auf
die Seiten example.com und example.org hält. Die Spaltennamen könnten dann so aussehen:
anchor:example.org“ und anchor:example.com“. In den jeweiligen Columns werden dann z. B.
”
”
die Linktexte abgelegt. In einer Column können nun beliebig viele Versionen eines Tupels stehen, die zu unterschiedlichen Zeiten gültig waren. Um diese zu unterscheiden, wird für jede
Version ein Zeitstempel mitgeführt, mithilfe dessen eine gezielte Adressierung einer bestimmten (Vorgänger) Version möglich ist. So wäre in unserer Abbildung in der Column contents“
”
der Inhalt der Webseite zu verschiedenen Zeitpunkten abgespeichert. Um eine explosionsartige
Datenvermehrung aufgrund der Versionierung zu vermeiden, kann man das Datenbanksystem
so konfigurieren, dass nur eine gewisse Anzahl von alten Versionen gespeichert werden oder
alle Versionen, die ein gewisses Alter überschreiten, automatisch gelöscht werden. Eine Tabelle
wird in sogenannte Tablets (Namensbereichen) unterteilt, die im Falle von Google automatisch bei Erreichen einer gewissen Größe weiter aufgeteilt werden. Mehrere Rechner bilden eine
Tabelle, dabei gibt es mehrere Tablet-Server und einen Master. Der Master übernimmt Verwaltungsaufgaben wie das Hinzufügen und Entfernen von Tablet-Servern und die Lastverteilung.
Die Tablet-Server sind für die Schreib - & Leseprozesse zuständig und können mehrere Tablets
verwalten. Da der Master nur verwaltende Tätigkeiten übernimmt, ist die Gefahr einer Überlastung des Systems gering, da jederzeit neue Tablet-Server hinzugezogen werden können, um
die gestiegene Last zu bewältigen. In unserem Beispiel könnte für die Webtabelle ein Tablet alle
.com-Domains umfassen und ein weiterer alle .de-Domains. Sollte nun der .de-Tablet zu groß
werden, kann er automatisch durch den Master in zwei neue Tablets, die nicht zu groß sind,
aufgeteilt werden. Wenn nun zusätzlich der .com-Tablet sehr gefragt ist und der Tablet-Server
an seine Leistungsgrenze gelangt, kann der Master einem unausgelasteten oder Reserve-TabletServer dieses Tablet zusätzlich zuordnen, um die Lastspitze abzufangen.[CDG+ 06]
Der Bereich der Wide-Column-Stores, kann ebenfalls als ausgereift angesehen werden, da Google mit seinem Paper über BigTable eine gute Grundlage für diesen Ansatz geliefert hat und
ihn selber auch mehr als erfolgreich für die eigenen Dienste einsetzt. Cassandra wurde initial
für facebook entwickelt und dort für die Posteingangssuche verwendet.
12
Ein System nach dem BigTable-Ansatz ist gut geeignet, um extrem große Mengen an Daten, die
einem groben gemeinsamen Schema folgen, zu speichern. Auch für die Haltung einer gewissen
Anzahl von älteren Versionen eines Objektes ist ein Wide-Column-Store-System geeignet. Vorallem für sehr skalierbare Datenbanken ist BigTable durch die automatische Lastverteilung und
Datenhaltung zu empfehlen. Nicht zu empfehlen ist BigTable für Systeme, die Objekt-ObjektBeziehungen benötigen.
5
Ein Beispiel - Cassandra
Cassandra ist eine hochverfügbare und hochskalierbare Datenbank, die ursprünglich von facebook entwickelt wurde und mittlerweile ein Apache-Toplevel-Projekt ist. Um die Hochverfügbarkeit zu erreichen, orientiert sich die Infrastruktur an Amazons Dynamo. Da Cassandra ursprünglich für die Posteingangssuche bei facebook entwickelt wurde, reicht jedoch ein einfacher KeyValue-Store, wie es Dynamo ist, nicht. Googles BigTable-Ansatz, der flexible Schemata erlaubt,
ist dafür besser geeignet und sehr gut dokumentiert. Das Besondere an Cassandras BigTableUmsetzung ist, dass es Super-Column-Families gibt. Column-Families können Super-ColumnFamilies beinhalten. Es darf jedoch keine Super-Column weitere Super-Columns beinhalten,
somit ist keine beliebige Rekursion möglich. Bei der Erstellung einer (Super-)Column-Family
muss man zusätzlich angeben, nach welcher Art sortiert werden soll, möglich sind die Sortierung nach Name der Columns oder deren Erstellungszeit. Um sich vorstellen zu können, wie
eine solche Tabelle aussehen könnte, folgend ein kurzes Beispiel, wie die Posteingangssuche bei
facebook in etwa realisiert ist.
Abbildung 6: facebook-Posteingangssuche
Bei der facebook-Posteingangssuche gibt es prinzipiell zwei Arten der Suche, einmal nach Nachrichten, die gewisse Wörter enthalten, und zum anderen nach dem zeitlichen Eingang. Dafür
existieren Zwei Columns, die hier einmal words und users heißen mögen. Dabei wird für jedes
Wort, das in einer Nachricht für den Benutzer gefunden wurde, eine eigene Column-Family unter
words angelegt, wo als Columns die Nachrichten-IDs angelegt werden. Somit ist es recht einfach
möglich, alle Nachrichten, die ein gewisses Wort enthalten zu finden. Für die andere Suchart
wird für jede Sender-ID eine Super-Column-Family unter users angelegt. Unter diesen Super-
13
Column-Families werden dann als Columns ebenfalls die Nachrichten-IDs eingetragen. Bei dem
Beispiel in Abbildung 6 ist dabei zu beachten, dass die Benennung willkürlich stattgefunden hat
und nicht der tatsächlichen Benennung entsprechen muss. Außerdem wurde aus Platzgründen
der Super-Column-Familyname verkürzt dargestellt. Zwar existiert die Möglichkeit mehrere Tabellen pro Cassandra-Installation zu verwenden, jedoch wird dies in der Praxis nicht umgesetzt.
Dies liegt sicherlich zum einen auch daran, dass mit den (Super-)Column-Families und der völlig
unbegrenzten Anzahl an Columns mehr oder weniger Ähnliches erreicht werden kann wie mit
Tabellen[Sil10]. Für die Lastverteilung bietet Cassandra ebenfalls einige Besonderheiten. So ist
eine automatische Verteilung der Hashbereiche und -werte auf die Knoten im Cluster möglich,
um eine gleichmäßige Auslastung der Knoten zu erreichen. Für die Replikation gibt es die Einstellungen Rack20 unaware, Rack aware und Datacenter aware. Dabei werden die Repliken so
verteilt, dass die Knoten z. B. alle im selben Rack oder Datencenter liegen, um die Latenzzeiten
möglichst gering zu halten. Man kann Cassandra als Versuch sehen, das Beste aus Amazon Dynamo und Google BigTable zu verbinden. Dies scheint auch gelungen zu sein, da bereits einige
größere Firmen wie Twitter, facebook und Digg Cassandra verwenden.[LM09], [Bin10]
6
RDBMS für die Cloud
Abschließend sollen noch einige Worte zu relationalen Datenbanken für die Cloud getroffen werden. Mit Microsoft SQL Azure und VoltDB gibt es zwei Datenbanken, die speziell für die Cloud
entwickelt wurden und bessere Skalierbarkeit bieten sollen als bisherige relationale Systeme.
Dies stimmt auch, da sie speziell dahingehend implementiert wurden. Dennoch sind sie nicht
in der Lage, dieselben Datenmengen zu verwalten wie Key-Value-Systeme [Wie10]. Desweiteren
sind sie nicht für komplexe Abfragen über Tabellen hinweg optimiert bzw. gedacht, und deswegen recht stark beschnitten. So existieren keine Check- und Foreignkey-Constraints. Um die
vollen Performancegewinne zu erzielen, sind Stored Procedures zu verwenden[Vol10b](1,12,60).
7
Zusammenfassung
Ziel dieser Ausarbeitung sollte es sein, einen kurzen Überblick über die Entstehung und die verschiedenen existierenden NoSQL-Konzepte zu geben. Ziel war es auf keinen Fall, dem Leser zu
vermitteln, dass relationale DBMS überflüssig geworden oder NoSQL-Systeme unnötig[Sto10]
sind. Ganz im Gegenteil sollte eher deutlich geworden sein, dass man sich ganz nach den speziellen Anforderungen seines Problems entweder für ein relationales System oder ein NoSQLSystem entscheiden muss, da beide Bereiche mit Bezug auf das CAP-Theorem ihre Stärken aber
auch Schwächen haben. So führt an relationalen Systemen kein Weg vorbei, wenn man strenge
Konsistenzanforderungen zu erfüllen hat. Wenn dies nicht der Fall ist und man ein größeres
Augenmerk auf Verteilbarkeit und Partitionierbarkeit legt, empfiehlt es sich, einen Blick auf
NoSQL-Systeme zu werfen.
20
Rack (dt. soviel wie: Serverschrank)
14
Ob NoSQL-Systeme sich nach dem Hype von 2009 einen größeren Markt erschließen können
oder ähnlich wie objektorientierte Datenbanken weiterhin ein Nieschendasein fristen, bleibt abzuwarten. Jedoch haben relationale Systeme ohne eine Falsifizierung des CAP-Theorems und
den damit einhergehenden Konzequenzen, keine Chance NoSQL-Systeme in deren Steckenpferd
zu schlagen und somit dürfte mit einem Verschwinden der Systeme nicht zu rechnen sein. Mit
dem Web 3.0 und der immer weiter steigenden Zahl von Daten und deren Synchronisation
ergeben sich etliche mögliche neue Anwendungsgebiete. Mit großer Sicherheit werden in Zukunft Mischsysteme in Erscheinung treten, die Systeme aus mehreren verschiedenen Bereichen
vereinen und bei denen jedes Teilsystem seine spezielle Aufgabe hat, da an harten Konsistenzbedingungen oftmals kein Weg vorbei führt und kein Ende der Datenexplosion abzusehen ist.
15
Literatur
[Bin10]
Bin, Simon: Key Value Stores Dynamo und Cassandra. Januar 2010. – Im Rahmen
des Seminars Cloud Data Management 09/10, Universität Leipzip
[Bre10]
Brekle, Jonas: Key Value Stores BigTable, Hadoop, CouchDB. 29. Januar 2010. –
Im Rahmen des Seminars Cloud Data Management 09/10, Universität Leipzip
[CDG+ 06] Chang, Fay ; Dean, Jeffrey ; Ghemawat, Sanjay ; Hsieh, Wilson C. ; Wallach,
Deborah A. ; Burrows, Mike ; Chandra, Tushar ; Fikes, Andrew ; Gruber,
Robert E.: Bigtable: A Distributed Storage System for Structured Data. In: Seventh
Symposium on Operating System Design and Implementation. Seattle, WA, USA,
November, 2006
[Cho10]
Chodorow, Kristina:
Collections.
http://www.mongodb.org/display/DOCS/
Collections. Version: 3. Mai 2010
[Cou10]
CouchDB: Technical Overview. http://couchdb.apache.org/docs/overview.
html. Version: 16. Juni 2010
[DHJ+ 07] DeCandia, Giuseppe ; Hastorun, Deniz ; Jampani, Madan ; Kakulapati, Gunavardhan ; Lakshman, Avinash ; Pilchin, Alex ; Sivasubramanian, Swaminathan
; Vosshall, Peter ; Vogels, Werner: Dynamo: Amazon’s Highly Available Keyvalue Store. In: SOSP. Stevenson, Washington, USA, 2007
[GL02]
Gilbert, Seth ; Lynch, Nancy: Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. In: ACM SIGACT News v.33
Issue 2 (2002)
[Hen08]
Henschen, Doug:
Column-Store Databases and DW Appliances: How to Ma-
ke the Right Choice. http://intelligent-enterprise.informationweek.com/
showArticle.jhtml?articleID=206901279&pgno=2. Version: 3. März 2008. – Zitiert nach Donald, Feinberg, Gartner Analyst
[Inf10]
InfoGrid:
Graph Database Tutorial.
http://infogrid.org/blog/2010/02/
operations-on-a-graph-database-part-1/. Version: 26. April 2010
[LM09]
Lakshman, Avinash ; Malik, Prashant: Cassandra – A Decentralized Structured
Storage System. In: The 3rd ACM SIGOPS International Workshop on Large Scale
Distributed Systems and Middleware. New York, NY, USA, 2009
[Mer10]
Merriman, Dwight: Sharding Introduction. http://www.mongodb.org/display/
DOCS/Sharding+Introduction. Version: 15. Juli 2010
[ND10]
NoSQL-Databases.org: NOSQL-DATABASES. http://nosql-databases.org.
Version: 1. Mai 2010
16
[Neu10]
Neubauer,
Peter:
Neo4j
Graphendatenbank.
-
die
High-Performance-
http://it-republik.de/jaxenter/artikel/Neo4j-%
96-die-High-Performance-Graphendatenbank-2919.html.
Version: 14. April
2010
[Pri08]
Pritchett, Dan: An Acid Alternative. http://queue.acm.org/detail.cfm?id=
1394128. Version: 8. Juli 2008
[Sil10]
Silas, Noah:
Cassandra DataModel.
http://wiki.apache.org/cassandra/
DataModel. Version: 13. Juni 2010
[Sto10]
Stonebraker, Michael:
Errors in Database Systems, Eventual Consis-
tency, and the CAP Theorem.
http://cacm.acm.org/blogs/blog-cacm/
83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/
fulltext. Version: 5. April 2010
[Tha10]
Tharakan, Royans K.: Brewers CAP Theorem on distributed systems. http:
//www.royans.net/arch/brewers-cap-theorem-on-distributed-systems/.
Version: 5. Juni 2010
[Vol10a]
Voldemort, Projekt:
Design.
http://project-voldemort.com/design.php.
Version: 5. Juli 2010
[Vol10b]
VoltDB LLC (Hrsg.): Using VoltDB. V1.0. VoltDB LLC, 24. Mai 2010
[Wie10]
Wienecke, Sebastian: Relationale Cloud-DB. 30. März 2010. – Im Rahmen des
Seminars Cloud Data Management 09/10, Universität Leipzip
[Wik10a]
Multiversion Concurrency Control.
http://en.wikipedia.org/w/index.php?
title=Multiversion_concurrency_control&oldid=364373611. Version: 27. Mai
2010
[Wik10b]
NoSQL.
http://en.wikipedia.org/w/index.php?title=NoSQL&oldid=
360460804. Version: 6. Mai 2010
17