-
Notifications
You must be signed in to change notification settings - Fork 613
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(storage): maintain per table bloom filter inside a SST #7187
Conversation
Codecov Report
@@ Coverage Diff @@
## main #7187 +/- ##
==========================================
+ Coverage 73.13% 73.15% +0.02%
==========================================
Files 1055 1054 -1
Lines 168781 168518 -263
==========================================
- Hits 123430 123274 -156
+ Misses 45351 45244 -107
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@@ -58,7 +59,7 @@ use super::{HummockError, HummockResult}; | |||
|
|||
const DEFAULT_META_BUFFER_CAPACITY: usize = 4096; | |||
const MAGIC: u32 = 0x5785ab73; | |||
const VERSION: u32 = 1; | |||
const VERSION: u32 = 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make the changes introduced by this PR backward compactible, modifying the VERSION
const is not enough and we need to do the following things:
- Change
SstableMeta::decode
to use different implementations to decode bloom filter based on the version. - When checking bloom filter in
surely_not_have_hashvalue
, using different implementations to check bloom filter based on the meta version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, but this will bring some duplicated code, maybe we can update version and remove duplicate code later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unavoidable if we want to ensure backward compatibility unless we fully deprecate a released version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can keep the BTreeMap structure for bloom filter in SstableMeta and simply put only one entry in the BTreeMap for version 1. Then we use if-else in the decode and surely_not_have_hashvalue implementation to decide how to populate and check the BTreeMap.
let entry = self.user_key_hashes.entry(table_id); | ||
|
||
match entry { | ||
std::collections::btree_map::Entry::Vacant(e) => { | ||
e.insert(vec![key_hash]); | ||
} | ||
std::collections::btree_map::Entry::Occupied(mut e) => { | ||
let current_key_hashes = e.get_mut(); | ||
current_key_hashes.push(key_hash); | ||
} | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor: can be simplified to:
self.user_key_hashes
.entry(table_id)
.or_default()
.push(key_hash);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, got it.
@@ -353,7 +372,8 @@ impl SstableMeta { | |||
.map(| tombstone| 16 + tombstone.start_user_key.encoded_len() + tombstone.end_user_key.encoded_len()) | |||
.sum::<usize>() | |||
+ 4 // bloom filter len | |||
+ self.bloom_filter.len() | |||
+ 8 * self.bloom_filter.len() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
table_id is u32
. Should this be 4 * self.bloom_filter.len()
?
@@ -353,7 +372,8 @@ impl SstableMeta { | |||
.map(| tombstone| 16 + tombstone.start_user_key.encoded_len() + tombstone.end_user_key.encoded_len()) | |||
.sum::<usize>() | |||
+ 4 // bloom filter len | |||
+ self.bloom_filter.len() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prior to this PR, we use bloom_filter.len()
to calculate the bloom filter size but it is no longer the case. Please find all the usage of bloom_filter.len()
and change them accordingly. I did a quick search and we need to change them in builder.rs
and sst_dump.rs
.
Is there any test could show that this feature could improve bloom-filter hit rate ? |
I do not think maintaining a complex bloom-filter is necessary ..... |
After some offline discussion, we can XOR with |
1 similar comment
After some offline discussion, we can XOR with |
I opened a new PR because the solution changed, so close this one. |
I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
As we have remove
table_id
andVnode
in bloom filter key, there may be some corner case that in one sst, two table have same key. So we can maintain per table bloom filter inside a SST.Checklist
./risedev check
(or alias,./risedev c
)Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.
Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)
part of #6391