rocksdb (fb leveldb fork) as riak backend?
matthewv at basho.com
Mon Jan 27 20:49:37 EST 2014
Basho's leveldb requirements have lead to different optimizations. Facebook has a captive hardware environment and usage case that does not match ours. I am not saying their changes are better or worse, only different.
- multiple databases running simultaneously: 6 to 64
- support for slow solitary SATA drives all the way to rocking' fast FusionIO PCI arrays
- fast disaster recovery / repair
- aggressive delete logic to help remove large chunks of deleted data now instead of next year
- (and a few things still not unleashed in Riak 2.0)
So our compaction strategy has come a long way: from Google's original single thread to a thread pool that can run simultaneous companions on the same database as well as other databases. We have a dedicated thread that constantly computes the speed of the local array and gradually manipulates each write request to prevent Google's designed stall … maximizing total throughput for the simultaneous databases while maintaining a constant user experience. And in between all that, we have retuned the skip list, the bloom filter, and integrated Intel's hardware CRC assembly code.
That is what meets Riak's needs.
On Jan 27, 2014, at 6:05 PM, Alexander Sicular <siculars at gmail.com> wrote:
> Hey Basho gang,
> Have you all taken any sort of look at FB's leveldb fork, rocksdb, http://rocksdb.org/? Just watching Dhruba's video it seems like it may be a useful upgrade, https://code.facebook.com/videos/174548089418739/rocksdb-a-high-performance-embedded-key-value-store-for-flash-storage-data-scale/. The main talking points seems to be that rocksdb upgrades leveldb such that it is more efficient when storing data more than system ram, has more efficient access patternsto take advantage of ssd's and has a better compaction story.
> Care to share your thoughts?
> -Alexander Sicular
> riak-users mailing list
> riak-users at lists.basho.com
More information about the riak-users