Neo4j Graph Database Presentation (German)
Als KEY, PDF herunterladen3 gefällt mir4,793 aufrufe
Das Dokument behandelt die Vorteile von Graphdatenbanken im Vergleich zu traditionellen relationalen Modellen, insbesondere bei der Modellierung komplexer Beziehungen. Es werden verschiedene Typen von NoSQL-Datenbanken, inklusive ihrer Anwendungsfälle, sowie die Herausforderungen des Informationswachstums und der Komplexität in der Datenverarbeitung thematisiert. Des Weiteren wird die Struktur und Funktionsweise des Property-Graph-Datenmodells erläutert.
![Die Zukunft
๏ Neo4j-Hosting
• Heroku
• CloudFoundry
• DotCloud
• Azure
๏ Query Language
from n=NODE(name,“Emil“), n -[r,KNOWS,..]-> f
where f.name = „Michael“
select n.name, f.name, r.length
๏ bessere Remote-Protokolle
๏ mehr Index Provider (Redis, BDB)
63](https://image.slidesharecdn.com/jax2011-110505164901-phpapp02/85/Neo4j-Graph-Database-Presentation-German-100-320.jpg)
Neo4j Graph Database Presentation (German)
- 1. Gute Beziehungen Graphendatenbanken für Jedermann twitter: @mesirii / #neo4j Michael Hunger email: michael@neotechnology.com web: http://www.neo4j.org/ Hacker @ Neo Technology web: http://www.jexp.de/
- 2. Agenda JAX 2011 Matrix PRESENTED_AT MODELS MODELS PRESENTED_AT PRESENTED_AT Neo4j NOSQL IS_A BELONGS_TO 2
- 3. Relationales Modell, allseits bekannt We all know the relational model. It has been predominant for a long time. Attendees username fullname registration speaker payment mtiberg Michael Tiberg null no 0 thobe Tobias Ivarsson 2010-04-07 yes 0 joe John Doe 2010-02-05 no 700 ... ... ... ... ... 3
- 4. Relationales Modell, allseits bekannt We all know the relational model. Attendees It has been predominant for a long time. username fullname registration speaker payment mtiberg Michael Tiberg null no 0 thobe Tobias Ivarsson 2010-04-07 yes 0 joe John Doe 2010-02-05 no 700 ... ... ... ... ... 3
- 5. Relationales Modell, allseits bekannt We all know the relational model. It has been predominant for a long time. Attendees username fullname registration speaker payment mtiberg Michael Tiberg null no 0 thobe Tobias Ivarsson 2010-04-07 yes 0 joe John Doe 2010-02-05 no 700 ... ... ... ... ... 3
- 6. Attendees The relational model has username fullname registration speaker payment a few problems, such as: •poor support for sparse data •modifying the data mtiberg Michael Tiberg null no 0 model is almost exclusively done through adding tables thobe Tobias Ivarsson 2010-04-07 yes 0 joe John Doe 2010-02-05 no 700 ... ... ... ... ... Location username latitude longitude title publish thobe 55°36'47.70"N 12°58'34.50"E Malmö yes San joe 37°49'36.00"N 122°25'22.00"W no Francisco ... ... ... ... ... 4
- 7. Attendees username fullname registration speaker payment mtiberg Michael Tiberg null no 0 thobe Tobias Ivarsson 2010-04-07 yes 0 joe John Doe 2010-02-05 no 700 ... ... ... ... ... Location username latitude longitude title publish thobe 55°36'47.70"N 12°58'34.50"E Malmö yes After a while, modeling complex relationships leads to complicated San schemasjoe 37°49'36.00"N 122°25'22.00"W no Francisco ... ... ... ... ... 5
- 8. Attendees Sessions username fullname registration speaker payment id title time room ... ... ... ... ... ... mtiberg Michael Tiberg null no 0 ... ... ... ... ... thobe Tobias Ivarsson 2010-04-07 yes 0 Session attendance joe John Doe 2010-02-05 no 700 session user ... ... ... ... ... ... ... Location ... ... username latitude longitude title publish More complication... thobe 55°36'47.70"N 12°58'34.50"E Malmö yes ... ... ... ... After a while, modeling ... ... complex relationships ... ... leads to complicated ...... ...... San ...... schemasjoe 37°49'36.00"N 122°25'22.00"W no ...... Francisco ...... ...... ...... ...... ... ... ... ... ... 5
- 9. After a while, modeling complex relationships leads to complicated schemas 5
- 10. Netze sind überall 6
- 11. Willkommen in der Matrix - die Welt - ein Netz Google Bildersuche: „graph OR network“ 7
- 12. Willkommen in der Matrix - die Welt - ein Netz ๏ Zusammenhänge in • Politik,Wirtschaft, Geschichte,Wissenschaft,Verkehr ๏ Biologie, Chemie, Physik, Soziologie • Körper, Ökosphere, Reaktionen, Interaktionen ๏ Internet • Hardware, Software, Interaktion ๏ Soziale Netzwerke • Familie, Freunde • Arbeit, Communities • Nachbarn, Städte, Lebensräume, Gesellschaft 8
- 13. Gute Beziehungen ๏ die Welt besteht aus Dingen und deren Beziehungen ๏ Beziehungen sind oft genauso wichtig wie die Dinge ๏ Netze = Ganzes > Summe der Teile ๏ komplexe Zusammenhänge ๏ ständiger Wandel,Veränderung auch von Strukturen ๏ Graph: Beziehungen sind Teil der Daten ๏ RDBMS: Beziehungen sind Teil des starren Schemas 9
- 14. Fragen und Antworten ๏ Komplexe Fragen ๏ Antworten liegen zwischen den Zeilen (Dingen) ๏ Lokalität der Informationen ๏ Globale Suchen sind sehr teuer ๏ Antwortzeiten sollten konstant sein, unabhängig von Datenmenge 10
- 15. Kategorien ? ๏ Kategorien == Klassen, Bäume ? ๏ Was ist wenn mehr als eine Kategorie passt? ๏ Tags ๏ Kategorie über Beziehungen „IS_A“ ๏ beliebig viele, schnelle Änderung ๏ „virtuelle“ Beziehungen - Traversals ๏ Kategorie dynamisch aus den Fragestellungen 11
- 16. 3 aktuelle Beispiele 12
- 17. Fowler & Christakis „Connected“ 13
- 18. New York Times R&D „Cascade“ 14
- 19. Deb Roy - MIT & Bluefin Labs „Birth of a Word“ TED Talk Researches Social Reactions to (Media) Events 15
- 20. Trends im Internet 16
- 21. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen 17
- 22. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen 1990 17
- 23. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application 1990 17
- 24. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application Text 1990 17
- 25. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application Text Hypertext 1990 17
- 26. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application Text Hypertext 1990 web 1.0 17
- 27. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application Hypertext RSS Text 1990 web 1.0 17
- 28. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Application Blogs Hypertext RSS Text 1990 web 1.0 17
- 29. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application Blogs Hypertext RSS Text 1990 web 1.0 17
- 30. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application Blogs RSS Wikis Text Hypertext 1990 web 1.0 17
- 31. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 17
- 32. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application user generated Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 17
- 33. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application user generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 17
- 34. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications Application user generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 web 2.0 17
- 35. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications RDF Application user generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 web 2.0 17
- 36. Informationswachstum Datenmenge Vernetzung Geräte aktive Nutzer Architekturen Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 web 2.0 17
- 37. Informationswachstum Datenmenge Services / Applications Vernetzung Geräte aktive Nutzer Architekturen Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 web 2.0 17
- 38. Informationswachstum Datenmenge Services / Applications Vernetzung Geräte aktive Nutzer Architekturen Semantic Web Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 web 1.0 web 2.0 17
- 39. Informationswachstum Datenmenge Services / Applications Vernetzung Geräte aktive Nutzer Architekturen Semantic Web Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 2011 web 1.0 web 2.0 17
- 40. Informationswachstum Datenmenge Services / Applications Giant Global Vernetzung Graph Geräte aktive Nutzer Architekturen Semantic Web Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 2011 web 1.0 web 2.0 17
- 41. Informationswachstum Datenmenge Services / Applications Giant Global Vernetzung Graph Geräte aktive Nutzer Architekturen Semantic Web Applications RDF Application user Ontologien generated tagging Blogs RSS Wikis Text Hypertext 1990 2000 2011 web 1.0 web 2.0 web 3.0 17
- 42. Herausforderung - CAP ๏ CAP Theorem (Brewer 2000) • Consistency • Availability • Partition Tolerance 18
- 43. NOSQL heisst Not Only SQL Polyglot Persistence 19
- 44. Vier NOSQL Kategorien NOSQL 20
- 45. Kategorie 1: Key-Value Datenbanken ๏ Herkunft: • “Dynamo: Amazon’s Highly Available Key-Value Store” (2007) ๏ Datenmodell: • Verteilte HashMap - Key-Value Paare ๏ Beispiele: • Project Voldemort • Tokyo {Cabinet,Tyrant, etc} • Riak 21
- 46. Kategorie II: Column (BigTable) Datenbanken ๏ Herkunft: • “Bigtable:(2006) Data” A Distributed Storage System for Structured ๏ Datenmodell: • Große Tabelle mit Spalten Familien ๏ Beispiele: • HBase • HyperTable • Cassandra 22
- 47. Kategorie III: Dokumentendatenbanken ๏ Herkunft: • Lotus Notes ๏ Datenmodell: • Sammlung von Dokumenten • Ein Dokument ist eine Key-Value Menge ๏ Beispiele: • CouchDB (CouchBase) • MongoDB 23
- 48. Kategorie IV: Graphendatenbanken ๏ Herkunft: • Graphentheory, Euler ๏ Datenmodell: • Knoten mit Attributen • Gerichtete Kanten • Kanten mit Identität,Typ und Attributen • Hyperedges 24
- 49. Scaling to size vs. Scaling to complexity Size Key/Value stores Bigtable clones Document databases Graph databases Billions of nodes and relationships > 90% of use cases Complexity 25
- 50. Komplexes Problem? Passende Tools! Image credits: Unknown :’( 26
- 51. Polyglot Persistence ๏ Ein System, mehrere Datenbanken - das beste Tool für das Problem nutzen ๏ Beispiele: • RDBMS für strukturierte DatenEntitäten Graphendatenbank für die Relationen zwischen den und eine • Domänenmodell in derDokumenten Datenbankgroße Dokumente in einer Graphendatenbank und 27
- 52. Graphendatenbanken 28
- 53. Overview Graph Databases ๏Neo4j ๏InfoGrid ๏Sones GraphDB ๏DEX ๏Infinite Graph ๏VertexDB (Objectivity) ๏FlockDB (Twitter) ๏AllegroGraph (Franz ๏Trinity (Microsoft) inc.) ๏CloudGraph ๏OrientDB ๏HypergraphDB 29
- 54. The Property Graph data model •Nodes •Relationships bet ween Nodes •Relationships have Labels •Relationships are directed, but traversed at equal speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 55. The Property Graph data model •Nodes •Relationships bet ween Nodes •Relationships have Labels •Relationships are directed, but traversed at equal speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 56. The Property Graph data model •Nodes •Relationships bet ween Nodes •Relationships have Labels •Relationships are directed, but traversed at equal speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 57. The Property Graph data model LIVES WITH LOVES OWNS DRIVES •Nodes •Relationships bet ween Nodes •Relationships have Labels •Relationships are directed, but traversed at equal speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 58. The Property Graph data model LOVES LIVES WITH LOVES OWNS DRIVES •Nodes •Relationships bet ween Nodes •Relationships have Labels •Relationships are directed, but traversed at equal speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 59. The Property Graph data model name: “Mary” LOVES name: “James” age: 35 age: 32 LIVES WITH twitter: “@spam” LOVES OWNS DRIVES •Nodes •Relationships bet ween Nodes •Relationships have Labels brand: “Volvo” •Relationships are directed, but traversed at equal model: “V70” speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 60. The Property Graph data model name: “Mary” LOVES name: “James” age: 35 age: 32 LIVES WITH twitter: “@spam” LOVES OWNS item type: “car” DRIVES •Nodes •Relationships bet ween Nodes •Relationships have Labels brand: “Volvo” •Relationships are directed, but traversed at equal model: “V70” speed in both directions •The semantics of the direction is up to the application (LIVES WITH is reflexive, LOVES is not) •Nodes have key-value properties •Relationships have key-value properties 30
- 61. Graphen sind whiteboard friendly An application domain model outlined on a whiteboard or piece of paper would be translated to an ER-diagram, then normalized to fit a Relational Database. With a Graph Database the model from the whiteboard is implemented directly. Image credits: Tobias Ivarsson 31
- 62. Graphen sind whiteboard friendly An application domain model outlined on a whiteboard or piece of paper would be translated to an ER-diagram, then normalized to fit a Relational Database. With a Graph Database the model from the whiteboard is implemented directly. * 1 * * 1 * 1 * 1 * Image credits: Tobias Ivarsson 31
- 63. Graphen sind whiteboard friendly An application domain model outlined on a whiteboard or piece of paper would be translated to an ER-diagram, then normalized to fit a Relational Database. With a Graph Database the model from the whiteboard is implemented directly. thobe Joe project blog Wardrobe Strength Hello Joe Modularizing Jython Neo4j performance analysis Image credits: Tobias Ivarsson 31
- 64. Anwendungsgebiete ๏ Vernetzte Domänen ๏ Beziehungen zwischen Entitäten sind ein wichtiger Aspekt ๏ Komplexe Fragestellungen ๏ Lokale Antworten, durch mehrstufige Traversierung 32
- 65. typische Beispiele 33
- 66. Routing 34
- 67. Soziale Netze 35
- 69. Spatial - GIS 37
- 70. ungeeignete Anwendungsgebiete ๏ Datenmengen > Pentabyte ๏ viele parallele simple lookup Anfragen (KV) ๏ massive Setoperationen auf großen, gleich strukturierten Daten (RDBMS) ๏ viele große Binärdaten (BLOB) 38
- 71. Neo4j is a Graph Database Graph databases FOCUS on the interconnection bet ween entities. 39
- 72. IS _A Neo4j Graph Database Graph databases FOCUS on the interconnection bet ween entities. 39
- 73. Anforderungen an ein Soziales Netzwerk ๏ Mit Freunden interagieren ๏ Empfehlungen für neue Freunde ๏ Sozialer Kontext einer Person z.B. Wie bin ich mit derjenigen verbunden? ๏ Rechte innerhalb des Netzes • z.b. Darf ich auf Daten der Person zugreifen? 40
- 74. “Schema” design ๏ Personen sind Knoten ๏ Freundschaften sind Beziehungen zwischen Personen Knoten ๏ Gruppen sind Knoten ๏ Gruppenmitgliedschaft sind Beziehungen zwischen von Personen Knoten zu Gruppen Knoten ๏ Index für Personen Knoten für Suche nach Namen ๏ Index für Gruppen Knoten für Suche nach Namen ๏ Traversals für Empfehlungen für Personen die nach Namen gesucht wurden ๏ Zugriffsrechte über Traversals von aktueller Person über Gruppen zu Zielperson 41
- 75. Beispiel: Ein soziales Netzwerk 42
- 76. Ein kleines soziales Netz Knoten haben verschiedene Eigenschaften Matrix Charaktere: Menschen vs. Programme Strukturen und Eigenschaften nach und nach aufbauen Fragestellungen: Gegner von Neo
- 77. Ein kleines soziales Netz FRIENDSHIP MEMBERSHIP Dozer Nebuchadnezzar crew ily :F am r a lifie Qu Tank Morpheus Agent Brown Agent Smith Thomas Anderson Cypher Q ua lifi er :L ov er s Agent taskforce Trinity 44
- 78. Neo4j API: Creating a social graph GraphDatabaseService graphDb = new EmbeddedGraphDatabase( GRAPH_STORAGE_LOCATION ); Transaction tx = graphDb.beginTx(); try { Node mrAnderson = graphDb.createNode(); mrAnderson.setProperty( "name", "Thomas Anderson" ); mrAnderson.setProperty( "age", 29 ); Node morpheus = graphDb.createNode(); morpheus.setProperty( "name", "Morpheus" ); morpheus.setProperty( "rank", "Captain" ); Relationship friendship = mrAnderson.createRelationshipTo( morpheus, SocialGraphTypes.FRIENDSHIP ); tx.success(); } finally { tx.finish(); } 45
- 79. Neo4j SDG API: Creating a social graph @NodeEntity class Person { @Indexed String name; @Min(0) @Max(120) int age; Rank rank; @RelatedTo(elementClass= Person.class, type = "FRIENDSHIP") Set<Person> friends; } Person mrAnderson = new Person("Thomas Anderson"); mrAnderson.setAge( 29 ); Person morpheus = new Person("Morpheus" ); morpheus.setRank( Rank.Captain ); mrAnderson.getFriends().add(morpheus); mrAnderson.relateTo(morpheus, "FRIENDSHIP"); 46
- 80. Neo4j Ruby API: Creating a social graph gem install neo4j require ”rubygems” require 'neo4j' class Person include Neo4j::NodeMixin property :name, :age, :rank index :name has_n :friends end Neo4j::Transaction.run do neo = Person.new :name=>'Neo', :age=>29 morpheus = Person.new :name=>'Morpheus', :rank=>'Captain' neo.friends << morpheus end neo.friends.each {|p|...} 47
- 81. Neo4j API: Recommend new friends Node person = ... TraversalDescription friendsOfFriends = Traversal.description() .relationships( SocialGraphTypes.FRIENDSHIP ) .breadthFirst() .evaluator( Evaluators.atDepth( 2 ) ); for ( Node recommendation : friendsOfFriends.traverse( person ).nodes() ) { System.out.println( recommendedFriend.getProperty("name") ); } 48
- 82. Neo4j SDG API: Recommend new friends class Person { @GraphTraversalBuilder(elementClass=Person.class, builder = FOFBuilder.class) Iterable<Person> friendOfFriends; } class FOFBuilder implements FieldTraversalDescriptionBuilder { public TraversalDescription build(NodeBacked start ...) { return Traversal.description().breadthFirst() .relationships( SocialGraphTypes.FRIENDSHIP ) .evaluator( Evaluators.atDepth( 2 ) ); }} TraversalDescription friendsOfFriends = for ( Person recommendation : person.getFriendsOfFriends()) { System.out.println( recommendation.getName() ); } 49
- 83. Neo4j API: How do I know this person? Node me = ... Node you = ... PathFinder shortestPathFinder = GraphAlgoFactory.shortestPath( Traversals.expanderForTypes( SocialGraphTypes.FRIENDSHIP, Direction.BOTH ), /* maximum depth: */ 4 ); Path shortestPath = shortestPathFinder.findSinglePath(me, you); for ( Node friend : shortestPath.nodes() ) { System.out.println( friend.getProperty( "name" ) ); } 50
- 84. Gibt es eine Verbindung im sozialen Netz ๏ Jeder hat durchschnittlich 50 Freunde Tobias Emil Johan Peter 51
- 85. Gibt es eine Verbindung im sozialen Netz ๏ Jeder hat durchschnittlich 50 Freunde Tobias Emil Johan Peter Database # persons query time Relational database 1 000 2 000 ms Neo4j Graph Database 1 000 2 ms Neo4j Graph Database 1 000 000 2 ms 51
- 86. Gibt es eine Verbindung im sozialen Netz ๏ Jeder hat durchschnittlich 50 Freunde Tobias Emil Johan Peter Database # persons query time Relational database 1 000 2 000 ms Neo4j Graph Database 1 000 2 ms Neo4j Graph Database 1 000 000 2 ms 51
- 87. Gibt es eine Verbindung im sozialen Netz ๏ Jeder hat durchschnittlich 50 Freunde Tobias Emil Johan Peter Database # persons query time Relational database 1 000 2 000 ms Neo4j Graph Database 1 000 2 ms Neo4j Graph Database 1 000 000 2 ms 51
- 88. Gibt es eine Verbindung im sozialen Netz ๏ Jeder hat durchschnittlich 50 Freunde Tobias Emil Johan Peter Database # persons query time Relational database 1 000 2 000 ms Neo4j Graph Database 1 000 2 ms Neo4j Graph Database 1 000 000 2 ms 51
- 89. Visualisierung 52
- 90. Visualisierung Energie-Markt-Simulation •Alfredas Chmieliauskas (Doktorant) •TU Delft •Spring Data Graph •Tinkerpop Gremlin •Visualisierung GraphViz 53
- 91. Mehr über Neo4j ๏ Neo4j läuft produktiv • In 24/7 Betrieb seit 2003 ๏ Neo4j wird aktiv entwickelt • Neo Technology hatte mehrere VC Finanzierungs - Runden ๏ Neo4j erbringt hochperformante Graphen-Operationen • 32 Mrd Knoten/Relationships & 64 Mrd Properties • traversiert 1’000’000+ Relationships / Sekunde auf Standardhardware 54
- 92. Features ๏ ACID (JTA/JTS, XA, 2PC, Tx recovery, deadlock detection, MVCC) ๏ Treiber (nativ, REST) für viele Programmiersprachen ๏ Property Graph Model ๏ hochperformante Traversals ๏ Data Size / Short Strings ๏ eigenes binäres Storage-Format (NIO / memory mapping) ๏ Integration externer Transaction Manager ๏ verschiedene Indexing Provider (Lucene, Redis, Berkeley DB) 55
- 93. Bindings REST:// 56
- 94. Domänen Frameworks Iʼm excited about Spring Data Graph. - Rod Johnson ๏ Zusammenarbeit mit vmware / SpringSource • Annotationen für Domänen Objekte • transparentes Mapping (AspectJ) • Neo4jTemplate • Neo4j-Server Integration • Tx-Integration ๏ http://www.springsource.org/spring-data/neo4j ๏ Tutorial Beispiel App - http://cineasts.net ๏ Guide-Book http://bit.ly/das-book 57
- 95. Domänen Frameworks ๏ Neo4jrb 1.0 - Komplett-Integration (Ruby, Rails) ๏ Grails - Plugin ๏ Django - Integration ๏ Qi4j (www.qi4j.org) • Framework für DDD in reinem Java5 • Entities / Associations / Properties • Neo4j ist ein “EntityStore” ๏ Jo4neo (http://code.google.com/p/jo4neo) • Annotations • Neo4j Persistence Pattern in Domänen Objekte 58
- 96. Anwender ๏ StudiVZ - soziale Netze ๏ ThingWorx - Network of Things ๏ amanziTel - TelCo Infrastruktur ๏ Bio4j - bioinformatics DB ๏ structr - open source CMS ๏ evident Software - device management ๏ und viele mehr ๏ einige Großfirmen, die (noch) nicht genannt werden wollen 59
- 97. Neo4j ist Open Source - Produkte & Lizenzen ๏ Community Edition • alle Features, Embedded und Server • GPL ๏ Advanced • + Monitoring & Support • AGPL oder Commercial ๏ Enterprise • HA • Online Backup • AGPL oder Commercial 60
- 98. Aktive Community ๏ Open Source & Engagement ist Grundlage für Erfolg ๏ durch GPL noch einmal verstärkt ๏ sehr aktive Mailingliste (700 / Monat) ๏ GitHub • http://github.com/neo4j • http://github.com/neo4j-examples ๏ Wiki • http://wiki.neo4j.org ๏ Alle Bindings / Driver von der Community entwickelt • http://neo4j.org/community/languages/ 61
- 99. Social movie database tutorial - cineasts.net Runs on top of the Spring Framework, Spring Data Graph and Neo4j Also available on VMware‘s PaaS offering CloudFoundry http://cineasts.cloudfoundry.com 62
- 100. Die Zukunft ๏ Neo4j-Hosting • Heroku • CloudFoundry • DotCloud • Azure ๏ Query Language from n=NODE(name,“Emil“), n -[r,KNOWS,..]-> f where f.name = „Michael“ select n.name, f.name, r.length ๏ bessere Remote-Protokolle ๏ mehr Index Provider (Redis, BDB) 63
- 101. @Neo4j OR #neo4j http://neotechnology.com
Hinweis der Redaktion
- #2: Show of Hands NOSQL , Graphendatenbanken\n
- #3: \n
- #4: Ein Blick zur&#xFC;ck\n
- #5: Ein Blick zur&#xFC;ck\n
- #6: TODO: pros and cons with RDBMS\n
- #7: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #8: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #9: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #10: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #11: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #12: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #13: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #14: TODO: explain how it get out of hand. scaling + complexity\n... what if we could rethink the model ...\n
- #15: \n
- #16: social networks (our actions in them work life health)\nthe internet\nits hardware\nits software\nour interactions\nour body\nnature environment\npolitical economic networks\nzusammenhaenge\nhistory\nscience\nzeit gr&#xFC;nen abgeordneter handy\n
- #17: social networks (our actions in them work life health)\nthe internet\nits hardware\nits software\nour interactions\nour body\nnature environment\npolitical economic networks\nzusammenhaenge\nhistory\nscience\nzeit gr&#xFC;nen abgeordneter handy\n
- #18: messy world\nfast changing world\nbez um graph sind teil der daten\nim rdbms teil des starren schemas\nkomplexe zusammenhaenge\nkomplexe fragen\nimmer neue kategorien - rels\ndynamisch - traversals\ntags attribute\ntemporale attribute\ndyn sprachen besser geeignet \n
- #19: messy world\nfast changing world\nbez um graph sind teil der daten\nim rdbms teil des starren schemas\nkomplexe zusammenhaenge\nkomplexe fragen\nimmer neue kategorien - rels\ndynamisch - traversals\ntags attribute\ntemporale attribute\ndyn sprachen besser geeignet \n
- #20: messy world\nfast changing world\nbez um graph sind teil der daten\nim rdbms teil des starren schemas\nkomplexe zusammenhaenge\nkomplexe fragen\nimmer neue kategorien - rels\ndynamisch - traversals\ntags attribute\ntemporale attribute\ndyn sprachen besser geeignet \n
- #21: messy world\nfast changing world\nbez um graph sind teil der daten\nim rdbms teil des starren schemas\nkomplexe zusammenhaenge\nkomplexe fragen\nimmer neue kategorien - rels\ndynamisch - traversals\ntags attribute\ntemporale attribute\ndyn sprachen besser geeignet \n
- #22: \n
- #23: \n
- #24: \n
- #25: messy world\nfast changing world\nbez um graph sind teil der daten\nim rdbms teil des starren schemas\nkomplexe zusammenhaenge\nkomplexe fragen\nimmer neue kategorien - rels\ndynamisch - traversals\ntags attribute\ntemporale attribute\ndyn sprachen besser geeignet \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: BASE (Brewer 1997)\nBasically Available\nSoft State\nEventual Consistent\n
- #47: \n
- #48: \n
- #49: \n
- #50: \n
- #51: \n
- #52: \n
- #53: Most of the emerging database technologies are concerned with scaling to huge amounts of data and massive load.\nThey do so by making data opaque and distribute elements based on key.\n
- #54: Use the right shape of database for the right kind of object\n
- #55: \n
- #56: \n
- #57: \n
- #58: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #59: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #60: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #61: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #62: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #63: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #64: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #65: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #66: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #67: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #68: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #69: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #70: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #71: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #72: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #73: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #74: nodes\nrelationships between nodes\nrelationships have types and directions\nrelationships are traversed equally fast in each direction, direction may be significant or not\nnodes have properties\nrelationships have properties\n
- #75: \n
- #76: \n
- #77: \n
- #78: \n
- #79: \n
- #80: \n
- #81: \n
- #82: \n
- #83: \n
- #84: \n
- #85: \n
- #86: \n
- #87: \n
- #88: \n
- #89: \n
- #90: \n
- #91: \n
- #92: \n
- #93: \n
- #94: \n
- #95: \n
- #96: \n
- #97: \n
- #98: \n
- #99: \n
- #100: \n
- #101: \n
- #102: \n
- #103: \n
- #104: \n
- #105: \n
- #106: \n
- #107: \n
- #108: \n
- #109: \n
- #110: \n
- #111: \n
- #112: \n
- #113: \n
- #114: \n
- #115: \n
- #116: Disk-based\nNative graph storage engine with custom binary on-disk format\nTransactional\nJTA/JTS, XA, 2PC, Tx recovery, deadlock detection, MVCC, etc\n\n
- #117: \n
- #118: \n
- #119: \n
- #120: \n
- #121: \n
- #122: \n
- #123: \n
- #124: \n
- #125: \n