Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und relevantere Anzeigen zu schalten. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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.503 Aufrufe

Veröffentlicht am

Veröffentlicht in: Automobil
  • Als Erste(r) kommentieren

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

×