36 ms·
Dgraph is aimed at minimizing network calls. In fact, the network calls are directly proportional to the complexity of the query, not the number of results. Whi
by mrjn 10y ago
Dgraph is aimed at minimizing network calls. In fact, the network calls are directly proportional to the complexity of the query, not the number of results. Which means the queries would maintain their latency even as you add more machines to the cluster.
https://github.com/dgraph-io/dgraph/blob/master/present/sydney5mins/g.slide https://github.com/dgraph-io/dgraph/blob/master/present/sydn...
- nl 10y agoRight, but unless you know the queries in advance there is always the risk of pathological queries that thrash the network. Naive example: in the movie dataset, if you partition by node type and have actors on one server and films on another a query like "find me all films with actors names starting with M who also starred in films with actors starting with N" will perform horribly, but if you partition by actor and film name it will be OK. Titan (and I think most distributed Graph DBs) use pluggable distribution strategies and default to random to try to combat this problem.