[ASTERIXDB-2128] Bloom Filter for LSMBTree is totally useless

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Component/s: IDX - Indexes, STO - Storage
• Assignee: Chen Luo
• Reporter: Chen Luo
• Created: 06/Oct/17 23:22
• Updated: 30/Nov/17 05:19
• Resolved: 30/Nov/17 05:19

Description

We use bloom filters on primary index (as LSMBTree) to skip unnecessary pk lookups on some disk components. The idea is that if the bloom filter reports false on some pk, we totally skip searching that disk component.

However, in our current complicated BTree/LSMBTree software stack, the bloom filter is completely useless (in terms of saving I/Os). Take a look at LSMBTreePointSearchCursor. At line 74, we first call btreeAccessors[i].search(rangeCursors[i], predicate), and then call BloomFilterAwareBTreePointSearchCursor.hasNext() which performs bloom filter check. However, the call sequence is wrong. Actually, btreeAccessors[i].search has already searched the primary key against the BTree, from the root down to the leaf, rendering bloom filter completely useless in this case.