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