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

Paulo Motta commented on CASSANDRA-17032:
-----------------------------------------

bq. I will point out that the two are not mutually exclusive. Like a compaction 
strategy, you could define it in the schema but also retain the ability to 
change it via JMX.

This. Even though it's still not perfect, our schema metadata broadcast is much 
more reliable now and issues are the exception rather than the rule.

I think we should be making new features easy to use for new users which don't 
have the tooling available, and optionally have a JMX safety valve for advanced 
users to deal with the hairy edge cases.

> Allow configuring max allowable disk usage quota by keyspace
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-17032
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17032
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local/Other
>            Reporter: Josh McKenzie
>            Assignee: Josh McKenzie
>            Priority: Normal
>
> This is a similar idea (basically identical idea; didn't want to steamroll 
> that old ticket w/an update to description etc) to what was raised and closed 
> in CASSANDRA-5394. In multi-tenant situations it can be very helpful to 
> provide disk quotas per Keyspaces for users.
> We can do this via a low priority background job that periodically checks 
> disk usage and flips a bit on the Keyspaces when it's over as well as reverts 
> it when things settle back down to prevent needing the read-before-write a 
> hard realtime requirement would introduce. While this would of course allow 
> users to "burst" their usage past that limit in the time window, it would 
> still be sufficient for many use-cases.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to