>> - Use a keyspace per customer > These effectively amount to the same thing and they both fall foul to the > limit in the number of column families so do not scale.
But then you can scale by moving some of the customers to a new cluster easily. If you keep everything in a single keyspace or - worse - if you do your multitenancy by prefixing row keys with customer ids of some kind, it won't be that easy, as you wrote later in your e-mail. M. Kind regards, Michał Michalski, michal.michal...@boxever.com On 5 August 2014 12:36, Phil Luckhurst <phil.luckhu...@powerassure.com> wrote: > Hi Mark, > > Mark Reddy wrote > > To segregate customer data, you could: > > - Use customer specific column families under a single keyspace > > - Use a keyspace per customer > > These effectively amount to the same thing and they both fall foul to the > limit in the number of column families so do not scale. > > > Mark Reddy wrote > > - Use the same column families and have a column that identifies the > > customer. On the application layer ensure that there are sufficient > checks > > so one customer can't read another customers data > > And while this gets around the column family limit it does not allow the > same level of data segregation. For example with a separate keyspace or > column families it is trivial to remove a single customer's data or move > that data to another system. With one set of column families for all > customers these types of actions become much more difficult as any change > impacts all customers but perhaps that's the price we have to pay to scale. > > And I still think this needs to be made more prominent in the > documentation. > > Thanks > Phil > > > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Reasonable-range-for-the-max-number-of-tables-tp7596094p7596119.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
