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 : foo@example.com,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

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

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.

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.

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

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.

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.

Referenzen VII

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

NoSQL-Datenbanken am Beispiel CouchDB

Technology

Transcript of NoSQL-Datenbanken am Beispiel CouchDB

CouchDB and Usage in Primero - d2wakvpiukf49j.cloudfront.net · CouchDB And Its Usage In Primero. What is CouchDB? NoSQL Database No hard schema like a traditional SQL database Data

NoSQL - Der neue Königsweg für Datenbanken?

Vorstellung der verteilten NoSQL Datenbank CouchDB · PDF file06. Okt 2009 CouchDB (Karl Glatz) 3 / 36 Web Anwendung (AJAX) Web Browser CouchDB Java Script HTTP RESTful (GET/POST)

Bases de Datos No Relacionales (NoSQL): Cassandra, CouchDB, MongoDB y Neo4j

7. Big Data und NoSQL-Datenbanken · SS18, © Prof. Dr. E. Rahm 7 -1 DBS 2 7. Big Data und NoSQL-Datenbanken Motivation Big Data –Herausforderungen –Einsatzbereiche Systemarchitekturen

Datenbanken Unit 12: NoSQL-Datenbanken und XMLinstitute.unileoben.ac.at/infotech/lehre/db/SS2018/Unit12.pdf · Unit 12: NoSQL-Datenbanken und XML Ronald Ortner 18. VI. 2018 Ronald

NoSQL - An introduction to CouchDB

NoSQL-Datenbanken...• MongoDB – Einfache Anfragen – Aggregation Framework und MapReduce – Indexierung und Anfrageoptimierung – Replikation und Sharding • CouchDB – Demo:

ZTB: NoSQL Not Only SQL, CouchDB - Apache CouchDB has ...home.agh.edu.pl/~wojnicki/wiki/_media/pl:ztb:dcouchdb-show.pdf · NoSQL ZTB: NoSQL – Not Only SQL, CouchDB Apache CouchDB

NoSQL CGN: CouchDB (11/2011)

NoSQL databáze - Encyklopédia poznania...Databáze, NoSQL, CouchDB, RavenDB, MongoDB, Neo4j, OrientDB, Titan, Redis, Memcached, Riak, Cassandra. Abstract The topic of this thesis

NoSQL & relax with CouchDBpywaw.org/media/slides/pywaw-23-nosql-relax-with-couchdb_1.pdf · Title: NoSQL & relax with CouchDB Author: Adam Dziedzic Subject: Bazy danych NoSQL Created

NoSQL-Datenbanken · 2017-04-12 · Quelle: Stefan Edlich, Achim Friedland, Jens Hampe,Benjamin Brauer: “NoSQL: Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken”, Carl

Reindownload.microsoft.com/download/3/3/1/3314E256-7BD... · Rein relationale DB in Prod? Datenbanken in produktiven Einsatz? 1 SQL + NoSQL DB in Prod? (MongoDB, Redis, CouchDB, Cassandra)

Couchdb Nosql

Leistungsmessung und Leistungsbewertung von NoSQL-Datenbanken · NoSQL-Datenbanken, welche in den letzten Jahren immer beliebter geworden sind und einige Vorteile gegenüber relationalen

NoSQL-Datenbanken · 2019-07-03 · NoSQL DokumentenorientierteWide Column StoresGraphdatenbankenKey-Value StoresDatenbanken 2 2 Inhaltsverzeichnis: Wide Column Stores • Einführung

NoSQL Datenbanken am Beispiel von CouchDB · Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: info@oio.de NoSQL Datenbanken am Beispiel von CouchDB OIO - Hauskonferenz

NoSQL - SGBD distribués et CouchDB · 2017-05-09 · Pr eambule NoSQL Introduction au NOSQL L’exemple de CouchDB Les motivations autour du NoSQL (Not Only SQL) Recouvre di erentes

NoSQL - Einführung in Graphen-Datenbanken mit Neo4j