cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Eggleston (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13475) First version of pluggable storage engine API.
Date Thu, 02 Nov 2017 21:41:00 GMT

    [ 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message