NoSQL-Datenbanken am Beispiel CouchDB

NoSQL-Datenbanken am Beispiel CouchDB

Vortrag an der Uni Bremen

5e8e44a4f6632772c47925006aff31d9?s=128

Kerstin Puschke

September 13, 2010
Tweet

Transcript

  1. NoSQL-Datenbanken am Beispiel CouchDB Dr. Kerstin Puschke Freie Universität Berlin

    13. September 2010 K. Puschke (FU Berlin) NoSQL 13. September 2010 1 / 55
  2. Übersicht 1 Einführung K. Puschke (FU Berlin) NoSQL 13. September

    2010 2 / 55
  3. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? K. Puschke (FU Berlin) NoSQL 13. September 2010 2 / 55
  4. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? 3 Datenmodelle K. Puschke (FU Berlin) NoSQL 13. September 2010 2 / 55
  5. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? 3 Datenmodelle 4 CouchDB K. Puschke (FU Berlin) NoSQL 13. September 2010 2 / 55
  6. Ü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
  7. Übersicht 1 Einführung Relationale Datenbanksysteme Weitere Datenbanksysteme NoSQL 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
  8. Relationale Datenbanksysteme in der Theorie K. Puschke (FU Berlin) NoSQL

    13. September 2010 4 / 55
  9. Relationale Datenbanksysteme in der Theorie Codd (1970) [3] K. Puschke

    (FU Berlin) NoSQL 13. September 2010 4 / 55
  10. Relationale Datenbanksysteme in der Theorie Codd (1970) [3] Codd’s 12

    Regeln (1985) [4, 5] K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  11. Relationale Datenbanksysteme in der Theorie Codd (1970) [3] Codd’s 12

    Regeln (1985) [4, 5] Vollständigkeit im Sinne der relationalen Algebra K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  12. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  13. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  14. 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 oder vergleichbare Sprache K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  15. 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 oder vergleichbare Sprache z.B. MySQL, Postgres, Oracle,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 4 / 55
  16. Weitere Datenbanksysteme Objektdatenbanken (db4o) K. Puschke (FU Berlin) NoSQL 13.

    September 2010 5 / 55
  17. Weitere Datenbanksysteme Objektdatenbanken (db4o) XML K. Puschke (FU Berlin) NoSQL

    13. September 2010 5 / 55
  18. Weitere Datenbanksysteme Objektdatenbanken (db4o) XML Speicherung als Schlüssel-Wert-Paare (BerkeleyDB) K.

    Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55
  19. Weitere Datenbanksysteme Objektdatenbanken (db4o) XML Speicherung als Schlüssel-Wert-Paare (BerkeleyDB) spaltenorientierte

    Systeme (Sybase IQ) K. Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55
  20. Weitere Datenbanksysteme Objektdatenbanken (db4o) XML Speicherung als Schlüssel-Wert-Paare (BerkeleyDB) spaltenorientierte

    Systeme (Sybase IQ) dokumentenorientierte Systeme (Lotus Notes) K. Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55
  21. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 5 / 55
  22. 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 (FU Berlin) NoSQL 13. September 2010 5 / 55
  23. NoSQL Begriffsklärung 2009 als Sammelbegriff für bereits länger existierende Systeme

    etabliert K. Puschke (FU Berlin) NoSQL 13. September 2010 6 / 55
  24. NoSQL Begriffsklärung 2009 als Sammelbegriff für bereits länger existierende Systeme

    etabliert Not only SQL K. Puschke (FU Berlin) NoSQL 13. September 2010 6 / 55
  25. NoSQL Begriffsklärung 2009 als Sammelbegriff für bereits länger existierende Systeme

    etabliert Not only SQL keine eindeutige Definition K. Puschke (FU Berlin) NoSQL 13. September 2010 6 / 55
  26. 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 (FU Berlin) NoSQL 13. September 2010 6 / 55
  27. 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 (FU Berlin) NoSQL 13. September 2010 7 / 55
  28. NoSQL Begriffsklärung Ankündigung no:sql(eu) conference, April 2010 [11] . .

    . era of “one-size-fits-all database” seems to be over. K. Puschke (FU Berlin) NoSQL 13. September 2010 8 / 55
  29. 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. K. Puschke (FU Berlin) NoSQL 13. September 2010 8 / 55
  30. 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 (FU Berlin) NoSQL 13. September 2010 8 / 55
  31. NoSQL-Systeme im Einsatz CouchDB (BBC, Ubuntu One) K. Puschke (FU

    Berlin) NoSQL 13. September 2010 9 / 55
  32. NoSQL-Systeme im Einsatz CouchDB (BBC, Ubuntu One) BigTable (GoogleMaps, GoogleReader,

    YouTube. . . ) K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55
  33. NoSQL-Systeme im Einsatz CouchDB (BBC, Ubuntu One) BigTable (GoogleMaps, GoogleReader,

    YouTube. . . ) Dynamo (Amazon Webservices, Amazon) K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55
  34. NoSQL-Systeme im Einsatz CouchDB (BBC, Ubuntu One) BigTable (GoogleMaps, GoogleReader,

    YouTube. . . ) Dynamo (Amazon Webservices, Amazon) Cassandra (Twitter, Facebook,. . . ) K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55
  35. NoSQL-Systeme im Einsatz CouchDB (BBC, Ubuntu One) BigTable (GoogleMaps, GoogleReader,

    YouTube. . . ) Dynamo (Amazon Webservices, Amazon) Cassandra (Twitter, Facebook,. . . ) Project Voldemort (linkedin) K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55
  36. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 9 / 55
  37. 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
  38. 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
  39. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? Web vs. RDBMS Verteilte Systeme NoSQL vs. SQL 3 Datenmodelle 4 CouchDB 5 Herausforderungen und Kritik K. Puschke (FU Berlin) NoSQL 13. September 2010 10 / 55
  40. (Un)strukturierte Daten Web vs. RDBMS RDBMS K. Puschke (FU Berlin)

    NoSQL 13. September 2010 11 / 55
  41. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend K. Puschke

    (FU Berlin) NoSQL 13. September 2010 11 / 55
  42. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend aufwändig zu

    entwerfen: Normalisierung,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55
  43. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend aufwändig zu

    entwerfen: Normalisierung,. . . nachträglich schwierig zu ändern K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55
  44. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend aufwändig zu

    entwerfen: Normalisierung,. . . nachträglich schwierig zu ändern stark strukturiert K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55
  45. (Un)strukturierte Daten Web vs. RDBMS RDBMS Datenbankschema entscheidend aufwändig zu

    entwerfen: Normalisierung,. . . nachträglich schwierig zu ändern stark strukturiert Webanwendungen K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55
  46. (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 K. Puschke (FU Berlin) NoSQL 13. September 2010 11 / 55
  47. (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 (FU Berlin) NoSQL 13. September 2010 11 / 55
  48. Abfragen Web vs. RDBMS RDBMS K. Puschke (FU Berlin) NoSQL

    13. September 2010 12 / 55
  49. Abfragen Web vs. RDBMS RDBMS dynamische Abfragen (ad hoc reporting)

    beliebige Abfragen über alle Daten direkt in SQL K. Puschke (FU Berlin) NoSQL 13. September 2010 12 / 55
  50. Abfragen Web vs. RDBMS RDBMS dynamische Abfragen (ad hoc reporting)

    beliebige Abfragen über alle Daten direkt in SQL Webanwendungen K. Puschke (FU Berlin) NoSQL 13. September 2010 12 / 55
  51. 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 (FU Berlin) NoSQL 13. September 2010 12 / 55
  52. Verteiltes Arbeiten Skalierbarkeit K. Puschke (FU Berlin) NoSQL 13. September

    2010 13 / 55
  53. 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]) K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
  54. Verteiltes Arbeiten Skalierbarkeit große Datenmengen früher: nur Großrechner; Anfrageoptimierung statt

    Rechenleistung K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
  55. Verteiltes Arbeiten Skalierbarkeit große Datenmengen früher: nur Großrechner; Anfrageoptimierung statt

    Rechenleistung heute: preiswerte Hardware ergänzen (auch via cloud) K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
  56. Verteiltes Arbeiten Skalierbarkeit große Datenmengen früher: nur Großrechner; Anfrageoptimierung statt

    Rechenleistung heute: preiswerte Hardware ergänzen (auch via cloud) Hochverfügbarkeit K. Puschke (FU Berlin) NoSQL 13. September 2010 13 / 55
  57. 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 (FU Berlin) NoSQL 13. September 2010 13 / 55
  58. CAP Theorem Consistency, Availability, Partition Tolerance Theorem K. Puschke (FU

    Berlin) NoSQL 13. September 2010 14 / 55
  59. 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. K. Puschke (FU Berlin) NoSQL 13. September 2010 14 / 55
  60. 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. K. Puschke (FU Berlin) NoSQL 13. September 2010 14 / 55
  61. 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. K. Puschke (FU Berlin) NoSQL 13. September 2010 14 / 55
  62. 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 (FU Berlin) NoSQL 13. September 2010 14 / 55
  63. C,A oder P? abhängig vom gewählten DBMS K. Puschke (FU

    Berlin) NoSQL 13. September 2010 15 / 55
  64. C,A oder P? abhängig vom gewählten DBMS abhängig vom Setup

    K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55
  65. C,A oder P? abhängig vom gewählten DBMS abhängig vom Setup

    abhängig von der Konfiguration - u.U. sogar pro Abfrage K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55
  66. C,A oder P? abhängig vom gewählten DBMS abhängig vom Setup

    abhängig von der Konfiguration - u.U. sogar pro Abfrage Network Partitioning oft unvermeidlich trade off: Consistency vs. Availability K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55
  67. C,A oder P? abhängig vom gewählten DBMS abhängig vom Setup

    abhängig von der Konfiguration - u.U. sogar pro Abfrage Network Partitioning oft unvermeidlich trade off: Consistency vs. Availability Abstufungen möglich K. Puschke (FU Berlin) NoSQL 13. September 2010 15 / 55
  68. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  69. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  70. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  71. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  72. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] pessimistic locking K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  73. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] pessimistic locking Availability & Partition Tolerance: CouchDB, MongoDB, Cassandra, Dynamo,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  74. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] pessimistic locking Availability & Partition Tolerance: CouchDB, MongoDB, Cassandra, Dynamo,. . . Weak Consistency, Eventual Consistency K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  75. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] pessimistic locking Availability & Partition Tolerance: CouchDB, MongoDB, Cassandra, Dynamo,. . . Weak Consistency, Eventual Consistency BASE (basically available, soft-state, eventual consistency) siehe Pritchett [13] K. Puschke (FU Berlin) NoSQL 13. September 2010 16 / 55
  76. CAP Theorem Häufige Settings Availability & Consistency: VoltDB, BigTable .

    . . Consistency & Partition Tolerance: viele RDBMS, . . . Strong Consistency, Enforced Consistency ACID (atomicity, consistency, isolation, durability) siehe Gray [7] und Haerder & Reuter [8] pessimistic locking Availability & Partition Tolerance: CouchDB, MongoDB, Cassandra, Dynamo,. . . Weak Consistency, Eventual Consistency BASE (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
  77. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  78. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  79. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  80. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz . . . K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  81. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz . . . dadurch aber Verlust vieler Vorteile, z.B. K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  82. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz . . . dadurch aber Verlust vieler Vorteile, z.B. Verlust von ACID-Garantien, K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  83. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz . . . dadurch aber Verlust vieler Vorteile, z.B. Verlust von ACID-Garantien, referentieller Integrität, K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  84. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus auf Verfügbarkeit statt Konsistenz . . . dadurch aber Verlust vieler Vorteile, z.B. Verlust von ACID-Garantien, referentieller Integrität, . . . K. Puschke (FU Berlin) NoSQL 13. September 2010 17 / 55
  85. NoSQL vs. SQL Nachteile auch in RDBMS vermeidbar, z.B. durch

    Verzicht auf Normalisierung Fokus 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
  86. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? 3 Datenmodelle Spaltenorientierung Objektorientierung Graphen Schlüssel-Wert-Paare Dokumentenorientierung 4 CouchDB 5 Herausforderungen und Kritik K. Puschke (FU Berlin) NoSQL 13. September 2010 18 / 55
  87. Relationales Modell striktes Schema Tabellen und Spalten statisch K. Puschke

    (FU Berlin) NoSQL 13. September 2010 19 / 55
  88. Relationales Modell striktes Schema Tabellen und Spalten statisch zeilenorientierte Speicherung

    K. Puschke (FU Berlin) NoSQL 13. September 2010 19 / 55
  89. Relationales Modell striktes Schema Tabellen und Spalten statisch zeilenorientierte Speicherung

    ’echte’ Beziehungen zwischen Daten foreign key constraints, joins. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 19 / 55
  90. Spaltenorientierung erste spaltenorientierte Datenbanken in den 1970ern K. Puschke (FU

    Berlin) NoSQL 13. September 2010 20 / 55
  91. Spaltenorientierung erste spaltenorientierte Datenbanken in den 1970ern Cassandra, BigTable,. .

    . K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55
  92. Spaltenorientierung erste spaltenorientierte Datenbanken in den 1970ern Cassandra, BigTable,. .

    . spaltenorientierte Speicherung K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55
  93. Spaltenorientierung erste spaltenorientierte Datenbanken in den 1970ern Cassandra, BigTable,. .

    . spaltenorientierte Speicherung mehr Performanz für bestimmte Abfragen z.B. Aggregieren innerhalb einer Spalte K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55
  94. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 20 / 55
  95. 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 (FU Berlin) NoSQL 13. September 2010 20 / 55
  96. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace K. Puschke (FU Berlin) NoSQL

    13. September 2010 21 / 55
  97. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace entspricht der Anwendung; Beispiel: ’Blog’

    K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  98. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace entspricht der Anwendung; Beispiel: ’Blog’

    column family K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  99. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace entspricht der Anwendung; Beispiel: ’Blog’

    column family entspricht einer Datei K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  100. Cassandra’s Datenmodell Vereinfachte Darstellung keyspace entspricht der Anwendung; Beispiel: ’Blog’

    column family entspricht einer Datei Beispiel: ’Posts’ oder ’Users’ K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  101. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  102. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  103. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  104. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  105. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  106. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  107. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  108. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 21 / 55
  109. 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 (FU Berlin) NoSQL 13. September 2010 21 / 55
  110. Cassandra’s Datenmodell Vereinfachte Darstellung verschiedene keys können verschiedene columns haben

    K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55
  111. Cassandra’s Datenmodell Vereinfachte Darstellung verschiedene keys können verschiedene columns haben

    kein striktes Schema K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55
  112. 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 } K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55
  113. 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 } K. Puschke (FU Berlin) NoSQL 13. September 2010 22 / 55
  114. 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 (FU Berlin) NoSQL 13. September 2010 22 / 55
  115. Objektorientierung Persistenzschicht für Objektorientierte Programmierung K. Puschke (FU Berlin) NoSQL

    13. September 2010 23 / 55
  116. Objektorientierung Persistenzschicht für Objektorientierte Programmierung Abfragen in objektorientierter Programmiersprache K.

    Puschke (FU Berlin) NoSQL 13. September 2010 23 / 55
  117. Objektorientierung Persistenzschicht für Objektorientierte Programmierung Abfragen in objektorientierter Programmiersprache OO-Programmiersprache

    (Java, C++,. . . ) oder DBMS-eigene Sprache K. Puschke (FU Berlin) NoSQL 13. September 2010 23 / 55
  118. Objektorientierung Persistenzschicht für Objektorientierte Programmierung Abfragen in objektorientierter Programmiersprache OO-Programmiersprache

    (Java, C++,. . . ) oder DBMS-eigene Sprache db4o, JADE, Databeans,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 23 / 55
  119. Graphen Graphen im Sinne der Mathematik K. Puschke (FU Berlin)

    NoSQL 13. September 2010 24 / 55
  120. Graphen Graphen im Sinne der Mathematik Knoten und Kanten K.

    Puschke (FU Berlin) NoSQL 13. September 2010 24 / 55
  121. Graphen Graphen im Sinne der Mathematik Knoten und Kanten modellieren

    z.B. Netzwerk, Leitungssystem,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 24 / 55
  122. Graphen Graphen im Sinne der Mathematik Knoten und Kanten modellieren

    z.B. Netzwerk, Leitungssystem,. . . Spezialfall: Baum z.B. Produktkategorien (Eltern-Kind-Beziehung) K. Puschke (FU Berlin) NoSQL 13. September 2010 24 / 55
  123. Graphendatenbanken InfoGrid, neo4j, . . . K. Puschke (FU Berlin)

    NoSQL 13. September 2010 25 / 55
  124. Graphendatenbanken InfoGrid, neo4j, . . . Daten als Graphen K.

    Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  125. Graphendatenbanken InfoGrid, neo4j, . . . Daten als Graphen Knoten

    eigenständige Objekte wie Kunde, Bestellung,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  126. Graphendatenbanken InfoGrid, neo4j, . . . Daten als Graphen Knoten

    eigenständige Objekte wie Kunde, Bestellung,. . . Kanten sind Beziehungen zwischen Knoten K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  127. Graphendatenbanken InfoGrid, neo4j, . . . Daten als Graphen Knoten

    eigenständige Objekte wie Kunde, Bestellung,. . . Kanten sind Beziehungen zwischen Knoten schematisiert oder schemafrei K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  128. 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” K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  129. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 25 / 55
  130. 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 (FU Berlin) NoSQL 13. September 2010 25 / 55
  131. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . K. Puschke (FU Berlin)

    NoSQL 13. September 2010 26 / 55
  132. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare K. Puschke (FU

    Berlin) NoSQL 13. September 2010 26 / 55
  133. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare Abfrage per Schlüssel

    K. Puschke (FU Berlin) NoSQL 13. September 2010 26 / 55
  134. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare Abfrage per Schlüssel

    schemafrei K. Puschke (FU Berlin) NoSQL 13. September 2010 26 / 55
  135. Schlüssel-Wert-Paare Riak, Tokyo Cabinet,. . . Schlüssel-Wert-Paare Abfrage per Schlüssel

    schemafrei keine ’echten’ Relationen K. Puschke (FU Berlin) NoSQL 13. September 2010 26 / 55
  136. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . K. Puschke (FU Berlin)

    NoSQL 13. September 2010 27 / 55
  137. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . Dokument: weitere Abstraktionsebene oberhalb

    von Schlüssel-Wert-Paaren K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
  138. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . Dokument: weitere Abstraktionsebene oberhalb

    von Schlüssel-Wert-Paaren für sich genommen sinnvolle Informationseinheit K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
  139. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . Dokument: weitere Abstraktionsebene oberhalb

    von Schlüssel-Wert-Paaren für sich genommen sinnvolle Informationseinheit meist Entsprechung im Real Life (Rechnung, Visitenkarte,. . . ) K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
  140. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
  141. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 27 / 55
  142. Dokumentenorientierung CouchDB, MongoDB, Riak,. . . 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 (FU Berlin) NoSQL 13. September 2010 27 / 55
  143. CouchDB’s Datenmodell Format: JavaScript Object Notation (JSON) K. Puschke (FU

    Berlin) NoSQL 13. September 2010 28 / 55
  144. CouchDB’s Datenmodell Format: JavaScript Object Notation (JSON) Bestandteil von JavaScript

    K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  145. CouchDB’s Datenmodell Format: JavaScript Object Notation (JSON) Bestandteil von JavaScript

    wird z.T. direkt vom Browser verstanden K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  146. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  147. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  148. 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: K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  149. 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), K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  150. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 28 / 55
  151. 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 (FU Berlin) NoSQL 13. September 2010 28 / 55
  152. CouchDB Dokument JSON K. Puschke (FU Berlin) NoSQL 13. September

    2010 29 / 55
  153. Übersicht 1 Einführung 2 Why Not Only SQL - warum

    nicht immer SQL einsetzen? 3 Datenmodelle 4 CouchDB Implementierung Updates and Concurrency Abfragen Design Documents Anwendungen 5 Herausforderungen und Kritik K. Puschke (FU Berlin) NoSQL 13. September 2010 30 / 55
  154. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster

    auf unzuverlässiger Standardhardware K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
  155. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster

    auf unzuverlässiger Standardhardware Datenbanksystem (nicht nur) für Webanwendungen K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
  156. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster

    auf unzuverlässiger Standardhardware Datenbanksystem (nicht nur) für Webanwendungen offene Webstandards K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
  157. Was ist CouchDB? Cluster Of Unreliable Commodity Hardware DataBase Datenbankcluster

    auf unzuverlässiger Standardhardware Datenbanksystem (nicht nur) für Webanwendungen offene Webstandards Robuste Replikation K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
  158. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 31 / 55
  159. 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 (FU Berlin) NoSQL 13. September 2010 31 / 55
  160. Implementierung Überblick HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov

    [16] K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  161. Implementierung Überblick HTTP/REST (Webserver enthalten) bzgl. REST siehe auch Tilkov

    [16] Erlang funktional, fehlertolerant, concurrency optimiert K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  162. 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,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  163. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  164. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  165. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  166. 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 (lokal), optimistic locking, Multi Version Concurrency Control K. Puschke (FU Berlin) NoSQL 13. September 2010 32 / 55
  167. Replikation shared nothing cluster Server unabhängig voneinander K. Puschke (FU

    Berlin) NoSQL 13. September 2010 33 / 55
  168. Replikation shared nothing cluster Server unabhängig voneinander inkrementell K. Puschke

    (FU Berlin) NoSQL 13. September 2010 33 / 55
  169. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert K.

    Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
  170. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert N-Master,

    Master-Slave,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
  171. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert N-Master,

    Master-Slave,. . . Hot failover, backup, Lastverteilung,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
  172. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert N-Master,

    Master-Slave,. . . Hot failover, backup, Lastverteilung,. . . extrem robust vermeidet die Fallacies of Distributed Computing K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
  173. Replikation shared nothing cluster Server unabhängig voneinander inkrementell gefiltert N-Master,

    Master-Slave,. . . Hot failover, backup, Lastverteilung,. . . extrem robust vermeidet die Fallacies of Distributed Computing ggf. manuell Konflikte lösen K. Puschke (FU Berlin) NoSQL 13. September 2010 33 / 55
  174. Updates komplettes Dokument abholen, verändern, zum Speichern zurücksenden K. Puschke

    (FU Berlin) NoSQL 13. September 2010 34 / 55
  175. Updates komplettes Dokument abholen, verändern, zum Speichern zurücksenden neue Version

    eines Dokumentes wird an Datenbankdatei angehängt K. Puschke (FU Berlin) NoSQL 13. September 2010 34 / 55
  176. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 34 / 55
  177. 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 (FU Berlin) NoSQL 13. September 2010 34 / 55
  178. Multi Version Concurrency Control optimistic locking K. Puschke (FU Berlin)

    NoSQL 13. September 2010 35 / 55
  179. Multi Version Concurrency Control optimistic locking Client schickt verändertes Dokument

    mit unveränderter Versionsnummer _rev K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
  180. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
  181. 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) K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
  182. 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: Konflikt K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
  183. 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: Konflikt keine Versionskontrolle es werden nicht alle Versionen aufbewahrt K. Puschke (FU Berlin) NoSQL 13. September 2010 35 / 55
  184. View (secondary) Index (Schlüssel-Wert-Paare) K. Puschke (FU Berlin) NoSQL 13.

    September 2010 36 / 55
  185. View (secondary) Index (Schlüssel-Wert-Paare) Schlüssel und Werte des Views sind

    Werte aus Dokumenten K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  186. 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. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  187. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  188. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  189. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  190. 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’ K. Puschke (FU Berlin) NoSQL 13. September 2010 36 / 55
  191. 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 (FU Berlin) NoSQL 13. September 2010 36 / 55
  192. View Beispiel View mit Schlüssel Datum und Wert Titel des

    Blogposts, dargestellt in Futon K. Puschke (FU Berlin) NoSQL 13. September 2010 37 / 55
  193. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
  194. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6] K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
  195. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6] map verarbeitet Dokumente erzeugt Schlüssel-Wert-Paare K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
  196. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6] map verarbeitet Dokumente erzeugt Schlüssel-Wert-Paare optionales reduce erzeugt aggregierte (Zwischen)Werte verarbeitet Ergebnisse von map oder rekursiv Zwischenergebnisse von reduce K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
  197. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6] 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 38 / 55
  198. Map Reduce View erzeugen map und reduce Funktionen: Konzept aus

    der funktionalen Programmierung parallele Verarbeitung großer Datenmengen MapReduce: framework zur verteilten Verarbeitung großer Datenmengen (freie Implementierung: Hadoop)siehe Dean & Ghemawat [6] 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 (FU Berlin) NoSQL 13. September 2010 38 / 55
  199. View Beispiel View ohne reduce K. Puschke (FU Berlin) NoSQL

    13. September 2010 39 / 55
  200. View Beispiel View mit reduce K. Puschke (FU Berlin) NoSQL

    13. September 2010 40 / 55
  201. View Beispiel View mit reduce View mit reduce und group_level=2

    K. Puschke (FU Berlin) NoSQL 13. September 2010 40 / 55
  202. Design Documents _id beginnt mit _design K. Puschke (FU Berlin)

    NoSQL 13. September 2010 41 / 55
  203. Design Documents _id beginnt mit _design enthalten Anwendungscode, sprich Funktionen

    K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55
  204. Design Documents _id beginnt mit _design enthalten Anwendungscode, sprich Funktionen

    Map-Reduce-Funktionen für Views K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55
  205. 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,. . . K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55
  206. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 41 / 55
  207. 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 (FU Berlin) NoSQL 13. September 2010 41 / 55
  208. Webanwendungen mit CouchDB Klassische Webanwendungen Serverseitige Skripte lesen Daten aus

    CouchDB K. Puschke (FU Berlin) NoSQL 13. September 2010 42 / 55
  209. Webanwendungen mit CouchDB Klassische Webanwendungen Serverseitige Skripte lesen Daten aus

    CouchDB erzeugen daraus dynamisch HTML K. Puschke (FU Berlin) NoSQL 13. September 2010 42 / 55
  210. Webanwendungen mit CouchDB Klassische Webanwendungen Serverseitige Skripte lesen Daten aus

    CouchDB erzeugen daraus dynamisch HTML Webserver liefert aus K. Puschke (FU Berlin) NoSQL 13. September 2010 42 / 55
  211. Webanwendungen mit CouchDB CouchApps leben vollständig in der Datenbank K.

    Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55
  212. Webanwendungen mit CouchDB CouchApps leben vollständig in der Datenbank keine

    middleware K. Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55
  213. Webanwendungen mit CouchDB CouchApps leben vollständig in der Datenbank keine

    middleware Show/List-Funktionen K. Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55
  214. Webanwendungen mit CouchDB CouchApps leben vollständig in der Datenbank keine

    middleware Show/List-Funktionen Attachments (HTML,CSS, Javascript) direkt ausliefern K. Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55
  215. 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 43 / 55
  216. 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 (FU Berlin) NoSQL 13. September 2010 43 / 55
  217. Dezentrale offline Webanwendung Ein Usecase für CouchApps Daten und Anwendung

    lokal beim user K. Puschke (FU Berlin) NoSQL 13. September 2010 44 / 55
  218. Dezentrale offline Webanwendung Ein Usecase für CouchApps Daten und Anwendung

    lokal beim user offline verfügbar K. Puschke (FU Berlin) NoSQL 13. September 2010 44 / 55
  219. Dezentrale offline Webanwendung Ein Usecase für CouchApps Daten und Anwendung

    lokal beim user offline verfügbar lokale Datenhaltung = niedrige Latenz K. Puschke (FU Berlin) NoSQL 13. September 2010 44 / 55
  220. Dezentrale offline Webanwendung Ein Usecase für CouchApps Daten und Anwendung

    lokal beim user offline verfügbar lokale Datenhaltung = niedrige Latenz dezentral K. Puschke (FU Berlin) NoSQL 13. September 2010 44 / 55
  221. 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 (FU Berlin) NoSQL 13. September 2010 44 / 55
  222. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten K. Puschke (FU Berlin) NoSQL

    13. September 2010 45 / 55
  223. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten bereits realisiert in Ubuntu K.

    Puschke (FU Berlin) NoSQL 13. September 2010 45 / 55
  224. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten bereits realisiert in Ubuntu Bookmarks,

    Adreßbuch,. . . in CouchDB speichern K. Puschke (FU Berlin) NoSQL 13. September 2010 45 / 55
  225. Desktop-Anwendungen Beispiel: Synchronisation von Anwendungsdaten bereits realisiert in Ubuntu Bookmarks,

    Adreßbuch,. . . in CouchDB speichern per Replikation mit anderen Rechnern synchronisieren K. Puschke (FU Berlin) NoSQL 13. September 2010 45 / 55
  226. Ü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
  227. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  228. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  229. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  230. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen Zweifel am Geschwindigkeitsvorteil von NoSQL-Systemen Stonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12] K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  231. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen Zweifel am Geschwindigkeitsvorteil von NoSQL-Systemen Stonebraker et al. [15], siehe auch Lai [9] und Pavlo et al. [12] CouchApps und Co: Verteilte Identitäten K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  232. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen Zweifel am Geschwindigkeitsvorteil von NoSQL-Systemen 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 K. Puschke (FU Berlin) NoSQL 13. September 2010 47 / 55
  233. Herausforderungen und Kritik HTML/JS, HTTP,. . . vorhandene Probleme bleiben

    bestehen kein ad hoc reporting BASE vs. ACID Zuverlässigkeit z.B. bei Finanztransaktionen Zweifel am Geschwindigkeitsvorteil von NoSQL-Systemen 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 (FU Berlin) NoSQL 13. September 2010 47 / 55
  234. Noch Fragen? Vielen Dank für Ihre Aufmerksamkeit! Fragen und Anmerkungen?

    K. Puschke (FU Berlin) NoSQL 13. September 2010 48 / 55
  235. Referenzen I J. Chris Anderson, Jan Lehnardt, and Noah Slater.

    CouchDB: The definitive Guide. O’Reilly, 2010. URL http://books.couchdb.org/relax/.
  236. 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 (FU Berlin) NoSQL 13. September 2010 50 / 55
  237. 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 (FU Berlin) NoSQL 13. September 2010 51 / 55
  238. 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
  239. 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 (FU Berlin) NoSQL 13. September 2010 53 / 55
  240. 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 (FU Berlin) NoSQL 13. September 2010 54 / 55
  241. Referenzen VII Stefan Tilkov. A brief introduction to rest. Info

    Queue, 2007. URL http://www.infoq.com/articles/rest-introduction.