[
https://issues.apache.org/jira/browse/CASSANDRA-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14549346#comment-14549346
]
Aleksey Yeschenko commented on CASSANDRA-9420:
----------------------------------------------
We've discussed this before, when introducing default TTL.
What we should have done back then was to make that option not a default, but
an enforced constrain. So that *every* update/insert always comes with the same
TTL.
I personally wouldn't mind adding a new {{required_ttl}} table option and have
it behave like this.
> Table option for promising that you will never touch a column twice
> -------------------------------------------------------------------
>
> Key: CASSANDRA-9420
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9420
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Björn Hegerfors
>
> There are time series use cases where you write all values with various TTLs,
> have GC grace = 0 and never ever update or delete a column after insertion.
> In the case where all TTLs are the same, DTCS with recent patches works
> great. But when there is lots of variations in TTLs, you are forced to choose
> between splitting your table into multiple TTL tiers or having your SSTables
> filled to the majority with tombstones. Or running frequent major compactions.
> The problem stems from the fact that Cassandra plays safe when a TTL has
> expired, and turns it into a tombstone, rather than getting rid of it on the
> spot. The reason is that this TTL _may_ have been in a column which has had
> an earlier write without (or with a higher) TTL. And then that one should now
> be deleted too.
> I propose that there should be table level setting to say "I guarantee that
> there will never be any updates to any columns". The effect of enabling that
> option is that all tombstones and expired TTLs should always be immediately
> removed during compaction. And the check for dropping entirely expired
> SSTables can be very loosened for these tables.
> This option should probably require gc_grace_seconds to be set to zero. It's
> also questionable if writes without TTL should be allowed to such a table,
> since those would become constants.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
