Live data from Hacker News

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

open.dgraph.io

21–30 of 101 posts

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

#21

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.)

We've experienced these downsides as well, although it seems that boltdb's memory usage can be deceptive due to mmap'ing the db file.

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

#22

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?

> 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

#23
post #22

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?

> 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

Not for this particular project, but I'll keep it in mind for if/when I ever need it!

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

#27

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…

I think what fortytw2 was trying to say is that the AGPL is not a wise choice for software that wants to gain the most popularity and usage as possible since usage of AGPL licensed software is categorically banned (even more so than GPLV3) by a some of companies.

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

#29

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)

The AGPL for database products isn't unheard of. See also Neo4J.

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

#30

Probably 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?

Badger is designed to store data on disk (like RocksDB or LevelDB), while Redis is an in-memory storage which can't store data sets larger than memory.
Post reply on HN