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 4
Ein E-Kommerz System: Relationale Sicht Sales-History Recommendations Kunden Einkaufswagen 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 Recommendations Kunden userid": 239178239, Name": "Smith", productid : 128623883, lastlogin : 2012-11-01", number": 5, Visits": 121, price : 12.20, shipping address : abc, shipping address : def DocumentStore GraphStore DocumentStore userid": 239178239, productid : 128623883, number": 5, price : 12.20, Name": "Meyer", lastlogin : 2012-11-21", Visits": 20, shipping address : xyz, 423453453=> 874365563=> 4328, shirt, L, 1, 12.99 6378, sweater, M, 2, 37.95 3245, sweater, blue, 1, 99.95 3245, 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 type": "sweater", color": "blue", size": M, material : wool, form : turtleneck" type : "pants", waist": 32, length : 34, color": "blue", material : cotton" type : "television", diagonal screen size": 46, hdmi inputs": 3, wall mountable": true, built-in digital tuner": true, dynamic contrast ratio : 50,000:1, Resolution : 1920x1080 DocumentStore Produkt-Katalog type": "sweater", color": "blue", size": M, material : wool, form : turtleneck" 7
Vorteile & Aufwand Natürliche Abbildung der Daten in der DB DB ist optimiert für genau dieses Datenformat Abfragen sind zugeschnitten auf dieses Format Fokussierung auf die Anwendungslogik Daten müssen redundant gehalten und synchronisiert werden Mehrere Technologien müssen verwendet werden Administrationsaufwand ist deutlich höher 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 Recommendations Kunden userid": 239178239, Name": "Smith", productid : 128623883, lastlogin : 2012-11-01", number": 5, Visits": 121, price : 12.20, shipping address : abc, shipping address : def DocumentStore GraphStore DocumentStore userid": 239178239, productid : 128623883, number": 5, price : 12.20, Name": "Meyer", lastlogin : 2012-11-21", Visits": 20, shipping address : xyz, 423453453=> 874365563=> 4328, shirt, L, 1, 12.99 6378, sweater, M, 2, 37.95 3245, sweater, blue, 1, 99.95 3245, 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 type": "sweater", color": "blue", size": M, material : wool, form : turtleneck" type : "pants", waist": 32, length : 34, color": "blue", material : cotton" type : "television", diagonal screen size": 46, hdmi inputs": 3, wall mountable": true, built-in digital tuner": true, dynamic contrast ratio : 50,000:1, Resolution : 1920x1080 DocumentStore Produkt-Katalog type": "sweater", color": "blue", size": M, material : wool, form : turtleneck" 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 & Aufwand Natürliche Abbildung der Daten in der DB DB ist optimiert für genau dieses Datenformat Abfragen sind zugeschnitten auf dieses Format Fokussierung auf die Anwendungslogik Nur noch eine Technology nötig Daten müssen redundant gehalten und synchronisiert werden Mehrere Technologien müssen verwendet werden Administrationsaufwand ist deutlich höher 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 DBServer Replica 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 Shard- Attribute 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