[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837201#comment-17837201
]
Sam Tunnicliffe commented on CASSANDRA-12937:
---------------------------------------------
So you're suggesting that we could have different default values in yaml across
the cluster, but that all nodes actually apply the same value regardless of
their own configured default? Which specific value makes it into schema just
depends on which instance acts as the coordinator for a given DCL statement? It
seems like if we actually want these to be cluster wide values and not
configurable on a per-node basis the defaults themselves should be in TCM,
independently of the schema transformations. In the past, we've used per-node
configuration like this to experiment with new compression algorithms on a
per-node basis and I can imagine potentially wanting to do the same with things
like compaction, so I'm not entirely convinced that this assumption is correct.
As far as the serialization format, schema transformations have to be
round-trippable via CQL for the purposes of recreating a schema from a
snapshot. So I don't think that using the CQL itself as the format is
inherently flawed and it does have a couple of big positives, namely that it's
great for visibility (for operators or when debugging) and that it doesn't
invent a new format, that we have version and manage as new
flags/features/defaults are added.
We should just need fully resolve and expand a DCL statement before serializing
it in {{SchemaAlteringStatement}} which would be entirely possible, but I
remain unconvinced that just picking the defaults from whatever node happens to
be coordinating is the right way to go.
> Default setting (yaml) for SSTable compression
> ----------------------------------------------
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Michael Semb Wever
> Assignee: Stefan Miklosovic
> Priority: Low
> Labels: AdventCalendar2021
> Fix For: 5.x
>
> Time Spent: 8h
> Remaining Estimate: 0h
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
