Das Dokument behandelt NoSQL-Datenbanken mit Fokus auf CouchDB und diskutiert deren Vorteile gegenüber relationalen Datenbankmodellen sowie Einsatzmöglichkeiten und -anforderungen. Es werden verschiedene Datenmodelle, Herausforderungen und Prinzipien, wie das CAP-Theorem, erläutert sowie die Architektur und Funktionsweise von CouchDB beschrieben. Abschließend werden konkrete Anwendungsfälle von NoSQL-Systemen vorgestellt.

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

2. Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 2 / 55

3. Übersicht
1 Einführung
Relationale Datenbanksysteme
Weitere Datenbanksysteme
NoSQL
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 3 / 55

4. 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,. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55

5. 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?
K. Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55

6. NoSQL
Begriffsklärung
2009 als Sammelbegriff für bereits länger existierende Systeme
etabliert
Not only SQL
keine eindeutige Definition
nicht-relationale Datenspeicher
K. Puschke (FU Berlin) NoSQL 13. September 2010 6 / 55

7. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 7 / 55

8. NoSQL
Begriffsklärung
Ankündigung no:sql(eu) conference, April 2010 [11]
. . . era of “one-size-fits-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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 8 / 55

9. 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)
...
K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55

10. Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
Web vs. RDBMS
Verteilte Systeme
NoSQL vs. SQL
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 10 / 55

11. (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
K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55

12. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 12 / 55

13. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55

14. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55

15. 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]
K. Puschke (FU Berlin) NoSQL 13. September 2010 14 / 55

16. C,A oder P?
abhängig vom gewählten DBMS
abhängig vom Setup
abhängig von der Konfiguration - u.U. sogar pro Abfrage
Network Partitioning oft unvermeidlich
trade off: Consistency vs. Availability
Abstufungen möglich
K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55

17. CAP Theorem
Häufige 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)
K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55

18. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55

19. Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
Spaltenorientierung
Objektorientierung
Graphen
Schlüssel-Wert-Paare
Dokumentenorientierung
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 18 / 55

20. Relationales Modell
striktes Schema
Tabellen und Spalten statisch
zeilenorientierte Speicherung
’echte’ Beziehungen zwischen Daten
foreign key constraints, joins. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 19 / 55

21. Spaltenorientierung
erste spaltenorientierte Datenbanken in den 1970ern
Cassandra, BigTable,. . .
spaltenorientierte Speicherung
mehr Performanz für bestimmte Abfragen
z.B. Aggregieren innerhalb einer Spalte
flexibleres Schema
Spalten dynamisch
keine ’echten’ Beziehungen
K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55

22. 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
identifiziert 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}
K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55

23. 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
}
K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55

24. Objektorientierung
Persistenzschicht für Objektorientierte Programmierung
Abfragen in objektorientierter Programmiersprache
OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene
Sprache
db4o, JADE, Databeans,. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 23 / 55

25. Graphen
Graphen im Sinne der Mathematik
Knoten und Kanten
modellieren z.B. Netzwerk, Leitungssystem,. . .
Spezialfall: Baum
z.B. Produktkategorien (Eltern-Kind-Beziehung)
K. Puschke (FU Berlin) NoSQL 13. September 2010 24 / 55

26. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55

27. Schlüssel-Wert-Paare
Riak, Tokyo Cabinet,. . .
Schlüssel-Wert-Paare
Abfrage per Schlüssel
schemafrei
keine ’echten’ Relationen
K. Puschke (FU Berlin) NoSQL 13. September 2010 26 / 55

28. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55

29. 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
Schlüssel-Wert-Paare
obligatorische Schlüssel:
_id zur eindeutigen Identifikation des Dokumentes (UUID),
_rev zur Versionierung des Dokumentes
Dokumente können Attachments haben
K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55

30. CouchDB Dokument
JSON
K. Puschke (FU Berlin) NoSQL 13. September 2010 29 / 55

31. Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
Implementierung
Updates and Concurrency
Abfragen
Design Documents
Anwendungen
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 30 / 55

32. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55

33. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55

34. Replikation
shared nothing cluster
Server unabhängig voneinander
inkrementell
gefiltert
N-Master, Master-Slave,. . .
Hot failover, backup, Lastverteilung,. . .
extrem robust
vermeidet die Fallacies of Distributed Computing
ggf. manuell Konflikte lösen
K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55

35. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 34 / 55

36. 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: Konflikt
keine Versionskontrolle
es werden nicht alle Versionen aufbewahrt
K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55

37. 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
effizientes Abfragen nach bestimmten Schlüsseln oder Bereichen
von Schlüsseln
’Titel aller Blogposts von Mai 2009’
zur Abfragezeit erzeugt/aktualisiert durch MapReduce
K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55

38. View
Beispiel
View mit Schlüssel Datum und Wert Titel des Blogposts, dargestellt in
Futon
K. Puschke (FU Berlin) NoSQL 13. September 2010 37 / 55

39. 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)
K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55

40. View
Beispiel
View ohne reduce
K. Puschke (FU Berlin) NoSQL 13. September 2010 39 / 55

41. View
Beispiel
View mit reduce
View mit reduce und group_level=2
K. Puschke (FU Berlin) NoSQL 13. September 2010 40 / 55

42. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55

43. Webanwendungen mit CouchDB
Klassische Webanwendungen
Serverseitige Skripte lesen Daten aus CouchDB
erzeugen daraus dynamisch HTML
Webserver liefert aus
K. Puschke (FU Berlin) NoSQL 13. September 2010 42 / 55

44. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55

45. 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
K. Puschke (FU Berlin) NoSQL 13. September 2010 44 / 55

46. Desktop-Anwendungen
Beispiel: Synchronisation von Anwendungsdaten
bereits realisiert in Ubuntu
Bookmarks, Adreßbuch,. . . in CouchDB speichern
per Replikation mit anderen Rechnern synchronisieren
K. Puschke (FU Berlin) NoSQL 13. September 2010 45 / 55

47. Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 46 / 55

48. 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 Authentifizierung/Autorisierung
vertrauenswürdiger Server nötig
K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55

49. Noch Fragen?
Vielen Dank für Ihre Aufmerksamkeit!
Fragen und Anmerkungen?
K. Puschke (FU Berlin) NoSQL 13. September 2010 48 / 55

50. Referenzen I
J. Chris Anderson, Jan Lehnardt, and Noah Slater.
CouchDB: The definitive 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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 49 / 55

51. 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: Simplified data processing on large clusters.
In Sixth Symposium on Operating System Design and
Implementation. 2004.
URL http://labs.google.com/papers/mapreduce.html.
K. Puschke (FU Berlin) NoSQL 13. September 2010 50 / 55

52. 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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 51 / 55

53. 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/.
K. Puschke (FU Berlin) NoSQL 13. September 2010 52 / 55

54. 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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 53 / 55

55. 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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 54 / 55

56. Referenzen VII
Stefan Tilkov.
A brief introduction to rest.
Info Queue, 2007.
URL
http://www.infoq.com/articles/rest-introduction.
K. Puschke (FU Berlin) NoSQL 13. September 2010 55 / 55