[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17849018#comment-17849018
]
Stefan Miklosovic commented on CASSANDRA-12937:
-----------------------------------------------
I consolidated the links for PR's as it was getting confusing.
Claude's PR: [https://github.com/apache/cassandra/pull/3168]
mine which is same as his but squashed:
[https://github.com/apache/cassandra/pull/3330]
I rebased mine against current trunk where CASSANDRA-19592 was merged and I see
that the problematic test (SSTableCompressionTest#configChangeIsolation) passes
now which is indeed good news.
I will run a CI to see if something else is broken.
btw [~jlewandowski] mentioned me privately that it would be nice if we had the
configuration like this:
{code}
sstable:
selected_format: big
default_compression: lz4 //// check this
format:
big:
option1: abc
option2: 123
bti:
option3: xyz
option4: 999
compression: //// check this
lz4:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
snappy:
enabled: true
chunk_length: 16KiB
max_compressed_length: 16KiB
deflate:
enabled: false
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
instead of what we have now:
{code}
sstable_compression:
- class_name: lz4
parameters:
- enabled: "true"
chunk_length: 16KiB
max_compressed_length: 16KiB
{code}
The reasoning behind that is that we are just enriching existing configuration
section, we are not inventing anything new. Plus it would be cool to have
predefined compression options so if we just use lz4 in CQL then all parameters
will be automatically taken into consideration as well. If we provide some
parameters on CQL, these will be merged into what is in cassandra.yaml.
[~claude] I can take a look into this.
> 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 20m
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
