Date post: | 12-May-2015 |
Category: |
Technology |
Upload: | kerstin-puschke |
View: | 5,225 times |
Download: | 0 times |
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 2 / 55
Übersicht
1 EinführungRelationale DatenbanksystemeWeitere DatenbanksystemeNoSQL
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 3 / 55
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,. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
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?
K. Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55
NoSQLBegriffsklärung
2009 als Sammelbegriff für bereits länger existierende SystemeetabliertNot only SQLkeine eindeutige Definitionnicht-relationale Datenspeicher
K. Puschke (FU Berlin) NoSQL 13. September 2010 6 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 7 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 8 / 55
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 (FU Berlin) NoSQL 13. September 2010 9 / 55
Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?Web vs. RDBMSVerteilte SystemeNoSQL vs. SQL
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 10 / 55
(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 (FU Berlin) NoSQL 13. September 2010 11 / 55
AbfragenWeb vs. RDBMS
RDBMSdynamische Abfragen (ad hoc reporting)beliebige Abfragen über alle Daten direkt in SQL
Webanwendungenwiederkehrende Abfragen, nur Parameter ändern sich
K. Puschke (FU Berlin) NoSQL 13. September 2010 12 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
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]
K. Puschke (FU Berlin) NoSQL 13. September 2010 14 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55
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)
K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 DatenmodelleSpaltenorientierungObjektorientierungGraphenSchlüssel-Wert-PaareDokumentenorientierung
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 18 / 55
Relationales Modell
striktes SchemaTabellen und Spalten statischzeilenorientierte Speicherung’echte’ Beziehungen zwischen Datenforeign key constraints, joins. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 19 / 55
Spaltenorientierung
erste spaltenorientierte Datenbanken in den 1970ernCassandra, BigTable,. . .spaltenorientierte Speicherungmehr Performanz für bestimmte Abfragenz.B. Aggregieren innerhalb einer Spalteflexibleres SchemaSpalten dynamischkeine ’echten’ Beziehungen
K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55
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}
K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
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}
K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55
Objektorientierung
Persistenzschicht für Objektorientierte ProgrammierungAbfragen in objektorientierter ProgrammierspracheOO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigeneSprachedb4o, JADE, Databeans,. . .
K. Puschke (FU Berlin) NoSQL 13. September 2010 23 / 55
Graphen
Graphen im Sinne der MathematikKnoten und Kantenmodellieren z.B. Netzwerk, Leitungssystem,. . .Spezialfall: Baumz.B. Produktkategorien (Eltern-Kind-Beziehung)
K. Puschke (FU Berlin) NoSQL 13. September 2010 24 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
Schlüssel-Wert-Paare
Riak, Tokyo Cabinet,. . .Schlüssel-Wert-PaareAbfrage per Schlüsselschemafreikeine ’echten’ Relationen
K. Puschke (FU Berlin) NoSQL 13. September 2010 26 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
CouchDB DokumentJSON
K. Puschke (FU Berlin) NoSQL 13. September 2010 29 / 55
Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDBImplementierungUpdates and ConcurrencyAbfragenDesign DocumentsAnwendungen
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 30 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 34 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
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 (FU Berlin) NoSQL 13. September 2010 36 / 55
ViewBeispiel
View mit Schlüssel Datum und Wert Titel des Blogposts, dargestellt inFuton
K. Puschke (FU Berlin) NoSQL 13. September 2010 37 / 55
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)
K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
ViewBeispiel
View ohne reduce
K. Puschke (FU Berlin) NoSQL 13. September 2010 39 / 55
ViewBeispiel
View mit reduce
View mit reduce und group_level=2
K. Puschke (FU Berlin) NoSQL 13. September 2010 40 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55
Webanwendungen mit CouchDBKlassische Webanwendungen
Serverseitige Skripte lesen Daten aus CouchDBerzeugen daraus dynamisch HTMLWebserver liefert aus
K. Puschke (FU Berlin) NoSQL 13. September 2010 42 / 55
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 (FU Berlin) NoSQL 13. September 2010 43 / 55
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 (FU Berlin) NoSQL 13. September 2010 44 / 55
Desktop-Anwendungen
Beispiel: Synchronisation von Anwendungsdatenbereits realisiert in UbuntuBookmarks, Adreßbuch,. . . in CouchDB speichernper Replikation mit anderen Rechnern synchronisieren
K. Puschke (FU Berlin) NoSQL 13. September 2010 45 / 55
Übersicht
1 Einführung
2 Why Not Only SQL - warum nicht immer SQL einsetzen?
3 Datenmodelle
4 CouchDB
5 Herausforderungen und Kritik
K. Puschke (FU Berlin) NoSQL 13. September 2010 46 / 55
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
K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
Noch Fragen?
Vielen Dank für Ihre Aufmerksamkeit!
Fragen und Anmerkungen?
K. Puschke (FU Berlin) NoSQL 13. September 2010 48 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 49 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 50 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 51 / 55
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/.
K. Puschke (FU Berlin) NoSQL 13. September 2010 52 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 53 / 55
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.
K. Puschke (FU Berlin) NoSQL 13. September 2010 54 / 55
Referenzen VII
Stefan Tilkov.A brief introduction to rest.Info Queue, 2007.URLhttp://www.infoq.com/articles/rest-introduction.
K. Puschke (FU Berlin) NoSQL 13. September 2010 55 / 55