You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Anoop Sam John (JIRA)" <ji...@apache.org> on 2018/02/07 06:08:00 UTC

[jira] [Commented] (HBASE-17339) Scan-Memory-First Optimization for Get Operations

    [ 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)