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 >
