Einführung - Abteilung Datenbanken Leipzig

NoSQL-Datenbanken
Kapitel 1: Einführung
Dr. Anika Groß
Sommersemester 2017
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/
• Schätzung von IBM
– Pro Tag werden 2,5 Exabytes an Daten generiert
– 90% aller Daten weltweit wurden in den letzten 2 Jahren erzeugt
Quelle (05 Feb 2013): http://www-03.ibm.com/press/de/de/pressrelease/40327.wss
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
• “Not only SQL”
• „Nicht relationale Ansätze“
• Verschiedene Anwendungen erfordern versch. Typen von 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
Rückblick - History ( … repeats itself )
• Early Database Management Systems
– Flat File Data Management Systems
•
•
•
•
Oft Daten zu einem Entity in einem record (meist ineffiziente Suche)
Datenduplizierung / Redundanz  Inkonsistenzen
Keine Implementierung von Zugriffsrechten
Keine Datenunabhängigkeit  Änderungen in Anwendungsprogrammen
– Hierarchical Data Management Systems
• Parent-child relationships (1:N), etwas weniger Redundanz
• Keine N:M Beziehungen
• Effizientere Suche
– Network Data Management Systems
•
•
•
•
Knoten und gerichtete Kanten ( N:M / mehrere parent records erlaubt), keine Zyklen
Schemas zur Definition der Knotentypen und Beziehungen
Schwieriges Design und Verwaltung
Retrieval: Programm muss ggf. hohe Anzahl an Kanten traversieren
 Nachteile adressiert von relationalen DBMS
1-8
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)
– Impedance 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-9
NoSQL Data Stores
* multi-model
Key-Value Stores (Kap.2)
• Kollektion von Key/Value-Paaren: 1 Wert (z.B. BLOB) je Schlüssel
• Zugriff über Schlüssel: get(key), put(key, value)
*
Document Stores (Kap.3)
• Speicherung semistrukturierter Daten als Dokument (z.B. JSON)
• Zugriff über Schlüssel oder einfache Anfragesprache
Wide Column Stores / Record Stores (Kap.5)
• Tables with records with (many) dynamic columns
• Zugriff über Schlüssel oder SQL-ähnliche Anfragesprache
Graph Databases (Kap.6)
*
• Repräsentation der Daten als Knoten und Kanten mit Properties
• Datenbankabfragen inkl. Graphalgorithmen
+ Skalierbare Relationale Datenbanken (Kap. 5)
MySQL Cluster, MegaStore, VoltDB, Clustrix, ScaleDB, ScaleBase, NimbusDB, ...
NoSQL – Data Stores for Big Data
10
Größe vs. Komplexität
Key-Value
Stores
data size
Column
Stores
Document
Databases
Graph
Databases
90 % of use cases
data complexity
1-11
NoSQL Datenmodelle
https://highlyscalable.files.wordpress.com/2012/02/overview2.png
1-12
DB Engines Ranking (Ausschnitt)
http://db-engines.com/en/ranking
NoSQL
– Data Stores for Big Data
13
Inhaltsverzeichnis
• NoSQL-Datenbanken
– Definition und Motivation
– Kategorisierung, Eigenschaften
• CAP-Theorem
– ACID-Eigenschaften
– BASE-Ansatz
1-14
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, ...
• Trade-off: Performanz vs. Datenkonsistenz
– Warten bis alle (relevanten) Knoten synchronisiert sind
– Vermeidung (oder Auflösung) von Mischkonflikten
1-15
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/Clients
sehen zur selben Zeit die selben Daten
•
Consistency
Availability
Partition
Tolerance
Availability (Verfügbarkeit)
– Jede Lese/Schreib-Anfrage an einen “non-failing” Knoten wird beantwortet, d.h. alle Clients
können stets lesen und schreiben.
– Knotenausfälle beeinflussen nicht die Verfügbarkeit “lebender” Knoten
•
Partitioning tolerance (Partitionstoleranz)
– System funktioniert bei Netzwerkpartitionierung trotz Verlust von Nachrichten
zwischen Knoten weiter
– Netzwerk-Partitionierung = Knoten aus einer Partition können nicht mehr mit Knoten aus
anderer Partition kommunizieren
Theorem: Ein verteiltes System kann maximal 2 der 3 Eigenschaften gleichzeitig erfüllen.
1-16
CAP Theorem - Fälle
(CA)
Consistency
MongoDB
BigTable
HBase
CP
CP • Konsistent aber nicht verfügbar bei
Netzwerkpartitionierung
• Transaktionen werden blockiert
• Vermeidung möglicher Konflikte bei
Merge zur Sicherstellung der Konsistenz
Availability
AP • Verfügbar aber nicht konsistent bei
Netzwerkpartitionierung
Partition
Tolerance
AP Dynamo/S3
Cassandra
• Writes stets möglich auch wenn keine Kommunikation mit
anderen Knoten möglich (z.B. Synchronisation)
• Notwendigkeit der Konfliktauflösung für inkonsistente Daten
(verschiedene Versionen des selben Datums an verschiedenen Knoten)
Kontroverse:
“2 of 3” irreführend, „CA“ gibt es nicht (CAP gilt für verteilte Systemen):
CAP Twelve Years Later: How the "Rules" Have Changed
Klassifikation der Systeme teilweise schwierig!
Please stop calling databases CP or AP
NoSQL – Data Stores for Big Data
Source: Misconceptions about
the CAP Theorem
17
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-18
BASE
• BA - Basically Available
– Partieller Ausfall einiger Teile des verteilten Systems  Rest läuft weiter
• Ohne Replikation: Bsp. 1 von 10 Servern fällt aus  10 % der Queries schlagen fehl
• NoSQL DBs mit Replikation (replication level=3, 1 Knotenausfall):
Queries können noch beantwortet werden
• S - Soft State
– Daten werden letztlich mit aktuelleren Daten überschrieben
– Überlappung mit E
• E - Eventually Consistent
– DB kann in inkonsistenten Zustand kommen
– Mehrere Kopien (Replika) der Daten auf versch. Servern können für
kurzen Zeitraum inkonsistent sein
• z.B. Nutzer aktualisiert Daten in einer Kopie, aber andere Kopie behält alten Stand
– Letztendlich aktualisiert der Replikationsmechanismus der NoSQL DB alle Replika
– Verschiedene Typen: casual consistency, read-your-writes consistency,
monotonic read consistency, monotonic write consistency, ..
1-19
Konsistenzmodelle
• Strong Consistency
update(x,v2)
r(x)=v1
r(x)=v2
r(x)=v2
r(x)=v2
t
• Eventual Consistency
update(x,v2)
r(x)=v1
r(x)=v2
r(x)=v1
r(x)=v1
r(x)=v2
r(x)=v1
t
inconsistency window
1-20
Konsistenzmodelle
• Read-your-writes Consistency
update(x,v2)
r(x)=v1
r(x)=v2
r(x)=v1
r(x)=v2
r(x)=v1
t
• Monotonic Read Consistency
update(x,v2)
r(x)=v1
r(x)=v2
r(x)=v1
r(x)=v2
r(x)=v2
r(x)=v1
t
1-21
ACID vs. BASE [Bre00]
• Aufgeben der (strengen) Konsistenz und des logischen
Einbenutzerbetriebs für Verfügbarkeit und Performanz
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-22
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-23
Inhaltsverzeichnis (vorläufig)
1.
Einführung
• NoSQL-Datenbanken
• CAP-Theorem
2.
Key-Value Stores
• Dynamo/Amazon S3
• Redis
• Microsoft Azure Storage
3.
Document Stores
•
CouchDB
•
MongoDB
4.
Search Engines
• Lucene
• Apache Solr
• ElasticSearch
1-24
5.
Record Stores & RDBMS 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-25