NoSQL-Datenbanksysteme

NoSQL-Datenbanksysteme
Hochschule Harz
14.06.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
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
3
Motivation: Big Data
• Big Data
– Log Analytics (Web Logs, Sensor Logs, Event Logs etc.)
– RFID Tracking and Analytics
– Social Network Daten (LinkedIn, Facebook, Twitter etc.)
– Social Networking Feeds (Facebook oder Twitter Feeds von
Firmenseiten)
– Gaming Data
– Streaming Data
– …
• Volumes of Data
– Eric Schmidt (Google CEO, 2010): “… 5 exabytes of information
created between the dawn of civilization through 2003 now created
every 2 days, and the pace is increasing.”
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 Datenbanksysteme
• 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 Datenbanksysteme
• 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, Couchbase …
Uta Störl
NoSQL-Datenbanksysteme
11
Column Family Datenbanksysteme
Row Key: title
"NoSQL"
Time Stamp
t5
Column Family text
Column Family revision
"content": "…"
"author": "Mendel"
"comment": "changed view … "
t4
"Redis"
"author": "Torben"
"comment": “there should be …"
t3
"content": "…"
"author": "Torben"
"comment": "initial …"
• Storage Layout
Row Key: title
Time Stamp
Column Family text
column: content
NoSQL
t5
A NoSQL database provides a mechanism …
Redis
t3
Redis is an open-source, networked …
Row Key: title
Time Stamp
ColumnFamily revision
column: author
column: comment
NoSQL
t5
Mendel
changed view …
NoSQL
t4
Torben
there should be
Redis
t3
Torben
initial …
• Systeme: Google BigTable, HBase, Cassandra …
Uta Störl
NoSQL-Datenbanksysteme
12
NoSQL Datenbanksysteme: Use Cases
Key-Value Database
Systems
Document Store
Database Systems
Column Family
Database Systems
Suitable Use Cases • Storing Session
Information
• User Profiles,
Preferences
• Shopping Cart
Data
• Event Logging
• Content
Management
Systems
• Blogging Platforms
• Web Analytics or
Real-Time Analytics
• Event Logging
• Content
Management Systems
• Blogging Platforms
• Counters
Examples
• Forbes (CMS)
• MTV (CMS)
•…
• Google (web pages)
• Facebook
(messaging)
• Twitter (places of
interest)
•…
Uta Störl
• Amazon (shopping
carts)
• Temetra (meter
data)
•…
NoSQL-Datenbanksysteme
13
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
14
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
15
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
16
Consistency bei Scale out?
Problem mit Konsistenz (Consistency) bei
• Replikation und verteilten Transaktionen – warum?
 CAP-Theorem (Brewer, 2000) 
 Besser: PACELC (Abadi, 2012)
– if there is a partition (P), how does the system trade off availability and
consistency (A and C);
– else (E), when the system is running normally in the absence of partitions,
how does the system trade off latency (L) and consistency (C)?
• PA/EL
– Default versions of Amazon Dynamo, Cassandra, Riak
– However, R + W > N  more consistency
• PC/EC
– HBase, BigTable
• PA/EC
– MongoDB
Uta Störl
NoSQL-Datenbanksysteme
17
Eventual Consistency
• 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
18
Eventual Consistency: Implementierung
• 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
19
Eventual Consistency am Beispiel Cassandra
• Write Consistency Level
– Zero: Asynchrones Schreiben im Hintergrund
– One/Two/Three: Stellt sicher, dass die Schreiboperation an
mindestens einem/zwei/drei 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/Two/Three: Rückgabewert des ersten/zwei/drei
antwortenden Knoten (ggf. inkonsistent)
– Quorum: Wenn eine Mehrheit der Knoten (N/2 + 1) 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
20
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
21
Anwendungsentwicklung mit NoSQL-DBMS
• Einfache APIs mit einfachsten 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"}‚
• Teilweise auch (rudimentäre) Anfragesprachen
• Language Bindings
– Java, Ruby, C#, Python, Erlang, PHP, Perl,
– REST
– Thrift
Uta Störl
NoSQL-Datenbanksysteme
22
Anwendungsentwicklung mit NoSQL-DBMS
• Herausforderung
– Daten verteilt über hunderte Knoten (zur Erinnerung: scale out)
– Data-to-Code oder Code-to-Data?
 Parallele Verarbeitung sehr großer Datenmenge erfordert neue
Algorithmen und Frameworks
 MapReduce
– (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)
• 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
23
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
24
MapReduce: Architektur und Phasen
Source: https://developers.google.com/appengine/docs/python/dataprocessing/overview
Uta Störl
NoSQL-Datenbanksysteme
25
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
26
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
27
MapReduce Frameworks
• MapReduce Frameworks kümmern sich um
– Skalierung
– Fehlertoleranz
– (Load balancing)
• MapReduce Frameworks
– Google
– Apache Hadoop: standalone oder integriert in NoSQL (und SQL)
DBMS
– Proprietäre MapReduce Frameworks integriertin NoSQL DBMS
Uta Störl
NoSQL-Datenbanksysteme
28
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
29
Performance und Benchmarks
• Was „kostet“ Scale out?
– Flexibilität führt zu Storage-Overhead
– Verteilungsarchitektur impliziert per se Overhead
 Beobachtung in der Praxis: Die Daten- und Knotenmenge muss groß genug
sein, damit ein wirklicher Performance-Vorteil zum Tragen kommt
• Klassische DB-Benchmarks
– Benchmarks für typische Szenarien (OLTP: TPC-*, SAP-Benchmarks)
– Metriken:
• Performance (transactions per minute)
• Preis/Performance
• 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)
Uta Störl
NoSQL-Datenbanksysteme
30
Performance und Benchmarks
• NoSQL-Benchmarks: State of the art
– Diverse Untersuchungen für ganz spezifische Anwendungen und Vergleich
von System x mit System y
– Bisher kaum generalisierende Benchmarks
• Beispiel: Yahoo! Cloud Serving Benchmark (SoCC 2010)
– eine Tabelle mit Records; verschiedene Datenverteilungen
– einfache Operationen: Lesen, Einfügen, Löschen von Records, Range Scans
– Metriken:
• Performance: Latenzzeit bei wachsendem Workload (bei konstanter
Hardware)
• Skalierung
– Scaleup: Performanz-Veränderung bei proportional wachsender
Datenmenge, Serveranzahl und Workload
– Elastic Speedup: Performanz-Veränderung beim Hinzufügen von
Servern im laufenden Betrieb
Uta Störl
NoSQL-Datenbanksysteme
31
Yahoo! Cloud Serving Benchmark
• Beispiel 1 (aus einer Vielzahl von Messungen)
– Scaleup-Verhalten (Performanz-Veränderung bei proportional
wachsender Datenmenge, Serveranzahl und Workload)
Quelle: Cooper et al. Benchmarking Cloud Serving Systems with YCSB; SoCC 2010
Uta Störl
NoSQL-Datenbanksysteme
32
Yahoo! Cloud Serving Benchmark
• Beispiel 2
– Latenzzeit bei wachsendem Workload (bei konstanter Hardware)
– Range Scan: Scans von 1-100 Records (Größe 1KB)
• ACHTUNG: Zahlen von 2010 (= alt im NoSQL-Alter) und nur für
spezifische Workloads!
Quelle: Cooper et al. Benchmarking Cloud Serving Systems with YCSB; SoCC 2010
Uta Störl
NoSQL-Datenbanksysteme
33
Agenda
• Motivation
• NoSQL – Grundlagen
• Anwendungsentwicklung mit NoSQL-DBMS
• Performance und Benchmarks
• Zusammenfassung und Ausblick
Uta Störl
NoSQL-Datenbanksysteme
34
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
35
NoSQL-Systeme: Zusammenfassung
• 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
36
Ausblick
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
37
Ausblick
• 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)
– April 2013
• Announcement of Hadoop Integration in Teradata with SQL-H-API (instead
of writing Map-Reduce jobs)
– …
*Microsoft: Einstellung des eigenen MapReduce-Frameworks Dryad
Uta Störl
NoSQL-Datenbanksysteme
38
*SQL-Systeme: Klassifikation
Quelle: Matthew Aslett 451 Group
Uta Störl
NoSQL-Datenbanksysteme
39