[
https://issues.apache.org/jira/browse/CASSANDRA-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051350#comment-13051350
]
Yang Yang edited comment on CASSANDRA-2735 at 6/17/11 10:06 PM:
----------------------------------------------------------------
true, I don't really care about expired data, I'm happy as long as we have an
expiring counter that "mostly" works or works with certain cautions.
but it seems that the "changing order" can come not only from compaction (which
is fixed for realistic scenarios here),
but also from effects of message drops.
"compact( compact (Add1, delete), Add2) " is the same as receiving Add1, delete
, Add2 in messages.
but we know that messages can be easily dropped.
so let's say the delete is dropped, then we replay it later (through repair for
example), so we have Add1, Add2, delete, the same issue appears.
I think the latter issue can be fixed by changing the TTL reconcile rule so
that reconciled death time is the older death time, not timestamp+new_TTL.
anyhow I think we users of the counters api need to understand that placing a
delete shortly after your last update, or place an update shortly after delete
is most likely not going to work. this patch fixes half of the issue, but it
still remains.
was (Author: yangyangyyy):
true, I don't really care about expired data, I'm happy as long as we have
an expiring counter that "mostly" works or works with certain cautions.
but it seems that the "changing order" can come not only from compaction (which
is fixed for realistic scenarios here),
but also from effects of message drops.
"compact( compact (Add1, delete), Add2) " is the same as receiving Add1, delete
, Add2 in messages.
but we know that messages can be easily dropped.
so let's say the delete is dropped, then we replay it later (through repair for
example), the same issue appears.
I think the latter issue can be fixed by changing the TTL reconcile rule so
that reconciled death time is the older death time, not timestamp+new_TTL.
anyhow I think we users of the counters api need to understand that placing a
delete shortly after your last update, or place an update shortly after delete
is most likely not going to work. this patch fixes half of the issue, but it
still remains.
> Timestamp Based Compaction Strategy
> -----------------------------------
>
> Key: CASSANDRA-2735
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2735
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Alan Liang
> Assignee: Alan Liang
> Priority: Minor
> Labels: compaction
> Attachments: 0004-timestamp-bucketed-compaction-strategy.patch
>
>
> Compaction strategy implementation based on max timestamp ordering of the
> sstables while satisfying max sstable size, min and max compaction
> thresholds. It also handles expiration of sstables based on a timestamp.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
