cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dikang Gu (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.
Date Mon, 30 Oct 2017 23:34:02 GMT


Dikang Gu commented on CASSANDRA-13475:

My major motivation is that we probably don't really need the CFS reference inside the StorageEngine,
at least in our RocksDB based implementation. In most case, I just need an identify to the
column family I'm current working on, could be table name or table uuid (maybe uuid is better
than table name), not necessary to be the CFS. That's why I address [] 's
comments on the CFS.

Can you explain more about `main hooks for a pluggable storage layer should be a CFS implementation`?
Current in my proposal, write requests will be implemented under the `applyMutate` API and
read requests will be handled by implementing the Partition interface. For Keyspace and CFS,
most of the coordinating logic should be remain unchanged.

> First version of pluggable storage engine API.
> ----------------------------------------------
>                 Key: CASSANDRA-13475
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Dikang Gu
>            Assignee: Dikang Gu
> In order to support pluggable storage engine, we need to define a unified interface/API,
which can allow us to plug in different storage engines for different requirements. 
> In very high level, the storage engine interface should include APIs to:
> 1. Apply update into the engine.
> 2. Query data from the engine.
> 3. Stream data in/out to/from the engine.
> 4. Table operations, like create/drop/truncate a table, etc.
> 5. Various stats about the engine.
> I create this ticket to start the discussions about the interface.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message