Vortrag - HTW Dresden

Polyglotte Persistenz
&
Multi-Model Datenbanken
192. Datenbankstammtisch
29.10.2014
Michael Hackstein
@mchacki
www.arangodb.com
Michael Hackstein
‣ ArangoDB Kern Entwickler
‣ Web Frontend
‣ Graphen Visualisierung
‣ Graphen Funktionalität
!
!
‣ Organisator der cologne.js
!
!
‣ MS. Inf.
(Datenbanken und
Informations Systeme)
2
Single-Model Datenarchitektur
Relationale Welt
3
Die Ära von Multi-Model bricht an
NoSQL Welt
Dokumente - JSON
{
{
}
}
“type":
“color":
“size":
“material”:
“form”:
“type“:
"pants",
“waist":
32,
“length”:
34,
“color":
"blue",
“material”: “cotton"
{
‣ Basierend
auf Key-Value Stores
“type":
"sweater",
“color":
"blue",
‣ Speichern
Dokumente mit logischer
“size":
“M”,
“material”: “wool”,
“form”:
“turtleneck"
Zusammengehörigkeit
in „collections“
}
{
“type“: ‣
"television",
Dateneinträge
werden als Dokumente mit
“diagonal screen size":
46,
“hdmi inputs":
3,
Attributstruktur
behandelt
“wall mountable":
true,
“built-in digital tuner": true,
‣ contrast
Ermöglichen
Abfragen und Indizierung von
“dynamic
ratio”: “50,000:1”,
Resolution”:
“1920x1080”
}
Attributwerten
"sweater",
"blue",
“M”,
“wool”,
“turtleneck"
Graphen
‣ Fokussiert auf m-zu-n Beziehungen zwischen Objekten
‣ Speichern „property graphs“. (Knoten und Kanten haben
Attribute)
‣ Einfache Abfragen für Pfade beliebiger und womöglich
unbekannter Länge
Key Value
‣
‣
‣
‣
‣
Speichere Daten immer zu einem Unique-Key
Daten werden nicht von dem System analysiert
Insbesondere gibt es kein Schema
Und keine Sekundäre Indexe
Skalieren und Partitionierung vergleichsweise einfach
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
K => V
4
Ein E-Kommerz System: Relationale Sicht
Sales-History
Einkaufswagen
Recommendations
Kunden
Produkt-Katalog
5
Polyglotte Persistenz
User Sessions
Financial Data
User Sessions
Financial Data
Redis
RDBMS
KeyValue
RDBMS
Shopping Cart
Recommendations
Shopping Cart
Recommendations
Riak
Neo4J
KeyValue
Graph
Product Catalog
Analytics
Product Catalog
Analytics
MongoDB
Cassandra
Document
Column
Reporting
User activity log
Reporting
User activity log
RDBMS
Cassandra
RDBMS
Column
Quelle: Martin Fowler, http://martinfowler.com/articles/nosql-intro.pdf
6
Single Model NoSQL-Datenbanken
Sales-History
{
{
“userID":
239178239,
“productID”: 128623883,
“number":
5,
“price”:
12.20,
}
DocumentStore
{
}
Kunden
Recommendations
GraphStore
}
{
“userID":
239178239,
“productID”: 128623883,
“number":
5,
“price”:
12.20,
}
{
423453453=>
874365563=>
4328,
6378,
3245,
3245,
“shirt”, “L”, 1, 12.99
“sweater”, “M”, 2, 37.95
“sweater”, “blue”, 1, 99.95
“pants”, “32/34”, “black”, 1, 99.95
KeyValueStore
}
5463, “shirt”, “S”, 1, 9.99
6378, “sweater”, “M”, 2, 37.95
3245, “pants”, “32/34”, “black”, 1, 99.95
}
Einkaufswagen
"Smith",
“2012-11-01",
121,
“abc”,
“def”
DocumentStore
“Name":
“lastLogin”:
“Visits":
“shipping address”:
{
“type":
“color":
“size":
“material”:
“form”:
"sweater",
"blue",
“M”,
“wool”,
“turtleneck"
{
{
“Name":
“lastLogin”:
“Visits":
“shipping address”:
“shipping address”:
}
"Meyer",
“2012-11-21",
20,
“xyz”,
“type":
“color":
“size":
“material”:
“form”:
"sweater",
"blue",
“M”,
“wool”,
“turtleneck"
“type“:
DocumentStore
“diagonal screen size":
“type“:
"pants",
“waist":
32,
“length”:
34,
“color":
"blue",
“material”: “cotton"
}
"television",
46,
“hdmi inputs":
3,
“wall mountable":
true,
“built-in digital tuner": true,
“dynamic contrast ratio”: “50,000:1”,
Resolution”:
“1920x1080”
Produkt-Katalog
7
Vorteile
‣ Natürliche Abbildung der
Daten in der DB
‣ DB ist optimiert für genau
dieses Datenformat
‣ Abfragen sind
zugeschnitten auf dieses
Format
&
Aufwand
‣ Daten müssen redundant
gehalten und synchronisiert
werden
‣ Mehrere Technologien
müssen verwendet werden
‣ Administrationsaufwand ist
deutlich höher
‣ Fokussierung auf die
Anwendungslogik
8
Alternative: Multi Model Datenbanken
‣ Können mehrere Datenformate natürlich speichern:
‣ Key-Value-Paare
‣ Dokumente
‣ Graphen
‣ Abfrage Möglichkeiten für jedes Format
‣ Unterschiedliche Abfragen sind kombinierbar
9
Polyglotte Persistenz
User Sessions
Financial Data
User Sessions
Financial Data
KeyValue
RDBMS
ArangoDB
ArangoDB
Shopping Cart
Recommendations
Shopping Cart
Recommendations
KeyValue
Graph
ArangoDB
ArangoDB
Product Catalog
Analytics
Product Catalog
Analytics
Document
Column
ArangoDB
Cassandra
Reporting
User activity log
Reporting
User activity log
RDBMS
Column
RDBMS
Cassandra
Source: Martin Fowler, http://martinfowler.com/articles/nosql-intro.pdf
10
Use Case: Multi-Model-Databases
Sales-History
{
{
“userID":
239178239,
“productID”: 128623883,
“number":
5,
“price”:
12.20,
}
DocumentStore
{
}
Kunden
Recommendations
GraphStore
}
{
“userID":
239178239,
“productID”: 128623883,
“number":
5,
“price”:
12.20,
}
{
423453453=>
874365563=>
4328,
6378,
3245,
3245,
“shirt”, “L”, 1, 12.99
“sweater”, “M”, 2, 37.95
“sweater”, “blue”, 1, 99.95
“pants”, “32/34”, “black”, 1, 99.95
KeyValueStore
}
5463, “shirt”, “S”, 1, 9.99
6378, “sweater”, “M”, 2, 37.95
3245, “pants”, “32/34”, “black”, 1, 99.95
}
Einkaufswagen
"Smith",
“2012-11-01",
121,
“abc”,
“def”
DocumentStore
“Name":
“lastLogin”:
“Visits":
“shipping address”:
{
“type":
“color":
“size":
“material”:
“form”:
"sweater",
"blue",
“M”,
“wool”,
“turtleneck"
{
{
“Name":
“lastLogin”:
“Visits":
“shipping address”:
“shipping address”:
}
"Meyer",
“2012-11-21",
20,
“xyz”,
“type":
“color":
“size":
“material”:
“form”:
"sweater",
"blue",
“M”,
“wool”,
“turtleneck"
“type“:
DocumentStore
“diagonal screen size":
“type“:
"pants",
“waist":
32,
“length”:
34,
“color":
"blue",
“material”: “cotton"
}
"television",
46,
“hdmi inputs":
3,
“wall mountable":
true,
“built-in digital tuner": true,
“dynamic contrast ratio”: “50,000:1”,
Resolution”:
“1920x1080”
Produkt-Katalog
11
Meine 4 Lieblingsfeatures von
‣ MULTI-MODEL speichert Graphen und Dokumente
‣ AQL mit eingebauten Joins & Traversals
‣ ACID beinhaltet Transaktionen über mehrere Collections
‣ FOXX erweitere die API und passe sie an deine Bedürfnisse an
12
AQL
‣ Dokument Abfrage:
FOR user IN users FILTER user.active == true
FOR game IN games FILTER game.player == user._id
RETURN {
username: user.name,
score: game.score
}
‣ Verändere Dokumente:
FOR u IN users FILTER u.status == 'not active'
UPDATE u WITH { active: false } IN users
!
‣ Graphen Traversal:
RETURN GRAPH_TRAVERSAL(
"underground_plan", "stations/main_station",
"outbound", {minDepth: 2, maxDepth: 5}
)
13
ACID - Transaktionen
‣ Führe eine Transaktion aus:
db._executeTransaction({
collections: {
write: ["users", "products"],
read: "recommendations"
},
action: function() {
// all operations go here
throw "failure"; // Triggers rollback
!
}
});
14
Vorteile
‣ Natürliche Abbildung der
Daten in der DB
‣ DB ist optimiert für genau
dieses Datenformat
‣ Abfragen sind
zugeschnitten auf dieses
Format
&
Aufwand
‣ Daten müssen redundant
gehalten und synchronisiert
werden
‣ Mehrere Technologien
müssen verwendet werden
‣ Administrationsaufwand ist
deutlich höher
‣ Fokussierung auf die
Anwendungslogik
‣ Nur noch eine Technology
nötig
15
Foxx
‣ Füge deine eigene, versionierbare REST-API zu ArangoDB
hinzu, geschrieben in JavaScript
‣ Verwende sie als Web Service von Rails, Node.js etc.
‣ Verwende sie direkt als Speicher für Web-frameworks wie AngularJS,
EmberJS, Backbone etc.
‣ OAuth2.0 und HTTP-Basic Auth eingebaut
‣ Operationen sind in der Datenbank gekapselt
‣ Weniger Netzwerkverkehr, direkter Datenzugriff
‣ Erhöht den Datenschutz
➡ Setups mit mehreren Endgeräten
➡ Microservices
/\
(~(
) )
/\_/\
( _-----_(@ @)
(
\ /
/|/--\|\ V
" "
" "
16
Eine Übersicht über
features
‣ Open Source und Kostenfrei (Apache 2 license)
‣ Sharding & Replication eingebaut
‣ JavaScript (V8 ist im Server eingebettet)
‣ Treiber für viele Programmiersprachen
‣ Eingebautes Web Interface
‣ Vollständige Dokumentation
‣ Professioneller sowie Community Support
17
Technische Details
‣ Automatische Schema Erkennung
‣ „Schema-freie“ Daten unwahrscheinlich
‣ Viele (Teil-)schemata sind zwischen Dokumenten geteilt
‣ Datenbankkern geschrieben in C++
‣ JavaScript und C++ für weitere Funktionalität
‣ Performanz kritische Teile können nach C++ portiert werden
‣ Daten werden als Memory mapped Files im Speicher gehalten
‣ Verschiedene Sekundäre Indizes
‣ Hashindex, Skiplistindex
‣ Geoindex
‣ Fulltextindex
18
Sharding Umsetzung
Coordinator
Coordinator
Consensus
DBServer
Replica
DBServer
Replica
19
Sharding Verteilung
‣ Beim erstellen einer Collection müssen angegeben werden:
‣ Anzahl der verwendeten Shards
‣ Menge von Attributen welche den Shardkey festlegen (default: _key)
‣ Derzeit nicht zur Laufzeit änderbar
‣ Dokumente werden anhand eines Hashes über die ShardAttribute verteilt.
‣ Abfragen können auch über alle anderen Attribute erfolgen
‣ Der ganze Cluster muss befragt werden
‣ Weniger Optimierungsmöglichkeiten
!
‣ Eine Sinnvolle Menge von Shardattributen muss frühzeitig
bestimmt werden
20
Graphen in ArangoDB (Einfach)
‣ Edgecollection speichert Kanten zwischen beliebigen anderen
Collections
‣ Uneingeschränkte Kanten Erstellung
‣ Keine Garantien über den Graphen
‣ Lose Enden, Verwaiste Kanten
‣ Knoten unabhängig von ihren Kanten
21
Graphen in ArangoDB (Erweitert)
‣ Graphen-Modul erlaubt Bedingungen in Graphen
‣ Kanten können auf Start- und Ziel-Collections eingeschränkt
werden
‣ Knoten sind nichtmehr unabhängig von ihren Kanten
‣ Wenn ein Knoten gelöscht wird, werden Kanten ebenso
gelöscht
‣ Wenn eine Kante erstellt wird, wird geprüft ob die Knoten
existieren
‣ Mehrere Collections können in einem Graphen
zusammengefasst werden und in einer Abfrage einfach
verwendet werden
22
Vielen Dank
!
!
!
‣ Gibt es Fragen?
‣ Twitter/github: @mchacki
‣ Email: mchacki@arangodb.com
‣ Google Group: https://groups.google.com/forum/#!forum/arangodb
23