Switch to RocksDb from LevelDB [JIRA: RIAK-1910]

[ArpitSuthar]

I would like to port leveldb backend storage to RocksDB.

RocksDB builds on LevelDB to be scalable to run on servers with many CPU cores, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, and to be flexible to allow for innovation.

[matthewvon]

Why? Have you personally tested the configuration?

See third party results: https://influxdb.com/blog/2014/06/20/leveldb_vs_rocksdb_vs_hyperleveldb_vs_lmdb_performance.html

[ArpitSuthar]

From the third party results we can that RocksDB is performing better in terms of Read/Write/Delete queries and DB compaction. Also it has performed average in other areas that are tested.

@matthewvon I would love to personally test the configuration of RockDB as storage with comparison of existing LevelDB. Though I need some guide to how to switch from RocksDB and test it.

[alexmoore]

@ArpitSuthar You'd have to implement Riak's Backend API. Basho does this through eLevelDB, which is the Erlang interface to Level, and our branch of LevelDB.

[urbanserj]

I would like to share my experience with rocksdb as a replacement for leveldb in our riak_kv-based database. I use leofs' erocksdb nif library [1]. It takes two working days to transit existing custom leveldb-backend to new rocksdb-backend.

Pros:

1. Storage efficiency increases up to 2 times
2. Disk utilization slumps [2]
3. Get, put, and fold operations speed up 3 times
4. Memory usage reduces to one-third
5. Cpu/schedulers utilization slightly diminishes

Cons:

1. Rocksdb has too many options

Also, rocksdb made it possible to implement new features. For example, now we have an efficient online snapshot for backup using checkpoints, automatic repair after a hard restart, and so on.

[1] https://github.com/leo-project/erocksdb [2] https://monosnap.com/file/1jS0v2UUiGqI4KVhHq0vuAHOyFKwfS.png

[matthewvon]

RocksDB comparison is still on the "we want to do this list". But honestly, it is not going to happen soon.

Not discounting your results. Not ignoring your results. Just saying it will be a while before we have time to duplicate and evaluate your results. It is a revenue priorities issue, not a technical issue.

[ArpitSuthar]

@matthewvon instead of completely switching to rocksdb , is it possible to have options for storage method like currently we have for bitcask and eleveldb ?

[matthewvon]

fyi: I am being forced to work with RocksDB on a different project. It looks really great on raw numbers. But the detail graphs look horrid ... it stalls all over the place ... and its performance really slumps once it starts actually reading data for compactions from disk. See this posting on RocksDB developer support page (especially the graph toward the end): https://www.facebook.com/groups/rocksdb.dev/permalink/1369946463103864/

[schrepfler]

Wondering if anyone picked this up?

[russelldb]

nope