Compaction is ScyllaDB’s storage-maintenance process for immutable SSTables. Updates and deletes leave older values or tombstones on disk; compaction merges SSTables into newer files, retaining the newest values and removing obsolete rows when safe. Fewer redundant files reduce the data reads must examine, helping read performance and controlling disk growth. section 6.2.3 section 8.4
Figure 6.6 Compaction combines multiple SSTables into a newer SSTable, skipping obsolete rows and eligible-for-deletion tombstones.
The merge creates a replacement SSTable while skipping superseded rows and tombstones that are eligible for deletion. section 6.2.3
Deletes need extra care. A tombstone remains until gc_grace_seconds has elapsed so that nodes have time to learn about the deletion. Removing it too early can allow deleted data to reappear on a node that missed the tombstone; retaining it longer consumes space. Run repair within this period to synchronize tombstones. section 6.2.3 section 6.6
Compaction can run in two ways:
- Minor compaction runs automatically against selected SSTables according to the table’s configured compaction strategy. section 6.2.3 section 8.4.1
- Major compaction is requested with nodetool compact and compacts all SSTables for a table; use it cautiously because it consumes resources and can make later minor compactions less effective. section 9.3.3
A strategy determines which SSTables are grouped. Size-tiered compaction strategy (STCS), the default, groups similarly sized files and produces fewer, larger SSTables, but may require substantial temporary disk space. Leveled compaction strategy (LCS) organizes fixed-size SSTables into levels. Time-window compaction strategy (TWCS) groups time-series data by windows. section 8.4.1
Repeated profile updates
If an author’s bio is written, flushed, and updated several times, versions can be scattered across many SSTables. Reads must inspect those files to select the newest bio. Compaction merges the relevant files and removes the obsolete versions when the newer version participates in the merge. section 8.4.1
Monitor active work with nodetool compactionstats. It reports ongoing operations, affected keyspaces and tables, and the amount of data being compacted. A sustained backlog or heavy continuous compaction can contribute to slow cluster performance because resources spent compacting are unavailable for reads. section 9.3.3
