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/


NoSQLBegriffsklärung

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



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.




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




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


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


(Un)strukturierte DatenWeb vs. RDBMS

RDBMSDatenbankschema entscheidend

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

stark strukturiert

Webanwendungenuser generated content

unstrukturierte Daten


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


Verteiltes Arbeiten

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


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!


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)


Relationales Modell

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


Spaltenorientierung

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


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


Objektorientierung

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


Graphen

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


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


Schlüssel-Wert-Paare

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


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


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


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


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


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


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


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)


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


Webanwendungen mit CouchDBKlassische Webanwendungen

Serverseitige Skripte lesen Daten aus CouchDBerzeugen daraus dynamisch HTMLWebserver liefert aus


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


Dezentrale offline WebanwendungEin Usecase für CouchApps

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


Desktop-Anwendungen

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


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


NoSQL und CouchDB

Technology

Transcript of NoSQL und CouchDB