cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Alexander Spitzer (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6851) Improve anticompaction after incremental repair
Date Sun, 06 Jul 2014 03:26:34 GMT


Russell Alexander Spitzer commented on CASSANDRA-6851:

Updated branch at
Sorry for the delay again but DSE waits for no one. 

I've moved the grouping function to AbstractCompactionStrategy with the default implementation
being the numeric grouper using a group size of 2. For Leveled compaction strategy I overrode
the function to first bin by level, and then group.

I've also added a few tests for anti-compacting a table with 10 sstables and a test for Leveled
Compaction Strat to make sure it's grouping method does not return groups with sstables from
mixed levels.

I tried to fix up most of the style issues and fix up the imports so they are more consistent
(no wildcards).

As usual please let me see anything out of place or anything that can use improvement and
I'll continue to try to get IDEA to respect my chosen style conventions. 

> Improve anticompaction after incremental repair
> -----------------------------------------------
>                 Key: CASSANDRA-6851
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Marcus Eriksson
>            Assignee: Russell Alexander Spitzer
>            Priority: Minor
>              Labels: compaction, lhf
>             Fix For: 2.1.1
> After an incremental repair we iterate over all sstables and split them in two parts,
one containing the repaired data and one the unrepaired. We could in theory double the number
of sstables on a node.
> To avoid this we could make anticompaction also do a compaction, for example, if we are
to anticompact 10 sstables, we could anticompact those to 2.
> Note that we need to avoid creating too big sstables though, if we anticompact all sstables
on a node it would essentially be a major compaction.

This message was sent by Atlassian JIRA

View raw message