SlideShare ist ein Scribd-Unternehmen logo
1 von 80
Downloaden Sie, um offline zu lesen
Not only SQL
                    CouchDB und andere NoSQL-Datenbanken


                                    Dr. Kerstin Puschke

                                   Vortrag an der HAW Hamburg


                                        3. Juni 2010




K. Puschke (Vortrag HAW Hamburg)             NoSQL              3. Juni 2010   1 / 79
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 (Vortrag HAW Hamburg)   NoSQL         3. Juni 2010   2 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

7   Praxisbeispiel

K. Puschke (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   3 / 79
Übersicht

1   Einführung
       Relationale Datenbanksysteme
       Weitere Datenbanksysteme
       NoSQL

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

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

K. Puschke (Vortrag HAW Hamburg)
7                                  NoSQL             3. Juni 2010   4 / 79
Relationale Datenbanksysteme




      in der Theorie
              Codd (1970) [3]
              Codd’s 12 Regeln (1985) [4, 5]
              Vollständigkeit im Sinne der relationalen Algebra
      in der Praxis und im Kontext des Vortrags
              zeilenbasierte Speicherung in Tabellen
              SQL als Sprache
              z.B. MySQL, Postgres, Oracle,. . .




K. Puschke (Vortrag HAW Hamburg)        NoSQL                     3. Juni 2010   5 / 79
Weitere Datenbanksysteme



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




K. Puschke (Vortrag HAW Hamburg)   NoSQL                  3. Juni 2010   6 / 79
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 (Vortrag HAW Hamburg)   NoSQL                   3. Juni 2010   7 / 79
NoSQL
Was NoSQL manchmal (nicht) ist




                           Verteiltes_Arbeiten
                    Skalierbarkeit    Schemafreiheit
          Geschwindigkeit    Open_Source        Open_Standards
                          Große_Datenmengen
          Aufgabe_der_ACID-Prinzipien       Einfache_Benutzung
              Fehlertoleranz    Concurrency       Durchsatz
                             Zuverlässigkeit




K. Puschke (Vortrag HAW Hamburg)   NoSQL                 3. Juni 2010   8 / 79
NoSQL
Begriffsklä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 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 (Vortrag HAW Hamburg)   NoSQL                                  3. Juni 2010     9 / 79
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 (Vortrag HAW Hamburg)     NoSQL                 3. Juni 2010   10 / 79
Übersicht

1   Einführung

2   Why Not Only SQL - warum nicht immer SQL einsetzen?
     Web vs. RDBMS
     Verteilte Systeme

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

7   Praxisbeispiel
K. Puschke (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   11 / 79
(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 (Vortrag HAW Hamburg)        NoSQL                3. Juni 2010   12 / 79
Abfragen
Web vs. RDBMS




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

Webanwendungen
      wiederkehrende Abfragen, nur Parameter ändern sich




K. Puschke (Vortrag HAW Hamburg)   NoSQL                 3. Juni 2010   13 / 79
Verteiltes Arbeiten




      Skalierbarkeit
              große Datenmengen
              früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung
              heute: preiswerte Hardware ergänzen (auch via cloud)
      Hochverfügbarkeit
      RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt




K. Puschke (Vortrag HAW Hamburg)       NoSQL                      3. Juni 2010   14 / 79
Verteiltes Arbeiten



      Skalierbarkeit
              große Datenmengen
              The largest BigTable instance manages about 6 petabytes of data
              spread across thousands of machines
              Jeff Dean, Google I/O conference, Mai 2008 (Shankland [14])
              früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung
              heute: preiswerte Hardware ergänzen (auch via cloud)
      Hochverfügbarkeit
      RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt




K. Puschke (Vortrag HAW Hamburg)                        NoSQL               3. Juni 2010   14 / 79
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!
siehe Brewer [2] und Lynch & Gilbert [10]




K. Puschke (Vortrag HAW Hamburg)            NoSQL            3. Juni 2010   15 / 79
CAP Theorem
Anwendung




      Availability & Consistency: Paxos, BigTable . . .
      Network Partitioning oft unvermeidlich
      trade off: Consistency vs. Availability
      Consistency & Partition Tolerance: viele RDBMS, . . .
              ACID (atomicity, consistency, isolation, durability)
              siehe Gray [7] und Haerder & Reuter [8]

      Availability & Partition Tolerance: CouchDB, MongoDB,
      Cassandra, Dynamo,. . .
              BASE (basically available, soft-state, eventual consistency)
              siehe Pritchett [13]




K. Puschke (Vortrag HAW Hamburg)                        NoSQL        3. Juni 2010   16 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs
      HTTP/REST
      MapReduce

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

7   Praxisbeispiel
K. Puschke (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   17 / 79
Protokoll und API




      viele NoSQL-Systeme nutzen
              vorhandene Programmiersprachen (neo4j,. . . )
              HTTP/REST (CouchDB, MongoDB,. . . )
      verbreitet: MapReduce-Techniken (Parallelisierung)




K. Puschke (Vortrag HAW Hamburg)       NoSQL                  3. Juni 2010   18 / 79
RESTful HTTP API




HTTP Protokoll
      Browser, curl,. . . sind DB-Clients
      Clients in beliebiger Sprache leicht zu programmieren
      vorhandene Webtechnologien nutzbar
      Load Balancer, Proxy, HTTPS via SSL-fähigen Proxy. . .
      Vor- und Nachteile von HTTP




K. Puschke (Vortrag HAW Hamburg)     NoSQL                    3. Juni 2010   19 / 79
RESTful HTTP API



REpresentational State Transfer API
      Architekturprinzip für Kommunikation zwischen heterogenen
      Anwendungen
      geeignet für verteilte Systeme
      Stateless Communication
              jeder Request in sich geschlossen
              Anwendungsinformationen nur im Client
              keine serverseitigen Sitzungen o.ä.




K. Puschke (Vortrag HAW Hamburg)      NoSQL             3. Juni 2010   20 / 79
CouchDB
REST/HTTP




      Willkommensnachricht des Servers
      http://localhost:5984
      Alle Datenbanken anzeigen
      http://localhost:5984/_all_dbs
      Informationen über die Datenbank kontaktdaten
      http://localhost:5984/kontaktdaten




K. Puschke (Vortrag HAW Hamburg)   NoSQL              3. Juni 2010   21 / 79
MapReduce




      map und reduce Funktionen: Konzept aus der funktionalen
      Programmierung
      verarbeitet große Datenmengen parallel
      MapReduce: framework zur verteilten Verarbeitung großer
      Datenmengen (Google)
      freie Implementierung: Hadoop




K. Puschke (Vortrag HAW Hamburg)   NoSQL                3. Juni 2010   22 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs

4   Datenmodelle
      Spaltenorientierung
      Objektorientierung
      Graphen
      Schlüssel-Wert-Paare
      Dokumentenorientierung

5   CouchDB

6   Herausforderungen und Kritik NoSQL
K. Puschke (Vortrag HAW Hamburg)                     3. Juni 2010   23 / 79
Relationales Modell




      striktes Schema
      Tabellen und Spalten statisch
      zeilenorientierte Speicherung
      ’echte’ Beziehungen zwischen Daten
      foreign key constraints, joins. . .




K. Puschke (Vortrag HAW Hamburg)   NoSQL    3. Juni 2010   24 / 79
Spaltenorientierung



      erste spaltenorientierte Datenbanken in den 1970ern
      Cassandra, BigTable,. . .
      spaltenorientierte Speicherung
      mehr Performanz für bestimmte Abfragen
      z.B. Aggregieren innerhalb einer Spalte
      flexibleres Schema
      Spalten dynamisch
      keine ’echten’ Beziehungen




K. Puschke (Vortrag HAW Hamburg)   NoSQL                    3. Juni 2010   25 / 79
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}

K. Puschke (Vortrag HAW Hamburg)        NoSQL                    3. Juni 2010   26 / 79
Cassandra’s Datenmodell
Vereinfachte Darstellung


      verschiedene keys können verschiedene columns haben
              kein striktes Schema
      Beispiel
      Abfrage (:Users, 42)
        {
      username : foo,
      email : foo@example.com,
      screen_name : FOOOOO
      }
      Abfrage (:Users, 23)
        {
      username : bar,
      admin : yes
      }

K. Puschke (Vortrag HAW Hamburg)     NoSQL            3. Juni 2010   27 / 79
Objektorientierung




      Persistenzschicht für Objektorientierte Programmierung
      Abfragen in objektorientierter Programmiersprache
      OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene
      Sprache
      db4o, JADE, Databeans,. . .




K. Puschke (Vortrag HAW Hamburg)    NoSQL                 3. Juni 2010   28 / 79
Graphen

      Graphen im Sinne der Mathematik
      Knoten und Kanten
      modellieren z.B. Netzwerk, Leitungssystem,. . .
      Spezialfall: Baum
      z.B. Produktkategorien (Eltern-Kind-Beziehung)




K. Puschke (Vortrag HAW Hamburg)   NoSQL                3. Juni 2010   29 / 79
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”
      häufige Operation: Traversierung
      gut geeignet für komplexe Beziehungsgeflechte
      z.B. social network




K. Puschke (Vortrag HAW Hamburg)        NoSQL                     3. Juni 2010   30 / 79
Schlüssel-Wert-Paare




      Riak, Tokyo Cabinet,. . .
      Schlüssel-Wert-Paare
      Wert muss kein String sein (Objekte,. . . möglich)
      Abfrage per Schlüssel
      schemafrei
      keine ’echten’ Relationen




K. Puschke (Vortrag HAW Hamburg)   NoSQL                   3. Juni 2010   31 / 79
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,. . . )
      üblicherweise kein leeren Felder
      schemafrei
      keine ’echten’ Relationen




K. Puschke (Vortrag HAW Hamburg)   NoSQL                    3. Juni 2010   32 / 79
CouchDB’s Datenmodell


      Format: JavaScript Object Notation (JSON)
      Bestandteil von JavaScript
      wird z.T. direkt vom Browser verstanden
      wenig Datentypen
      diese werden von nahezu allen Sprachen verstanden
      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 (Vortrag HAW Hamburg)       NoSQL                    3. Juni 2010   33 / 79
CouchDB Dokument
JSON




       Dokument mit _id 69a. . . aus Datenbank kontaktdaten
       http://localhost:5984/kontaktdaten/
       69a87107057813de1414e08a9f000912




K. Puschke (Vortrag HAW Hamburg)   NoSQL                 3. Juni 2010   34 / 79
CouchDB Dokument
JSON




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   35 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB
      Implementierung
      Updates and Concurrency
      Abfragen
      Design Documents
      Anwendungen

6   Herausforderungen und Kritik NoSQL
K. Puschke (Vortrag HAW Hamburg)                     3. Juni 2010   36 / 79
Was ist CouchDB?



      Cluster Of Unreliable Commodity Hardware DataBase
      Datenbankcluster auf unzuverlässiger Standardhardware
      Datenbanksystem (nicht nur) für Webanwendungen
      offene Webstandards
      Robuste Replikation
      schemafrei
      geeignet für unstrukturierte Daten
      Philosophie: entspanntes Arbeiten
      keine Entscheidungen, die nicht zu revidieren sind




K. Puschke (Vortrag HAW Hamburg)   NoSQL                   3. Juni 2010   37 / 79
Implementierung
Überblick



      HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov [16]
      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 (Vortrag HAW Hamburg)        NoSQL                        3. Juni 2010   38 / 79
Replikation



      shared nothing cluster
      Server unabhängig voneinander
      inkrementell
      gefiltert
      N-Master, Master-Slave, P2P, eigene Cloud,. . .
      Hot failover, backup, Lastverteilung,. . .
      extrem robust
      ggf. manuell Konflikte lösen




K. Puschke (Vortrag HAW Hamburg)     NoSQL              3. Juni 2010   39 / 79
Updates




      komplettes Dokument abholen, verändern, zum Speichern
      zurücksenden
      neue Version eines Dokumentes wird an Datenbankdatei
      angehängt
      Robust: was einmal auf Platte steht, wird nicht mehr angefaßt
      Geschwindigkeit: neue Version kann angehängt werden, während
      alte noch gelesen wird




K. Puschke (Vortrag HAW Hamburg)   NoSQL                   3. Juni 2010   40 / 79
Multi Version Concurrency Control



      optimistic locking
              Client schickt verändertes Dokument mit unveränderter
              Versionsnummer _rev
              Server prüft, ob diese _rev identisch ist mit der aktuell
              gespeicherten
              wenn ja: Dokument wird gespeichert (Server vergibt neue _rev)
              wenn nein: Fehlermeldung
      keine Versionskontrolle
      es werden nicht alle Versionen aufbewahrt




K. Puschke (Vortrag HAW Hamburg)       NoSQL                     3. Juni 2010   41 / 79
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 (Vortrag HAW Hamburg)       NoSQL                     3. Juni 2010   42 / 79
View - Beispiel
      Dokument eines Blogposts
      http://localhost:5984/simple_blog/
      17cf8a2934231a6cedc9e30fd30045a7
      View
      http://localhost:5984/simple_blog/_design/
      by-date/_view/blogposts-by-date
      http://localhost:
      5984/_utils/database.html?simple_blog/_design/
      by-date/_view/blogposts-by-date
      Query: Blogpost vom 12. April 2010
      http://localhost:5984/simple_blog/_design/
      by-date/_view/blogposts-by-date?key=[2010,4,12]
      Query: Blogposts aus März 2010
      http://localhost:5984/simple_blog/_design/
      by-date/_view/blogposts-by-date?startkey=[2010,
      3,0]&endkey=[2010,3,31]
K. Puschke (Vortrag HAW Hamburg)   NoSQL     3. Juni 2010   43 / 79
View
Beispiel




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




K. Puschke (Vortrag HAW Hamburg)   NoSQL                 3. Juni 2010   44 / 79
View
Beispiel


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




K. Puschke (Vortrag HAW Hamburg)   NoSQL               3. Juni 2010   45 / 79
Map Reduce
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
      Map-Reduce-Funktionen gespeichert in Dokumenten
      (Designdokumente)




K. Puschke (Vortrag HAW Hamburg)   NoSQL                   3. Juni 2010   46 / 79
View - Beispiel

      Designdokument (map-Funktion)
      http://localhost:
      5984/simple_blog/_design/by-date
      Designdokument (map und reduce)
      http://localhost:
      5984/simple_blog/_design/per-date
      View
      http://localhost:5984/simple_blog/_design/
      per-date/_view/posts-per-date
      http://localhost:
      5984/_utils/database.html?simple_blog/_design/
      per-date/_view/posts-per-date
      Gruppiert
      http://localhost:5984/simple_blog/_design/
      per-date/_view/posts-per-date?group_level=1
K. Puschke (Vortrag HAW Hamburg)   NoSQL     3. Juni 2010   47 / 79
Designdokument
Beispiel




Designdokument mit map-Funktion




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   48 / 79
Designdokument
Beispiel




Designdokument mit map- und reduce-Funktionen




K. Puschke (Vortrag HAW Hamburg)   NoSQL        3. Juni 2010   49 / 79
View
Beispiel




View ohne reduce




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   50 / 79
View
Beispiel



View mit reduce




View mit reduce und group_level=2




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   51 / 79
Design Documents




      _id beginnt mit _design
      enthalten Anwendungscode, sprich Funktionen
              Map-Reduce-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 (Vortrag HAW Hamburg)      NoSQL                     3. Juni 2010   52 / 79
Beispiel Show Functions




      Design Dokument (Show)
      http://localhost:
      5984/kontaktdaten/_design/output
      Dokument anzeigen
      http://localhost:
      5984/kontaktdaten/_design/output/_show/card/
      69a87107057813de1414e08a9f000912




K. Puschke (Vortrag HAW Hamburg)   NoSQL     3. Juni 2010   53 / 79
Designdokument
Beispiel




Designdokument mit show-Funktion




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   54 / 79
Webanwendungen mit CouchDB
Klassische Webanwendungen




      Serverseitige Skripte lesen Daten aus CouchDB
      erzeugen daraus dynamisch HTML
      Webserver liefert aus




K. Puschke (Vortrag HAW Hamburg)   NoSQL              3. Juni 2010   55 / 79
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 (Vortrag HAW Hamburg)   NoSQL                  3. Juni 2010   56 / 79
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 (Vortrag HAW Hamburg)   NoSQL          3. Juni 2010   57 / 79
Desktop-Anwendungen




      Beispiel: Synchronisation von Anwendungsdaten
      bereits realisiert in Ubuntu
      Bookmarks, Adreßbuch,. . . in CouchDB speichern
      per Replikation mit anderen Rechnern synchronisieren




K. Puschke (Vortrag HAW Hamburg)     NoSQL               3. Juni 2010   58 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

7   Praxisbeispiel

K. Puschke (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   59 / 79
Herausforderungen und Kritik


      HTML/JS, HTTP,. . .
      vorhandene Probleme bleiben bestehen
      kein ad hoc reporting
      BASE vs. ACID
      Zuverlässigkeit z.B. bei Finanztransaktionen
      Zweifel an der Geschwindigkeit
      Stonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12]

      CouchApps und Co: Verteilte Identitäten
              serverseitiger Code nötig für Authentifizierung/Autorisierung
              vertrauenswürdiger Server nötig




K. Puschke (Vortrag HAW Hamburg)                             NoSQL        3. Juni 2010   60 / 79
Übersicht

1   Einführung

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

3   Protokolle & APIs

4   Datenmodelle

5   CouchDB

6   Herausforderungen und Kritik

7   Praxisbeispiel

K. Puschke (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   61 / 79
Einfache Bloganwendung
ER-Diagramm




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   62 / 79
Einfache Bloganwendung
Relationes Schema




      Tabelle Posts mit Spalten
      post_id, Titel, Text, user, Datum
      Tabelle Kommentare mit Spalten
      comment_id, Text, user, Datum, post_id
      foreign key constraint
      Kommentare.post_id, Posts.post_id




K. Puschke (Vortrag HAW Hamburg)   NoSQL       3. Juni 2010   63 / 79
Einfache Bloganwendung
ER-Diagramm




Dokumentenorientierter Ansatz?




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   64 / 79
Einfache Bloganwendung
Blogpost ohne Kommentare




      http://localhost:
      5984/blog0/cc50e8668ff421c1c09be1b71000077a




K. Puschke (Vortrag HAW Hamburg)   NoSQL     3. Juni 2010   65 / 79
Einfache Bloganwendung
Blogpost ohne Kommentare




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   66 / 79
Einfache Bloganwendung
Blogpost mit Kommentare “inline”




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   67 / 79
Einfache Bloganwendung
Kommentar als eigenes Dokument




K. Puschke (Vortrag HAW Hamburg)   NoSQL   3. Juni 2010   68 / 79
Einfache Bloganwendung
Kommentar als eigenes Dokument



View zur Ausgabe von Posts mit zugehörigen Kommentaren
zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw.
Kommentar
map-Funktion

function(doc) {
  if (doc.type == "post") {
    emit([doc._id, 0], doc);
  } else if (doc.type == "comment") {
    emit([doc.post_id, 1], doc);
  }
}



K. Puschke (Vortrag HAW Hamburg)   NoSQL              3. Juni 2010   69 / 79
Einfache Bloganwendung
Kommentar als eigenes Dokument

View zur Ausgabe von Posts mit zugehörigen Kommentaren
zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw.
Kommentar




K. Puschke (Vortrag HAW Hamburg)   NoSQL              3. Juni 2010   70 / 79
Einfache Bloganwendung
Blogposts und Kommentare




      Kommentare “inline”
              Direkter Zugriff auf Kommentare durch geeigneten View
              Vorteil: alles beisammen, beim Löschen des Posts werden alle
              Kommentare mit gelöscht,. . .
              Nachteil: jeder neue Kommentar ist ein Update des Posts; bei
              vielen Kommentaren Konflikte wahrscheinlich
      Alternative: Kommentare in eigenen Dokumenten
              Gemeinsame Ausgabe eines Posts und seiner Kommetare durch
              geeigeneten View




K. Puschke (Vortrag HAW Hamburg)       NoSQL                     3. Juni 2010   71 / 79
Noch Fragen?




                          Vielen Dank für Ihre Aufmerksamkeit!




                                   Fragen und Anmerkungen?




K. Puschke (Vortrag HAW Hamburg)            NoSQL                3. Juni 2010   72 / 79
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 (Vortrag HAW Hamburg)   NoSQL                    3. Juni 2010   73 / 79
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 and
      Implementation. 2004.
      URL http://labs.google.com/papers/mapreduce.html.



K. Puschke (Vortrag HAW Hamburg)   NoSQL           3. Juni 2010   74 / 79
Referenzen III

      Jim Gray.
      The transaction concept: Virtues and limitations.
      In Proceedings of the 7th International Conference on Very Large
      Databases, 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 (Vortrag HAW Hamburg)   NoSQL                      3. Juni 2010   75 / 79
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 (Vortrag HAW Hamburg)    NoSQL                      3. Juni 2010   76 / 79
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 SIGMOD
      International 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 (Vortrag HAW Hamburg)   NoSQL               3. Juni 2010   77 / 79
Referenzen VI

      Stephen Shankland.
      Google spotlights data center inner workings.
      cnet news, Mai 2008.
      URL
      http://news.cnet.com/8301-10784_3-9955184-7.html.
      Michael Stonebraker, Daniel Abadi, David J. DeWitt, Sam
      Madden, 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 (Vortrag HAW Hamburg)   NoSQL             3. Juni 2010   78 / 79
Referenzen VII




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




K. Puschke (Vortrag HAW Hamburg)   NoSQL      3. Juni 2010   79 / 79

Weitere ähnliche Inhalte

Andere mochten auch

TestDisk User Manual
TestDisk User ManualTestDisk User Manual
TestDisk User ManualRockety Ryder
 
Timetable identity
Timetable identityTimetable identity
Timetable identityheiko.vogl
 
Behind the scenes of a grown-up web application
Behind the scenes of a grown-up web applicationBehind the scenes of a grown-up web application
Behind the scenes of a grown-up web applicationKerstin Puschke
 
Linux slides fort_2013_upload
Linux slides fort_2013_uploadLinux slides fort_2013_upload
Linux slides fort_2013_uploadRosa Freund
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxTrivadis
 
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)Kerstin Puschke
 
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)Kerstin Puschke
 
Nmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIXNmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIXGanesh Mandala
 
Extreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and TuningExtreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and TuningMilind Koyande
 
Windows command prompt a to z
Windows command prompt a to zWindows command prompt a to z
Windows command prompt a to zSubuh Kurniawan
 
Webentwicklung mit PHP und MySQL
Webentwicklung mit PHP und MySQLWebentwicklung mit PHP und MySQL
Webentwicklung mit PHP und MySQLKerstin Puschke
 
Linux monitoring and Troubleshooting for DBA's
Linux monitoring and Troubleshooting for DBA'sLinux monitoring and Troubleshooting for DBA's
Linux monitoring and Troubleshooting for DBA'sMydbops
 
Linux Troubleshooting
Linux TroubleshootingLinux Troubleshooting
Linux TroubleshootingKeith Wright
 
Course on Ehtical Hacking - Introduction
Course on Ehtical Hacking - IntroductionCourse on Ehtical Hacking - Introduction
Course on Ehtical Hacking - IntroductionBharat Thakkar
 
The New CSS Layout - dotCSS
The New CSS Layout - dotCSSThe New CSS Layout - dotCSS
The New CSS Layout - dotCSSRachel Andrew
 

Andere mochten auch (20)

TestDisk User Manual
TestDisk User ManualTestDisk User Manual
TestDisk User Manual
 
Timetable identity
Timetable identityTimetable identity
Timetable identity
 
In der Ruhe liegt die Kraft
In der Ruhe liegt die KraftIn der Ruhe liegt die Kraft
In der Ruhe liegt die Kraft
 
Linux- und Windows Rechner…
Linux- und Windows Rechner…Linux- und Windows Rechner…
Linux- und Windows Rechner…
 
oEmbed (on rails)
oEmbed (on rails)oEmbed (on rails)
oEmbed (on rails)
 
Behind the scenes of a grown-up web application
Behind the scenes of a grown-up web applicationBehind the scenes of a grown-up web application
Behind the scenes of a grown-up web application
 
Linux slides fort_2013_upload
Linux slides fort_2013_uploadLinux slides fort_2013_upload
Linux slides fort_2013_upload
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für Linux
 
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
 
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
 
Linux monitoring
Linux monitoringLinux monitoring
Linux monitoring
 
Nmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIXNmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIX
 
3 infomeeting
3 infomeeting3 infomeeting
3 infomeeting
 
Extreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and TuningExtreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and Tuning
 
Windows command prompt a to z
Windows command prompt a to zWindows command prompt a to z
Windows command prompt a to z
 
Webentwicklung mit PHP und MySQL
Webentwicklung mit PHP und MySQLWebentwicklung mit PHP und MySQL
Webentwicklung mit PHP und MySQL
 
Linux monitoring and Troubleshooting for DBA's
Linux monitoring and Troubleshooting for DBA'sLinux monitoring and Troubleshooting for DBA's
Linux monitoring and Troubleshooting for DBA's
 
Linux Troubleshooting
Linux TroubleshootingLinux Troubleshooting
Linux Troubleshooting
 
Course on Ehtical Hacking - Introduction
Course on Ehtical Hacking - IntroductionCourse on Ehtical Hacking - Introduction
Course on Ehtical Hacking - Introduction
 
The New CSS Layout - dotCSS
The New CSS Layout - dotCSSThe New CSS Layout - dotCSS
The New CSS Layout - dotCSS
 

Ähnlich wie Not only SQL - CouchDB und andere NoSQL-Datenbanken

Cloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von MetadatenCloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von MetadatenMagnus Pfeffer
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Dietmar Leher
 
RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?Capgemini
 
7 Top Internet-Trends
7 Top Internet-Trends7 Top Internet-Trends
7 Top Internet-TrendsMarkus Tressl
 
Big Data Konnektivität
Big Data KonnektivitätBig Data Konnektivität
Big Data KonnektivitätTrivadis
 
Einbindung von Linked Data in existierende Bibliotheksanswendungen
Einbindung von Linked Data in existierende BibliotheksanswendungenEinbindung von Linked Data in existierende Bibliotheksanswendungen
Einbindung von Linked Data in existierende Bibliotheksanswendungenredsys
 
Dokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDBDokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDBMario Müller
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open SourceDaniel Schneller
 
SAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdfSAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdfCazLP
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudAWS Germany
 
Web-2.0-Forschung der KWARC-Gruppe
Web-2.0-Forschung der KWARC-GruppeWeb-2.0-Forschung der KWARC-Gruppe
Web-2.0-Forschung der KWARC-GruppeChristoph Lange
 
SWIB 2010: Linked Open Projects
SWIB 2010: Linked Open ProjectsSWIB 2010: Linked Open Projects
SWIB 2010: Linked Open ProjectsKai Eckert
 
PostgreSQL: Die Freie Datenbankalternative
PostgreSQL: Die Freie DatenbankalternativePostgreSQL: Die Freie Datenbankalternative
PostgreSQL: Die Freie DatenbankalternativePeter Eisentraut
 
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...Dennis Zielke
 
MongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwaltenMongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwaltenTobias Trelle
 
amsl - Ergebnispräsentation der EFRE-Förderphase
amsl - Ergebnispräsentation der EFRE-Förderphaseamsl - Ergebnispräsentation der EFRE-Förderphase
amsl - Ergebnispräsentation der EFRE-FörderphaseBjörn Muschall
 

Ähnlich wie Not only SQL - CouchDB und andere NoSQL-Datenbanken (20)

Cloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von MetadatenCloud Computing für die Verarbeitung von Metadaten
Cloud Computing für die Verarbeitung von Metadaten
 
Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)Datenbanken - Eine Übersicht (WPMeetUP München)
Datenbanken - Eine Übersicht (WPMeetUP München)
 
RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?RDBMS oder NoSQL – warum nicht beides?
RDBMS oder NoSQL – warum nicht beides?
 
7 Top Internet-Trends
7 Top Internet-Trends7 Top Internet-Trends
7 Top Internet-Trends
 
Big Data Konnektivität
Big Data KonnektivitätBig Data Konnektivität
Big Data Konnektivität
 
Einbindung von Linked Data in existierende Bibliotheksanswendungen
Einbindung von Linked Data in existierende BibliotheksanswendungenEinbindung von Linked Data in existierende Bibliotheksanswendungen
Einbindung von Linked Data in existierende Bibliotheksanswendungen
 
Linuxtag holgerkoch openqrm_2013
Linuxtag holgerkoch openqrm_2013Linuxtag holgerkoch openqrm_2013
Linuxtag holgerkoch openqrm_2013
 
Dokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDBDokumentenorientiere Datenbanken am Beispiel CouchDB
Dokumentenorientiere Datenbanken am Beispiel CouchDB
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
 
SAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdfSAP_Basis_Klassisch.pdf
SAP_Basis_Klassisch.pdf
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
 
Web-2.0-Forschung der KWARC-Gruppe
Web-2.0-Forschung der KWARC-GruppeWeb-2.0-Forschung der KWARC-Gruppe
Web-2.0-Forschung der KWARC-Gruppe
 
SWIB 2010: Linked Open Projects
SWIB 2010: Linked Open ProjectsSWIB 2010: Linked Open Projects
SWIB 2010: Linked Open Projects
 
PostgreSQL: Die Freie Datenbankalternative
PostgreSQL: Die Freie DatenbankalternativePostgreSQL: Die Freie Datenbankalternative
PostgreSQL: Die Freie Datenbankalternative
 
Conference 2013 REST
Conference 2013 RESTConference 2013 REST
Conference 2013 REST
 
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...
Laudatio Workshop Entwicklersession zu Gemeinsamkeiten in Forschungsdatenrepo...
 
MongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwaltenMongoDB - Riesige Datenmengen schemafrei verwalten
MongoDB - Riesige Datenmengen schemafrei verwalten
 
Wir sind aber nicht Twitter
Wir sind aber nicht TwitterWir sind aber nicht Twitter
Wir sind aber nicht Twitter
 
amsl - Ergebnispräsentation der EFRE-Förderphase
amsl - Ergebnispräsentation der EFRE-Förderphaseamsl - Ergebnispräsentation der EFRE-Förderphase
amsl - Ergebnispräsentation der EFRE-Förderphase
 
DSpace 5 und Linked (Open) Data
DSpace 5 und Linked (Open) DataDSpace 5 und Linked (Open) Data
DSpace 5 und Linked (Open) Data
 

Not only SQL - CouchDB und andere NoSQL-Datenbanken

  • 1. Not only SQL CouchDB und andere NoSQL-Datenbanken Dr. Kerstin Puschke Vortrag an der HAW Hamburg 3. Juni 2010 K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 1 / 79
  • 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 2 / 79
  • 3. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik 7 Praxisbeispiel K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 3 / 79
  • 4. Übersicht 1 Einführung Relationale Datenbanksysteme Weitere Datenbanksysteme NoSQL 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik K. Puschke (Vortrag HAW Hamburg) 7 NoSQL 3. Juni 2010 4 / 79
  • 5. Relationale Datenbanksysteme in der Theorie Codd (1970) [3] Codd’s 12 Regeln (1985) [4, 5] Vollständigkeit im Sinne der relationalen Algebra in der Praxis und im Kontext des Vortrags zeilenbasierte Speicherung in Tabellen SQL als Sprache z.B. MySQL, Postgres, Oracle,. . . K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 5 / 79
  • 6. Weitere Datenbanksysteme Objektdatenbanken (db4o) XML Speicherung als Schlüssel-Wert-Paare (BerkeleyDB) spaltenorientierte Systeme (Sybase IQ) dokumentenorientierte Systeme (Lotus Notes) kaum Verbreitung im Vergleich zu relationalen Systemen frühe Formen von NoSQL? K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 6 / 79
  • 7. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 7 / 79
  • 8. NoSQL Was NoSQL manchmal (nicht) ist Verteiltes_Arbeiten Skalierbarkeit Schemafreiheit Geschwindigkeit Open_Source Open_Standards Große_Datenmengen Aufgabe_der_ACID-Prinzipien Einfache_Benutzung Fehlertoleranz Concurrency Durchsatz Zuverlässigkeit K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 8 / 79
  • 9. NoSQL Begriffsklä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 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 9 / 79
  • 10. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 10 / 79
  • 11. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? Web vs. RDBMS Verteilte Systeme 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik 7 Praxisbeispiel K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 11 / 79
  • 12. (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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 12 / 79
  • 13. Abfragen Web vs. RDBMS RDBMS dynamische Abfragen (ad hoc reporting) beliebige Abfragen über alle Daten direkt in SQL Webanwendungen wiederkehrende Abfragen, nur Parameter ändern sich K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 13 / 79
  • 14. Verteiltes Arbeiten Skalierbarkeit große Datenmengen früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung heute: preiswerte Hardware ergänzen (auch via cloud) Hochverfügbarkeit RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 14 / 79
  • 15. Verteiltes Arbeiten Skalierbarkeit große Datenmengen The largest BigTable instance manages about 6 petabytes of data spread across thousands of machines Jeff Dean, Google I/O conference, Mai 2008 (Shankland [14]) früher: nur Großrechner; Anfrageoptimierung statt Rechenleistung heute: preiswerte Hardware ergänzen (auch via cloud) Hochverfügbarkeit RDBMS: Verteiltes Arbeiten nachträglich rudimentär zugefügt K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 14 / 79
  • 16. 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! siehe Brewer [2] und Lynch & Gilbert [10] K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 15 / 79
  • 17. CAP Theorem Anwendung Availability & Consistency: Paxos, BigTable . . . Network Partitioning oft unvermeidlich trade off: Consistency vs. Availability Consistency & Partition Tolerance: viele RDBMS, . . . ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] Availability & Partition Tolerance: CouchDB, MongoDB, Cassandra, Dynamo,. . . BASE (basically available, soft-state, eventual consistency) siehe Pritchett [13] K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 16 / 79
  • 18. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs HTTP/REST MapReduce 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik 7 Praxisbeispiel K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 17 / 79
  • 19. Protokoll und API viele NoSQL-Systeme nutzen vorhandene Programmiersprachen (neo4j,. . . ) HTTP/REST (CouchDB, MongoDB,. . . ) verbreitet: MapReduce-Techniken (Parallelisierung) K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 18 / 79
  • 20. RESTful HTTP API HTTP Protokoll Browser, curl,. . . sind DB-Clients Clients in beliebiger Sprache leicht zu programmieren vorhandene Webtechnologien nutzbar Load Balancer, Proxy, HTTPS via SSL-fähigen Proxy. . . Vor- und Nachteile von HTTP K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 19 / 79
  • 21. RESTful HTTP API REpresentational State Transfer API Architekturprinzip für Kommunikation zwischen heterogenen Anwendungen geeignet für verteilte Systeme Stateless Communication jeder Request in sich geschlossen Anwendungsinformationen nur im Client keine serverseitigen Sitzungen o.ä. K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 20 / 79
  • 22. CouchDB REST/HTTP Willkommensnachricht des Servers http://localhost:5984 Alle Datenbanken anzeigen http://localhost:5984/_all_dbs Informationen über die Datenbank kontaktdaten http://localhost:5984/kontaktdaten K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 21 / 79
  • 23. MapReduce map und reduce Funktionen: Konzept aus der funktionalen Programmierung verarbeitet große Datenmengen parallel MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (Google) freie Implementierung: Hadoop K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 22 / 79
  • 24. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle Spaltenorientierung Objektorientierung Graphen Schlüssel-Wert-Paare Dokumentenorientierung 5 CouchDB 6 Herausforderungen und Kritik NoSQL K. Puschke (Vortrag HAW Hamburg) 3. Juni 2010 23 / 79
  • 25. Relationales Modell striktes Schema Tabellen und Spalten statisch zeilenorientierte Speicherung ’echte’ Beziehungen zwischen Daten foreign key constraints, joins. . . K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 24 / 79
  • 26. Spaltenorientierung erste spaltenorientierte Datenbanken in den 1970ern Cassandra, BigTable,. . . spaltenorientierte Speicherung mehr Performanz für bestimmte Abfragen z.B. Aggregieren innerhalb einer Spalte flexibleres Schema Spalten dynamisch keine ’echten’ Beziehungen K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 25 / 79
  • 27. 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} K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 26 / 79
  • 28. Cassandra’s Datenmodell Vereinfachte Darstellung verschiedene keys können verschiedene columns haben kein striktes Schema Beispiel Abfrage (:Users, 42) { username : foo, email : foo@example.com, screen_name : FOOOOO } Abfrage (:Users, 23) { username : bar, admin : yes } K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 27 / 79
  • 29. Objektorientierung Persistenzschicht für Objektorientierte Programmierung Abfragen in objektorientierter Programmiersprache OO-Programmiersprache (Java, C++,. . . ) oder DBMS-eigene Sprache db4o, JADE, Databeans,. . . K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 28 / 79
  • 30. Graphen Graphen im Sinne der Mathematik Knoten und Kanten modellieren z.B. Netzwerk, Leitungssystem,. . . Spezialfall: Baum z.B. Produktkategorien (Eltern-Kind-Beziehung) K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 29 / 79
  • 31. 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” häufige Operation: Traversierung gut geeignet für komplexe Beziehungsgeflechte z.B. social network K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 30 / 79
  • 32. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare Wert muss kein String sein (Objekte,. . . möglich) Abfrage per Schlüssel schemafrei keine ’echten’ Relationen K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 31 / 79
  • 33. 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,. . . ) üblicherweise kein leeren Felder schemafrei keine ’echten’ Relationen K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 32 / 79
  • 34. CouchDB’s Datenmodell Format: JavaScript Object Notation (JSON) Bestandteil von JavaScript wird z.T. direkt vom Browser verstanden wenig Datentypen diese werden von nahezu allen Sprachen verstanden 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 33 / 79
  • 35. CouchDB Dokument JSON Dokument mit _id 69a. . . aus Datenbank kontaktdaten http://localhost:5984/kontaktdaten/ 69a87107057813de1414e08a9f000912 K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 34 / 79
  • 36. CouchDB Dokument JSON K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 35 / 79
  • 37. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB Implementierung Updates and Concurrency Abfragen Design Documents Anwendungen 6 Herausforderungen und Kritik NoSQL K. Puschke (Vortrag HAW Hamburg) 3. Juni 2010 36 / 79
  • 38. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster auf unzuverlässiger Standardhardware Datenbanksystem (nicht nur) für Webanwendungen offene Webstandards Robuste Replikation schemafrei geeignet für unstrukturierte Daten Philosophie: entspanntes Arbeiten keine Entscheidungen, die nicht zu revidieren sind K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 37 / 79
  • 39. Implementierung Überblick HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov [16] 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 38 / 79
  • 40. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert N-Master, Master-Slave, P2P, eigene Cloud,. . . Hot failover, backup, Lastverteilung,. . . extrem robust ggf. manuell Konflikte lösen K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 39 / 79
  • 41. Updates komplettes Dokument abholen, verändern, zum Speichern zurücksenden neue Version eines Dokumentes wird an Datenbankdatei angehängt Robust: was einmal auf Platte steht, wird nicht mehr angefaßt Geschwindigkeit: neue Version kann angehängt werden, während alte noch gelesen wird K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 40 / 79
  • 42. Multi Version Concurrency Control optimistic locking Client schickt verändertes Dokument mit unveränderter Versionsnummer _rev Server prüft, ob diese _rev identisch ist mit der aktuell gespeicherten wenn ja: Dokument wird gespeichert (Server vergibt neue _rev) wenn nein: Fehlermeldung keine Versionskontrolle es werden nicht alle Versionen aufbewahrt K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 41 / 79
  • 43. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 42 / 79
  • 44. View - Beispiel Dokument eines Blogposts http://localhost:5984/simple_blog/ 17cf8a2934231a6cedc9e30fd30045a7 View http://localhost:5984/simple_blog/_design/ by-date/_view/blogposts-by-date http://localhost: 5984/_utils/database.html?simple_blog/_design/ by-date/_view/blogposts-by-date Query: Blogpost vom 12. April 2010 http://localhost:5984/simple_blog/_design/ by-date/_view/blogposts-by-date?key=[2010,4,12] Query: Blogposts aus März 2010 http://localhost:5984/simple_blog/_design/ by-date/_view/blogposts-by-date?startkey=[2010, 3,0]&endkey=[2010,3,31] K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 43 / 79
  • 45. View Beispiel View mit Schlüssel Datum und Wert Titel des Blogposts, dargestellt in Futon K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 44 / 79
  • 46. View Beispiel View mit Schlüssel Datum und Wert Titel des Blogposts, Rohansicht K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 45 / 79
  • 47. Map Reduce 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 Map-Reduce-Funktionen gespeichert in Dokumenten (Designdokumente) K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 46 / 79
  • 48. View - Beispiel Designdokument (map-Funktion) http://localhost: 5984/simple_blog/_design/by-date Designdokument (map und reduce) http://localhost: 5984/simple_blog/_design/per-date View http://localhost:5984/simple_blog/_design/ per-date/_view/posts-per-date http://localhost: 5984/_utils/database.html?simple_blog/_design/ per-date/_view/posts-per-date Gruppiert http://localhost:5984/simple_blog/_design/ per-date/_view/posts-per-date?group_level=1 K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 47 / 79
  • 49. Designdokument Beispiel Designdokument mit map-Funktion K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 48 / 79
  • 50. Designdokument Beispiel Designdokument mit map- und reduce-Funktionen K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 49 / 79
  • 51. View Beispiel View ohne reduce K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 50 / 79
  • 52. View Beispiel View mit reduce View mit reduce und group_level=2 K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 51 / 79
  • 53. Design Documents _id beginnt mit _design enthalten Anwendungscode, sprich Funktionen Map-Reduce-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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 52 / 79
  • 54. Beispiel Show Functions Design Dokument (Show) http://localhost: 5984/kontaktdaten/_design/output Dokument anzeigen http://localhost: 5984/kontaktdaten/_design/output/_show/card/ 69a87107057813de1414e08a9f000912 K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 53 / 79
  • 55. Designdokument Beispiel Designdokument mit show-Funktion K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 54 / 79
  • 56. Webanwendungen mit CouchDB Klassische Webanwendungen Serverseitige Skripte lesen Daten aus CouchDB erzeugen daraus dynamisch HTML Webserver liefert aus K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 55 / 79
  • 57. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 56 / 79
  • 58. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 57 / 79
  • 59. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten bereits realisiert in Ubuntu Bookmarks, Adreßbuch,. . . in CouchDB speichern per Replikation mit anderen Rechnern synchronisieren K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 58 / 79
  • 60. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik 7 Praxisbeispiel K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 59 / 79
  • 61. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen Zweifel an der Geschwindigkeit Stonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12] CouchApps und Co: Verteilte Identitäten serverseitiger Code nötig für Authentifizierung/Autorisierung vertrauenswürdiger Server nötig K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 60 / 79
  • 62. Übersicht 1 Einführung 2 Why Not Only SQL - warum nicht immer SQL einsetzen? 3 Protokolle & APIs 4 Datenmodelle 5 CouchDB 6 Herausforderungen und Kritik 7 Praxisbeispiel K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 61 / 79
  • 63. Einfache Bloganwendung ER-Diagramm K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 62 / 79
  • 64. Einfache Bloganwendung Relationes Schema Tabelle Posts mit Spalten post_id, Titel, Text, user, Datum Tabelle Kommentare mit Spalten comment_id, Text, user, Datum, post_id foreign key constraint Kommentare.post_id, Posts.post_id K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 63 / 79
  • 65. Einfache Bloganwendung ER-Diagramm Dokumentenorientierter Ansatz? K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 64 / 79
  • 66. Einfache Bloganwendung Blogpost ohne Kommentare http://localhost: 5984/blog0/cc50e8668ff421c1c09be1b71000077a K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 65 / 79
  • 67. Einfache Bloganwendung Blogpost ohne Kommentare K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 66 / 79
  • 68. Einfache Bloganwendung Blogpost mit Kommentare “inline” K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 67 / 79
  • 69. Einfache Bloganwendung Kommentar als eigenes Dokument K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 68 / 79
  • 70. Einfache Bloganwendung Kommentar als eigenes Dokument View zur Ausgabe von Posts mit zugehörigen Kommentaren zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw. Kommentar map-Funktion function(doc) { if (doc.type == "post") { emit([doc._id, 0], doc); } else if (doc.type == "comment") { emit([doc.post_id, 1], doc); } } K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 69 / 79
  • 71. Einfache Bloganwendung Kommentar als eigenes Dokument View zur Ausgabe von Posts mit zugehörigen Kommentaren zusammengesetzter Schlüssel mit _id und 0 bzw. 1 für Post bzw. Kommentar K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 70 / 79
  • 72. Einfache Bloganwendung Blogposts und Kommentare Kommentare “inline” Direkter Zugriff auf Kommentare durch geeigneten View Vorteil: alles beisammen, beim Löschen des Posts werden alle Kommentare mit gelöscht,. . . Nachteil: jeder neue Kommentar ist ein Update des Posts; bei vielen Kommentaren Konflikte wahrscheinlich Alternative: Kommentare in eigenen Dokumenten Gemeinsame Ausgabe eines Posts und seiner Kommetare durch geeigeneten View K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 71 / 79
  • 73. Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit! Fragen und Anmerkungen? K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 72 / 79
  • 74. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 73 / 79
  • 75. 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 and Implementation. 2004. URL http://labs.google.com/papers/mapreduce.html. K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 74 / 79
  • 76. Referenzen III Jim Gray. The transaction concept: Virtues and limitations. In Proceedings of the 7th International Conference on Very Large Databases, 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 75 / 79
  • 77. 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 76 / 79
  • 78. 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 SIGMOD International 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 77 / 79
  • 79. Referenzen VI Stephen Shankland. Google spotlights data center inner workings. cnet news, Mai 2008. URL http://news.cnet.com/8301-10784_3-9955184-7.html. Michael Stonebraker, Daniel Abadi, David J. DeWitt, Sam Madden, 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 (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 78 / 79
  • 80. Referenzen VII Stefan Tilkov. A brief introduction to rest. Info Queue, 2007. URL http://www.infoq.com/articles/rest-introduction. K. Puschke (Vortrag HAW Hamburg) NoSQL 3. Juni 2010 79 / 79