[
https://issues.apache.org/jira/browse/CASSANDRA-18441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711118#comment-17711118
]
David Capwell commented on CASSANDRA-18441:
-------------------------------------------
Thanks [~blambov] for driving this!
bq. In other words, I agree it makes most sense for the class name to be the
only configuration parameter there. (AFAIK we have never used discovery as a
method of finding classes to initialize.)
There is a first time for everything! Relying on every node having the same
config can be dangerous, so fell its best that we learn formats via class path
rather than config.
bq. On the write side at the very least we need a yaml option to specify the
selected format
Agree, we should have something like
{code}
default_sstable_format: big
{code}
bq. These must be configurable by node
100% agree; there is one big question that I need to ask, and its nested vs not
nested. [~maedhroz] and I tried to get us to move to a nested model, but there
was strong pushback that we should not do that, so when it becomes about params
we need to answer "should" this be nested or not, answering this makes this a
lot more annoying sadly...
Lets say we allow nesting, then I could see something like the following
{code}
sstable_format:
bti:
row_index_granularity: 4kb
version: ca
{code}
There are a few things going on that make this very different than the proposal:
1) The usage of "bti". Formats tend to have names, so I feel we should index
off that. We can make sure names are unique at startup, but will never really
be able to define against different nodes defining the names differently... to
help lower this risk, the format should define the name, and we should use the
defined names we saw during loading
2) we should reject unknown formats and unknown configs in a consistent manner.
ATM we rely on DD to validate this during startup, but these may change after
boot (can add JMX or allow mutable access via SettingsTable). I feel we should
push this logic into the data structure that Conf
bq. in the future it makes sense to also permit per-table configuration
Agree, but this gets tricky without transactional cluster metadata, as you can
fall into the same trap that pluggable memtable had; if you have a single node
in the cluster with different configs, you break things.
Streaming already requires that if 1 node uses a config, all nodes must
understand it... so it maybe that we have to deal with this already, so maybe
its ok to expose "'sstable_format': 'big'" in the table metadata? I would need
to think about this more, but due to the fact streaming requires we get this
right, not sure if table param makes things worse.
If we do add this without TCM, we need to use names that are from the format
and not from the user... that at least makes sure that if the class path is
consistent we are fine.
The other issue is also on rolling upgrades, lets say for 5.0 -> 5.1 where we
get a brand new bti version... whatever is put into the table metadata must be
understood by the whole cluster before we accept... With TCM targeted for 5.0
this maybe safe to assume we can handle this? Not actually sure how we can
validate changes before apply in that world... [~samt]/[~ifesdjeen] would be
great to get your feedback on this.
> Improvements to SSTable format configuration
> --------------------------------------------
>
> Key: CASSANDRA-18441
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18441
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Branimir Lambov
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.x
>
>
> CEP-17 and CASSANDRA-17056 abstracted some interfaces for SSTable format
> implementations and defined a method of plugging in specific configurations.
> This method is brittle and asks users to specify format identifiers whose
> configuration does not provide value but can be the source of conflicts and
> problems. On the other hand it makes important choices non-obvious, as the
> selection of format to write is given by the order of configured interfaces.
> An improved specification mechanism needs to be put in place before Cassandra
> 5 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
