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, 15 Jun 2014 22:54:01 GMT


Russell Alexander Spitzer commented on CASSANDRA-6851:

Gave this another go, this is another rough draft and I'll need to add a few more unit tests
to make sure it's behaving as schedule. 

I implemented a naive grouper which lets you just define a number of sstables to group together
during an anti compaction. For the final version of this patch we can determine a more clever
way of grouping together sstables.

Sorry it took me a while to get back to this, my weekends have been pretty devoted to DSE
what with the new release coming so soon. 

> 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