During the day Michael works for Neo Technology on the Neo4j graph database. He’s also the main caretaker of the Neo4j developer community. On top of that Michael is the project lead of Spring Data Neo4j, which he helped to develop from the idea into a convenient and complete solution for object graph mapping.
Below you can find the full recording of the session, so you can watch it yourself and form your own opinions. If you feel just a bit lazier than that, read this post first and then watch the session. It’ll make remembering things Michael talk about easier.
To start off, Michael talked about why people started using graph databases? Well, those in the ivory towers techies often come up with new things for no reason except that it can be done and it seems cool. But the industry cares about actual problems and often neglects technologies if they don’t offer real benefit. Databases are hardly a new thing exactly, and they come in all shapes and colors, just in the previous session Christopher Batey has talked about distributed databases and Cassandra. So what graphs can offer us, besides the ultimate versatility in describing any data?
Michael talked about his experience with several problems that typical relational databases suffer from. How do you convert your object model into a relational model, how you do the reverse conversion? What happens when you need to update your data schema? How to optimize complex queries, and so forth. All these questions are tough for any database to answer well.
A graph database doesn’t magically solve all these problems, but it does try to make some of them easier to handle. One such area, for example, is modelling hierarchical data, possibly with cycles or working with natural languages and synonyms.
In a nutshell, a graph database model consists of nodes that hold data connected by edges, called relationships in Neo4j. I bet you have an idea how to implement that just on a Java level, right? This model fits really well into the way Java objects interact. Well, Neo4j started from just that. Then they added a proper persistence solution with memory mapping, transactions and transaction logs for consistency. Additionally, they added Apache Lucene for faster entity lookups and things are looking pretty good.
If you include Cypher, a query language for Neo4j, that allows you to interact with the database and reap all the benefits from the graph data model, you get a pretty complete graph database solution.
The good thing is that Neo4j is an open-source project and can offer you the ACID transactional guarantees that you already know about and know how to explain to your manager. Naturally not every problem would benefit from a graph data model. But Michael has brought some examples that outline common use cases where companies use Neo4j, from fraud detection to network graphs to identity management to real-time recommendations.
Then Michael showed a short, but fantastically slick demo of Neo4j, Neo4j data browser and how the basic querying works. I won’t repeat all that here, watch the session it’s worth it. Or if you prefer reading text instead of watching video, we have a recent blogpost that explains the basic configuration of Neo4j stack, Cypher syntax details and how to run queries.
In a nutshell, if your data is more about relationships rather than values, you might need a graph database. If you agree with any of the points Michael mentioned about the relation databases, you should look to see if you can remodel your data as a graph.
- Data model in relational universe is built for forms not for joins
- Strict schema is not suitable for variable structured data
- Variable hierarchies and networks are really hard to store and query
- Denormalization is often a solution for performance, but it introduces other challenges
The best thing is that as a Java developer you already have all the tools you need to communicate with a Neo4j database. Even if you are not a fan of the Spring Data project, and won’t touch the Spring Data Neo4j, you can always use plain old JDBC drivers and run Cypher queries through that. Additionally, the Neo4j server has a REST API, so there’s every chance you’ll get the data you need with ease.
To conclude, graph databases offer a different model and a viewport into your data. You might see major benefits of using a graph database implementation like Neo4j. However, don’t hope that it will magically solve all your problems. Even during the sessions the IRC chat was hot with questions about Neo4J’s internal implementation: how exactly does it speed up the join queries, and so forth. Michael answered them after the session, so if you’re interested, be sure to check it out.
RebelLabs Interview with Michael Hunger
Right after the main session we had a chance to sit with Michael and ask him a couple of questions about life, the universe, databases, programming, Java and what it means to be a terrible software developer!
Michael talked to us a bit about the situation with Java’s Unsafe API and why so many projects tend to use the private interface despite the inevitable consequences. Neo4j, for one, uses it and isn’t looking forward to the changes in Java 9. However, during our chat Michael pointed out that Java community is a very blessed and rich one, so maybe we should be a little more humble about the open source projects that allow us to do so much for free. It’s a tricky situation, but everyone should judge for themselves.
If you leave your email in the form below, I’d be happy to send you an occasional email about what’s happening with RebelLabs, the best pieces of content we have and what’s happening in the world of Java in general.