Reputation: 133
Requirement is simple: we have to create a table which will have only 24 hours of data. We have two options
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.
Upvotes: 10
Views: 9228
Reputation: 549
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.
Upvotes: 0
Reputation: 6667
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
Upvotes: 17
Reputation: 1231
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
Upvotes: 0