hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (HBASE-5000) Speed up simultaneous reads of a block when block caching is turned off
Date Mon, 12 Dec 2011 05:40:31 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167360#comment-13167360
] 

Lars Hofhansl edited comment on HBASE-5000 at 12/12/11 5:39 AM:
----------------------------------------------------------------

+1 on documenting. Could state there that block caching can be disabled on a per scan bases,
and in fact should be disabled if the data scanned is known (or likely to) not to fit in the
cache.

Generally shouldn't aim for loading the same block only once per JVM if requested by multiple
threads at the same time? Could do some kind of reference counting to keep track of other
requesters, or register a call back when the block is loaded...

                
      was (Author: lhofhansl):
    +1 on documenting. Could state there, that block caching can be disabled on a per scan
bases, and in fact should be disable if the data scanned is known (or likely to) not to fit
in the cache.

Generally shouldn't aim for loading the same block only once per JVM if requested by multiple
threads at the same time? Could do some kind of reference counting to keep track of other
requesters, or register a call back when the block is loaded...

                  
> Speed up simultaneous reads of a block when block caching is turned off
> -----------------------------------------------------------------------
>
>                 Key: HBASE-5000
>                 URL: https://issues.apache.org/jira/browse/HBASE-5000
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Mikhail Bautin
>            Assignee: Mikhail Bautin
>            Priority: Minor
>
> With block caching, when one client starts reading a block and another one comes around
asking for the same block, the second client waits for the first one to finish reading and
returns the block from cache. This is achieved by locking on the block offset using IdLock,
a "sparse lock" primitive allowing to lock on arbitrary long numbers. However, in case there
is no block caching, there is no reason to wait for other clients that are reading the same
block. One challenge optimizing this that we don't necessary have accurate information about
whether other HFile API clients interested in the block would cache it.
> Setting priority as minor, as it is very unusual to turn off block caching.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message