Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mobile meets NoSQL

1,545 views

Published on

Published in: Automotive
  • Be the first to comment

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

×