> 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
