cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Anuff ...@anuff.com>
Subject Re: Multi-tenancy, and authentication and authorization
Date Tue, 18 Jan 2011 20:07:44 GMT
Hi Jeremy, thanks, I was really coming at it from the question of whether
keyspaces were a functional basis for multitenancy in Cassandra.  I think
the MT issues discussed on the wiki page are the , but I'd like to get a
better understanding of the core issue of keyspaces and then try to get that
onto the page as maybe the first section.

Ed

On Tue, Jan 18, 2011 at 11:42 AM, Jeremy Hanna
<jeremy.hanna1234@gmail.com>wrote:

> 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 list.
>
> 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 <indika.kuma@gmail.com>
> 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
> >
> >
>
>

Mime
View raw message