My suggestion is simple: don't use any deprecated stuff out there. In
practically any case there is a good reason why it's deprecated.
SuperColumns are not deprecated.
On Sat Jan 7 19:51:55 2012, R. Verlangen wrote:
My suggestion is simple: don't use any deprecated stuff out there. In
practically any case there is a good reason why it's deprecated.
I've seen a couple of composite-column vs supercolumn discussions in
the past weeks here: I think a little bit of searching will get you
around.
Cheers
2012/1/7 Aklin_81 <asdk...@gmail.com <mailto:asdk...@gmail.com>>
I read entire columns inside the supercolumns at any time but as for
writing them, I write the columns at different times. I don't have the
need to update them except that die after their TTL period of 60 days.
But since they are going to be deprecated, I don't know if it would be
really advisable to use them right now.
I believe if it was possible to do wildchard querying for a list of
column names then the supercolumns use cases may be easily replaced by
normal columns. Could it practically possible, in future ?
On Sat, Jan 7, 2012 at 8:05 AM, Terje Marthinussen
<tmarthinus...@gmail.com <mailto:tmarthinus...@gmail.com>> wrote:
> Please realize that I do not make any decisions here and I am
not part of the core Cassandra developer team.
>
> What has been said before is that they will most likely go away
and at least under the hood be replaced by composite columns.
>
> Jonathan have however stated that he would like the supercolumn
API/abstraction to remain at least for backwards compatibility.
>
> Please understand that under the hood, supercolumns are merely
groups of columns serialized as a single block of data.
>
>
> The fact that there is a specialized and hardcoded way to
serialize these column groups into supercolumns is a problem
however and they should probably go away to make space for a more
generic implementation allowing more flexible data structures and
less code specific for one special data structure.
>
> Today there are tons of extra code to deal with the slight
difference in serialization and features of supercolumns vs
columns and hopefully most of that could go away if things got
structured a bit different.
>
> I also hope that we keep APIs to allow simple access to groups
of key/value pairs to simplify application logic as working with
just columns can add a lot of application code which should not be
needed.
>
> If you almost always need all or mostly all of the columns in a
supercolumn, and you normally update all of them at the same time,
they will most likely be faster than normal columns.
>
> Processing wise, you will actually do a bit more work on
serialization/deserialization of SC's but the I/O part will
usually be better grouped/require less operations.
>
> I think we did some benchmarks on some heavy use cases with ~30
small columns per SC some time back and I think we ended up with
SCs being 10-20% faster.
>
>
> Terje
>
> On Jan 5, 2012, at 2:37 PM, Aklin_81 wrote:
>
>> I have seen supercolumns usage been discouraged most of the times.
>> However sometimes the supercolumns seem to fit the scenario most
>> appropriately not only in terms of how the data is stored but
also in
>> terms of how is it retrieved. Some of the queries supported by
SCs are
>> uniquely capable of doing the task which no other alternative
schema
>> could do.(Like recently I asked about getting the equivalent of
>> retrieving a list of (full)supercolumns by name, through use of
>> composite columns, unfortunately there was no way to do this
without
>> reading lots of extra columns).
>>
>> So I am really confused whether:
>>
>> 1. Should I really not use the supercolumns for any case at all,
>> however appropriate, or I just need to be just careful while
realizing
>> that supercolumns fit my use case appropriately or what!?
>>
>> 2. Are there any performance concerns with supercolumns even in the
>> cases where they are used most appropriately. Like when you need to
>> retrieve the entire supercolumns everytime & max. no of subcolumns
>> vary between 0-10.
>> (I don't write all the subcolumns inside supercolumn, at once
though!
>> Does this also matter?)
>>
>> 3. What is their future? Are they going to be deprecated or may be
>> enhanced later?
>
