mrjn

29 ms·

301.
by mrjn 10y ago
Dgraph does automatic replication, for providing fault tolerance. It's baked in pretty deep into Dgraph. We use consensus algorithm, so all your writes are atomically consistent (not eventually consistent). https://docs.dgra
302.
by mrjn 10y ago
Dgraph follows MongoDB licensing. The clients are all in Apache, and the server code is AGPL. This doesn't affect anyone using Dgraph for commercial purposes; but if they make changes to the server code, they'll have to release th
303.
by mrjn 10y ago
(author of Dgraph) Dgraph's retrieval is pretty fast, so looking up properties is trivial. It also supports indexing various data types: supports full-text search, term matching and regexps on strings, inequality and sorting on ints, f
304.
by 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
305.
Show HN: GraphQL+-, a Variant of GraphQL for Graph DBs(wiki.dgraph.io)
7 points by mrjn 10y ago|0 comments
306.
Asanawarrior: Use Taskwarrior as a CLI to Asana(github.com)
2 points by mrjn 10y ago|0 comments
307.
Show HN: Gru – Open source solution for better technical interviews(open.dgraph.io)
13 points by mrjn 10y ago|0 comments
308.
by mrjn 10y ago
Re: server resource wastage. That's a great point -- and someone in Jeff Dean's talk asked the same question. So, the small optimization that he mentions is to send the query to the replica after 2ms telling it which server it was
309.
Show HN: Golang implementation of custom encoding in net/rpc vs. grpc.io(open.dgraph.io)
10 points by mrjn 10y ago|3 comments
310.
by mrjn 10y ago
Thanks for your comments! I think people feel that the data set wasn't big enough to prove scalability. While I disagree, I think this is a great opportunity as well -- to hear from people. We can actually bring up the entire 1.9B trip
311.
by mrjn 10y ago
This is not a benchmark. But, there is network communication going on in the multi node cluster tests.
312.
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
313.
by mrjn 10y ago
It depends upon the memory available. We have a background goroutine which checks how much memory we're using and evicts posting lists if we exceed a predefined usage. If we have a lot of memory then we just won't evict the postin
314.
by mrjn 10y ago
This is not a benchmark. This is an experiment to determine whether Dgraph scales as you'd expect it to. If you're interested, there're a list of complex queries that we've run: https://discuss.dgraph.io/
315.
by mrjn 10y ago
The writes for Dgraph actually happen in O(log N) time where N = number of subjects for a given predicate; and a background job then syncs the posting lists to disk later. So, that performance wouldn't be any worse than what we observe
316.
by mrjn 10y ago
Not exactly. Given enough time and a lot of hard disk, you can put the entire 1.9B triples into any database -- that doesn't prove that it scales. Also, if the database uses a single global mutex lock for all reads and writes, again it
317.
Scaling nodes in a Dgraph cluster(blog.dgraph.io)
69 points by mrjn 10y ago|35 comments
318.
by mrjn 10y ago
We do pretty strict code reviews https://github.com/dgraph-io/dgraph/pulls?utf8=%E2%9C%93&q=i... . Nothing goes into master until it gets LGTMed. The point was that, if all of your team members are having a co
319.
by mrjn 10y ago
Agree. In fact, that's the main motivation behind this bot is to ensure that we don't use Slack for everything. But, it goes beyond that. We also realized that Slack wasn't a productivity enhancer, it was a bonding catalyst.
320.
by mrjn 10y ago
Awesome! We took that detour as well, tried a bunch of other chat apps, but in the end, Slack won out. It's the most mature chat system out there. With Wisemonk keeping us accountable, we're now able to tackle the negatives of Sla
321.
by mrjn 10y ago
The main reason for not turning off notifications is the fear of missing out, decisions being made without you. And it's a very valid fear. One team member going away from Slack is bad for the member and for the team. If everyone else
322.
by mrjn 10y ago
We at Dgraph use Trello as well. TBH, the commenting on Trello is primitive compared to Discourse. We still comment on Trello when we're talking about specific cards -- but if it needs thorough discussion, we always go to Discourse. In
323.
by mrjn 10y ago
The main reason for not turning off notifications is the fear of missing out, decisions being made without you. And it's a very valid fear.
324.
Show HN: Bot to steer discussions from Slack to Discourse(medium.dgraph.io)
106 points by mrjn 10y ago|47 comments
325.
Releasing Dgraph, distributed graph database: v0.3(github.com)
6 points by mrjn 10y ago|0 comments
326.
Why we are building DGraph(medium.com)
4 points by mrjn 10y ago|0 comments
327.
by mrjn 11y ago
So, for filters like year >= 1975, that'd be part of our sorting feature push, which would also help with this sort of filter. Also, string matching / name search, is in our roadmap as well. The clients don't need to pass
328.
by mrjn 11y ago
The way data is sharded across machines, is done via predicate. So, in this case, the 2.4 billion occurrences only leads to a data of 2.4G * 8 bytes (uint64 id) ~ 20GB of data for us, on one machine; which is pretty manageable. Furthermore,
329.
by mrjn 11y ago
Up until v1.0, we're only looking at GraphQL. After that, we'll consider adding other languages depending upon the demand.
330.
by mrjn 11y ago
We have funding now, would be made public soon. So, we have enough to keep us going for a bit, and focus solely on the engineering challenges. DGraph would support high availability, which means all our shards would be replicated 3x across

More ›