I'm thinking of experimenting with Neo4j to re-implement some of the things we're currently doing in PostgreSQL, mainly as an exercise for my own skills development. But just in case it actually turns out to be a useful approach, I'm curious as to how many people out there are using Neo4j for real applications?
I know MongoDB is quite widely used now (for a NoSQL DB at least), partly thanks to MongoDB's smart promotion via free online classes, but you don't hear much about Neo4j being used so widely. Any of you JavaRanchers got any experience using Neo4j?
This is also an area I would like to experiment with and gain some commercial experience in. Sadly, I have not been given the opportunity yet but some of my fellow colleagues are actively using MongoDB, not Neo4j. A gap in the market here in the South West perhaps!
chris webster wrote:Any of you JavaRanchers got any experience using Neo4j?
I used it in one component in one of my customer projects.
Reason for using it was not performance - atleast not intentionally - but to simply reduce the
volume of code that would otherwise have to written and tested if using plain RDBMS SQL queries.
The component modelling involved users and groups. A user could become members of multiple groups.
Each group could have multiple child groups, and each child group could have its own child groups, and so on.
Users could could become members at multiple levels in the group hierarchy.
Membership in a subgroup implied membership in the parent group.
Certain use cases involved providing some shared resources at every group level to all users who were members in that group.
Implementing such membership querying using SQL in mysql looked like a pain. Mysql did not (probably still does not)
have recursive queries, and even if it did, it probably would have to be coded as SQL procedures.
Even worse, I was using hibernate for DB operations - a framework which I'm not exactly a fan of.
Performance optimization hacks post testing seemed inevitable with this approach.
Neo4j seemed like the right tool for the job, because the above model is a graph (each group and user is a node, and presence of an edge is membership).
Wrote some prototypes and realized the API was exceedingly simple to use. Documentation (API and user manuals) were good.
The source code was also rather educative on graph algorithms, none of which I was familiar with at the time.
Response times of membership queries even with deep nesting levels was excellent.
All in all, that component, which had all the makings of a month long pain in the neck, became a breeze to implement within a couple of days, thanks to neo4j.
However, I didn't get any experience about its scalability, replication or high availability aspects; the project didn't require them.
I'm glad I used it. If I run into the same kind of situation in future involving groups, users, and recursive memberships
(RBAC authorization strategy is one common enterprise use case I can think of), neo4j is something I'll definitely look at.
Karthik: Thanks for your detailed account of your experience - sounds very encouraging. I'm thinking of trying Neo4j to replace a RDBMS implementation that requires us to navigate lots of joins between tables in order to provide the views of the data that the users actually want. We could solve some of these problems with denormalisation, but that creates different problems with maintenance. However, I think this data and the required views of it could be modelled quite easily as a graph, so Neo4j seems like an interesting alternative. Just need to find time to do the actual work!
I feel I should be able to set up a basic relationship between nodes (whether undirected, one-way or two-way) without having to define anything in code first. Is that an unrealistic expectation? Or do I just need to look at some other graph DB besides neo4j?
chris webster wrote:Karthik: Thanks for your detailed account of your experience. I'm thinking of trying Neo4j to replace a RDBMS implementation
You're welcome. While browsing through that code yesterday, I remembered another design decision I took. Although all these indirect relationship queries were primarily
handled by neo4j, I still treated the RDBMS as the System of Record and stored direct membership relationships in the mysql database too. The reason was I was under
time constraints and did not have much time to look into secondary aspects of data storage like backup and restore. I wanted a familiar way to recreate
atleast the direct memberships in case of some disaster; once the direct memberships were known, it wasn't difficult to recreate the neo4j graph from them.
It's very likely neo4j has its own support for backup and restore, and you might want to look into that.
Another aspect is transactions - neo4j has support for them and also some integration support for JTA and spring transaction management.
So if already using a spring stack and looking to use both RDBMS and neo4j with transactions, using spring-data-neo4j might be a good solution.
ulf dittmer wrote:In order to use neo4j, I have to define relationships beforehand via Java Enums?