cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Kibardin <>
Subject Re: Once again, super columns or composites?
Date Thu, 27 Sep 2012 21:47:34 GMT
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!

On Thu, Sep 27, 2012 at 2:02 PM, Sylvain Lebresne <>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

View raw message