cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (Jira)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-15074) Allow table property defaults (e.g. compaction, compression) to be specified for a cluster/keyspace
Date Mon, 11 Nov 2019 16:21:00 GMT

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

Aleksey Yeschenko commented on CASSANDRA-15074:
-----------------------------------------------

Sounds like a good idea to me. And not that hard to implement either. Would need to make some
changes to params to only persist explicit values in the template tables, and would have to
think about how we want to handle authz, but it's definitely both valuable and doable.

> Allow table property defaults (e.g. compaction, compression) to be specified for a cluster/keyspace
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-15074
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15074
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Cluster/Schema
>            Reporter: Joey Lynch
>            Priority: Low
>             Fix For: 4.x
>
>
> During an IRC discussion in [cassandra-dev|https://wilderness.apache.org/channels/?f=cassandra-dev/2019-04-02#1554224083]
it was proposed that we could have table property defaults stored on a Keyspace or globally
within the cluster. For example, this would allow users to specify "All new tables on this
cluster should default to LCS with SSTable size of 320MiB" or "all new tables in Keyspace
XYZ should have Zstd commpression with a 8 KiB block size" or "default_time_to_live should
default to 3 days" etc ... This way operators can choose the default that makes sense for
their organization once (e.g. LCS if they are running on fast SSDs), rather than requiring
developers creating the Keyspaces/Tables to make the decision on every creation (often without
context of which choices are right).
> A few implementation options were discussed including:
>  * A YAML option
>  * Schema provided at the Keyspace level that would be inherited by any tables automatically
>  * Schema provided at the Cluster level that would be inherited by any Keyspaces or Tables
automatically
> In IRC it appears that rough consensus was found in having global -> keyspace ->
table defaults which would be stored in schema (no YAML configuration since this isn't node
level really, it's a cluster level config).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message