Thanks for the response Aaron.

We do not anticipate more than 10-15 tenants on the cluster. Even if one
does decide to create one KS/tenant, there is the problem of variable loads
on the KS's. I went through this link
http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-improved-memory-and-disk-space-managementwhich
does promise better memory management. I did have two more questions
-
- Was the new memory management written taking into account a situation of
many KS's? (In other words, did multi-tenancy influence the re-design of
memory management?)
- i know that users trying out multi-tenancy are generally recommending not
to create many Ks's/CF's, but i am wondering if there is any documentation
for why this happens or the details on the negative impact on
memory/performance?and are there are any performance benchmarks available
for Cassandra 1.0 clusters with many KS's?


On Wed, Feb 1, 2012 at 12:11 PM, aaron morton <aa...@thelastpickle.com>wrote:

> The existing authentication plug-in does not support row level
> authorization.
>
> You will need to add authentication to your API layer to ensure that a
> request from client X always has the client X key prefix. Or modify
> cassandra to provide row level authentication.
>
> The 1.x Memtable memory management is awesome, but I would still be
> hesitant about creating KS's and CF's at the request of an API client.
>
> Cheers
>
>
> -----------------
> Aaron Morton
> Freelance Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 2/02/2012, at 8:52 AM, Subrahmanya Harve wrote:
>
> > We are using Cassandra 0.8.7 and building a multi-tenant cassandra
> platform
> > where we have a common KS and common CFs for all tenants. By using
> Hector's
> > virtual keyspaces, we are able to add modify rowkeys to have a tenant
> > specific id. (Note that we do not allow tenants to modify/create KS/CF.
> We
> > just allow tenants to write and read data) However we are in the process
> of
> > adding authentication and authorization on top of this platform such that
> > no tenant should be able to retrieve data belonging to any other tenant.
> >
> > By configuring Cassandra for security using the documentation here -
> > http://www.datastax.com/docs/0.8/configuration/authentication , we were
> > able to apply the security constraints on the common keyspace and common
> > CFs. However this does not prevent a tenant from retrieving data
> belonging
> > to another tenant. For this to happen, we would need to have separate CFs
> > and/or keyspaces for each tenant.
> > Looking for more information on the topic here
> >
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Re-Multi-tenancy-and-authentication-and-authorization-td5935230.htmland
> > other places, it looks like the recommendation is "not" to create
> > separate CFs and KSs for every tenant as this would have impacts on
> > Memtables and other memory issues. Does this recommendation still hold
> > good?
> > With jiras like
> > https://issues.apache.org/jira/browse/CASSANDRA-2006resolved, does it
> > mean we can now create multiple (but limited) CFs and KSs?
> > More generally, how do we prevent a tenant from intentional/accidental
> data
> > manipulation of data owned by another tenant? (given that all tenants
> will
> > provide the right credentials)
>
>

Reply via email to