Hacker News Reader

Comment by electriclove | Hacker News Reader

The post states "Most other graph databases or layers are built as sidekicks."

What specifically falls into that? As someone new to the space, I'd like to understand if he is referring to things like Neo4j, ArangoDB, etc..

View on HN

Neo4j, at least as of about a year ago, was seriously lacking in constraints and guarantees to use it as a database of record. Performance-wise, it's fundamentally built to perform well at a small set of specific graph operations, while more normal DB operations or even doing graph things plus fairly ordinary data fetching with those graphs was, necessarily, anywhere from so-so to terrible, as far as performance. Looking at how N4j stores its data is enlightening. It's also a huge memory hog (Java, plus leaning hard on cached data in memory to keep performance tolerable due to the aforementioned trade-offs).

Didn't stop N4j's marketing folks from trying to sell it as suitable for basically any purpose. Gotta get that unicorn growth. Very early-MongoDB in that regard. "No, really, it's suitable for whatever you're doing—probably the best for it, in fact! Uh, what is it you're doing, again?"

That one, at least, is best suited to assisting some other, primary DB, for a certain narrow set of tasks.

Most graph databases are being used as secondary systems, often used as indexing for other databases, etc. We believe this is due to a lack of features or performance at scale.

Our goal at Dgraph is to be used as main storage similarly to how people use Postgres or Mongo.

Happy to ask Manish (the author of the post and CEO of Dgraph) for more details!

Congrats on the funding! I've been looking into Dgraph (and also played a bit with Badger), as well as other graph databases as a way to store chronographic event data, while enabling rich relationships between the observed artifacts belonging to each event. The problem is that the solutions I find seem an ugly hack compared to a relational solution. Can you point me to any specific Dgraph documentation or case studies for these kinds of workloads?

Let's chat! We're working on improving our docs specifically regarding the data modeling aspects.

If your use case is open source we could even use it as one of our case studies :)

francesc@dgraph.io

By chronological event data, you mean timeseries data? Dgraph can be used for storing that, though, it's not specifically designed to store data that "flat".

It should work conceptually. At least, for smaller datasets, it should be alright (gigabytes or something), but for bigger datasets (terabytes), I think a specific TS DB would make more sense.

However, you can take the aggregations from there and store that along with relationships into Dgraph. That'd be a perfect fit.

fyi - We built a product around a way to store chronographic data in a graph database, capable of handling any resource, relationship, property, and/or event detail you can throw at it. It's called IBM Agile Service Manager.

Take a look, feel free to reach out if you'd like to know more:

Update from our technical team on the latest version: https://www.linkedin.com/pulse/new-ibm-asm-v115-some-paralle...

Black Friday with IBM Agile Service Manager (video from our technical team): https://www.youtube.com/watch?v=lJGVAJU6qp8

generally I think of GraphDbs as being fast read, slow write - does Dgraph has this issue? This is actually why I don't think of graph dbs as the source of truth db.

Dgraph's writes are actually very fast. The one-time bulk loader loads at millions of records per second. With recent optimizations [1], the live loader can load 21M records in 5 mins without indices and 20 mins with tons of indices. Note that all live data load also does WAL, consensus and disk syncs before every write call finishes to ensure crash-resilience.

[1]: https://github.com/dgraph-io/dgraph/commit/d697ca0898f0ac951...

Reply on news.ycombinator.com