cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (CASSANDRA-13561) Purge TTL on expiration
Date Wed, 19 Jul 2017 17:38:00 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-13561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jeff Jirsa updated CASSANDRA-13561:
-----------------------------------
    Comment: was deleted

(was: 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message