cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7272) Add "Major" Compaction to LCS
Date Mon, 11 Jan 2016 17:36:40 GMT


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:
>             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

View raw message