[
https://issues.apache.org/jira/browse/CASSANDRA-21533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Yan updated CASSANDRA-21533:
---------------------------------
Test and Documentation Plan: 4.1PR:
https://github.com/apache/cassandra/pull/4961
Status: Patch Available (was: Open)
> Configurable compression algorithm for each LCS level
> -----------------------------------------------------
>
> Key: CASSANDRA-21533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21533
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
> Reporter: Yuqi Yan
> Assignee: Yuqi Yan
> Priority: Normal
> Fix For: 4.1.x, trunk
>
>
> Allow an LCS table to use a different sstable compressor per level. The most
> useful case: keep the high-churn L0 tier on a fast codec (LZ4) while deeper
> levels retain a high-ratio codec (Zstd). L0 is repeatedly rewritten by
> STCS-in-L0 and L0→L1 compactions, so paying full Zstd cost there wastes
> compaction CPU for data that is short-lived at that level; the ratio only
> matters once data settles into the deeper, stable levels.
> *Motivation*
> This generalizes the idea already accepted in CASSANDRA-15379
> ({{{}flush_compression{}}}), which flushes with fast LZ4 and lets compaction
> re-compress to the table codec. Today there is no way to keep the churny
> compaction tier on a fast codec — the table's single compressor applies to
> every level.
> *Proposed change*
> * New LCS compaction sub-option {{{}per_level_compression{}}}: a
> comma-separated {{level:CompressorClass}} list (e.g.
> {{{}'0:LZ4Compressor'{}}}). Levels not listed inherit the table
> {{{}compression{}}}.
> * Only the compressor _class_ is overridden; {{chunk_length_in_kb}} and
> {{min_compress_ratio}} are inherited from the table compression so chunk
> sizing stays consistent.
> * Applied in the compaction write path, keyed on the target sstable level.
>
> I'll share a patch for 4.1 targeting LCS and will create a trunk PR targeting
> both UCS / LCS. Not very sure how UCS handles the "level" concept if
> configured with size tiered like "T4" but I think the idea of using faster
> compression in shallow level for "L10" like setup still make sense
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
