[
https://issues.apache.org/jira/browse/HBASE-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16355000#comment-16355000
]
Anoop Sam John commented on HBASE-17339:
----------------------------------------
The BF blocks need NOT be always in memory. It depends on the cache size and
access pattern. By default if we have on heap LRU cache alone, all the index,
bloom and data blocks come to there and chances of any type of block miss is
possible. When one uses Bucket cache (We called it L2 but it not not really L2
any more), the data blocks will be in BC always and the on heap cache will keep
index, bloom blocks. More likely we may have the blocks always in cache but
this cache also size limited and so miss is possible. This issue is closed
now. Did not see much perf boost. This was/is an interesting issue..
> Scan-Memory-First Optimization for Get Operations
> -------------------------------------------------
>
> Key: HBASE-17339
> URL: https://issues.apache.org/jira/browse/HBASE-17339
> Project: HBase
> Issue Type: Improvement
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Priority: Major
> Attachments: HBASE-17339-V01.patch, HBASE-17339-V02.patch,
> HBASE-17339-V03.patch, HBASE-17339-V03.patch, HBASE-17339-V04.patch,
> HBASE-17339-V05.patch, HBASE-17339-V06.patch, read-latency-mixed-workload.jpg
>
>
> The current implementation of a get operation (to retrieve values for a
> specific key) scans through all relevant stores of the region; for each store
> both memory components (memstores segments) and disk components (hfiles) are
> scanned in parallel.
> We suggest to apply an optimization that speculatively scans memory-only
> components first and only if the result is incomplete scans both memory and
> disk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
