hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7180) RegionScannerImpl.next() is inefficient.
Date Tue, 04 Dec 2012 23:11:00 GMT

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

Lars Hofhansl commented on HBASE-7180:

Talked to Stack and Gregory C. offline. Will use the initial approach with a better name for
the "internal" next method.
> RegionScannerImpl.next() is inefficient.
> ----------------------------------------
>                 Key: HBASE-7180
>                 URL: https://issues.apache.org/jira/browse/HBASE-7180
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>         Attachments: 7180-0.94-SKETCH.txt, 7180-0.94-v1.txt
> We just came across a special scenario.
> For our Phoenix project (SQL runtime for HBase), we push a lot of work into HBase via
coprocessors. One method is to wrap RegionScanner in coprocessor hooks and then do processing
in the hook to avoid returning a lot of data to the client unnecessarily.
> In this specific case this is pretty bad. Since the wrapped RegionScanner's next() does
not "know" that it is called this way is still does all of this on each invocation:
> # Starts a RegionOperation
> # Increments the request count
> # set the current read point on a thread local (because generally each call could come
from a different thread)
> # Finally does the next on its StoreScanner(s)
> # Ends the RegionOperation
> When this is done in a tight loop millions of times (as is the case for us) it starts
to become significant.
> Not sure what to do about this, really. Opening this issue for discussion.
> One way is to extend the RegionScanner with an "internal" next() method of sorts, so
that all this overhead can be avoided. The coprocessor could call the regular next() methods
once and then just call the cheaper internal version.
> Are there better/cleaner ways?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message