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