ttl in cassandra creating tombstones

2
votes

I am only doing inserts to cassandra. While inserting , not nulls are only inserted to avoid tombstones. But few records are inserted with TTL. But then doing select count(*) from table gives following errors -

Read 76 live rows and 1324 tombstone cells for query SELECT * FROM xx.yy WHERE token(y) >= token(fc872571-1253-45a1-ada3-d6f5a96668e8) LIMIT 100 (see tombstone_warn_threshold)

Do TTL inserts lead to tombstones in cassandra 3.7 ? How can the warning be mitigated ?

There are no updates done only inserts , some records without TTL , others with TTL

2
cassandracassandra-3.0
Is not that TTL would eventually turned to tombstone? – madz
Can we see the table structure and insert code? – madz

2 Answers

4
votes

From datastax documentation: https://docs.datastax.com/en/cql/3.1/cql/cql_using/use_expire_c.html

After the number of seconds since the column's creation exceeds the TTL value, TTL data is considered expired and is included in results. Expired data is marked with a tombstone after on the next read on the read path, but it remains for a maximum of gc_grace_seconds. After this amount of time, the tombstoned data is automatically removed during the normal compaction and repair processes.

These entries will be treated as tombstones until compaction or repair.

4
votes

To add one more point for TTL and compaction. Even though, after gc_grace_seconds, the default setting for compaction only kicks off depending on tombstone_compaction_interval and tombstone_threshold

Previously, we were having read timeout issue due to high number of tombstones for tables having high number of records. Eventually, we need to reduce tombstone_threshold as well as enable unchecked_tombstone_compaction to make compaction process triggered more frequently.

You can refer to the below docs for more details

http://docs.datastax.com/en/cql/3.3/cql/cql_reference/cqlCreateTable.html?hl=unchecked_tombstone_compaction#tabProp__cqlTableGc_grace_seconds