[ 
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579092#comment-13579092
 ] 

Jonathan Halliday commented on CASSANDRA-4775:
----------------------------------------------

> Not sure we'd want to support avg (since it requires extra information to be 
> stored, as you point out), but it would be easy to support some kind of 
> reduce(Iterable<Column> with any scheme that stores per-column updates.

On reflection I don't think the extra data is really the problem. It's how to 
present that data at the client that's tricky.  Supporting a configurable 
reducer for merging old+new local values and local+remote values is only one of 
the ways that 'counters' can be made more flexible. By also making the datatype 
of the column that reducer operates on a pluggable option you can achieve a 
variety of additional behaviours.  The existing counters become essentially  
ReducibleThing<bigint,IntegerAdditionReducer>  whilst HyperLogLog may use  
ReducibleThing<bitset,BitwiseLogicalANDReducer>  and the most general case is 
ReducibleThing<blob,UserDefinedReducer> which would allow for custom 'merge / 
conflict resolution' policies. In this model the implementation of avg would be 
ReducibleThing<CompositeType(bigint:sum,bigint:count),TwoFieldIntegerAdditionReducer>
 which does the right thing on the server, but leaves the client having to 
manage the composite and calculate the average as sum/count rather than being 
handed the single value directly.
                
> Counters 2.0
> ------------
>
>                 Key: CASSANDRA-4775
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Arya Goudarzi
>              Labels: counters
>             Fix For: 2.0
>
>
> The existing partitioned counters remain a source of frustration for most 
> users almost two years after being introduced.  The remaining problems are 
> inherent in the design, not something that can be fixed given enough 
> time/eyeballs.
> Ideally a solution would give us
> - similar performance
> - less special cases in the code
> - potential for a retry mechanism

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to