Using MongoDB as our master database, should I use a separate graph database to implement relationships between entities?

Question

We're currently in the process of implementing a CRM-like solution internally for a professional firm. Due to the nature of the information stored, and the varying values and keys for the information we decided to use a document storage database, as it suited the purposes perfectly (In this case we chose MongoDB).

As part of this CRM solution we wish to store relationships and associations between entities, examples include storing conflicts of interest information, shareholders, trustees etc. Linking all these entities together in the most effective way we determined a central model of "relationship" was necessary. All relationships should have history information attached to them ( commencement and termination dates), as well as varying meta data; for example a shareholder relationship would also contain number of shares held.

As traditional RDBMS solutions didn't suit our former needs, using them in our current situation is not viable. What I'm trying to determine is whether using a graph database is more pertinent in our case, or if in fact just using mongo's built-in relational information is appropriate.

The relationship information is going to be used quite heavily throughout the system. An example of some of the informational queries we wish to perform are:

• Get all 'key contact' people of companies who are 'clients' of 'xyz limited'
• Get all other 'shareholders' of companies where 'john' is a shareholder
• Get all 'Key contact' people of entities who are 'clients' of 'abc limited' and are clients of 'trust us bank limited'

Given this "tree" structure of relationships, is using a graph database (such as Neo4j) more appropriate?

Answer 1

Mike,

you should be able to store your relationship data in the graph database. Its high performance on traversing big graphs comes from locality, i.e. you don't run queries globally but rather start a a set of nodes (which equal documents in your case, which are looked up by an index. you might even store start-node-ids for quick access in your mongo documents). From there you can traverse arbitrarily large paths in constant time (wrt data set size).

What are your other requirements (i.e. data set size, # of concurrent accesses etc, relationship/graph complexity).

Your queries are a really good fit for the graph database and easily expressable in its terms.

I'd suggest that you just grab a graphdb like neo4j and do a quick spike with your domain to verify the general feasibility and also find out additional questions you would like to have answered before investing in the second technology.

P.S. If you hadn't started yet, you could also have gone with a pure graphdb approach as graph databases are a superset of document databases. And you'd rather talk domain in your case anyway than just generic documents. (E.g. structr is a CMS built on top of Neo4j).