NoSQL meets mobile.cologne           mobile.cologne            2013-03-14       Jan Steemann (triAGENS)                  ©...
about:self   Entwickler bei der triAGENS GmbH   Dokumentendatenbank      vi, C/C++, Linux, open source...              ...
NoSQL matters 2013   Konferenz zu NoSQL-Themen & -Produkten:    Redis, Riak, MongoDB, CouchDB, ...   optionaler Training...
To SQL ornot to SQL?        © 2013 triAGENS GmbH | 2013-03-14
Relationale Datenbanken   „SQL-Datenbanken“ sind relationale Datenbanken, die    mit SQL abgefragt werden   sie basieren...
Normalisierung   relationales Gebot: du sollst Daten normalisiert    speichern (Normalformen 1 - x)   durch Normalisieru...
Problem: Skalierung       relationale Datenbanken sind nur schwer zu        skalieren, denn       SQL erlaubt grundsätzl...
Problem: Skalierung   in einem Cluster müssen sich einzelne Server    absprechen, damit die Konsistenz gewahrt    bleibt,...
Problem: Schemas   die Verwendung von festen Schemas    bedeutet, dass nur Daten gespeichert werden    können, die das Sc...
Problem: Schemas   zum Speichern von Objekten in relationalen    Datenbanken braucht man viel Code oder ORMs:    var user...
Problem: Performance   Verwendung von SQL bedeutet Overhead:    query parsing, query planning, …   braucht man für folge...
NoSQLto the rescue?        © 2013 triAGENS GmbH | 2013-03-14
Neue Ansätze   in den letzten Jahren sind viele neue    Datenbanken entstanden   diese lösen oder umgehen die genannten ...
„NoSQL“   eine Gemeinsamkeit der meisten neueren    Datenbanken ist, dass sie auf SQL als    Abfragesprache verzichten  ...
NoSQL == non-relational   so gut wie alle NoSQL-Datenbanken sind    „non-relational“ und verwenden nicht das    relationa...
NoSQL & Skalierung?       „NoSQL“ bedeutet nicht automatisch        Skalierung       es existieren im NoSQL-Bereich...  ...
Skalierung       In verteilten Datenbanken wird die Skalierbarkeit oft        „erkauft“ durch Abstriche bei Features:    ...
NoSQL-Kategorien       die meisten NoSQL-Datenbanken können        folgenden Kategorien zugeordnet werden:   Key / value ...
NoSQL-Datenbanken   in jeder Kategorie existieren viele, durchaus    unterschiedliche Implementierungen   ausführliche L...
Key / valuestores        © 2013 triAGENS GmbH | 2013-03-14
Prinzip   für einen (eindeutigen) Key wird jeweils ein    Wert (Value) gespeichert   verschiedene Keys sind unabhängig  ...
Beispiele   Zugriff erfolgt immer über eindeutigen Key:    store.put("obj3", "{ a: 1, b: 1 }")    store.remove("obj2");  ...
Eigenschaften       wenig Overhead, denn   Werteinhalte werden vom store „ignoriert“ (kein       Parsing, kein Schema, k...
Beispiel memcached (single server)   in-memory only   simples Protokoll mit Operationen wie z. B.    GET / SET / ADD / R...
Beispiel redis (single server)       in-memory / snapshots / changelogs       single threaded       erweitert das simpl...
Distributed key / value stores   Simples key / value-Modell erlaubt horizontale    Skalierung: keys werden per Hash-Funkt...
Beispiel riak (distributed)   konfigurierbare Backends (durable / memory)   automatisches Failover und Re-Balancing   Z...
Document stores       © 2013 triAGENS GmbH | 2013-03-14
Prinzip   Document stores speichern „Dokumente“:    zusammengesetzte Objekte mit benannten    Attributen, auf die einzeln...
Prinzip   Dokumente derselben Domäne werden in    derselben „Collection“ gespeichert (Äquivalent    zur Tabelle in relati...
Beispiele   Speichern von Dokumenten:    db.users.save({               verschiedene Dokumenttypen      _id: "user1",     ...
Eigenschaften   Listen können direkt in Dokumente    eingebettet und abgefragt werden, ohne    zusätzliche Collections:  ...
Beispiel CouchDB   ACID-Garantien für Operationen auf einer    „Database“   Abfragen über Dokument-Keys oder „Views“    ...
Graph databases       © 2013 triAGENS GmbH | 2013-03-14
Prinzip       „Graphen“: Gesamtheit von   Objekten (Knoten, vertices) sowie      Beziehungen zwischen Objekten (Kanten,...
Prinzip       Knoten können über Kanten mit beliebig        vielen anderen Knoten verknüpft werden:   one-to-one      o...
Eigenschaften       vielfältige Abfragemöglichkeiten        (Abfrage der Objekte, aber auch der Pfade        dazwischen)...
Abfragen       Verschiedene Abfragesprachen:       Gremlin (Traversal-Skriptsprache, nutzt        XPath)       Traversa...
Datenbankenauf dem Device(no server)       © 2013 triAGENS GmbH | 2013-03-14
Datenbank-APIs im Browser       aktuelle Browser bieten folgende Datenbank-APIs        für lokale Datenspeicherung an:   ...
Datenbank-APIs im Browser       Browser-Datenbanken sind hilfreich u. a.   als Cache / Zwischenspeicher, z. B. wenn keine...
Javascript-Userland-Datenbanken       Beispiel SculeJS:   MongoDB-Clone in Javascript      in-memory, mit optionalem Fa...
Embedded Datenbanken   grundsätzlich können Datenbank-Libraries    auch in native Applikationen eingebunden    (embedded)...
Embedded Datenbanken       Beispiel TouchDB:   CouchDB-ähnliche Datenbank-Engine,       geschrieben in Objective C  unt...
Fazit        © 2013 triAGENS GmbH | 2013-03-14
SQL vs. NoSQL   relationale Datenbanken sind weiterhin für    viele Einsatzgebiete geeignet   für bestimmte Probleme kön...
NoSQL for the web   NoSQL-Datenbanken mit HTTP-API und    JSON-Support übernehmen tw. die Rollen    von web und applicati...
© 2013 triAGENS GmbH | 2013-03-14
Nächste SlideShare
Wird geladen in …5
×

Mobile meets NoSQL

1.393 Aufrufe

Veröffentlicht am

Veröffentlicht in: Automobil
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.393
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
124
Aktionen
Geteilt
0
Downloads
6
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Mobile meets NoSQL

  1. 1. NoSQL meets mobile.cologne mobile.cologne 2013-03-14 Jan Steemann (triAGENS) © 2013 triAGENS GmbH | 2013-03-14
  2. 2. about:self Entwickler bei der triAGENS GmbH Dokumentendatenbank vi, C/C++, Linux, open source... © 2013 triAGENS GmbH | 2013-03-14
  3. 3. NoSQL matters 2013 Konferenz zu NoSQL-Themen & -Produkten: Redis, Riak, MongoDB, CouchDB, ... optionaler Training day 26. - 27. April 2013 im KOMED (Mediapark) Programm auf: http://nosql-matters.org/ © 2013 triAGENS GmbH | 2013-03-14
  4. 4. To SQL ornot to SQL? © 2013 triAGENS GmbH | 2013-03-14
  5. 5. Relationale Datenbanken „SQL-Datenbanken“ sind relationale Datenbanken, die mit SQL abgefragt werden sie basieren auf dem relationalen Modell (* 1970) in relationalen Datenbanken werden Datensätze in Tabellen mit typisierten Spalten gespeichert optional gibt es Beziehungen (references) zwischen Spalten verschiedener Tabellen sowie Konsistenzbedingungen (constraints) die Summe aller die Datenbank beschreibenden Elemente heißt „Schema“ © 2013 triAGENS GmbH | 2013-03-14
  6. 6. Normalisierung relationales Gebot: du sollst Daten normalisiert speichern (Normalformen 1 - x) durch Normalisierung werden Redundanzen aufgelöst, dadurch Konsistenz und Integrität der Daten erhöht normalisierte Daten sind meist auf mehrere Tabellen verteilt um sie wieder zusammenzubringen, benötigt man Joins © 2013 triAGENS GmbH | 2013-03-14
  7. 7. Problem: Skalierung relationale Datenbanken sind nur schwer zu skalieren, denn  SQL erlaubt grundsätzlich Abfragen auf alle Tabellen und Daten, selbst wenn diese auf mehrere Server im Cluster verteilt sind  für Abfragen muss eine konsistente Sicht auf die Daten gewahrt bleiben © 2013 triAGENS GmbH | 2013-03-14
  8. 8. Problem: Skalierung in einem Cluster müssen sich einzelne Server absprechen, damit die Konsistenz gewahrt bleibt, z. B. für unique constraints, Sichtbarkeit von Commits, ... das führt zu komplizierten Protokollen mit Netzwerk-Overhead, Locks usw.: geringer Durchsatz und geringe Skalierbarkeit Workaround: selbstgebautes Sharding © 2013 triAGENS GmbH | 2013-03-14
  9. 9. Problem: Schemas die Verwendung von festen Schemas bedeutet, dass nur Daten gespeichert werden können, die das Schema vorsieht Applikationscode und Datenbank-Schema müssen zusammenpassen verändertes Schema = ALTER TABLE, ggf. Datenmigration, ggf. Downtime © 2013 triAGENS GmbH | 2013-03-14
  10. 10. Problem: Schemas zum Speichern von Objekten in relationalen Datenbanken braucht man viel Code oder ORMs: var user = {  eingebettetes Objekt   name: {      first: "J",      last: "S"    },    dob: {      y: 1974,  Liste, mit verschiedenen     m: "November"  Datentypen   },    likes: [ "vi", "C", "C++", 42 ]  } © 2013 triAGENS GmbH | 2013-03-14
  11. 11. Problem: Performance Verwendung von SQL bedeutet Overhead: query parsing, query planning, … braucht man für folgende Abfragen wirklich SQL? SELECT * FROM `table` WHERE id = ? DELETE FROM `table` WHERE id = ? INSERT INTO `session` (id, data) VALUES (?, ?) ... © 2013 triAGENS GmbH | 2013-03-14
  12. 12. NoSQLto the rescue? © 2013 triAGENS GmbH | 2013-03-14
  13. 13. Neue Ansätze in den letzten Jahren sind viele neue Datenbanken entstanden diese lösen oder umgehen die genannten Probleme, oftmals durch andere Annahmen darüber, welche die Aufgabe die Datenbank eigentlich erledigen soll Entwicklung oftmals aus der Not heraus und nicht kommerziell getrieben © 2013 triAGENS GmbH | 2013-03-14
  14. 14. „NoSQL“ eine Gemeinsamkeit der meisten neueren Datenbanken ist, dass sie auf SQL als Abfragesprache verzichten schließlich hat sich der Begriff „NoSQL“ als Sammelbegriff für die neuen Datenbanken etabliert es gibt aber keine eindeutige Definition von „NoSQL“ © 2013 triAGENS GmbH | 2013-03-14
  15. 15. NoSQL == non-relational so gut wie alle NoSQL-Datenbanken sind „non-relational“ und verwenden nicht das relationale Datenmodell NoSQL-Datenbanken sind meist komplett schema-frei oder bieten nur high-level Schema-Elemente (z. B. „Collections“ als Äquivalent zu „Tabellen“) © 2013 triAGENS GmbH | 2013-03-14
  16. 16. NoSQL & Skalierung? „NoSQL“ bedeutet nicht automatisch Skalierung es existieren im NoSQL-Bereich...  ...single server-Datenbanken mit Fokus auf hoher Performanz für einzelne Operationen  ...verteilte (distributed) Datenbanken mit Fokus auf horizontaler Skalierung und high availability © 2013 triAGENS GmbH | 2013-03-14
  17. 17. Skalierung In verteilten Datenbanken wird die Skalierbarkeit oft „erkauft“ durch Abstriche bei Features:  „teure“ Features wie Joins werden gar nicht erst angeboten  Abfragen in einer verteilten Datenbank haben keine strikte Konsistenz  Inkonsistenzen und Konflikte können (und dürfen) vorkommen. Nicht die Datenbank, sondern die Applikation muss sie behandeln © 2013 triAGENS GmbH | 2013-03-14
  18. 18. NoSQL-Kategorien die meisten NoSQL-Datenbanken können folgenden Kategorien zugeordnet werden: Key / value stores   (Wide) column stores  Document databases  Graph databases jede Kategorie bietet verschiedene Abfragemöglichkeiten und Einsatzbereiche © 2013 triAGENS GmbH | 2013-03-14
  19. 19. NoSQL-Datenbanken in jeder Kategorie existieren viele, durchaus unterschiedliche Implementierungen ausführliche Liste auf http://nosql-database.org/ aktuell sind dort 150 Datenbanken gelistet, die meisten davon sind open source © 2013 triAGENS GmbH | 2013-03-14
  20. 20. Key / valuestores © 2013 triAGENS GmbH | 2013-03-14
  21. 21. Prinzip für einen (eindeutigen) Key wird jeweils ein Wert (Value) gespeichert verschiedene Keys sind unabhängig voneinander Werte sind nur über Keys wieder abfragbar Value-Daten werden vom Store als (unteilbare) BLOBs behandelt Zugriff auf Teilwerte nicht möglich © 2013 triAGENS GmbH | 2013-03-14
  22. 22. Beispiele Zugriff erfolgt immer über eindeutigen Key: store.put("obj3", "{ a: 1, b: 1 }") store.remove("obj2"); store.get("numUsers"); broken JSON herzlich willkommen Erlaubt: store.put("json", "{ a: 1"); store.put("binary", "...binary data..."); © 2013 triAGENS GmbH | 2013-03-14
  23. 23. Eigenschaften wenig Overhead, denn Werteinhalte werden vom store „ignoriert“ (kein  Parsing, kein Schema, keine Validierung usw.)  es gibt nur sehr simple Zugriffsmethoden (keine Abfragesprachen usw.) ideal, wenn Werte komplett und nicht in Einzelteilen abgefragt werden sollen (serialisierte Objekte, BLOBs) © 2013 triAGENS GmbH | 2013-03-14
  24. 24. Beispiel memcached (single server) in-memory only simples Protokoll mit Operationen wie z. B. GET / SET / ADD / REPLACE / DELETE © 2013 triAGENS GmbH | 2013-03-14
  25. 25. Beispiel redis (single server) in-memory / snapshots / changelogs single threaded erweitert das simple Zugriffsmodell um atomare Transaktionen   spezialisierte Operationen für Datenstrukturen (Listen, Sets, ...) dadurch viele zusätzliche Einsatzbereiche © 2013 triAGENS GmbH | 2013-03-14
  26. 26. Distributed key / value stores Simples key / value-Modell erlaubt horizontale Skalierung: keys werden per Hash-Funktion auf verschiedene Server verteilt i. d. R. besteht kein Einfluss darauf, welche Server konkret für welche keys zuständig sind oft ist kontrollierbar, wie viele Server für jeden Key zuständig sind („Quorum“) dadurch high availability mit automatischem Failover möglich © 2013 triAGENS GmbH | 2013-03-14
  27. 27. Beispiel riak (distributed) konfigurierbare Backends (durable / memory) automatisches Failover und Re-Balancing Zusätzliche Indizes erlauben equality & range queries auf secondary keys Javascript-map / reduce-Abfragemöglichkeit Zugriff über HTTP-REST API © 2013 triAGENS GmbH | 2013-03-14
  28. 28. Document stores © 2013 triAGENS GmbH | 2013-03-14
  29. 29. Prinzip Document stores speichern „Dokumente“: zusammengesetzte Objekte mit benannten Attributen, auf die einzeln zugegriffen werden kann Attributwerte sind typisiert (z. B. Zahlen, Strings, Booleans, Listen, Objekte) jedes Dokument hat einen eindeutigen Key {    _id: "user2",    name: { first: "J", last: "S", middle: null },   likes: [ "vi", "C", "C++", 42 ]  } © 2013 triAGENS GmbH | 2013-03-14
  30. 30. Prinzip Dokumente derselben Domäne werden in derselben „Collection“ gespeichert (Äquivalent zur Tabelle in relationalen Datenbanken) aber: Collections haben kein vordefiniertes Schema und: verschiedene Dokumente derselben Collection können unterschiedliche Attribute besitzen (goodbye ALTER TABLE !) © 2013 triAGENS GmbH | 2013-03-14
  31. 31. Beispiele Speichern von Dokumenten: db.users.save({  verschiedene Dokumenttypen   _id: "user1",  in einer Collection   name: "foo" sind kein Problem ! }); db.users.save({    _id: "user2",    name: {     first: "J",      last: "S"    }  }); © 2013 triAGENS GmbH | 2013-03-14
  32. 32. Eigenschaften Listen können direkt in Dokumente eingebettet und abgefragt werden, ohne zusätzliche Collections: SQL-Anti pattern !! likes: [ "vi", "C", "C++", 42 ]  Objekte in Programmiersprachen lassen sich relativ gut als Dokumente abbilden Arrays und Unterobjekte müssen nicht normalisiert werden © 2013 triAGENS GmbH | 2013-03-14
  33. 33. Beispiel CouchDB ACID-Garantien für Operationen auf einer „Database“ Abfragen über Dokument-Keys oder „Views“ (Javascript-map / reduce) Replikation Master / Master, eventual consistency, change polling HTTP-REST API mit JSON als Datenformat nutzbar als web & application server („couchapps“) © 2013 triAGENS GmbH | 2013-03-14
  34. 34. Graph databases © 2013 triAGENS GmbH | 2013-03-14
  35. 35. Prinzip „Graphen“: Gesamtheit von Objekten (Knoten, vertices) sowie   Beziehungen zwischen Objekten (Kanten, edges) die Objekte und Beziehungen selbst sind meist strukturierte Dokumente wie in document stores das ermöglicht bei Bedarf die Typisierung von Knoten und Kanten („property graph“, Gewichtung) © 2013 triAGENS GmbH | 2013-03-14
  36. 36. Prinzip Knoten können über Kanten mit beliebig vielen anderen Knoten verknüpft werden: one-to-one   one-to-many  many-to-many Listen, Bäume, Netze, … Zyklische und azyklische Graphen © 2013 triAGENS GmbH | 2013-03-14
  37. 37. Eigenschaften vielfältige Abfragemöglichkeiten (Abfrage der Objekte, aber auch der Pfade dazwischen) klassische Anwendungsfälle:  Geo-Queries (kürzester Weg von A → B)  Soziale Beziehungen (Freunde von Freunden) © 2013 triAGENS GmbH | 2013-03-14
  38. 38. Abfragen Verschiedene Abfragesprachen:  Gremlin (Traversal-Skriptsprache, nutzt XPath)  Traversals in native code (meist Java)  Cypher (deklarativ, in Neo4j) © 2013 triAGENS GmbH | 2013-03-14
  39. 39. Datenbankenauf dem Device(no server) © 2013 triAGENS GmbH | 2013-03-14
  40. 40. Datenbank-APIs im Browser aktuelle Browser bieten folgende Datenbank-APIs für lokale Datenspeicherung an: WebStorage (localStorage, sessionStorage):  simple key / value-API  WebSQL (deprecated): SQL queries (mit SQLite als Back end)  IndexedDB: key / value-API, mit Support für secondary indexes jeweils nicht überall verfügbar (Fix: shims) © 2013 triAGENS GmbH | 2013-03-14
  41. 41. Datenbank-APIs im Browser Browser-Datenbanken sind hilfreich u. a. als Cache / Zwischenspeicher, z. B. wenn keine  Netzwerkverbindung vorhanden ist  wenn Daten nur auf dem Client und nicht zentral benötigt werden dauerhafte Persistenz und Speicherplatz im Browser nicht gut kontrollierbar Datenbank ist unter User-Kontrolle (Datenmanipulation, jail breaks) © 2013 triAGENS GmbH | 2013-03-14
  42. 42. Javascript-Userland-Datenbanken Beispiel SculeJS: MongoDB-Clone in Javascript   in-memory, mit optionalem Fallback zu localStorage Beispiel PouchDB:  CouchDB-Clone in Javascript  speichert Daten lokal mittels WebSQL oder IndexedDB  unterstützt beidseitige Replikation mit remote CouchDB-Server über CouchDB-HTTP API © 2013 triAGENS GmbH | 2013-03-14
  43. 43. Embedded Datenbanken grundsätzlich können Datenbank-Libraries auch in native Applikationen eingebunden (embedded) werden die Datenbank ist dann untrennbarer Bestandteil der eigentlichen Applikation und wird mit ausgeliefert kein separater Datenbank-Server © 2013 triAGENS GmbH | 2013-03-14
  44. 44. Embedded Datenbanken Beispiel TouchDB: CouchDB-ähnliche Datenbank-Engine,  geschrieben in Objective C  unterstützt beidseitige Replikation mit CouchDB über CouchDB-HTTP API Beispiel Tokyo Cabinet:  relativ verbreitete Key / value-Library, es gibt auch Bindings für Objective C © 2013 triAGENS GmbH | 2013-03-14
  45. 45. Fazit © 2013 triAGENS GmbH | 2013-03-14
  46. 46. SQL vs. NoSQL relationale Datenbanken sind weiterhin für viele Einsatzgebiete geeignet für bestimmte Probleme können NoSQL- Datenbanken besser geeignet sein oft geben NoSQL-Datenbanken geringere Garantien als relationale Datenbanken Referentielle Integrität, Konsistenz, Isolation, Datenvalidierung, Versionierung usw. „darf“ in vielen Fällen die Applikation übernehmen © 2013 triAGENS GmbH | 2013-03-14
  47. 47. NoSQL for the web NoSQL-Datenbanken mit HTTP-API und JSON-Support übernehmen tw. die Rollen von web und application server Clients können bei Bedarf direkt mit der Datenbank kommunizieren (müssen aber nicht) HTTP-Support ist überall vorhanden (Browser, native apps), man benötigt keine speziellen Client-Libraries mehr © 2013 triAGENS GmbH | 2013-03-14
  48. 48. © 2013 triAGENS GmbH | 2013-03-14

×