I have added my comments to this issue: https://issues.apache.org/jira/browse/CASSANDRA-2006
Good luck! On Thu, Jan 20, 2011 at 1:53 PM, indika kumara <indika.k...@gmail.com>wrote: > Thanks David.... We decided to do it at our client-side as the initial > implementation. I will investigate the approaches for supporting the fine > grained control of the resources consumed by a sever, tenant, and CF. > > Thanks, > > Indika > > On Thu, Jan 20, 2011 at 3:20 PM, David Boxenhorn <da...@lookin2.com>wrote: > >> As far as I can tell, if Cassandra supports three levels of configuration >> (server, keyspace, column family) we can support multi-tenancy. It is >> trivial to give each tenant their own keyspace (e.g. just use the tenant's >> id as the keyspace name) and let them go wild. (Any out-of-bounds behavior >> on the CF level will be stopped at the keyspace and server level before >> doing any damage.) >> >> I don't think Cassandra needs to know about end-users. From Cassandra's >> point of view the tenant is the user. >> >> On Thu, Jan 20, 2011 at 7:00 AM, indika kumara <indika.k...@gmail.com>wrote: >> >>> +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 >>>>> >>>> >>>> >>> >> >
