cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6851) Improve anticompaction after incremental repair
Date Mon, 16 Jun 2014 19:47:02 GMT

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

Marcus Eriksson commented on CASSANDRA-6851:
--------------------------------------------

A few quick comments (I'll get a better look tomorrow or so);

First, i think we need to make it a bit smarter with regards to what sstables we merge, for
example, if we go totally random, we could end up with overlapping sstables in the leveled
manifest. I would probably make the grouping in the compaction strategies, so that we can
make the grouping leveling-aware for example

Second, code style: http://wiki.apache.org/cassandra/RunningCassandraInIDEA - braces on newlines,
inner classes should be capitalized

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

Mime
View raw message