NoSQL-Datenbanksysteme - Fachbereich Informatik Hochschule

NoSQL-Datenbanksysteme:
Revolution oder Evolution?
Kolloquium Institut für Informatik, Universität Rostock
24.01.2013
Prof. Dr. Uta Störl | Hochschule Darmstadt | [email protected]
NoSQL: DAS aktuelle Datenbank-Buzzword
Quelle: http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html
Uta Störl
NoSQL-Datenbanksysteme
2
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Koexistenz von SQL- und NoSQL-Datenbanksystemen?
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
3
Motivation: Big Data
• Big Data
– Social Network Daten (LinkedIn, Facebook, Twitter etc.)
– Social Networking Feeds (Facebook oder Twitter Feeds von
Firmenseiten)
– Log Analysen (Web Logs, Sensor Logs, Event Logs etc.)
– Gaming Data
– Streaming Data
– …
Uta Störl
NoSQL-Datenbanksysteme
4
Eigenschaften von BigData: The 4 V‘s
Quelle: L. Haas, IBM
Uta Störl
NoSQL-Datenbanksysteme
5
NoSQL (Not only SQL): Definition
Es existiert noch kein einheitliche Definition – ein Variante:
[Edlich et al: 2011 bzw. http://nosql-database.org/]
Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die
meistens einige der nachfolgenden Punkte berücksichtigen:
• Das zugrundeliegende Datenmodell ist nicht relational.
• Das System ist schemafrei oder hat nur schwächere Schemarestriktionen.
• Das System bietet eine einfache API. aktuell werden komplexere APIs entwickelt
• Die Systeme sind von Anbeginn an auf eine verteilte und horizontale
Skalierbarkeit ausgerichtet.
• Aufgrund der verteilten Architektur unterstützt das System eine einfache
Datenreplikation.
• Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde:
Eventually Consistent und BASE, aber nicht ACID
inzwischen teilweise
„sowohl als auch“
• Das NoSQL-System ist Open Source. ???
Uta Störl
NoSQL-Datenbanksysteme
6
NoSQL: Die Essenz
Datenmodell
• Das zugrundeliegende Datenmodell ist nicht relational.
• Das System ist schemafrei oder hat nur schwächere
Schemarestriktionen.
Skalierungsarchitektur
• Die Systeme sind von Anbeginn an auf eine verteilte und horizontale
Skalierbarkeit ausgerichtet.
• Aufgrund der verteilten Architektur unterstützt das System eine
einfache Datenreplikation.
Uta Störl
NoSQL-Datenbanksysteme
7
NoSQL: Die Essenz
Datenmodell
• Das zugrundeliegende Datenmodell ist nicht relational.
• Das System ist schemafrei oder hat nur schwächere
Schemarestriktionen.
Skalierungsarchitektur
• Die Systeme sind von Anbeginn an auf eine verteilte und horizontale
Skalierbarkeit ausgerichtet.
• Aufgrund der verteilten Architektur unterstützt das System eine
einfache Datenreplikation.
Uta Störl
NoSQL-Datenbanksysteme
8
(Mögliche) Kategorisierung
•
(Noch) keine einheitliche Klassifikation – häufig verwendete Kategorisierung in
Anlehnung an http://www.nosql-database.org/
•
Core NoSQL Systems:
– Key-Value Databases
– Document Databases
– Column Family Databases
– Graph Databases
– Neu (2012): Multimodel Databases
•
Soft NoSQL Systems:
– Object Databases
– Grid & Cloud Database Solutions
– XML Databases
– Multivalue Databases
– …
Uta Störl
NoSQL-Datenbanksysteme
9
Key-Value Databases
• Datenmodell
– Key-Value-Paare mit eindeutigem Key
(„the big hash table“)
– Key und Value enthalten Byte-Arrays =
beliebige, serialisierte Datentypen
(für value auch beliebig komplex)
– Typische Grundoperationen:
• set (key, value)
• value = get (key)
• delete (key)
key
value
key
value
key
value
key
value
key
value
• Indexstrukturen:
– Hash-Maps, B*-Bäume auf key
• Systeme: Amazon Dynamo / S3, Redis, Riak, Voldemort, …
Uta Störl
NoSQL-Datenbanksysteme
10
Document Databases
• Datenmodell
– Kleinste logische Einheit: „Dokument“ identifiziert über
documentID
{
– Format i.a. JSON, BSON, YAML, RDF
"id": 1,
"name": “football boot",
– Schemafrei, d.h. Anwendung übernimmt
"price": 199,
Schema-Verantwortung
"stock": {
"warehouse": 120,
"retail": 10
}
• Indexstrukturen
}
– B-Baum-Index für documentID
– Teilweise auch B-Baum-Indexe für Datenfelder in Dokumenten
• Systeme
– MongoDB, CouchDB, …
Uta Störl
NoSQL-Datenbanksysteme
11
NoSQL: Die Essenz
Datenmodell
• Das zugrundeliegende Datenmodell ist nicht relational.
• Das System ist schemafrei oder hat nur schwächere
Schemarestriktionen.
Skalierungsarchitektur
• Die Systeme sind von Anbeginn an auf eine verteilte und horizontale
Skalierbarkeit ausgerichtet.
• Aufgrund der verteilten Architektur unterstützt das System eine
einfache Datenreplikation.
Uta Störl
NoSQL-Datenbanksysteme
12
Scale up vs. Scale out
Scale up: wenige, große Server
Scale out: viele, kleinere
(Commodity-)Server
Quelle: ibm.com
Uta Störl
Quelle: eggmusic.com
NoSQL-Datenbanksysteme
13
Scale up vs. Scale out
Scale up
• Vorteile:
– transparent für DBMS
– Administrationsaufwand
konstant
• Nachteile:
– Hardware-Kosten
– Skalierung nur in größeren
Stufen möglich  höhere
Kosten und ungenutzte
Leistung
Uta Störl
Scale out
• Vorteile:
– Kostengünstigere
Hardware
– Skalierung in kleineren
Stufen möglich
• Nachteile:
– Last- und Datenverteilung
notwendig
– Ggf. verteilte Protokolle
(2PC, Replikation)
– Erhöhte Fehlerrate (mehr
und einfachere Hardware)
– Erhöhter
Administrationsaufwand
NoSQL-Datenbanksysteme
14
Scale out: CAP-Theorem
Eigenschaften verteilter Datensysteme:
• Consistency: alle Clients (Anwendungen) haben die gleiche Sicht auf
den Datenbestand – auch im Fall von Updates
• Availability: jeder Request an einen non-failing Knoten führt zu einer
Antwort, d.h. ausgefallene Knoten beeinflussen nicht die Verfügbarkeit
der anderen Knoten.
• Partition Tolerance: Systemeigenschaften bleiben auch bei
Partitionierung des Netzwerks erhalten (d.h. Knoten können weiter
funktionieren auch wenn die Kommunikation mit anderen
Knotengruppen verloren gegangen ist)
 CAP Theorem (Eric Brewer, 2000): in verteilten Datensystemen sind zu
jeder Zeit nur maximal zwei dieser drei Eigenschaften erreichbar
Uta Störl
NoSQL-Datenbanksysteme
15
Konsistenz in AP-Systemen?
• Strong Consistency
– Nach Abschluss eines Updates sehen alle nachfolgenden Zugriffe
(auch an anderen Knoten!) den aktuellen Wert
(entspricht C in ACID)
• Weak Consistency
– Es ist nicht garantiert, dass nachfolgende Zugriffe den aktuellen
Wert sehen
– Spezialform: Eventual Consistency (Vogel, 2008):
Es ist garantiert, dass nach einem Zeitfenster schlussendlich
(eventually) alle Zugriffe den aktuellen Wert sehen (falls
zwischenzeitlich keine weiteren Updates erfolgen)
Uta Störl
NoSQL-Datenbanksysteme
16
Eventual Consistency aus Sicht des Client
Praktisch relevante Spezialformen der Eventual Consistency:
• Read-your-writes Consistency
– Jeder Prozess sieht seine eigenen Änderungen (niemals ältere
Werte für die geänderten Objekte)
• Session Consistency
– Read-your-writes innerhalb einer Session
• Monotonic Read Consistency
– Wenn ein Prozess einen Wert gelesen hat, sieht er danach nie einen
älteren Wert für dieses Objekt.
• Monotonic Write Consistency
– Die Schreiboperationen einer Transaktion werden vom System
serialisiert
Uta Störl
NoSQL-Datenbanksysteme
17
Eventual Consistency – Server Side
•
Terminologie:
– N: Anzahl der Replikate eines Datenobjektes
– W: Anzahl der Replikate, die den Erhalt des Update bestätigt haben
müssen, bevor das Update abgeschlossen werden kann
– R: Anzahl der Replikate, die während einer Lese-Operation gelesen
werden
W+R > N
 Strong Consistency durch Quorum
W+R <= N
 Weak/Eventual Consistency
W
W
R
R
Typische Konfiguration im NoSQL-Umfeld:
N=3, R=2, W=2
Uta Störl
NoSQL-Datenbanksysteme
18
Eventual Consistency am Beispiel Cassandra
•
•
Cassandra
– ursprünglich von facebook entwickelt – seit 2008 Apache Projekt
– u.a. genutzt von Twitter, Digg, bis 2010 auch facebook (dort inzwischen
ersetzt durch HBase)
Write Consistency Level
– Zero: Asynchrones Schreiben im Hintergrund
– Any/One: Stellt sicher, dass die Schreiboperation an mindestens einem
Knoten ausgeführt wurde
– Quorum: Stellt sicher, dass die Schreiboperation an der Mehrheit der
Knoten (N/2 + 1) geschrieben wurde
– All: Stellt sicher, dass die Schreiboperation an allen Knoten ausgeführt
wurde
• Read Consistency Level
– One: Rückgabewert des ersten antwortenden Knoten (ggf. inkonsistent)
– Quorum: Wenn eine Mehrheit der Knoten geantwortet hat, wird der Wert
mit dem jüngsten Zeitstempel zurückgegeben
– All: Wenn alle(!) Knoten geantwortet haben, wird der Wert mit dem
jüngsten Zeitstempel zurückgegeben
Uta Störl
NoSQL-Datenbanksysteme
19
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Koexistenz von SQL- und NoSQL-Datenbanksystemen?
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
20
Anwendungsentwicklung mit NoSQL-DBMS
• Unterschiedlichste Sprachanbindungen: Shell, Java, REST, Ruby, C#,
Python, PHP, …
• Einfachste Grundoperationen (get/put/delete o.ä.)
– Beispiel: Update in CouchDB (Shell)
$curl –X PUT http://127.0.0.1:5984/myCouch DB/
b8a025323b6b91d21c8997913831f46f -d
'{"_rev":"1-3014e70edc650450e45a8e0818bc7bce",
"unfallID":"1", "fahrzeugTyp":"Audi",
"personenAnzahl":"2"}'
• Aber auch erste (proprietäre) Ansätze von Anfragesprachen
CQL (Cassandra Query Language) INSERT / UPDATE / SELECT …
• Standardisierung?
UnSQL (Unstructured Query Language) – „One Language Fits All?“
Uta Störl
NoSQL-Datenbanksysteme
21
Parallelisierung der Anfrageverarbeitung
• Scale out – Skalierung auf viele (kleinere) Server
• Parallele Verarbeitung sehr großer Datenmenge erfordert neue
Algorithmen und Frameworks
• (alte) Idee aus funktionaler Programmierung (LISP, ML etc.)
– Operationen ändern die Daten nicht, sondern arbeiten immer auf
neu erstellten Kopien
 Unterschiedliche Operationen auf den gleichen Daten beeinflussen
sich nicht (keine Concurrency-Konflikte, keine Deadlocks, keine
RaceConditions)
 MapReduce
– Idee neu angewandt und mit komfortablem Framework vorstellt:
J. Dean and S.Gehmawat. MapReduce: Simplified Data Processing on Large
Clusters. OSDI'04. 2004 http://labs.google.com/papers/mapreduce.html
Uta Störl
NoSQL-Datenbanksysteme
22
MapReduce: Grundprinzip & WordCount Bsp.
•
Entwickler muss zwei primäre Methoden implementieren
– Map: (key1, val1) → [(key2, val2)]
– Reduce: (key2, [val2]) → [(key3, val3)]
Key
Documents
Doc1
Doc2
Sport, Handball,
Fußball
Fußball, DFB
Sport
MAP
Documents
Doc3
Sport, Halle, Geld
Doc4
Fußball, DFB, Geld
Uta Störl
Value
MAP
Key
1
Handball 1
Fußball
REDUCE
1
Fußball
1
Key
DFB
1
Sport
1
Halle
1
Geld
1
Fußball
1
DFB
1
Geld
1
Value
Sport
2
Handball
1
Fußball
3
Value
NoSQL-Datenbanksysteme
Key
REDUCE
Value
DFB
2
Halle
1
Geld
2
23
Map & Reduce Funktionen (Prinzip)
Beispielimplementierung in Hadoop (Java)
…
public static class Map extends MapReduceBase implements Mapper<LongWritable, Text, Text, IntWritable> {
…
public void map(LongWritable key, Text value, OutputCollector<Text, IntWritable> output, …) … {
String line = value.toString();
StringTokenizer tokenizer = new StringTokenizer(line);
while (tokenizer.hasMoreTokens()) {
word.set(tokenizer.nextToken());
output.collect(word, one);
}
}
}
public static class Reduce extends MapReduceBase implements Reducer<Text, IntWritable, Text, IntWritable> {
public void reduce(Text key, Iterator<IntWritable> values, OutputCollector<Text, IntWritable> output, …) … {
int sum = 0;
while (values.hasNext()) {
sum += values.next().get();
}
output.collect(key, new IntWritable(sum));
}
}
Quelle: http://hadoop.apache.org/docs/r1.0.4/mapred_tutorial.html
Uta Störl
NoSQL-Datenbanksysteme
24
MapReduce: Verbesserung mit Combine
•
Um die Ergebnisgröße zu reduzieren und die Shuffle-Kosten (Zuweisung der
Daten zum jeweiligen Reduce-Knoten) zu reduzieren, wird in der Praxis häufig
eine Combine-Phase auf dem Map-Knoten zwischengeschaltet:
Key
Documents
Sport, Handball,
Fußball
Fußball, DFB
Sport
MAP
Documents
Sport, Halle, Geld
Fußball, DFB, Geld
Uta Störl
MAP
Key
Value
Sport
1
Handball 1
COMBINE
Value
1
Handball 1
Fußball
2
DFB
1
Fußball
1
Fußball
Key
DFB
Sport
1
1
1
Halle
1
Sport
1
Geld
1
Halle
1
Fußball
1
Geld
2
DFB
1
Fußball
1
Geld
1
DFB
1
Value
Key
COMBINE
NoSQL-Datenbanksysteme
REDUCE
Value
REDUCE
25
Anwendungsentwicklung mit NoSQL-DBMS
• Trend: Verwendung von Query-Frameworks mit Operatoren auf
höherem Abstraktionslevel statt direkter MapReduce-Programmierung
– Analyse von großen Cloudera*-Kunden aus E-Commerce,
Telekommunikation, Medien und Einzelhandel:
Quelle: Chen, Alspaugh, Katz. Interactive Analytical Processing in Big Data Systems: A CrossIndustry Study of MapReduce Workloads; VLDB2012
*Cloudera: Kommerzieller Anbieter Hadoop-basierter Software und Services
Uta Störl
NoSQL-Datenbanksysteme
26
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Koexistenz von SQL- und NoSQL-Datenbanksystemen?
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
27
Performance
• Was „kostet“ Scale out?
– Flexibilität führt zu Storage-Overhead
• HBase: Faktor 2.1 ohne Replikation – Faktor 6.3 mit 3 Replikaten
(Quelle: Schindler, NoSQL I/O, VDLB2012)
– Verteilungsarchitektur impliziert per se Overhead
– Außerdem: NoSQL-Systeme häufig in Release 0.* oder 1.*
 noch viel Optimierungspotential
 Beobachtung in der Praxis: Die Daten- und Knotenmenge muss groß
genug sein, damit ein wirklicher Performance-Vorteil zum Tragen
kommt
Uta Störl
NoSQL-Datenbanksysteme
28
Benchmarks
•
•
•
Klassische DB-Benchmarks
– Benchmarks für typische Szenarien (OLTP: TPC-*, SAP-Benchmarks)
– Metriken:
• Performance (transactions per minute)
• Preis/Performance
• Skalierung über DB-Größe
Benchmarks für NoSQL-Systeme?
– Was ist ein „typisches“ NoSQL-Szenario? Facebook? Log-Analyse? ?
– Metriken:
• Verhalten bei wachsender Datenmenge
• Verhalten bei veränderter Server-Anzahl (dynamisches Hinzufügen und
Entfernen)
State of the art
– Diverse Untersuchungen für ganz spezifische Anwendungen und Vergleich
von System x mit System y
– Bisher kaum generalisierende Benchmarks
Uta Störl
NoSQL-Datenbanksysteme
29
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Koexistenz von SQL- und NoSQL-Datenbanksystemen?
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
30
Koexistenz von SQL- und NoSQL-DBMS?
• Muss es immer eine entweder-oder-Auswahl sein?
 Auswahl des geeigneten Systems für die jeweilige Aufgabe
statt „One Size Fits All“?
– Beispiel: Amadeus Log Service
• Wöchentlich mehrere hundert Terabyte Log-Daten von verschiedenen
Servern einer SOA-Architektur
• Architektur (Prototyp, Kossmann:2012)
– Verteiltes Dateisystem (HDFS) für komprimierte Log-Daten
– NoSQL-System (HBase) zur Indexierung nach Timestamp und
SessionID
– Full Text Search Engine (SOLR) für Volltextsuche
– MapReduce-Framework (Hadoop) zur Analyse (Nutzerstatistiken
und Fehleranalyse)
– Relationales DBMS (Oracle) für Meta-Daten (Benutzer-Infos etc.)
• Zum Weiterlesen: Donald Kossmann: http://wp.sigmod.org/?p=559
Uta Störl
NoSQL-Datenbanksysteme
31
Koexistenz von SQL- und NoSQL-DBMS?
• Trend: MapReduce (Hadoop) Integration in relationale DBMS und
Data Warehouse Systeme
– 2012 erschienen
•
•
•
•
•
Oracle BigData-Appliance
Oracle NoSQL 2.0 (Key-Value-Store)
IBM Infosphere mit Hadoop-Support
Microsoft SQL Server 2012 mit Hadoop*-Support
…
– Oktober 2012
• Ankündigung der Integration von Hadoop (Cloudera-Distribution) in
SAPs BigData-Angebot (SAP HANA, SAP Sybase IQ, SAP Data Integrator,
SAP Business Objects)
*Microsoft: Einstellung des eigenen MapReduce-Frameworks Dryad
Uta Störl
NoSQL-Datenbanksysteme
32
Koexistenz von SQL- und NoSQL-DBMS?
• NewSQL-DBMS
– Idee: Das Beste aus beiden Welten vereinen
•
•
•
•
•
SQL
ACID
Nicht-sperrende Concurrency Control
Hohe per-node Performance
Scale out, shared nothing Architektur
– Erweiterungen bestehender Systeme
• MySQL Cluster
• (PostgreSQL: nativer JSON-Support und hstore (key-value) Datentyp)
– Entwicklung komplett neuer Systeme
• VoltDB (Michael Stonebraker)
• Drizzle
• …
Uta Störl
NoSQL-Datenbanksysteme
33
*SQL-Systeme: Klassifikation
Quelle: Matthew Aslett 451 Group
Uta Störl
NoSQL-Datenbanksysteme
34
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Koexistenz von SQL- und NoSQL-Datenbanksystemen?
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
35
NoSQL-Systeme: Zusammenfassung
• Vorteile
– Flexible und kostengünstige horizontale Skalierung (scale out)
– Verarbeitung riesiger Datenmengen mit kostengünstiger Software
– Hochgradig parallelisierbare Anfrageverarbeitung mit MapReduce
– Schemaflexibilität (falls benötigt)
• Nachteile
– Ggf. Abstriche bei Konsistenz
– Erhöhter Aufwand für Entwicklung
• Proprietäre, wenig mächtige APIs / „Anfragesprachen“
• OR-Mapper bislang nur rudimentär unterstützt
– Bisher kaum Tools für Performance-Analyse und DB-Administration
Uta Störl
NoSQL-Datenbanksysteme
36
NoSQL-Systeme: Zusammenfassung (Forts.)
• Entscheidung für oder gegen NoSQL-Systeme
– Datenanalyse
• Wie groß ist die erwartete Datenmenge?
• Komplexität der Daten und Schemaflexibilität?
• Art der Navigation zwischen den Daten?
Konsistenzanforderungen der Anwendungen?
Anfrageanforderungen der Anwendungen?
Performanceanforderungen (Latenz, Skalierbarkeit, Concurrency)?
Nicht-funktionale Anforderungen (Lizenz, Firmenpolitik, Sicherheit,
Dokumentation etc.)
– Kosten (inkl. Entwicklung und Administration!)
–
–
–
–
• Welches NoSQL-System?
– Prototyping!
– Performance-Analyse!
Uta Störl
NoSQL-Datenbanksysteme
37
Ausblick
• Wichtige offene Punkte
– Standardisierte Anfragesprache(n)
– Benchmarks
• Revolution oder Evolution? Thesen:
– „Kleine“ Revolution die zur Evolution der etablierten relationalen
Systeme führt
• Integration von MapReduce-Ansätzen in relationale DBMS
insbesondere DataWarehouse-Systeme
• (Noch) stärkere Entwicklung hin zu nicht-sperrenden Concurrency
Control Verfahren, um scale out zu ermöglichen
• Mittelfristig: Integration von „konfigurierbarer“ Konsistenz in
relationalen DBMS
– Nutzung von NoSQL-DBMS als „Applikationsdatenbank“ – nicht als
„Integrationsdatenbank“  Koexistenz
Uta Störl
NoSQL-Datenbanksysteme
38