[ https://issues.apache.org/jira/browse/CASSANDRA-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko updated CASSANDRA-6506: ----------------------------------------- Fix Version/s: (was: 2.1 beta2) 3.0 Anyway, committed the first two, changed fixver to 3.0. > 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)