Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "Counters" page has been changed by SylvainLebresne. http://wiki.apache.org/cassandra/Counters?action=diff&rev1=9&rev2=10 -------------------------------------------------- == Interface == The interface follows the main API. The main differences are: - * CounterColumn requires an i64 value and no timestamp, and + * CounterColumn requires an i64 value (can be negative) and no timestamp, and - * CounterDeletion does not take a timestamp. + * Deletion, when used on a counter column family, does not use a timestamp. Internally, the data store generates timestamps on the server to determine priority of deletion. + The new structures for dealing with counters are: {{{ struct CounterColumn { 1: required binary name, @@ -53, +54 @@ 1: required binary name, 2: required list<CounterColumn> columns } - }}} - {{{ struct Counter { 1: optional CounterColumn column, 2: optional CounterSuperColumn super_column } + }}} + Moreover, as mentioned previously, then timestamp field of Deletion is now optional (but + remain mandatory for non counter column family operation). + The Mutation has also been updated with a new `counter` field for batch increment/decrement. - struct CounterDeletion { - 1: optional binary super_column, - 2: optional SlicePredicate predicate, - } + The counter operation comprise `batch_mutate` and the following new operations: - /** - A CounterMutation is either an insert, represented by filling counter, or a deletion, represented by filling the deletion attribute. - @param counter. An insert to a counter column or supercolumn - @param deletion. A deletion of a counter column or supercolumn - */ - struct CounterMutation { - 1: optional Counter counter, - 2: optional CounterDeletion deletion, - } - }}} - {{{ # counter methods @@ -87, +76 @@ 2:required ColumnParent column_parent, 3:required CounterColumn column, 4:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) - throws (1:InvalidRequestException ire, 2:UnavailableException ue, 3:TimedOutException te), - /** - * Batch increment or decrement a counter. - */ - void batch_add(1:required map<binary, map<string, list<CounterMutation>>> update_map, - 2:required ConsistencyLevel consistency_level=ConsistencyLevel.ONE) throws (1:InvalidRequestException ire, 2:UnavailableException ue, 3:TimedOutException te), /** @@ -132, +115 @@ == Technical limitations == - Writes require CL.ONE. - * The commutative design requires partitionability and idempotence between partitions. - * If a write fails unexpectedly (timeout for example) the client will not know if the operation has been performed. A retry can result in an over count. + * If a write fails unexpectedly (timeout or loss of connection to the coordinator node) the client will not know if the operation has been performed. A retry can result in an over count. + * Range slices on counter column family is not yet supported (https://issues.apache.org/jira/browse/CASSANDRA-2342). - - == Operational considerations == - * Reusing IP addresses will cause problems. Since the current version of the patch uses machine ip addresses in the on disk data format as an identifier a reuse of an old address will result in incorrect counts. - * See https://issues.apache.org/jira/browse/CASSANDRA-1944 and https://issues.apache.org/jira/browse/CASSANDRA-1938 == Further reading == - See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] and especially the [[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design doc]] for further information about how this works. + See [[https://issues.apache.org/jira/browse/CASSANDRA-1072|CASSANDRA-1072]] and especially the [[https://issues.apache.org/jira/secure/attachment/12459754/Partitionedcountersdesigndoc.pdf|design doc]] for further information about how this works internally.
