On Fri, Oct 1, 2010 at 5:12 PM, Zhu Han <schumi....@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 >> >
