Contenu connexe
Similaire à Mobile meets NoSQL
Similaire à Mobile meets NoSQL (20)
Mobile meets NoSQL
- 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
- 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
- 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
- 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
- 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
- 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
- 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