Hi Aaron, I appreciate your help. I am a newbie to Cassandra - just began to study the code-base.
Do you suggest the following approach? *1) No changes are in either keyspace names or column family names but the row-key would be ‘the actual row key’ + 'tenant ID'. It is needed to keep separate mappings for keyspace vs tenants and column family vs tenants (can be a form of authorization).* 2) *keep a keyspace per tenant yet expose virtually as many keyspaces.* 3)* A single keyspace for all tenant * What do you mean by 'use namespaces in the keys'? Can a key be an QName? Thanks, Indika On Tue, Jan 18, 2011 at 5:26 PM, indika kumara <indika.k...@gmail.com>wrote: > Moving to user list > > > On Tue, Jan 18, 2011 at 4:05 PM, Aaron Morton <aa...@thelastpickle.com>wrote: > >> Have a read about JVM heap sizing here >> http://wiki.apache.org/cassandra/MemtableThresholds >> >> If you let people create keyspaces with a mouse click you will soon run >> out of memory. >> >> I use Cassandra to provide a self service "storage service" at my >> organization. All virtual databases operate in the same Cassandra keyspace >> (which does not change), and I use namespaces in the keys to separate >> things. Take a look at how amazon S3 works, it may give you some ideas. >> >> If you want to continue to discussion let's move this to the user list. >> >> A >> >> >> On 17/01/2011, at 7:44 PM, indika kumara <indika.k...@gmail.com> wrote: >> >> > Hi Stu, >> > >> > In our app, we would like to offer cassandra 'as-is' to tenants. It >> that >> > case, each tenant should be able to create Keyspaces as needed. Based on >> the >> > authorization, I expect to implement it. In my view, the implementation >> > options are as follows. >> > >> > 1) The name of a keyspace would be 'the actual keyspace name' + 'tenant >> ID' >> > >> > 2) The name of a keyspace would not be changed, but the name of a column >> > family would be the 'the actual column family name' + 'tenant ID'. It >> is >> > needed to keep a separate mapping for keyspace vs tenants. >> > >> > 3) The name of a keypace or a column family would not be changed, but >> the >> > name of a column would be 'the actual column name' + 'tenant ID'. It is >> > needed to keep separate mappings for keyspace vs tenants and column >> family >> > vs tenants >> > >> > Could you please give your opinions on the above three options? if >> there >> > are any issue regarding above approaches and if those issues can be >> solved, >> > I would love to contribute on that. >> > >> > Thanks, >> > >> > Indika >> > >> > >> > On Fri, Jan 7, 2011 at 11:22 AM, Stu Hood <stuh...@gmail.com> wrote: >> > >> >>> (1) has the problem of multiple memtables (a large amount just isn't >> >> viable >> >> There are some very straightforward solutions to this particular >> problem: I >> >> wouldn't rule out running with a very large number of >> >> keyspace/columnfamilies given some minor changes. >> >> >> >> As Brandon said, some of the folks that were working on multi-tenancy >> for >> >> Cassandra are no longer focused on it. But the code that was generated >> >> during our efforts is very much available, and is unlikely to have gone >> >> stale. Would love to talk about this with you. >> >> >> >> Thanks, >> >> Stu >> >> >> >> On Thu, Jan 6, 2011 at 8:08 PM, indika kumara <indika.k...@gmail.com> >> >> wrote: >> >> >> >>> Thank you very much Brandon! >> >>> >> >>> On Fri, Jan 7, 2011 at 12:40 AM, Brandon Williams <dri...@gmail.com> >> >>> wrote: >> >>> >> >>>> On Thu, Jan 6, 2011 at 12:33 PM, indika kumara < >> indika.k...@gmail.com >> >>>>> wrote: >> >>>> >> >>>>> Hi Brandon, >> >>>>> >> >>>>> I would like you feedback on my two ideas for implementing mufti >> >>> tenancy >> >>>>> with the existing implementation. Would those be possible to >> >>> implement? >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> Indika >> >>>>> >> >>>>>>>>>> Two vague ideas: (1) qualified keyspaces (by the tenet domain) >> >>> (2) >> >>>>> multiple Cassandra storage configurations in a single node (one per >> >>>>> tenant). >> >>>>> For both options, the resource hierarchy would be /cassandra/ >> >>>>> <cluster_name>/<tenant name (domain)>/keyspaces/<ks_name>/ >> >>>>> >> >>>> >> >>>> (1) has the problem of multiple memtables (a large amount just isn't >> >>> viable >> >>>> right now.) (2) more or less has the same problem, but in JVM >> >> instances. >> >>>> >> >>>> I would suggest a) not trying to offer cassandra itself, and instead >> >>> build >> >>>> a >> >>>> service that uses cassandra under the hood, and b) splitting up >> tenants >> >>> in >> >>>> this layer. >> >>>> >> >>>> -Brandon >> >>>> >> >>> >> >> >> > >
