NoSQL-Datenbanken am Beispiel CouchDB

NoSQL-Datenbankenam Beispiel CouchDB

Dr. Kerstin Puschke

Freie Universität Berlin

13. September 2010

K. Puschke (FU Berlin) NoSQL 13. September 2010 1 / 55

Übersicht

1 Einführung

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

3 Datenmodelle

4 CouchDB

5 Herausforderungen und Kritik


Übersicht

1 EinführungRelationale DatenbanksystemeWeitere DatenbanksystemeNoSQL


3 Datenmodelle

4 CouchDB



Relationale Datenbanksysteme

in der TheorieCodd (1970) [3]

Codd’s 12 Regeln (1985) [4, 5]

Vollständigkeit im Sinne der relationalen Algebrain der Praxis und im Kontext des Vortrags

zeilenbasierte Speicherung in TabellenSQL oder vergleichbare Sprachez.B. MySQL, Postgres, Oracle,. . .


Weitere Datenbanksysteme

Objektdatenbanken (db4o)XMLSpeicherung als Schlüssel-Wert-Paare (BerkeleyDB)spaltenorientierte Systeme (Sybase IQ)dokumentenorientierte Systeme (Lotus Notes)kaum Verbreitung im Vergleich zu relationalen Systemenfrühe Formen von NoSQL?


NoSQLBegriffsklärung

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


NoSQLWas NoSQL manchmal (nicht) ist

Verteiltes_ArbeitenSkalierbarkeit Schemafreiheit

Geschwindigkeit Open_Source Open_StandardsGroße_Datenmengen

Aufgabe_der_ACID-Prinzipien Einfache_BenutzungFehlertoleranz Concurrency Durchsatz

Zuverlässigkeit


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


Übersicht

1 Einführung

2 Why Not Only SQL - warum nicht immer SQL einsetzen?Web vs. RDBMSVerteilte SystemeNoSQL vs. SQL

3 Datenmodelle

4 CouchDB



(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

RDBMSdynamische Abfragen (ad hoc reporting)beliebige Abfragen über alle Daten direkt in SQL

Webanwendungenwiederkehrende Abfragen, nur Parameter ändern sich


Verteiltes Arbeiten

Skalierbarkeitgroße Datenmengenfrüher: nur Großrechner; Anfrageoptimierung statt Rechenleistungheute: preiswerte Hardware ergänzen (auch via cloud)

HochverfügbarkeitRDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt


Verteiltes Arbeiten

Skalierbarkeitgroße Datenmengen

The largest BigTable instance manages about 6 petabytes of dataspread across thousands of machinesJeff Dean, Google I/O conference, Mai 2008 (Shankland [14])

früher: nur Großrechner; Anfrageoptimierung statt Rechenleistungheute: preiswerte Hardware ergänzen (auch via cloud)

HochverfügbarkeitRDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt


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!siehe Brewer [2] und Lynch & Gilbert [10]


C,A oder P?

abhängig vom gewählten DBMSabhängig vom Setupabhängig von der Konfiguration - u.U. sogar pro AbfrageNetwork Partitioning oft unvermeidlichtrade off: Consistency vs. AvailabilityAbstufungen möglich


CAP TheoremHäufige Settings

Availability & Consistency: VoltDB, BigTable . . .Consistency & Partition Tolerance: viele RDBMS, . . .

Strong Consistency, Enforced ConsistencyACID (atomicity, consistency, isolation, durability)siehe Gray [7] und Haerder & Reuter [8]

pessimistic lockingAvailability & Partition Tolerance: CouchDB, MongoDB,Cassandra, Dynamo,. . .

Weak Consistency, Eventual ConsistencyBASE (basically available, soft-state, eventual consistency)siehe Pritchett [13]

optimistic locking, multi-version concurrency control (MVCC)


NoSQL vs. SQL

Nachteile auch in RDBMS vermeidbar, z.B. durchVerzicht auf NormalisierungFokus 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


Übersicht

1 Einführung


3 DatenmodelleSpaltenorientierungObjektorientierungGraphenSchlüssel-Wert-PaareDokumentenorientierung

4 CouchDB



Relationales Modell

striktes SchemaTabellen und Spalten statischzeilenorientierte Speicherung’echte’ Beziehungen zwischen Datenforeign key constraints, joins. . .


Spaltenorientierung

erste spaltenorientierte Datenbanken in den 1970ernCassandra, BigTable,. . .spaltenorientierte Speicherungmehr Performanz für bestimmte Abfragenz.B. Aggregieren innerhalb einer Spalteflexibleres SchemaSpalten dynamischkeine ’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}


Cassandra’s DatenmodellVereinfachte Darstellung

verschiedene keys können verschiedene columns habenkein striktes Schema

BeispielAbfrage (:Users, 42){

username : foo,email : [email protected],screen_name : FOOOOO}Abfrage (:Users, 23){

username : bar,admin : yes}


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”häufige Operation: Traversierunggut 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,. . .Dokument: weitere Abstraktionsebene oberhalb vonSchlüssel-Wert-Paarenfür sich genommen sinnvolle Informationseinheitmeist Entsprechung im Real Life (Rechnung, Visitenkarte,. . . )üblicherweise kein leeren Felderschemafreikeine ’echten’ Relationen


CouchDB’s Datenmodell

Format: JavaScript Object Notation (JSON)Bestandteil von JavaScriptwird z.T. direkt vom Browser verstandenwenig Datentypendiese werden von nahezu allen Sprachen verstandenSchlüssel-Wert-Paareobligatorische Schlüssel:

_id zur eindeutigen Identifikation des Dokumentes (UUID),_rev zur Versionierung des Dokumentes

Dokumente können Attachments haben


CouchDB DokumentJSON


Übersicht

1 Einführung


3 Datenmodelle

4 CouchDBImplementierungUpdates and ConcurrencyAbfragenDesign DocumentsAnwendungen



Was ist CouchDB?

Cluster Of Unreliable Commodity Hardware DataBaseDatenbankcluster auf unzuverlässiger StandardhardwareDatenbanksystem (nicht nur) für Webanwendungenoffene WebstandardsRobuste Replikationschemafreigeeignet für unstrukturierte DatenPhilosophie: entspanntes Arbeitenkeine Entscheidungen, die nicht zu revidieren sind


ImplementierungÜberblick

HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov [16]

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: ACID (lokal), optimistic locking,Multi Version Concurrency Control


Replikation

shared nothing clusterServer unabhängig voneinanderinkrementellgefiltertN-Master, Master-Slave,. . .Hot failover, backup, Lastverteilung,. . .extrem robustvermeidet die Fallacies of Distributed Computingggf. manuell Konflikte lösen


Updates

komplettes Dokument abholen, verändern, zum Speichernzurücksendenneue Version eines Dokumentes wird an DatenbankdateiangehängtRobust: was einmal auf Platte steht, wird nicht mehr angefaßtGeschwindigkeit: neue Version kann angehängt werden, währendalte noch gelesen wird


Multi Version Concurrency Control

optimistic lockingClient schickt verändertes Dokument mit unveränderterVersionsnummer _revServer prüft, ob diese _rev identisch ist mit der aktuellgespeichertenwenn ja: Dokument wird gespeichert (Server vergibt neue _rev)wenn nein: Konflikt

keine Versionskontrollees 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 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


ViewBeispiel

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


Map ReduceView erzeugen

map und reduce Funktionen: Konzept aus der funktionalenProgrammierungparallele Verarbeitung großer DatenmengenMapReduce: framework zur verteilten Verarbeitung großerDatenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6]

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

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


ViewBeispiel

View ohne reduce


ViewBeispiel

View mit reduce

View mit reduce und group_level=2


Design Documents

_id beginnt mit _designenthalten Anwendungscode, sprich Funktionen

Map-Reduce-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


Übersicht

1 Einführung


3 Datenmodelle

4 CouchDB



Herausforderungen und Kritik

HTML/JS, HTTP,. . .vorhandene Probleme bleiben bestehenkein ad hoc reportingBASE vs. ACIDZuverlässigkeit z.B. bei FinanztransaktionenZweifel am Geschwindigkeitsvorteil von NoSQL-SystemenStonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12]

CouchApps und Co: Verteilte Identitätenserverseitiger Code nötig für Authentifizierung/Autorisierungvertrauenswürdiger Server nötig


Noch Fragen?

Vielen Dank für Ihre Aufmerksamkeit!

Fragen und Anmerkungen?


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.


http://books.couchdb.org/relax/

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

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 andImplementation. 2004.URL http://labs.google.com/papers/mapreduce.html.


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


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


http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf

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


http://database.cs.brown.edu/sigmod09/benchmarks-sigmod09.pdf

http://database.cs.brown.edu/sigmod09/benchmarks-sigmod09.pdf

http://queue.acm.org/detail.cfm?id=1394128

Referenzen VI

Stephen Shankland.Google spotlights data center inner workings.cnet news, Mai 2008.URLhttp://news.cnet.com/8301-10784_3-9955184-7.html.

Michael Stonebraker, Daniel Abadi, David J. DeWitt, SamMadden, 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.


http://news.cnet.com/8301-10784_3-9955184-7.html

http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf

http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf

Referenzen VII

Stefan Tilkov.A brief introduction to rest.Info Queue, 2007.URLhttp://www.infoq.com/articles/rest-introduction.


http://www.infoq.com/articles/rest-introduction

NoSQL-Datenbanken am Beispiel CouchDB

Technology

Transcript of NoSQL-Datenbanken am Beispiel CouchDB