[
https://issues.apache.org/jira/browse/CASSANDRA-13475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226828#comment-16226828
]
Aleksey Yeschenko commented on CASSANDRA-13475:
-----------------------------------------------
I’m with Blake on this.
Now, I’ll be upfront: I’m not 100% sold on the idea of making the storage
engine pluggable, although I am warming up to it, at least if someone did a
really good job.
What I was expecting from the patch:
1. Keyspace abstracted away, ColumnFamilyStore (Table) interfaces extracted,
with all sstable/compaction/etc. specific logic isolated into concrete default
engine implementation
2. Some kind of StorageEngine interface that would consume metadata and return
initialized engine-specific instances of Keyspace/Table classes
3. Abstracted away metadata, now that I think of it; default compaction,
compression, and other params don’t make sense for rocksdb engine, I assume,
nor would they for some other non-default implementations; also should be able
to set options for non-default engine via CQL
4. Same goes for metrics; you’d be still creating all the default metric per
ks/table, many of which making no sense in other engines; leaky
5. Acknowledgement and enumeration of everything that needs to be modified. And
a lot needs to be - from startup checks to periodic tasks, to even some read
logic that uses CFS for row size estimation
Assuming that the engine would be set on per-keyspace basis (which IMO makes
most sense), Keyspace and CFS would be the primary extension points; not
‘CFS/Keyspace will become a thin wrapper around the storage engine API’, but
the exact opposite.
The suggested patch/API is very minimal, and not in a good way. It’s a hacky
default engine bypass mechanism, not a proper abstraction of the storage
engine, and not even a good starting point, imo :\
More importantly, I feel like the full scope of a properly implemented
abstracted out storage engine is realized; done right, it’s a *huge* effort. I
would like to see some kind of plan, with the full scope at least described,
and perhaps suggested phases/steps of getting there.
> 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
