It's an interesting experiment!
Did you test with more than 2 nodes? Do you expect scalability to be as linear
as regular Cassandra?
From: Eric Stevens [mailto:migh...@gmail.com]
Sent: jeudi 20 avril 2017 00:41
Subject: Re: Cassandra on RocksDB experiment result
> Right now all the compaction strategies share the assumption that the data
> structure and layout on disk is fixed. With pluggable storage engine, we
> need to special case each compaction strategy (or at least the Abstract
> class of compaction strategy) for each engine.
As Ben points out, compaction should be treated as _part_ of the storage
layer. The need to engage in compaction is a consequence of immutable data
stores behind a mutable interface. A different storage layer might require
a different approach or might not even require compaction in the same sense.
On Wed, Apr 19, 2017 at 4:01 PM Ben Bromhead <b...@instaclustr.com> wrote:
> This looks super cool would love to see more details.
> On a general note, a pluggable storage layer allows other storage engines
> (and possibly datastores) to leverage Cassandras distributed primitives
> (dynamo, gossip, paxsos?, drivers, cql etc). This could allow Cassandra to
> fill similar use cases as Dynomite from Netflix.
> Also as Sankalp mentioned we get some other benefits including better
> In my experience with pluggable storage engines (in the MySQL world), the
> > engine manages all storage that it "owns." The higher tiers in the
> > architecture don't need to get involved unless multiple storage engines
> > have to deal with compaction (or similar) issues over the entire
> > e.g., every storage engine has read/write access to every piece of data,
> > even if that data is owned by another storage engine.
> > I don't know enough about Cassandra internals to have an opinion as to
> > whether or not the above scenario makes sense in the Cassandra context.
> > "sharing" (processes or data) between storage engines gets pretty hairy,
> > easily deadlocky (!), even in something as relatively straightforward as
> > MySQL.
> This would be an implementation detail, but given that tables in Cassandra
> don't know about each other (no joins, foreign keys etc... ignore mv for
> the moment), but storage engine interactions probably wouldn't be an issue.
> > This was a long and old debate we had several times in the past. One of
> > the difficulty of pluggable storage engine is that we need to manage the
> > differences between the LSMT of native C* and RockDB engine for
> > repair, streaming etc...
> > Right now all the compaction strategies share the assumption that the
> > structure and layout on disk is fixed. With pluggable storage engine, we
> > need to special case each compaction strategy (or at least the Abstract
> > class of compaction strategy) for each engine.
> > The current approach is one storage engine, many compaction strategies
> > different use-cases (TWCS for time series, LCS for heavy update...).
> > With pluggable storage engine, we'll have a matrix of storage engine x
> > compaction strategies.
> Compaction is part of the storage engine, and if I understand Dikangs
> design spec, it is bypassed?
> Cassandras currently storage engine is a log structured merge tree. RocksDB
> does it's own thing.
> Again this is an implementation detail about where the storage engine
> interface line is drawn, but from the above example compaction I think it
> is a non issue?
> > And not even mentioning the other operations to handle like streaming and
> > repair.
> Streaming and repair would be the harder problem to solve than compaction
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692 <(650)%20284-9692>
> Managed Cassandra / Spark on AWS, Azure and Softlayer