The GP is right, I started using Cassandra right before they got a hardon for "CQL" and the docs used to explicitly layout the data model when using the thrift interface. (The Thrift data model is basically what you get when you use COMPACT STORAGE, we still using CQL). Simply put, I bet the 30x increase in performance is not because they used COMPACT STORAGE, and is because Map/collections have terrible performance, and COMPACT STORAGE forced them describe the data the "right" way.
Instead of using a map (or COMPACT STORAGE), they should have defined their schema upfront (one of the limitations brought on by not-SQL). However if they didn't want to do that then COMPACT STORAGE is obviously a better solution than using a Map.
To answer your question about COMPACT STORAGE, standard CQL basically does the work for you (in terms of parsing the "xsv") but you have you define the schema upfront (as in, you have know all the map keys before hand). The reason they tell you not to use COMPACT STORAGE is for those cases where you don't need a dynamic schema, using COMPACT STORAGE doesn't really get you anything.
Lastly, IMO, I wouldn't touch CQL Collections or COMPACT STORAGE unless absolutely necessary. If you do need a dynamic schema I would rather encode the data as a msgpack or protobuf blob.
If thats the case, then thats something you should have highlighted that as well. Now that I think about it we decided to store blobs under one column using msgpack for a similar reason (although mine was "we had mongo eat up all our disk space because of field names, so now our code is littered with single character field names"). I've thought about fixing it, but if its the case I guess thats related to CASSANDRA-4175. The map solution makes it come across you weren't quite sure what you were doing.
However, I'm even more surprised at the "slower for queries" part. Maybe I'll do some tests with COMPACT STORAGE.
Might be specific to the Python driver, but it was slower for queries because most of the cputime was being spent decoding column structure/metadata and on type conversions. We also tested msgpack blobs, iirc, but the xsv format was the winner for query perf and for compactness on disk.
Would have gladly gone into more detail, but at 4,000+ words for the blog post already... :)
Hmm, so I tried converting a table we had from a standard table to one with COMPACT STORAGE. The space saving wasn't all that great (100GB -> 80GB), not near 30x.
I stand by my point that the mistake was using CQL maps when you should have just used a defined schema.
Instead of using a map (or COMPACT STORAGE), they should have defined their schema upfront (one of the limitations brought on by not-SQL). However if they didn't want to do that then COMPACT STORAGE is obviously a better solution than using a Map.
To answer your question about COMPACT STORAGE, standard CQL basically does the work for you (in terms of parsing the "xsv") but you have you define the schema upfront (as in, you have know all the map keys before hand). The reason they tell you not to use COMPACT STORAGE is for those cases where you don't need a dynamic schema, using COMPACT STORAGE doesn't really get you anything.
Lastly, IMO, I wouldn't touch CQL Collections or COMPACT STORAGE unless absolutely necessary. If you do need a dynamic schema I would rather encode the data as a msgpack or protobuf blob.