[
https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5182:
--------------------------------------
Attachment: 5182-1.1.txt
Binh,
Thanks for investigation. You are right that purging row depends on bloom
filter check, so if you have bloomfilter_fp_chance of 1.0, it is very likely
that the row is not going to be purged.
In 1.2 and above, we use AlwaysPresentFilter which always returns true for row
presence when fp_change is 1.0, so the row is never going to be purged when you
set fp_change=1.0.
Simple fix is attached. Instead of only hitting bloom filter, we check through
key cache and index file for actual row presence.
> Deletable rows are sometimes not removed during compaction
> ----------------------------------------------------------
>
> Key: CASSANDRA-5182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5182
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.5
> Reporter: Binh Van Nguyen
> Assignee: Yuki Morishita
> Attachments: 5182-1.1.txt, test_ttl.tar.gz
>
>
> Our use case is write heavy and read seldom. To optimize the space used,
> we've set the bloom_filter_fp_ratio=1.0 That along with the fact that each
> row is only written to one time and that there are more than 20 SSTables
> keeps the rows from ever being compacted. Here is the code:
> https://github.com/apache/cassandra/blob/cassandra-1.1/src/java/org/apache/cassandra/db/compaction/CompactionController.java#L162
> We hit this conner case and because of this C* keeps consuming more and more
> space on disk while it should not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
