cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7272) Add "Major" Compaction to LCS
Date Thu, 26 Mar 2015 15:15:56 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382028#comment-14382028
] 

Carl Yeksigian commented on CASSANDRA-7272:
-------------------------------------------

Looks good, just a few comments:

For the SplittingSizeTieredCompactionWriter, it seems like we should be using the size of
the sstable to split instead of the number of partitions. If the partitions aren't equal sizes,
the sstables could end up not being distributed 50%, 25%, etc.

The MajorLevelCompactionStrategy doesn't skipAncestors for anything but the first metadatacollector;
we should keep the skipping ancestors around so that we can skip for all the other metadatacollectors
we create.

Nits:
  - AbstractCompactionStrategy has an extra import
  - CompactionManager has utils.* imports and a few specific utils imports; we should drop
the utils.* and include utils.JVMStabilityInspector
  - A few empty javadoc tags in CompactionAwareWriter
  - In StorageService,Proxy we should use "splitOutput" instead of "optOutput"

> Add "Major" Compaction to LCS 
> ------------------------------
>
>                 Key: CASSANDRA-7272
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7272
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: T Jake Luciani
>            Assignee: Marcus Eriksson
>            Priority: Minor
>              Labels: compaction, docs-impacting
>             Fix For: 3.0
>
>
> 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)

Mime
View raw message