This a

1. © 2013 triAGENS GmbH | 2013-06-05
NoSQL – eine
Übersicht
Symfony User Group, Startplatz
2013-06-05
Jan Steemann (triAGENS)

2. © 2013 triAGENS GmbH | 2013-06-05
about:self
 Entwickler bei der triAGENS GmbH
 Multi-Model-Datenbank
 PHP 4.0.* ... PHP 5.3.*

3. © 2013 triAGENS GmbH | 2013-06-05
Relationale Datenbanken

4. © 2013 triAGENS GmbH | 2013-06-05
Relationale Datenbanken
 relationale Datenbanken:
SQL Server, MySQL, Postgres, Oracle, DB2...
 basieren auf dem relationalen Modell (* 1970)
 Datensätze werden in Tabellen mit
typisierten Spalten gespeichert
 im Datenbank-Schema wird definiert, welche Tabellen,
Spalten und Datentypen verwendet werden können

5. © 2013 triAGENS GmbH | 2013-06-05
Beispiel: Tabelle "users"
user_id user_name group_name status
1 jean users active
2 daniel admin active
3 david users inactive
4 frank admin active
5 zoe users active
CREATE TABLE users (user_id INTEGER,
user_name VARCHAR(40),
group_name VARCHAR(40),
status VARCHAR(16),
PRIMARY KEY(user_id)
)

6. © 2013 triAGENS GmbH | 2013-06-05
Normalisierung
 relationales Gebot:
Daten sollen normalisiert gespeichert werden
 Normalformen 1 - x
 Zweck:
Redundanzen auflösen,
Konsistenz und Integrität der Daten erhöhen

7. © 2013 triAGENS GmbH | 2013-06-05
Normalisierung: 3 Tabellen
user_id user_name
group_name
1 jean
users
2 daniel
admin
3 david
4 frank
5 zoe
group_id
1
2
1
2
1
group_id
1
2
status_id
1
1
2
1
1
status_name
active
inactive
status_id
1
2
reference
reference

8. © 2013 triAGENS GmbH | 2013-06-05
Joins, References, Constraints
 normalisierte Daten sind meist auf mehrere Tabellen
verteilt
 zur Abfrage benötigt man dann Joins
 es können Beziehungen (references) und
Konsistenzbedingungen (constraints) definiert werden
 diese werden von der Datenbank erzwungen

9. © 2013 triAGENS GmbH | 2013-06-05
Transaktionen
 Operationen auf mehrere Objekte (Datensätze /
Tabellen) können durch Transaktionen geschützt
werden
 Transaktionen garantieren ACID-Eigenschaften für
Operationen:
Atomicity, Consistency, Isolation, Durability

10. © 2013 triAGENS GmbH | 2013-06-05
Problem: Skalierung
 Skalierung relationaler Datenbanken ist schwierig,
denn
 das relationale Modell und SQL erlauben beliebige
Abfragen (Joins, Aggregationen, ...)
 bei verteilten Daten müssen Join-(Teil-)Ergebnisse
über das Netzwerk ausgetauscht werden (A x B)
 ggf. müssen mehrere Server Teilabfragen ausführen,
die später aggregiert werden müssen

11. © 2013 triAGENS GmbH | 2013-06-05
Problem: Skalierung
 Skalierung relationaler Datenbanken ist schwierig,
denn
 für Transaktionen muss eine cluster-weit konsistente
Sicht auf die Daten gewahrt bleiben
 für die Sichtbarkeit von Commits, unique constraints,
ID-Vergabe usw. ist Kommunikation zwischen Servern
erforderlich
 tw. sind komplizierte Protokolle (z. B. two-phase
commit) und Locks erforderlich

12. © 2013 triAGENS GmbH | 2013-06-05
Workaround: sharding via Applikation
 Applikation "kennt" Verteilung der Daten und spricht
direkt die korrekten Server an
 Konsistenz, Isolation usw. sind nur schwer zu
gewährleisten
 Applikation übernimmt tw. Aufgaben der Datenbank

13. © 2013 triAGENS GmbH | 2013-06-05
Problem: Schemas
 die Verwendung von fixen Schemas bewirkt, dass nur
Daten gespeichert werden können, die vom Schema
vorgesehen wurden
 Schemaänderung erfordert ALTER TABLE, ggf.
Datenmigration, ggf. Downtime
 Änderungen an Applikationscode und Datenbank-
Schema müssen "gleichzeitig" ausgerollt werden

14. © 2013 triAGENS GmbH | 2013-06-05
Problem: dynamische Daten
 Speicherung dynamischer Strukturen ist oftmals
problematisch
 dynamisch = Anzahl und Typen der Attribute zur
Entwicklungszeit unbekannt oder vom Nutzer änderbar
$config => array(
array("name" => "maxUsers", "value" => 7),
array("name" => "label", "value" => "myApp"),
array("name" => "dtStart", "value" => "2013-05-29")
);

15. © 2013 triAGENS GmbH | 2013-06-05
Workaround: serialize
 serialize() und Speicherung in BLOB-Spalte funktioniert
 deaktiviert aber die meisten Datenbank-Features
(SELECT auf einzelne Attribute), Inhaltsprüfung, Joins
usw.
 Bonus-Workaround:
JSON-Spaltentyp in Postgres

16. © 2013 triAGENS GmbH | 2013-06-05
Problem: impedance mismatch
 Speicherung komplexer Strukturen/Objekte aus
Programmiersprache benötigt ORMs und/oder eigenen
mapping code
$post = array(
"title" => "how databases work",
"dt" => "2013-05-29T12:44:03Z",
"author" => array(
"first" => "J",
"last" => "S",
"nickname" => "@foo"
),
"tags" => array("database", "mysql", "rdbms")
);

17. © 2013 triAGENS GmbH | 2013-06-05
NoSQL- die Rettung?

18. © 2013 triAGENS GmbH | 2013-06-05
Nicht-relationale Datenbanken
 in den letzten Jahren sind viele neue,
nicht-relationale Datenbanken entstanden
 diese lösen einige der genannten Probleme
(Skalierung, Schemas, dynamische Daten, impedance
mismatch)
 tw. durch weniger Zusicherungen und Garantien (a.k.a.
Delegation von Aufgaben an die Applikation)!

19. © 2013 triAGENS GmbH | 2013-06-05
"NoSQL"
 der Begriff "NoSQL" hat sich als Sammelbegriff für
viele neuere, nicht-relationale Datenbanken etabliert
 aktuell 150 Datenbanken auf http://nosql-database.org/
 es gibt keine verbindliche Definition von "NoSQL"...
 ...und wenig Standards

20. © 2013 triAGENS GmbH | 2013-06-05
Schemafreiheit
 NoSQL-Datenbanken bieten meist nur wenig
Möglichkeiten zur Schema-Definition
 oft keine "Tabellen" und "Spalten"
 tw. gibt es einzeln ansprechbare Attribute und
Datentypen, tw. auch nicht (= BLOB)
 Schemafreiheit ermöglicht, jederzeit Daten zu
speichern – auch Daten neuartiger Form

21. © 2013 triAGENS GmbH | 2013-06-05
Schemafreiheit
 Schema ist in gespeicherten Daten inhärent vorhanden
 verschiedene Versionen eines "Schemas" können
parallel existieren:
{ name: "..." }
{ name: { first: "...", last: "..." } }
{ firstName: "...", lastName: "..." }
 die Datenbank kennt keine "richtige" Struktur

22. © 2013 triAGENS GmbH | 2013-06-05
Schemafreiheit
 kein Migrationszwang:
man kann selbst entscheiden, ob (und wann) "alte"
Daten migriert werden
 wenn keine Migration alter Daten erfolgt, muss die
Applikation mit verschiedenen Versionen umgehen
können
(= mehr Kontrolle, mehr Verantwortung)

23. © 2013 triAGENS GmbH | 2013-06-05
Normalisierung vs. not
 NoSQL-Datenbanken sind i. d. R. nicht für
normalisierte Datenmodelle ausgelegt
 im Gegenteil ist "erwünscht", ein Objekt als
zusammengehöriges Aggregat zu speichern (keine
Aufteilung der Objekteigenschaften auf verschiedene
"Tabellen" etc.)
 durch die Aggregatorientierung ist das Lesen und
Speichern von kompletten Objekten einfach und
schnell

24. © 2013 triAGENS GmbH | 2013-06-05
Beispiel: User-Objekt
{
"id": "user02",
"name": {
"first": "foo",
"last": "bar"
},
"status": "active",
"friendIds": [
"user03", "user04", "user99"
]
}

25. © 2013 triAGENS GmbH | 2013-06-05
Abfragemöglichkeiten
 Abfragen über Aggregatgrenzen hinweg sind tw.
problematisch (abhängig von Datenbank)
 tw. müssen die Objekte von der Applikation einzeln
abgefragt und wieder zusammengefügt werden
 dies ist oftmals teuer...
 ...und die Datenbank garantiert keine Konsistenz für
das Gesamtergebnis

26. © 2013 triAGENS GmbH | 2013-06-05
NoSQL & Skalierung?
 NoSQL bedeutet nicht zwangsläufig "Skalierung"
 im NoSQL-Bereich existieren...
 ...single server-Datenbanken mit Fokus auf hoher
Performanz und/oder Convenience
 ...verteilte (distributed) Datenbanken mit Fokus auf
horizontaler Skalierung und high availability

27. © 2013 triAGENS GmbH | 2013-06-05
NoSQL & Skalierung
 in verteilten NoSQL-Datenbanken wird die
Skalierbarkeit oft erkauft durch Abstriche bei Features
und Garantien, z. B.
 "teure" Features wie Joins oder Transaktionen werden
nicht angeboten
 Abfragen in einer verteilten Datenbank haben keine
zugesicherte Konsistenz
 Inkonsistenzen und Konflikte können (und dürfen)
vorkommen. Nicht die Datenbank, sondern die
Applikation muss sie behandeln

28. © 2013 triAGENS GmbH | 2013-06-05
NoSQL-Datenbank-Kategorien
 die meisten NoSQL-Datenbanken können folgenden
Kategorien zugeordnet werden:
 Key/value stores
 (Wide) column stores (404)
 Dokumentdatenbanken
 Graph-Datenbanken
 jede Kategorie bietet verschiedene
Abfragemöglichkeiten und Einsatzbereiche

29. © 2013 triAGENS GmbH | 2013-06-05
Key Value Stores

30. © 2013 triAGENS GmbH | 2013-06-05
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
 Values werden vom Store als (unteilbare) BLOBs
behandelt
 Zugriff auf Teilwerte nicht möglich

31. © 2013 triAGENS GmbH | 2013-06-05
Beispiele
 Zugriff erfolgt immer über eindeutigen Key:
$store->put("obj3", "{ a: 1, b: 1 }")
$store->remove("obj2");
$store->get("numUsers");
 Key/value store übernimmt keine Validierung:
$store->put("json", "{ a: 1");
$store->put("binary", "...binary data...");

32. © 2013 triAGENS GmbH | 2013-06-05
Eigenschaften
 wenig Overhead, denn
 Werteinhalte werden vom store "ignoriert" (kein
Parsing, kein Schema, keine Validierung)
 es gibt nur simple Zugriffsmethoden
(keine Abfragesprachen usw.)
 ideal, wenn Werte komplett und nicht in Einzelteilen
abgefragt werden sollen (serialisierte Objekte, BLOBs)

33. © 2013 triAGENS GmbH | 2013-06-05
Distributed key/value stores
 simples key/value-Modell erlaubt Skalierung:
voneinander unabhängige keys können auf
verschiedene Server verteilt werden
 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 Failover

34. © 2013 triAGENS GmbH | 2013-06-05
Beispiele
 embedded: Kyoto Cabinet
 single server: Memcached, Redis
 distributed: Couchbase, Riak, Oracle NoSQL
 services: Dynamodb

35. © 2013 triAGENS GmbH | 2013-06-05
Dokumentendatenbanken

36. © 2013 triAGENS GmbH | 2013-06-05
Prinzip
 Dokumentdatenbanken speichern "Dokumente"
 Dokumente sind zusammengesetzte Objekte
("Aggregate") mit benannten Attributen
 Attributwerte sind typisiert (z. B. Zahlen, Strings, Listen,
Unterobjekte)
 verschiedene Typisierungssysteme
(JSON, BSON, XML)

37. © 2013 triAGENS GmbH | 2013-06-05
Dokument: Beispiel
{
"id": "user02",
"name": {
"first": "foo",
"last": "bar"
},
"status": "active",
"friendIds": [
"user03", "user04", "user99"
]
}

38. © 2013 triAGENS GmbH | 2013-06-05
Abfragemöglichkeiten
 auf die Attribute von Dokumenten kann auch einzeln
zugegriffen werden
 tw. können auch Indizes auf die einzelnen Attribute
angelegt werden
 deutlich erweiterte Abfragemöglichkeiten gegenüber
Key/value stores

39. © 2013 triAGENS GmbH | 2013-06-05
Collections, Schemafreiheit
 Dokumente desselben Typs werden in derselben
"Collection" gespeichert (Äquivalent zur "Tabelle" in
relationalen Datenbanken)
 Collections haben kein vordefiniertes Schema
 verschiedene Dokumente in derselben Collection
können unterschiedliche Attribute besitzen

40. © 2013 triAGENS GmbH | 2013-06-05
Speichern von Dokumenten
$db->save(array(
"id" => "user01",
"name" => "foo"
));
$db->save(array(
"id" => "user02",
"name" => array(
"first" => "foo",
"last" => "bar"
),
"friendIds" => array("user01", "user03", "user99")
));

41. © 2013 triAGENS GmbH | 2013-06-05
Listen und Unterobjekte
 Listen können direkt in Dokumente eingebettet und
abgefragt werden, ohne Transformation/Joins etc:
"friendIds" => array("user01", "user03", "user99")
 Objekte in Programmiersprachen lassen
sich relativ gut als Dokumente abbilden
 Arrays und Unterobjekte müssen nicht erst normalisiert
werden

42. © 2013 triAGENS GmbH | 2013-06-05
Beispiele
 single server: CouchDB, ArangoDB
 distributed: MongoDB, CouchBase, RavenDB,
RethinkDB

43. © 2013 triAGENS GmbH | 2013-06-05
Graph-
Datenbanken

44. © 2013 triAGENS GmbH | 2013-06-05
Prinzip
 ein "Graph" ist die Gesamtheit von
 Objekten (Knoten, auch "vertices") sowie
 Beziehungen (Kanten, auch "edges")
daniel
david
zoefrankstuart

45. © 2013 triAGENS GmbH | 2013-06-05
Prinzip
 die Objekte und Beziehungen sind meist beliebig
strukturier- und typisierbar
 ein Objekt kann mehrere Beziehungen zu anderen
Objekten aufweisen (1:1, 1:n, n:m)

46. © 2013 triAGENS GmbH | 2013-06-05
Graph: Beispiel
{
"name": "daniel",
"age": 27,
"gender": "male"
}
{
"name": "david",
"age": 35
}
{"type":"is-boss-of"}
{
"name": "zoe",
"age": 33
}
{"type":"is-friend-of"}
{"type":"loves"}

47. © 2013 triAGENS GmbH | 2013-06-05
Einsatzmöglichkeiten
 Hierarchien, Klassifikationen (Bäume)
 soziale Beziehungen (Netzwerke)
 geographische Daten (Navigation, Routen)
 ...
 die Objekte selbst und die direkten und
indirekten Beziehungen ("Pfade") sind
abfragbar

48. © 2013 triAGENS GmbH | 2013-06-05
Graph-Abfragen
 Graph-Abfragen sind oft komplex:
 Traversals: in der Datenbank ausgeführte Programme
 Gremlin (Datenbank-übergreifende Traversal-
Skriptsprache)
 Datenbank-eigene Abfragemöglichkeiten
(z. B. Abfragesprache "Cypher" in Neo4j)

49. © 2013 triAGENS GmbH | 2013-06-05
Multi-Model-Datenbanken
 Multi-Model-Datenbanken verbinden
verschiedene Datenmodelle und
Abfragemöglichkeiten
 Beispiele:
 OrientDB (Dokumente, Graphen, „SQL“)
 ArangoDB (Dokumente, Graphen, AQL)

50. © 2013 triAGENS GmbH | 2013-06-05
Fazit

51. © 2013 triAGENS GmbH | 2013-06-05
NoSQL
 Key/value stores schränken Abfragemöglichkeiten ein,
sind aber für große Datenmengen oder hohen
Durchsatz oft die einzige Lösung
 Dokumentendatenbanken sind relativ breit einsetzbar
 Graphen können eine sinnvolle Ergänzung sein und
bieten zusätzliche Möglichkeiten
 Schemafreiheit ermöglicht relativ leichten Einstieg und
einfachere Entwicklung

52. © 2013 triAGENS GmbH | 2013-06-05
NoSQL
 viele NoSQL-Datenbanken bieten geringere Garantien
als relationale Datenbanken
 Referentielle Integrität, Konsistenz, Isolation,
Datenvalidierung, Versionierung usw. "darf" (und muss)
in vielen Fällen die Applikation übernehmen
 "teure" Features sind oft nicht vorhanden und müssen
bei Bedarf von der Applikation emuliert werden

53. © 2013 triAGENS GmbH | 2013-06-05
Relational vs. NoSQL
 welche Datenbank am besten geeignet ist, hängt vom
konkreten Anwendungsfall ab
 keine Datenbank (relational und NoSQL) ist für jeden
Einsatzbereich geeignet
 es geht darum, die beste(n) Datenbank(en) für den
jeweiligen Anwendungsfall zu finden

54. © 2013 triAGENS GmbH | 2013-06-05
Relational || NoSQL
 relationale Datenbanken sind etabliert und für viele
Einsatzgebiete geeignet
 es gibt viele Entwickler und Tools für relationale
Datenbanken
 NoSQL-Datenbanken sind heterogen und noch nicht so
etabliert
 sie können aber durchaus gute und tw. auch bessere
Lösungen für bestimmte Probleme sein

55. © 2013 triAGENS GmbH | 2013-06-05
Relational && NoSQL in Kombination
 NoSQL-Datenbanken können z. B. eingesetzt werden,
um relationale Datenbanken zu entlasten
 sie können außerdem dort eingesetzt werden, wo das
relationale Modell nicht "passt" und sowieso bereits
Workarounds verwendet werden (dynamische Daten,
Graphen, BLOBs, ...)

56. © 2013 triAGENS GmbH | 2013-06-05
Web-Datenbanken
 viele NoSQL-Datenbanken bieten eine HTTP-REST-
API, über die Clients mit der Datenbank
kommunizieren können
 solche Datenbanken können meist mittels Browser
administriert und auch genutzt werden
 HTML/JavaScript-Front ends können die Datenbank
ebenfalls "direkt" nutzen

57. © 2013 triAGENS GmbH | 2013-06-05
Web-Datenbanken
 diverse NoSQL-Datenbanken sind server-seitig mittels
JavaScript erweiterbar
 das ermöglicht einen einfachen Einstieg und sogar
JavaScript-code reusage

58. +
{
"title":"Hello World Example",
"database":"ArangoDB",
“me":“Dorthe Luebbert“
“twitter":“luebbert42“
}
Using ArangoDB with Symfony – an introduction

59. +
Infrastructure
n Symfony 2.x
n ArangoDB 1.3
n Bundles
n triagens/arangodb
-> PHP driver
n mop/arangodbbundle
-> bridge to Symfony
-> configuration
-> integration with FosUserBundle
n f21/paradox ->
-> ODM for ArangoDB (inspired by RedBean)

60. +
Configure Symfony for ArangoDB
// install ArangoDB (lots of binaries availlable)
brew install ArangoDB
// check that is running by accessing the web ui
http://localhost:8529/_admin/html/index.html
// prepare Symfony – vim path/to/myapp/composer.json
"require": {
…
"triagens/ArangoDb": "dev-devel",
"mop/arangodbbundle" : "dev-master"
…
},

61. +
Setting the connection parameters
//myapp/app/config/config.yml
mop_arango_db:
default_connection: main
connections:
main:
host: 127.0.0.1
port: 8529
$connection = $this->get('mop_arangodb.default_connection');

62. https://github.com/luebbert42/symfony-arangodb

63. +
Data model
{
"genre": "sci-fi",
"title": "Star wars",
"topics":
["spaceship",
"laser-games",
“romance“]
}
Relational model
Aggregate model
- nested structure
- redundancy = ok
- ! joins

64. +
Scope of the PHP driver
n Driver wraps around the HTTP interface
n Access
n Documents
n Collections
n Graphs
n Transactions
n „Advanced“ queries using AQL (ArangoDB‘s query language similar
to SQL, but also handling graphs, lists...)
n maps JSON documents to extendable PHP objects
n nested structures are mapped to arrays
n access document properties via get(attributename)

65. +List example: controller
// src/Triagens/ArangodbBundle/Controller/DefaultController.php
use triagensArangoDbDocument;
use triagensArangoDbCollectionHandler as
CollectionHandler;
public function listAction($genre) {
$connection = $this-
>get('mop_arangodb.default_connection');
$collectionHandler = new CollectionHandler($connection);
$movie = new Document();

66. +
List example: view
// src/Triagens/ArangodbBundle/Resources/views/list.html.twig
{% if movies|length > 0 %}
{% for movie in movies %}
<h1>{{movie.get("title")}}</h1>
{% for topic in movie.get("topics") %}
- {{topic}} <br>
{% endfor %}
{% endfor %}
{% else %}
No movies found.
{% endif %}

67. +
More interesting examples
... shown by Jan live J

68. © 2013 triAGENS GmbH | 2013-06-05
Vielen Dank!
Stay in touch:
Fork me on github
Google group: ArangoDB
Twitter: @steemann @arangodb
www.arangodb.org
Foxx – Javascript application
framework for ArangoDB