The main issue with replacing super columns with composite columns right
now is that if you don't know all your sub-column names you can't select
multiple "super columns" worth of data in the same query without getting
extra stuff. You have to use a slice to get all subcolumns of a given
super column, and you can't have disjoint slices, so if you want two
super columns full, you have to get all the other stuff that is in
between them, or make two queries.
If you know what all of the sub-column names are you can ask for all of
the super/sub column pairs for all of the super columns you want and not
get extra data.
If you don't need to pull multiple super columns at a time with slices
like that, then there isn't really an issue.
A bonus of using composite keys like this, is that if there is a
specific sub column you want from multiple super columns, you can pull
all those out with a single multiget and you don't have to pull the rest
of the columns...
So there are pros and cons...
-Jeremiah
On 01/03/2012 01:58 PM, Asil Klin wrote:
I have a super columns family which I always use to retrieve a list of
supercolumns(with all subcolumns) by name. I am looking forward to
replace all SuperColumns in my schema with the composite columns.
How could I design schema so that I could do the equivalent
of retrieving a list of supercolumns by name, in case of using
composite columns.
(As of now I thought of using the supercolumn name as the first
component of the composite name and the subcolumn name as 2nd
component of composite name.)
