[
https://issues.apache.org/jira/browse/CASSANDRA-13475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236648#comment-16236648
]
Blake Eggleston commented on CASSANDRA-13475:
---------------------------------------------
I think it’s too early to start looking at code, or talking about api
specifics. We should start by getting a rough plan together. My thoughts on an
initial plan are below. This is just a rough idea dump, so let me know if I’ve
missed anything.
# Discuss expectations, guidelines, non-technical stuff, etc.
** Let’s start off by making sure we’re all on the same page about:
*** What we expect the end result to be
*** Guidelines on planning / implementing component refactors
*** Any approximate timelines you have in mind, if any
*** Pluggable storage's place in the cassandra project
# Agree on the boundaries of the storage engine layer. What it is and isn’t
responsible for.
** This has already been discussed to some degree, but let’s agree on a
definition.
# Work out a strategy for streaming and repair
** This is a bit hand wavy at the moment, and not having a solid streaming and
repair story is a non starter. So let’s figure out how that’s going to work
(including incremental repair) before we get too deep into anything els
# Decide how schema ui / metadata will be refactored to support multiple
storage engines
# Work out a strategy for exposing metrics / monitoring from different engines.
# Migrate read command and write logic into cfs
# Identify remaining leaky parts of CFS class.
** Some of this will be legit storage implementation details. Other parts will
be systems we’ve missed, or things that need to be abstracted.
# Identify systems not controlled by CFS that interacts with storage layer on
it’s own
# Implement streaming / repair changes
# Refactor each leaky group of cfs components
# Refactor each non-cfs system that interacts with storage layer.
# Refactor metrics/monitoring systems
# Refactor schema ui, metadata implementation
# Extract interfaces from CFS and keyspace
# Introduce pluggable Keyspace/CFS factories controlled by schema
Thoughts?
> 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
> Priority: Major
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
