Releasing v0.4

Thanks for your feedback over the last couple of months. This release addresses some of the main pain points of using Dgraph .

Installation

Dgraph uses RocksDB, which doesn’t have a native Go interface. To use RocksDB via Go, Cgo is required, which makes doing a simple go get installation of Dgraph hard. You first need to download, compile and install RocksDB, before installing Dgraph . While go get would still require more manual steps, starting this version only contributors to Dgraph would have to do that.

We have embedded RocksDB into Dgraph binary and generated binaries for both Linux and Mac. Now, most users can just choose one of these two options:

$ curl https://get.dgraph.io | bash

Or, download the latest release from Github. And extract the binaries to /usr/local/bin.

# For Linux
$ sudo tar -C /usr/local/bin -xzf dgraph-linux-amd64-VERSION.tar.gz

# For Mac
$ sudo tar -C /usr/local/bin -xzf dgraph-darwin-amd64-VERSION.tar.gz

That’s it! These simple steps give you everything that you need to install Dgraph .

Documentation

Dgraph is a small team of enthusiastic developers, who like to code more than they like to write docs. Even when the team writes documentation, it gets stale very quickly. Honestly, that’s not a story unique to us. It’s a common problem affecting many projects.

So, I thought why not solve it in a way where our documentation would never get stale. I looked around for inspiration and found these two documentations that maximized screen estate usage and were easy to follow. Each of these allowed search engines to easily index them while providing a lot of content per web page, which made doing a browser search easy.

• Arch Linux
• Gentoo Linux

I run Arch Linux on my desktop and laptop, and love it’s thorough up to date documentation. So, I couldn’t be more excited about building something similar for Dgraph .

So, after last 3 weeks of no-coding-only-documentation effort, presenting wiki.dgraph.io, the official source of Dgraph documentation.

Just like Arch and Gentoo, it’s using MediaWiki software, which most people use on a daily basis (Thanks, Wikipedia).

The main reason we chose wiki over other solutions is that it puts the power of editing right in the hands of the user. So if a user spots an error, they have everything they need to fix it. If the fix is more complicated, writing a note stating that this article or section is out of date is sufficient to get the team and more importantly, other users notified; so they can take appropriate action.

And Dgraph community welcomed the change! We already have contributions to wiki from community members on various pages. They keep us accountable and help maintain the quality of the documentation. So, check it out, and if you find any issues or need more clarity in some section, log in, and edit the page. It’s that simple.

Btw, if you installed Dgraph above, this is the page you’re looking for: https://wiki.dgraph.io/Beginners_Guide.

Clients

In v0.3, we released a Go client for Dgraph . Thanks to our enthusiastic community, we got contributions for other languages. Now we have client code for both Java and Python. Thanks @bitmalloc and @mohitranka!

In fact, Python client installation is as simple as:

$ pip install -U pydgraph

You can read more about how to install and use them here: https://wiki.dgraph.io/Clients.

Debugging

Why did this query take so long to run?

This question stumped us! We didn’t know why. logrus was useful only for general logging. It couldn’t pinpoint which log was from which query, and show which steps of execution took how long, during the life of the query.

The moment I realized that grpc.io is a ground-up rewrite of stubby, Google’s internal rpc system; I knew that we had to switch to it. Stubby could provide amazing debugging information about each request to the server, and something that’s very well translated to grpc.

So, after thorough effort, I was able to replace most of the logrus.Log statements to use context and trace.

Thanks to these, you can now easily debug live queries running on Dgraph . In fact, you can see all this in action on one of our demo Dgraph instance via /debug/requests.

2016/07/14 06:54:55.615143    0.003184    Query
06:54:55.615157     .    14    ... Query received: { me(_xid_: m.0bxtg) { type.object.name.en film.actor.film { film.performance.film { type.object.name.en type.object.name.ru } } } }
06:54:55.615295     .   138    ... Xid: m.0bxtg Uid: 14685953405111677952
06:54:55.615312     .    17    ... Query parsed
06:54:55.615323     .    11    ... Sample value for attr: _root_ Val:
06:54:55.617188     .    55    ... (18 events discarded)
06:54:55.617190     .     3    ... Reply from child. Index: 1 Attr: type.object.name.ru
06:54:55.617192     .     2    ... Reply from child. Index: 0 Attr: film.performance.film
06:54:55.617194     .     2    ... Reply from child. Index: 1 Attr: film.actor.film
06:54:55.617195     .     1    ... Graph processed
06:54:55.618252     .  1057    ... Latencies: Total: 3.102143ms Parsing: 163.283µs Process: 1.88333ms Json: 601.266µs

These live queries are further categorized by how long they took to run. So, you can easily identify slower queries.

2016/07/14 03:16:13.684030    0.100109    Query
03:16:13.684045     .    15    ... Query received: { me(_xid_: m.06pj8) { type.object.name.en film.director.film { type.object.name.en film.film.initial_release_date film.film.country film.film.starring { film.performance.actor { type.object.name.en } film.performance.character { type.object.name.en } } film.film.genre { type.object.name.en } } } }
03:16:13.684175     .   130    ... Xid: m.06pj8 Uid: 4255310415198890869
03:16:13.684193     .    17    ... Query parsed
03:16:13.684197     .     4    ... Sample value for attr: _root_ Val:
03:16:13.744452     .    41    ... (47 events discarded)
03:16:13.744458     .     5    ... Reply from child. Index: 1 Attr: film.performance.character
03:16:13.744466     .     8    ... Reply from child. Index: 4 Attr: film.film.genre
03:16:13.744477     .    11    ... Reply from child. Index: 1 Attr: film.director.film
03:16:13.744482     .     5    ... Graph processed
03:16:13.783501     . 39020    ... Latencies: Total: 99.461379ms Parsing: 156.916µs Process: 60.288205ms Json: 25.813948ms

Also, you can see latency (in microseconds) statistics over various time intervals.

Count: 20    Mean: 59979    StdDev: 37593    Median: 84261
[    2048,    4096)    4    20.000%    20.000%
[    4096,    8192)    2    10.000%    30.000%
[    65536,    131072)    14    70.000%    100.000%

This is the first time we have such data available, and we’ll tweak what gets reported over time to make these logs more and more useful.

Hope you like these features and try out the new release.