Your SlideShare is downloading. ×
  • Gefällt mir
  • Speichern
Einführung in nosql // ArangoDB mit Symfony 2
Nächste SlideShare
Wird geladen in ...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Einführung in nosql // ArangoDB mit Symfony 2

  • 773 Views
Published

This a

This a

  • Full Name Full Name Comment goes here.
    Sind Sie sicher, dass Sie...
    Ihre Nachricht erscheint hier
    Hinterlassen Sie den ersten Kommentar
Keine Downloads

Views

Gesamtviews
773
On SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2

Aktionen

Geteilt
Downloads
0
Kommentare
0
Gefällt mir
1

Einbettungen 0

No embeds

Inhalte melden

Als unangemessen gemeldet Als unangemessen melden
Als unangemessen melden

Wählen Sie Ihren Grund, warum Sie diese Präsentation als unangemessen melden.

Löschen
    No notes for slide

Transcript

  • 1. © 2013 triAGENS GmbH | 2013-06-05NoSQL – eineÜbersichtSymfony User Group, Startplatz2013-06-05Jan Steemann (triAGENS)
  • 2. © 2013 triAGENS GmbH | 2013-06-05about:self Entwickler bei der triAGENS GmbH Multi-Model-Datenbank PHP 4.0.* ... PHP 5.3.*
  • 3. © 2013 triAGENS GmbH | 2013-06-05Relationale Datenbanken
  • 4. © 2013 triAGENS GmbH | 2013-06-05Relationale Datenbanken relationale Datenbanken:SQL Server, MySQL, Postgres, Oracle, DB2... basieren auf dem relationalen Modell (* 1970) Datensätze werden in Tabellen mittypisierten Spalten gespeichert im Datenbank-Schema wird definiert, welche Tabellen,Spalten und Datentypen verwendet werden können
  • 5. © 2013 triAGENS GmbH | 2013-06-05Beispiel: Tabelle "users"user_id user_name group_name status1 jean users active2 daniel admin active3 david users inactive4 frank admin active5 zoe users activeCREATE 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-05Normalisierung 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-05Normalisierung: 3 Tabellenuser_id user_namegroup_name1 jeanusers2 danieladmin3 david4 frank5 zoegroup_id12121group_id12status_id11211status_nameactiveinactivestatus_id12referencereference
  • 8. © 2013 triAGENS GmbH | 2013-06-05Joins, References, Constraints normalisierte Daten sind meist auf mehrere Tabellenverteilt zur Abfrage benötigt man dann Joins es können Beziehungen (references) undKonsistenzbedingungen (constraints) definiert werden diese werden von der Datenbank erzwungen
  • 9. © 2013 triAGENS GmbH | 2013-06-05Transaktionen Operationen auf mehrere Objekte (Datensätze /Tabellen) können durch Transaktionen geschütztwerden Transaktionen garantieren ACID-Eigenschaften fürOperationen:Atomicity, Consistency, Isolation, Durability
  • 10. © 2013 triAGENS GmbH | 2013-06-05Problem: Skalierung Skalierung relationaler Datenbanken ist schwierig,denn das relationale Modell und SQL erlauben beliebigeAbfragen (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-05Problem: Skalierung Skalierung relationaler Datenbanken ist schwierig,denn für Transaktionen muss eine cluster-weit konsistenteSicht auf die Daten gewahrt bleiben für die Sichtbarkeit von Commits, unique constraints,ID-Vergabe usw. ist Kommunikation zwischen Servernerforderlich tw. sind komplizierte Protokolle (z. B. two-phasecommit) und Locks erforderlich
  • 12. © 2013 triAGENS GmbH | 2013-06-05Workaround: sharding via Applikation Applikation "kennt" Verteilung der Daten und sprichtdirekt die korrekten Server an Konsistenz, Isolation usw. sind nur schwer zugewährleisten Applikation übernimmt tw. Aufgaben der Datenbank
  • 13. © 2013 triAGENS GmbH | 2013-06-05Problem: Schemas die Verwendung von fixen Schemas bewirkt, dass nurDaten gespeichert werden können, die vom Schemavorgesehen 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-05Problem: dynamische Daten Speicherung dynamischer Strukturen ist oftmalsproblematisch dynamisch = Anzahl und Typen der Attribute zurEntwicklungszeit 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-05Workaround: serialize serialize() und Speicherung in BLOB-Spalte funktioniert deaktiviert aber die meisten Datenbank-Features(SELECT auf einzelne Attribute), Inhaltsprüfung, Joinsusw. Bonus-Workaround:JSON-Spaltentyp in Postgres
  • 16. © 2013 triAGENS GmbH | 2013-06-05Problem: impedance mismatch Speicherung komplexer Strukturen/Objekte ausProgrammiersprache benötigt ORMs und/oder eigenenmapping 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-05NoSQL- die Rettung?
  • 18. © 2013 triAGENS GmbH | 2013-06-05Nicht-relationale Datenbanken in den letzten Jahren sind viele neue,nicht-relationale Datenbanken entstanden diese lösen einige der genannten Probleme(Skalierung, Schemas, dynamische Daten, impedancemismatch) 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ürviele 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-05Schemafreiheit NoSQL-Datenbanken bieten meist nur wenigMöglichkeiten zur Schema-Definition oft keine "Tabellen" und "Spalten" tw. gibt es einzeln ansprechbare Attribute undDatentypen, tw. auch nicht (= BLOB) Schemafreiheit ermöglicht, jederzeit Daten zuspeichern – auch Daten neuartiger Form
  • 21. © 2013 triAGENS GmbH | 2013-06-05Schemafreiheit Schema ist in gespeicherten Daten inhärent vorhanden verschiedene Versionen eines "Schemas" könnenparallel existieren:{ name: "..." }{ name: { first: "...", last: "..." } }{ firstName: "...", lastName: "..." } die Datenbank kennt keine "richtige" Struktur
  • 22. © 2013 triAGENS GmbH | 2013-06-05Schemafreiheit kein Migrationszwang:man kann selbst entscheiden, ob (und wann) "alte"Daten migriert werden wenn keine Migration alter Daten erfolgt, muss dieApplikation mit verschiedenen Versionen umgehenkönnen(= mehr Kontrolle, mehr Verantwortung)
  • 23. © 2013 triAGENS GmbH | 2013-06-05Normalisierung vs. not NoSQL-Datenbanken sind i. d. R. nicht fürnormalisierte Datenmodelle ausgelegt im Gegenteil ist "erwünscht", ein Objekt alszusammengehöriges Aggregat zu speichern (keineAufteilung der Objekteigenschaften auf verschiedene"Tabellen" etc.) durch die Aggregatorientierung ist das Lesen undSpeichern von kompletten Objekten einfach undschnell
  • 24. © 2013 triAGENS GmbH | 2013-06-05Beispiel: User-Objekt{"id": "user02","name": {"first": "foo","last": "bar"},"status": "active","friendIds": ["user03", "user04", "user99"]}
  • 25. © 2013 triAGENS GmbH | 2013-06-05Abfragemöglichkeiten Abfragen über Aggregatgrenzen hinweg sind tw.problematisch (abhängig von Datenbank) tw. müssen die Objekte von der Applikation einzelnabgefragt und wieder zusammengefügt werden dies ist oftmals teuer... ...und die Datenbank garantiert keine Konsistenz fürdas Gesamtergebnis
  • 26. © 2013 triAGENS GmbH | 2013-06-05NoSQL & Skalierung? NoSQL bedeutet nicht zwangsläufig "Skalierung" im NoSQL-Bereich existieren... ...single server-Datenbanken mit Fokus auf hoherPerformanz und/oder Convenience ...verteilte (distributed) Datenbanken mit Fokus aufhorizontaler Skalierung und high availability
  • 27. © 2013 triAGENS GmbH | 2013-06-05NoSQL & Skalierung in verteilten NoSQL-Datenbanken wird dieSkalierbarkeit oft erkauft durch Abstriche bei Featuresund Garantien, z. B. "teure" Features wie Joins oder Transaktionen werdennicht angeboten Abfragen in einer verteilten Datenbank haben keinezugesicherte Konsistenz Inkonsistenzen und Konflikte können (und dürfen)vorkommen. Nicht die Datenbank, sondern dieApplikation muss sie behandeln
  • 28. © 2013 triAGENS GmbH | 2013-06-05NoSQL-Datenbank-Kategorien die meisten NoSQL-Datenbanken können folgendenKategorien zugeordnet werden: Key/value stores (Wide) column stores (404) Dokumentdatenbanken Graph-Datenbanken jede Kategorie bietet verschiedeneAbfragemöglichkeiten und Einsatzbereiche
  • 29. © 2013 triAGENS GmbH | 2013-06-05Key Value Stores
  • 30. © 2013 triAGENS GmbH | 2013-06-05Prinzip 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) BLOBsbehandelt Zugriff auf Teilwerte nicht möglich
  • 31. © 2013 triAGENS GmbH | 2013-06-05Beispiele 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-05Eigenschaften wenig Overhead, denn Werteinhalte werden vom store "ignoriert" (keinParsing, kein Schema, keine Validierung) es gibt nur simple Zugriffsmethoden(keine Abfragesprachen usw.) ideal, wenn Werte komplett und nicht in Einzelteilenabgefragt werden sollen (serialisierte Objekte, BLOBs)
  • 33. © 2013 triAGENS GmbH | 2013-06-05Distributed key/value stores simples key/value-Modell erlaubt Skalierung:voneinander unabhängige keys können aufverschiedene Server verteilt werden i. d. R. besteht kein Einfluss darauf, welche Serverkonkret für welche keys zuständig sind oft ist kontrollierbar, wie viele Server für jeden Keyzuständig sind ("Quorum") dadurch high availability mit Failover
  • 34. © 2013 triAGENS GmbH | 2013-06-05Beispiele embedded: Kyoto Cabinet single server: Memcached, Redis distributed: Couchbase, Riak, Oracle NoSQL services: Dynamodb
  • 35. © 2013 triAGENS GmbH | 2013-06-05Dokumentendatenbanken
  • 36. © 2013 triAGENS GmbH | 2013-06-05Prinzip 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-05Dokument: Beispiel{"id": "user02","name": {"first": "foo","last": "bar"},"status": "active","friendIds": ["user03", "user04", "user99"]}
  • 38. © 2013 triAGENS GmbH | 2013-06-05Abfragemöglichkeiten auf die Attribute von Dokumenten kann auch einzelnzugegriffen werden tw. können auch Indizes auf die einzelnen Attributeangelegt werden deutlich erweiterte Abfragemöglichkeiten gegenüberKey/value stores
  • 39. © 2013 triAGENS GmbH | 2013-06-05Collections, Schemafreiheit Dokumente desselben Typs werden in derselben"Collection" gespeichert (Äquivalent zur "Tabelle" inrelationalen Datenbanken) Collections haben kein vordefiniertes Schema verschiedene Dokumente in derselben Collectionkönnen unterschiedliche Attribute besitzen
  • 40. © 2013 triAGENS GmbH | 2013-06-05Speichern 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-05Listen und Unterobjekte Listen können direkt in Dokumente eingebettet undabgefragt werden, ohne Transformation/Joins etc:"friendIds" => array("user01", "user03", "user99") Objekte in Programmiersprachen lassensich relativ gut als Dokumente abbilden Arrays und Unterobjekte müssen nicht erst normalisiertwerden
  • 42. © 2013 triAGENS GmbH | 2013-06-05Beispiele single server: CouchDB, ArangoDB distributed: MongoDB, CouchBase, RavenDB,RethinkDB
  • 43. © 2013 triAGENS GmbH | 2013-06-05Graph-Datenbanken
  • 44. © 2013 triAGENS GmbH | 2013-06-05Prinzip ein "Graph" ist die Gesamtheit von Objekten (Knoten, auch "vertices") sowie Beziehungen (Kanten, auch "edges")danieldavidzoefrankstuart
  • 45. © 2013 triAGENS GmbH | 2013-06-05Prinzip die Objekte und Beziehungen sind meist beliebigstrukturier- und typisierbar ein Objekt kann mehrere Beziehungen zu anderenObjekten aufweisen (1:1, 1:n, n:m)
  • 46. © 2013 triAGENS GmbH | 2013-06-05Graph: 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-05Einsatzmöglichkeiten Hierarchien, Klassifikationen (Bäume) soziale Beziehungen (Netzwerke) geographische Daten (Navigation, Routen) ... die Objekte selbst und die direkten undindirekten Beziehungen ("Pfade") sindabfragbar
  • 48. © 2013 triAGENS GmbH | 2013-06-05Graph-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-05Multi-Model-Datenbanken Multi-Model-Datenbanken verbindenverschiedene Datenmodelle undAbfragemöglichkeiten Beispiele: OrientDB (Dokumente, Graphen, „SQL“) ArangoDB (Dokumente, Graphen, AQL)
  • 50. © 2013 triAGENS GmbH | 2013-06-05Fazit
  • 51. © 2013 triAGENS GmbH | 2013-06-05NoSQL Key/value stores schränken Abfragemöglichkeiten ein,sind aber für große Datenmengen oder hohenDurchsatz oft die einzige Lösung Dokumentendatenbanken sind relativ breit einsetzbar Graphen können eine sinnvolle Ergänzung sein undbieten zusätzliche Möglichkeiten Schemafreiheit ermöglicht relativ leichten Einstieg undeinfachere Entwicklung
  • 52. © 2013 triAGENS GmbH | 2013-06-05NoSQL viele NoSQL-Datenbanken bieten geringere Garantienals 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üssenbei Bedarf von der Applikation emuliert werden
  • 53. © 2013 triAGENS GmbH | 2013-06-05Relational vs. NoSQL welche Datenbank am besten geeignet ist, hängt vomkonkreten Anwendungsfall ab keine Datenbank (relational und NoSQL) ist für jedenEinsatzbereich geeignet es geht darum, die beste(n) Datenbank(en) für denjeweiligen Anwendungsfall zu finden
  • 54. © 2013 triAGENS GmbH | 2013-06-05Relational || NoSQL relationale Datenbanken sind etabliert und für vieleEinsatzgebiete geeignet es gibt viele Entwickler und Tools für relationaleDatenbanken NoSQL-Datenbanken sind heterogen und noch nicht soetabliert sie können aber durchaus gute und tw. auch bessereLösungen für bestimmte Probleme sein
  • 55. © 2013 triAGENS GmbH | 2013-06-05Relational && 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 dasrelationale Modell nicht "passt" und sowieso bereitsWorkarounds verwendet werden (dynamische Daten,Graphen, BLOBs, ...)
  • 56. © 2013 triAGENS GmbH | 2013-06-05Web-Datenbanken viele NoSQL-Datenbanken bieten eine HTTP-REST-API, über die Clients mit der Datenbankkommunizieren können solche Datenbanken können meist mittels Browseradministriert und auch genutzt werden HTML/JavaScript-Front ends können die Datenbankebenfalls "direkt" nutzen
  • 57. © 2013 triAGENS GmbH | 2013-06-05Web-Datenbanken diverse NoSQL-Datenbanken sind server-seitig mittelsJavaScript erweiterbar das ermöglicht einen einfachen Einstieg und sogarJavaScript-code reusage
  • 58. +{"title":"Hello World Example","database":"ArangoDB",“me":“Dorthe Luebbert““twitter":“luebbert42“}Using ArangoDB with Symfony – an introduction
  • 59. +Infrastructuren  Symfony 2.xn  ArangoDB 1.3n  Bundlesn  triagens/arangodb-> PHP drivern  mop/arangodbbundle-> bridge to Symfony-> configuration-> integration with FosUserBundlen  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 uihttp://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.ymlmop_arango_db:default_connection: mainconnections:main:host: 127.0.0.1port: 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 modelAggregate model-  nested structure-  redundancy = ok-  ! joins
  • 64. +Scope of the PHP drivern  Driver wraps around the HTTP interfacen  Accessn  Documentsn  Collectionsn  Graphsn  Transactionsn  „Advanced“ queries using AQL (ArangoDB‘s query language similarto SQL, but also handling graphs, lists...)n  maps JSON documents to extendable PHP objectsn  nested structures are mapped to arraysn  access document properties via get(attributename)
  • 65. +List example: controller// src/Triagens/ArangodbBundle/Controller/DefaultController.phpuse triagensArangoDbDocument;use triagensArangoDbCollectionHandler asCollectionHandler;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-05Vielen Dank!Stay in touch:Fork me on githubGoogle group: ArangoDBTwitter: @steemann @arangodbwww.arangodb.orgFoxx – Javascript applicationframework for ArangoDB