[
https://issues.apache.org/jira/browse/CASSANDRA-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092345#comment-15092345
]
Carl Yeksigian commented on CASSANDRA-7272:
-------------------------------------------
The L1 sstables won't overlap with the data in the L2, so none of the L2
sstables should be selected due to overlap for the compaction with L1 sstables.
Since we don't know exactly how many sstables we are going to compact to when
we start the major compaction, we don't know which level would be optimal at
the beginning, which is why we do layering instead.
If you are seeing a performance impact after performing a major LCS compaction,
can you open a new ticket so that we can investigate?
> Add "Major" Compaction to LCS
> ------------------------------
>
> Key: CASSANDRA-7272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7272
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Assignee: Marcus Eriksson
> Priority: Minor
> Labels: compaction, docs-impacting
> Fix For: 2.2.0 beta 1
>
>
> LCS has a number of minor issues (maybe major depending on your perspective).
> LCS is primarily used for wide rows so for instance when you repair data in
> LCS you end up with a copy of an entire repaired row in L0. Over time if you
> repair you end up with multiple copies of a row in L0 - L5. This can make
> predicting disk usage confusing.
> Another issue is cleaning up tombstoned data. If a tombstone lives in level
> 1 and data for the cell lives in level 5 the data will not be reclaimed from
> disk until the tombstone reaches level 5.
> I propose we add a "major" compaction for LCS that forces consolidation of
> data to level 5 to address these.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
