Right now there's no monitoring in place for dgraph.xyz and it went down a few hours ago. We don't have alerts set up so were not notified that the servers were down.

Need to set up something like a heartbeat monitor at a minimum and alerts to notify the right people.

As mentioned in #3 , To go ahead with establishing the performance evaluation,comparison of Dgraph with the rest of the Graph databases in the list we need a way to drive Dgraph from a Java client. And yes, Dgraph anyway needs utilities to be driven from host languages and definitely Java is on the list. Please create a timeline/milestone/label and assignment.

We want to build a very basic Java client driver similar to Go client we have right now. It would communicate with the server over gRPC and can run queries and mutations.

Mutations via GraphQL which I introduced recently, won't work the same way as our bulk loader does. Because these mutations would need to go over the network; while our bulk loader, even in distributed state, does not. The general idea to do mutations is as follows:

Step 1: Network calls to assign Uids for all Xids.

Step 2: Distributed based on predicates, and multiple network calls to reach all corresponding servers. One RPC each server to load up the edges.

Step 3: Wait for success. If success, return or run the query part of GraphQL.
In case of failure, return to client; and let them retry. Later, we can add a retry loop here. Note that without transactions, some of these would have been applied; without any particular way to revert their changes (potential overwrites over data before this change was made). *

• The transactional behaviour would fall under distributed transactions, which we don't intend to support at least until v1.0. So, for now, we'll have this issue where a failure would result in some unapplied RDFs -- in general, until distributed transactions, we don't provide atomicity over multiple RDFs. Each RDF is applied atomically; and independently from others.

Need to create Makefile for setting up dependencies and easy build of Dgraph. If it sounds good please assign it to me and give appropriate label.

Write a blog post, and announce on Reddit.

We should support modifying data via the common GraphQL query endpoint.

https://facebook.github.io/graphql/#sec-Language.Query-Document.Operations

GraphiQL allows for in-browser interactive style querying and inspection of results (and other associated features). Investigate what it takes to make sure GraphiQL is supported out of the box with DGraph.

Have a Go driver for DGraph, which would allow us to avoid the JSON conversion step.

Test DGraph v0.2 thoroughly, with Go 1.5.3.

Hello , can't you remove that dependencies of rocksDB ? you can use BoltDB or TSL from InfluxDB. just a suggestion.

curl localhost:8082/query -XPOST -d $'query {me(_xid_: manish) {_xid_ type.object.name.en fav.director {_xid_ type.object.name.en film.director.film {_xid_}}}' | pytho^C-m json.tool | less

Doesn't return _xid_ for film.director.film over the 3 node cluster set up for film data.

https://github.com/google/cayley seems like an alternative to this project. Would be interesting to document the differences.

We want to build a very basic Python client driver similar to the Go client we have right now. It would communicate with the server over gRPC and can run queries and mutations.

https://github.com/facebook/rocksdb/wiki/RocksDB-Basics#readonly-mode

Read Only mode provides better performance; and that's exactly what we do during the second phase of the loader. So, allow UID RocksDB to be opened read only.
https://github.com/dgraph-io/dgraph/blob/master/server/loader/main.go#L79

The current RocksDB library that we use doesn't support this operation. So, consider switching to https://github.com/tecbot/gorocksdb

Commit Logs require monotonically increasing timestamps. Currently, if the clock moves back in time, the logs would cause a log FATAL. We should instead just wait to let the timestamp increase above the last valid ts; instead of crashing.

For clustering to be achieved automatically, a discovery mechanism needs to be implemented. Multicast-based discovery mechanisms are always prefered because it requires zero-configuration, but since most, if not all cloud providers block multicast traffic I propose the adoption of a gossip protocol like the one implemented by Serf.

By doing so, there's only one requirement in order to form a cluster, at least one node must exist and it must be reachable by any new nodes. Every new node (member) does a full state sync with the existing member and begins gossiping its existence to the cluster.

Gossip allows to keep an eventually-consistent view of the cluster at any given node.

Thoughts?

We need a RocksDB expert to have a look at how we're doing things, and recommend the right read/write options.

Need relative performance measure for Heap and Query method for Rock's DB merge by @ashwin95r . I'm on it tonight. As @manishrjain had suggested in gitter I'll start with a very simple test and stop there if performance difference is evident. Since its the battle of time complexities and run time measurements sometimes the difference would be evident only on working with large datasets/nodes so that the other factors get abstracted and the run time can be truly judged to be dependent on the core operation under scrutiny. Mark assignment/label

Would require parsing GraphQL appropriately and an additional field in query.SubGraph.

We need a tool to query our data in RocksDB. It should support a single key lookup, parsing the value and iterating over the Posting List showing all the relevant data. The key []byte should be constructed using these flags:
--xid
--uid
--attribute

If only an attribute is provided, it should do a range scan. Also allow --limit and --count; which are both useful for range scan. --limit N would limit the number of results to N; and count would count the number of results, without showing you the results.

The C++ code for rocksdb merge using the heaps has to be written in Go

Something like Travis CI, Wercker or equivalent.

This is the most popular page on discuss:
https://discuss.dgraph.io/t/differences-between-dgraph-and-cayley/23

This is also the most popular question on Reddit:
https://www.reddit.com/comments/4fs7qm/why_we_built_dgraph/

And again:
https://www.reddit.com/r/golang/comments/3uyj8m/announcing_alpha_release_of_open_source/

And again on HN:
https://news.ycombinator.com/item?id=11322444

So, it's about time we do a real benchmark. @ashwin95r has written some code to benchmark Dgraph for his final year thesis. So, he will be the coordinator for this project.

We can reuse that code to throw similar queries at Cayley and see how it compares.

I have RDF in turtle that I converted to nquads (which it seems is what you load). I passes validation with rapper and I use rapper to convert the RDF to nquads with no issues. I compressed it and used the following commands with the resulting output.

Any suggestions on load the data is welcome. If you are interested the RDF (turtle format) is at http://opencoredata.org/rdf/JRSO_cruises_gl.ttl

root@4333ee8f86cd:/data2load# uidassigner --numInstances 1 --instanceIdx 0 --rdfgzips /data2load/JRSO_cruises_gl.nq.gz  --uids /dgraph/uids/u0 
INFO[0000] Empty size: [16] EmptyPosting size: [24]      package=posting
INFO[0000] Set max procs to num  cpus                    num_cpus=1 package=uidassigner_main prev_maxprocs=1
INFO[0000] Only XIDs with FP(xid)%numInstance == instanceIdx will be given UID  instanceIdx=0 numInstances=1 package=uidassigner_main
INFO[0000] Handling...                                   package=uidassigner_main path=/data2load/JRSO_cruises_gl.nq.gz
INFO[0001] Counters                                      ignored=0 len_cnq=0 package=loader parsed=6499 pending=513 processed=5986 read=16500
INFO[0002] Counters                                      ignored=0 len_cnq=0 package=loader parsed=17429 pending=2114 processed=15315 read=25248
INFO[0003] Counters                                      ignored=0 len_cnq=0 package=loader parsed=27503 pending=2305 processed=25198 read=35090
INFO[0004] Counters                                      ignored=0 len_cnq=0 package=loader parsed=32965 pending=821 processed=32144 read=42965
INFO[0005] Counters                                      ignored=0 len_cnq=0 package=loader parsed=43215 pending=1219 processed=41996 read=51902
INFO[0005] List Merge counters                           added=0 clean=0 dirtysize=23725 mapsize=33695 merged=1667 package=posting pending=0
INFO[0006] Counters                                      ignored=0 len_cnq=0 package=loader parsed=46312 pending=674 processed=45638 read=56313
INFO[0007] Counters                                      ignored=0 len_cnq=0 package=loader parsed=56353 pending=643 processed=55710 read=66354
INFO[0008] Counters                                      ignored=0 len_cnq=0 package=loader parsed=66550 pending=1789 processed=64761 read=74655
INFO[0009] Counters                                      ignored=0 len_cnq=0 package=loader parsed=68989 pending=2187 processed=66802 read=78990
INFO[0010] Counters                                      ignored=0 len_cnq=0 package=loader parsed=73945 pending=1696 processed=72249 read=82137
INFO[0011] Counters                                      ignored=0 len_cnq=0 package=loader parsed=81007 pending=2212 processed=78795 read=91007
INFO[0012] List Merge counters                           added=0 clean=0 dirtysize=38415 mapsize=55278 merged=2576 package=posting pending=0
INFO[0012] Counters                                      ignored=0 len_cnq=0 package=loader parsed=84296 pending=709 processed=83587 read=93525
INFO[0013] Counters                                      ignored=0 len_cnq=0 package=loader parsed=91678 pending=4 processed=91674 read=101679
INFO[0014] Counters                                      ignored=0 len_cnq=0 package=loader parsed=95628 pending=509 processed=95119 read=105628
INFO[0015] Counters                                      ignored=0 len_cnq=0 package=loader parsed=104226 pending=108 processed=104118 read=114226
INFO[0016] Counters                                      ignored=0 len_cnq=0 package=loader parsed=112717 pending=50 processed=112667 read=122718
INFO[0017] Counters                                      ignored=0 len_cnq=0 package=loader parsed=118931 pending=2586 processed=116345 read=126305
INFO[0017] List Merge counters                           added=0 clean=0 dirtysize=54026 mapsize=77485 merged=3421 package=posting pending=0
INFO[0018] Counters                                      ignored=0 len_cnq=0 package=loader parsed=122992 pending=747 processed=122245 read=132992
INFO[0019] Counters                                      ignored=0 len_cnq=0 package=loader parsed=134489 pending=2214 processed=132275 read=142163
INFO[0020] Counters                                      ignored=0 len_cnq=0 package=loader parsed=134489 pending=261 processed=134228 read=144490
INFO[0021] Counters                                      ignored=0 len_cnq=0 package=loader parsed=145755 pending=1667 processed=144088 read=153874
INFO[0023] Counters                                      ignored=0 len_cnq=0 package=loader parsed=145756 pending=730 processed=145026 read=155756
INFO[0023] Counters                                      ignored=0 len_cnq=0 package=loader parsed=146940 pending=8 processed=146932 read=156940
INFO[0024] List Merge counters                           added=0 clean=0 dirtysize=70563 mapsize=100503 merged=4411 package=posting pending=0
INFO[0024] Counters                                      ignored=0 len_cnq=0 package=loader parsed=157803 pending=1969 processed=155834 read=165731
INFO[0025] Counters                                      ignored=0 len_cnq=0 package=loader parsed=157804 pending=1909 processed=155895 read=166481
INFO[0026] Counters                                      ignored=0 len_cnq=0 package=loader parsed=164957 pending=1691 processed=163266 read=173106
INFO[0027] Counters                                      ignored=0 len_cnq=0 package=loader parsed=168458 pending=309 processed=168149 read=178458
INFO[0028] Counters                                      ignored=0 len_cnq=0 package=loader parsed=172417 pending=1030 processed=171387 read=182418
INFO[0028] List Merge counters                           added=0 clean=0 dirtysize=77108 mapsize=113038 merged=5059 package=posting pending=0
INFO[0030] Counters                                      ignored=0 len_cnq=0 package=loader parsed=184142 pending=2564 processed=181578 read=194142
INFO[0031] Counters                                      ignored=0 len_cnq=0 package=loader parsed=196048 pending=1727 processed=194321 read=204201
INFO[0032] Counters                                      ignored=0 len_cnq=0 package=loader parsed=196049 pending=1520 processed=194529 read=205049
INFO[0033] List Merge counters                           added=0 clean=0 dirtysize=86317 mapsize=128648 merged=5729 package=posting pending=0
INFO[0033] Counters                                      ignored=0 len_cnq=0 package=loader parsed=203218 pending=1423 processed=201795 read=205049
FATA[0033] While handling rdf reader.                    error=No Object in NQuad package=uidassigner_main
root@4333ee8f86cd:/data2load# 

Both loader and query processor would need to support distribution.

Loader
Depending on number of servers, loader would only store edges corresponding to fingerprint(attribute) % N on each server.

Query Processor
Query processor would use the same formula to find the right server holding the attribute required, and appropriate send the query portion to that server, and consolidate results.

Track which attributes each server is serving, and add ability to move them around.

This would be done via a global RAFT group, so each server knows the location of all attributes.

Following the instructions to pull and start the docker image (docker pull dgraph/dgraph:latest). Once inside I get:

root@8881830c7daf:/go# mkdir /dgraph/m
root@8881830c7daf:/go# server --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u
Illegal instruction

Mac OS X 10.11.4

bash-3.2$ docker version
Client:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:49:29 UTC 2015
OS/Arch: darwin/amd64

Server:
Version: 1.8.1
API version: 1.20
Go version: go1.4.2
Git commit: d12ea79
Built: Thu Aug 13 02:49:29 UTC 2015
OS/Arch: linux/amd64

Neo4J is the most popular Graph database. It would be great to see how DGraph performs against it.

Update: We published the results via a blog post here: https://open.dgraph.io/post/benchmark-neo4j/

GraphQL Fragments

http://swat.cse.lehigh.edu/projects/lubm/

Sending a mutation via GRPC client causes panic because mutations are not processed. See: https://github.com/dgraph-io/dgraph/blob/master/server/main.go#L224

anic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x59e428]

goroutine 27 [running]:
panic(0x9453e0, 0xc82000e120)
    /usr/local/go/src/runtime/panic.go:464 +0x3e6
github.com/dgraph-io/dgraph/query.ToSubGraph(0x0, 0x160, 0x0, 0x0)
    /home/dan/work/src/github.com/dgraph-io/dgraph/query/query.go:393 +0x28
main.(*server).Query(0xef6970, 0x7f338ca05828, 0xc8201144e0, 0xc820116210, 0xd, 0x0, 0x0)
    /home/dan/work/src/github.com/dgraph-io/dgraph/server/main.go:230 +0x53b
github.com/dgraph-io/dgraph/query/graph._DGraph_Query_Handler(0x91eaa0, 0xef6970, 0x7f338ca05828, 0xc8201144e0, 0xc820110680, 0x0, 0x0, 0x0, 0x0)
    /home/dan/work/src/github.com/dgraph-io/dgraph/query/graph/graphresponse.pb.go:129 +0x132
github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc820126c80, 0x7f338ca4a7c0, 0xc8200fc000, 0xc820132460, 0xc8201194c0, 0xeb8810, 0xc820114390, 0x0, 0x0)
    /home/dan/work/src/github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc/server.go:497 +0xe13
github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc.(*Server).handleStream(0xc820126c80, 0x7f338ca4a7c0, 0xc8200fc000, 0xc820132460, 0xc820114390)
    /home/dan/work/src/github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc/server.go:646 +0x109d
github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc82000e450, 0xc820126c80, 0x7f338ca4a7c0, 0xc8200fc000, 0xc820132460)
    /home/dan/work/src/github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc/server.go:323 +0xa0
created by github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
    /home/dan/work/src/github.com/dgraph-io/dgraph/vendor/google.golang.org/grpc/server.go:324 +0x9a

I fixed this issue in my much diverged govendor->aws branch by adapting these lines from the http endpoint. However, I'm not sure if this was left out for a reason/implications

Ran into connections getting timed out with the server today after the HN post went up:

ATA[901074] dial tcp :12345: getsockopt: connection timed out call=Worker.ServeTask package=worker
INFO[901075] Sample value attr=root package=query val=
INFO[901075] ProcessTaskOverNetwork attr=film.director.film instanceIdx=1 numInstances=3 package=wor
ker runHere=false
FATA[901075] connection is shut down call=Worker.ServeTask package=worker
INFO[901075] Sample value attr=root package=query val=
INFO[901075] ProcessTaskOverNetwork attr=film.director.film instanceIdx=0 numInstances=3 package=wor
ker runHere=false
FATA[901075] connection is shut down call=Worker.ServeTask package=worker
Log Fatal due to connection timeout issue.

My idea is to enable everyone to use DGraph, to make DGraph as a default choice of database for application developers to build their mobile/web applications. One of the very significant steps needed to get there is to make setting up of Dgraph super simple and really easy, It should be made so simple that anyone can now, for the first time in history, should be able to have a GraphDB up running and ready to use in less than a minute.

In this regard here my propsal for the Install section of the Readme.md. That needs DGraph to offer binary releases ( One of advantages of DGraph being build in Go, need not ask users to install complicated libraries, just a binary would suffice! ).

Install and run DGraph

• GNU/Linux 64 bit.

  • Download the binary from https://downlaod.dgraph.com/server/release/v1/linux-64/dgaph .

    $ chmod +x dgraph
    
    $ ./dgraph --mutations ~/dgraph/m --postings ~/dgraph/p --uids ~/dgraph/u ` 
    

  (Note: Explore dgraph --help for more options)

• OSX 64 bit.

  • Download the binary from https://downlaod.dgraph.com/server/release/v1/linux-64/dgaph .

  $ chmod +x dgraph
  
  $ ./dgraph --mutations ~/dgraph/m --postings ~/dgraph/p --uids ~/dgraph/u ` 
  

• Docker

$ docker pull dgraph/dgraph:latest
# Setting a somedir volume on the host will persist your data.
$ docker run -t -i -v /somedir:/dgraph -p 80:8080 dgraph/dgraph:latest
# Ensure mutations directory exists.
$ mkdir /dgraph/m
# Run the server
$ dgraph --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u

• From Source

NOTE: Source installation is intended for only developers and advanced users. For general use, please download official releases from https://download.dgraph.io/

If you do not have a working Golang environment, please follow [Install Golang]([Go 1.6 from here]%28https://golang.org/dl/%29.).

$ go get -d github.com/dgraph-io/dgraph
#Make file takes care of installing RocksDB dependency too. 
$ make
$ $GOPATH/bin/dgraph --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u

When calculating how much memory is being used by our program using Go's runtime module, we don't take into account memory used by RocksDB (being called via cgo). So, check if there's a way to get the memory usage by RocksDB, and add it to the memory usage reported by Go. This should be more accurate and hopefully fix the discrepancy that we see now.

We need a code review system which can highlight all the golint, go vet, and other issues. Given the high noise ratio, we want to show these to the reviewer and the author of the change, so they can make a decision about which ones to fix. Not all these issues are relevant, so we don't want to block the changelist just because golint complains.

So far I think Phabricator seems to have such a mechanism. We should also look into Gerrit. Once decided, we should set up one. Suggestions on other code review systems which can allow for above customization are welcome!

We need a code review system which can highlight all the golint, go vet, and other issues. Given the high noise ratio, we want to show these to the reviewer and the author of the change, so they can make a decision about which ones to fix. Not all these issues are relevant, so we don't want to block the changelist just because golint complains.

So far I think Phabricator seems to have such a mechanism. We should also look into Gerrit. Once decided, we should set up one. Suggestions on other code review systems which can allow for above customization are welcome!

We want to build a very basic C++ client driver similar to the Go client we have right now. It would communicate with the server over gRPC and can run queries and mutations.

Does it?

Greeting all,

I have recently found dgraph and it looks perfect for the project that I am working on at the moment so I started to investigate it usage on my Ubuntu 15.04 system.

I was going through the single-instance docker setup and ran into a problem:

Single instance via Docker

There's a docker image that you can readily use for playing with DGraph.

$ docker pull dgraph/dgraph:latest

Setting a somedir volume on the host will persist your data.

$ docker run -t -i -v /somedir:/dgraph -p 80:8080 dgraph/dgraph:latest

Now that you're within the Docker instance, you can start the server.

$ mkdir /dgraph/m # Ensure mutations directory exists.
$ dgraph --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u

I was able to create and start up the docker image as I made the "somedir" to be /data that I created. It all started up and then inside the docker image I am at:

root@3577df598657:/go#

The catch is the last line above

$ dgraph --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u

in that

root@3577df598657:/go# dgraph --mutations /dgraph/m --postings /dgraph/p --uids /dgraph/u
bash: dgraph: command not found

I am assuming that the docker setup compiled dgraph with golang and also set the path directory, but I am not sure why it does not start?

I want to continue down your installation and testing path so that I can complete the testing of the single instance and then move on to the multiple instances on a single machine followed by installing dgraph docker images on different physical servers as well.

I also want to set up the github "website" repository so that I can replicate your

https://dgraph.io/

on a local host to do more testing towards my project.

Can you please let me know what is happening with the dgraph command not found problem as it seems that golang has not compiled the code to create it?

Thanks,
Lonnie

Every 5 seconds, gentlyMerge outputs a log. Largely with the same information. Only output the log, if something changes, hence reducing the amount of noise.

go version
go version go1.4.3 linux/amd64

loader --postings /dgraph/p --rdfgzips /data/rdf-films.gz, /data/names.gz --stw_ram_mb 7000
loader --postings /dgraph/p --rdfgzips /data/rdf-films.gz, /data/names.gz --stw_ram_mb 7000
INFO[0000] Empty size: [16] EmptyPosting size: [24] package=posting
INFO[0000] Set max procs to num cpus num_cpu=4 package=loader_main prev_maxprocs=1
INFO[0000] Handling... package=loader_main path=/data/rdf-films.gz

3 merged=2732887 package=posting pending=13836
INFO[0451] List Merge counters added=2746995 clean=3865 dirtysize=0 mapsize=1625 merged=2741105 package=posting pending=5890
INFO[0452] Merged lists. Calling GC. package=posting
INFO[0456] Trying to free OS memory package=posting
INFO[0459] Memory Usage after calling GC. allocated_MB=1486 package=posting
INFO[0460] Counters ignored=0 len_cnq=9971 package=loader parsed=1065104 pending=12971 processed=1052133 read=1075108
runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort
PC=0x7efdfe2a8107

goroutine 0 [idle]:

goroutine 1 [chan receive, 7 minutes]:
github.com/dgraph-io/dgraph/loader.HandleRdfReader(0x7efdfef4b0f8, 0xc20805a000, 0x1, 0x7efdfef4b0f8, 0x0, 0x0)
/go/src/github.com/dgraph-io/dgraph/loader/loader.go:179 +0x2d3
main.main()
/go/src/github.com/dgraph-io/dgraph/server/loader/main.go:88 +0xd2c

goroutine 17 [syscall, 7 minutes, locked to thread]:
runtime.goexit()
/usr/src/go/src/runtime/asm_amd64.s:2232 +0x1
goroutine 1812945 [chan receive]:
github.com/dgraph-io/dgraph/posting.(*counters).periodicLog(0xc2a68c0bc0)
/go/src/github.com/dgraph-io/dgraph/posting/lists.go:45 +0x68
created by github.com/dgraph-io/dgraph/posting.MergeLists
/go/src/github.com/dgraph-io/dgraph/posting/lists.go:245 +0x1ef

rax 0x0
rbx 0x7f7607fa8708
rcx 0x7f7607c39107
rdx 0x6
rdi 0x1f6
rsi 0x1f7
rbp 0x642d12
rsp 0x7f7606986798
r8 0xa
r9 0x7f7606987700
r10 0x8
r11 0x206
r12 0x7f75fc033990
r13 0x7f7608919060
r14 0x0
r15 0x7f7606987700
rip 0x7f7607c39107
rflags 0x206
cs 0x33
fs 0x0
gs 0x0

• Low Latency
• High Throughput
• RDF Parsing
• Rocks DB Badger DB for persistence
• Commit Logs (Replaced by RAFT logs)
• Query Language - GraphQL-like
  • Query
  • Root Arguments
  • Fields
  • Response in JSON
  • Field Arguments
  • Field Alias
  • Mutations #23 [v0.2]
  • Fragments #8
  • Variables
  • Type System
    • Scalar Types
    • Object Types
  • Mutation validation for scalar types
  • String matching / Name search
  • Sort by attribute
  • Limit number of results #9
  • Filter
    • anyof
    • allof
    • eq (equal)
    • inequality (>=, <=, >, <)
  • Aggregate Functions
    • count
    • sum
    • max
    • min
  • Geospatial Queries
    • Nearby
    • Within
    • Contains
    • Intersects
• Official Clients
  • Javascript
  • Go [v0.3]
  • Java
• Distributed Transactions
• Distributed #14 [v0.2]
  • Distributed Loader [v0.2]
  • Distributed Server [v0.2]
• Clustering
  • Node discovery and membership via Dgraph Zero
• High Availability
  • Raft
  • Automatic Data Replication
  • Automatic Failover for reads
  • Read linearizability
• Resilience
  • Shard moves to handle server failure
• Export
• Backup

After v1.0 / Proprietary Plugins

• Multi-homing support
• Cypher Support
• Access Control Lists
• Query Graphical User Interface
• User authentication
• Cluster Management
• SPARQL [maybe]
• Tinkerpop Support [maybe]
• Distributed transactions [maybe]

Need a common account to allow the DGraph core team to access the servers. Right now only @manishrjain has access.

And benchmark the performance difference against the current implementation using pure Go. If Ragel performs better, we'd want to switch over sooner, before we build more features on top of existing code.

johncai:/Users/johncai/go/src/github.com/dgraph-io/dgraph/server (master)
$ ./server --instanceIdx 0 --mutations $DIR/m0 --port 8080 --postings
$DIR/p0 --workers ":12345,:12346,:12347" --uids $DIR/uasync.final
--workerport ":12345"
INFO[0000] Empty size: [16] EmptyPosting size: [24] package=posting
INFO[0000] Set max procs to num cpus num_cpu=8
package=server prev_maxprocs=8
path: ../server/m0
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x4180928]

goroutine 1 [running]:
panic(0x45433c0, 0xc820012110)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
github.com/dgraph-io/dgraph/commit.(*Logger).handleFile(0xc8200aaa00,
0x7fff5fbff565, 0xc, 0x0, 0x0, 0x554cf90, 0xc82018d9e0, 0x0, 0x0)
/Users/johncai/go/src/
github.com/dgraph-io/dgraph/commit/log.go:249 +0x148

github.com/dgraph-io/dgraph/commit.(_Logger).(github.com/dgraph-io/dgraph/commit.handleFile)-fm(0x7fff5fbff565,
0xc, 0x0, 0x0, 0x554cf90, 0xc82018d9e0, 0x0, 0x0)
/Users/johncai/go/src/
github.com/dgraph-io/dgraph/commit/log.go:315 +0x74
path/filepath.Walk(0x7fff5fbff565, 0xc, 0xc820135c70, 0x0, 0x0)
/usr/local/go/src/path/filepath/path.go:394 +0xa5
github.com/dgraph-io/dgraph/commit.(_Logger).Init(0xc8200aaa00)
/Users/johncai/go/src/
github.com/dgraph-io/dgraph/commit/log.go:315 +0x92b
main.main()
/Users/johncai/go/src/
github.com/dgraph-io/dgraph/server/main.go:318 +0x5ba

$DIR/m0 was a non-existent directory when this happened

Write a Golang json parser and formatter tool. Should be pretty simple 20 lines of code.