Database Reference
In-Depth Information
The expiring cell
Every once in a while, you find yourself in a situation where the data gets stale after a giv-
en time, and you want to delete it because it does not have a future value or will possibly
mess up with the result set. One such example could be a user session object or a password
reset request that expires in a day, or maybe you are streaming out word frequency analysis
on tweets posted in the last week (moving average). Cassandra gives you the power to
make any cell (and hence row) expire after a given time. And if later, before the data is ex-
pired, you want to further change the expiry time, you can do that too. This expiry time is
commonly referred to as TTL.
On insertion or the update of a TTL-containing cell, the coordinator node sets a deletion
timestamp by adding the current local time to the TTL provided. The column expires when
the local time of a querying node goes past the set expiration timestamp. The deleted node
is marked for deletion with a tombstone and is removed during a compaction after the ex-
piration timestamp or during repair. Expiring columns take 8 bytes of extra space to record
the TTL. Here's an example:
# Create a regular table
cqlsh:mastering_cassandra> CREATE TABLE demo_ttl ( id int
PRIMARY KEY, expirable_col varchar, column2 int );
# Insert data as usual
cqlsh:mastering_cassandra> INSERT INTO demo_ttl (id,
expirable_col, column2) VALUES (1, 'persistent_row', 10);
# Insert a row with TTL equals to 30 seconds
cqlsh:mastering_cassandra> INSERT INTO demo_ttl (id,
expirable_col, column2) VALUES (2, 'row_with_30sec_TTL', 30)
using TTL 30;
# Observe decreasing TTL with time
cqlsh:mastering_cassandra> SELECT ttl(expirable_col),
ttl(column2) FROM demo_ttl WHERE id = 2;
ttl(expirable_col) | ttl(column2)
--------------------+--------------
23 | 23
