2

I am in a new system where two different TTLs (30 days and 90 days) are being used with TWCS compaction. As a result, the team needs to do major compaction (STCS) every 40-50 days, which is affecting performance.

Last week major compaction was initiated which was completed yesterday and I have seen they never used split-output (-s) option. There is already 2 huge sstable (10 gb compacted and 300 gb uncompacted as an output of this compaction.

  1. Post STCS compaction, along with 2 bigger SSTables ,older sstables still coexist (since mid Dec 2022). What may be the reason?
  2. If next time the team will run compaction with split option, will that bigger file be split? Or do we have to use sstablesplit to get that splitted?
  3. In 2 out of 5 nodes some sstables are there since July 2022 in the data file path. What may be the problem ?? I have observed some sstable files in snapshot directory...is this the issue??
Improve this question
2
  • Does the application only perform inserts into this TWCS table and that there is no further updates or deletes to the data?
    – Madhavan
    Commented Feb 3, 2023 at 14:28
  • Yes...TTL takes care of the delete
    – Cassandra Thrift
    Commented Feb 6, 2023 at 7:44

1 Answer 1

Reset to default
2

Performing a major compaction on TWCS tables does not make sense because of how the strategy works.

With the TimeWindowCompactionStrategy (or TWCS), SSTables which belong within the same time window are compacted together into a single SSTable using SizeTieredCompactionStrategy (or STCS). After the STCS compaction completes, there is no further compaction done in TWCS.

A major compaction with the "split" option makes no sense since it splits the data into files which are 50%, 25%, 12.5%, etc of the total size. This is completely against the goal of TWCS which is to merge all the data into a single SSTable for every time window.

If a TTL is set on the data and gc_grace_seconds has passed, SSTables which have 100% fully expired data are dropped (deleted from the filesystem) without compaction -- it happens automatically without manual intervention.

If the table contains data with different TTLs, it indicates that perhaps you don't have a true timeseries use case so TWCS is not a good fit. If so, we recommend you switch to STCS. Otherwise, let TWCS do its job.

If you haven't already seen it, I recommend having a look at the resources below to get a better understanding on how Cassandra compactions work. Cheers!

Improve this answer
2
  • Hello Erick.Yes,as each sstable contains both 30 and 90 days TTL so an sstable is supposed to be dropped only after the time>90 days but here team faced node down issue after around 60-70 days and they taken the strategy to do manual compaction.I am thinking of proposing to create different tables for different TTL so that TWCS can effectively remove SStable automatically per time. But as we have a big sstable of >250 gb which definitely accumulated lot of tombstones so what would be the immediate resolution...should we go for sstable split or next compaction with -s option. Plz suggest
    – Cassandra Thrift
    Commented Feb 2, 2023 at 7:13
  • Point number 1 is resolved after node restart.
    – Cassandra Thrift
    Commented Feb 2, 2023 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.