Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 18 May 2015 22:08:01 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12830833.1431984127000.149283.1431986881847@Atlassian.JIRA>
In-Reply-To: <JIRA.12830833.1431984127000@Atlassian.JIRA>
References: <JIRA.12830833.1431984127000@Atlassian.JIRA>
 <JIRA.12830833.1431984127152@arcas>
Subject: [jira] [Commented] (CASSANDRA-9420) Table option for promising that
 you will never touch a column twice
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-9420?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14549346#comment-14549346 ]=20

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, b=
ut an enforced constrain. So that *every* update/insert always comes with t=
he same TTL.

I personally wouldn't mind adding a new {{required_ttl}} table option and h=
ave 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=C3=B6rn Hegerfors
>
> There are time series use cases where you write all values with various T=
TLs, have GC grace =3D 0 and never ever update or delete a column after ins=
ertion. In the case where all TTLs are the same, DTCS with recent patches w=
orks 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 th=
e spot. The reason is that this TTL _may_ have been in a column which has h=
ad an earlier write without (or with a higher) TTL. And then that one shoul=
d now be deleted too.
> I propose that there should be table level setting to say "I guarantee th=
at 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 immedi=
ately removed during compaction. And the check for dropping entirely expire=
d SSTables can be very loosened for these tables.
> This option should probably require gc_grace_seconds to be set to zero. I=
t's also questionable if writes without TTL should be allowed to such a tab=
le, since those would become constants.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)