This compaction strategy aims to take the place of all three existing Cassandra Compaction Strategies.
It works by first consolidating sparse data (sorted runs that span the entire token range but are small) until it reaches a configruable target amount of data (by default 16 * target size = 8 GiB). Then it promotes these sorted runs to be "dense" sorted runs.
Dense runse are considered for compaction via density tiering rather than size. The node's range is broken up into the target work size and then compactions are performed "across" the levels. This stage uses a different tiering factor because you often want control over how young versus old data compacts with itself.
Phase 1: Flushes
- Flush products are very small and very sparse. They overlap with everything and are generally a bummer.
- Output: Attempt to split the flush products into split_range size sorted run (will probably not succeed).
Phase 2: Sparse Run Consolidation
- Compact across the entire token range.
- More or less straight up size tiering, with some automatic min_threshold adjustment based on flush rate.
- Output: Split the sparse products into split_range size sorted runs.
Phase 3: Dense Run De-overlapping
- Compact across pieces of sorted runs split evenly into work_size splits of the node's data.
- Sorted runs are tiered with a factor of min_threshold_levels (4), subject to a constraint that the overlaps remain under max_read_per_read (10). If we do exceed max_read_per_read the youngest min_threshold_levels levels compact.
- Major compaction across dense and sorted runs occurs on two conditions and any full compactions are spread out over an target_rewrite_interval_in_seconds of time (4 hours) and involves a target_work_unit_in_mb amount of data (8 GiB). This allows us to make progress even with only a target_work_unit_in_mb amount of disk space.
- Major Compaction Case #1: If old dense runs are found (by default 10 days old). This allows us to ensure that tombstones find their data within 10 days. Can be disabled by setting max_level_age_in_seconds to zero
- Major Compaction Case #2: A user has triggered a full compaction. Sparse runs are compacted immediately and dense runs will proceed along the interval (target_rewrite_interval_in_seconds).
Note The defaults are fine in almost all cases. You only need to tune these things if you want to disable some behavior or really want to optimize. Changes in write throughput are gracefully handled e.g. for bulk loading (once we observe 4 rapid flushes we will adjust the min threshold automatically).