3 ms·
You can't derive rate from latency alone. The query might be IO bound. If that's the case, you can run queries concurrently.
by perfmode 10y ago
You can't derive rate from latency alone. The query might be IO bound. If that's the case, you can run queries concurrently.
- jnordwick 10y agoI tend to care more about latency than throughput. FedEx has the best throughput in the world if you can wait a couple days. True though. I'm guessing with a latency number like that, the throughput is pretty bad too.
- ashwin95r 10y agoExactly what https://dgraph.io https://dgraph.io is built for. Low latency, high throughput.
- jnordwick 10y agoLooks interesting. That semi-declarative query language is hideous though. Reminds me of attempts to make XML into a programming language.
- mrjn 10y ago(author of Dgraph) It's based on GraphQL, which is definitely not a hack like XML => language and currently catching on faster than a forest fire. Dgraph's derivation, GraphQL+- (for lack of better name) is a lot more powerful than Cypher or Gremlin. Both of the latter allow only returning lists of results; while GraphQL+- returns back an entire subgraph. Thus, all the relationships are maintained. It also allows expressing complex joins using a function like variable blocks; feeding results from one into another like you'd do in any popular language. You can try running some complex queries with GraphQL+-, it might change your view. http://play.dgraph.io/ http://play.dgraph.io/
- jnordwick 10y agoCool af Edit: I still think it looks hideous. Def try to figure it out more tomorrow.