[
https://issues.apache.org/jira/browse/CASSANDRA-13475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226027#comment-16226027
]
Blake Eggleston commented on CASSANDRA-13475:
---------------------------------------------
What I mean is that CFS basically exposes a storage api to the rest of
Cassandra, and has a lot of the per-table storage implementation details and
state. So instead of adding another interface, why not make CFS one of the
primary extension points for the storage api? So you’d extract an
IColumnFamilyStore interface, the current ColumnFamilyStore class would be
CassandraColumnFamilyStore or whatever, and rocksdb would have a
RocksDBColumnFamilyStore.
This will be less invasive, highlight the areas where the storage layer
implementation details leak into other parts of the project, and prevent
cassandra storage layer specific stuff (like compaction strategies) from
getting created/started/accessed.
> First version of pluggable storage engine API.
> ----------------------------------------------
>
> Key: CASSANDRA-13475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13475
> 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
