nosql und couchdb

NoSQL und CouchDB

Dr. Kerstin Puschke

Mai 2010

K. Puschke () NoSQL Mai 2010 1 / 30

Lizenz

LizenzDieser Text steht unter einer Creative CommonsAttribution 3.0 Germany Lizenz, siehehttp://creativecommons.org/licenses/by/3.0/de/

K. Puschke () NoSQL Mai 2010 2 / 30

NoSQLBegriffsklärung

2009 als Sammelbegriff für bereits länger existierende SystemeetabliertNot only SQLkeine eindeutige Definitionnicht-relationale Datenspeicher

K. Puschke () NoSQL Mai 2010 3 / 30

NoSQLBegriffsklä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 thefuture is about choosing a data store that best matches yourdata set and operational requirements. It’s a future ofheterogeneous data backends, polyglot persistence andchoosing Not Only SQL but sometimes also a documentdatabase, a key-value store or a graph database.

K. Puschke () NoSQL Mai 2010 4 / 30

NoSQLBegriffsklä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 thefuture is about choosing a data store that best matches yourdata set and operational requirements.

It’s a future ofheterogeneous data backends, polyglot persistence andchoosing Not Only SQL but sometimes also a documentdatabase, a key-value store or a graph database.

K. Puschke () NoSQL Mai 2010 4 / 30

NoSQLBegriffsklä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 thefuture is about choosing a data store that best matches yourdata set and operational requirements. It’s a future ofheterogeneous data backends, polyglot persistence andchoosing Not Only SQL but sometimes also a documentdatabase, a key-value store or a graph database.

K. Puschke () NoSQL Mai 2010 4 / 30

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

(Un)strukturierte DatenWeb vs. RDBMS

RDBMSDatenbankschema entscheidend

aufwändig zu entwerfen: Normalisierung,. . .nachträglich schwierig zu ändern

stark strukturiert

Webanwendungenuser generated content

unstrukturierte Daten

K. Puschke () NoSQL Mai 2010 6 / 30

AbfragenWeb vs. RDBMS

RDBMdynamische Abfragen (ad hoc reporting)beliebige Abfragen über alle Daten direkt in SQLAbfrage-Optimierung oft erforderlich

Webanwendungenwiederkehrende Abfragen, nur Parameter ändern sich

K. Puschke () NoSQL Mai 2010 7 / 30

Verteiltes Arbeiten

SkalierbarkeitHochverfügbarkeitRDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügtProblem: Fallacies of Distributed Computing

K. Puschke () NoSQL Mai 2010 8 / 30

CAP TheoremConsistency, Availability, Partition Tolerance

TheoremConsistencyDer Client glaubt, eine Menge von Operationen sei auf einenSchlag passiert: Alle Clients sehen dieselben Daten.AvailabilityJede Operation endet mit einer bestimmungsgemäßen Antwort:Alle Clients können auf eine Version der Daten zugreifen.Partition ToleranceOperationen werden zu Ende geführt, auch wenn die Datenbankpartitioniert ist.

Nur zwei der drei Eigenschaften sind gleichzeitig möglich!

K. Puschke () NoSQL Mai 2010 9 / 30

CAP TheoremAnwendung

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

Relationales Modell

striktes Schemazeilenorientierte Speicherung’echte’ Beziehungen zwischen Datenforeign key constraints, joins. . .

K. Puschke () NoSQL Mai 2010 11 / 30

Spaltenorientierung

Cassandra, BigTable,. . .spaltenorientierte Speicherungmehr Performanz für bestimmte Abfragenz.B. Aggregieren innerhalb einer Spalteflexibleres Schemakeine ’echten’ Beziehungen

K. Puschke () NoSQL Mai 2010 12 / 30

Cassandra’s DatenmodellVereinfachte Darstellung

keyspaceentspricht der Anwendung; Beispiel: ’Blog’

column familyentspricht einer DateiBeispiel: ’Posts’ oder ’Users’beliebig viele Einträge (key + columns)

keyidentifiziert einen Eintrag in der column familywird bei Abfragen benutztkeys sind lokalgleichnamige keys verschiedener column families sind verschiedenkeine ’echten’ Beziehungen

columntupel (name, value, timestamp)Beispiel: {name:username, value:foo, timestamp:12345}verschiedene keys können verschiedene columns haben

K. Puschke () NoSQL Mai 2010 13 / 30

Objektorientierung

Persistenzschicht für Objektorientierte ProgrammierungAbfragen in objektorientierter ProgrammierspracheOO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigeneSprachedb4o, JADE, Databeans,. . .

K. Puschke () NoSQL Mai 2010 14 / 30

Graphen

Graphen im Sinne der MathematikKnoten und Kantenmodellieren z.B. Netzwerk, Leitungssystem,. . .Spezialfall: Baumz.B. Produktkategorien (Eltern-Kind-Beziehung)

K. Puschke () NoSQL Mai 2010 15 / 30

Graphendatenbanken

InfoGrid, neo4j, . . .Daten als Graphen

Knoteneigenständige Objekte wie Kunde, Bestellung,. . .Kanten sind Beziehungen zwischen Knoten

schematisiert oder schemafreiKanten sind “first class objects”gut geeignet für komplexe Beziehungsgeflechtez.B. social network

K. Puschke () NoSQL Mai 2010 16 / 30

Schlüssel-Wert-Paare

Riak, Tokyo Cabinet,. . .Schlüssel-Wert-PaareAbfrage per Schlüsselschemafreikeine ’echten’ Relationen

K. Puschke () NoSQL Mai 2010 17 / 30

Dokumentenorientierung

CouchDB, MongoDB, Riak, XML-Datenbanken. . .Dokument: weitere Abstraktionsebene oberhalb vonSchlüssel-Wert-Paarenfür sich genommen sinnvolle Informationseinheitmeist Entsprechung im Real Life (Rechnung, Visitenkarte,. . . )schemafreikeine ’echten’ Relationen

K. Puschke () NoSQL Mai 2010 18 / 30

CouchDB’s Datenmodell

Format: JavaScript Object Notation (JSON)Bestandteil von JavaScriptSchlüssel-Wert-Paareobligatorische 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

Was ist CouchDB?

Cluster Of Unreliable Commodity Hardware DataBaseDatenbankcluster auf unzuverlässiger StandardhardwareDatenbanksystem (nicht nur) für Webanwendungenoffene WebstandardsRobuste Replikationverteiltes Arbeiten ohne Fallacies of Distributed Computingschemafreigeeignet für unstrukturierte Daten

K. Puschke () NoSQL Mai 2010 20 / 30

ImplementierungÜberblick

HTTP/REST (Webserver enthalten)Erlangfunktional, fehlertolerant, concurrency optimiertViewserver in JavaScript (Indizes erstellen)alternativ via Plugins auch PHP, Ruby, Python, Perl, CommonLisp, Erlang,. . .dokumentenbasierte Speicherung (JSON)Datenbank und Indizes als B-Tree gespeicherteventual consistency (in verteilten Systemen)Storage Engine: ACIDoptimistic locking, Multi Version Concurrency Control

K. Puschke () NoSQL Mai 2010 21 / 30

Updates

neue Version eines Dokumentes wird an Datenbankdateiangehängtkeine diffs, keine partiellen updatesRobust: was einmal auf Platte steht, wird nicht mehr angefaßtserialisierte Schreibzugriffe (pro Datenbank)Geschwindigkeit: neue Version kann angehängt werden, währendalte noch gelesen wirdMVCC

K. Puschke () NoSQL Mai 2010 22 / 30

View

(secondary) Index (Schlüssel-Wert-Paare)Schlüssel und Werte des Views sind Werte aus Dokumenten

Beispiel: Erstellungsdaten als Schlüssel, Blogposttitel als Wertekönnen auch arrays von Werten (aus Dokumenten) seinWerte (im View) können auch aggregierte Werte (aus Dokumenten)sein

sortiert nach Schlüsselneffizientes Abfragen nach bestimmten Schlüsseln oder Bereichenvon Schlüsseln’Titel aller Blogposts von Mai 2009’zur Abfragezeit erzeugt/aktualisiert durch MapReduce

K. Puschke () NoSQL Mai 2010 23 / 30

MapReduceView erzeugen

map verarbeitet Dokumenteerzeugt Schlüssel-Wert-Paareoptionales reduce erzeugt aggregierte (Zwischen)Werteverarbeitet Ergebnisse von map oder rekursivZwischenergebnisse von reduce

group: anwenden auf Objekte mit gleichem SchlüsselBeispiel: nicht alle Blogposts zählen, sondern Blogposts pro TagMapReduce-Funktionen gespeichert in Dokumenten(Designdokumente)

K. Puschke () NoSQL Mai 2010 24 / 30

Design Documents

CouchDB-Dokumente_id beginnt mit _designenthalten Anwendungscode, sprich Funktionen

MapReduce-Funktionen für ViewsValidation: Zulässigkeit von Updatesinput prüfen, nur eingeloggte user,. . .serverseitige Bearbeitung vor dem Speichern eines DokumentesShow/List: JSON in HTML, XML,. . . konvertieren

K. Puschke () NoSQL Mai 2010 25 / 30

Webanwendungen mit CouchDBKlassische Webanwendungen

Serverseitige Skripte lesen Daten aus CouchDBerzeugen daraus dynamisch HTMLWebserver liefert aus

K. Puschke () NoSQL Mai 2010 26 / 30

Webanwendungen mit CouchDBCouchApps

leben vollständig in der Datenbankkeine middlewareShow/List-FunktionenAttachments (HTML,CSS, Javascript) direkt ausliefernAusgelieferte Webseite greift per Javascript/HTTP auf CouchDBzuReplikation: update, fork, backup von Anwendungen

K. Puschke () NoSQL Mai 2010 27 / 30

Dezentrale offline WebanwendungEin Usecase für CouchApps

Daten und Anwendung lokal beim useroffline verfügbarlokale Datenhaltung = niedrige Latenzdezentral(gefilterte) Replikation mit anderen usern

K. Puschke () NoSQL Mai 2010 28 / 30

Desktop-Anwendungen

Beispiel: Synchronisation von Anwendungsdatenbereits realisiert in UbuntuBookmarks, Adreßbuch,. . . in CouchDB speichernper Replikation mit anderen Rechnern synchronisieren

K. Puschke () NoSQL Mai 2010 29 / 30

Herausforderungen und Kritik

HTML/JS, HTTP,. . .vorhandene Probleme bleiben bestehenkein ad hoc reportingBASE vs. ACIDZweifel an der Geschwindigkeit?CouchApps und Co: Verteilte Identitäten

serverseitiger Code nötig für Authentifizierung/Autorisierungvertrauenswürdiger Server nötig

K. Puschke () NoSQL Mai 2010 30 / 30