Das Dokument bietet eine umfassende Einführung in NoSQL-Datenbanken, insbesondere CouchDB, und beschreibt deren Entwicklung, Struktur und Vorteile gegenüber traditionellen relationalen Datenbanken. Es hebt die Vielseitigkeit und Anpassungsfähigkeit von NoSQL-Systemen hervor, die es ermöglichen, verschiedene Datenspeicher zu kombinieren, um spezifische Anforderungen zu erfüllen. Darüber hinaus werden die Herausforderungen und Kritikpunkte an der Verwendung von NoSQL vorgestellt, einschließlich der Probleme bei Ad-hoc-Berichten und der Notwendigkeit serverseitiger Logik für Authentifizierung.

1. NoSQL und CouchDB
Dr. Kerstin Puschke
Mai 2010
K. Puschke () NoSQL Mai 2010 1 / 30

2. Lizenz
Lizenz
Dieser Text steht unter einer Creative Commons
Attribution 3.0 Germany Lizenz, siehe
http://creativecommons.org/licenses/by/3.0/de/
K. Puschke () NoSQL Mai 2010 2 / 30

3. 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 () NoSQL Mai 2010 3 / 30

4. NoSQL
Begriffsklärung
no:sql(eu) conference. http://www.nosqleu.com, April 2010
. . . era of “one-size-fits-all database” seems to be over.
K. Puschke () NoSQL Mai 2010 4 / 30

5. NoSQL
Begriffsklärung
no:sql(eu) conference. http://www.nosqleu.com, April 2010
. . . 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.
K. Puschke () NoSQL Mai 2010 4 / 30

6. NoSQL
Begriffsklärung
no:sql(eu) conference. http://www.nosqleu.com, April 2010
. . . 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 () NoSQL Mai 2010 4 / 30

7. 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 () NoSQL Mai 2010 5 / 30

8. (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 () NoSQL Mai 2010 6 / 30

9. Abfragen
Web vs. RDBMS
RDBM
dynamische Abfragen (ad hoc reporting)
beliebige Abfragen über alle Daten direkt in SQL
Abfrage-Optimierung oft erforderlich
Webanwendungen
wiederkehrende Abfragen, nur Parameter ändern sich
K. Puschke () NoSQL Mai 2010 7 / 30

10. Verteiltes Arbeiten
Skalierbarkeit
Hochverfügbarkeit
RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt
Problem: Fallacies of Distributed Computing
K. Puschke () NoSQL Mai 2010 8 / 30

11. 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!
K. Puschke () NoSQL Mai 2010 9 / 30

12. CAP Theorem
Anwendung
Availability & Consistency: Paxos, BigTable . . .
Consistency & Partition Tolerance: viele RDBMS, . . .
ACID (atomicity, consistency, isolation, durability)
Availability & Partition Tolerance: CouchDB, MongoDB,
Cassandra, Dynamo,. . .
BASE (basically available, soft-state, eventual consistency)
K. Puschke () NoSQL Mai 2010 10 / 30

13. Relationales Modell
striktes Schema
zeilenorientierte Speicherung
’echte’ Beziehungen zwischen Daten
foreign key constraints, joins. . .
K. Puschke () NoSQL Mai 2010 11 / 30

14. Spaltenorientierung
Cassandra, BigTable,. . .
spaltenorientierte Speicherung
mehr Performanz für bestimmte Abfragen
z.B. Aggregieren innerhalb einer Spalte
flexibleres Schema
keine ’echten’ Beziehungen
K. Puschke () NoSQL Mai 2010 12 / 30

15. 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}
verschiedene keys können verschiedene columns haben
K. Puschke () NoSQL Mai 2010 13 / 30

16. Objektorientierung
Persistenzschicht für Objektorientierte Programmierung
Abfragen in objektorientierter Programmiersprache
OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene
Sprache
db4o, JADE, Databeans,. . .
K. Puschke () NoSQL Mai 2010 14 / 30

17. Graphen
Graphen im Sinne der Mathematik
Knoten und Kanten
modellieren z.B. Netzwerk, Leitungssystem,. . .
Spezialfall: Baum
z.B. Produktkategorien (Eltern-Kind-Beziehung)
K. Puschke () NoSQL Mai 2010 15 / 30

18. 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”
gut geeignet für komplexe Beziehungsgeflechte
z.B. social network
K. Puschke () NoSQL Mai 2010 16 / 30

19. Schlüssel-Wert-Paare
Riak, Tokyo Cabinet,. . .
Schlüssel-Wert-Paare
Abfrage per Schlüssel
schemafrei
keine ’echten’ Relationen
K. Puschke () NoSQL Mai 2010 17 / 30

20. 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,. . . )
schemafrei
keine ’echten’ Relationen
K. Puschke () NoSQL Mai 2010 18 / 30

21. CouchDB’s Datenmodell
Format: JavaScript Object Notation (JSON)
Bestandteil von JavaScript
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 () NoSQL Mai 2010 19 / 30

22. Was ist CouchDB?
Cluster Of Unreliable Commodity Hardware DataBase
Datenbankcluster auf unzuverlässiger Standardhardware
Datenbanksystem (nicht nur) für Webanwendungen
offene Webstandards
Robuste Replikation
verteiltes Arbeiten ohne Fallacies of Distributed Computing
schemafrei
geeignet für unstrukturierte Daten
K. Puschke () NoSQL Mai 2010 20 / 30

23. Implementierung
Überblick
HTTP/REST (Webserver enthalten)
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
K. Puschke () NoSQL Mai 2010 21 / 30

24. Updates
neue Version eines Dokumentes wird an Datenbankdatei
angehängt
keine diffs, keine partiellen updates
Robust: was einmal auf Platte steht, wird nicht mehr angefaßt
serialisierte Schreibzugriffe (pro Datenbank)
Geschwindigkeit: neue Version kann angehängt werden, während
alte noch gelesen wird
MVCC
K. Puschke () NoSQL Mai 2010 22 / 30

25. 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 () NoSQL Mai 2010 23 / 30

26. MapReduce
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
MapReduce-Funktionen gespeichert in Dokumenten
(Designdokumente)
K. Puschke () NoSQL Mai 2010 24 / 30

27. Design Documents
CouchDB-Dokumente
_id beginnt mit _design
enthalten Anwendungscode, sprich Funktionen
MapReduce-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 () NoSQL Mai 2010 25 / 30

28. Webanwendungen mit CouchDB
Klassische Webanwendungen
Serverseitige Skripte lesen Daten aus CouchDB
erzeugen daraus dynamisch HTML
Webserver liefert aus
K. Puschke () NoSQL Mai 2010 26 / 30

29. 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 () NoSQL Mai 2010 27 / 30

30. 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 () NoSQL Mai 2010 28 / 30

31. Desktop-Anwendungen
Beispiel: Synchronisation von Anwendungsdaten
bereits realisiert in Ubuntu
Bookmarks, Adreßbuch,. . . in CouchDB speichern
per Replikation mit anderen Rechnern synchronisieren
K. Puschke () NoSQL Mai 2010 29 / 30

32. Herausforderungen und Kritik
HTML/JS, HTTP,. . .
vorhandene Probleme bleiben bestehen
kein ad hoc reporting
BASE vs. ACID
Zweifel an der Geschwindigkeit?
CouchApps und Co: Verteilte Identitäten
serverseitiger Code nötig für Authentifizierung/Autorisierung
vertrauenswürdiger Server nötig
K. Puschke () NoSQL Mai 2010 30 / 30