DATENBANKSYSTEME NOSQL - VSIS
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Kapitel 4 – Teil 2
NoSQL-Datenbanksysteme
Inhalt:
CAP (Consistency/Availability/Partition-Tolerance);
BASE (Basically Available, Soft State, Eventually Consistent);
Datenmodelle: Key-Value-Stores, Spaltenbasierte DBS,
Dokumentenorientierte DBSMotivation (1)
Heutige Systeme arbeiten im Bereich der Web-Anwendungen
mit sehr hohen Datenmengen
• Datenverwaltung im Peta-Byte-Bereich bei Facebook, Amazon oder auch Ebay
• Anforderung an die Web-Systeme
- Skalierbares Design
- Schnelle Updates von Daten
- Aufrechterhalten eines hohen Datendurchsatzes
(vor allem während Änderungen im Datenbestand erfolgen)
- Hardware: Eher Massenware (viele) statt monolithische Mainframes
- Elastizität
- Skalieren mit der Last Æ Maschinen je nach Last dazu oder abschalten
- Hohe Verfügbarkeit - Downtime bedeutet Umsatzverlust
- Replikation von Daten (mit Multi-Mastering)
- Geographische Replikation
- Automatisierte Fehler-Recovery
Ritter, DIS, SS 2012, Kapitel 4 2Motivation (2)
Klassische (zentralisierte) Datenbanksysteme nicht ausreichend um diese
Datenmengen effizient zu verwalten
Verteilte Datenbanksysteme mit ACID-Eigenschaften skalieren besser als
klassische Systeme, allerdings für hochverfügbare Systeme einige Nachteile:
• Commit-Protokolle
- Nachrichtenaufkommen
- 2PC kann blockieren und damit die Verfügbarkeit des Systems einschränken.
- 3PC löst das Blockierungsproblem; allerdings nur bei nicht vorhandenen Netzwerkpartitionen.
• Serialisierbarkeit
- Bei homogene Föderationen (ohne Replikation) sichert SS2PL auf allen Sites
globale Serialisierbarkeit zu.
- Inhärentes Problem von Sperrverfahren: Deadlocks (und verteilte Deadlock-Erkennung).
Cloud?
Ritter, DIS, SS 2012, Kapitel 4 3Das CAP-Theorem (1)
Dient zur Klassifikation von verschiedenen
verteilten Datenbanksystemen
Für verteilte Datenbanken sind maximal zwei
der drei Eigenschaften erreichbar:
• Konsistenz: Nach Abschluss einer Transaktion
ist der Datenbestand in einem verteilten
Datenbanksystem konsistent.
• Verfügbarkeit: Ein verteiltes Datenbanksystem
muss akzeptable Reaktionszeiten liefern.
• Ausfalltoleranz: Ein Ausfall eines Knotens in
einem verteilten Datenbanksystem darf nicht
zum Ausfall des Gesamtsystems führen.
Eric Brewer, ACM-PODC Keynote, Juli 2000
Gilbert, Lynch: Brewer's Conjecture and the Feasibility of
Consistent, Available, Partition-Tolerant Web Services, SigAct News 2002
Ritter, DIS, SS 2012, Kapitel 4 4Das CAP-Theorem (2)
Konsistenz (C - Consistency)
• Hier: Replikationskonsistenz
- Es ist gibt einen eindeutigen, sichtbaren Systemzustand: Alle Clients sehen bei zeitgleichen
Zugriffen knotenunabhängig die selbe Version eines Datenobjektes.
- Voraussetzung: Es muss aus globaler Sicht eine totale Ordnung < auf allen Operationen im
System existieren, die einen Datensatz (auch wenn er auf verschiedene Knoten repliziert ist)
von einem initialen Zustand in einen neuen Zustand überführt.
- Beispiel: w1(x) < r2(x) (für alle Knoten gültig)
W[Value] ÆV1
R[Value] ÆV1
Replikation
Ritter, DIS, SS 2012, Kapitel 4 5Das CAP-Theorem (3)
Verfügbarkeit (A - Availability)
• Jede Anfrage an ein verteiltes Datenbanksystem muss ein Resultat
zurückgeben (in akzeptabler Zeit).
• Bzw: Jeder Client kann immer lesen und schreiben.
• Voraussetzung:
- Jeder Algorithmus des Systems terminiert in endlicher Zeit.
Ausfalltoleranz (P - Partition Tolerance)
• Kein Fehler (außer dem totalen Netzausfall) darf das verteilte System
fehlerhaft antworten lassen.
• P qualifiziert die Attribute C und A:
1. Ein System mit C und P ist auch bei willkürlichen Nachrichtenverlusten
konsistent.
2. Ein System mit A und P ist auch bei willkürlichen Nachrichtenverlusten
verfügbar.
Ritter, DIS, SS 2012, Kapitel 4 6Das CAP-Theorem (4)
Für (verteilte) Datenbanksysteme sind maximal zwei
der drei Eigenschaften (A, P, C) erreichbar
Beweis-Idee
• Annahme: Es gibt System mit allen drei Eigenschaften C, A und P
• Ausgangssituation: Schreiben
Lesen
Ritter, DIS, SS 2012, Kapitel 4 7Das CAP-Theorem (5)
Beweis-Idee (Forts.)
• Fall 1 – Synchronisation im fehlerfreien Fall:
W[Value] ÆV1
R[Value] ÆV1
Replikation
Ritter, DIS, SS 2012, Kapitel 4 8Das CAP-Theorem (6)
Beweis-Idee (Forts.)
• Fall 2 – Partition
- Auftreten einer Netzwerkpartition zwischen den Knoten K1 und K2:
Veralteter Wert:
W[Value] ÆV1
R[Value] ÆV0
Inkonsistenz
Replikation
- Auf Grund der Verfügbarkeitsbedingung muss der Schreibvorgang genauso wie der Lesevorgang
auch bei bestehender Netzwerkpartition terminieren.
- Da die Replikation nicht erfolgen kann, liest Lesevorgang aber einen alten Wert.
Die Konsistenzbedingung ist damit verletzt!
Ritter, DIS, SS 2012, Kapitel 4 9Das CAP-Theorem (7)
Beweis-Idee (Forts.)
• Konsequenz
1. Keine Verfügbarkeit ohne Verlust der Konsistenz
2. Keine Konsistenz ohne Verlust der Verfügbarkeit
Antwort blockieren Antwort ohne
bis ACK eingetroffen Replikation
Æ Konsistenz Æ Verfügbarkeit
Replikation
Ritter, DIS, SS 2012, Kapitel 4 10Das CAP-Theorem (8)
Beweis-Idee (Forts.)
• CAP-Theorem impliziert: Jede der Zweierkombinationen CP, AC
und AP kann in einem verteilten System erreicht werden.
Beispiel für CA: Zentralisiertes DBS
Beispiel für CP:
Verteiltes DB-System mit
2-Phasen-Commit-Protokoll
CP CA
AP AP: vgl. Folie 9; AP notwendig
für hochverfügbare, horizontal
skalierbare Systeme;
Relaxierung des
Konsistenzbegriffs, s.u.
Ritter, DIS, SS 2012, Kapitel 4 11BASE (1) (Basically Available, Soft State, Eventually Consistent) Bei ACID vor allen Dingen Fokus auf die konsistente Sicht auf die Daten • Nach dem CAP-Theorem also Fokus auf das C • Durch Sperr- und Commit-Protokolle wird zugesichert, dass nach jeder Transaktion die Sicht auf den Datenbestand konsistent ist. Bei BASE steht die Verfügbarkeit im Vordergrund • Nach CAP: Wenn Verfügbarkeit und Ausfalltoleranz fokussiert werden, wird die Konsistenz eingeschränkt. • Konsistenz als Übergangsprozess und kein fester Zustand nach Beendigung einer Transaktion: Der Zustand der Konsistenz wird „irgendwann“ erreicht (Eventually Consistent). Abgeschwächte Konsistenzbedingungen lassen bei AP- Systemen inkonsistente Sicht auf Daten zu! Ritter, DIS, SS 2012, Kapitel 4 12
BASE (2)
Konsistenzklasse Read-your-Writes
• Ein Client, der selbst einen Datensatz geändert hat, wird später keine ältere Version lesen
können als die von ihm geänderte Version des Objektes.
Read-Your-Writes
Consistency
Wenn Wc1[x,v0] vor Rc1,k1[x,v1]
- Spezialfall Session Consistency: Im Rahmen einer Session wird Read-your-Writes
garantiert, in dem beispielsweise innerhalb einer Session nur mit einem Knoten
kommuniziert werden kann, der dann die Daten erst lokal speichert und dann im
Hintergrund an andere Knoten repliziert.
wC[x,1] wC [x,1]
K1 K1
A wC [x,1] w[x,2] rC[x,2]
B w[x,0] rC[x,0] wC [x,1]
K2 K2
Ritter, DIS, SS 2012, Kapitel 4 13BASE (3)
Klasse Monotonic-Read
• Garantiert monoton ansteigende Versionen von Objekten bei
Lesezugriffen eines Clients.
Montonic-Read Consistency
w[x,1] rC[x,1] w[x,1] rC[x,1]
K1 K1
A w[x,1] w[x,2] rC[x,2]
B w[x,0] rC[x,0] w[x,1]
K2 K2
Ritter, DIS, SS 2012, Kapitel 4 14BASE (4)
Klasse Monotonic-Write
• Die Schreibzugriffe eines Clients werden vom System serialisiert ausgeführt.
Monotonic-Write Consistency
• Eine Schreiboperation eines Clients auf x wird immer erst auf allen Knoten
abgeschlossen, bevor eine weitere Schreiboperation des gleichen Clients erfolgt.
wC [x,1] wC [x,1]
K1 K1
A wC [x,1] wC[x,2]
B wC[x,2]
K2 K2
Ritter, DIS, SS 2012, Kapitel 4 15BASE (5)
Kausale Konsistenz (Writes Follow Reads)
• Garantiert die Kausalität eines Lesevorgangs für einen folgenden Schreibzugriff.
Causal Consistency
• Die Schreiboperation, die für den Lesevorgang ursächlich ist, muss auf allen Knoten
abgeschlossen sein, damit der neue Wert geschrieben werden kann.
w [x,1] rC [x,1] w[x,1] rC [x,1]
K1 K1
A w [x,1] wC[y,2]
B wC[y,2] w [x,1]
K2 K2
Ritter, DIS, SS 2012, Kapitel 4 16BASE (6)
Starke Konsistenz
• Entspricht dem Konsistenzbegriff des CAP-Theorems
- Starke Konsistenz verlangt, dass ein Client stets den aktuellsten Wert
eines Datenobjektes erhält, unabhängig von welchem Knoten der
Datenzugriff erfolgt.
Strong Consistency
- Bevor also ein Wert gelesen werden kann, muss sichergestellt werden,
das er nach einem Schreibvorgang an alle Knoten repliziert ist.
- Nicht verträglich mit einem AP-System (weil nicht verfügbar).
Ritter, DIS, SS 2012, Kapitel 4 17BASE (7)
Fragen:
• Wie bestimmt man ob eine Version älter oder jünger ist als eine
andere?
- Zentral verwaltete Versionsnummern, die streng monoton
wachsen (Flaschenhals)
- Dezentral Lamport: Time, Clocks, and the Ordering of
Events in a Distributed System, Comm. of
beispielsweise durch Vektor-Clocks the ACM, July 1978, Vol. 21, No. 7
• Wie können die Konsistenzklassen Read-your-Writes, Monotonic-
Read, Monotonic-Write sowie Writes Follow Reads erreicht
werden?
- Verschiedene Konsistenzprotokolle möglich; bei NoSQL-
Datenbanken häufig Quorum-basierte Protokolle genutzt.
Ritter, DIS, SS 2012, Kapitel 4 18Konsistenzprotokolle (1)
Quorum-basierte Protokolle
• Idee: Clients müssen Erlaubnis von mehreren Servern anfordern und
erhalten, bevor sie ein repliziertes Datenelement lesen oder schreiben
• Vorgehen
- Eine Datei wird immer über N Server repliziert. Für eine
Aktualisierung muss mehr als die Hälfte (N/2+1) der Replikatknoten
zustimmen; dann wird geändert und eine Versionsnummer
zugewiesen.
- Um eine replizierte Datei zu lesen, muss ein Client Kontakt zu mehr
als der Hälfte der Server aufnehmen und sie nach ihren
Versionsnummern fragen. Der Client wird die Version mit der
höchsten Versionsnummer nehmen.
- Beispiel: 5 Server, Client stellt fest: 3 Server haben Version 8. Dann
ist ausgeschlossen, dass die beiden anderen Version 9 haben, da für
eine Aktualisierung auf Version 9 mindestens 3 Server zustimmen
müssen.
Ritter, DIS, SS 2012, Kapitel 4 19Konsistenzprotokolle (2)
Quorum-basierte Protokolle (Forts.)
• Gifford-Schema für N Repliken (für N < S Server)
- zum Lesen: ≥ NR Server
- zum Schreiben: ≥ NW müssen zustimmen, wobei
1. N R + NW > N (Keine Lese/Schreib-Konflikte, immer aktuellste Version genutzt)
2. NW > N/2 (Keine Schreib/Schreib-Konflikte)
Lese-Quorum
A B C D A B C D
E F G H E F G H
I J K L I J K L
S = 12, NR = 3, NW = 10 Schreib-Quorum S = 12, NR = 7, NW = 6
A) Das letzte Schreib-Quorum bestand aus 10 Servern von C-L B) Es kann zu Schreib-Schreib-Konflikten kommen, wenn ein Client
Zum Lesen: Lesequorum enthält mind. einen aus C-L A-F als Quorum wählt und ein anderer G-L Æ beide Aktualisierungen
Der Client betrachtet die Versionsnummern und wählt den neusten werden akzeptiert (NW = N/2) (Zwei Versionen gleichen Alters!)
Ritter, DIS, SS 2012, Kapitel 4 20NoSQL-Datenbanken (1) … not only SQL
Vom Design auf Scale-Out ausgelegt
• NoSQL-Systeme können weitere Rechnerknoten in das System einbinden und so Effizienz
steigern.
• Im Gegensatz zum klassischen Scale-Up, wo nur die Hardware eines einzelnen Systems
erweitert wird.
Datenmodell nicht zwangsweise Relational
• In der NoSQL-Bewegung gibt es Systeme mit unterschiedlichen Datenmodellen
- Key-Value-Stores
- Spalten-Orientierte Speicherung (Wide-Column-Stores)
- Dokumentenorientierte Speicherung
- Graphen-orientierte Speicherung
NoSQL-Datenbanksysteme unterstützen in der Regel Replikation
Nutzen von BASE und Eventually Consistency statt ACID bei der
Datenmanipulation
Meistens sind NoSQL-Systeme aus der Kategorie CP oder AP, selten aus der
Kategorie CA.
Ritter, DIS, SS 2012, Kapitel 4 21NoSQL-Datenbanken (2)
Relational
Übersicht Jeder Client kann jederzeit
Datenmodelle Key-Value
Spaltenbasiert
Dokumenten-Orientiert
Lesen und Schreiben
CA
A AP
Postgres, MySQL, … Dynamo, Voldemort, Redis
Vertica Cassandra
SimpleDB, CouchDB, Riak
Alle Clients haben die
C CP
BigTable, Hypertable, Hbase
P Das System läuft gut trotz
selbe Sicht auf die Daten MongoDB, TerraStore Netzwerk-Partitionen
Redis, MemcacheDB
Nathan Hurst: Visual Guide to NoSQL Systems
http://blog.nahurst.com/visual-guide-to-nosql-systems
Ritter, DIS, SS 2012, Kapitel 4 22Datenmodelle (1)
Key-Value-Stores
• Bieten mindestens ein einfaches Schema aus Schlüssel und Wert an
- Schlüssel können aber in Namensräume und Datenbanken aufgeteilt
werden.
- Werte können nicht nur Zeichenketten, sondern auch Listen sein.
• Vorteil:
- Einfache Schemata
- Einfache Datenhaltung und Replikation möglich
• Nachteil:
- Abfragemächtigkeit gering, da meistens eigene Anfragesprache:
- Kein SQL, es werden sogenannte CRUD-Operationen einer API
bereitgestellt (Create, Read, Update, Delete).
• Beispiel-Systeme: Amazon Dynamo (AP), Voldemort (AP), Redis (CP)
Ritter, DIS, SS 2012, Kapitel 4 23Datenmodelle (2)
Wide-Column-Stores
• Datenhaltung klassischerweise Tupel-orientiert
• In Wide-Column-Stores ist Datenhaltung vertikal nach den Attributen
partitioniert:
PK A Z PK A PK Z
…
• Vorteil:
- Datenhaltung lässt sich entsprechend wie bei Key-Value-Stores einfach
replizieren
- SQL lässt sich prinzipiell anwenden, NoSQL-Datenbanken nutzen aber
meistens CRUD-Operationen
• Nachteil Wide-Column-Stores:
- Joins nötig um alle Attribute eines Datensatzes zu bekommen
• Beispiele: Apache Cassandra (AP), Google Bigtable (CP), Apache Hbase (CP)
Ritter, DIS, SS 2012, Kapitel 4 24Datenmodelle (3)
Document-Stores
• Von der Idee her wie Key-Value-Stores: Als Values werden aber strukturierte
XML-Dokumente wie RDF oder andere strukturierte Formate wie JSON (binäre
Variante BSON) benutzt:
- Beispiel JSON:
SurName=`Doe`
FirstName=`John`
Age=`42`
• Vorteil:
- Ein Document-Store ist schemafrei bzgl. der gespeicherten Dokumente
(Anwendung ist dafür verantwortlich)
- Einfache Datenhaltung und Replikation möglich
• Nachteil:
- Integritätsbedingung zwischen Dokumenten ohne Schemata schwierig zu
überwachen
- Anfrageverarbeitung auf Dokumente selbst schwierig
• Beispiele: CouchDB (AP), Amazon SimpleDB (AP), MongoDB (CP)
Ritter, DIS, SS 2012, Kapitel 4 25Beispiel für Key-Value-Stores
Beispiel
• Amazon Dynamo
- Dynamo ist ein System der Kategorie AP.
- Daten werden durch einen Consistent-Hashing-Algorithmus
partitioniert und verteilt.
- Nutzt Quorum-basiertes Konsistenzprotokoll mit den folgenden
Parametern:
- N: Anzahl der Replikate
- NR : Anzahl der Knoten, die bei einem Lesevorgang erfolgreich
gelesen werden müssen
- NW: Anzahl der Knoten, auf denen ein Schreibvorgang erfolgreich
abgeschlossen werden muss
- Nur Teil ein des Gifford-Schema wird angewandt: N < R + W
Sloppy Quorum: Schreib-Schreib-Konflikte werden nicht verpflichtend
verhindert.
Ritter, DIS, SS 2012, Kapitel 4 26Beispiel für Key-Value-Stores (2)
Schreibvorgang Dynamo
Verteiltes System Anwendungssystem
W[d] Æ dneu
W[d] Æ d(1,0,0)
ACK
W[d]Æd(1,0,0)
ACK
N = 3, NR = 2, NW = 2
Ritter, DIS, SS 2012, Kapitel 4 27Beispiel für Key-Value-Stores (3)
Lesevorgang Dynamo
Verteiltes System Anwendungssystem
R[d]
R[d]
{d(1,0,0), d(0,1,0)}
Konflikt: Es gibt 2 gleichalte Objektversionen des
selben Objekts, die Dynamo zurückliefert (Client
D(0,1,0)
R[d]
muss das Problem lösen)
N = 3, NR = 2, NW = 1
Kann entstehen, wenn
N = 3, NR = 2, NW = 1 (NW< N/2!)
Dynamo ist in dieser Konfiguration nicht konsistent!
Diskussion: bei N = NW wird zugesichert, dass
Änderung auf allen Knoten erfolgt Æ Availability
nicht mehr erfüllt!
Ritter, DIS, SS 2012, Kapitel 4 28Zusammenfassung (1)
NoSQL-Datenbanken sind ein großes Feld:
• Verschiedene Datenmodelle
- Key-Value-Stores
- Wide-Column-Stores
- Dokumentenorientierte Datenbanken
- (Graphenbasierte Datenbanken)
• CAP-Theorem gibt verschiedene Klassifizierungen von Systemen
vor, die jeweils zwei der drei Eigenschaften Availability, Partition
Tolerance oder Consistency erfüllen können
- Viele NoSQL-Systeme arbeiten mit Replikaten und implementieren AP-
Systeme, um Availability mit Eventually Consistency zuzusichern.
Ritter, DIS, SS 2012, Kapitel 4 29Zusammenfassung (2)
BASE statt ACID
• Eventually Consistency als Form der Datenkonsistenz bei Replikation:
- Konsistenz ist kein fester Zustand nach Commit,
sondern wird „irgendwann“ erreicht
• Verschiedene Abstufungen möglich
- Read-Your-Writes,
- Monotonic-Read, Monitonic Write
- Writes Follow Reads
Konsistenzprotokolle sichern Garantien von
Konsistenzmodellen zu
Lamport: The Part-Time Parliament,
• Prominentes Beispiel: Quorum-Consensus ACM Transactions on Computer Systems
• Variante: Paxos-Consensus (nicht behandelt) 16, 2 (May 1998), 133-169
NoSQL-Datenbanken sind aktuelles Industrie- und
Forschungsfeld
Ritter, DIS, SS 2012, Kapitel 4 30Sie können auch lesen
