(https://open.dgraph.io/licensing is a dead link)
Badger – A fast key-value store written natively in Go
11–20 of 101 posts
Re: Badger – A fast key-value store written natively in Go
#12Why not boltdb?
Re: Badger – A fast key-value store written natively in Go
#13Re: Badger – A fast key-value store written natively in Go
#14I 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
#15fio [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?
Re: Badger – A fast key-value store written natively in Go
#16Few 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
#17Re: Badger – A fast key-value store written natively in Go
#18Why not boltdb?
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
#19How does this compare to boltdb?
Re: Badger – A fast key-value store written natively in Go
#20off 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)
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.