cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <>
Subject Re: Impact of Changing Compaction Strategy
Date Fri, 15 Jan 2016 18:45:07 GMT
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:  ""
Date:  Friday, January 15, 2016 at 10:16 AM
To:  ""
Subject:  Impact of Changing Compaction Strategy


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?


Sent from Yahoo Mail on Android

View raw message