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. > >
