Using both db and document db graphs

I am considering a setup where I have entities stored both in a db document (e.g. CouchDB) and in a db graphic (e.g. Neo4j). The rationale is to store each entity information (data, drops, values, complex internal structure) in the db document while maintaining the entity relationships (parents, children, associated objects) in the db column.

Has anyone done / seen / been bitten by a setting like this? What problems should I expect? The first thing that comes to mindaka is 2-phase fixation. But backups here are also problematic.

+4
source share
2 answers

You can check out the Seven Databases book in seven weeks . Chapter 8 talks about creating a polygon structure through CouchDB, Neo4j, and Redis.

+3
source

Ran

Since CouchDB and most (all?) Document / kv repositories do not support transactions, you need to stop worrying about two-phase commits. For example, you can make XA transactions between Neo4j and MySQL, but not CouchDB or its relatives.

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

0
source

All Articles