It's advised you do not use compact storage, as it's primarily for backwards compatibility.
The first of these option is COMPACT STORAGE. This option is meanly targeted towards backward compatibility with some table definition created before CQL3. But it also provides a slightly more compact layout of data on disk, though at the price of flexibility and extensibility, and for that reason is not recommended unless for the backward compatibility reason. On Wed, Jul 31, 2013 at 2:54 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > You should also profile what your data looks like on disk before picking a > format. It may not be as efficient to use one form or the other due to > extra disk overhead. > > > On Wed, Jul 31, 2013 at 1:32 PM, Jon Ribbens < > jon-cassan...@unequivocal.co.uk> wrote: > >> On Wed, Jul 31, 2013 at 02:21:52PM +0200, Alain RODRIGUEZ wrote: >> > I like to point to this article from Sylvain, which is really well >> > written. >> > http://www.datastax.com/dev/blog/thrift-to-cql3 >> >> Ah, thankyou, it looks like a combination of multi-column "PRIMARY KEY" >> and use of collections may well suffice for what I want. I must admit >> that I did not find any of this particularly obvious from the CQL >> documentation. >> >> By the way, http://cassandra.apache.org/doc/cql3/CQL.html#createTableStmt >> says "A table with COMPACT STORAGE must also define at least one >> clustering key", which seems to contradict definition 2 in the >> thrift-to-cql3 document you pointed me to. >> > > -- Jon Haddad http://www.rustyrazorblade.com skype: rustyrazorblade
