We should definitely evaluate pluggable storage engine...Besides several other advantages, it also helps in adding lot of tests to the storage engine.
On Wed, Apr 19, 2017 at 11:22 AM, Jon Haddad <jonathan.had...@gmail.com> wrote: > 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? > > Jon > > > > 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 > >
