Re: multitenant support with key spaces
You may want to look at using virtual keyspaces: http://hector-client.github.io/hector/build/html/content/virtual_keyspaces.html And follow these tickets: http://wiki.apache.org/cassandra/MultiTenant -brian On May 6, 2013, at 2:37 AM, Darren Smythe wrote: How many keyspaces can you reasonably have? We have around 500 customers and expect that to double end of year. We're looking into C* and wondering if it makes sense for a separate KS per customer? If we have 1000 customers, so one KS per customer is 1000 keyspaces. Is that something C* can handle efficiently? Each customer has about 10 GB of data (not taking replication into account). Or is this symptomatic of a bad design? I guess the same question applies to our notion of breaking up the column families into time ranges. We're naively trying to avoid having few large CFs/KSs. Is/should that be a concern? What are the tradeoffs of a smaller number of heavyweight KS/CFs vs. manually sharding the data into more granular KSs/CFs? Thanks for any info. -- Brian ONeill Lead Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://weblogs.java.net/blog/boneill42/ blog: http://brianoneill.blogspot.com/
Re: multitenant support with key spaces
On Sun, May 5, 2013 at 11:37 PM, Darren Smythe darren1...@gmail.com wrote: How many keyspaces can you reasonably have? Very Low Hundreds, though this relates more to CFs than Ks. If we have 1000 customers, so one KS per customer is 1000 keyspaces. Is that something C* can handle efficiently? No. I guess the same question applies to our notion of breaking up the column families into time ranges. We're naively trying to avoid having few large CFs/KSs. Is/should that be a concern? Very large rows are significantly worse than very large CFs or KS. =Rob
Re: multitenant support with key spaces
Another option may be virtual column families with PlayOrm. We currently do around 60,000 column families to store data from 60,000 different sensors that keep feeding us information. Dean On 5/6/13 11:18 AM, Robert Coli rc...@eventbrite.com wrote: On Sun, May 5, 2013 at 11:37 PM, Darren Smythe darren1...@gmail.com wrote: How many keyspaces can you reasonably have? Very Low Hundreds, though this relates more to CFs than Ks. If we have 1000 customers, so one KS per customer is 1000 keyspaces. Is that something C* can handle efficiently? No. I guess the same question applies to our notion of breaking up the column families into time ranges. We're naively trying to avoid having few large CFs/KSs. Is/should that be a concern? Very large rows are significantly worse than very large CFs or KS. =Rob
