1. NoSQL meets mobile.cologne
mobile.cologne
2013-03-14
Jan Steemann (triAGENS)
© 2013 triAGENS GmbH | 2013-03-14

2. about:self
 Entwickler bei der triAGENS GmbH
 Dokumentendatenbank
 vi, C/C++, Linux, open source...
© 2013 triAGENS GmbH | 2013-03-14

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. To SQL or
not to SQL?
© 2013 triAGENS GmbH | 2013-03-14

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. 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. 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. 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. 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. 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. 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. NoSQL
to the rescue?
© 2013 triAGENS GmbH | 2013-03-14

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. „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. 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. 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. 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. 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. 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. Key / value
stores
© 2013 triAGENS GmbH | 2013-03-14

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. 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. 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. 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. 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. 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. 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. Document stores
© 2013 triAGENS GmbH | 2013-03-14

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. 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. 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. 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. 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. Graph databases
© 2013 triAGENS GmbH | 2013-03-14

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. 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. 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. 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. Datenbanken
auf dem Device
(no server)
© 2013 triAGENS GmbH | 2013-03-14

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. 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. 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. 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. 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. Fazit
© 2013 triAGENS GmbH | 2013-03-14

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. 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. © 2013 triAGENS GmbH | 2013-03-14