[
https://issues.apache.org/jira/browse/PHOENIX-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani reopened PHOENIX-7229:
-----------------------------------
HBASE-27241 is only present on hbase 2.5+ versions, hence hbase 2.4 based
builds fail if we try to access bloom filter metrics with IT test.
Reopening the Jira to remove BloomFilterIT test, we can figure out how best to
write test later, after 5.2.0 release.
> Leverage bloom filters for single key point lookups
> ---------------------------------------------------
>
> Key: PHOENIX-7229
> URL: https://issues.apache.org/jira/browse/PHOENIX-7229
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.1.3
> Reporter: Tanuj Khurana
> Assignee: Tanuj Khurana
> Priority: Major
> Fix For: 5.2.0
>
>
> PHOENIX-6710 enabled bloom filters by default when Phoenix tables are
> created. However, we were not making use of it because Phoenix translates
> point lookups to scans with the scan range [startkey, stopkey) where startkey
> is inclusive and is equal to the row key and stopkey is exclusive and is the
> next key after the row key.
> This fails the check inside the hbase code in
> [StoreFileReader#passesBloomFilter|https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileReader.java#L245-L250]
> because it applies bloom filter only to scans which are gets and a scan is a
> GET only if startkey = stopkey and both are inclusive. This is defined here
> [Scan#isGetScan|https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java#L253-L255]
> We recently have some customers whose use case involves doing point lookups
> where the row key is not going to be present in the table. Bloom filters are
> ideal for those use cases.
> We can change our scan range for point lookups to leverage Bloom filters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
