Gremlin with mongodb

[Deepak Das]

Can anyone say how to work with  gremlin and mongodb.I have to represent the data in mongodb interms of graph..Can anyone help me out

[Stephen Mallette]

Davy Suvee built a mongodb implementation of Blueprints:

https://github.com/datablend/blueprints-mongodb-graph

it's based on Blueprints 2.3.0, so you might need to fork it and try to bring it up to 2.5.0 if you want to use the latest.  That said, I think that work was mostly an experiment more than something meant for production.  I think you will find the implementation slow compared to the more readily used implementations like Titan, Neo4j, OrientDB, etc.

On Mon, Mar 2, 2015 at 4:14 AM, Deepak Das <deepak...@gmail.com> wrote:

Can anyone say how to work with  gremlin and mongodb.I have to represent the data in mongodb interms of graph..Can anyone help me out

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/cdfba598-56e2-4e44-9101-d71edb3c12ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Schumacher]

This will obviously increase complexity and infrastructure requirements, but in an application that we built, we actually took a hybrid approach. 

1. Store documents in MongoDB, as is.

2. In our app, transform the documents into appropriate nodes and edges, and persist those in Titan (we used Cassandra+ES).  

A great benefit of this is that if you want to change your graph's ontology, you can just iterate over the documents in Mongo, replaying the (new) transforms to fit the new ontology. 

We ended up keeping a reference to the original Mongo ObjectID as a property on every node and edge, so that we could retrieve the documents from Mongo when needed. 

Another option is also to just store the data in the graph only, IF your documents otherwise map 1-1 to nodes and edges. In most (all?) of the graph db's I've seen you can attach arbitrary properties to vertices and edges (In Titan, even hashmaps, if you want to do sub-documents -- just be careful if you need to do any "update" operations on these). 

[Daniel Quest]

Having worked on Mongo quite a bit, I can confirm that the advice from Kevin here is quite sound.  In general the two technologies complement each other.  We tend to use Mongo on apps where the data is denormalized and we want a fast cache for search.  Graphs are great for data analytics and algorithms.  I tend to prefer graphs when the use cases are not as well defined because they are so flexible.  Mongo really suffers when you try to change the document structure and you have a bunch of code pointing to the old structure... Painful.  

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/05d0d267-1612-4ec1-ac68-a5c7eb6a7877%40googlegroups.com.