Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jepsen: Dgraph 1.1.1

jepsen.io

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Jepsen: Dgraph 1.1.1

#31

Post by aphyr »

wpietri wrote: post #5

There's a part I don't get here: "To store large datasets Dgraph shards the set of triples by attribute, breaks attributes into one or more tablets, and assigns each tablet to a group of nodes." But earlier, it says, "For convenience, Dgraph can also represent all triples associated with a given entity as a JSON object mapping attributes to values—where values are other entities, that entity’s attributes and values a…

The first sentence is describing how Dgraph shards data for storage; the second sentence discusses how data can be represented in the query API. You're right that this could lead to broad fanout, if users typically retrieved all attributes for a given UID. It also impacts the performance of joins: graph traversal across a single attribute is much faster when all those edges are on the same node, but graph traversal across different attributes might pay a higher latency cost. This is a classic dilemma in distributed graph storage--does one shard by attribute? By entity? Each leads to distinct performance tradeoffs, and Dgraph happened to choose attribute sharding.

Also keep in mind that typical Dgraph workloads request specific attributes (think "SELECT NAME, AGE") rather than everything ("SELECT *"), which reduces the impact of fanout. :)

Re: Jepsen: Dgraph 1.1.1

#32

Post by mrjn »

mavbo wrote: post #24
mrjn wrote: post #11

Hey folks, author of Dgraph here. If you're interested in the design details of Dgraph, and have the appetite for a very technical research paper, please check this out: https://dgraph.io/paper I'd like to thank Kyle in doing another round of testing. Some of these bugs that we fixed (in 2018 and 2019) were very tricky edge cases -- it's incredible to see Dgraph running so much more stable now, under all varied failu…

I've been using Dgraph in building some PoCs and it's been great. My current confusion is around the push for a plain GraphQL compliant query endpoint as I'm not sure what the intended purpose is. Presumably it's not for direct connections between a front-end web client and the DB using something like Apollo Client. Should front ends still be going through some sort of API server that ingests GraphQL or REST style re…

The latest version of Dgraph 20.03.1 contains GraphQL endpoint. We're releasing few more features very soon, which would add object level auth, ability to trigger custom logic, call remote GraphQL endpoints to execute part of the query, and so on. So, you could put Dgraph directly in front of a frontend, without worry.

Dgraph can also be called via Apollo Gateway, as part of their federation.

We also have other very interesting stuff in the pipeline, which would cater a lot to front end development as well as backend. So, stay tuned.

Re: Jepsen: Dgraph 1.1.1

#33

Post by mrjn »

nick238 wrote: post #20
mrjn wrote: post #11

Hey folks, author of Dgraph here. If you're interested in the design details of Dgraph, and have the appetite for a very technical research paper, please check this out: https://dgraph.io/paper I'd like to thank Kyle in doing another round of testing. Some of these bugs that we fixed (in 2018 and 2019) were very tricky edge cases -- it's incredible to see Dgraph running so much more stable now, under all varied failu…

Does Dgraph work in geo-distributed applications? It's great to be "distributed" and all, but if your cluster is in one data center and it loses connection, you're hosed. I'd assume for something using Raft (and whatever other custom protocol you're also using) there must be a way to configure election timeouts, but I can't find any docs on it.

Depends upon how far apart are the servers. It is on our roadmap to experiment with Dgraph servers as part of one cluster across US based datacenters. Once we establish that, we can try it out across US / Europe, etc.

We use 100ms heartbeats, with 20x that for election timeouts, in line with Etcd. Don't think that's exposed to the end user -- nobody has needed to tweak that.

Re: Jepsen: Dgraph 1.1.1

#34

Post by mrjn »

wiradikusuma wrote: post #26

I've been using Dgraph for over a year (on/off, it's a side project). I first saw Dgraph on HN. I thought Dgraph was going to be the "secret sauce" for my app after reading the list of features (maybe I was mesmerized by the cute mascot). Few months down the line, though, sometimes I question my decision and whether I should have used the good old PgSQL. Let me explain. 1. Coming from SQL and key-value NoSQL, Dgraph…

Hmm... That's probably not the testimonial I was hoping to get from a Dgraph user.

Though, I can see part of your pain is because of the custom query language, GraphQL+-. We now offer standard official GraphQL compliance as well, which tackles a lot of these issues you ran into.

1 and 2. GraphQL is becoming very common, so plenty of resources.

3. GraphQL has many amazing editors.

4. GraphQL allows for lack of referential integrity by setting certain fields in the object as non-nullable, which can remove those objects from the results and so on -- which is frankly, the thesis we have around a distributed graph database, sharded by predicates (not nodes).

5. arrr... sad.

6. GraphQL has many client libraries and so on.

Hope we could change your opinion by switching you to standard GraphQL -- particularly, if you don't need the advanced features provided by plus-minus.

Re: Jepsen: Dgraph 1.1.1

#35

Post by mrjn »

mro_name wrote: post #22
mrjn wrote: post #11

Hey folks, author of Dgraph here. If you're interested in the design details of Dgraph, and have the appetite for a very technical research paper, please check this out: https://dgraph.io/paper I'd like to thank Kyle in doing another round of testing. Some of these bugs that we fixed (in 2018 and 2019) were very tricky edge cases -- it's incredible to see Dgraph running so much more stable now, under all varied failu…

Hi, was nosing around your website and find it very much appealing. Am currently for hire, rooted in germany. Whom should I contact? Thx! Am author of https://github.com/mro/librdf.sqlite

We are looking for a Community Engineer:

https://discuss.dgraph.io/t/hiring-community-engineer-to-sta...

Re: Jepsen: Dgraph 1.1.1

#36

Post by mrjn »

cube2222 wrote: post #19

Haven't used DGraph itself but I've used the storage engine they built for it - Badger, an alternative to RocksDB better optimized for SSD's - in two projects. One was for event saving and retrieval, which was able to sustain a stable 60k writes /s with simultaneous 10k reads /s. It worked great overall, with stuff needing nontrivial tuning being 1. RAM usage 2. If you overwhelm it with writes it'll stall to keep up…

Love it! You should send a PR to add OctoSQL to the list of projects using Badger (GitHub README).

Re: Jepsen: Dgraph 1.1.1

#37

Post by mrjn »

kwesthaus wrote: post #21
enzotar wrote: post #3

Can anyone share their production experience with Dgraph?

Wasn't at a huge scale but for one project another intern and I took a proof of concept that another engineer had done with Gremlin [1] and turned it into a full tool and ended up using dgraph. The python bindings were easy to work with and Ratel (the UI/web frontend) made quick searches and tests easy. I liked working with it so now I'm the package maintainer for it on AUR [2]. At some point I'd like to make a repo…

Thanks for maintaining Dgraph on AUR. I'm a fan of Arch Linux.

I think the latest release is 20.03.1, perhaps time to update?

Re: Jepsen: Dgraph 1.1.1

#38

Post by anonymousDan »

aphyr wrote: post #30
anonymousDan wrote: post #27

Does Jepsen ever open source any of their tooling/test harnesses? I teach a distributed systems class and it would be great to have an automated test framework/tools for Distributed systems issues

Yes: the library is prominently linked on the home page, and there are deep links to the Dgraph test suite code throughout the report. Pretty much all of my work is OSS, and public release of test harness for each report is explicitly part of the Jepsen ethics policy. :) https://github.com/jepsen-io https://jepsen.io/ https://jepsen.io/ethics

Awesome! Quick question - how much of the test harness you use for each report is generic/reusable, and how much is system specific? I have my students implement various algorithms/systems in Elixir e.g. Raft/Paxos, various broadcast algs etc. It would be nice to have something both they and I could use to simulate network partitions etc.

Re: Jepsen: Dgraph 1.1.1

#39

Post by mrjn »

aphyr wrote: post #31
wpietri wrote: post #5

There's a part I don't get here: "To store large datasets Dgraph shards the set of triples by attribute, breaks attributes into one or more tablets, and assigns each tablet to a group of nodes." But earlier, it says, "For convenience, Dgraph can also represent all triples associated with a given entity as a JSON object mapping attributes to values—where values are other entities, that entity’s attributes and values a…

The first sentence is describing how Dgraph shards data for storage; the second sentence discusses how data can be represented in the query API. You're right that this could lead to broad fanout, if users typically retrieved all attributes for a given UID. It also impacts the performance of joins: graph traversal across a single attribute is much faster when all those edges are on the same node, but graph traversal a…

> graph traversal across different attributes might pay a higher latency cost

Those can be done concurrently if at the same query level, so not necessarily any slower. In other terms, the number of network calls required (in a sufficiently distributed cluster, where each predicate/attribute is on a different server), is proportional to the number of attributes asked for in the query, not the number of results (at any step in graph traversal).

And that's the big part of the design. By constraining the number of network calls to very few machines, while doing traversals, which would lead to millions of results in the intermediate steps -- Dgraph can deal with high fan-out queries (with lots of node results) much better.

Alternative would be to shard by nodes (entities) -- in which case, if the intermediate steps have millions of results, they could end up broadcasting to the entire cluster to execute a single query. That'd kill latency.

So, the problem is not how many attributes a query is asking for -- that's generally bounded. The problem is how many nodes you end up with as you traverse the graph, those could be in millions.

That's why many graph layer systems suck at doing anything deeper than 1 or 2 level traversals / joins.

Re: Jepsen: Dgraph 1.1.1

#40

Post by throwaway595 »

wiradikusuma wrote: post #26

I've been using Dgraph for over a year (on/off, it's a side project). I first saw Dgraph on HN. I thought Dgraph was going to be the "secret sauce" for my app after reading the list of features (maybe I was mesmerized by the cute mascot). Few months down the line, though, sometimes I question my decision and whether I should have used the good old PgSQL. Let me explain. 1. Coming from SQL and key-value NoSQL, Dgraph…

You might consider using cayley [1] instead. If you find it easier to drop and recreate the database from scratch, then you have a source-of-record (to recreate the database from) and so it might make sense to treat your graph database as the place for doing graph analytics rather than as the place for storing the source-of-record data AND doing graph analytics.

Thinking of the graph database as a graphics programmer might think of the GPU might be a helpful perspective.

[1] https://cayley.io/ [2] https://oss.redislabs.com/redisgraph/

EDIT: I love dgraph, and reevaluate it anew frequently. However, I've shipped cayley and this approach works. Continue down-voting this throwaway account though.

Post reply on HN