cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5546) Gc_grace should start at the creation of the column, not when it expires
Date Mon, 12 May 2014 15:37:15 GMT

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

Jonathan Ellis updated CASSANDRA-5546:
--------------------------------------

    Fix Version/s:     (was: 2.1 rc1)
                   3.0

> Gc_grace should start at the creation of the column, not when it expires
> ------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5546
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5546
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>             Fix For: 3.0
>
>
> Currently, gc_grace determines "the minimum time we keep a column that has been marked
for deletion", where "marked for deletion" is creation time for a DeletedColumn or the expiration
time for an ExpiringColumn.
> However, in the case of expiring columns, if you want to optimize deletions while making
sure you don't resurrect overwritten data, you only care about keeping expired columns gc_grace
seconds *since their creation time*, not *since their expiration time*. It would thus be better
to have gc_grace be "the minimum time we keep a column since it's creation" (which would change
nothing for tombstones, but for TTL would basically ensure we remove the expiration time from
the time we keep the column once expired).
> To sum it up, this would have the following advantages:
> # This will make fine tuning of gc_grace a little less of a black art.
> # This will be more efficient for CF mixing deletes and expiring columns (we'll remove
tombstones for the expiring one sooner).
> # This means gc_grace will be more reliable for things like CASSANDRA-5314.
> Doing this is pretty simple. The one concern is backward compatilibity: it means people
that have fine tuned gc_grace to a very low value because they knew it was ok due to their
systematic use of ttls might have to update it back to a bigger, more reasonable value before
updates.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message