4 ms·

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 e

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

V-eHGsd_ 9y ago
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.
mrjn 9y ago
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.
valarauca1 9y ago
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.
- ntoshev 9y ago
  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.
  - valarauca1 9y ago
    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.
FRex 9y ago
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/kyotocabinet/ http://fallabs.com/tokyocabinet/ http://fallabs.com/tokyocabinet/ https://en.wikipedia.org/wiki/Tokyo_Cabinet_and_Kyoto_Cabinet 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.

V-eHGsd_ 9y ago

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.

mrjn 9y ago

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.

valarauca1 9y ago

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.

ntoshev 9y ago
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.
- valarauca1 9y ago
  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.

FRex 9y ago

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/kyotocabinet/ http://fallabs.com/tokyocabinet/ http://fallabs.com/tokyocabinet/ https://en.wikipedia.org/wiki/Tokyo_Cabinet_and_Kyoto_Cabinet 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.