Some advice to dgraph

  1. Long term version

I have used dgraph for more than half a year, it’s great!But it also exposes too many problems, especially when upgrading to a new version.

I think may be dgraph can mark and matain some version as long term version which means it works well with basic function like bulkload/liveload/online mutation/online query etc. That would help those who want to try dgraph or use it in proc env.

I have spend too mucn time to struggle with the problems of dgraph and sometimes it makes me upset.

And In my test, v1.1.1/v1.2.3/v20.03.1 is relatively stable, may be this can help someone to dicide which version to choose.

2.All in one version

For those who want to try dgraph, deploy is still too complex. May be dgraph can ref jadger which supplys a all-in-one release, what you need is just download and run.

Especially, for those data scientist, sometimes what they need is just a graph database which can import/query/visualize data, performance / scalability / distributed is not so important as easy-using. That’s why so many people choose neo4j while the easy-using of cyper and neo4j data browser is something other matters.

3 Likes

Hey @JimWen,

Thanks for making these points. I might not have the full context here, perhaps @dmai or @MichelDiz has?

But, for us to understand better, could you elaborate a bit more on the problems you encountered?

We have a standalone Docker image, which can make running Dgraph easier. Which part of deployment is complex?

1 Like

You don’t have to do this unless you want to solve a problem/bug that has recently been fixed.

As a continuation of the previous sentence, today Dgraph has a new versioning policy which leads to a “long term support” policy. See this blog post

The other issues from your text would be nice to have more context.

Cheers.

1 Like

Even our new versioning policy does not say anything about long term support. This is what we say in our blog post:

We will support the release series for one year and security patches for 18 months.

2 Likes

Sorry to learn this lately, i have just read this blog post just now, that’s a really good news.

As i know, not everyone know how to or want to run a docker image.

For me, running bare metal is much simpler than relying on Docker or k8s(for the ones who don’t like containers, and don’t want to depend on having to learn them). In practice, you only need 2 instances/nodes (Alpha and Zero). If you need multiple instances, there is no problem right after learning the basics, you can handle it.

Can you share a little bit of the context that you claim to be complex to deal with? I mean your setup with Dgraph. How do you run it(bare metal?)? and how do you consume it?

About all-in-one, Dgraph needs this pattern of Alphas and Zeros to work in a distributed way. I don’t know if Jaeger has this since it is a passive model, where just receives data to display traces.

Perhaps we could provide a small script for different OS as an example. Do not know.

For engineer it’s definitely easy to deploy zero and alpha, what i mean is those data scientist or people not so familiar with distributed knowledge.
Any way, just an advice from my perspective, may be not right.

1 Like

Got it.

I personally believe that they are a good audience for Dgraph - I think that today our audience is among devs who work in modern web applications (and who use GraphQL, scientists don’t use GraphQL for now, I think).

Dgraph has the potential for big data and even replacing Triple Store in my opinion. Scientists and academics uses Triple Store way more than other types of DBs - Due to its benefits and it was created with web semantics and open data in mind.

Scientists and academics are welcome, but first, we have to have more of them with us to understand their needs. They need to get involved.

Thanks.