Thank you so much Jon for your input the link you provided are very helpful I am considering also to migrate to the BTI format would you recommending doing that before or after switching to UCS or its not important? ________________________________ From: Jon Haddad <j...@rustyrazorblade.com> Sent: Thursday, September 11, 2025 6:34 PM To: user@cassandra.apache.org <user@cassandra.apache.org> Subject: Re: TWCS migration to UCS
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<mailto: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
