Re: tickets to start

+dev Hi Koray, The closest thing we have to that list is the "lhf" (low hanging fruit) tag on jira: https://issues.apache.org/jira/issues/?jql=project%20%3D%2012310865%20AND%20labels%20%3D%20lhf%20AND%20status%20!%3D%20resolved On Wed, Apr 19, 2017 at 4:40 AM, koray mehmet

Re: Cassandra on RocksDB experiment result

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

Re: Cassandra on RocksDB experiment result

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 wrote: > I have no clue what it would take to accomplish a pluggable

RE: Cassandra on RocksDB experiment result

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

Re: Cassandra on RocksDB experiment result

"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

Re: Cassandra on RocksDB experiment result

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