Graph DBs vs. Document DBs vs. Triplestores

Question

This is a somewhat abstract and general question. I\'m interested in the inherent (as well as implementation-specific) properties of different approaches to persist unstruct

Answer 1

There is an ad hoc standard for graph databases - Tinkerpop, including the Gremlin (imperative) query language, supported by about everything other than ArangoDB.

To muddy the waters further there are also hybrid document-graph databases OrientDB and ArangoDB.

It strikes me that a major difference between storing a child relationship using an edge in a graph database versus as an embedded object in a document database is that with the former the child can be moved to another parent cheaply and without risk of having it appear in two places with two different places.

Answer 2

Just a small correction to amk answer: Tinkerpop also contains an adaptor for ArangoDB, see https://github.com/triAGENS/blueprints-arangodb-graph/wiki/Gremlin. So you can use Gremlin queries with ArangoDB.

In general, multi-model databases like ArangoDB or OrientDB allow you to use all the nice features of document databases (schema-free, indexes) together with graph structures. A vertex or an edge is simply a document as in a document database. You can have as many properties or even embedded documents as you like. You can define hash, range, fulltext, or geo indexes on these documents. Or you can forget about the document structure and view your documents as vertices and edges, using Gremlin or some traversal language to investige the underlying graph.

As for the question "are we doomed with polyglot persistence": Independent of the document / graph database question, I belive that RDBMS will be around a little while longer. So, the answer to that question is: "yes, that is very likely".

Answer 3

I'm not sure I would agree with the sentiment that a lot of people don't like SPARQL. SPARQL 1.0 did have some short comings, but it quite nicely addressed what it was designed for, and the new iteration, SPARQL 1.1, builds upon it adding many constructs from SQL that people expected to see in the original spec including sub-queries, aggregates & update semantics. I think the fact that it's standard and you can expect to see the same parsing & semantics in every triple store, as opposed to dialects of SQL, is a nice feature.

I would also claim that all triple stores are graph databases; you can put properties on specific edges in RDF, albeit not as nicely as you can w/ Neo4j. But triple stores have the advantage of a real query language, a w3c standard data representation which makes it trivial to take your data to another triplestore, and for a number of triple stores, the ability to perform reasoning based on OWL.

I dont know anything about the scalability for most graph db's, but generally, the commercial RDF databases scale quite well. All can scale into the billions of triples, which handles a great many use cases. Though how they handle scale differs wildly from vendor to vendor wrt to scale up or scale out, clustering, etc. You'll also see pretty different mem & hardware requirements to match the implementations for each. For me, I've tended to just go and grab an EC2 instance, usually a 2XL or 4XL, mount an EBS large enough to hold the data, and I'm pretty well set.

Additionally, some triple stores integrate with Lucene or similar technologies to provide inverted indexes over the data, and many now are starting to include geo-spatial and temporal indexes. These are very useful features that I'm not sure of their availability in something like Neo4j.

With that said, they're not going to scale as well as a relational databases, they're just not as mature. But you're also not going to get screwed when you have "real" amounts of data either. Of course, one of the advantages of triples stores is reasoning, which performing at scale is tricky, but that's much of the reason why the various OWL profiles were created. But you can paint yourself into a corner if you don't think ahead.

I think graph databases, triple stores specifically, can be a pretty good match for a lot of applications that are being built, but I dont think that means that everything should be done with them. Like anything else, they're tools w/ their good points and their bad points, so you kind of have to make the right choice based on your application. But they probably always merit at least a consideration these days.