Live data from Hacker News

Badger – A fast key-value store written natively in Go

open.dgraph.io

11–20 of 101 posts

Re: Badger – A fast key-value store written natively in Go

#11
off topic: flipping through the dgraph code, I noticed their licensing switch from Apache 2 to AGPLv3, anyone involved around to comment? Adding a draconic open source license is an unwise decision for an early stage database product imo

(https://open.dgraph.io/licensing is a dead link)

Re: Badger – A fast key-value store written natively in Go

#14
There is so much negativity in these comments! This project is really cool!

I really appreciate the trend to rewrite C/C++ libraries in Go. It has always been really frustrating that hacky library wrappers for other languages leave performance and features on the table because they're either incomplete or just too hard to implement in the host language. For most of the languages out there, it is always better to have a native implemention.

There are now a number of great embedded key/value stores for Go, which make it really easy to create simple, high performance stateful services that don't need the features provided by SQL.

Re: Badger – A fast key-value store written natively in Go

#15
Range iteration latency is very important and might be limited by concurrency. I think you can only get 100K IOPS on Amazon’s i3.large when the disk Request queue is full.

fio [1] can easily do this because it spawn a number of threads

While working with Rocksdb we also found that Range iteration latency was very bad compared to a B+-tree and that RocksDB get good read performance mostly from random read because it's using bloomfilters.

Does anyone know if this got fixed somehow recently?

[1] https://linux.die.net/man/1/fio

Re: Badger – A fast key-value store written natively in Go

#16
This could not have come at a better time, I've been looking for a fast, simple, pure Go key-value store.

Few questions:

- Does this have a log file? If so, what does it log and can it be disabled?

- How is the data stored? (Single file, multiple files, etc.)

- How is the RAM usage?

Re: Badger – A fast key-value store written natively in Go

#18

Why not boltdb?

They're based on different technologies. Bolt uses B-Trees and Badger/Rocks/Leveldb use LSM trees.

Bolt also uses insane amounts of RAM and writes get slower and slower as the size of the database increases. (Personal experience, don't have benchmarks. Take this at face value.)

Re: Badger – A fast key-value store written natively in Go

#20

off topic: flipping through the dgraph code, I noticed their licensing switch from Apache 2 to AGPLv3, anyone involved around to comment? Adding a draconic open source license is an unwise decision for an early stage database product imo ( https://open.dgraph.io/licensing is a dead link)

> Adding a draconic open source license is an unwise decision

AGPLv3 is just a license, it is not "draconic", nor "cancer", (despite what Ballmer wants you to believe), it simply represents an ethical/moral agreement with the ideology of software freedom and since it is their code, they are free to express what they believe via the appropriate license. Nobody is making them do it, nobody is forcing you to use it and nobody is demanding you agree with it, it was a free choice and is therefore as far from "draconic" as one can possibly be, unless you believe that everybody who doesn't subscribe to your worldview is "draconic" by definition.

Post reply on HN