cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Alexander Spitzer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6851) Improve anticompaction after incremental repair
Date Mon, 19 May 2014 01:22:38 GMT

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

Russell Alexander Spitzer commented on CASSANDRA-6851:
------------------------------------------------------

I began working on this issue (and learning about the compaction paths) by grouping the repaired
and unrepaired tables and then calling a compaction on each group. This required me to add
a hook into AbstractCompactionTask for the results of a compaction operation so that I could
fulfill the return contract of doAntiCompaction. Currently it seems like the 2.1 tests are
not passing cleanly and I'm not sure of which issues might be related to my patch. I'm running
a bit short on time for this weekend so I'll keep working when I can find some time.

My major question for finishing this is what should we be using a threshold for an sstable
being to large? Should we let this be user configurable or put a static ceiling on the compaction?

As usual I would appreciate any advice or critique for my efforts thus far

Current work:
https://github.com/RussellSpitzer/cassandra/compare/CASSANDRA-6851

> Improve anticompaction after incremental repair
> -----------------------------------------------
>
>                 Key: CASSANDRA-6851
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6851
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>            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
(v6.2#6252)

Mime
View raw message