1

I have a Cassandra 2.1 cluster where we insert data though Java with TTL as the requirement of persisting the data is 30 days. But this causes problem as the files with old data with tombstones is kept on the disk. This results in disk space being occupied by data which is not required. Repairs take a lot of time to clear this data (upto 3 days on a single node) Is there a better way to delete the data?

I have come across this on datastax

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. https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutDeletes.html?hl=tombstone

Will the data be deleted more efficiently if I set TTL at table level instead of setting each time while inserting. Also, documentation is for Cassandra 3, so will I have to upgrade to newer version to get any benefits?

warrior107
  • 709
  • 1
  • 9
  • 25

2 Answers2

5

Setting default_time_to_live applies the default ttl to all rows and columns in your table - and if no individual ttl is set (and cassandra has correct ntp time on all nodes), cassandra can easily drop those data safely.

But keep some things in mind: your application is still able so set a specific ttl for a single row in your table - then normal processing will apply. On top, even if the data is ttled it won't get deleted immediately - sstables are still immutable, but tombstones will be dropped during compaction.

What could help you really a lot - just guessing - would be an appropriate compaction strategy:

http://docs.datastax.com/en/archived/cassandra/3.x/cassandra/dml/dmlHowDataMaintain.html#dmlHowDataMaintain__twcs-compaction

TimeWindowCompactionStrategy (TWCS) Recommended for time series and expiring TTL workloads.

The TimeWindowCompactionStrategy (TWCS) is similar to DTCS with simpler settings. TWCS groups SSTables using a series of time windows. During compaction, TWCS applies STCS to uncompacted SSTables in the most recent time window. At the end of a time window, TWCS compacts all SSTables that fall into that time window into a single SSTable based on the SSTable maximum timestamp. Once the major compaction for a time window is completed, no further compaction of the data will ever occur. The process starts over with the SSTables written in the next time window.

This help a lot - when choosing your time windows correctly. All data in the last compacted sstable will have roughly equal ttl values (hint: don't do out-of-order inserts or manual ttls!). Cassandra keeps the youngest ttl value in the sstable metadata and when that time has passed cassandra simply deletes the entire table as all data is now obsolete. No need for compaction.

How do you run your repair? Incremental? Full? Reaper? How big in terms of nodes and data is your cluster?

Mandraenke
  • 3,086
  • 1
  • 13
  • 26
  • There is only one application which writes data to the cluster so we can disable individual TTL if TTL is set at table level and if that provides any improvement. We insert data where transactionId is primary key (there can be about 100 rows for each key spanning across about a week). So if any row is older than 30 days, we are okay to delete that row. We use LeveledCompactionStrategy for compaction, will switching to TimeWindowCompactionStrategy help? We repair in Incremental. But lately there was some problem with cron job so was running full repairs on some of the nodes. – warrior107 Dec 28 '17 at 11:32
  • TWCS could help in your case - it's often a good fit for data wich will be ttled and inserted in-order. I would suggest a time window of a week perhaps, so after 35 days old data in sstables will be gone. During the week compations are size-tiered, and one major compation at the end of the time window - have a look at the number of sstables and your read pattern. For repairs have a look at: http://cassandra-reaper.io/docs/download/install/ – Mandraenke Dec 28 '17 at 13:08
0

The quick answer is yes. The way it is implemented is by deleting the SStable/s directly from disk. Deleting an SStable without the need to compact will clear up disk space faster. But you need to be sure that the all the data in a specific sstable is "older" than the globally configured TTL for the table.

This is the feature referred to in the paragraph you quoted. It was implemented for Cassandra 2.0 so it should be part of 2.1

TomerSan
  • 1,576
  • 6
  • 12