+1 Are there JIRAs for these requirements? I would like to contribute from my capacity.
As per my understanding, to support some muti-tenant models, it is needed to qualified keyspaces' names, Cfs' names, etc. with the tenant namespace (or id). The easiest way to do this would be to modify corresponding constructs transparently. I tought of a stage (optional and configurable) prior to authorization. Is there any better solutions? I appreciate the community's suggestions. Moreover, It is needed to send the tenant NS(id) with the user credentials (A users belongs to this tenant (org.)). For that purpose, I thought of using the user credentials in the AuthenticationRequest. s there any better solution? I would like to have a MT support at the Cassandra level which is optional and configurable. Thanks, Indika On Wed, Jan 19, 2011 at 7:40 PM, David Boxenhorn <da...@lookin2.com> wrote: > Yes, the way I see it - and it becomes even more necessary for a > multi-tenant configuration - there should be completely separate > configurations for applications and for servers. > > - Application configuration is based on data and usage characteristics of > your application. > - Server configuration is based on the specific hardware limitations of the > server. > > Obviously, server limitations take priority over application configuration. > > > Assuming that each tenant in a multi-tenant environment gets one keyspace, > you would also want to enforce limitations based on keyspace (which > correspond to parameters that the tenant payed for). > > So now we have three levels: > > 1. Server configuration (top priority) > 2. Keyspace configuration (payed-for service - second priority) > 3. Column family configuration (configuration provided by tenant - third > priority) > > > On Wed, Jan 19, 2011 at 3:15 PM, indika kumara <indika.k...@gmail.com>wrote: > >> As the actual problem is mostly related to the number of CFs in the system >> (may be number of the columns), I still believe that supporting exposing the >> Cassandra ‘as-is’ to a tenant is doable and suitable though need some >> fixes. That multi-tenancy model allows a tenant to use the programming >> model of the Cassandra ‘as-is’, enabling the seamless migration of an >> application that uses the Cassandra into the cloud. Moreover, In order to >> support different SLA requirements of different tenants, the configurability >> of keyspaces, cfs, etc., per tenant may be critical. However, there are >> trade-offs among usability, memory consumption, and performance. I believe >> that it is important to consider the SLA requirements of different tenants >> when deciding the strategies for controlling resource consumption. >> >> I like to the idea of system-wide parameters for controlling resource >> usage. I believe that the tenant-specific parameters are equally important. >> There are resources, and each tenant can claim a portion of them based on >> SLA. For instance, if there is a threshold on the number of columns per a >> node, it should be able to decide how many columns a particular tenant can >> have. It allows selecting a suitable Cassandra cluster for a tenant based >> on his or her SLA. I believe the capability to configure resource >> controlling parameters per keyspace would be important to support a keyspace >> per tenant model. Furthermore, In order to maximize the resource sharing >> among tenants, a threshold (on a resource) per keyspace should not be a hard >> limit. Rather, it should be oscillated between a hard minimum and a maximum. >> For example, if a particular tenant needs more resources at a given time, he >> or she should be possible to borrow from the others up to the maximum. The >> threshold is only considered when a tenant is assigned to a cluster - the >> remaining resources of a cluster should be equal or higher than the resource >> limit of the tenant. It may need to spread a single keyspace across multiple >> clusters; especially when there are no enough resources in a single >> cluster. >> >> I believe that it would be better to have a flexibility to change >> seamlessly multi-tenancy implementation models such as the Cassadra ‘as-is’, >> the keyspace per tenant model, a keyspace for all tenants, and so on. Based >> on what I have learnt, each model requires adding tenant id (name space) to >> a keyspace’s name or cf’s name or raw key, or column’s name. Would it be >> better to have a kind of pluggable handler that can access those resources >> prior to doing the actual operation so that the required changes can be >> done? May be prior to authorization. >> >> Thanks, >> >> Indika >> > >
