[
https://issues.apache.org/jira/browse/CASSANDRA-13561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093463#comment-16093463
]
Jeff Jirsa commented on CASSANDRA-13561:
----------------------------------------
I'm just trying to page this into my mind and also try to correlate with other
recent tickets I've seen. This seems pretty close to what [~bdeggleston]
touched on with CASSANDRA-13643 , though this is more aggressive (and more
invasive, in the sense that it needs a new table property). Does Blake's
addition to call purge on the tombstone generated have a similar effect here?
> 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]
