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
There is probably something I missed the message below.
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
"I have no clue what it would take to accomplish a pluggable storage
engine, but I love this idea."
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
We should definitely evaluate pluggable storage engine...Besides several
other advantages, it also helps in adding lot of tests to the storage
On Wed, Apr 19, 2017 at 11:22 AM, Jon Haddad
> I have no clue what it would take to accomplish a pluggable
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
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
The closest thing we have to that list is the "lhf" (low hanging fruit) tag
On Wed, Apr 19, 2017 at 4:40 AM, koray mehmet