1-1

NoSQL-Datenbanken

Kapitel 1: Einführung

Dr. Anika Groß

Sommersemester 2017

Universität Leipzig

http://dbs.uni-leipzig.de

1-2

Inhaltsverzeichnis

• NoSQL-Datenbanken

– Motivation und Definition

– Kategorisierung, Eigenschaften

• CAP-Theorem

– ACID-Eigenschaften

– BASE-Ansatz

1-3

• Schätzung von IBM

– Pro Tag werden 2,5 Exabytes an Daten generiert

– 90% aller Daten weltweit wurden in den letzten 2 Jahren erzeugt

Quelle (05 Feb 2013): http://www-03.ibm.com/press/de/de/pressrelease/40327.wss

Massives Datenwachstum

Quelle: http://hortonworks.com/blog/7-key-drivers-for-the-big-data-market/

1-4

Datenproduzenten

Quelle: Einführungsveranstaltung Seminar “New Trends in Big Data” WS 2013/14

1-5

Big Data Challenges

Quelle: http://kavyamuthanna.wordpress.com/category/big-data/

1-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-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-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-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)

NoSQL – Data Stores for Big Data

Key-Value Stores (Kap.2)

Document Stores (Kap.3)

Graph Databases (Kap.6)

NoSQL Data Stores

10

*

* multi-model

*

• Kollektion von Key/Value-Paaren: 1 Wert (z.B. BLOB) je Schlüssel• Zugriff über Schlüssel: get(key), put(key, value)

• Speicherung semistrukturierter Daten als Dokument (z.B. JSON)• Zugriff über Schlüssel oder einfache Anfragesprache

• 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, ...

Wide Column Stores / Record Stores (Kap.5)

• Tables with records with (many) dynamic columns• Zugriff über Schlüssel oder SQL-ähnliche Anfragesprache

1-11

Größe vs. Komplexitätd

ata

size

data complexity

Key-Value

StoresColumn

Stores

Document

Databases

Graph

Databases

90 % of use cases

1-12

NoSQL Datenmodelle

https://highlyscalable.files.wordpress.com/2012/02/overview2.png

NoSQL – Data Stores for Big Data

DB Engines Ranking (Ausschnitt)

13http://db-engines.com/en/ranking

1-14

Inhaltsverzeichnis

• NoSQL-Datenbanken

– Definition und Motivation

– Kategorisierung, Eigenschaften

• CAP-Theorem

– ACID-Eigenschaften

– BASE-Ansatz

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

http://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

1-16

Theorem: Ein verteiltes System kann maximal 2 der 3 Eigenschaften gleichzeitig erfüllen.

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)

– System funktioniert bei Netzwerkpartitionierung trotz Verlust von Nachrichten

zwischen Knoten weiter

– Netzwerk-Partitionierung = Knoten aus einer Partition können nicht mehr mit Knoten aus

anderer Partition kommunizieren

PartitionTolerance

Availability

Consistency

NoSQL – Data Stores for Big Data

• 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)• Notwendigkeit der Konfliktauflösung für inkonsistente Daten

(verschiedene Versionen des selben Datums an verschiedenen Knoten)

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 APSource: Misconceptions about

the CAP Theorem

CAP Theorem - Fälle

17

PartitionTolerance

Availability

ConsistencyCP

AP

(CA)

MongoDBBigTableHBase

Dynamo/S3 Cassandra

CP

AP

1-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)

DBS1 VL Prof. Rahm, Uni Leipzig

1-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, ..

1-20

inconsistency window

Konsistenzmodelle

• Strong Consistency

• Eventual Consistency

r(x)=v1 r(x)=v2

r(x)=v2update(x,v2)

r(x)=v2

r(x)=v1 r(x)=v2

r(x)=v1update(x,v2)

r(x)=v1

r(x)=v1 r(x)=v2

t

t

1-21

Konsistenzmodelle

• Read-your-writes Consistency

• Monotonic Read Consistency

r(x)=v1 r(x)=v1

r(x)=v2update(x,v2)

r(x)=v1

r(x)=v1 r(x)=v2

r(x)=v1update(x,v2)

r(x)=v1

r(x)=v2 r(x)=v2

r(x)=v2

t

t

1-22

ACID vs. BASE [Bre00]

• Aufgeben der (strengen) Konsistenz und des logischen

Einbenutzerbetriebs für Verfügbarkeit und Performanz

ACID BASE

Konsistenz streng (stets aktuelle Daten pro

Knoten)

Verfügbarkeit eingeschränkt (z.B. bei Ausfall

des Koordinatorknotens bei 2PC)

Prinzip • pessimistisch / konservativ

• Anwendung kann sich auf

“Datenqualität” verlassen

Priorität Transaktionen im logischen

Einbenutzerbetrieb

Evolution aufwändig (Schema)

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

4. Search Engines

• Lucene

• Apache Solr

• ElasticSearch

5. Record Stores & RDBMS in der Cloud

• BigTable/HBase, Cassandra

• Megastore

• H-Store/VoltDB

• Synchronisation

• Transaktionen

6. Graphdatenmanagement

• Graphmodell & -algorithmen

• Graphdatenbanken

• Parallele Graph-Algorithmen

1-25

Literatur

• [Bre00] Brewer. Towards robust distributed systems. Proceedings of the

Annual ACM Symposium on Principles of Distributed Computing (2000)

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

• [GL02] Gilbert and Lynch. Brewer's conjecture and the feasibility of

consistent, available, partition-tolerant web services. ACM SIGACT News

(2002)