[
https://issues.apache.org/jira/browse/CASSANDRA-9830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264264#comment-15264264
]
Paulo Motta commented on CASSANDRA-9830:
----------------------------------------
There a few situations when a previously disabled top-level bloom filter needs
to be reloaded:
- Anti-compaction causes previously unrepaired top-level sstable drop to L0
- Anti-compaction increases the number of levels in the repaired set (so
previously top-level repaired sstables are no longer top-level)
- disable_top_level_bloom_filter option is unset
- user changes compaction strategy to other strategy
Given that the main objective of this optimization is to reduce memory usage
and rebuilding bloom filters is quite expensive, rather than not generating (or
removing) top-level bloom filters on disk, it's more reasonable to only release
bloom filters from memory while still keeping them on disk for a potential
reload in the future.
Another benefit of keeping BFs on disk is to keep most of the logic within
{{LeveledCompactionStrategy}}, rather than having other sstables consumers
(such as tools like {{sstablelevelreset}}) being aware that a top-level sstable
may not have it's bloom filter component if this option is enabled to deal with
it accordingly.
One caveat is that when a new level L is created, overlapping sstables from L-1
must have it's bloom filter reloaded to avoid expensive seek when doing new
compactions. This is automatically done by "organic" compactions when they
replace compacted sstables from L-1. Since anti-compactions may create new-top
levels in the repaired set, we must explicitly check for overlapping sstables
in lower levels to reload their bloom filters if necessary. In order to avoid
doing this more expensive overlap check for every sstable added, I modified the
compaction manager to always use the bulk add method (addSSTables) (which is
overridden by {{LeveledCompactionStrategy}}) so we can perform this check fewer
times (specially when doing anti-compaction).
I rebased and added unit tests to cover edge cases mentioned above.
||trunk||
|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-9830]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9830-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9830-dtest/lastCompletedBuild/testReport/]|
Also resubmitted cstar_perf tests to make sure we're getting consistent results
(will post results later):
*
[majors|http://cstar.datastax.com/tests/id/ddf75066-0e23-11e6-979b-0256e416528f]
*
[minors|http://cstar.datastax.com/tests/id/e86f087c-0e23-11e6-979b-0256e416528f]
*
[repair|http://cstar.datastax.com/tests/id/da385b14-0e23-11e6-979b-0256e416528f]
> Option to disable bloom filter in highest level of LCS sstables
> ---------------------------------------------------------------
>
> Key: CASSANDRA-9830
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9830
> Project: Cassandra
> Issue Type: New Feature
> Components: Compaction
> Reporter: Jonathan Ellis
> Assignee: Paulo Motta
> Priority: Minor
> Labels: performance
> Fix For: 3.x
>
>
> We expect about 90% of data to be in the highest level of LCS in a fully
> populated series. (See also CASSANDRA-9829.)
> Thus if the user is primarily asking for data (partitions) that has actually
> been inserted, the bloom filter on the highest level only helps reject
> sstables about 10% of the time.
> We should add an option that suppresses bloom filter creation on top-level
> sstables. This will dramatically reduce memory usage for LCS and may even
> improve performance as we no longer check a low-value filter.
> (This is also an idea from RocksDB.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
