Prof. Dr. Ingo Claßen Einführung Kategorisierung von NoSQL

Werbung
NoSQL
Prof. Dr. Ingo Claßen
Hochschule für Technik und Wirtschaft Berlin
Einführung
Kategorisierung von NoSQL-Systemen
Verteilung
Konsistenz
Literatur
Einführung
Warum NoSQL
I
Unterstützung großer Datenmengen verwaltet durch Computer-Cluster
I
Horizontale Skalierbarkeit
I
Flexibler Umgang mit Schemata
I
Bessere Anpassung an Datenstrukturen in Anwendungen
I
Polyglot Persistence
NoSQL – Ingo Claßen
2/20
Einführung
Stärken relationaler Datenbanksysteme
I
Ausgereift und bereits lange verfügbar
I
Hoher Grad an Standardisierung
I
Einfaches Datenmodell (Tabellen), gut geeignet für
betriebswirtschaftliche Daten
I
Deklarative Abfragesprache mit komplexen Operationen (SQL)
I
Starke Unterstützung für Konsistenzsicherung
I
Starke Unterstützung für Transaktionen (ACID)
I
Starke Unterstützung für Datensicherheit
NoSQL – Ingo Claßen
3/20
Einführung
Schwächen relationaler Datenbanksysteme
I
Einfaches Datemodell: nur Tabellen (Impedance Mismatch)
I
Normalisierung erforderlich
I
Schemaänderungen aufwendig
I
Keine Unterscheidung von Objekten und Beziehungen
I
Schwache Unterstützung für Rekursion
I
Eingeschränkte Datentypen
I
Unterstützung verteilter Transaktionen aufwendig (2PC)
I
Schlechte horizontale Skalierbarkeit
NoSQL – Ingo Claßen
4/20
Kategorisierung von NoSQL-Systemen
Kategorisierung von NoSQL-Systemen
I
Schlüssel-Wert-Systeme
I
I
I
I
Spaltenfamilien-Systeme
I
I
I
Mischung aus Schlüssel-Wert-Systemen und spaltenorientierten
Datenbanken
Mehrdimensionales assoziatives Array
Dokumentendatenbanken
I
I
I
Einfaches Datenmodell
Schlüssel üblicherweise Zeichenketten
Werte z.B. Listen, Mengen, Hashes, Blobs
Üblicherweise JSON-Dateien als Dokumente
Geschachtelte Strukturen
Graphdatenbanken
I
I
Knoten und Kanten als Datenelemente
Einfache Navigation im Graphen
NoSQL – Ingo Claßen
5/20
Verteilung
Aspekte verteilter NoSQL-Systeme
I
Skalierung
I
I
I
Knoten-Hardware
I
I
I
Horizontal, shared nothing
Nahtlos: Dynamisches Hinzufügen/Entfernen von Knoten
Standard-Rechner (commoditiy hardware)
Heterogen
Management
I
I
I
Dezentrale Kontrolle
Uniforme Einsetzbarkeit von Knoten
Last-Balanzierung
NoSQL – Ingo Claßen
6/20
Verteilung
Verteilungstransparenz
I
Zugriffstransparenz
I
Ortstransparenz
I
Replikationstransparenz
I
Framentierungstransparenz
I
Migrationstransparenz
I
Nebenläudigkeitstransparenz
I
Fehlertransparenz
NoSQL – Ingo Claßen
7/20
Verteilung
Fehler in verteilten Systemen
I
Server-Fehler
I
Fehler in der Nachrichtenübertragung
I
Verbindungsfehler
I
Netzwerkpartitionierung
NoSQL – Ingo Claßen
8/20
Verteilung
Sharding
I
Daten auf verschiedenen Knoten
I
Leser verteilen Arbeit auf Knoten
I
Gemeinsam genutzte Daten auf
gleichen Knoten (z.B. Aggregate)
I
Verteilung Daten (z.B. geographisch)
I
Zusammen mit Replikation
NoSQL – Ingo Claßen
9/20
Verteilung
Allokation Objekte: Consistent Hashing
Zuordnung Objekte
NoSQL – Ingo Claßen
Einfügen Knoten
Löschen Knoten
10/20
Verteilung
Master-Slave-Replikation
I
Änderungen nur auf Master
I
Propagation Änderungen auf Slaves
I
Skalierung in Bezug auf Lesezugriffe
I
Verfügbarkeit – Lesen bei Ausfall
Master möglich
I
Sicherungskopien der Daten
I
Inkonsistenzen beim Lesen (veraltete
Zustände)
NoSQL – Ingo Claßen
11/20
Verteilung
Peer-To-Peer-Replikation
I
Vor- und Nachteile wie
Master-Slave-Replikation
I
Weiterer Vorteil: Skalierung beim
Schreiben
I
Weiterer Nachteil: Schreibkonflikte
NoSQL – Ingo Claßen
12/20
Verteilung
Replikation und Sharding
I
Skalierung + Ausfalltolernanz
I
Verschiedene Master für
verschiedene Datenelemente
möglich
NoSQL – Ingo Claßen
13/20
Konsistenz
CAP - Consistency, Availability, Partition Tolerance
I
Konsistenz (Consistency)
I
I
I
I
Verfügbarkeit (Availability)
I
I
I
Konsistenter Zustand im verteilten System
Änderung auf einem Knoten
Lesezugriff auf replizierten Knoten liefert geänderten Wert
System bietet akzeptable Reaktionszeit
Auch bei Ausfall von Knoten und Netzwerkverbindungen
Ausfalltoleranz (Partition Tolerance)
I
Bei Ausfall von Knoten / Netzwerkverbindungen: kein Ausfall
Gesamtsystem
NoSQL – Ingo Claßen
14/20
Konsistenz
Zusammenspiel von C, A und P
1. Kein Ausfall im System
I
I
C und A kann sichergestellt werden
Replikation der Daten kann erfolgen
2. Ausfall im System – Entscheidung zwischen C und A
I
Entscheidung für C
I
I
I
Entscheidung für A
I
I
I
I
I
I
I
Operationen auf allen Knoten ablehnen
Keine Verfügbarkeit
Operationen auf verfügbaren Knoten zulassen
Erzeugt inkonstistenten Zustand im Gesamsystem
Knoten können verschiedene Zustände für gleiches Objekt haben
Konstistenz später herstellen
(Eingeschränkte) Verfügbarkeit
Keine absolute Entscheidung zwischen C und A
Verschiedene Strategien möglich
NoSQL – Ingo Claßen
15/20
Konsistenz
Base - Basic Available, Soft State, Eventually Consistent
I
Basic Available
I
I
Soft State
I
I
(Eingeschränkte) Verfügbarkeit als oberstes Ziel
Fenster der Inkonsistenz
Eventually Consistent
I
Irgendwann wird ein konsistenter Zustand erreicht
NoSQL – Ingo Claßen
16/20
Konsistenz
Konsistenz aus Nutzersicht
I
Beteiligte
I
I
I
I
Verteiltes Speichersystem
Prozess A schreibt und liest
Prozesse B und C unabhängig von A, schreiben und lesen auch
Konsistenzmodelle
I
Starke Konsistenz
I
I
I
Nach Änderung: A, B und C sehen immer den neuen Wert
Alle Replikate müssen aktualisiert sein
Schwache Konsistenz
I
I
I
NoSQL – Ingo Claßen
A, B oder C sehen den alten Wert
z.B. beim Lesen eines Replikats
Eventual Consistency ist eine Form schwacher Konsistenz
17/20
Konsistenz
Variationen von Eventual Consistency
I
Causal consistency
I
I
I
Read-your-writes consistency
I
I
I
Innerhalb Sitzung: A hat ändert: A sieht neuen Wert
AußerhalbSitzung: A sieht möglicherweise alten Wert
Monotonic read consistency
I
I
A hat Wert geändert: A sieht immer neuen Wert
Session consistency
I
I
B hängt kausal von A ab: B sieht neuen Wert
C sieht möglicherweise alten Wert
A hat neuen Wert gelesen: A sieht immer neuen Wert danach
Monotonic write consistency
I
Serialisierung der Schreibzugriffe innerhalb eines Prozesses
NoSQL – Ingo Claßen
18/20
Konsistenz
Konsistenz aus Server-Sicht
I
Definitionen
I
I
I
I
N = Anzahl Knoten
W = Anzahl Knoten Änderungsbestätigung (W-Quorum)
R = Anzahl Knoten Lesebestätigung (R-Quorum)
Alternativen
I
I
I
I
W = N: Fokus auf Konsistenz
W = 1: Fokus auf Verfügbarkeit
W+R > N: Starke Konsistenz
W+R <= N: Schwache Konsistenz
NoSQL – Ingo Claßen
19/20
Literatur
Literatur
I
NoSQL - Einstieg in die Welt nichtrelationaler Web 2.0
Datenbanken, Edlich, Friedland, Hampe, Brauer, Brückner, Hanser,
2011
I
Seven Databases in Seven Weeks: A Guide to Modern
Databases and the NoSQL Movement, Redmont, O’Reilly UK Ltd,
2012
I
NoSQL Distilled, Saldage, Fowler, Addison Wesley, 2012
I
Advanced Data Management, Wiese, De Gruyter, 2015
NoSQL – Ingo Claßen
20/20
Herunterladen