[
https://issues.apache.org/jira/browse/CASSANDRA-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-7019:
---------------------------------------
Attachment: temp-plot.html
So I ran some ~day long tests, using the three new options from this ticket,
{{none}}, {{row}}, and {{cell}}, and the parent commit on trunk, which I
labeled {{control}}. I then grabbed all of the compaction throughput results
from the debug.log files, and attached a very basic graph here, as
temp-plot.html.
The 20% delete workload had a mixture of partition, row, and cell deletions. We
saw improved compaction throughput with 7019 when compared to trunk, and then
expected but acceptable drops in compaction performance with the more
aggressive tombstone removal options.
I will begin dumping all the raw data I have, as well as the stress graphs so
you can see how read/write perf is affected as well. I should note, at this
time I have found nothing that would prevent me from being +1 on this ticket.
> Improve tombstone compactions
> -----------------------------
>
> Key: CASSANDRA-7019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7019
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction
> Reporter: Marcus Eriksson
> Assignee: Branimir Lambov
> Labels: compaction, fallout
> Fix For: 3.x
>
> Attachments: 7019-2-system.log, 7019-debug.log, temp-plot.html
>
>
> When there are no other compactions to do, we trigger a single-sstable
> compaction if there is more than X% droppable tombstones in the sstable.
> In this ticket we should try to include overlapping sstables in those
> compactions to be able to actually drop the tombstones. Might only be doable
> with LCS (with STCS we would probably end up including all sstables)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
