NoSQL-Datenbanken am Beispiel CouchDB

NoSQL-Datenbanken
am Beispiel CouchDB

Dr. Kerstin Puschke

Freie Universität Berlin

13. September 2010

K. Puschke (FU Berlin) NoSQL 13. September 2010 1 / 55

Übersicht

1 Einführung

2 Why Not Only SQL - warum nicht immer SQL einsetzen?

3 Datenmodelle

4 CouchDB

5 Herausforderungen und Kritik


Übersicht

1 Einführung
Relationale Datenbanksysteme
Weitere Datenbanksysteme
NoSQL


3 Datenmodelle

4 CouchDB



Relationale Datenbanksysteme

in der Theorie
Codd (1970) [3]
Codd’s 12 Regeln (1985) [4, 5]
Vollständigkeit im Sinne der relationalen Algebra
in der Praxis und im Kontext des Vortrags
zeilenbasierte Speicherung in Tabellen
SQL oder vergleichbare Sprache
z.B. MySQL, Postgres, Oracle,. . .


Weitere Datenbanksysteme

Objektdatenbanken (db4o)
XML
Speicherung als Schlüssel-Wert-Paare (BerkeleyDB)
spaltenorientierte Systeme (Sybase IQ)
dokumentenorientierte Systeme (Lotus Notes)
kaum Verbreitung im Vergleich zu relationalen Systemen
frühe Formen von NoSQL?


NoSQL
Begriffsklärung

2009 als Sammelbegriff für bereits länger existierende Systeme
etabliert
Not only SQL
keine eindeutige Deﬁnition
nicht-relationale Datenspeicher


NoSQL
Was NoSQL manchmal (nicht) ist

Verteiltes_Arbeiten
Skalierbarkeit Schemafreiheit
Geschwindigkeit Open_Source Open_Standards
Große_Datenmengen
Aufgabe_der_ACID-Prinzipien Einfache_Benutzung
Fehlertoleranz Concurrency Durchsatz
Zuverlässigkeit


NoSQL
Begriffsklärung

Ankündigung no:sql(eu) conference, April 2010 [11]

. . . era of “one-size-ﬁts-all database” seems to be over.
Instead of squeezing all your data into tables, we believe the
future is about choosing a data store that best matches your
data set and operational requirements. It’s a future of
heterogeneous data backends, polyglot persistence and
choosing Not Only SQL but sometimes also a document
database, a key-value store or a graph database.


NoSQL-Systeme im Einsatz

CouchDB (BBC, Ubuntu One)
BigTable (GoogleMaps, GoogleReader, YouTube. . . )
Dynamo (Amazon Webservices, Amazon)
Cassandra (Twitter, Facebook,. . . )
Project Voldemort (linkedin)
redis (github, The Guardian)
MongoDB (sourceforge, github, New York Times)
...


Übersicht

1 Einführung

Web vs. RDBMS
Verteilte Systeme
NoSQL vs. SQL

3 Datenmodelle

4 CouchDB



(Un)strukturierte Daten
Web vs. RDBMS

RDBMS
Datenbankschema entscheidend
aufwändig zu entwerfen: Normalisierung,. . .
nachträglich schwierig zu ändern
stark strukturiert

Webanwendungen
user generated content
unstrukturierte Daten


Abfragen
Web vs. RDBMS

RDBMS
dynamische Abfragen (ad hoc reporting)
beliebige Abfragen über alle Daten direkt in SQL

Webanwendungen
wiederkehrende Abfragen, nur Parameter ändern sich


Verteiltes Arbeiten

Skalierbarkeit
große Datenmengen
früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung
heute: preiswerte Hardware ergänzen (auch via cloud)
Hochverfügbarkeit
RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt


Verteiltes Arbeiten

Skalierbarkeit
große Datenmengen
The largest BigTable instance manages about 6 petabytes of data
spread across thousands of machines
Jeff Dean, Google I/O conference, Mai 2008 (Shankland [14])
früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung
heute: preiswerte Hardware ergänzen (auch via cloud)
Hochverfügbarkeit
RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt


CAP Theorem
Consistency, Availability, Partition Tolerance

Theorem
Consistency
Der Client glaubt, eine Menge von Operationen sei auf einen
Schlag passiert: Alle Clients sehen dieselben Daten.
Availability
Jede Operation endet mit einer bestimmungsgemäßen Antwort:
Alle Clients können auf eine Version der Daten zugreifen.
Partition Tolerance
Operationen werden zu Ende geführt, auch wenn die Datenbank
partitioniert ist.
Nur zwei der drei Eigenschaften sind gleichzeitig möglich!
siehe Brewer [2] und Lynch & Gilbert [10]


C,A oder P?

abhängig vom gewählten DBMS
abhängig vom Setup
abhängig von der Konﬁguration - u.U. sogar pro Abfrage
Network Partitioning oft unvermeidlich
trade off: Consistency vs. Availability
Abstufungen möglich


CAP Theorem
Häuﬁge Settings

Availability & Consistency: VoltDB, BigTable . . .
Consistency & Partition Tolerance: viele RDBMS, . . .
Strong Consistency, Enforced Consistency
ACID (atomicity, consistency, isolation, durability)
siehe Gray [7] und Haerder & Reuter [8]
pessimistic locking
Availability & Partition Tolerance: CouchDB, MongoDB,
Cassandra, Dynamo,. . .
Weak Consistency, Eventual Consistency
BASE (basically available, soft-state, eventual consistency)
siehe Pritchett [13]
optimistic locking, multi-version concurrency control (MVCC)


NoSQL vs. SQL

Nachteile auch in RDBMS vermeidbar, z.B. durch
Verzicht auf Normalisierung
Fokus auf Verfügbarkeit statt Konsistenz
...
dadurch aber Verlust vieler Vorteile, z.B.
Verlust von ACID-Garantien,
referentieller Integrität,
...
ggf. ein NoSQL-System die bessere Wahl


Übersicht

1 Einführung


3 Datenmodelle
Spaltenorientierung
Objektorientierung
Graphen
Schlüssel-Wert-Paare
Dokumentenorientierung

4 CouchDB



Relationales Modell

striktes Schema
Tabellen und Spalten statisch
zeilenorientierte Speicherung
’echte’ Beziehungen zwischen Daten
foreign key constraints, joins. . .


Spaltenorientierung

erste spaltenorientierte Datenbanken in den 1970ern
Cassandra, BigTable,. . .
spaltenorientierte Speicherung
mehr Performanz für bestimmte Abfragen
z.B. Aggregieren innerhalb einer Spalte
ﬂexibleres Schema
Spalten dynamisch
keine ’echten’ Beziehungen


Cassandra’s Datenmodell
Vereinfachte Darstellung

keyspace
entspricht der Anwendung; Beispiel: ’Blog’
column family
entspricht einer Datei
Beispiel: ’Posts’ oder ’Users’
beliebig viele Einträge (key + columns)
key
identiﬁziert einen Eintrag in der column family
wird bei Abfragen benutzt
keys sind lokal
gleichnamige keys verschiedener column families sind verschieden
keine ’echten’ Beziehungen
column
tupel (name, value, timestamp)
Beispiel: {name:username, value:foo, timestamp:12345}


Cassandra’s Datenmodell
Vereinfachte Darstellung

verschiedene keys können verschiedene columns haben
kein striktes Schema
Beispiel
Abfrage (:Users, 42)
{
username : foo,
email : foo@example.com,
screen_name : FOOOOO
}
Abfrage (:Users, 23)
{
username : bar,
admin : yes
}


Objektorientierung

Persistenzschicht für Objektorientierte Programmierung
Abfragen in objektorientierter Programmiersprache
OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene
Sprache
db4o, JADE, Databeans,. . .


Graphen

Graphen im Sinne der Mathematik
Knoten und Kanten
modellieren z.B. Netzwerk, Leitungssystem,. . .
Spezialfall: Baum
z.B. Produktkategorien (Eltern-Kind-Beziehung)


Graphendatenbanken

InfoGrid, neo4j, . . .
Daten als Graphen
Knoten
eigenständige Objekte wie Kunde, Bestellung,. . .
Kanten sind Beziehungen zwischen Knoten
schematisiert oder schemafrei
Kanten sind “first class objects”
häufige Operation: Traversierung
gut geeignet für komplexe Beziehungsgeflechte
z.B. social network



Riak, Tokyo Cabinet,. . .
Abfrage per Schlüssel
schemafrei
keine ’echten’ Relationen


Dokumentenorientierung

CouchDB, MongoDB, Riak,. . .
Dokument: weitere Abstraktionsebene oberhalb von
Schlüssel-Wert-Paaren
für sich genommen sinnvolle Informationseinheit
meist Entsprechung im Real Life (Rechnung, Visitenkarte,. . . )
üblicherweise kein leeren Felder
schemafrei
keine ’echten’ Relationen


CouchDB’s Datenmodell

Format: JavaScript Object Notation (JSON)
Bestandteil von JavaScript
wird z.T. direkt vom Browser verstanden
wenig Datentypen
diese werden von nahezu allen Sprachen verstanden
obligatorische Schlüssel:
_id zur eindeutigen Identiﬁkation des Dokumentes (UUID),
_rev zur Versionierung des Dokumentes
Dokumente können Attachments haben


CouchDB Dokument
JSON


Übersicht

1 Einführung


3 Datenmodelle

4 CouchDB
Implementierung
Updates and Concurrency
Abfragen
Design Documents
Anwendungen



Was ist CouchDB?

Cluster Of Unreliable Commodity Hardware DataBase
Datenbankcluster auf unzuverlässiger Standardhardware
Datenbanksystem (nicht nur) für Webanwendungen
offene Webstandards
Robuste Replikation
schemafrei
geeignet für unstrukturierte Daten
Philosophie: entspanntes Arbeiten
keine Entscheidungen, die nicht zu revidieren sind


Implementierung
Überblick

HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov [16]
Erlang
funktional, fehlertolerant, concurrency optimiert
Viewserver in JavaScript (Indizes erstellen)
alternativ via Plugins auch PHP, Ruby, Python, Perl, Common
Lisp, Erlang,. . .
dokumentenbasierte Speicherung (JSON)
Datenbank und Indizes als B-Tree gespeichert
eventual consistency (in verteilten Systemen)
Storage Engine: ACID (lokal), optimistic locking,
Multi Version Concurrency Control


Replikation

shared nothing cluster
Server unabhängig voneinander
inkrementell
geﬁltert
N-Master, Master-Slave,. . .
Hot failover, backup, Lastverteilung,. . .
extrem robust
vermeidet die Fallacies of Distributed Computing
ggf. manuell Konﬂikte lösen


Updates

komplettes Dokument abholen, verändern, zum Speichern
zurücksenden
neue Version eines Dokumentes wird an Datenbankdatei
angehängt
Robust: was einmal auf Platte steht, wird nicht mehr angefaßt
Geschwindigkeit: neue Version kann angehängt werden, während
alte noch gelesen wird


Multi Version Concurrency Control

optimistic locking
Client schickt verändertes Dokument mit unveränderter
Versionsnummer _rev
Server prüft, ob diese _rev identisch ist mit der aktuell
gespeicherten
wenn ja: Dokument wird gespeichert (Server vergibt neue _rev)
wenn nein: Konﬂikt
keine Versionskontrolle
es werden nicht alle Versionen aufbewahrt


View

(secondary) Index (Schlüssel-Wert-Paare)
Schlüssel und Werte des Views sind Werte aus Dokumenten
Beispiel: Erstellungsdaten als Schlüssel, Blogposttitel als Werte
können auch arrays von Werten (aus Dokumenten) sein
Werte (im View) können auch aggregierte Werte (aus Dokumenten)
sein
sortiert nach Schlüsseln
efﬁzientes Abfragen nach bestimmten Schlüsseln oder Bereichen
von Schlüsseln
’Titel aller Blogposts von Mai 2009’
zur Abfragezeit erzeugt/aktualisiert durch MapReduce


View
Beispiel

View mit Schlüssel Datum und Wert Titel des Blogposts, dargestellt in
Futon


Map Reduce
View erzeugen

map und reduce Funktionen: Konzept aus der funktionalen
Programmierung
parallele Verarbeitung großer Datenmengen
MapReduce: framework zur verteilten Verarbeitung großer
Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6]
map verarbeitet Dokumente
erzeugt Schlüssel-Wert-Paare
optionales reduce erzeugt aggregierte (Zwischen)Werte
verarbeitet Ergebnisse von map oder
rekursiv Zwischenergebnisse von reduce
group: anwenden auf Objekte mit gleichem Schlüssel
Beispiel: nicht alle Blogposts zählen, sondern Blogposts pro Tag
Map-Reduce-Funktionen gespeichert in Dokumenten
(Designdokumente)

View
Beispiel

View ohne reduce


View
Beispiel

View mit reduce

View mit reduce und group_level=2


Design Documents

_id beginnt mit _design
enthalten Anwendungscode, sprich Funktionen
Map-Reduce-Funktionen für Views
Validation: Zulässigkeit von Updates
input prüfen, nur eingeloggte user,. . .
serverseitige Bearbeitung vor dem Speichern eines Dokumentes
Show/List: JSON in HTML, XML,. . . konvertieren


Webanwendungen mit CouchDB
Klassische Webanwendungen

Serverseitige Skripte lesen Daten aus CouchDB
erzeugen daraus dynamisch HTML
Webserver liefert aus


Webanwendungen mit CouchDB
CouchApps

leben vollständig in der Datenbank
keine middleware
Show/List-Funktionen
Attachments (HTML,CSS, Javascript) direkt ausliefern
Ausgelieferte Webseite greift per Javascript/HTTP auf CouchDB
zu
Replikation: update, fork, backup von Anwendungen


Dezentrale offline Webanwendung
Ein Usecase für CouchApps

Daten und Anwendung lokal beim user
offline verfügbar
lokale Datenhaltung = niedrige Latenz
dezentral
(gefilterte) Replikation mit anderen usern


Desktop-Anwendungen

Beispiel: Synchronisation von Anwendungsdaten
bereits realisiert in Ubuntu
Bookmarks, Adreßbuch,. . . in CouchDB speichern
per Replikation mit anderen Rechnern synchronisieren


Übersicht

1 Einführung


3 Datenmodelle

4 CouchDB



Herausforderungen und Kritik

HTML/JS, HTTP,. . .
vorhandene Probleme bleiben bestehen
kein ad hoc reporting
BASE vs. ACID
Zuverlässigkeit z.B. bei Finanztransaktionen
Zweifel am Geschwindigkeitsvorteil von NoSQL-Systemen
Stonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12]

CouchApps und Co: Verteilte Identitäten
serverseitiger Code nötig für Authentiﬁzierung/Autorisierung
vertrauenswürdiger Server nötig


Noch Fragen?

Vielen Dank für Ihre Aufmerksamkeit!

Fragen und Anmerkungen?


Referenzen I

J. Chris Anderson, Jan Lehnardt, and Noah Slater.
CouchDB: The deﬁnitive Guide.
O’Reilly, 2010.
URL http://books.couchdb.org/relax/.
Eric A. Brewer.
Towards robust distributed systems.
In Principles of Distributed Computing (Keynote). 2000.
URL http://www.cs.berkeley.edu/~brewer/
cs262b-2004/PODC-keynote.pdf.
Edgar F. Codd.
A relational model of data for large shared data banks.
Communications of the ACM, 13(6):377–387, 1970.
doi:10.1145/362384.362685.


Referenzen II

Edgar F. Codd.
Does your dbms run by the rules?
ComputerWorld, Oktober 1985.
Edgar F. Codd.
Is your dbms really relational?
ComputerWorld, Oktober 1985.
Jeffrey Dean and Sanjay Ghemawat.
Mapreduce: Simpliﬁed data processing on large clusters.
In Sixth Symposium on Operating System Design and
Implementation. 2004.
URL http://labs.google.com/papers/mapreduce.html.


Referenzen III

Jim Gray.
The transaction concept: Virtues and limitations.
In Proceedings of the 7th International Conference on Very Large
Databases, pages 144–154. 1981.
Theo Haerder and Andreas Reuter.
Principles of transaction-oriented database recovery.
ACM Computing Surveys, 15:287–317, 1983.
Eric Lai.
Researchers: Databases still beat google’s mapreduce.
Computer World, April 2009.
URL http://www.computerworld.com/s/article/
9131526/Researchers_Databases_still_beat_Google_
s_MapReduce.


Referenzen IV

Nancy Lynch and Seth Gilbert.
Brewer’s conjecture and the feasibility of consistent, available,
partition-tolerant web services.
ACM SIGACT News, 33(2):51–59, 2002.
doi:10.1.1.20.1495.
URL http://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.20.1495&rep=rep1&type=pdf.
no:sql(eu).
no:sql(eu), April 2010.
URL http://www.nosqleu.com/.


Referenzen V

Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J. Abadi,
David J. Dewitt, Samuel Madden, and Michael Stonebraker.
A comparison of approaches to large-scale data analysis.
In SIGMOD ’09: Proceedings of the 2009 ACM SIGMOD
International Conference. ACM, June 2009.
URL http://database.cs.brown.edu/sigmod09/
benchmarks-sigmod09.pdf.
Dan Pritchett.
Base: An acid alternative.
ACM Queue, 6(3):48–55, 2008.
URL http://queue.acm.org/detail.cfm?id=1394128.


Referenzen VI

Stephen Shankland.
Google spotlights data center inner workings.
cnet news, Mai 2008.
URL
http://news.cnet.com/8301-10784_3-9955184-7.html.
Michael Stonebraker, Daniel Abadi, David J. DeWitt, Sam
Madden, Erik Paulson, Andrew Pavlo, and Alexander Rasin.
Mapreduce and parallel dbmss: Friends or foes?
Communications of the ACM, 53(1):64–71, 2010.
ISSN 0001-0782.
doi:http://doi.acm.org/10.1145/1629175.1629197.
URL http://database.cs.brown.edu/papers/
stonebraker-cacm2010.pdf.


Referenzen VII

Stefan Tilkov.
A brief introduction to rest.
Info Queue, 2007.
URL
http://www.infoq.com/articles/rest-introduction.


NoSQL-Datenbanken am Beispiel CouchDB

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie NoSQL-Datenbanken am Beispiel CouchDB

Ähnlich wie NoSQL-Datenbanken am Beispiel CouchDB (20)

Mehr von Kerstin Puschke

Mehr von Kerstin Puschke (6)

NoSQL-Datenbanken am Beispiel CouchDB