has there been any recent discussion on multitenancy namespaces ?  I think
this would effectively solve the scenario -- a formalized partition-key
that's enforced at the storage layer, similar to oracle's virtual private
database

it was on the wiki from ~ Aug 2010

http://wiki.apache.org/cassandra/MultiTenant
>>>>
Namespaces - in a multi-tenant use case, each user might like to have a
keyspace XYZ for whatever reason. So it might be nice to have namespaces so
that keyspace XYZ could be specific to their user. Ideally this would be an
option that would not affect those that don't use namespaces.

   - The distinction from keyspaces is that a namespace would be completely
   transparent to the user: the existence of namespaces would not be exposed.
   It might be returned by the authentication backend on login, and prefixed
   to keyspaces transparently.

<<<<

thanks !!!


On Sat, Dec 6, 2014 at 11:25 PM, Jason Wee <peich...@gmail.com> wrote:

> +1 well said Jack!
>
> On Sun, Dec 7, 2014 at 6:13 AM, Jack Krupansky <j...@basetechnology.com>
> wrote:
>
>>   Generally, limit a Cassandra cluster low hundreds of tables,
>> regardless of number of keyspaces. Beyond low hundreds is certainly an
>> “expert” feature and requires great care. Sure, maybe you can have 500 or
>> 750 or maybe even 1,000 tables in a cluster, but don’t be surprised if you
>> start running into memory and performance issues.
>>
>> There is an undocumented method to reduce the table overhead to support
>> more tables, but... if you are not expert enough to find it on your own,
>> then you are definitely not expert enough to be using it.
>>
>> -- Jack Krupansky
>>
>>  *From:* Raj N <raj.cassan...@gmail.com>
>> *Sent:* Tuesday, November 25, 2014 12:07 PM
>> *To:* user@cassandra.apache.org
>> *Subject:* Keyspace and table/cf limits
>>
>>  What's the latest on the maximum number of keyspaces and/or tables that
>> one can have in Cassandra 2.1.x?
>>
>> -Raj
>>
>
>


-- 
Frank Hsueh | frank.hs...@gmail.com

Reply via email to