[
https://issues.apache.org/jira/browse/CASSANDRA-18533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779554#comment-17779554
]
Maxwell Guo edited comment on CASSANDRA-18533 at 11/2/23 3:18 PM:
------------------------------------------------------------------
[~blambov]Hi, I have some questions here.
1.we are going to put the format-specific options into the [option
map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/AbstractSSTableFormat.java#L27]
here , am I right ?
2.it seems key_cache_size, key_cache_keys_to_save, key_cache_save_period, are
not sstable level but just for key cache which is db level, should I remove
them?
3.I am a little confusing now for table level configuration in CASSANDRA-18534
and options here. if we are going to define sstable option like [this
|https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1029],then
we may mix the table level options in CASSANDRA-18534 and the options here,
what I am thinking is that YAML needs to define several types of
configurations:(1) sstable option just for bti;(2) sstable option for big;(3)
common option that can be used in bti and big; if we have other sstable format
in the future ,we may need to expand this category.
{code:java}
sstable:
selected_format:big (or some use custom type like big-fast)
format.option:
-common:
row_index_granularity: xxx
-big:
bf_chance:xxxx
-bti:
xxxxxx
-bti-fast:
xxxx
{code}
where all the custom-type sstable format will inherit common's option values
all will also have it's own custom option values, take their union as the final
value.
In this way, we can put all sstable configuration here, and CASSANDRA-18534 can
also define the table's custom type of sstable format, through ddl using
sstable_format = 'big', which can use the local yaml's value.
was (Author: maxwellguo):
[~blambov]Hi, I have some questions here.
1.we are going to put the format-specific options into the [option
map|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/AbstractSSTableFormat.java#L27]
here , am I right ?
2.it seems key_cache_size, key_cache_keys_to_save, key_cache_save_period, are
not sstable level but just for key cache which is db level, should I remove
them?
3.I am a little confusing now for table level configuration in CASSANDRA-18534
and options here. if we are going to define sstable option like [this
|https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1029],then
we may mix the table level options in CASSANDRA-18534 and the options here,
feeling not clear as we mix the table level configuration together with those
non-table level, should we separate them at yaml level, though the original
yaml do not define a configuration as table level or not .if we define sstable
format like this :
{code:java}
sstable:
selected_format: big
format.options:
- bit-fast:
row_index_granularity: 1kiB
bloom_filter_fp_chance: 0.01
- big-small:
row_index_granularity: 1kiB
bloom_filter_fp_chance: 0.01
{code}
what about change to
{code:java}
sstable:
selected_format: big
format.options:
- bit-fast:
row_index_granularity: 1kiB
table-level:
bloom_filter_fp_chance: 0.01
{code}
{code}
> Move format-specific sstable options into the format configuration
> ------------------------------------------------------------------
>
> Key: CASSANDRA-18533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18533
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema, Local/SSTable
> Reporter: Branimir Lambov
> Assignee: Maxwell Guo
> Priority: Normal
> Fix For: 5.x
>
>
> This mainly concerns cassandra yaml settings:
> - {{column_index_size}}, which should also be renamed to
> {{row_index_granularity}}
> - {{column_index_cache_size}}
> - {{index_summary_capacity}}
> - {{index_summary_resize_interval}}
> and possibly
> - {{key_cache_size}}, {{key_cache_keys_to_save}}, {{key_cache_save_period}},
> {{key_cache_migrate_during_compaction}}
> - {{sstable_preemptive_open_interval}}
> Existing settings should be deprecated but still picked up if defined.
> At this point we will not consider table-level options that make better sense
> as format parameters ({{min/max_index_interval}}, {{bloom_filter_fp_chance}},
> {{crc_check_chance}} and possibly {{compression}}), because we do not yet
> support per-table format selection/configuration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
