NoSQL-Datenbanken. Kapitel 1: Einführung. Dr. Anika Groß Sommersemester Universität Leipzig 1-1

Transkript

1 NoSQL-Datenbanken Kapitel 1: Einführung Dr. Anika Groß Sommersemester 2017 Universität Leipzig 1-1

2 Inhaltsverzeichnis NoSQL-Datenbanken Motivation und Definition Kategorisierung, Eigenschaften CAP-Theorem ACID-Eigenschaften BASE-Ansatz 1-2

3 Massives Datenwachstum Schätzung von IBM Quelle: Pro Tag werden 2,5 Exabytes an Daten generiert 90% aller Daten weltweit wurden in den letzten 2 Jahren erzeugt Quelle (05 Feb 2013): 1-3

4 Datenproduzenten Quelle: Einführungsveranstaltung Seminar New Trends in Big Data WS 2013/14 1-4

5 Big Data Challenges Quelle: 1-5

6 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

7 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

8 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

9 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

10 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

11 Größe vs. Komplexität data size Key-Value Stores Column Stores Document Databases Graph Databases 90 % of use cases data complexity 1-11

12 NoSQL Datenmodelle

13 DB Engines Ranking (Ausschnitt) NoSQL Data Stores for Big Data 13

14 Inhaltsverzeichnis NoSQL-Datenbanken Definition und Motivation Kategorisierung, Eigenschaften CAP-Theorem ACID-Eigenschaften BASE-Ansatz 1-14

15 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 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

16 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 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) Availability System funktioniert bei Netzwerkpartitionierung trotz Verlust von Nachrichten zwischen Knoten weiter Consistency Partition Tolerance 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

17 CP AP CAP Theorem - Fälle (CA) Konsistent aber nicht verfügbar bei Netzwerkpartitionierung Transaktionen werden blockiert Vermeidung möglicher Konflikte bei Merge zur Sicherstellung der Konsistenz Verfügbar aber nicht konsistent bei Netzwerkpartitionierung Writes stets möglich auch wenn keine Kommunikation mit anderen Knoten möglich (z.b. Synchronisation) Availability Consistency Partition Tolerance Notwendigkeit der Konfliktauflösung für inkonsistente Daten (verschiedene Versionen des selben Datums an verschiedenen Knoten) AP CP Dynamo/S3 Cassandra MongoDB BigTable HBase 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

18 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) 1-18 DBS1 VL Prof. Rahm, Uni Leipzig

19 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,

20 Konsistenzmodelle Strong Consistency update(x,v2) r(x)=v2 r(x)=v1 r(x)=v2 r(x)=v2 Eventual Consistency t update(x,v2) r(x)=v1 r(x)=v1 r(x)=v2 r(x)=v1 r(x)=v2 r(x)=v1 inconsistency window t 1-20

21 Konsistenzmodelle Read-your-writes Consistency update(x,v2) r(x)=v2 r(x)=v1 r(x)=v1 r(x)=v2 r(x)=v1 Monotonic Read Consistency t update(x,v2) r(x)=v1 r(x)=v1 r(x)=v2 r(x)=v2 r(x)=v2 r(x)=v1 t 1-21

22 ACID vs. BASE [Bre00] Aufgeben der (strengen) Konsistenz und des logischen Einbenutzerbetriebs für Verfügbarkeit und Performanz Konsistenz Verfügbarkeit Prinzip Priorität Evolution ACID streng (stets aktuelle Daten pro Knoten) eingeschränkt (z.b. bei Ausfall des Koordinatorknotens bei 2PC) pessimistisch / konservativ Anwendung kann sich auf Datenqualität verlassen Transaktionen im logischen Einbenutzerbetrieb aufwändig (Schema) BASE 1-22

23 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

24 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 5. Record Stores & RDBMS in der Cloud BigTable/HBase, Cassandra Megastore H-Store/VoltDB Synchronisation Transaktionen 6. Graphdatenmanagement Graphmodell & -algorithmen Graphdatenbanken Parallele Graph-Algorithmen 4. Search Engines Lucene Apache Solr ElasticSearch 1-24

25 Literatur [Bre00] Brewer. Towards robust distributed systems. Proceedings of the Annual ACM Symposium on Principles of Distributed Computing (2000) [GL02] Gilbert and Lynch. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News (2002) 1-25