I have no clue what it would take to accomplish a pluggable storage engine, but 
I love this idea.  

Obviously the devil is in the details, & a simple K/V is very different from 
supporting partitions, collections, etc, but this is very cool & seems crazy 
not to explore further.  Will you be open sourcing this work?


> On Apr 19, 2017, at 9:21 AM, Dikang Gu <dikan...@gmail.com> wrote:
> Hi Cassandra developers,
> This is Dikang from Instagram, I'd like to share you some experiment
> results we did recently, to use RocksDB as Cassandra's storage engine. In
> the experiment, I built a prototype to integrate Cassandra 3.0.12 and
> RocksDB on single column (key-value) use case, shadowed one of our
> production use case, and saw about 4-6X P99 read latency drop during peak
> time, compared to 3.0.12. Also, the P99 latency became more predictable as
> well.
> Here is detailed note with more metrics:
> https://docs.google.com/document/d/1Ztqcu8Jzh4USKoWBgDJQw82DBurQm
> sV-PmfiJYvu_Dc/edit?usp=sharing
> Please take a look and let me know your thoughts. I think the biggest
> latency win comes from we get rid of most Java garbages created by current
> read/write path and compactions, which reduces the JVM overhead and makes
> the latency to be more predictable.
> We are very excited about the potential performance gain. As the next step,
> I propose to make the Cassandra storage engine to be pluggable (like Mysql
> and MongoDB), and we are very interested in providing RocksDB as one
> storage option with more predictable performance, together with community.
> Thanks.
> -- 
> Dikang

Reply via email to