[
https://issues.apache.org/jira/browse/CASSANDRA-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940643#comment-13940643
]
Aleksey Yeschenko commented on CASSANDRA-6506:
----------------------------------------------
bq. I'm also uncomfortable with originalType() (and enableCounters() to some
extend). It feels pretty error prone as you need to think hard about whether
you you call that first before calling some other method or not. It feels to me
that again, we shouldn't need anything special with CellNameType for counters:
thrift/CQL should convert things to/from the "internal" format, but as far as
CellName/CellNameType are concerned, we shouldn't need anything special casing
at all (I do understand that we probably need to start storing whether the
table is dense or not in the system table for thrift to convert things
properly, but it's high time we do that anyway).
Mostly, they are there indeed to be able to distinguish between the original
comparator being CompositeType(UTF8Type) and just UTF8Type, for example. With
CASSANDRA-6717 this should become a non-issue, but that's 3.0, and we can
always get rid of originalType() and enableCounters() later.
bq. Also, tbh, I'm starting to wonder if 2.1 is such a reasonable target for
this at this point. Especially given we can't get rid of CounterCell right now
(I think we should seriously consider getting rid of local/remote shard for
3.0) this feels like a lot of changes to push at the last minute, and it
doesn't felt like it brings so much to the table that it can't wait 3.0.
Especially since in 3.0 it might be achievable to get rid of CounterCell once
and for all (and we wouldn't have to care about CQL2).
Maybe. I wanted this in 2.1 to sweeten the upgrade to new counters by improving
performance where we can (see the last set two sets of graphs in
CASSANDRA-6553, where 6556 writes are a lot smoother than writes w/out them).
That and getting rid of CASSANDRA-6405 for good. Current reconcile code should
die, really.
bq. I think we should seriously consider getting rid of local/remote shard for
3.0
We should, but I seriously don't see how this could be accomplished - hence not
holding my breath for implementing counters as maps, for example.
bq. I believe disallowing the drop of columns for CQL3 counter tables is a
regression. Not sure why the patch does it tbh.
That's because using the timestamp field for the logical clock breaks the
re-adding of previously dropped counter cells.
> counters++ split counter context shards into separate cells
> -----------------------------------------------------------
>
> Key: CASSANDRA-6506
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6506
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 2.1 beta2
>
>
> This change is related to, but somewhat orthogonal to CASSANDRA-6504.
> Currently all the shard tuples for a given counter cell are packed, in sorted
> order, in one binary blob. Thus reconciling N counter cells requires
> allocating a new byte buffer capable of holding the union of the two
> context's shards N-1 times.
> For writes, in post CASSANDRA-6504 world, it also means reading more data
> than we have to (the complete context, when all we need is the local node's
> global shard).
> Splitting the context into separate cells, one cell per shard, will help to
> improve this. We did a similar thing with super columns for CASSANDRA-3237.
> Incidentally, doing this split is now possible thanks to CASSANDRA-3237.
> Doing this would also simplify counter reconciliation logic. Getting rid of
> old contexts altogether can be done trivially with upgradesstables.
> In fact, we should be able to put the logical clock into the cell's
> timestamp, and use regular Cell-s and regular Cell reconcile() logic for the
> shards, especially once we get rid of the local/remote shards some time in
> the future (until then we still have to differentiate between
> global/remote/local shards and their priority rules).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
