I would imagine it to be somewhat easy to implement this via a thrift wrapper so that each tenant is connecting to the proxy thrift server that masks the fact that there are multiple tenants... or is that how people are thinking about this
- Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jan 2011 21:20, "Aaron Morton" <aa...@thelastpickle.com> wrote: > 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 >> > >> > >> >>
