Hacker News Reader

Comment by Veratyr | Hacker News Reader

Very interesting, though a shame (to me) that it's Go, as I'm actually after a C++ KV store that ideally isn't RocksDB (I want something that's much easier to embed and RocksDB has a bunch of dependencies).

Have you tried benchmarking on baremetal though? I've been shopping around for a KV store and came across this benchmark: http://www.lmdb.tech/bench/ondisk/#sec7

Interestingly, for 768-byte values, LevelDB is the clear winner when it comes to read scaling on a VM yet on bare metal it's drastically outperformed by LMDB.

View on HN

On bare metal you'll be hard pressed to beat LMDB.

It's really about as simple, and as bare bones as you can make a traditional KV storage while still preserving MVCC, transactions, and maintaining ACID.

Furthermore it's design is prefectly suited to exploit Optane/FRAM non-volatile RAM devices that appear to becoming.

Apparently the way LMDB does I/O is exercising slower (more complex?) code paths in the virtualization implementation code compared to LevelDB, and virtualization overhead is significant in these benchmarks (actually slows down execution several times).

LMDB does mmap while LevelDB does plain file I/O.

It depends on the hypervisor. XEN/AWS uses and older slower path for memory allocation then the modern KVM/Intel-EPT allows.

Every `malloc` under XEN (that can't be satisfied with unused memory already mapped into that processes userspace) requires a hyper call.

This VMM approach was _largely_ depreciated about 6 years ago when Intel created page table bits that let the bare metal OS give the VM a _range_ of memory it can virtually re-map, but AWS hasn't adopted this.

Have you heard of Kyoto and Tokyo Cabinet libraries? That's the first thing I think of when I think of a KV in C++:

http://fallabs.com/kyotocabinet/

http://fallabs.com/tokyocabinet/

https://en.wikipedia.org/wiki/Tokyo_Cabinet_and_Kyoto_Cabine...

(The names contain Cabinet but they aren't related to city/national governments.)

I once played around with Kyoto in Lua but can't say anything good or bad about it's performance, scalability, etc. They have documentation and some presentation slides in English on their website and provide quite a lot of language bindings if you are interested.

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, because that's what most people would use to run the applications/DBs built on top of the KV store. This ensures that the hardware specs used for benchmarking are easily available to everyone.

they say that when you have a hammer, everything looks like a nail. bearing in mind that I definitely have a go-hammer, but depending on the library you're dealing with, turning a go library into a .a or .so via cgo is pretty painless. it usually requires just a very small shim.

anyway, not strictly an answer to the question you asked, but b/c I've spent so much time doing cgo I figured I'd mention it as a possibility.

Reply on news.ycombinator.com