7

I'm considering a setup where I have entities stored both in a document db (e.g. CouchDB) and a graph db (e.g. Neo4j). The rationale is storing each entity information (data, blobs, values, complex internal structure) in the document db while storing the entity relations (parents, children, associated entities) in the graph db.

Has anyone done / seen / been bitten by a setup like this? What kind of issues should I expect? First thing that come to mindaka the 2-phase commit. But backups are problematic too here.

Ran Biron
  • 6,317
  • 5
  • 37
  • 67

2 Answers2

4

You may check out the book "Seven DBs in Seven Weeks". 8th chapter talks about building up a polyglot structure via CouchDB, Neo4j and Redis.

VolkanT
  • 574
  • 5
  • 10
0

Ran,

Since CouchDB and most (all?) of the document/ kv stores do not support transactions, you would need to stop worrying about 2-phase-commits. You can do XA transactions between Neo4j and MySQL for example, but not CouchDB or it's relatives.

Indeed, for simplicity's sake, why not a pure graph database architecture? You get the better expressiveness and transactions - what is the rationale of adding another moving part in the form of a second store type?

lassewesth
  • 219
  • 1
  • 2
  • 3
    in case you got some really big context (e.g. building graph of websites with its' content, too) for each node, i think the double setup with a document db is rational. – ulkas Aug 30 '12 at 09:53
  • Unless the content is blobs of videos and images, there'd be no problem keeping it all in the graph. – akollegger Aug 30 '12 at 12:25
  • 3
    @Andreas - ah - but I do have blobs. But more important - I have lots and lots of unstructured attributes on each node - and I want to run reports and batch processes on the entities. Graph database would slow me down considerably and will impose capacity restrictions I don't want to deal with. – Ran Biron Aug 30 '12 at 18:51
  • 1
    @Ran I see. Agreed that what matters is the questions you want to ask of the data. You could look at cross-store persistence with some like Spring Data to save the right bits to the right buckets. – akollegger Aug 31 '12 at 19:11
  • arangodb ( https://github.com/triAGENS/ArangoDB ) seems to combine document and graph database features – poseid Nov 18 '12 at 14:39