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 16:12:34 GMT

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

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

I was thinking L4, then L5 (as in this patch, currently). Ideally, we would pick the level
where all of the sstables would fit, but we don't know how many sstables will end up being
produced by the compaction in the end, so this seems like a compromise. This would be similar
to the thinking in CASSANDRA-6323.

> 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