Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 22 Jan 2014 23:25:20 +0000 (UTC)
From: "Donald Smith (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12690414.1390428549745.51204.1390433120505@arcas>
In-Reply-To: <JIRA.12690414.1390428549745@arcas>
References: <JIRA.12690414.1390428549745@arcas>
Subject: [jira] [Commented] (CASSANDRA-6611) Allow for FINAL ttls and FINAL
 (immutable) inserts to eliminate the need for tombstones
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


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

Donald Smith commented on CASSANDRA-6611:
-----------------------------------------

Would it be better, then, to enforce this at the schema level, in a CREATE =
TABLE statement?

> Allow for FINAL ttls and FINAL (immutable) inserts 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=E2=80=
=99d be no risk of missed deletes.  You wouldn=E2=80=99t even need GCable t=
ombstones.  The purpose of a tombstone is to cover the case where a differe=
nt node was down and it didn=E2=80=99t notice the delete and it still had t=
he column and tried to replicate it back; but that won=E2=80=99t happen if =
it too had the TTL.
> So, if =E2=80=93 and it=E2=80=99s a big if =E2=80=93 a table disallowed u=
pdates to TTL, then you could really optimize deletion of TTLed columns: yo=
u could do away with tombstones entirely.   If a table allows updates to TT=
L then it=E2=80=99s 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 thos=
e too. Probably other optimizations would be enabled too.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)