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