[
https://issues.apache.org/jira/browse/CASSANDRA-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590601#comment-13590601
]
Jonathan Ellis commented on CASSANDRA-5182:
-------------------------------------------
bq. So overall I do like the last patch attached by Yuki. Of course, the
solution of just saying "you shouldn't disable bloom filters on workloads that
perform deletes" works too, and I wouldn't oppose it, but it doesn't have my
preference because I'm always a bit afraid of solving an issue by saying "don't
do this", as it usually end up in people getting bitten first and hearing they
shouldn't have done it second.
The problem is it's not as simple as "people get bitten if we don't
getPosition, and don't if we do" -- they get bitten either way, and IMO the
bite from getPosition is worse, since it will destroy compaction performance
for any workload where index doesn't fit entirely in ram, which makes BF
disabling almost useless. But if we say "only disable BF where you're not
doing deletes," it has a legitimate if narrow use case.
> 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.3
>
> 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
