NoSQL und CouchDB

Transcript

1. NoSQL und CouchDB Dr. Kerstin Puschke Mai 2010 K. Puschke () NoSQL Mai 2010 1 / 30
2. Lizenz Lizenz Dieser Text steht unter einer Creative Commons Attribution 3.0 Germany Lizenz, siehe http://creativecommons.org/licenses/by/3.0/de/ K. Puschke () NoSQL Mai 2010 2 / 30
3. NoSQL Begriffsklärung 2009 als Sammelbegriff für bereits länger existierende Systeme etabliert Not only SQL keine eindeutige Definition nicht-relationale Datenspeicher K. Puschke () NoSQL Mai 2010 3 / 30
4. NoSQL Begriffsklärung no:sql(eu) conference. http://www.nosqleu.com, April 2010 . . . era of “one-size-fits-all database” seems to be over. K. Puschke () NoSQL Mai 2010 4 / 30
5. NoSQL Begriffsklä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 the future is about choosing a data store that best matches your data set and operational requirements. K. Puschke () NoSQL Mai 2010 4 / 30
6. NoSQL Begriffsklä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 the future is about choosing a data store that best matches your data set and operational requirements. It’s a future of heterogeneous data backends, polyglot persistence and choosing Not Only SQL but sometimes also a document database, a key-value store or a graph database. K. Puschke () NoSQL Mai 2010 4 / 30
7. 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
8. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend aufwändig zu entwerfen: Normalisierung,. . . nachträglich schwierig zu ändern stark strukturiert Webanwendungen user generated content unstrukturierte Daten K. Puschke () NoSQL Mai 2010 6 / 30
9. Abfragen Web vs. RDBMS RDBM dynamische Abfragen (ad hoc reporting) beliebige Abfragen über alle Daten direkt in SQL Abfrage-Optimierung oft erforderlich Webanwendungen wiederkehrende Abfragen, nur Parameter ändern sich K. Puschke () NoSQL Mai 2010 7 / 30
10. Verteiltes Arbeiten Skalierbarkeit Hochverfügbarkeit RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt Problem: Fallacies of Distributed Computing K. Puschke () NoSQL Mai 2010 8 / 30
11. CAP Theorem Consistency, Availability, Partition Tolerance Theorem Consistency Der Client glaubt, eine Menge von Operationen sei auf einen Schlag passiert: Alle Clients sehen dieselben Daten. Availability Jede Operation endet mit einer bestimmungsgemäßen Antwort: Alle Clients können auf eine Version der Daten zugreifen. Partition Tolerance Operationen werden zu Ende geführt, auch wenn die Datenbank partitioniert ist. Nur zwei der drei Eigenschaften sind gleichzeitig möglich! K. Puschke () NoSQL Mai 2010 9 / 30
12. CAP Theorem Anwendung 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
13. Relationales Modell striktes Schema zeilenorientierte Speicherung ’echte’ Beziehungen zwischen Daten foreign key constraints, joins. . . K. Puschke () NoSQL Mai 2010 11 / 30
14. Spaltenorientierung Cassandra, BigTable,. . . spaltenorientierte Speicherung mehr Performanz für bestimmte Abfragen z.B. Aggregieren innerhalb einer Spalte flexibleres Schema keine ’echten’ Beziehungen K. Puschke () NoSQL Mai 2010 12 / 30
15. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace entspricht der Anwendung; Beispiel: ’Blog’ column family entspricht einer Datei Beispiel: ’Posts’ oder ’Users’ beliebig viele Einträge (key + columns) key identifiziert einen Eintrag in der column family wird bei Abfragen benutzt keys sind lokal gleichnamige keys verschiedener column families sind verschieden keine ’echten’ Beziehungen column tupel (name, value, timestamp) Beispiel: {name:username, value:foo, timestamp:12345} verschiedene keys können verschiedene columns haben K. Puschke () NoSQL Mai 2010 13 / 30
16. Objektorientierung Persistenzschicht für Objektorientierte Programmierung Abfragen in objektorientierter Programmiersprache OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene Sprache db4o, JADE, Databeans,. . . K. Puschke () NoSQL Mai 2010 14 / 30
17. Graphen Graphen im Sinne der Mathematik Knoten und Kanten modellieren z.B. Netzwerk, Leitungssystem,. . . Spezialfall: Baum z.B. Produktkategorien (Eltern-Kind-Beziehung) K. Puschke () NoSQL Mai 2010 15 / 30
18. Graphendatenbanken InfoGrid, neo4j, . . . Daten als Graphen Knoten eigenständige Objekte wie Kunde, Bestellung,. . . Kanten sind Beziehungen zwischen Knoten schematisiert oder schemafrei Kanten sind “first class objects” gut geeignet für komplexe Beziehungsgeflechte z.B. social network K. Puschke () NoSQL Mai 2010 16 / 30
19. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare Abfrage per Schlüssel schemafrei keine ’echten’ Relationen K. Puschke () NoSQL Mai 2010 17 / 30
20. Dokumentenorientierung CouchDB, MongoDB, Riak, XML-Datenbanken. . . Dokument: weitere Abstraktionsebene oberhalb von Schlüssel-Wert-Paaren für sich genommen sinnvolle Informationseinheit meist Entsprechung im Real Life (Rechnung, Visitenkarte,. . . ) schemafrei keine ’echten’ Relationen K. Puschke () NoSQL Mai 2010 18 / 30
21. CouchDB’s Datenmodell Format: JavaScript Object Notation (JSON) Bestandteil von JavaScript Schlüssel-Wert-Paare obligatorische 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
22. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster auf unzuverlässiger Standardhardware Datenbanksystem (nicht nur) für Webanwendungen offene Webstandards Robuste Replikation verteiltes Arbeiten ohne Fallacies of Distributed Computing schemafrei geeignet für unstrukturierte Daten K. Puschke () NoSQL Mai 2010 20 / 30
23. Implementierung Überblick HTTP/REST (Webserver enthalten) Erlang funktional, fehlertolerant, concurrency optimiert Viewserver in JavaScript (Indizes erstellen) alternativ via Plugins auch PHP, Ruby, Python, Perl, Common Lisp, Erlang,. . . dokumentenbasierte Speicherung (JSON) Datenbank und Indizes als B-Tree gespeichert eventual consistency (in verteilten Systemen) Storage Engine: ACID optimistic locking, Multi Version Concurrency Control K. Puschke () NoSQL Mai 2010 21 / 30
24. Updates neue Version eines Dokumentes wird an Datenbankdatei angehängt keine diffs, keine partiellen updates Robust: was einmal auf Platte steht, wird nicht mehr angefaßt serialisierte Schreibzugriffe (pro Datenbank) Geschwindigkeit: neue Version kann angehängt werden, während alte noch gelesen wird MVCC K. Puschke () NoSQL Mai 2010 22 / 30
25. View (secondary) Index (Schlüssel-Wert-Paare) Schlüssel und Werte des Views sind Werte aus Dokumenten Beispiel: Erstellungsdaten als Schlüssel, Blogposttitel als Werte können auch arrays von Werten (aus Dokumenten) sein Werte (im View) können auch aggregierte Werte (aus Dokumenten) sein sortiert nach Schlüsseln effizientes Abfragen nach bestimmten Schlüsseln oder Bereichen von Schlüsseln ’Titel aller Blogposts von Mai 2009’ zur Abfragezeit erzeugt/aktualisiert durch MapReduce K. Puschke () NoSQL Mai 2010 23 / 30
26. MapReduce View erzeugen map verarbeitet Dokumente erzeugt Schlüssel-Wert-Paare optionales reduce erzeugt aggregierte (Zwischen)Werte verarbeitet Ergebnisse von map oder rekursiv Zwischenergebnisse von reduce group: anwenden auf Objekte mit gleichem Schlüssel Beispiel: nicht alle Blogposts zählen, sondern Blogposts pro Tag MapReduce-Funktionen gespeichert in Dokumenten (Designdokumente) K. Puschke () NoSQL Mai 2010 24 / 30
27. Design Documents CouchDB-Dokumente _id beginnt mit _design enthalten Anwendungscode, sprich Funktionen MapReduce-Funktionen für Views Validation: Zulässigkeit von Updates input prüfen, nur eingeloggte user,. . . serverseitige Bearbeitung vor dem Speichern eines Dokumentes Show/List: JSON in HTML, XML,. . . konvertieren K. Puschke () NoSQL Mai 2010 25 / 30
28. Webanwendungen mit CouchDB Klassische Webanwendungen Serverseitige Skripte lesen Daten aus CouchDB erzeugen daraus dynamisch HTML Webserver liefert aus K. Puschke () NoSQL Mai 2010 26 / 30
29. Webanwendungen mit CouchDB CouchApps leben vollständig in der Datenbank keine middleware Show/List-Funktionen Attachments (HTML,CSS, Javascript) direkt ausliefern Ausgelieferte Webseite greift per Javascript/HTTP auf CouchDB zu Replikation: update, fork, backup von Anwendungen K. Puschke () NoSQL Mai 2010 27 / 30
30. Dezentrale offline Webanwendung Ein Usecase für CouchApps Daten und Anwendung lokal beim user offline verfügbar lokale Datenhaltung = niedrige Latenz dezentral (gefilterte) Replikation mit anderen usern K. Puschke () NoSQL Mai 2010 28 / 30
31. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten bereits realisiert in Ubuntu Bookmarks, Adreßbuch,. . . in CouchDB speichern per Replikation mit anderen Rechnern synchronisieren K. Puschke () NoSQL Mai 2010 29 / 30
32. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben bestehen kein ad hoc reporting BASE vs. ACID Zweifel an der Geschwindigkeit? CouchApps und Co: Verteilte Identitäten serverseitiger Code nötig für Authentifizierung/Autorisierung vertrauenswürdiger Server nötig K. Puschke () NoSQL Mai 2010 30 / 30