cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Yang (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-2774) one way to make counter delete work better
Date Wed, 15 Jun 2011 15:49:48 GMT

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

Yang Yang edited comment on CASSANDRA-2774 at 6/15/11 3:48 PM:
---------------------------------------------------------------

It's good to step back and ask " what is the contract ?" Now
So far cassandra let time be dictated arbitrarily by client (
Client assigns timestamp) so it can afford to expect *the*
Ordering and *the* result

In counters client-generated ts can't be used so we can't guarantee *the* expected
Result.

But we will guaranttee that all nodes on the system eventually agree on
*some* common result, this is actually consistent with the definition
Of eventual consistency brought forth by Dynamo


( if u look at client-generated ts. It could indeed produce some
Unintuitive results: if a client sets ts to be very late into
The future, latter writes could be wiped out. For regular columns
 This is in the same way against common client expectations about ordering as in the counter
case)

In summary the current implementation cannot guarattee any 
common agreement on counter value but the new approach guarantees the achievement of *some*
common value



      was (Author: yangyangyyy):
    It's good to step back and ask " what is the contract ?" Now
So far cassandra let time be dictated arbitrarily by client (
Client assigns timestamp) so it can afford to expect* **** the* ***
Ordering and *the** result

In counters client-generated ts can't be used so we can't guarantee* the* expected
Result.

But we will guaranttee that all nodes on the system eventually agree on
*some* common result, this is actually consistent with the definition
Of eventual consistency brought forth by Dynamo


( if u look at client-generated ts. It could indeed produce some
Unintuitive results: if a client sets ts to be very late into
The future, latter writes could be wiped out. For regular columns
 This is in the same way against common client expectations about ordering as in the counter
case)

In summary the current implementation cannot guarattee any 
common agreement on counter value but the new approach guarantees thecommon value

Achievement of some 
  
> one way to make counter delete work better
> ------------------------------------------
>
>                 Key: CASSANDRA-2774
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2774
>             Project: Cassandra
>          Issue Type: New Feature
>    Affects Versions: 0.8.0
>            Reporter: Yang Yang
>         Attachments: counter_delete.diff
>
>
> current Counter does not work with delete, because different merging order of sstables
would produces different result, for example:
> add 1
> delete 
> add 2
> if the merging happens by 1-2, (1,2)--3  order, the result we see will be 2
> if merging is: 1--3, (1,3)--2, the result will be 3.
> the issue is that delete now can not separate out previous adds and adds later than the
delete. supposedly a delete is to create a completely new incarnation of the counter, or a
new "lifetime", or "epoch". the new approach utilizes the concept of "epoch number", so that
each delete bumps up the epoch number. since each write is replicated (replicate on write
is almost always enabled in practice, if this is a concern, we could further force ROW in
case of delete ), so the epoch number is global to a replica set
> changes are attached, existing tests pass fine, some tests are modified since the semantic
is changed a bit. some cql tests do not pass in the original 0.8.0 source, that's not the
fault of this change.
> see details at http://mail-archives.apache.org/mod_mbox/cassandra-user/201106.mbox/%3CBANLkTikQcgLSNwtT-9HvqpSeoo7SF58SnA@mail.gmail.com%3E
> the goal of this is to make delete work ( at least with consistent behavior, yes in case
of long network partition, the behavior is not ideal, but it's consistent with the definition
of logical clock), so that we could have expiring Counters

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message