6.4 Nicht-Relationale Datenbanksysteme

Transkript

1 6.4 Nicht-Relationale Datenbanksysteme In den letzten 10+ Jahren ist eine Vielzahl verschiedenartiger nicht-relationaler Datenbanksysteme entstanden Einen Überblick über die verschiedenen entstandenen Arten von nicht-relationalen Datenbanksystemen sowie den Vorschlag einer Gruppierung bietet folgender Artikel R. Catell: Scalable SQL and NoSQL Data Stores SIGMOD Record, December

2 6.4.1 Key-Value Stores Key-Value Stores speichern Schlüssel-Wert-Paare wie (37821, Max Müller ) und bieten zumindest folgende Methoden zum Zugriff put(key, value) legt Wert zu Schlüssel ab get(key) holt Wert zu Schlüssel sofern die zugrundeliegende Datenstruktur die Ordnung der Werte beibehält, gibt es zudem Bereichsanfragen range(low, high) holt Werte mit Schlüsseln im Bereich Schlüssel und Werte sind intern meist byte[], Entwickler muss sich um Serialisierung/Deserialisierung kümmern 48

3 Key-Value Stores Verbreitete Systeme: BerkeleyDB ( Redis ( Riak KV ( Project Voldemort ( Systeme übernehmen häufig Ideen aus Amazon Dynamo: G. DeCandia et al.: Dynamo: Amazon s Highly Available Key-value Store, ACM SOSP

4 BerkeleyDB BerkeleyDB ist ein Key-Value-Store zum Betrieb auf einem Rechner, der zudem (ähnlich SQLite) in Anwendungen eingebettet werden kann BerkeleyDB basiert auf einem B + -Baum als Datenstruktur und unterstützt somit auch Bereichsanfragen BerkeleyDB Java Edition bietet sogenannte Stored Collections; diese implementieren die von Java bekannten Interfaces List und Map und lagern Daten transparent im Sekundärspeicher aus 50

5 Redis Redis ist ein verteilter Key-Value Store, der Daten im Hauptspeicher der Rechner hält, sofern keine Dauerhaftigkeit sichergestellt werden muss Replikation (d.h. die gleichen Daten werden mehrfach gehalten) erlaubt zudem eine Skalierung bei Wachstum der Anfragelast 51

6 HollywoodDB in Redis Schauspieler und Filme in jeweils eigenem Namespace 3141 { Vorname : Uma, Name : Thurman, Geburstdatum : spieltin : [{ FId : 2718, Rolle : Die Braut }, ] } { Titel : Kill Bill, Volume 1, Jahr : 2003, Land : U.S.A. darinspielt : [{ SId : 3141, Rolle : Die Braut }, ] }... Schauspieler Filme 52

7 HollywoodDB in Redis Q1: Alle Attributes des Schauspielers mit der SId 3141 get( Schauspieler_3141 ) Q2: Alle Filme aus Land U.S.A. mit ihren Attributen Scannen und Filtern aller Filme in der Anwendung Redis unterstützt selbst keine Indizes, wir könnten jedoch in unserer Anwendung einen Index verwalten, z.b. Land_U.S.A { FIds : [2718, ] } 53

8 HollywoodDB in Redis Q3: Alle Schauspieler mit ihren Attributen, die in dem Film mit dem Titel Kill Bill, Volume 1 mitgespielt haben Redis unterstützt keine Verknüpfungen (Joins) Finden des Films mit dem gegebenen Titel wie in Q2 Scanne und Filtern aller Schauspieler in der Anwendung Q4: Anzahl der Filme, in denen der Schauspieler mit der SId 3141 pro Jahr gespielt hat, aufsteigend sortiert nach dem Jahr Scannen aller Filme in der Anwendung bei gleichzeitigen Gruppieren und Aggregieren 54

9 6.4.2 Extensible Record Stores Extensible Record Stores erweitern die Idee von Key- Value Stores, indem sie für den Wert eine Struktur (ähnlich dem Schema einer Tabelle) zulassen Schlüssel ist weiterhin z.b. ein byte[] Wert besteht aus Paaren von Spaltenname und -wert Im Gegensatz zum relationalen Modell gibt es kein fixes Schema und das System ist für dünnbesetzte Daten optimiert, d.h. Spalten für die meisten Daten unbekannt BigTable als ein bei Google entwickeltes System war Vorreiter der Extensible Record Stores 55

10 Extensible Record Stores Operationen: Im einfachsten Fall wie bei Key-Value Stores Verbreitete Systeme: Apache HBase ( Apache Cassandra ( Hypertable ( Systeme übernehmen häufig Ideen aus Google BigTable: F. Chang et al.: Bigtable: A Distributed Storage System for Structured Data, ACM Transactions on Computer Systems 26(2):4,

11 Apache Cassandra Aufgrund des vorgegebenen Schemas kann man sich die Daten als Tabelle, evtl. mit vielen Lücken, vorstellen Apache Cassandra imitiert soweit möglich SQL und bietet mit CQL eigene Sprache für DDL, DML und DQL Schauspieler SId Vorname Name Geburtsdatum spieltin 3141 Uma Thurman [2718,... ]. Filme FId Titel Jahr Land darinspielt 2718 Kill Bill, Volume U.S.A. [3141,... ] Mengenwertige Attribute. 57

12 HollywoodDB in Apache Cassandra Q1: Alle Attributes des Schauspielers mit der SId SELECT * 2 FROM Schauspieler 3 WHERE SId = 3141 Q2: Alle Filme aus Land U.S.A. mit ihren Attributen 1 SELECT * 2 FROM Filme 3 WHERE Land = U.S.A. Cassandra warnt vor Bearbeitung durch Scannen der Tabelle Cassandra kann Anfrage durch Anlegen eines Index auf einer einzelnen Spalte (hier: Land) beschleunigen 58

13 HollywoodDB in Apache Cassandra Q3: Alle Schauspieler mit ihren Attributen, die in dem Film mit dem Titel Kill Bill, Volume 1 mitgespielt haben Cassandra unterstützt keinerlei Joins, daher Zerlegung in zwei Anfragen notwendig ( Film mit Titel Kill Bill, Volume 1 dann Schauspieler, die in Film mit Fid 2718 gespielt haben ) Q4: Anzahl der Filme, in denen der Schauspieler mit der SId 3141 pro Jahr gespielt hat, aufsteigend sortiert nach dem Jahr Cassandra unterstützt Gruppierung und Aggregation nur auf Attributen des Primärschlüssels, daher müssen diese in der Anwendung erfolgen 59

14 6.4.3 Dokumentorientierte Datenbanken Dokumentenorientierte Datenbanken (document stores) modellieren die Daten als Dokumente in einem Format wie JSON oder XML JavaScript Object Notation (JSON) leichtgewichtiges Format, ursprünglich zur Serialisierung von JavaScript-Objekten JSON-Dokument ist Folge von Schlüssel-Wert-Paaren Schlüssel ist ein String Wert ist ein String, Integer, Float, Boolean, Array oder ein geschachteltes JSON-Dokument 60

15 Dokumentenorientierte Datenbanken Operationen: Einfügen, Löschen und Ändern von Dokumenten Anfragen in stark unterschiedlichem Umfang und Ausprägung JSON-Dokumente als Kombination von Wertevergleichen JavaScript-Funktion, die auf jedes Dokument angewandt wird MapReduce-Implementierungen für komplexeste Anfragen Verbreitete Systeme: CouchDB ( MongoDB ( Elasticsearch ( 61

16 JavaScript Object Notation (JSON) Beispiel: JSON-Dokument zu Uma Thurman { Vorname : Uma, Name : Thurman, Geburstdatum : spieltin : [{ FId : 2718, Rolle : Die Braut }, ] } JSON ist leicht zu lesen und zu verarbeiten JSON ist im Vergleich zu XML leichtgewichtiger JSON selbst legt kein Schema fest, mit JSON-Schema existiert jedoch ein Format zur Schemadefinition, so dass Dokumente validiert werden können 62

17 Dokumentenorientierte Datenbanken Zugriff auf so gespeicherte Daten dann mittels Anfrageprädikaten z.b. { Name : Thurman } Systeme bieten teilweise zusätzliche Funktionalität Gruppierung und Aggregation (MongoDB) MapReduce zur Anfrageformulierung (CouchDB) Indizes auf ausgewählten Attributen (MongoDB, CouchDB) Verteilung und Replikation zur Skalierung bei großen Datenmengen und/oder hoher Anfragelast 63

18 MongoDB & CouchDB MongoDB erwartet Dokumente im JSON-Format; erlaubt Anfrageterminologie an SQL angelehnt CouchDB erwartet Dokumente im JSON-Format; erlaubt Implementierung von Anfragen in MapReduce 64

19 MongoDB Schauspieler und Filme jeweils in eigener Collection { _id : 3141, Vorname : Uma, Name : Thurman, Geburstdatum : spieltin : [{ FId : 2718, Rolle : Die Braut }, ] }... { _id : 2718, Titel : Kill Bill, Volume 1, Jahr : 2003, Land : U.S.A. darinspielt : [{ SId : 3141, Rolle : Die Braut }, ] }... Schauspieler Filme 65

20 HollywoodDB in MongoDB Q1: Alle Attributes des Schauspielers mit der SId db.schauspieler.find({" _id" : 3141}) Q2: Alle Filme aus Land U.S.A. mit ihren Attributen 1 db.filme.find({" Land" : "U.S.A."}) Anfrage kann durch Anlegen eines Index auf der Spalte Land beschleunigt werden MongoDB unterstützt Indizes über mehrere Spalten und bietet zahlreiche Optionen zu deren Kalibrierung 66

21 HollywoodDB in MongoDB Q3: Alle Schauspieler mit ihren Attributen, die in dem Film mit dem Titel Kill Bill, Volume 1 mitgespielt haben db.filme.aggregate([ {$match : {Titel : "Kill Bill, Volume 1"}}, {$unwind : "$darinspielt"}, {$project : {darinspielt : 1}}, {$lookup : {from : "Schauspieler", localfield : "darinspielt.sid", foreignfield : "_id", as : "Schauspieler"}}, {$project : {Schauspieler : 1}} ]) 67

22 HollywoodDB in MongoDB Q4: Anzahl der Filme, in denen der Schauspieler mit der SId 3141 pro Jahr gespielt hat, aufsteigend sortiert nach dem Jahr db.filme.aggregate([ {$unwind : "$darinspielt"}, {$match : { "darinspielt.sid" : 3141}}, {$group : { _id : "$Jahr", Anzahl : {$sum : 1} }}, {$sort : {"Jahr" : 1}} ]) 68

23 6.4.4 Graphdatenbanken Graphdatenbanken (graph stores) speichern Daten in Form eines gerichteten, beschrifteten Graphs (directed labeled graph) Man kann zwei Variationen dieser Idee unterscheiden Semantic Web -Ansatz (nach T. Berners-Lee) auf Grundlage der W3C-Standards RDF und RDF Schema, wobei alles als Knoten und Kanten im Graph dargestellt wird Property-Graph-Modell hingegen erlaubt, dass Knoten und Kanten eigene Attribute besitzen können, was im Vergleich zu kompakteren Graphen führt 69

24 Graphdatenbanken Festes Schema, wie beim relationalen Modell, ist meist nicht erforderlich, d.h. neue Beschriftungen für Kanten und Knoten können hinzugefügt werden Triple Stores für Daten im Semantic-Web Format RDF mit Anfragesprache SPARQL sind Spezialfall von Graphdatenbanken 70

25 Graphdatenbanken Operationen: Einfügen, Löschen und Ändern von Knoten und Kanten Anfragen basieren auf der Angabe von Graphmustern (graph patterns), die komplexe Operationen (z.b. kürzeste Pfade) beinhalten können Schema ist flexibel, kann jedoch (z.b. mittels RDF Schema) angegeben und dann auch validiert werden Skalierung durch Partitionierung und/oder Replikation ACID-Transaktionen (Neo4J und OrientDB) 71

26 Resource Description Framework (RDF) Resource Description Framework (RDF) stellt Graph als Sammlung von (Subjekt, Prädikat, Objekt)-Tripeln dar, wobei Subjekt sowie Prädikat URIs und das Objekt eine URI oder ein Wert (literal) sein können <s:2718, a:name, Thurman > RDF Schema zur Schemadefinition SPARQL als Anfragesprache für RDF-Daten RDF, RDF Schema und SPARQL sind Standards des W3C 72

27 Property Graph Model Property Graph Model fordert, dass Kanten beschriftet sind, dass Knoten und Kanten eine eindeutige ID besitzen und erlaubt, dass diesen eine Menge von Attributen (Schlüssel-Wert-Paare) zugeordnet ist 73

28 RDF vs. Property Graph Model f:3141 Thurman _id : s2718 Name : Thurman Vorname : Uma Geburtsdatum : a:spieltin a:name spieltin _id : sf6643 Rolle: Die Braut a:geb. s:2718 a:vorname Uma _id : f3141 Titel : Kill Bill 1 Land : U.S.A. Jahr : 2013 RDF Property Graph Model 74

29 Graphdatenbanken Verbreitete Systeme (RDF) sogenannte Triple Stores: Apache Jena ( Virtuoso ( RDF4J ( Verbreitete Systeme (Property Graph Model): Neo4J ( OrientDB ( 75

30 Neo4J Neo4J zum Betrieb auf einem Rechner; bietet mit Cypher eine eigene Anfragesprache, die auch Graphoperationen wie kürzeste Pfade unterstützt OrientDB zum Betrieb auf mehreren Rechnern; unterstützt SQL als Anfragesprache 76

31 Neo4J Neben Kanten können auch Knoten beschriftet werden und hierdurch, ähnlich zu Tabellen, typisiert werden Cypher als SQL-artige Anfragesprache 1 CREATE (s:schauspieler { 2 SId:3141, 3 Vorname: Uma, 4 Name: Thurman, 5 Geburtsdatum: }) Integritätsbedingungen zur Schemadefinition welche Attribute muss ein Knoten besitzen welche Attribute müssen eindeutig sein welche Attribute sind voneinander abhängig 77

32 HollywoodDB in Neo4J Q1: Alle Attributes des Schauspielers mit der SId MATCH (s:schauspieler) 2 WHERE s.sid = RETURN * Q2: Alle Filme aus Land U.S.A. mit ihren Attributen 1 MATCH (f:filme) 2 WHERE f.land= U.S.A. 3 RETURN * Anfrage kann durch Anlegen eines Index auf dem Attribut (Spalte) Land beschleunigt werden Indizes über Kombination von Attributen unterstützt 78

33 HollywoodDB in Neo4J Q3: Alle Schauspieler mit ihren Attributen, die in dem Film mit dem Titel Kill Bill, Volume 1 mitgespielt haben 1 MATCH (s:schauspieler)-[r:spieltin]->(f:filme) 2 WHERE f.titel= Kill Bill, Volume 1 3 RETURN s 79

34 HollywoodDB in Neo4J Q4: Anzahl der Filme, in denen der Schauspieler mit der SId 3141 pro Jahr gespielt hat, aufsteigend sortiert nach dem Jahr 1 MATCH (s:schauspieler)-[r:spieltin]->(f:filme) 2 WHERE s.sid= RETURN COUNT(f.Titel) AS Anzahl, f.jahr 4 ORDER BY f.jahr 80

35 Zusammenfassung NoSQL bietet Alternativen zu RDBMSs für Anwendungen, die z.b. keine ACID-Transaktionen benötigen, kein rigides Schema festlegen können oder ihre Daten auf viele herkömmliche Rechner verteilen müssen Bei rudimentären Systemen (z.b. Key-Value Stores) müssen Entwickler vieles, was bei einem RDBMS gegeben ist, beispielsweise Joins, selbst implementieren SQL als Anfragesprache spielt auch in NoSQL-Systemen eine Rolle und wird zunehmend nachgerüstet (z.b. Apache Drill und Apache Impala) 81

36 Zusammenfassung Konvergenz von RDBMS und NoSQL-Datenbanken RDBMS lernen andere NoSQL-Ansätze zu imitieren (z.b. SAP HANA als Graphdatenbank) JSON als zusätzlicher Datentyp zur Schemaflexibilisierung (z.b. in PostgreSQL und MySQL) SQL-Anfragen über NoSQL-Datenbanken z.b. mittels JDBC-Treibern (z.b. für MongoDB) oder RDBMS mit NoSQL-Storage (z.b. Apache Phoenix) 82

37 Zusammenfassung Unterschiedliche Ansätze für unterschiedliche Anforderungen Key-Value Stores: keinerlei Schema, hohe Lese-/Schreiblast, einfachste Anfragen Caches Extensible-Record Stores: erweiterbares Schema, hohe Lese-/Schreiblast, objektbezogene Anfragen Document Stores: flexibles Schema, hohe Lese-/Schreiblast, objektbezogene Anfragen Object Stores Graphdatenbanken: flexibles Schema, komplexe Anfragen über Objekte und deren Beziehungen Social Networks 83

38 Literatur [1] A. Kemper und A. Eickler: Datenbanksysteme Eine Einführung, De Gruyter Oldenbourg, 2015 (Kapitel 21) [2] L. Wiese: Advanced Data Management for SQL, NoSQL, Cloud and Distributed Databases, DeGruyter, 2015 [3] M. Kleppmann: Designing Data-Intensive Applications, O Reilly,