incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@yakaz.com>
Subject Re: [DISCUSSION] High-volume counters in Cassandra
Date Fri, 01 Oct 2010 15:24:47 GMT
On Fri, Oct 1, 2010 at 5:12 PM, Zhu Han <schumi.han@gmail.com> wrote:
>> They have however at least one advantage:
>>  - your super columns are indexed, you don't have to deserialize them
>>    entirely each time.
>>
>
> The  size of counter super column is limited to how many replicas propagated
> values as the lead replica.  It's size is upper bounded by the number of
> replicas.  Even if we support hinted hand off of counters, the size of super
> columns just equals to the size of nodes in the cluster, as the worse case.

I wasn't clear, sorry. What I was saying is that if you encode superColumns
using a standard CF (by projecting), then, when you want to request the
subcolumns of a given super column in the encoding, this amount to requesting
a slice of standard columns, so you only deserialize the requested columns.
While if you use true super columns, not encoded ones, you're subject to the
limitation of super columns not being indexed.

I was not talking about the superColumns holding the counters (my previous
mail is not specific at all to counters).

That being said, everything you said is true. For counters, the super columns
limitations are not a problem at all.

>
>
> IMHO, it's not a big deal to de-serialize them entirely, the can fit into
> memory very easily. Did I miss anything here?
>
> One advantage of implementing counter as a new CF type:
> --you can add some counter specific configuration very easily.
>
> best regards,
> hanzhu
>
> To sum up, I can see the following drawbacks to such encoding:
>>  - querying SC by names is less efficient.
>>  - it takes more disk space (but that's the cheapest resource we have
>> isn't it).
>>
>> I'd say these are fair compromises.
>>
>> --
>> Sylvain
>>
>

Mime
View raw message