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