Not sure if these are what Jeff was referring to but as a workaround, you
can configure the following STCS compaction subproperties:
- min_threshold - set to 2 so that only a minimum of 2 similar-sized
sstables are required to trigger a minor compaction instead of the default 4
-
The deleting compaction strategy from protectwise
(https://github.com/protectwise/cassandra-util/blob/master/deleting-compaction-strategy/README.md)
was written (I believe) to solve a similar problem - business based deletion
rules to enable flexible TTLs. May want to glance at that.
Other
>
> With STCS, estimated droppable tombstones being always 0.0 (thus also no
> automatic single SSTable compaction may happen): Is this a matter of not
> writing with TTL? If yes, would enabling TTL with STCS improve the disk
> reclaim situation, cause then single SSTAble compactions will kick in?
Hello,
our top contributor from a data volume perspective is time series data. We are
running with STCS since our initial production deployment in 2014 with several
clusters with a varying number of nodes, but currently with max. 9 nodes per
single cluster per different region in AWS with
