Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Graph Databases: Solving Problems with Connected Data

Graph Databases: Solving Problems with Connected Data

In this connected world, traditional data stores often make it difficult to find valuable relationships. Graph databases focus not only on the entities, but the connections between them. By making relationships a key component of the model, contextualizing a set of data becomes incredibly simple. Join us in this session to learn how graph databases are used to improve the data world and help developers easily make sense of connected data!

* Exploring graphs and how they provide data context
* How to transform our projects into graph structures
* Optimizing the model for our use case
* Accessing data through queries, analysis, visualization, applications, and more!

Jennifer Reif

August 16, 2022

More Decks by Jennifer Reif

Other Decks in Technology


  1. Who Am I? • Developer + Advocate • Continuous learner

    • Blogger • Speaker • Other: geek Jennifer Reif Email: [email protected] Twitter: @JMHReif LinkedIn: linked.com/in/jmhreif Github: github.com/JMHReif Website: jmhreif.com
  2. It’s all about data Everything is built on data •

    Businesses, industry, governments, economics, people • Our understanding of the world • Data is how we learn • Trial and error • Asking questions • Accumulated over time
  3. Domain-Driven Design (DDD) • Mutual understanding of domain, concepts •

    Iterations • Understanding data = better understanding of result • Better product, minimum functionality • Sanity check code
  4. Relational database • Pros: • Slices of data that can

    be easily assembled with queries • Handles data integrity and unique rows, low data duplication • Cons: • All relationships must be assembled with JOINs (with NF adherence) • JOINs are constructed from human knowledge Goal: Assemble data into meaningful sets
  5. NoSQL/Document database • Pros: • Can handle varied (unstructured) data

    more readily • Groups related info in a single place • Cons: • Designed to avoid JOINs and SQL • Makes aggregation operations cumbersome Goal: Group related info together
  6. Graph database Goal: Best of both worlds • Pros: •

    Relationships stored with related entities, no assembly required • Make JOIN operations easy, visual even • Cons: • Storing relationships requires some write operation overhead • Di ff erent mentality for modeling, querying, etc
  7. Have to pick just one? • Polyglot persistence: • Using

    multiple persistence strategies, each serving a di ff erent need • “Using the right tool for the job”
  8. Graph databases 2010 New tech arises from… • Solution need

    • Missing solution in the technology space • Looking for a “better way” to handle certain problems
  9. What Does It Solve? Product use case • Document path

    (not just data) • Answering how and why • Understanding connections • Find alternates, impacts, etc. • Produce better assumptions, decisions
  10. Misconceptions “Gotchas” • Database - physical storage of data •

    Not just analysis tool • Not just visualization • Can be “system of record” / “source of truth” db • Not just analytics workloads, transactional too • Not a silver bullet (like any technology) • There are things it does NOT do well
  11. Nodes Graph components • Represent objects or entities • Can

    be labeled • May have properties Order Product Employee orderId: 162468 total: $8320.48 productId: 08746589 name: “Ipoh Coffee” id: 247924 startDate: 2016-05-04 role: “Salesperson”
  12. Relationships Graph components • Must have a type • Must

    have a direction Order Product Employee orderId: 162468
  13. Relationships Graph components • Must have a type • Must

    have a direction • May have properties Order Product Employee orderId: 162468 commission: .02
  14. Relationships Graph components • Must have a type • Must

    have a direction • May have properties • Nodes can share multiple relationships Order Product Employee orderId: 162468
  15. Label Graph Components • A group of nodes • Like

    a category Person Employee Customer
  16. Property Graph components • Key-value pair • Associated with node

    or relationship • Like a variable name and value Order Employee orderId: 162468 id: 247924 SOLD total: $8320.48 date: 2022-08-16 commission: .02 startDate: 2016-05-04 role: “Salesperson”
  17. SQL vs Cypher SELECT o.OrderId, o.Total, o.Items, op.Quantity, op.Price, p.Name

    FROM Order o LEFT JOIN OrderedProduct op ON op.OrderId = o.OrderId LEFT JOIN Product p ON op.ProductId = p.ProductId; SQL Cypher MATCH (o:Order)-[r:CONTAINS]->(p:Product) RETURN o, r, p; Order Product OrderedProduct Order Product
  18. Cypher • Functional and visual • Based on ASCII-art •

    Declarative query language • Focuses on what to retrieve • Not how A B LIKES MATCH (A)-[:LIKES]->(B)
  19. Cypher: powerful and expressive Jennifer Neo4j WORKS_FOR CREATE (:Person {

    name: ‘Jennifer’}) -[:WORKS_FOR]-> (:Company { name: ‘Neo4j’}) NODE PROPERTY NODE PROPERTY LABEL LABEL
  20. Cypher in 20 seconds… • Nodes look like this: •

    (var:Label) OR (var:Label {propKey: propValue}) • Relationships look like this: • -[var:REL_TYPE]-> OR -[var:REL_TYPE {propKey: propValue}]-> • Using Cypher is looking for patterns of those nodes/rels: • (var1:Label)-[var2:REL_TYPE]->(var3:Label)
  21. Building applications • Drivers: lots of languages supported • Plugins/extensions/libraries:

    • APOC utilities • Graph Data Science • GraphQL • …and more! • Integrations/frameworks: • Spring, Micronaut, Quarkus • Kettle, Spark, PowerBI, JDBC, etc.
  22. Resources • Neo4j AuraDB Free: dev.neo4j.com/aura-java • Neo4j GraphAcademy: dev.neo4j.com/learn

    • Neo4j blog: dev.neo4j.com/blog • Neo4j YouTube: dev.neo4j.com/videos Jennifer Reif Email: [email protected] Twitter: @JMHReif LinkedIn: linked.com/in/jmhreif Github: github.com/JMHReif Website: jmhreif.com