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