This strikes me as bad practice in the world of multi tenant systems. I don't want to create a table per customer. So I'm wondering if dynamically modifying the table is an accepted practice? --> Can you give some details about your use case ? How would you "alter" a table structure to adapt it to a new customer ?
Wouldn't it be better to model your table so that it supports addition/removal of customer ? On Fri, Jun 13, 2014 at 9:00 PM, Mark Greene <green...@gmail.com> wrote: > Thanks DuyHai, > > I have a follow up question to #2. You mentioned ideally I would create a > new table instead of mutating an existing one. > > This strikes me as bad practice in the world of multi tenant systems. I > don't want to create a table per customer. So I'm wondering if dynamically > modifying the table is an accepted practice? > > -- > about.me <http://about.me/markgreene> > > > On Fri, Jun 13, 2014 at 2:54 PM, DuyHai Doan <doanduy...@gmail.com> wrote: > >> Hello Mark >> >> Dynamic columns, as you said, are perfectly supported by CQL3 via >> clustering columns. And no, using collections for storing dynamic data is a >> very bad idea if the cardinality is very high (>> 1000 elements) >> >> 1) Is using Thrift a valid approach in the era of CQL? --> Less and >> less. Unless you are looking for extreme performance, you'd better off >> choosing CQL3. The ease of programming and querying with CQL3 does worth >> the small overhead in CPU >> >> 2) If CQL is the best practice, should I alter the schema at runtime >> when I detect I need to do an schema mutation? --> Ideally you should not >> alter schema but create a new table to adapt to your changing requirements. >> >> 3) If I utilize CQL collections, will Cassandra page the entire thing >> into the heap? --> Of course. All collections and maps in Cassandra are >> eagerly loaded entirely in memory on server side. That's why it is >> recommended to limit their cardinality to ~ 1000 elements >> >> >> >> >> On Fri, Jun 13, 2014 at 8:33 PM, Mark Greene <green...@gmail.com> wrote: >> >>> I'm looking for some best practices w/r/t supporting arbitrary columns. >>> It seems from the docs I've read around CQL that they are supported in some >>> capacity via collections but you can't exceed 64K in size. For my >>> requirements that would cause problems. >>> >>> So my questions are: >>> >>> 1) Is using Thrift a valid approach in the era of CQL? >>> >>> 2) If CQL is the best practice, should I alter the schema at runtime >>> when I detect I need to do an schema mutation? >>> >>> 3) If I utilize CQL collections, will Cassandra page the entire thing >>> into the heap? >>> >>> My data model is akin to a CRM, arbitrary column definitions per >>> customer. >>> >>> >>> Cheers, >>> Mark >>> >> >> >
