© 2013 triAGENS GmbH | 2013-03-14

NoSQL meets mobile.colognemobile.cologne

2013-03-14

Jan Steemann (triAGENS)

© 2013 triAGENS GmbH | 2013-03-14

about:self

Entwickler bei der triAGENS GmbH Dokumentendatenbank vi, C/C++, Linux, open source...

© 2013 triAGENS GmbH | 2013-03-14

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

To SQL or not to SQL?

© 2013 triAGENS GmbH | 2013-03-14

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

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

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

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

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

Problem: Schemas

zum Speichern von Objekten in relationalen Datenbanken braucht man viel Code oder ORMs:

var user = {   name: {     first: "J",     last: "S"   },   dob: {     y: 1974,     m: "November"   },   likes: [ "vi", "C", "C++", 42 ] }

Liste, mit verschiedenen Datentypen

eingebettetes Objekt

© 2013 triAGENS GmbH | 2013-03-14

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

NoSQL to 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 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

„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

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

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

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

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

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

Key / value stores

© 2013 triAGENS GmbH | 2013-03-14

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

Beispiele

Zugriff erfolgt immer über eindeutigen Key:

store.put("obj3", "{ a: 1, b: 1 }")store.remove("obj2");store.get("numUsers");

Erlaubt:

store.put("json", "{ a: 1");store.put("binary", "...binary data...");

broken JSON herzlich willkommen

© 2013 triAGENS GmbH | 2013-03-14

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

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

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

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

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

Document stores

© 2013 triAGENS GmbH | 2013-03-14

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

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

Beispiele

Speichern von Dokumenten:

db.users.save({   _id: "user1",   name: "foo"});

db.users.save({   _id: "user2",   name: {    first: "J",     last: "S"   } });

verschiedene Dokumenttypenin einer Collection sind kein Problem !

© 2013 triAGENS GmbH | 2013-03-14

Eigenschaften

Listen können direkt in Dokumente eingebettet und abgefragt werden, ohne zusätzliche Collections:

likes: [ "vi", "C", "C++", 42 ] 

Objekte in Programmiersprachen lassen sich relativ gut als Dokumente abbilden

Arrays und Unterobjekte müssen nicht normalisiert werden

SQL-Anti pattern !!

© 2013 triAGENS GmbH | 2013-03-14

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

Graph databases

© 2013 triAGENS GmbH | 2013-03-14

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

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

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

Abfragen

Verschiedene Abfragesprachen: Gremlin (Traversal-Skriptsprache, nutzt

XPath) Traversals in native code (meist Java) Cypher (deklarativ, in Neo4j)

© 2013 triAGENS GmbH | 2013-03-14

Datenbanken auf 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:

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

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

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

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

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

Fazit

© 2013 triAGENS GmbH | 2013-03-14

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

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