cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hanna <>
Subject Re: Multi-tenancy, and authentication and authorization
Date Tue, 18 Jan 2011 19:42:25 GMT
Feel free to use that wiki page or another wiki page to collaborate on more pressing multi
tenant issues.  The wiki is editable by all.  The MultiTenant page was meant as a launching
point for tracking progress on things we could think of wrt MT.

Obviously the memtable problem is the largest concern at this point.  If you have any ideas
wrt that and want to collaborate on how to address that, perhaps even in a way that would
get accepted in core cassandra, feel free to propose solutions in a jira ticket or on the

A caveat to getting things into core cassandra - make sure anything you do is considerate
of single-tenant cassandra.  If possible, make things pluggable and optional.  The round robin
request scheduler is an example.  The functionality is there but you have to enable it.  If
it can't be made pluggable/optional, you can get good feedback from the community about proposed
solutions in core Cassandra (like for the memtable issue in particular).

Anyway, just wanted to chime in with 2 cents about that page (since I created it and was helping
maintain it before getting pulled off onto other projects).

On Jan 18, 2011, at 1:12 PM, Ed Anuff wrote:

> Hi Indika, I've done a lot of work using the keyspace per tenant model, and I'm seeing
big problems with the memory consumption, even though it's certainly the most clean way to
implement it.  Luckily, before I used the keyspace per tenant approach, I'd implemented my
system using a single keyspace approach and can still revert back to that.  The rest of the
stuff for multi-tenancy on the wiki is largely irrelevant, but the keyspace issue is a big
concern at the moment.
> Ed
> On Tue, Jan 18, 2011 at 9:40 AM, indika kumara <> wrote:
> Hi Aaron,
> I read some articles about the Cassandra, and now understand a little bit about trade-offs.
> I feel the goal should be to optimize memory as well as performance. I have to consider
the number of column families, the columns per a family, the number of rows, the memtable’s
threshold, and so on. I also have to consider how to maximize resource sharing among tenants.
However, I feel that a keyspace should be able to be configured based on the tenant’s class
(e.g replication factor). As per some resources, I feel that the issue is not in the number
of keyspaces, but with the number of CF, the number of the rows in a CF, the numbers of columns,
the size of the data in a column, and so on. Am I correct? I appreciate your opinion. 
> What would be the suitable approach? A keyspace per tenant (there would be a limit on
the tenants per a Cassandra cluster) or a keyspace for all tenant.
> I still would love to expose the Cassandra ‘as-is’ to a tenant virtually yet with
acceptable memory consumption and performance.
> Thanks,
> Indika

View raw message