How do size-tiered and leveled compaction differ in a log-structured store, and which workloads suit each?
answer
- merge similar sizes vs levels
- overlapping vs non-overlapping
- fewer rewrites vs fewer files
- write-heavy vs read and update heavy
basics
~20 sSize-tiered compaction merges groups of similar-sized files into bigger ones, rewriting data rarely but leaving many overlapping files. Leveled compaction keeps each level's files non-overlapping, so reads touch few files and less stale data lingers, at the cost of rewriting data more often.
solid answer
~50 s**Size-tiered**: when several files of similar size accumulate, merge them into one larger file. Data is rewritten only a few times, so **write amplification is low**, which suits write-heavy ingestion. But a key can live in many overlapping files, so reads may touch many, stale versions linger until files of similar size meet, and a big merge needs a lot of **temporary free space**. **Leveled**: files are organised into levels, each several times larger than the last, and within a level **files do not overlap**. A file moving down is merged with the overlapping files of the next level. A read touches at most about one file per level, and superseded data is cleaned up quickly, so **read and space amplification are low**. The price is **more rewriting**, as data moves through every level. Leveled suits read-heavy and update- or delete-heavy workloads; size-tiered suits append-mostly, write-heavy ones. Many engines now offer hybrids that can be tuned between the two.
go deeper
Know the two strategies by name and that one merges similar-sized files while the other keeps files in non-overlapping levels.
Explain each mechanism and its effect on write, read and space amplification, and map each to a workload.
Choose and tune a strategy from measured write ratio, update rate, disk headroom and latency targets, and spot compaction backlog.
Be ready to set storage and performance budgets that follow from the chosen strategy and justify changing it on a live system.
## What any compaction strategy decides Flushes create a steady stream of new sorted files. A **compaction strategy** decides **which files to merge, and when**. That choice sets the balance between rewriting data (write amplification), the number of files a read touches (read amplification) and stale data on disk (space amplification). ## Size-tiered compaction - Files are grouped into **tiers of similar size**. - When enough files (a threshold such as four) accumulate in a tier, they are **merged into one larger file**, which joins the next tier. - Over time the store holds a few very large files and many smaller, newer ones. Properties: - **Low write amplification**: each byte is rewritten roughly once per tier it climbs. - **High read amplification**: a key updated over time can appear in files of every tier, and all of them overlap in key range. - **High space amplification**: superseded versions survive until files of similar size meet, and merging the largest files needs free space comparable to their size. ## Leveled compaction - Files are organised into **levels** L0, L1, L2…, each several times larger than the previous (a factor such as ten). - Within each level beyond the first, files hold **non-overlapping key ranges**. - When a level exceeds its target size, a file is picked and **merged with the overlapping files in the next level**. Properties: - **Low read amplification**: a point read checks at most about one file per level, plus the newest level. - **Low space amplification**: most data sits in the largest level, and stale versions are merged away quickly. - **High write amplification**: data is rewritten as it passes each level, each time together with overlapping data from the level below. ## Side by side | | size-tiered | leveled | |---|---|---| | merge trigger | several files of similar size | a level exceeds its target size | | overlap between files | yes, across all tiers | no, within a level | | write amplification | low | high | | read amplification | high | low | | space amplification | high, plus large temporary space | low | | good fit | write-heavy, append-mostly | read-heavy, update- and delete-heavy | | poor fit | frequent updates and deletes | very high sustained writes, immutable time series | ## Hybrids and tuning Modern engines increasingly treat the two as ends of a spectrum: tiered merging at the small, hot levels and leveled merging at the large ones, or a single strategy whose parameters move it between the two. The trade-off does not disappear; tuning chooses a point on it. ## How to choose 1. Measure the **write-to-read ratio** and how often keys are **updated or deleted**. 2. Check **free disk space headroom**: size-tiered needs room for its biggest merges. 3. Look at **read-latency targets**: leveled keeps tail latency lower. 4. For time-ordered data that expires, consider a **time-window** strategy instead. ## Interview angle Describe both mechanisms, place them on the write-read-space trade-off, map each to workloads, and mention that engines now offer hybrids.
- Why is size-tiered compaction a poor fit for data updated frequently?Each update adds a new version in a new small file, and old versions survive in large files until similar-sized files meet. Reads must merge many overlapping versions, and stale data takes up disk for a long time.
- Why does leveled compaction struggle under very high sustained writes?Every byte is rewritten as it moves through each level, merged with overlapping data below. If ingest outpaces that rewriting, files pile up in the top level, reads slow and the engine may throttle writes.
saying these in an interview costs you the question
- Saying leveled compaction has lower write amplification than size-tiered
- Choosing size-tiered for a workload dominated by updates and deletes
- Ignoring the free space size-tiered needs for large merges
- Believing a compaction strategy can avoid the trade-off entirely