Hi Jeremy, thanks, I was really coming at it from the question of whether keyspaces were a functional basis for multitenancy in Cassandra. I think the MT issues discussed on the wiki page are the , but I'd like to get a better understanding of the core issue of keyspaces and then try to get that onto the page as maybe the first section.
Ed On Tue, Jan 18, 2011 at 11:42 AM, Jeremy Hanna <jeremy.hanna1...@gmail.com>wrote: > Feel free to use that wiki page or another wiki page to collaborate on more > pressing multi tenant issues. The wiki is editable by all. The MultiTenant > page was meant as a launching point for tracking progress on things we could > think of wrt MT. > > Obviously the memtable problem is the largest concern at this point. If > you have any ideas wrt that and want to collaborate on how to address that, > perhaps even in a way that would get accepted in core cassandra, feel free > to propose solutions in a jira ticket or on the list. > > A caveat to getting things into core cassandra - make sure anything you do > is considerate of single-tenant cassandra. If possible, make things > pluggable and optional. The round robin request scheduler is an example. > The functionality is there but you have to enable it. If it can't be made > pluggable/optional, you can get good feedback from the community about > proposed solutions in core Cassandra (like for the memtable issue in > particular). > > Anyway, just wanted to chime in with 2 cents about that page (since I > created it and was helping maintain it before getting pulled off onto other > projects). > > On Jan 18, 2011, at 1:12 PM, Ed Anuff wrote: > > > Hi Indika, I've done a lot of work using the keyspace per tenant model, > and I'm seeing big problems with the memory consumption, even though it's > certainly the most clean way to implement it. Luckily, before I used the > keyspace per tenant approach, I'd implemented my system using a single > keyspace approach and can still revert back to that. The rest of the stuff > for multi-tenancy on the wiki is largely irrelevant, but the keyspace issue > is a big concern at the moment. > > > > Ed > > > > On Tue, Jan 18, 2011 at 9:40 AM, indika kumara <indika.k...@gmail.com> > wrote: > > Hi Aaron, > > > > I read some articles about the Cassandra, and now understand a little bit > about trade-offs. > > > > I feel the goal should be to optimize memory as well as performance. I > have to consider the number of column families, the columns per a family, > the number of rows, the memtable’s threshold, and so on. I also have to > consider how to maximize resource sharing among tenants. However, I feel > that a keyspace should be able to be configured based on the tenant’s class > (e.g replication factor). As per some resources, I feel that the issue is > not in the number of keyspaces, but with the number of CF, the number of the > rows in a CF, the numbers of columns, the size of the data in a column, and > so on. Am I correct? I appreciate your opinion. > > > > What would be the suitable approach? A keyspace per tenant (there would > be a limit on the tenants per a Cassandra cluster) or a keyspace for all > tenant. > > > > I still would love to expose the Cassandra ‘as-is’ to a tenant virtually > yet with acceptable memory consumption and performance. > > > > Thanks, > > > > Indika > > > > > >
