[jira] Commented: (CASSANDRA-2101) support deletes in counters

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-2101:
---------------------------------------------

Before commenting on the patch itself, I want to use this ticket to recall that counter deletes are intrinsically broken. It has been said already but I'll use this comment to explain in more depth how so and keep a trace of this for the record.

First, I'll use the following notation:
{noformat}
  c(x, 3)@[4, 2] - for a counter column of name x, value 3, timestamp 4 and timestampOfLastDelete 2 (I'll use -1 as the min timestampOfLastDelete).
{noformat}
and
{noformat}
  d(x)@[5] - for a tombstone of name x and timestamp 5
{noformat}

And now suppose that the following inserts are done (in that order):
{noformat}
   c(x, 1)@[1, -1]
   d(x)@[2]
   c(x, 1)@[3, -1]
{noformat}

If these inserts are resolved in that order, everything is fine:
{noformat}
   c(x, 1)@[1, -1]
 + d(x)@[2]
=> d(x)@[2]
 + c(x, 1)@[3, -1]
=> c(x, 1)@[3, 2]
{noformat}

However, some reordering don't work. Namely, if you merge the two counts together, before you merge one of the count with the delete:
{noformat}
   c(x, 1)@[1, -1]
 + c(x, 1)@[3, -1]
=> c(x, 2)@[3, -1]
 + d(x)@[2]
=> c(x, 2)@[3, 2]
{noformat}

The problem is, the resolve operation is not commutative when you consider counter columns and tombstones. But Cassandra rely heavily on resolve being commutative (as a side note, I never understood the reason of the CommutativeType terminology in the code. It suggest that regular columns are not commutative, while they are as far as resolve is concerned. Resolve is not idempotent on counters however).

Not only is there no guarantee on which order the insert will be received by each node, but even if they are in the right order, there is no guarantee that (minor) compaction won't screw up this.

Hence I think that there is not much guarantee we can give on deletes. The only one I can think of is that when on issue a delete, you must wait to issue any following update that the delete have reach all the nodes and all of them have been fully compacted.

That being said, we can keep counter deletes. It's at least useful for cases where you know that you won't reuse a counter ever and want to get rid of the disk space. But I would add a very strong warning to its documentation.

Lastly, the deletion of full counter rows or super columns suffers the same problem for the same reason.


> support deletes in counters
> ---------------------------
>
>                 Key: CASSANDRA-2101
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2101
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8
>            Reporter: Kelvin Kakugawa
>            Assignee: Kelvin Kakugawa
>             Fix For: 0.8
>
>         Attachments: 0001-CASSANDRA-2101-fix-timestampOfLastDelete-reconciliat.patch
>
>
> Obey timestampOfLastDelete during reconciliation.

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