N SQL EINSTIEG IN DIE WELT NICHT RELATIONALER WEB 2.0 DATENBANKEN. EXTRA: Mit kostenlosem E-Book

Transkript

1 stefan EDLICH achim FRIEDLAND jens HAMPE benjamin BRAUER markus BRÜCKNER N SQL 2. Auflage EINSTIEG IN DIE WELT NICHT RELATIONALER WEB 2.0 DATENBANKEN EXTRA: Mit kostenlosem E-Book NEU: Jetzt mit Kapiteln zu OrientDB und Membase

2 Inhalt Geleitwort... XIII Vorwort... XV Vorwort zur 2. Auflage...XVII 1 Einführung Historie Definition und Diskussion Kategorisierung von NoSQL-Systemen Key/Value-Systeme Column-Family-Systeme Document Stores Graphdatenbanken Fazit NoSQL Theoretische Grundlagen Map/Reduce Funktionale Ursprünge Phasen und Datenfluss Komponenten und Architektur Anwendungsbereiche und Implementierungen Praktisches Beispiel Zusammenfassung CAP und Eventually Consistent Konsistenzmodell relationaler Datenbanken CAP-Theorem Alternatives Konsistenzmodell: BASE Consistent-Hashing Multiversion Concurrency Control Vector Clocks Paxos REST Web-scale?...51

3 VI Inhalt Bausteine Entwurf von REST-Applikationen Skalierung von REST-Systemen Fazit Wide Column Stores HBase Überblick Allgemeines Datenmodell Installation CRUD-Operationen Fortgeschrittene Abfragen mit Map/Reduce Skalierung und Konfiguration Replikation Bewertung Cassandra Allgemeines Installation Datenmodell CRUD-Operationen Abfragen in Cassandra Replikation und Skalierung Bewertung Amazon SimpleDB Allgemeines Datenmodell Datensicherheit und Datenschutz Installation CRUD-Operationen Zugriff mit dem AWS Toolkit für Eclipse Replikation und Skalierung Bewertung Document Stores CouchDB Überblick Beschreibung Datenmodell View-Modell Zugriffskontrolle Installation

4 Inhalt CRUD-Operationen Erstellen von Views Replikation Skalierung CouchApps Bewertung MongoDB Überblick Datenmodell Installation CRUD-Operationen Fortgeschrittene Abfragen und Map/Reduce Skalierung Replikation Bewertung Inhalt VII 5 Key/Value-Datenbanken Redis Überblick Allgemeines Installation CRUD-Operationen Redis Hashes Redis Messaging Zugriff aus anderen Programmiersprachen Replikation und Konfiguration Skalierung Bewertung Chordless Überblick Allgemeines Installation CRUD-Operationen Fortgeschrittene Abfragen Skalierung, Replikation und Konfiguration Bewertung Riak Überblick Allgemeines Installation CRUD-Operationen Zugriff aus anderen Programmiersprachen...184

5 VIII Inhalt Abfragen und Links in Riak Riak Search Skalierung, Replikation und Konfiguration Bewertung Membase Überblick Allgemeines Installation Architektur und Konzepte Das Memcached-Protokoll Zugriff aus anderen Programmiersprachen Skalierung und Replikation Der Moxi Die TAP-Schnittstelle Bewertung Graphdatenbanken Mathematische und technische Grundlagen Das allgemeine Graphenmodell Das Property-Graph-Modell Relationen höherer Ordnung Repräsentation von Graphen Traversierung von Graphen Indizierung von Graphdaten Skalierung mittels Replikation und Partitionierung Graph Query Languages Vergleich mit anderen Datenmodellen Zusammenfassung Der Tinkerpop Graph Processing Stack Blueprints Blueprints.NET Frames Pipes und Pipes.NET Gremlin Pacer Rexster AllegroGraph Datenmodell Installation CRUD-Operationen mit Java RDF-Reasoning und Konsistenzkriterien Bewertung...259

6 Inhalt IX 6.4 DEX Beschreibung Datenmodell Installation CRUD-Operationen Graphoperationen DEX-Skripting DEX-Shell Bewertung HyperGraphDB Datenmodell Installation CRUD-Operationen Graphoperationen Peer-To-Peer-Framework Bewertung InfiniteGraph Beschreibung Datenmodell Installation CRUD-Operationen Graphoperationen Bewertung InfoGrid Beschreibung Datenmodell Installation CRUD-Operationen Models Bewertung Neo4j Installation CRUD-Operationen mit der Java-API CRUD-Operationen mit JRuby HTTP/REST-Schnittstelle Cypher Replikation und Skalierung Bewertung sones GraphDB Datenmodell Installation CRUD-Operationen Bewertung...308

7 X Inhalt 6.10 Weitere graphorientierte Ansätze Twitters FlockDB Google Pregel Apache Hama Microsoft Trinity Die VertexDB-Familie Filament OrientDB Überblick Allgemeines Datenmodell Struktur der Datenablage Datenbanksicherheit Installation CRUD-Operationen DocumentDB CRUD-Operationen ObjectDB CRUD-Operationen GraphDB Datenbankschemata Transaktionen HTTP-REST-Schnittstelle Replizierung Hosting über NuvolaBase Bewertung Weitere NoSQL-Datenbanken Wide Column Stores Hypertable Cloudera Document Stores Key/Value/Tupel-Stores Amazon Dynamo Dynomite und KAI Voldemort Scalaris Die Tokyo-Produktfamilie Weitere Key/Value-Systeme Google App Engine Storage Weitere Soft -NoSQL-Lösungen...368

8 Inhalt XI 9 Orientierung im Datenbankraum Grundlegende Gedanken Datenanalyse Transaktionsmodell Performancesapekte Abfrageanforderungen Architektur Weitere nicht-funktionale Anforderungen Anwendungsfälle für NoSQL-Datenbanken Fazit Register

9 1 Einführung NoSQL zu verstehen, bedeutet nicht nur, die Technik zu beherrschen, sondern auch die Geschichte und die Philosophie von NoSQL zu kennen. Wenden wir uns daher zuerst der Geschichte von NoSQL zu. 1.1 Historie Die Geschichte der NoSQL-Systeme begann durchaus parallel zum Siegeszug der relationalen Systeme. Bereits 1979 entwickelte Ken Thompson eine Key/Hash-Datenbank namens DBM. Mit Systemen wie Lotus Notes, BerkeleyDB und GT.M aus den 80er Jahren entstanden dann die ersten noch heute populären Vorreiter der NoSQL-Systeme, im Vergleich zu heute natürlich noch mit geringen Datenmengen tauchte dann der Begriff NoSQL zum ersten Mal bei einer Datenbank von Carlo Strozzi auf. Seiner Datenbank lag zwar immer noch ein relationales Datenbankmodell zugrunde, er stellte aber keine SQL- API zur Verfügung. Der eigentliche Schub für NoSQL kam aber seit 2000 mit dem Web 2.0 und dem Versuch, auch große Datenmengen zu verarbeiten. So kann man sicherlich Google mit seinen Ansätzen wie Map/Reduce (siehe Abschnitt 2.1) und dem BigTable-Datenbanksystem (2004) auf einem eigenen Filesystem (GFS) als den NoSQL-Vorreiter schlechthin bezeichnen. Und natürlich zogen Firmen wie Yahoo, Amazon und später bald auch alle Sozialnetzwerke wie MySpace, Facebook, LinkedIn usw. nach. Bis 2005 entstanden aber auch einige im Vergleich kleinere hochinteressante Datenbanken, die in vielen Facetten schon NoSQL-Charakter aufwiesen. db4o, Neo4j, memcached und InfoGrid haben hier ihren Ursprung. Von 2006 bis 2009 entstanden dann die heutigen klassischen NoSQL-Systeme wie HBase/ Hypertable, CouchDB, Cassandra, Voldemort, Dynamo/Dynomite, MongoDB, Redis, Riak und viele andere, wie sie z.b. im NoSQL-Archiv hinterlegt sind [NArchiv]. Doch erst im Mai 2009 tauchte der heutige Begriff in einem Weblog von Eric Evans auf [Oska09]. Das Team von Johan Oskarsson suchte damals einen Begriff für ein Event (das NoSQL Meetup vom 11. Juni 2009 in San Francisco [Event09]), welches sich mit distributed data storage - Systemen beschäftigte.

10 2 1 Einführung Man sieht also, dass es Datenbanken, die stark von der relationalen SQL-Philosophie der leistungsstarken RDBMS-Systeme abweichen, schon seit vielen Jahrzehnten gibt. Eine starke Formation dieser NoSQL-Systeme als Kontrast zu dem RDBMS-Monopol bildete sich jedoch erst seit Definition und Diskussion Bei der Arbeit am NoSQL-Archiv [NArchiv] haben sich die Autoren früh um eine Definition des Begriffs NoSQL bemüht. Dies fällt relativ schwer, da es weder Gremien noch Organisationen gibt, die sich um eine Begriffsklärung bemüht haben. Dementsprechend versteht heutzutage auch jeder unter NoSQL etwas leicht Verschiedenes, was durchaus seine Berechtigung hat und zur Vielfalt des Ökosystems beiträgt. Dennoch soll an dieser Stelle der Versuch der Definition gewagt werden, um neu einsteigenden Lesern den Zugang zur Materie zu erleichtern. Die Definition aus dem NoSQL-Archiv lautet in deutscher Übersetzung: Definition: Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen: 1. Das zugrundeliegende Datenmodell ist nicht relational. 2. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet. 3. Das NoSQL-System ist Open Source. 4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen. 5. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation. 6. Das System bietet eine einfache API. 7. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde: Eventually Consistent und BASE, aber nicht ACID (siehe dazu Abschnitt 2.4). Dies bedarf einiger Erläuterungen. Das Kernziel von NoSQL bestand darin, sogenannte Web-Scale-Datenbanken zu entwickeln, also Datenbanken für die ungeheuren Datenmengen des Web 2.0-Zeitalters im Terabyte- oder sogar Petabyte-Bereich. Dazu kam auch die Erkenntnis, dass es immer schwerer wird, herkömmliche relationale Datenbanken mit normaler commodity-hardware zu skalieren. Die großen relationalen DB-Hersteller versuchten zwar, den Eindruck zu vermitteln, sie könnten die akuten Probleme im Web 2.0 komplett abdecken. Bei genauerer Betrachtung und in der praktischen Anwendung zeigte sich aber, dass dem nicht so ist.

11 1.2 Definition und Diskussion 3 Und so ist mit Punkt eins der Definition gemeint, dass das relationale Datenmodell nicht immer das perfekte Datenmodell sein muss. Sicherlich hat das relationale Datenmodell unbestreitbare Vorteile, die es in zuverlässigen Systemen seit Jahrzehnten bewiesen hat. Nicht umsonst hat es sich durchgesetzt. Dennoch gibt es genügend andere Datenmodelle, die nicht in relationale Strukturen gepresst werden sollten. Das Graphenmodell ist hier ein bekanntes Beispiel: Die Traversion eines Graphen mittels Tabellen und join-operationen lösen zu wollen, bringt erhebliche Performanceprobleme mit sich. Tatsache ist aber, dass Derartiges in der Industrie immer wieder versucht wird und andere Datenbanken wie Graphdatenbanken leider gar nicht erst evaluiert werden. Punkt zwei beschreibt die Verteilung der Datenbank und die Ausrichtung auf Skalierbarkeit. Wenn Tera- oder gar Petabyte von Daten mit Standard-Hardware gespeichert und verwaltet werden müssen, dann ist es von Vorteil, wenn die eingesetzte Datenbank von Anbeginn auf Skalierung ausgerichtet ist. Bei Open Source-Datenbanken wie HBase oder Cassandra ist diese Anforderung als Erstes in das Design der Datenbank mit eingeflossen. Unter horizontaler Skalierbarkeit (Scale-out) versteht man das Einfügen (und ggf. auch Löschen) von Nodes (d.h. Rechnerknoten), die dynamisch eingebunden werden und einen Teil der Last/Daten tragen können. Dieses Scale-out-Prinzip steht diametral zu dem klassischen Scale-up-Prinzip, bei dem ein Server auf mehr Leistungsfähigkeit aufgerüstet wird. Zu Punkt drei der Definition: Das Open Source-Kriterium wurde in der Community heiß diskutiert, ist aber sicherlich nicht so strikt gemeint, wie es geschrieben den Anschein hat. Es gibt erst einmal keinen logischen Grund, warum Systeme wie Hypertable oder Amazon SimpleDB nicht auch NoSQL-Systeme sein sollten, nur weil sie nicht Open Source sind. Diese Forderung kommt von der Erkenntnis, dass in der Industrie zu oft viel Geld für (u.u. auch relationale) Datenbanksysteme ausgegeben worden ist, die aber dennoch nicht ideal passen. Und so ist fast die gesamte Open Source-Bewegung als Protest zu verstehen, mit der Idee ein anderes Geschäftsmodell zu etablieren. Und tatsächlich sind aus Systemen wie CouchDB oder Neo4j Firmen entstanden, die andere Lizenz- und Businessmodelle verfolgen, mit einem Open Source-Produkt als Basis. In diesem Sinne wird kein NoSQL- Verfechter Open Source als Ausschlusskriterium sehen, sondern eher als Botschaft, sich auch mal in der Open Source-Welt umzuschauen. Mit der Schemafreiheit oder den schwächeren Schemaanforderungen aus Punkt vier stehen aber handfeste Anforderungen an Web 2.0-Datenbanken auf der Tagesordnung. Warum wurde es immer wichtiger, Schemarestriktionen zu lockern? Die Erfahrung zeigte, dass Web 2.0-Projekte und -Portale deutlich agiler sein müssen als beispielsweise Bankanwendungen aus den 90er Jahren. Der Punkt ist, dass Schemaerweiterungen in relationalen Datenbankanwendungen (mit ALTER TABLE) nicht selten schmerzhaft verlaufen und das darüber liegende Portal für Stunden lahmlegen können. Die Idee der NoSQL-Systeme dagegen ist, einen Teil der Verantwortung im Umgang mit dem Schema auf die Anwendung zu übertragen. Hier kann eine Anpassung nämlich unter Umständen einfacher sein. Anstatt wie bei relationalen Anwendungen die Tabelle stundenlang zu sperren und zu konvertieren, wird vielfach der Ansatz verfolgt, die Daten zu versionieren (siehe Abschnitt 2.4, z.b. MVCC). So kann die Anwendung von Anfang an erweiterte Daten (z.b. mit einem Feld mehr) schreiben und ein Hintergrundprozess die Daten konvertieren und als neue Version schreiben. In diesem Fall gibt es eventuell nur ein kleines Zeitfenster, in dem das

12 4 1 Einführung Lesen der Daten die alte Version ohne das neue Feld zurückliefert. Aber gerade in Web 2.0-Anwendungen ist diese Einschränkung oft tolerierbar. In sicherheitskritischen Transaktionssysteme natürlich nicht. Daher ist es initial durchaus sinnvoll zu schauen, ob der Anwendungsbereich konsistente Daten erfordert und deshalb ein Schema hilfreich ist, oder ob man schemafrei mit leichten, seltenen Inkonsistenz-Zeitfenstern nicht evtl. agiler entwickeln kann. Punkt fünf fordert eine einfache Replikationsunterstützung. Dies ist eine logische Konsequenz des verteilten Designs der meisten NoSQL-Anwendungen. Nachdem zugegebenermaßen die Replikation seit den 90er Jahren mit den etablierten relationalen Systemen nur umständlich umgesetzt werden konnte, war es ein inhärenter Wunsch vieler Entwickler, dies von Anfang an einfach zu gestalten. Dies ist der Mehrzahl der Datenbanken auch beeindruckend gelungen. NoSQL-Datenbanken wie CouchDB oder Redis können mit einem einzigen Kommando repliziert werden, was z.b. in der mobilen Welt ganz neue Einsatzgebiete erschließen wird. Einer der interessantesten und diskussionswürdigsten Aspekte ist aus Punkt sechs die Forderung nach einer einfachen API. Die meisten Datenbankentwickler würden sicherlich sagen, dass SQL bereits recht klar, einfach und dennoch mächtig ist. Es ist schließlich nicht zu widerlegen, dass SQL einer der reifsten Standards der Datenbankwelt ist, insbesondere bei einem sauberen relationalen Modell. Aber die Welt dreht sich weiter, und Anforderungen sowie Technologien ändern sich. Ist das relationale Datenbankmodell quasi schon verbastelt und werden immer neue Spalten und Tabellen unüberlegt angefügt, dann kann auch das zugehörige SQL unschön und nicht mehr performant werden. Ein weiterer Punkt ist, dass auch SQL mit Strings arbeitet, die fehleranfällig sind, Fehler zur Compile-Zeit nicht entdeckt werden und auch nicht refactoring-fest sind. Dies führte zu einer logischen Weiterentwicklung zum Beispiel im LINQ-Standard. So ist es eine logische Folge, dass auch NoSQL-Datenbanken versuchen, neue Wege zu gehen, wenn die Abfragen vielleicht auch in dem Maße nicht mehr direkt join-intensiv sind, wie das bisher der Fall war. Eines der besten Beispiele liefert auch hier CouchDB, bei dem Datenbankoperationen als REST-Anfragen formuliert werden. Dies bedeutet im Vergleich zu SQL einen erheblichen Paradigmenwechsel, eröffnet aber in der Web 2.0-Welt gleichzeitig wieder hochinteressante Einsatzgebiete wie Datenbankbefehle aus dem Browser an andere remote Web- Browser. Viele NoSQL-APIs sind daher tatsächlich einfacher als SQL, bieten aber manchmal auch weniger mächtige (insbesondere Abfrage-) Funktionalität an. Problematisch wird es bei NoSQL-Datenbanken mit komplexen Abfragen, die weiterhin das Hoheitsgebiet von SQL bleiben. Nicht selten müssen NoSQL-Anwender dann z.b. komplexe Abfragen als Map/Reduce-Abfragen (siehe Abschnitt 2.1) formulieren. Und dies in definierten Sprachen, die der Anwender evtl. nicht beherrscht. Hier steht NoSQL noch auf unsicheren Füßen und muss in Sachen Entwicklerfreundlichkeit noch vieles nachholen. Das letzte Wort ist hier jedoch bestimmt noch nicht gesprochen, und die Community wird sicher noch viele Optimierungsfelder finden. Der letzte Punkt betrifft das Konsistenzmodell von NoSQL-Systemen. Einiges dazu wurde bereits in Punkt vier besprochen und wird in Kapitel 2.2 noch weiter vertieft. Daher soll dies hier nur kurz angesprochen werden. Nicht alle heutigen (Web-)Systeme benötigen die strikten Konsistenz- und Transaktionsanforderungen, die alle bekannten relationalen Sys-

13 1.3 Kategorisierung von NoSQL-Systemen 5 teme zur Verfügung stellen. Nicht alle Anwendungen sind sicherheitskritische Bank anwendungen. Dennoch wird oft suggeriert, dass immer ein klassisches relationales ACID- System die beste Lösung ist. Vielleicht sind die bekanntesten relationalen SQL-Datenbanken sogar die beste Lösung für das Gros der Anforderungen. Aber sicher nicht immer. Das typische Beispiel sind Social Web-Portale, die in der Regel keine besonders kritischen Daten halten. Dort ist es unproblematisch, wenn Daten auch innerhalb der Knoten der ver teilten Datenbanken inkonsistent sind. Blogs oder Freundschaftsmarkierungen in Face book können sicherlich auch mal für ein kurzes Zeitfenster inkonsistent sein. Man spricht daher von Systemen, die Eventually Consistent sind (siehe Abschnitt 2.4), also nicht sofort, sondern etwas später konsistent sind. Solche Systeme benötigen daher keine ACID-Garantien (Atomar, Konsistent, Isoliert, Dauerhaft), sondern es reicht die sogenannte optimistischere BASE-Anforderung (basic available, soft state, eventually consistent). Bei vielen NoSQL-Systemen muss man daher genau hinschauen, welches Konsistenzmodell zugrunde liegt. So gibt es durchaus einige NoSQL-Systeme, die trotzdem ACID anbieten. Manche bieten sogar ausschließlich ACID an, bei anderen Systemen hat man die Wahl zwischen ACID und BASE, und viele andere bieten einfach nur BASE oder BASE-Derivate an. Dies ist daher auch eines der Kernkriterien für eine Orientierung bzw. einen Anforderungskatalog, wann welche Datenbank eingesetzt werden sollte. Dazu aber mehr in Kapitel 8. Abschließend soll auch die Diskussion über den Begriff NoSQL nicht unerwähnt bleiben. Schon bald, nachdem sich NoSQL als Bezeichnung einer Bewegung durchgesetzt hatte, fühlten sich viele Blogger berufen, gegen diesen Begriff anzugehen (am bekanntesten vielleicht Herr Dhananjay Nene [Nene10]). Und natürlich ist der Begriff relativ nichtssagend. Schon der eingangs erwähnte Carlo Strozzi schlug vor, doch NoSQL in NoREL umzubenennen. Doch NoSQL war sehr schnell ein Selbstläufer und der Begriff nicht mehr zu verdrängen. Viele Kritiker hatten allerdings unterschätzt, dass NoSQL ein perfekter Marketingbegriff war. Und ohne die Kraft dieses wenn auch unsinnigen oder nichtssagenden Begriffs wäre die NoSQL-Community nicht dahin gekommen, wo sie jetzt ist. Immerhin schlug Emil Eifrem von Neo4j frühzeitig vor, NoSQL als Not only SQL zu übersetzen, womit sich die Community inzwischen angefreundet hat. 1.3 Kategorisierung von NoSQL-Systemen Offenbar hat die Marktmacht relationaler (SQL-)Datenbanksysteme alle anderen Datenbanken herausgefordert, sich unter der Fahne von NoSQL zu vereinigen. So haben bisher über 100 nichtrelationale Systeme die Aufnahme in das NoSQL-Archiv beantragt, darunter auch die exotischsten Datenbanken. Sogar Firmen wie Oracle oder IBM also die klassischen RDBMS-Hersteller haben sich gemeldet und beantragt, bestimmte Produkte auch unter der NoSQL-Flagge segeln zu lassen.

14 Register Symbole 2-Hop-Cover Hop-Cover gen 117, 132 A Abfrage 377 Abgeleitete Kante 216 AbstractPipe 237 Acceptors 48 ACID 30, 330, 376 ACM 31 Adjazenzliste 218, 231 Adjazenzmatrix 217 Adobe 65 AllegroGraph 233, 248 allgemeines Graphenmodell 209 Amazon 1, 34 Amazon Dynamo 82, 179, 359 Amazon EC2 167 Amazon Elastic MapReduce 24 Amazon Web Services 96 Apache Hadoop 65 Apache Hama 315 Apache Jackrabbit 358 Apache Thrift 84, 371 App Engine 367 Armstrong, Joe 119 AsciiType 87 asynchroner Prozess 237 Atom 269 ATOM 56 Ausfalltoleranz 31 Availability 31 Availability-Zone 203, 204 AWS 96 B Backup 380 Backup/Restore 380 baidu.com 356 balancierter Baum 221 ballots 48 BASE 33, 179, 376 BashReduce 24 Baum, balancierter 221 BBC 130 bedingte Anfragen 60 BerkeleyDB 1, 275, 366 BerkeleyDB XML 369 BigTable 1, 64, 82, 367 Bild- und Textanalyse 207 Bioinformatik 207 Blueprints 231, 330 Blueprints.NET 211, 234 Boost Graph Library 211, 217, 230 Breadth-First-Traversal 219 Breitensuche 219 BSON 133 B-Tree 365 Bucket 179, 194, 331 Bucket/Key/Value-Modell 331 Bulk-Kommando 157 Business-Daten 373 BytesType 87 C Caching 59 Canonical 130 CAP 193 CAP-Theorem 31 Cassandra 82 cassandra-cli 84

15 386 Register Cassandra Query Language 89 Causal Consistency 34 Cell-Prozessorserie 23 Chord 39 Chordless 168 Chubby-Prozess 50 Chunk 143 Class 332 Client-Sharding 166 Cloud-Computing 98 Cloudera 65 Cluster 332 Clustering 181 Clustering-Algorithmus 223 Codd 225 Column 83, 85 Column Families 6, 83 Common LISP 249 comparator 87 Consistency 31 Consistency-Level 93 Consistent Hashing 36, 93, 359 CouchApps 129 CouchDB 23, 118 CouchDB Lounge 129, 360 cqlsh 89 Crash Resistance 380 CRUD-Operation 242, 244 C-Store 63, 368 curl 124 D Data Access Pattern 378 Data Segment 332 Data-Structure Server 166 Data-Warehouse 63 Datenart 373 Datenflussnetz 239 datenflussorientiert 237 Datenkomplexität 375 Datenmenge 375 Datenmodell objektorientiertes 227 relationales 225 Datennavigation 374 Datensilo 229 Daten- und Speichermodell 374 Datenzugriffsmuster 378 db4o 1, 369 DBObject 137 DELETE 54 Depth-First-Traversal 219 DEX 260 Dictionary 166 Disco 24 Distributed Hash Table 93 Django 357 Document Stores 6 DocumentDB 336 Dog House 247 Dokumentendatenbank 228 Dokumentmodell 331 Domain-Daten 373 Dynomite 360 E EAV-Model 226 EMC Documentum 369 Emit 19 Empfehlungssystem 207, 221 Engine 336 Engine Yard 130 Entity-Attribute-Value-Datenmodell 226, 229 Erlang 196 Erlang/OPT 119 ETS 363 Euler, Leonhard 207 Eulerkreis 220 Eulerweg 220 Evans, Eric 1 Event-Daten 373 exist 369 Expiration-Time 194 F Facebook 1, 193 FarmVille 193 Filament 324 FileMap 23 Filtering 294 flapps 310 FlockDB 309, 366

16 Register Flow-based Programming 237 FluidDB 63 fold 13 full table scan 221 funktionale Sprache 12 Futon 123, 127 G Gemstone 369 geographische Daten 373 Geoinformationssystem 207 gerichtete Hyperkante 213 gerichtete Kante 209 GET 54 gewichteter Graph 212 GFS 1, 19 GigaSpaces 7, 368 Gizzard 366 Go 24 Google 12, 50, 367 Google Pregel 312 Google Query Language 367 GQL 302, 304, 367 Graph gewichteter 212 hierarchischer 215 multi-relationaler 210 Partitionierungsalgorithmus 219 Persistenz 217 Repräsentation 217 Traversierung 219 Visualisierung 215 Graph Query Language 225, 243, 302 Graphdatenbank 6 Graphdatenverarbeitung 209 GraphDB 343 Graphenmodell, allgemeines 209 Graph-Traversal 233, 240 Graphtraversierung 219, 225 Greenplum 23, 368 Gremlin 225, 240, 249 Grep 22 Grid-Datenbank 6 GridFS 134 GridGain 23 Groovy 240 GROUP BY 142 GT.M 1, 366 GXEF 308 H Hamiltonkreis 220 Hamiltonweg 220 Hashes 160 Hashfunktionen 36 Haskell 14 Hazelcast 7, 368 HBase 64 HDFS 80, 356 HEAD 54 Hidden Handoff 179 hierarchischer Graph 215, 216 Hinted Handoff 191 Hive 372 Holumbus 24 Hook 330 HQL 356 HTML-Formulare 55 HTTP 51, 244 HyperGraphDB 213, 269 Hyperkante 213 gerichtete 213 Hypernode 215 HyperSQL 173 Hypertable 356 I IBM 119 IBMs Lotus 368 Idempotenz 53 IEnumerable 237 IEnumerator 237 igraph 230 Indexdatenstruktur 215 Indexfreie Traversierung 229 Indizierung von Graphdaten 221 Indizierungsverfahren 221 InfoGrid 1, 284 Inzidenzmatrix 218 IP-Adresse 44 ISideEffectPipe 238 Register 387

17 388 Register ISIS 368 Iterator 237 J Jabber 274 Java 184 JavaScript 120, 132, 188 JDBC 162 JDO 367 Jena 249 join 187, 229 JPA 367 JRuby 69, 244, 330 JSON 8, 72, 119, 179, 228, 330 Judd, Doug 356 JUNG Graph Framework 217, 230 JVM 302 K KAI 360 Kante abgeleitete 216 gerichtete 209 ungerichtete 209, 213 versionierte 216 virtuelle 214 Kantenlabel 211 Kantenliste 218, 219 Key/Hash-Datenbank 1 Keyspace 50, 64, 83 Key/Value 6 Knoten, versionierter 216 Konfiguration 335 Konflikterkennung 94 Königsberger Brückenproblem 208 Konsistenz 30 Kosten 97 Kryptographie 36 kürzester Weg 208 Kyoto Cabinet 364 L Lastverteilung 59 Leader 48 LexicalUUIDType 87 Link 52, 55, 180 Link-Typ 57 link-walking 187 Linked Open Data 207 LinkedIn 1 LINQ 4 LISP 13 Liste 158 Listener 335 Literal 210 locality of reference 218 Location Based Services 8 Log-Daten 373 logische Schlussfolgerung 215, 248 LongType 87 Lotus Notes 1 Lucene 222 M MAC-ID 44 map 13 Mapper, objekt-relationaler 229, 236 Map/Reduce 1, 12, 140 MarkLogic 369 Master 20 Maximaler Fluss 208 Mehrfachkante 209, 211 Membase 193 Membase-Protokoll 199 Memcached 1, 193 MemcacheDB 366 Message-Daten 373 Metadaten 373 Methoden (HTTP) 53 Minimaler Spannbaum 208 MonetDB 63, 368 MongoDB 24, 131 Monotonic Read Consistency 34 Monotonic Write Consistency 35 Moxi 202 Multigraph 209 Multimodel Store 330 Multi-Node Cluster 68 Multiprozessor 166 multi-relationaler Graph 210 Multi-Value Properties 212

18 Register 389 Multiversion Concurrency Control 216 Mustererkennung 215 MVCC 41, 356 MySpace 1 MySQL 31, 310 N Nebenläufigkeitskontrolle 216 Neo4j 1, 8, 232, 290 Netz, soziales 224 n-hop-cover 244 NuvolaBase 353 NVIDIA GPUs 23 O ObjectDB 340 Objectivity 369 Objektdatenbank 6, 369 Objektdatenmodell 331 Objekt-Graph-Mapper 236 objektorientiertes Datenmodell 227 Objekt-relationaler Mapper 229, 236 OLAP 63 Ontologie 214, 227 Open Source 3 OpenSSL 121 Operationen 52 OrderPreservingPartitioner 92 OrientDB 329 OrientDB-Studio 334 OrientKV 330 Oskarsson, Johan 1 owl\ inverseof 258 sameas 258 SymmetricProperty 258 TransitiveProperty 258 OWL 249 P PaaS 367 Pacer 244 Page-Rank 208 Paging 160 Paretoprinzip 224 Partitioner 92 Partitionierung 222 Partitionierungsalgorithmus 224 Partition Tolerance 31 Patent 12 Pattern-Matching 192, 208 Paxos 48, 363 Peer-to-Peer 177 Performance-Dimensionen 376 Persistenz von Graphen 217 Pfad 214 Pfaddefinition, semantische 214 Phoenix 23 Pig 372 Pipeline 239 Pipelining 166 Pipes.NET 237 POJO 340 POST 54 Postgres 31 Potenzgesetz 224 Prädikat 210 Prevayler 368 Primärschlüssel 65 Progress 369 Prolog 249 Property 210 virtuelle 216 Property-Graph 230, 303 Property-Graph-Datenmodell 210, 225 Property-Graph-Modell 331 Proposer 48 protobuf 73 Prozess, asynchroner 237 Prüfsummen 36 Pruning 294 PUT 54 pycassa 88 Q Qizmt 24 Qt-Concurrent 23 Quadtree 221 Query-by-Example 253 QuickGraph 234 Quintupel 249

19 390 Register Quorum 191 Quorum-Consensus-Algorithmen 47 Quota 195 R RAM 152 randomisierte Traversierung 219, 221 RandomPartitioner 92 Range Queries 91 RavenDB 358 rdf\ type 257 RDF 8 RDF RDF-Datenbank 250 RDF Query Language 225 RDF-Reasoning 248, 257 RDF-Schema 214, 227 RDF Schema Language (RDFS) 257 RDF-Statements 253 RDF-Store 209, 227, 248 RDF-Triple-Store 259 rdfs\ domain 257 range 258 subclassof 257 subpropertyof 258 RDFS 249 Read-your-write Consistency 34 Reasoning 214 Rebalance 201 Rechtemanagement 332 Record 332 RecordID 332 rediff.com 356 Redis 152 redis-conf 165 Refactoring 379 RegionServer 78 Reification 249 Relation höherer Ordnung 213 Relationales Datenmodell 225 Replikation 145, 180, 222, 379 Replizierung 351 Repräsentation, Graphen 217 Repräsentationen 52 REpresentational State Transfer 51 Resource Description Framework 208, 227 Ressourcen 52 REST 4, 51, 179, 244 RevisionId 212, 234 Rexster 244 Riak 39, 117, 179 RightScale 194 Ring 38, 93, 176, 190 Ring-Adressraum 179 Row 85 R-Tree 221 Ruby 163, 185 rufus-tokyo 365 S SaaS 114, 367 Safety 53 Sanfillippo, Salvatore 152 Scala 164, 330 Scalaris 50, 363 Scale-out 377 Scale-up 377 Scalien 50 Schema 133 Schlüsselraum 190 Schlussfolgerung, logische 215, 248 Schreibsperre 216 SciDB 64 Scratchpad 101 Secondary Indices 92 Sector/Sphere 24 Sedna 369 seed node 93 Seiteneffekt 238 SemanticProperty 235 Semantic Web 227, 248 Semantische Pfaddefinition 214 Sesame 249 Session Consistency 34 Session-Daten 373 Sets 158 Shard 143 Sharding 143 shared memory 19 shared-nothing 179

20 Register 391 Shell 267 Sibling 183 Sicherheit 380 Single-Master-Multiple-Slave 222 Single-Node Cluster 68 Skalierbarkeit 3 Skiplist 221 Skynet 24 SNMP-Protokoll 181 SOAP 97 Software as a Service 228 sones 302 SonesDB 8 soziales Netz 224 Spaltenfamilie 66 Spannbaum, minimaler 208 SPARQL 225, 249 Sprache, funktionale 12 SQL 192 Stargate 72 Statuslosigkeit 59 sticky session 223 Storage 332 Straßennavigationssystem 212 Strozzi, Carlo 1, 5 StumbleUpon 65 subcomparator 87 Subgraph 215 Subgraphdefinition 215 SuperColumns 83, 86 SwapSpace 363 Sybase IQ 368 SybaseIQ 63 T Tamino 369 TAP-Schnittstelle 203 Teilgraph 223 telnet 155 Temporäre Daten 373 Terrastore 358 Thompson, Ken 1 Thrift 74, 356 ThruDB 358 Tiefensuche 219 Timeout 188 Time To Live 157 TimeUUIDType 87 TinkerGraph 242 Tinkerpop 230, 330, 343 Tinkerpop Blueprints 209 Tinkerpop Frames 234, 236 Tinkerpop Pipes 237 Tokyo Cabinet 363, 364 Tokyo Dystopia 364 Tokyo Promenade 364 Tokyo Tyrant 364 Transaktion 233, 347 Traveling Salesman 220 Traversierung indexfreie 229 randomisierte 219, 221 von Graphen 219 Triple 210 TripleId 250 Tupel 133 Tuple Stores 6 Twister 23 Twitter 309, 366 Two-Phase-Commit-Protokoll 47 U Ubuntu 130, 182 ungerichtete Kante 209, 213 Uniform Resource Identifier 53, 210 Uniform Resource Locator 53 Unique Part Identifier, UPI 250 UNIX 153 UTF UTF8Type 87 V Validierung 88 Vector Clocks 43, 181, 183, 359 Vektorclock 212 Verfügbarkeit 31 Versant 369 versionierte Kante 216 versionierter Knoten 216 Versions-Vektoren 44 VertexDBs 321

21 392 Register Vertica 368 Views 120, 127 Virtual Memory 197 virtuelle Kante 214, 216 virtueller Knoten 216 virtuelle Property 216 virtueller Server 39 Visualisierung 215 von Graphen 215 VMWare 152 vnodes 190 Vogels, Werner 34 W Web Ontology 227 Web Ontology Language (OWL) 214, 257 web-scale 51 WebShell 304 Weg, kürzester 208 Wide Column Stores 6 Wissensrepräsentation 207, 210 Worker 20 X X Xindice 369 XLINK 228 XML 228 XML-Datenbank 6, 369 XMPP 274 XPath 240 XPRISO 285 Y Yahoo 1, 65 YAML 8 Z Zeitstempel 87 Zipfsches Gesetz 224 zookeeper 67 Zygna 193