9

Requirement is simple: we have to create a table which will have only 24 hours of data. We have two options

  1. Defile TTL with each insert
  2. Make table property default_time_to_live for 24 hours.

I have general idea about both the things but internally which one will be helpful to deal with tombstones? or both will generate same amount of tombstones? Which one will be better and why any reference link will be appreciated.

theone
  • 113
  • 1
  • 5

3 Answers3

16

If a table has default_time_to_live on it then rows that exceed this time limit are deleted immediately without tombstones being written. This will not affect rows / columns that have an explicit TTL set on them. These will be tombstoned.

If you go down the TTL route then you should consider setting the gc_grace_seconds property on the table to something less than the default (10 days). Particularly if you are looking at a 24 hour TTL.

References:

How data is deleted <-- Good background

CREATE TABLE properties <-- Table property reference

About Deletes and Tombstones in Cassandra <-- Everything you ever wanted to know about deletes and tombstones

mikea
  • 6,537
  • 19
  • 36
  • Thanks Mikea for answer with required reference link. Very helpful !!! – theone Apr 27 '18 at 14:21
  • 1
    @mikea could you tell me why `default_time_to_live` does not require tombstones? Thanks. – gabrielgiussi Sep 06 '18 at 17:58
  • 1
    Indeed it seems `default_time_to_live` does use tombstone, see this other stackoverflow post: [How default_time_to_live would delete rows without tombstones in Cassandra?](https://stackoverflow.com/q/52282517/6185694) – jinnlao Feb 18 '21 at 14:15
0

If you use Cassandra 3.0 you can also define materialized view, see details: https://docs.datastax.com/en/cql/3.3/cql/cql_using/useCreateMV.html

Using TTL is not that effective as you will generate lots of tombstones, which depending on the amount of data might effect your read performance.

Also I think your question regarding the TTL is answered here:

cassandra TTL for table behaviour

Andrea Nagy
  • 1,201
  • 9
  • 21
0

If you are using Go then GocqlX solves this problem with RewriteRows function based on table model.

https://github.com/scylladb/gocqlx/commit/13ef8ceaf1c1661ec51459347e6b2aea6e59037c

Example:

    if err := session.ExecStmt("ALTER TABLE XXXXX WITH default_time_to_live = 0"); err != nil {
        return err
    }
    if err := table.RewriteRows(session, myGocqlXTableModelForXXXXX); err != nil {
        return err
    }

For big tables you should be using an efficient full table scan plus with this technique.

mmatczuk
  • 539
  • 4
  • 9