cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6611) Allow for FINAL ttls and FINAL inserts or TABLEs to eliminate the need for tombstones
Date Sat, 25 Jan 2014 02:51:38 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881627#comment-13881627
] 

Brandon Williams commented on CASSANDRA-6611:
---------------------------------------------

I should note that, if your client is willing to promise not to overwrite the cell much, and
willing to eat the performance hit of the CAS every time it does (including the initial write
itself) then this is probably workable.  Still though, I think in that situation you're better
off separating the TTL data into another CF, since you'll never need to repair that CF as
long as the only way anything is deleted from it is via TTL.

> Allow for FINAL ttls and FINAL inserts or TABLEs to eliminate the need for tombstones
> -------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6611
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6611
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Donald Smith
>
> Suppose you're not allowed to update the TTL of a column (cell) -- either because CQL
is extended to allow syntax like "USING *FINAL* TTL 86400" or because there were a table option
saying that TTL is immutable.
> If you never update the TTL of a column, then there should be no need for tombstones
at all:  any replicas will have the same TTL.  So there’d be no risk of missed deletes.
 You wouldn’t even need GCable tombstones.  The purpose of a tombstone is to cover the case
where a different node was down and it didn’t notice the delete and it still had the column
and tried to replicate it back; but that won’t happen if it too had the TTL.
> So, if – and it’s a big if – a table disallowed updates to TTL, then you could
really optimize deletion of TTLed columns: you could do away with tombstones entirely.   If
a table allows updates to TTL then it’s possible a different node will have the row without
the TTL and the tombstone would be needed.
> Or am I missing something?
> Disallowing updates to rows would seem to enable optimizations in general.   Write-once,
non-updatable rows are a common use case. If cassandra had FINAL tables (or FINAL INSERTS)
then it could eliminate tombstones for those too. Probably other optimizations would be enabled
too.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message