Not only SQL - CouchDB und andere NoSQL-Datenbanken

Not only SQL
CouchDB und andere NoSQL-Datenbanken

Dr. Kerstin Puschke

Vortrag an der HAW Hamburg

3. Juni 2010

K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 1 / 79

Lizenz

Lizenz
Dieser Text steht unter einer Creative Commons
Attribution 3.0 Germany Lizenz, siehe
http://creativecommons.org/licenses/by/3.0/de/


Übersicht

1 Einführung

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

3 Protokolle & APIs

4 Datenmodelle

5 CouchDB

6 Herausforderungen und Kritik

7 Praxisbeispiel


Übersicht

1 Einführung
Relationale Datenbanksysteme
Weitere Datenbanksysteme
NoSQL


3 Protokolle & APIs

4 Datenmodelle

5 CouchDB


K. Puschke (Vortrag HAW Hamburg)
7 NoSQL 3. Juni 2010 4 / 79

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

3 Protokolle & APIs

4 Datenmodelle

5 CouchDB


7 Praxisbeispiel

(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]


CAP Theorem
Anwendung

Availability & Consistency: Paxos, BigTable . . .
Network Partitioning oft unvermeidlich
trade off: Consistency vs. Availability
Consistency & Partition Tolerance: viele RDBMS, . . .
ACID (atomicity, consistency, isolation, durability)
siehe Gray [7] und Haerder & Reuter [8]

Availability & Partition Tolerance: CouchDB, MongoDB,
Cassandra, Dynamo,. . .
BASE (basically available, soft-state, eventual consistency)
siehe Pritchett [13]


Übersicht

1 Einführung


3 Protokolle & APIs
HTTP/REST
MapReduce

4 Datenmodelle

5 CouchDB


7 Praxisbeispiel

Protokoll und API

viele NoSQL-Systeme nutzen
vorhandene Programmiersprachen (neo4j,. . . )
HTTP/REST (CouchDB, MongoDB,. . . )
verbreitet: MapReduce-Techniken (Parallelisierung)


RESTful HTTP API

HTTP Protokoll
Browser, curl,. . . sind DB-Clients
Clients in beliebiger Sprache leicht zu programmieren
vorhandene Webtechnologien nutzbar
Load Balancer, Proxy, HTTPS via SSL-fähigen Proxy. . .
Vor- und Nachteile von HTTP


RESTful HTTP API

REpresentational State Transfer API
Architekturprinzip für Kommunikation zwischen heterogenen
Anwendungen
geeignet für verteilte Systeme
Stateless Communication
jeder Request in sich geschlossen
Anwendungsinformationen nur im Client
keine serverseitigen Sitzungen o.ä.


CouchDB
REST/HTTP

Willkommensnachricht des Servers
http://localhost:5984
Alle Datenbanken anzeigen
http://localhost:5984/_all_dbs
Informationen über die Datenbank kontaktdaten
http://localhost:5984/kontaktdaten


MapReduce

map und reduce Funktionen: Konzept aus der funktionalen
Programmierung
verarbeitet große Datenmengen parallel
MapReduce: framework zur verteilten Verarbeitung großer
Datenmengen (Google)
freie Implementierung: Hadoop


Übersicht

1 Einführung


3 Protokolle & APIs

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

5 CouchDB

6 Herausforderungen und Kritik NoSQL
K. Puschke (Vortrag HAW Hamburg) 3. Juni 2010 23 / 79

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,. . .
Wert muss kein String sein (Objekte,. . . möglich)
Abfrage per Schlüssel
schemafrei
keine ’echten’ Relationen


Dokumentenorientierung

CouchDB, MongoDB, Riak, XML-Datenbanken. . .
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

Dokument mit _id 69a. . . aus Datenbank kontaktdaten
http://localhost:5984/kontaktdaten/
69a87107057813de1414e08a9f000912


CouchDB Dokument
JSON


Übersicht

1 Einführung


3 Protokolle & APIs

4 Datenmodelle

5 CouchDB
Implementierung
Updates and Concurrency
Abfragen
Design Documents
Anwendungen

6 Herausforderungen und Kritik NoSQL
K. Puschke (Vortrag HAW Hamburg) 3. Juni 2010 36 / 79

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
optimistic locking, Multi Version Concurrency Control


Replikation

shared nothing cluster
Server unabhängig voneinander
inkrementell
geﬁltert
N-Master, Master-Slave, P2P, eigene Cloud,. . .
Hot failover, backup, Lastverteilung,. . .
extrem robust
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: Fehlermeldung
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
Dokument eines Blogposts
http://localhost:5984/simple_blog/
17cf8a2934231a6cedc9e30fd30045a7
View
http://localhost:5984/simple_blog/_design/
by-date/_view/blogposts-by-date
http://localhost:
5984/_utils/database.html?simple_blog/_design/
by-date/_view/blogposts-by-date
Query: Blogpost vom 12. April 2010
by-date/_view/blogposts-by-date?key=[2010,4,12]
Query: Blogposts aus März 2010
by-date/_view/blogposts-by-date?startkey=[2010,
3,0]&endkey=[2010,3,31]

View
Beispiel

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


View
Beispiel

View mit Schlüssel Datum und Wert Titel des Blogposts, Rohansicht


Map Reduce
View erzeugen

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

Designdokument (map-Funktion)
http://localhost:
5984/simple_blog/_design/by-date
Designdokument (map und reduce)
http://localhost:
5984/simple_blog/_design/per-date
View
per-date/_view/posts-per-date
http://localhost:
5984/_utils/database.html?simple_blog/_design/
per-date/_view/posts-per-date
Gruppiert
per-date/_view/posts-per-date?group_level=1

Designdokument
Beispiel

Designdokument mit map-Funktion


Designdokument
Beispiel

Designdokument mit map- und reduce-Funktionen


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


Beispiel Show Functions

Design Dokument (Show)
http://localhost:
5984/kontaktdaten/_design/output
Dokument anzeigen
http://localhost:
5984/kontaktdaten/_design/output/_show/card/
69a87107057813de1414e08a9f000912


Designdokument
Beispiel

Designdokument mit show-Funktion


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 Protokolle & APIs

4 Datenmodelle

5 CouchDB


7 Praxisbeispiel


Herausforderungen und Kritik

HTML/JS, HTTP,. . .
vorhandene Probleme bleiben bestehen
kein ad hoc reporting
BASE vs. ACID
Zuverlässigkeit z.B. bei Finanztransaktionen
Zweifel an der Geschwindigkeit
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


Übersicht

1 Einführung


3 Protokolle & APIs

4 Datenmodelle

5 CouchDB


7 Praxisbeispiel


Einfache Bloganwendung
ER-Diagramm


Relationes Schema

Tabelle Posts mit Spalten
post_id, Titel, Text, user, Datum
Tabelle Kommentare mit Spalten
comment_id, Text, user, Datum, post_id
foreign key constraint
Kommentare.post_id, Posts.post_id


ER-Diagramm

Dokumentenorientierter Ansatz?


Blogpost ohne Kommentare

http://localhost:
5984/blog0/cc50e8668ff421c1c09be1b71000077a


Blogpost ohne Kommentare


Blogpost mit Kommentare “inline”


Kommentar als eigenes Dokument



View zur Ausgabe von Posts mit zugehörigen Kommentaren
zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw.
Kommentar
map-Funktion

function(doc) {
if (doc.type == "post") {
emit([doc._id, 0], doc);
} else if (doc.type == "comment") {
emit([doc.post_id, 1], doc);
}
}



View zur Ausgabe von Posts mit zugehörigen Kommentaren
zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw.
Kommentar


Blogposts und Kommentare

Kommentare “inline”
Direkter Zugriff auf Kommentare durch geeigneten View
Vorteil: alles beisammen, beim Löschen des Posts werden alle
Kommentare mit gelöscht,. . .
Nachteil: jeder neue Kommentar ist ein Update des Posts; bei
vielen Kommentaren Konﬂikte wahrscheinlich
Alternative: Kommentare in eigenen Dokumenten
Gemeinsame Ausgabe eines Posts und seiner Kommetare durch
geeigeneten View


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.


Not only SQL - CouchDB und andere NoSQL-Datenbanken

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Not only SQL - CouchDB und andere NoSQL-Datenbanken

Similaire à Not only SQL - CouchDB und andere NoSQL-Datenbanken (20)

Not only SQL - CouchDB und andere NoSQL-Datenbanken