Hi Isaeed, 1. I can recommend UCS as a replacement for every compaction strategy, including TWCS. I wrote a bit about it here [1], and we have a Time series section in the docs [2]
2. Your read performance will depend entirely on the number of SSTables per read. You've got a ton there - p99 is 35. Both have a lot of tuning options. Using scaling_parameters T4 will result in fewer SSTables than T4, T8, but will have higher write amplification as you will compact more. For these types of questions, I lean on easy-cass-lab [3] and cassandra-easy-stress [4], which was donated to the project a few months ago. 3. UCS naturally groups SSTables by time. Newer SSTables will have lower density than older ones, so they get compacted together. The behavior of TWCS windowing, while useful in a lot of ways, makes it impossible for tables with TWCS to make good use zero copy streaming. You're looking a more than a 10x difference in streaming performance when compared to the slow streaming path. I was able to take a cluster from 3TB / node without the ability to expand (due to streaming failures) to 12TB / node, with UCS providing quite a bit of the heavy lifting. I wrote a bit about the impact of streaming on node density and how it impacts cost [5]. 4. The docs have some good settings to try. Scaling params: T4, T8 is a good starting point, and I'd look at 'base_shard_count': '8'. Jon [1] https://rustyrazorblade.com/post/2025/07-compaction-strategies-and-performance/ [2] https://cassandra.apache.org/doc/5.0/cassandra/managing/operating/compaction/ucs.html [3] https://github.com/rustyrazorblade/easy-cass-lab [4] https://github.com/apache/cassandra-easy-stress [5] https://rustyrazorblade.com/post/2025/03-streaming/ On Thu, Sep 11, 2025 at 2:28 AM Isaeed Mohanna <isa...@xsense.co> wrote: > Hi > We have a table that stores metrics but does not have TTL, it is > partitioned by metrics_source, metric_type and clustered by a timestamp. > we are currently using the following TWCS compaction with the settings > below. > {'class': > 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy', > 'compaction_window_size': '7', 'compaction_window_unit': 'DAYS', > 'max_threshold': '32', 'min_threshold': '4'} > > Some relevant info from tablestats and table historgram, currently the > performance is sufficint for our usecase. > SSTable count: 529 > Max SSTable size: 15.577GiB > Local read/write ratio: 0.75296SSTables Time Window: 7 DAYS, max duration: > 3707 days 4 hours 58 minutes 47 seconds > Local read count: 3823721 > Local read latency: 2.129 ms > Local write count: 5078241 > Local write latency: 0.011 ms > > Percentile Read Latency Write Latency SSTables > Partition Size Cell Count > 50% 1597.00 10.00 > 12.00 17084 1331 > 75% 1916.00 12.00 > 20.00 29521 2299 > 95% 3973.00 29.00 > 29.00 73457 5722 > 98% 9887.00 35.00 > 29.00 126934 9887 > 99% 14237.00 50.00 > 35.00 182785 11864 > Min 373.00 2.00 > 0.00 36 0 > Max 29521.00 446.00 > 50.00 8409007 654949 > > We have recently upgraded to cassandra 5.0.5 and I have been reading about > UCS, since our data does not have TTL we are accumulating sstables with > time. > > 1. Would you recommend migrating to UCS is it production ready and > safe to use? > 2. My scenario has mixed worload, a constant wrote and occasiouanl > bursts of read. Would UCS result in comparable performance or better to > TWCS? > 3. Because my data has no TLL, Is there an option in UCS to use a > time based compaction in the lower tiers like TWCS and a SizeBased in > higher tier to have the best of both worlds? > 4. Which UCS settings do you think would be a good starting point to > experiemnt. > > > > *Best regards, Isaeed Mohanna* > > >
