As everyone says, it's not issues with the Keyspace directly as they are just a container. It's the CF's in the keyspace, but let's just say keyspace cause it's easier.
As things stand, if you allow point and click creation for keyspaces you will hand over control of the memory requirements to the users. This will be a bad thing. E.g. Lots of cf's will get created and you will run out of memory, or cf's will get created with huge Memtable settings and you will run out of memory, or caches will get set huge and you get the picture. One badly behaving keyspace or column family can take down a node / cluster. IMHO currently the best way to share a Cassandra cluster is through some sort of application layer that uses as static keyspace. Others have a better understanding of the internals and may have ideas about how this could change in the future. Aaron On 19/01/2011, at 9:07 AM, Ed Anuff <e...@anuff.com> wrote: > 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 > > > > > >
