[
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)
