[
https://issues.apache.org/jira/browse/CASSANDRA-13561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093343#comment-16093343
]
Andrew Whang commented on CASSANDRA-13561:
------------------------------------------
Correct, this implementation would still require a compaction to purge the
expired cells.
Also correct, in the scenario you described there is a risk of the expired cell
returning from the dead. The scenario does disregard HH. If hints are properly
delivered, the risk is mitigated. To be clear, the scenario is similar to
setting GCGS=0. The user has to understand the risk of using these settings.
The risk is also mitigated in use cases where there is a default TTL on the
table or client mutations use a default TTL. These are the scenarios for which
we use this feature in our environment. In these use cases, we noticed the
table suffered from high droppable tombstone ratio and high read latency. Using
this feature to purge TTL as they expired addressed both droppable tombstone
ratio and read latency.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
