Thank you. Is that true for 0.8.7 as well?
On Thu, Feb 2, 2012 at 8:20 AM, Jeremiah Jordan < jeremiah.jor...@morningstar.com> wrote: > 10-15 KS should be fine. The issue is when you want to have hundreds or > thousands of KS/CF. > > -Jeremiah > > -----Original Message----- > From: Subrahmanya Harve [mailto:subrahmanyaha...@gmail.com] > Sent: Thursday, February 02, 2012 1:43 AM > To: dev@cassandra.apache.org > Subject: Re: Queries on AuthN and AuthZ for multi tenant Cassandra > > 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-mem > ory-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-Mult > i-tenancy-and-authentication-and-authorization-td5935230.htmland<http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Re-Mult%0Ai-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) > > > > >
