0

I've been struggling with how specifically TWCS works lately. In our workflow we have some tables containing time-series data with a mostly static TTL. As such, a decision was made to use TWCS as the compaction strategy for this. There are, however, unfortunately some of these tables which appear to be taking up more space than usual, i.e. they appear to be blocked by the oldest SSTables. We have already pinpointed one potential root cause. There is a scenario in which a TTL rewrite may occur on an existing record, e.g. diminishing the TTL of this existing record. In this scenario, it makes sense that this record, which would reside in multiple SSTables, with higher and lower TTL, should block other SSTables from being compacted. Indeed, after a while these updated records appeared to TTL out and subsequently all was unblocked. However, there are also tables which are growing rapidly, for which the sstableblockers tool reveals no blocking tables.

Therefore I took to reading some articles about this. Some articles I refer to are e.g. https://thelastpickle.com/blog/2016/12/08/TWCS-part1.html or https://www.redshots.com/cassandra-twcs-must-have-ttls/. Especially the latter caused suspicion in me as to whether a TTL change between "new" records would also have a blocking effect. The latter article specifically mentions The deletion of the whole sstable when filled with TTL's will only happen if it is the oldest sstable, therefore once one cannot be deleted, none of the subsequent ones can be deleted either.

We consider the following scenario with TWCS:
We write e.g. 100 records with a TTL of 5000 which all end up in the same SSTable, then subsequently, we write 100 new records with a different TTL of 100, written to a new column (but maybe the same partition).
Based on my tests I presume that the first 100 records to "TTL out" will not release any disk space until the SSTable containing the records with oldest TTL expires.

However, I wasn't entirely confident about this, especially since both SSTables essentially contain nothing that should be shadowing each other. As such, I don't believe there should logically be a reason for these tables to not be removed from disk. Furthermore, I also considered the possibility of older TTL'ed and newer TTL'ed data being mixed in the oldest SSTable. I presumed this would also behave the same. In general, questions remained. As such I wanted to validate this conclusion.

In short: with TWCS, is removal from disk of a new record with lower TTL going to be blocked by any older record with higher TTL residing in a different SSTable?

1 Answer 1

0

The short answer is yes. SSTables which contain non-expired data will be blocked.

The long answer is that the data access pattern as you described indicates to me that you don't have a "true" time-series data model so it is not a good fit for TWCS. If your data is really time-series, you wouldn't be updating records at different times or with different TTLs.

Even with the limited information you posted, I would recommend switching to STCS. Cheers!

5
  • Thank you Eric! A bit more context:, the table itself is a sorted collection of trend points, so it should lend itself to the usage of twcs as far as I understand. The updating of the records happens as far as I know only in very specific circumstances, which we could eliminate by just writing a new point in stead of updating ttl. What we cannot work around though is the mixing of ttl's as users of our app can choose the ttl. However, that means if no data is ever updated, only written we probably would not run into problems with twcs. Is that correct?
    – LVC
    Commented May 1 at 20:33
  • What is "a sorted collection of trend points"? In any case, I'm still convinced your data is not time-series if it is getting updated out-of-sequence. Cheers! Commented May 2 at 3:49
  • Apologies Erick, I'll try to be more clear. We use this table to write"points" that create a graph based on integer values over time. The partitioning key describes what specific item the graph is created for and how often we should write the point to the table. The clustering column describes the time the point was written to the database (and as such the point itself). The points are written in order. Sometimes a user notices the graphs become too large on disk, then the new points are written with a smaller TTL. They are still written in sequence unless my understanding is flawed.
    – LVC
    Commented May 2 at 5:56
  • TWCS is designed for time series data that has a default TTL. It isn't suitable for use cases where you're updating the data out-of-sequence with a different TTL. I recommend switching to STCS. Cheers! Commented May 2 at 23:58
  • Thank you Erick for the many and quick responses! It is much appreciated. I realize our use-case is likely a bit too complex for use with TWCS. As it stands, I will advocate to move back to STCS, even if it means taking a diskspace hit. I'm not sure whether the unified compaction strategy would be a solution for the disk space hit (and a fitting solution for the data set) when that is released, but I guess we can have a look at that as it takes shape.
    – LVC
    Commented May 3 at 8:21

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.