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 > > > > > >
