[
https://issues.apache.org/jira/browse/CASSANDRA-13561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091165#comment-16091165
]
Kurt Greaves commented on CASSANDRA-13561:
------------------------------------------
You are right. CASSANDRA-13418 is a different issue to what you are talking
about. It is a specific option for allowing expiration of only completely
expired SSTables where there are overlaps with another SSTable.
My understanding is that you are saying we should purge TTL'd cells as soon as
they expire, rather than waiting for GCGS to pass, but obviously we would still
require a compaction to make that happen. Is that correct?
In theory it would be nice but I think once you take into account that an
update that sets a TTL may not make it to all nodes, you have a problem.
For example:
3 nodes A B and C, RF=3
An INSERT without any TTL's set for PK "a" makes it to all 3 nodes
B goes down
An update setting a single column "b" to TTL after x seconds for PK "a" is sent.
B comes back up (disregarding HH)
A and C are now in a state with "b" having a TTL while B has no TTL for the
same cell.
"b" expires on A and C, a compaction is triggered and the cell gets removed.
"b" returns from the dead from B.
> Purge TTL on expiration
> -----------------------
>
> Key: CASSANDRA-13561
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13561
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Andrew Whang
> Assignee: Andrew Whang
> Priority: Minor
> Fix For: 4.0
>
>
> Tables with mostly TTL columns tend to suffer from high droppable tombstone
> ratio, which results in higher read latency, cpu utilization, and disk usage.
> Expired TTL data become tombstones, and the nature of purging tombstones
> during compaction (due to checking for overlapping SSTables) make them
> susceptible to surviving much longer than expected. A table option to purge
> TTL on expiration would address this issue, by preventing them from becoming
> tombstones. A boolean purge_ttl_on_expiration table setting would allow users
> to easily turn the feature on or off.
> Being more aggressive with gc_grace could also address the problem of long
> lasting tombstones, but that would affect tombstones from deletes as well.
> Even if a purged [expired] cell is revived via repair from a node that hasn't
> yet compacted away the cell, it would be revived as an expiring cell with the
> same localDeletionTime, so reads should properly handle them. As well, it
> would be purged in the next compaction.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
