Property Graphs and Document Databases

[Stefán]

Hi,

I'm fairly new to the NoSQL space but I have been trying, for the past
few months, to select solutions for a stack being assembled for fairly
big project. I have used Terracotta in the pasta (and loved it) and
after having researched some higher profiled alternatives the
Terrastore project caught my attention.

I would like some feedback from this group regarding an idea involving
a document store and a graph database serving as en elaborate index
and "traversal engine".

Graph database, like Neo4j, obviously handle relations and graph
traversals extremely well because of the embedded indexes (amongst
other things) but the ability to attach unlimited number of properties
to vertices and edges does, in my opinion, not make a property graph a
document store superset as sometimes claimed.

As much of the traversal performance is achieved by keeping the whole
graph in memory. A major shortcoming, for me, is that this includes
all properties regardless of whether or not they are relevant for
traversals/filtering or not.

The solution I have been looking for is a document store with some
hypergraph tendencies and is able to maintain directed document links
which are loaded, a long with the selected document properties and
link properties, into a graph engine which provides it's services much
in the same way as elasticsearch/lucene provides indexing/search.
Keeping a light weight (just-enough) graph+properties in memory and
storing the full nodes (vertices/documents) in a document store sounds
like an interesting addition for traversal based querying rather than
"just" the text based search already in place.

Is this something that you have considered, unrealistic or something
simply to silly to ponder? :o)

Regards,
-Stefan Baxter

[Sergio Bossa]

Hi Stefan,

welcome to the group.

I never tried by myself to bridge document databases with graph ones,
but let me see if I understand your approach: you want to keep a
"limited version" of your graph on a single graph database, using it
only for traversals, and retrieve the whole information from another
distributed store ... is that right?

Well, if so, the idea is pretty nice and I think could be easily
implemented by hacking a little bit by the graph database side, but I
have two big concern:
1) You're still not scalable, because you still have one graph index.
2) You now have two different databases, and you have to keep them in
sync despite of failures.

BTW, keep us posted :)
Cheers,

Sergio B.

--
Sergio Bossa
http://www.linkedin.com/in/sergiob

[Alex Miller]

Have you considered using a semantic web triple store?