cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5936) Improve the way we pick L0 compaction candidates
Date Tue, 22 Oct 2013 21:33:50 GMT

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

T Jake Luciani commented on CASSANDRA-5936:
-------------------------------------------

[~mericsson] Have you looked at all at promoting any L0 sstable to a level with no overlaps?
 LevelDB does this and I think it would give LCS a lot more breathing room before it starts
hitting the wall.  It would also promote more cross level parallel compactions.



> Improve the way we pick L0 compaction candidates
> ------------------------------------------------
>
>                 Key: CASSANDRA-5936
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5936
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>             Fix For: 2.1
>
>
> We could improve the way we pick compaction candidates in level 0 in LCS.
> The most common way for us to get behind on compaction is after repairs, we should exploit
the fact that the streamed sstables are most often very narrow in range since the other nodes
in the ring will have a similar sstable-range-distribution. We should in theory be able to
do 10 concurrent compactions involving L1 - ie, partition L0 in buckets defined by the sstables
in L1 to only keep one L1 SSTable busy for every compaction (be it L1 to L2 or L0 to L1).
> we will need some heuristics on when to select candidates from the buckets and when to
do it the old way (since L0 sstables can span several L1 sstables)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message