[jira] [Comment Edited] (CASSANDRA-9420) Table option for promising that you will never touch a column twice

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

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

Aleksey Yeschenko edited comment on CASSANDRA-9420 at 5/20/15 1:34 PM:
-----------------------------------------------------------------------

Right. I was speaking slightly out of context of this ticket.

Anecdotally, from observing #cassandra and talking to Field people, it seems like there are many users relying just on TTL and never doing any deletes. Having an option for them to express it in metadata, and for us to enforce it, would allow us to drop expired TTL cells much more aggressively.

I'm speaking of using the same TTL everywhere, here, which should be at least as common as varying TTLs. We don't care about overwrites here at all, only need to enforce that all UPDATEs and INSERTs come with the same default TTL at all times. Maybe forbid DELETEs too.

[~mstump] Am I talking nonsense here? Is this relevant at all?


was (Author: iamaleksey):
Right. I was speaking slightly out of context of this ticket.

Anecdotally, from observing #cassandra and talking to Field people, it seems like there are many users relying just on TTL and never doing any updates. Having an option for them to express it in metadata, and for us to enforce it, would allow us to drop expired TTL cells much more aggressively.

I'm speaking of using the same TTL everywhere, here, which should be at least as common as varying TTLs. We don't care about overwrites here at all, only need to enforce that all UPDATEs and INSERTs come with the same default TTL at all times. Maybe forbid DELETEs too.

[~mstump] Am I talking nonsense here? Is this relevant at all?

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