Sunday, June 22, 2014

Graph Database Observations

I have been ramping up (maybe a little late to the dance?) on graph database technologies, specifically Neo4j and Titan.

I really like modeling for graph databases.  It is much more intuitive and direct in terms of moving toward a solution.  I can see where graph dbs fit into the Agile development methodology really well (about time something fit into Agile well).
Even as a novice, data modeling for a graph database feels intuitive, fast and fun!

I have seen some promise in Talend Big Data Integration tool in migrating data into Neo4j.  I think that is a HUGE plus!  Way to go Talend!!

However what I do see, at least initially, is a large amount of coding to migrate data from database to a graph database.  Maybe this is a good thing?  Graph dbs seem to shrink the design time, document in an intuitive manner and require more time for developers to code the solution.  For years I have felt strongly that too much time is wasted designing and documenting solutions and not enough time is spent actually coding them.  Graph databases seem to tip the scale in favor of the developer with regard to this dynamic.
Graph databases seem to reduce design and documentation durations and give that time back to the developer!

Here are five things I have learned so far that are worth passing on:

  1. Nodes = vertices = records (in the relational world)

  2. Relationships = edges = constraints (in the relational world)

  3. Nodes/Vertices = records = you will have a lot of nodes/vertices (learn how to create 'em, you'll need it)

  4. Nodes/Vertices have properties which hold values (kind of like table attributes)

  5. Relationship/edges have direction and properties allowing for the developer to program the strength of the relationship and make the relationship bi or uni directional


I mentioned modeling for graph databases so I will share my first graph model.  This model is just a draft and a high level depiction of a customer centric solution.  However I feel it is a good example of how intuitive they are to read, develop from and iterate through.  This only took about 15 minutes to work out.

[caption id="attachment_3491" align="aligncenter" width="747"]high level graph model of a customer centric solution high level graph model of a customer centric solution[/caption]

That's it for now.  I'll be adding to this topic as I develop more graph skills!

Helpful links

http://nosql.mypopescu.com/post/10162152437/what-is-a-graph-database#about-blog

http://thinkaurelius.github.io/titan/

https://github.com/thinkaurelius/titan/wiki/Getting-Started

http://www.neo4j.org/

http://www.neo4j.org/learn

2 comments:

What data quality is (and what it is not)

Like the radar system pictured above, data quality is a sentinel; a detection system put in place to warn of threats to valuable assets. ...