[
https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577189#comment-13577189
]
Bryan Talbot commented on CASSANDRA-5182:
-----------------------------------------
Our use case doesn't require maximum effort to delete rows. What we ran into
was an unexpected interaction between two features: bloom filter tuned for low
read rate, and deleting tombstoned rows. With that configuration NO rows were
being removed.
As long as there is some reasonable effort to remove rows with bloom filter
disabled OR it's clearly known that a reasonable FP setting is required to
remove tombstones, I think we could have avoided a lot of headaches.
How does the new tombstone histogram feature in 1.2 affect this issue? If that
feature solves the problem already, maybe this fix is irrelevant.
> 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.0.7
> Reporter: Binh Van Nguyen
> Assignee: Yuki Morishita
> Fix For: 1.2.2
>
> Attachments: 5182-1.1.txt, 5182-1.2.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
