On Sat, Dec 6, 2014 at 11:22 AM, Eric Stevens <migh...@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 <dep...@gmail.com> wrote: > >> On Fri, Dec 5, 2014 at 4:32 PM, Robert Coli <rc...@eventbrite.com> wrote: >> >>> On Wed, Dec 3, 2014 at 1:54 PM, Raj N <raj.cassan...@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.
