When you change compaction strategy, nothing happens until the next flush. On the next flush, the new compaction strategy will decide what to do – if you change from STCS to DTCS, it will look at various timestamps of files, and attempt to group them by time windows based on the sstable’s minTimestamp, and your DTCS base_time_seconds and an ever-growing multiple of min_threshold
Generally, many people recommend doing a STCS major before changing to DTCS (essentially to force all sstables into the oldest possible bucket). Whether or not that’s ideal for you depends on why you’re using DTCS (do you want to cut down on compaction, or are you setting yourself up for efficient TTL expiration). If it’s the latter, you should be sure you understand the impact of STCS major on your TTL use case (no data will TTL out until all of the data currently on disk is ready to expire). From: Anuj Wadehra Reply-To: "user@cassandra.apache.org" Date: Friday, January 15, 2016 at 10:16 AM To: "user@cassandra.apache.org" Subject: Impact of Changing Compaction Strategy Hi, I need to understand whether all existing sstables are recreated/updated when we change compaction strategy from STCS to DTCS? Sstables are immutable by design but do we take an exception for such cases and update same files when an Alter statement is fired to change the compaction strategy? Thanks Anuj Sent from Yahoo Mail on Android
smime.p7s
Description: S/MIME cryptographic signature
