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.)
Badger – A fast key-value store written natively in Go
21–30 of 101 posts
Re: Badger – A fast key-value store written natively in Go
#22This 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?
Shameless plug: If you have write-once (or seldom) and read-often kind of access pattern for JSON documents, I wrote a simple (619 LOC), pure Go key-value store, that supports this use case: microblob[1]. It logs in common format, uses a single file backend and scales up and down with RAM..
Re: Badger – A fast key-value store written natively in Go
#23This 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?
> I've been looking for a fast, simple, pure Go key-value store. Shameless plug: If you have write-once (or seldom) and read-often kind of access pattern for JSON documents, I wrote a simple (619 LOC), pure Go key-value store, that supports this use case: microblob[1]. It logs in common format, uses a single file backend and scales up and down with RAM.. [1] https://github.com/miku/microblob
Re: Badger – A fast key-value store written natively in Go
#24Re: Badger – A fast key-value store written natively in Go
#25nobody has said it so I must. Badgers? We don't need no stinking badgers!
Re: Badger – A fast key-value store written natively in Go
#26Re: Badger – A fast key-value store written natively in Go
#27off 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…
As an aside, one can certainly describe something as draconic(or whatever else) if one views it as such; it's just an opinion.
Re: Badger – A fast key-value store written natively in Go
#28Re: Badger – A fast key-value store written natively in Go
#29off 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)
It makes sense from the host business's point of view. If you are the sole contributor, then you're entitled to do what you like. Moreover, you're also free to charge for commercial licences.
This licencing model wouldn't be appropriate for a community-centric database, such as PostgreSQL. With many contributors to core, no one would be able to arbitrage the situation.
Re: Badger – A fast key-value store written natively in Go
#30Probably a naive question, but how does it compare to Redis? When would someone look for a K-V store written in X instead of the already mature Redis?