Hacker News Reader

Comment by ignoramous | Hacker News Reader

Wikidata did a comprehensive analysis of Graph DBs [0], and settled on BlazeGraph with TitanDB coming a close second.

Notably, there are quite a few omissions. DGraph and Cayley [1] being two of those. Interestingly, both are developed by Googlers. Cayley is used by Kythe.io [2], a Google project that kind of competes with srclib [3] by SourceGraph.

Cayley has native JavaScript interface, which makes it an interesting choice for Node JS based apps.

At work, we settled on TitanDB, primarily because it supports DynamoDB/Cassandra for storage and ElasticSearch. Most of the graph DBs rely on some storage engine or the other underneath-- Cayley supports LevelDB, for instance; whereas TitanDB supports BerkeleyDB apart from aforementioned DyanmoDB and Cassandra.

[0] https://docs.google.com/a/wikimedia.org/spreadsheets/d/1MXik...

[1] https://github.com/google/cayley

[2] https://kythe.io

[3] https://srclib.org

View on HN

Both Cayley and TitanDB aren't native graph databases. In fact, Cayley supports many storage engines, including MongoDB etc. This is because both are graph layers, and the data maintenance is done via the real database underneath. This has benefits in the sense that it's easier to build, but also doesn't perform as well when it comes to query latency.

DGraph, OTOH, is a native graph database. We do use RocksDB, but the data distribution and maintenance is done by us. It's optimized for decreasing the number of network calls, to keep them linear to the complexity of the query, not the number of results. This is of incredible value when you're running real time queries, serving results directly to end user. The query latency hence, isn't too affected by high fan out of intermediate results and should remain low; while providing high throughput.

In fact, the entire HN traffic is being served by one GCE n1-standard-4 instance right now, using all 4 cores really well :-).

Also see: https://github.com/dgraph-io/dgraph/wiki/Differences-between...

For me the demo doesn't work, CORS violation while trying to access http://dgraph.xyz/query. (EDIT: manually accessing it sends me in a cloudflare(?) captcha, that might mess with the query?)

hmm.. we have the CORS allowed, so this shouldn't be the issue. It's possibly the cloudflare captcha issue.

Cloudflare does that when you are hitting it from a suspicious VPN IP address. There may be other reasons why it doesn't like your IP.

Thanks.

I have questions, I'd be glad if you could answer them:

1. DGraph v0.2 isn't production ready?

2. DGraph API doc is missing?

3a. Does DGraph support bulk loading of RDFs only? No support for graphSON?

3b. Does DGraph support incremental loading of a Graph? Or just bulk loads?

4. Is 'distribution' achieved by maintaining a copy of entire Graph data across all instances? Or is data distributed too?

5. What's with the UID generation? Is to establish a partioning scheme?

1. I wouldn't term anything up until 1.0 as production ready. 2. API doc? Basically, there's only one endpoint, called /query. All the queries just go through that. There's a wiki page with some test queries to get you started.

3a. Yes, with the 2 phase loader. Only RDFs are supported right now, nothing else. https://github.com/dgraph-io/dgraph#distributed-bulk-data-lo...

3b. Yes, with mutations. https://github.com/dgraph-io/dgraph#queries-and-mutations

4. It's truly distributed. The data is actually sharded, with each shard containing part of the data and served by a separate instance. The bulk loader instructions generate 3 instances.

5. To keep the queries, data storage and data transfer efficient, we assign a uint64 ID to all entities. UID assignment is that operation.

I take that it's a self-funded project? Good luck, and I hope you hit production sooner. You've got any roadmaps for us to keep track of?

A few Qs abt the storage layer:

DGraph supports replication too, in case a node fails...?

Given your description, I take that you've implemented a custom data distribution protocol on top of rocksdb? Do you have plans to extract this 'distributed rocksdb' out to its own implementation? How would something like this compare to actordb.com and/or rqlite?

Thx again.

We have funding now, would be made public soon. So, we have enough to keep us going for a bit, and focus solely on the engineering challenges.

DGraph would support high availability, which means all our shards would be replicated 3x across servers, so in case one server fails, the shards would still be available for querying and mutations. In addition, shard movements to other servers would happen so the replication factor remains the same. We aim to achieve this using (Etcd's) RAFT protocol, by version 0.4.

RocksDB is just a medium for us to have something between the database and disk. All the data arrangement, handling, movement etc. happens above RocksDB. So, no there's no "distributed rocksdb" here.

http://thinkaurelius.com/2013/11/01/a-letter-regarding-nativ...

Re Wikidata, it's worth noting that they discarded TitanDB because it was assumed dead after the Datastax acquisition of Aurelius, which turned out not to be the case after all.

Also, the choice of BlazeGraph whiffed of politics. Wikidata (or at least one of the primary developers) seems to have been courted by the BlazeGraph people, to the point where Wikidata prematurely abandoned their research spreadsheet. This was at a time when there was hardly any public info/documentation about BlazeGraph, and its pedigree seemed completely unknown/untested.

The roadmap for Titan is unclear to say the least. No communication, then a release drops, then nothing again. Hmm.

I agree with your point about the Wikidata decision process. Some links about this if anyone is interested: https://news.ycombinator.com/item?id=11201943

BlazeGraph seems like a reasonable product (now). But I don't like seeing this "Wikidata evaluated products and chose Blazegraph" thing - they started an evaluation process.

AFAICT, Titan is effectively dead, being replaced by Datastax Graph. Likewise, Blazegraph is about graph computation (think Spark's GraphX, OLAP) rather than simple reads/writes (OLTP). Systems can try to straddle both, but the benchmarks should be different.

Quickly looking at this project suggests it's on the OLTP side, not OLAP, so apples/oranges. Claiming more performance than a GPU compute engine would need some real benchmarking ;-)

Blazegraph is about graph computation (think Spark's GraphX, OLAP)

This is definitely incorrect. Wikidata uses it exclusively for read/write queries.

The (GPU accelerated) graph processing in BlazeGraph is new, and it's pretty unclear to me if it actually does the (GraphX) style processing. The examples[1] are all query-based.

It does look interesting though!

[1] https://www.blazegraph.com/product/gpu-accelerated/

Blazegraph has multiple backends. Their GPU compute engine vs. their classic DB engine are different ones. And yes, I doubt they use the same approach as GraphX, considering they've published how they don't (MapGraph) and GPUs require way more work. Lumping all these systems together doesn't make sense: reads aren't writes, and there's a whole world of graph computations. Benchmarks matter.

That said, I'd be skeptical of a GPU system for being great at writes, and I'd be skeptical of a non-GPU one computing better than one on GPUs.

There's quite a lot of activity on http://github.com/thinkaurelius/titan for a dead project. Admittedly, the issues are piling up, but the code seems to be actively worked on.

Hi, I'm one of the creators of Sourcegraph and srclib. Just wanted to clarify that srclib doesn't compete with Kythe. They tackle different issues and we're even considering using Kythe as a low-level language library.

Reply on news.ycombinator.com