You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "ZhaoYang (JIRA)" <ji...@apache.org> on 2016/08/09 14:06:20 UTC

[jira] [Commented] (CASSANDRA-8032) User based request scheduler

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

ZhaoYang commented on CASSANDRA-8032:
-------------------------------------

[~iamaleksey] thanks for the explanation. Cassandra 4.0 is likely to be announced in the end of the 2016, how about multi-tenant feature?

> User based request scheduler
> ----------------------------
>
>                 Key: CASSANDRA-8032
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8032
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: mck
>            Assignee: mck
>            Priority: Minor
>              Labels: patch
>         Attachments: v1-0001-CASSANDRA-8032-User-based-request-scheduler.txt
>
>
> Today only a keyspace based request scheduler exists.
> Post CASSANDRA-4898 it could be possible to implement a request_scheduler based on users (from system_auth.credentials) rather than keyspaces. This could offer a finer granularity of control, from read-only vs read-write users on keyspaces, to application dedicated vs ad-hoc users. Alternatively it could also offer a granularity larger and easier to work with than per keyspace.
> The request scheduler is a useful concept but i think that setups with enough nodes often favour separate clusters rather than either creating separate virtual datacenters or using the request scheduler. To give the request scheduler another, and more flexible, implementation could especially help those users that don't yet have enough nodes to warrant separate clusters, or even separate virtual datacenters. On such smaller clusters cassandra can still be seen as an unstable technology because poor consumers/schemas can easily affect, even bring down, a whole cluster.
> I haven't look into the feasibility of this within the code, but it comes to mind as rather simple, and i would be interested in offering a patch if the idea carries validity.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)