NoSQL-Datenbanken - Abteilung Datenbanken Leipzig

NoSQL-Datenbanken
Kapitel 1: Einführung
Lars Kolb
Sommersemester 2014
Universität Leipzig
http://dbs.uni-leipzig.de
1-1
Inhaltsverzeichnis
• NoSQL-Datenbanken
– Motivation und Definition
– Kategorisierung, Eigenschaften
• CAP-Theorem
– ACID-Eigenschaften
– BASE-Ansatz
1-2
Massives Datenwachstum
Quelle: http://hortonworks.com/blog/7-key-drivers-for-the-big-data-market/
• IBM (2012)
– Pro Tag werden 2,5 Exabytes an Daten generiert
– 90% aller Daten weltweit wurden in den letzten 2 Jahren erzeugt
1-3
Datenproduzenten
Quelle: Einführungsveranstaltung Seminar “New Trends in Big Data” WS 2013/14
1-4
Big Data Challenges
Quelle: http://kavyamuthanna.wordpress.com/category/big-data/
1-5
Parallele DBS?
• Anforderung: Effiziente Verarbeitung großer Datenmengen…
–
–
–
–
in einer preiswerten, verteilten (heterogenen) Infrastruktur
mit konkurrierenden Schreib- und Lesezugriffen
unter Berücksichtigung von Knoten- bzw. Netzwerkausfällen
für beliebige Daten (unstrukturiert, semi-strukturiert, strukturiert)
• Parallele Datenbanksysteme ungeeignet ...
–
–
–
–
teure, homogene Infrastruktur
geringe Fehlertoleranz (z.B. Query-Restart)
nur für strukturierte Daten (statisches Schema)
begrenzte Skalierbarkeit (ca. 100 Knoten)
• ... dafür
– mächtige, einfache Anfragesprache
– ACID-Eigenschaften
– Datenunabhängigkeit
1-6
NoSQL-Datenbanken
• Keine standardisierte Definition
• Datenbanksystem, das eines oder mehrere der folgenden Kriterien
aufweist
– Kein relationales Datenmodell
• Schemafrei oder schwache Schemarestriktionen
• Keine Joins / keine Normalisierung
– Verteiltes, auf horizontale Skalierbarkeit ausgelegtes System
• “Commodity Hardware”
– “Kein SQL”
• Zugriff mit einfacher API statt SQL
– “Keine Transaktionen”
• Konsistenzmodell BASE statt ACID
1-7
Motivation NoSQL-Datenbanken
• Relationales Schema zu starr für viele Webanwendungen
– Evolution: Änderung der Webanwendung führt meist zu Schemaänderung
– Datenstruktur: Heterogene Informationsarten führen zu großen, unübersichtlichen
Schemas (u.a. einfache mengenwertige Attribute z.B. Tags)
– Impedence Mismatch
– Anfrage: Wartbarkeit komplexer SQL-Anfragen (viele Joins)
• Vorteile relationaler Modellierung spielen geringere Rolle
– Data Store meist nur für eine Anwendung, daher Datenunabhängigkeit kein Ziel
– Effiziente SQL-Ausführung (Optimierung) durch komplexe Anfragen begrenzt
• Fokus: Performanz und Verfügbarkeit
– begrenzte Skalierbarkeit paralleler Datenbanksysteme
– geringe Fehlertoleranz (z.B. Query-Restart)
1-8
Kategorisierung von NoSQL-Datenbanken
• Key-Value Stores ( Kapitel 2)
http://cattell.net/datastores/Datastores.pdf
– Amazon Dynamo, MemCacheDB, Voldemort, Riak, Redis, Scalaris, ...
– Speicherung eines Werts (z.B. BLOB) pro nutzer-definiertem Schlüssel
– Zugriff über Schlüssel, d.h. put (key, value) und get (key) -Methode
• Document Stores ( Kapitel 3)
– SimpleDB, CouchDB, MongoDB, Terrastore, ...
– Speicherung semistrukturierter Daten als Dokument (z.B. JSON)
– Zugriff über Schlüssel oder einfache Anfragesprache
• Extensible Record Stores (Wide-column stores) ( Kapitel 5)
– BigTable / HBase, HyperTable, Cassandra, ...
– Tabellen-basierte Speicherung mit flexibler Erweiterung um neue Attribute
– Zugriff über Schlüssel oder SQL-ähnliche Anfragesprache
• Scalable Relational Databases ( Kapitel 5)
– MySQL Cluster, MegaStore, VoltDB, Clustrix, ScaleDB, ScaleBase, NimbusDB, ...
1-9
Inhaltsverzeichnis
• NoSQL-Datenbanken
– Definition und Motivation
– Kategorisierung, Eigenschaften
• CAP-Theorem
– ACID-Eigenschaften
– BASE-Ansatz
1-10
Performantes, verteiltes Datenmanagement
• Annahmen („Irrtümer“) der verteilten Datenverarbeitung
– Das Netzwerk ist ausfallsicher, sicher und homogen
– Die Latenzzeit ist gleich Null, der Datendurchsatz unendlich und die Kosten des
Datentransports können mit Null angesetzt werden
– Die Netzwerktopologie ist unveränderlich
http://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
• Verteilte Datenverarbeitung erfordert Kommunikation zwischen Knoten
– u.a. Synchronisation und Replikation
– robust gegen Knotenausfälle, Nachrichtenverlust, ...
• Tradeoff: Performanz vs. Datenkonsistenz
– Warten bis alle (relevanten) Knoten synchronisiert sind
– Vermeidung (oder Auflösung) von Mischkonflikten
1-11
CAP-Theorem [Bre00] [GL02]
• CAP = Consistency, Availability, Partitioning Tolerance
• Consistency (Konsistenz)
– System funktioniert entweder “voll” oder “gar nicht” ( ACID-Atomarität)
– Alternativ: Updates werden bei allen relevanten Knoten zur gleichen “logischen” Zeit
durchgeführt, d.h. alle Knoten sehen zur selben Zeit die selben Daten.
• Availability (Verfügbarkeit)
– Jede Lese/Schreib-Anfrage an einen “non-failing” Knoten wird beantwortet
– Knotenausfälle beeinflussen nicht die Verfügbarkeit “lebender” Knoten
• Partioning tolerance (Partitionstoleranz)
– System funktioniert trotz Verlust von Nachrichten zwischen Knoten
– Netzwerk-Partitionierung = Knoten aus einer Partition können nicht mehr mit Knoten
aus anderer Partition kommunizieren
• Theorem: Ein verteiltes System kann maximal zwei der drei Eigenschaften
gleichzeitig erfüllen.
1-12
CAP-Fälle
• CA – keine Partitionstoleranz
– (Relationale) Datenbank ermöglicht verteilte Transaktionen zur Konsistenzwahrung
– Voraussetzung: funktionierendes Netzwerk (kein Nachrichtenverlust)
• CP – keine Verfügbarkeit
– im Falle von Netzwerkpartitionierung werden Transaktionen blockiert
– Vermeidung möglicher Konflikte bei Merge, dadurch Sicherstellung der Konsistenz
• AP – keine Konsistenz
– Writes stets möglich auch wenn keine Kommunikation mit anderen Knoten möglich
(z.B. Synchronisation)
– Notwendigkeit der Auflösung inkonsistenter Daten, d.h. verschiedene Versionen des
selben Datums an verschiedenen Knoten
1-13
CAP-Theorem und Data Stores
Availability (Verfügbarkeit):
Alle Clients können stets lesen
und schreiben.
nach: Nathas Hurst’s Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
A
Dynamo/S3 (KV)
CouchDB (Document)
Cassandra (Record)
Parallele
DBMS
Consistency
(Konistenz): Alle
Clients haben stets die
gleiche Sicht auf die
Daten.
C
Verteilte Datenbanken
Azure Storage (KV)
MongoDB (Document)
BigTable/HBase (Record)
1-14
P
Partition Tolerance
(Partitionstoleranz): Das
System funktioniert trotz
Netzwerk-Partitionierung
weiter.
ACID
• RDBMS gewährleistet für Transaktionen ACID-Eigenschaften.
• Atomicity
– ’Alles oder Nichts’-Eigenschaft (Fehlerisolierung)
• Consistency
– eine erfolgreiche Transaktion erhält die DB-Konsistenz (Gewährleistung der
definierten Integritätsbedingungen)
• Isolation
– alle Aktionen innerhalb einer Transaktion müssen vor parallel ablaufenden
Transaktionen verborgen werden („logischer Einbenutzerbetrieb“)
• Durability
– Überleben von Änderungen erfolgreich beendeter Transaktionen trotz beliebiger
(erwarteter) Fehler garantieren (Persistenz)
DBS1 VL Prof. Rahm, Uni Leipzig
1-15
ACID vs. BASE [Bre00]
• Aufgabe (strenger) Konsistenz und logischem Einbenutzerbetrieb für
Verfügbarkeit und Performanz
• BASE = Basically Available, soft-state, eventual consistency
ACID
BASE
Konsistenz
streng (stets aktuelle Daten pro
Knoten)
Verfügbarkeit
eingeschränkt (z.B. bei Ausfall
des Koordinatorknotens bei 2PC)
Prinzip
• pessimistisch / konservativ
• Anwendung kann sich auf
“Datenqualität” verlassen
Priorität
Transaktionen im logischen
Einbenutzerbetrieb
Evolution
aufwändig (Schema)
1-16
Inhalt der Vorlesung
• Techniken zum effizienten Management großer un-/semi-strukturierter
Datenmengen
• Verteilte Architekturen zum
– Storage (Speicherung)
– Retrieval/Querying (Anfrageverarbeitung)
• Algorithmen zur
– Synchronisation (z.B. für Replikation)
– Realisierung von Transaktionen
1-17
Inhaltsverzeichnis (vorläufig)
1.
Einführung
• NoSQL-Datenbanken
• CAP-Theorem
2.
Key-Value Stores
• Microsoft Azure Storage
• Amaszon S3/Dynamo
3.
Document Stores
•
CouchDB
•
MongoDB
4.
Skalierbare Webanwendungen
•
Design-Prinzipien
•
Google App Engine
1-18
5.
Record Stores & RDMS in der Cloud
•
BigTable/HBase, Cassandra
•
Megastore
•
H-Store/VoltDB
•
Synchronisation
•
Transaktionen
6.
Graphdatenmanagement
•
Graphmodell & -algorithmen
•
Graphdatenbanken
•
Parallele Graph-Algorithmen
Literatur
• [Bre00] Brewer. Towards robust distributed systems. Proceedings of the
Annual ACM Symposium on Principles of Distributed Computing (2000)
http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
• [GL02] Gilbert and Lynch. Brewer's conjecture and the feasibility of
consistent, available, partition-tolerant web services. ACM SIGACT News
(2002)
1-19