[ https://issues.apache.org/jira/browse/CASSANDRA-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008738#comment-14008738 ]
Aleksey Yeschenko commented on CASSANDRA-6506: ---------------------------------------------- [~aabbeell] this has been explored before. See the comments for CASSANDRA-4775 (TL;DR - it's not going to happen, for multiple serious reasons). > 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: 3.0 > > > 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)