Do I understand correctly that multi model mean you can create relational dbs, documents dbs, key value pairs etc in Arrango?
If yes, I wonder why someone would need a multi model db, do you have any examples?
If yes, I wonder why someone would need a multi model db, do you have any examples?
You can then scale this across multiple machines as necessary. The benefit of such a design is that your team only needs to learn on technology not many. You don’t need to know redis, postgres and Neo4j to derive the same benefits.
A graph DB is optimised for a traversing a general graph structure, whereas a document DB is optimised for a tree-structured document and sometimes queries can't traverse links between documents.
Optimised means performance, layout in storage (so locality, retrival and join patterns), the kinds of query operators that are offered, and even that the language they use is more suited to different ways of modelling data.
Effectively you can market a graphDB as a document DB, the reverse isn’t true. What am I missing
Of course you can implement a documentDB on top of a graphDB, or market the latter as the former. And of course there are applications running on a documentDB that would be as fast or faster on a graphDB.
The differences are one of "impedance mismatch" rather than insurmountable differences.
For example, if you query all vertices with a property x=foo, then query all properties of the vertices, and then traverse all tree-child like properties to more vertices, and continue doing this recursively, that query will be like getting all documents with x=foo. But that's more complicated to express in a graphDB QL than a documentDB QL, and likely to run slower on the graphDB (due to data non-locality) if there are many properties or much tree depth.
In general a documentDB stores all the data for a document clustered together without being told to, and likes to retrieve them as a unit. Because that structure is clear, applications tend to be designed around it as an assumption.