NoSQL-Datenbanken. Kapitel 1: Einführung. Lars Kolb Sommersemester Universität Leipzig 1-1

Transkript

1 NoSQL-Datenbanken Kapitel 1: Einführung Lars Kolb Sommersemester 2014 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 Quelle: IBM (2012) Pro Tag werden 2,5 Exabytes an Daten generiert 90% aller Daten weltweit wurden in den letzten 2 Jahren erzeugt 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 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 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) Impedence 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-8

9 Kategorisierung von NoSQL-Datenbanken Key-Value Stores ( Kapitel 2) Amazon Dynamo, MemCacheDB, Voldemort, Riak, Redis, Scalaris,... Speicherung eines Werts (z.b. BLOB) pro nutzer-definiertem Schlüssel Zugriff über Schlüssel, d.h. put (key, value) und get (key) -Methode Document Stores ( Kapitel 3) SimpleDB, CouchDB, MongoDB, Terrastore,... Speicherung semistrukturierter Daten als Dokument (z.b. JSON) Zugriff über Schlüssel oder einfache Anfragesprache Extensible Record Stores (Wide-column stores) ( Kapitel 5) BigTable / HBase, HyperTable, Cassandra,... Tabellen-basierte Speicherung mit flexibler Erweiterung um neue Attribute Zugriff über Schlüssel oder SQL-ähnliche Anfragesprache Scalable Relational Databases ( Kapitel 5) MySQL Cluster, MegaStore, VoltDB, Clustrix, ScaleDB, ScaleBase, NimbusDB,

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

11 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,... Tradeoff: Performanz vs. Datenkonsistenz Warten bis alle (relevanten) Knoten synchronisiert sind Vermeidung (oder Auflösung) von Mischkonflikten 1-11

12 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 sehen zur selben Zeit die selben Daten. Availability (Verfügbarkeit) Jede Lese/Schreib-Anfrage an einen non-failing Knoten wird beantwortet Knotenausfälle beeinflussen nicht die Verfügbarkeit lebender Knoten Partioning tolerance (Partitionstoleranz) System funktioniert trotz Verlust von Nachrichten zwischen Knoten Netzwerk-Partitionierung = Knoten aus einer Partition können nicht mehr mit Knoten aus anderer Partition kommunizieren Theorem: Ein verteiltes System kann maximal zwei der drei Eigenschaften gleichzeitig erfüllen. 1-12

13 CAP-Fälle CA keine Partitionstoleranz (Relationale) Datenbank ermöglicht verteilte Transaktionen zur Konsistenzwahrung Voraussetzung: funktionierendes Netzwerk (kein Nachrichtenverlust) CP keine Verfügbarkeit im Falle von Netzwerkpartitionierung werden Transaktionen blockiert Vermeidung möglicher Konflikte bei Merge, dadurch Sicherstellung der Konsistenz AP keine Konsistenz Writes stets möglich auch wenn keine Kommunikation mit anderen Knoten möglich (z.b. Synchronisation) Notwendigkeit der Auflösung inkonsistenter Daten, d.h. verschiedene Versionen des selben Datums an verschiedenen Knoten 1-13

14 CAP-Theorem und Data Stores Availability (Verfügbarkeit): Alle Clients können stets lesen und schreiben. A nach: Nathas Hurst s Visual Guide to NoSQL Systems Parallele DBMS Dynamo/S3 (KV) CouchDB (Document) Cassandra (Record) Consistency (Konistenz): Alle Clients haben stets die gleiche Sicht auf die Daten. C Verteilte Datenbanken Azure Storage (KV) MongoDB (Document) BigTable/HBase (Record) P Partition Tolerance (Partitionstoleranz): Das System funktioniert trotz Netzwerk-Partitionierung weiter. 1-14

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

16 ACID vs. BASE [Bre00] Aufgabe (strenger) Konsistenz und logischem Einbenutzerbetrieb für Verfügbarkeit und Performanz BASE = Basically Available, soft-state, eventual consistency 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-16

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

18 Inhaltsverzeichnis (vorläufig) 1. Einführung NoSQL-Datenbanken CAP-Theorem 2. Key-Value Stores Microsoft Azure Storage Amaszon S3/Dynamo 3. Document Stores CouchDB MongoDB 5. Record Stores & RDMS in der Cloud BigTable/HBase, Cassandra Megastore H-Store/VoltDB Synchronisation Transaktionen 6. Graphdatenmanagement Graphmodell & -algorithmen Graphdatenbanken Parallele Graph-Algorithmen 4. Skalierbare Webanwendungen Design-Prinzipien Google App Engine 1-18

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