Oh... Sylvain, thanks a lot for such a complete answer. Yeah, I understand my mistake in suggestions regarding composites. It seems, composites are pretty much an advanced version of key manual joining into a string column name: <key1>:<key2>
Thanks a lot! Ed On Thu, Sep 27, 2012 at 2:02 PM, Sylvain Lebresne <sylv...@datastax.com>wrote: > > But from my understanding, you just can't update composite column, only > > delete and insert... so this may make my update use case much more > > complicated. > > Let me try to sum things up. > In regular column families, a column (value) is defined by 2 keys: the > row key and the column name. > In super column families, a column (value) is defined by 3 keys: the > row key, the super column name and the column name. > > So a super column is really just the set of columns that share the > same (row key, super column name) pair. > > The idea of composite columns is to use regular columns, but simply to > distinguish multiple parts of the column name. So now if you take the > example of a CompositeType with 2 components. In that column family: > a column (value) is defined by 3 keys: the row key, the first > component of the column name and the second component of the column > name. > > In other words, composites are a *generalization* of super columns and > super columns are the case of composites with 2 components. Except > that super columns are hard-wired in the cassandra code base in a way > that come with a number of limitation, the main one being that we > always deserialize a super column (again, which is just a set of > columns) in its entirety when we read it from disk. > > So no, it's not true that " you just can't update composite column, > only delete and insert" nor that it is "not possible to add any > sub-column to your composite". > > That being said, if you are using the thrift interface, super columns > do have a few perks currently: > - the grouping of all the sub-columns composing a super columns is > hard-wired in Cassandra. The equivalent for composites, which consists > in grouping all columns having the same value for a given component, > must be done client side. Maybe some client library do that for you > but I'm not sure (I don't know for Pycassa for instance). > - there is a few queries that can be easily done with super columns > that don't translate easily to composites, namely deleting whole super > columns and to a less extend querying multiple super columns by name. > That's due to a few limitations that upcoming versions of Cassandra > will solve but it's not the case with currently released versions. > > The bottom line is: if you can do without those few perks, then you'd > better use composites since they have less limitations. If you can't > really do without these perks and can live with the super columns > limitations, then go on, use super columns. (And if you want the perks > without the limitations, wait for Cassandra 1.2 and use CQL3 :D) > > > > ... and as I know, DynamicComposites is not recommended (and actually not > > supported by Pycassa). > > DynamicComposites don't do what you think they do. They do nothing > more than "regular" composite as far as comparing them to SuperColumns > is concerned, except giving you ways to shoot yourself in the foot. > > -- > Sylvain >
