cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Wang <dep...@gmail.com>
Subject Re: Keyspace and table/cf limits
Date Sat, 06 Dec 2014 21:15:14 GMT
On Sat, Dec 6, 2014 at 11:22 AM, Eric Stevens <mightye@gmail.com> wrote:

> Based on recent conversations with Datastax engineers, the recommendation
> is definitely still to run a finite and reasonable set of column families.
>
> The best way I know of to support multitenancy is to include tenant id in
> all of your partition keys.
>
> On Fri Dec 05 2014 at 7:39:47 PM Kai Wang <depend@gmail.com> wrote:
>
>> On Fri, Dec 5, 2014 at 4:32 PM, Robert Coli <rcoli@eventbrite.com> wrote:
>>
>>> On Wed, Dec 3, 2014 at 1:54 PM, Raj N <raj.cassandra@gmail.com> wrote:
>>>
>>>> The question is more from a multi-tenancy point of view. We wanted to
>>>> see if we can have a keyspace per client. Each keyspace may have 50 column
>>>> families, but if we have 200 clients, that would be 10,000 column families.
>>>> Do you think that's reasonable to support? I know that key cache capacity
>>>> is reserved in heap still. Any plans to move it off-heap?
>>>>
>>>
>>> That's an order of magnitude more CFs than I would want to try to
>>> operate.
>>>
>>> But then, I wouldn't want to operate Cassandra multi-tenant AT ALL, so
>>> grain of salt.
>>>
>>> =Rob
>>> http://twitter.com/rcolidba
>>>
>>>
>> I don't know if it's still true but Jonathan Ellis wrote in an old post
>> saying there's a fixed overhead per cf. Here is the link.
>> http://dba.stackexchange.com/a/12413. Even if it's improved since C*
>> 1.0, I still don't feel comfortable to scale my system by creating CFs.
>>
>>
I agree with Eric on encoding tenant id into the partition key. It seems OP
wants to use keyspace to achieve client isolation. But I think multitenancy
is too high level as a feature to be put into the database layer. It's
better handled by the application IMO.

Mime
View raw message