Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 18 May 2015 21:23:00 +0000 (UTC)
From: =?utf-8?Q?Bj=C3=B6rn_Hegerfors_=28JIRA=29?= <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12830833.1431984127000.148689.1431984180191@Atlassian.JIRA>
In-Reply-To: <JIRA.12830833.1431984127000@Atlassian.JIRA>
References: <JIRA.12830833.1431984127000@Atlassian.JIRA>
 <JIRA.12830833.1431984127152@arcas>
Subject: [jira] [Created] (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

Bj=C3=B6rn Hegerfors created CASSANDRA-9420:
------------------------------------------

             Summary: 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 TTL=
s, have GC grace =3D 0 and never ever update or delete a column after inser=
tion. In the case where all TTLs are the same, DTCS with recent patches wor=
ks great. But when there is lots of variations in TTLs, you are forced to c=
hoose between splitting your table into multiple TTL tiers or having your S=
STables filled to the majority with tombstones. Or running frequent major c=
ompactions.

The problem stems from the fact that Cassandra plays safe when a TTL has ex=
pired, 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 th=
at option is that all tombstones and expired TTLs should always be immediat=
ely 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)