[
https://issues.apache.org/jira/browse/CASSANDRA-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159617#comment-14159617
]
mck commented on CASSANDRA-8032:
--------------------------------
{quote}AFAIK this feature isn't really being used by people.{quote}
Then i agree the right decision sounds like to remove it altogether.
I'm definitely not interested in providing a patch that isn't inline with
future plans for multitenancy :-)
Is the removal of thrift definite for cassandra-3.0 ? if so i'd be happy to
provide the simple patch that removes the request_scheduler altogether.
Ok, then everything below is just for clarity's sake…
{quote}"finer granularity of control, from read-only vs read-write users on
keyspaces" … Using it for "virtual datacenter" bulding would be a hack…{quote}
No no, I didn't mean the control of reads vs writes, but rather just the
scheduler being more flexible by being based upon either user or keyspace.
{quote}… and on its own it's not enough to support true multitenancy…{quote}
This came up for us recently because another c* user recommended using separate
clusters per application domain.
And given that it's a) all too easy for one keyspace to bring down the whole
cluster, and b) the difficulty around upgrading c* when it comes to the matrix
of testing required between keyspaces, use-cases, and all the different clients
in use, (not to mention potential bugs popping up during the actual rolling
upgrade process), the idea of using separate clusters certainly carries a lot
of weight.
But the problem is that, apart from not working with the theoretical ability of
C* in that it can provide the same isolation with just separate
virtual-datacenters, i reckon this can cause a hurdle for the adoption of C*.
When people are trying out C* if such robustness can only be provided given
enough nodes to warrant separate clusters you are going to discourage them,
people naturally believe in the robustness they experience, rather than what
you promise them. Put this up against the the current trend of microservices
and devOps-within-each-team, if the cost to each team to use C* each time is 3
new stand-alone nodes, it isn't a cost-effective solution.
Having to go for separate clusters to achieve this "robustness" also doesn't
sell to the analytics advantages of C* – having your analytics in a separate
virtual-dc is a really sweet feature, whenever you want to do analytics on
something new just add a replica of it into the analytics dc, wait for the
streaming to finish, and bang you're off and running… not so easy with separate
clusters.
{quote}…you need better resource isolation/usage limits support, deep and on
all levels, to make that happen.{quote}
And indeed that was my next improvement to file (and look into providing a
patch for), at a minimum i believe one does need to bring compaction into the
scheduler.
I think this could provide a welcome start to multitenancy suitable for
microservices-based enterprises, and a robustness and isolation for smaller
users that don't yet have enough traffic to warrant separate clusters for each
keyspace.
Rather long-winded, and just my 2¢ and one user's perspective, but i hope at
least i've explained it well enough that it's understood. Maybe i can build
some community support for multitenancy in the CQL world… and maybe there's
smarter ways of achieving it than the previous request_scheduler approach…
> User based request scheduler
> ----------------------------
>
> Key: CASSANDRA-8032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8032
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> 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)
