I ask myself this every day. CQL3 is "new way" to do things, including wide rows with collections. There is no "upgrade path". You adopt CQL3's sparse tables as soon as you start creating column families from CQL. There is not much backwards compatibility. CQL3 can query compact tables, but you may have to remove the metadata from them so they can be transposed. Thrift can not write into CQL tables easily, because of how the primary keys and column names are encoded into the key column and compact metadata is not equal to cql3's metadata.
http://www.datastax.com/dev/blog/thrift-to-cql3 For a large swath of problems I like how CQL3 deals with them. For example you do not really need CQL3 to store a collection in a column family along side other data. You can use wide rows for this, but the integrated solution with CQL3 metadata is interesting. My biggest beefs are: 1) column names are UTF8 (seems wasteful in most cases) 2) sparse empty row to ghost (seems like tiny rows with one column have much overhead now) 3) using composites (with (compound primary keys) in some table designs) is wasteful. Composite adds two unsigned bytes for size and one unsigned byte as 0 per part. 4) many lines of code between user/request and actual disk. (tracing a CQL select VS a slice, young gen, etc) 5) not sure if "collections" can be used in REALLY wide row scenarios. aka 1,000,000 entry set? I feel that in an effort to be nube friendly, sparse+CQL is presented as the best default option. However the 5 above items are not minor, and in several use cases could make CQL's sparse tables a bad choice for certain applications. Those users would get better performance from compact storage. I feel that message sometimes gets washed away in all the CQL coolness. "What is that you say? This is not actually the most efficient way to store this data? Well who cares I can do an IN CLAUSE! WooHoo!" On Wed, Jan 9, 2013 at 12:10 PM, Ben Hood <0x6e6...@gmail.com> wrote: > I'm currently in the process of porting my app from Thrift to CQL3 and it > seems to me that the underlying storage layout hasn't really changed > fundamentally. The difference appears to be that CQL3 offers a neater > abstraction on top of the wide row format. For example, in CQL3, your query > results are bound to a specific schema, so you get named columns back - > previously you had to process the slices procedurally. The insert path > appears to be tighter as well - you don't seem to get away with leaving out > key attributes. > > I'm sure somebody more knowledgeable can explain this better though. > > Cheers, > > Ben > > > On Wed, Jan 9, 2013 at 4:51 PM, mrevilgnome <mrevilgn...@gmail.com> wrote: > >> We use the thrift bindings for our current production cluster, so I >> haven't been tracking the developments regarding CQL3. I just discovered >> when speaking to another potential DSE customer that wide rows, or rather >> columns not defined in the metadata aren't supported in CQL 3. >> >> I'm curious to understand the reasoning behind this, whether this is an >> intentional direction shift away from the big table paradigm, and what's >> supposed to happen to those of us who have already bought into >> C* specifically because of the wide row support. What is our upgrade path? >> > >
