cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7019) Major tombstone compaction
Date Thu, 25 Sep 2014 15:16:34 GMT

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

Carl Yeksigian commented on CASSANDRA-7019:
-------------------------------------------

For LCS, we might be artifically penalizing early tokens. What if we started at the highest
level which we are currently storing data in instead of at L1? It will be a good proxy for
the size of the data that we are currently storing, and it will avoid unnecessarily recompacting
data because we placed it in such a low level.

I'm +1 to [~jjordan]'s proposal to change the default to this; I'd rather just add an option
to compact to start minor compactions instead of adding a new command.

> Major tombstone compaction
> --------------------------
>
>                 Key: CASSANDRA-7019
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7019
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>              Labels: compaction
>             Fix For: 3.0
>
>
> It should be possible to do a "major" tombstone compaction by including all sstables,
but writing them out 1:1, meaning that if you have 10 sstables before, you will have 10 sstables
after the compaction with the same data, minus all the expired tombstones.
> We could do this in two ways:
> # a nodetool command that includes _all_ sstables
> # once we detect that an sstable has more than x% (20%?) expired tombstones, we start
one of these compactions, and include all overlapping sstables that contain older data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message