cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Giussi <gabrielgiu...@gmail.com>
Subject Fwd: How default_time_to_live would delete rows without tombstones in Cassandra?
Date Mon, 17 Sep 2018 12:58:07 GMT
From
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html

> Cassandra allows you to set a default_time_to_live property for an entire
table. Columns and rows marked with regular TTLs are processed as described
above; but when a record exceeds the table-level TTL, **Cassandra deletes
it immediately, without tombstoning or compaction**.

This is also answered in https://stackoverflow.com/a/50060436/3517383

>  If a table has default_time_to_live on it then rows that exceed this
time limit are **deleted immediately without tombstones being written**.

And commented in LastPickle's post About deletes and tombstones (
http://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html#comment-3949581514
)

> Another clue to explore would be to use the TTL as a default value if
that's a good fit. TTLs set at the table level with 'default_time_to_live'
**should not generate any tombstone at all in C*3.0+**. Not tested on my
hand, but I read about this.

I've made the simplest test that I could imagine using
`LeveledCompactionStrategy`:

    CREATE KEYSPACE IF NOT EXISTS temp WITH replication = {'class':
'SimpleStrategy', 'replication_factor': '1'};

    CREATE TABLE IF NOT EXISTS temp.test_ttl (
        key text,
        value text,
        PRIMARY KEY (key)
    ) WITH  compaction = { 'class': 'LeveledCompactionStrategy'}
      AND default_time_to_live = 180;

 1. `INSERT INTO temp.test_ttl (key,value) VALUES ('k1','v1');`
 2. `nodetool flush temp`
 3. `sstabledump mc-1-big-Data.db`
[image: cassandra0.png]

 4. wait for 180 seconds (default_time_to_live)
 5. `sstabledump mc-1-big-Data.db`
[image: cassandra1.png]

The tombstone isn't created yet
 6. `nodetool compact temp`
 7. `sstabledump mc-2-big-Data.db`
[image: cassandra2.png]

The **tombstone is created** (and not dropped on compaction due to
gc_grace_seconds)

The test was performed using apache cassandra 3.0.13

>From the example I conclude that isn't true that `default_time_to_live` not
require tombstones, at least for version 3.0.13.
However this is a very simple test and I'm forcing a major compaction with
`nodetool compact` so I may not be recreating the scenario where
default_time_to_live magic comes into play.

But how would C* delete without tombstones? Why this should be a different
scenario to using TTL per insert?

This is also asked at stackoverflow
<https://stackoverflow.com/questions/52282517/how-default-time-to-live-would-delete-rows-without-tombstones-in-cassandra>

Mime
View raw message