cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13279) Table default settings file
Date Wed, 01 Mar 2017 08:53:45 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15889793#comment-15889793
] 

Robert Stupp commented on CASSANDRA-13279:
------------------------------------------

I agree with Sylvain, adding a new config file introduces a lot of issues - e.g. operational:
who or what ensures these files are consistent over all nodes at all times?
I also do not think that introducing a config file that magically changes _documented_ defaults
is a good idea. I am sure that this _will_ confuse users - especially in big teams.

Table parameters are tuned _per table_, which means these need to be tuned per table - not
per coordinator node executing the DDL.

TBH, I do not think that adding another config file or introducing some hard to manage per-node
default values is a good idea.


> Table default settings file
> ---------------------------
>
>                 Key: CASSANDRA-13279
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13279
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Configuration
>            Reporter: Romain Hardouin
>            Priority: Minor
>              Labels: config, documentation
>
> Following CASSANDRA-13241 we often see that there is no one-size-fits-all value for settings.
We can't find a sweet spot for every use cases.
> It's true for settings in cassandra.yaml but as [~brstgt] said for {{chunk_length_in_kb}}:
"this is somewhat hidden for the average user". 
> Many table settings are somewhat hidden for the average user. Some people will think
RTFM but if a file - say tables.yaml - contains default values for table settings, more people
would pay attention to them. And of course this file could contain useful comments and guidance.

> Example with SSTable compression options:
> {code}
> # General comments about sstable compression
> compression:
>     # First of all: explain what is it. We split each SSTable into chunks, etc.
>     # Explain when users should lower this value (e.g. 4) or when a higher value like
64 or 128 are recommended.
>     # Explain the trade-off between read latency and off-heap compression metadata size.
>     chunk_length_in_kb: 16
>     
>     # List of available compressor: LZ4Compressor, SnappyCompressor, and DeflateCompressor
>     # Explain trade-offs, some specific use cases (e.g. archives), etc.
>     class: 'LZ4Compressor'
>     
>     # If you want to disable compression by default, uncomment the following line
>     #enabled: false
> {code}
> So instead of hard coded values we would end up with something like TableConfig + TableDescriptor
à la Config + DatabaseDescriptor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message