mrjn

30 ms·

271.
by mrjn 9y ago
Also at: https://techcrunch.com/2017/12/19/dgraph-raises-3m-for-its-o...
272.
by mrjn 9y ago
It's unclear if Neptune supports ACID transactions. They mention "you can use relationships to process financial and purchase transactions in near real time", which could be interpreted either way, and have nothing on the fea
273.
by mrjn 9y ago
My experiences switching from a Mac to running Arch Linux on a Thinkpad.
274.
Linux vs. Mac on a laptop(medium.com)
7 points by mrjn 9y ago|4 comments
275.
by mrjn 9y ago
SQL is not beating NoSQL. NoSQL is evolving. https://blog.dgraph.io/post/sql-vs-nosql/
276.
by mrjn 9y ago
All the benchmarking code and log is located here: https://github.com/dgraph-io/badger-bench
277.
Badger vs. LMDB vs. BoltDB: Benchmarking Key-Value Databases in Golang(blog.dgraph.io)
9 points by mrjn 9y ago|2 comments
278.
by mrjn 9y ago
This post explains issues encountered when writing data to file system, and how Badger was checked and fixed to deal with these issues; using a tool called ALICE. Corresponding paper: https://www.usenix.org/system/files
279.
Making Badger crash resilient with ALICE(blog.dgraph.io)
1 points by mrjn 9y ago|1 comments
280.
by mrjn 9y ago
Over the last couple of months, we've been working solely on Dgraph scalability and performance. Here's our journey!
281.
Scale the shit out of this(open.dgraph.io)
12 points by mrjn 9y ago|1 comments
282.
by mrjn 9y ago
Glad to know you're trying Dgraph! Related questions are being done based on question tags. We do support full-text search, which is what the search bar is using for questions and answers.
283.
Show HN: Stack Overflow and Dgraph = Graph Overflow(graphoverflow.dgraph.io)
5 points by mrjn 9y ago|2 comments
284.
Running Stack Overflow on Dgraph(open.dgraph.io)
11 points by mrjn 9y ago|0 comments
285.
by mrjn 9y ago
Why is this marked as dup? This is the first time the Github link is on HN.
286.
by mrjn 9y ago
> so whenever an OS thread is blocked the OS scheduler simply schedules another OS thread Go does that even now. If a thread is blocked, it would create another thread, but it does it with a small delay. I saw a visible increase in IOPS
287.
by mrjn 9y ago
Badger should outperform LevelDB easily, particularly as the value sizes increase. The design and our benchmarks are both consistent with this. I haven't had a chance to benchmark on baremetal. We chose to run the benchmarks on Amazon,
288.
by mrjn 9y ago
It's not. The comparison is using the same APIs as provided by LevelDB/RocksDB. Not the transactional ones mentioned below. TransactionDB* txn_db; Status s = TransactionDB::Open(options, path, &txn_db); Transaction* txn = txn_
289.
by mrjn 9y ago
The reason we want to KISS is to ensure a solid, robust, and performant layer of storage, that other projects can use to build their transactional versions, etc. One can take Badger and build a transactional layer above it, and it would sti
290.
by mrjn 9y ago
Go is slow when doing a lot of random lookups. Each lookup into disk is a blocking one, which causes a Goroutine to block the OS thread. A new OS thread then has gets created after a time delay to schedule goroutines. This happens over and
291.
Show HN: Badger – an embeddable, persistent key-value store written in Go(github.com)
88 points by mrjn 9y ago|33 comments
292.
by mrjn 9y ago
Go has no native support for aio. Based on this thread, Goroutines seem to do the same thing, via epolls. https://groups.google.com/forum/#!topic/golang-nuts/AQ8JOHxm... I think the best bet is to build a fio
293.
by mrjn 9y ago
We have tried with BoltDB. Its performance is really bad. It is just badly implemented, acquires a global mutex lock across all reads and writes. We wouldn't have written Badger if BoltDB worked for us. RocksDB performs much better and
294.
by mrjn 9y ago
Actually, no relation to Wisconsin Badgers. Badger is (and has been) Dgraph's mascot. So, we thought it would be nice to name the key-value store "Badger."
295.
by mrjn 9y ago
LevelDB should be slower than RocksDB.
296.
by mrjn 9y ago
You are comparing a memory first store against a disk first store. Everything is much faster if it only has to be stored in RAM before the update is considered successful.
297.
by mrjn 9y ago
(Badger author) We have tried huge prefetch size, using one Goroutine for each key; hence 100K concurrent goroutines doing value prefetching. But, in practice, throughput stabilizes after a very small number of goroutines (like 10). I suspe
298.
by mrjn 9y ago
(Badger author here) BoltDB is super slow. Doesn't even come close to the performance we need, which is why we decided to write Badger from scratch.
299.
by mrjn 10y ago
Expect freebase.dgraph.io in a couple of weeks.
300.
by mrjn 10y ago
(Dgraph author) That's a good point. I think I'll load one instance up with the entire Freebase data, run it on freebase.dgraph.io, and blog about how and whys etc. Expect that in the next couple of weeks.

More ›