Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # user - HBase random read performance


Copy link to this message
-
Re: 答复: HBase random read performance
lars hofhansl 2013-04-16, 14:55
This fundamentally different, though. A scanner by default scans all regions serially, because it promises to return all rows in sort order.
A multi get is already parallelized across regions (and hence accross region servers).
Before we do a lot of work here we should fist make sure that nothing else is wrong with OPs setup.
17s for 10000 is not right.
Ankit, what does the IO look like across the machines in the cluster while this is happening?

Since you pick 10000 rows at random your expectation is that entire set of rows will fit into the block cache? Is that the case?

-- Lars

________________________________
 From: Ted Yu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Monday, April 15, 2013 10:03 AM
Subject: Re: 答复: HBase random read performance
 

This is a related JIRA which should provide noticeable speed up:

HBASE-1935 Scan in parallel

Cheers

On Mon, Apr 15, 2013 at 7:13 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> I looked
> at src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java in
> 0.94
>
> In processBatchCallback(), starting line 1538,
>
>         // step 1: break up into regionserver-sized chunks and build the
> data structs
>         Map<HRegionLocation, MultiAction<R>> actionsByServer >           new HashMap<HRegionLocation, MultiAction<R>>();
>         for (int i = 0; i < workingList.size(); i++) {
>
> So we do group individual action by server.
>
> FYI
>
> On Mon, Apr 15, 2013 at 6:30 AM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
>> Doug made a good point.
>>
>> Take a look at the performance gain for parallel scan (bottom chart
>> compared to top chart):
>> https://issues.apache.org/jira/secure/attachment/12578083/FDencode.png
>>
>> See
>> https://issues.apache.org/jira/browse/HBASE-8316?focusedCommentId=13628300&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13628300for explanation of the two methods.
>>
>> Cheers
>>
>> On Mon, Apr 15, 2013 at 6:21 AM, Doug Meil <[EMAIL PROTECTED]
>> > wrote:
>>
>>>
>>> Hi there, regarding this...
>>>
>>> > We are passing random 10000 row-keys as input, while HBase is taking
>>> around
>>> > 17 secs to return 10000 records.
>>>
>>>
>>> ….  Given that you are generating 10,000 random keys, your multi-get is
>>> very likely hitting all 5 nodes of your cluster.
>>>
>>>
>>> Historically, multi-Get used to first sort the requests by RS and then
>>> *serially* go the RS to process the multi-Get.  I'm not sure of the
>>> current (0.94.x) behavior if it multi-threads or not.
>>>
>>> One thing you might want to consider is confirming that client behavior,
>>> and if it's not multi-threading then perform a test that does the same RS
>>> sorting via...
>>>
>>>
>>> http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#
>>> getRegionLocation%28byte[<http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#getRegionLocation%28byte[>
>>> ]%29
>>>
>>> …. and then spin up your own threads (one per target RS) and see what
>>> happens.
>>>
>>>
>>>
>>> On 4/15/13 9:04 AM, "Ankit Jain" <[EMAIL PROTECTED]> wrote:
>>>
>>> >Hi Liang,
>>> >
>>> >Thanks Liang for reply..
>>> >
>>> >Ans1:
>>> >I tried by using HFile block size of 32 KB and bloom filter is enabled.
>>> >The
>>> >random read performance is 10000 records in 23 secs.
>>> >
>>> >Ans2:
>>> >We are retrieving all the 10000 rows in one call.
>>> >
>>> >Ans3:
>>> >Disk detai:
>>> >Model Number:       ST2000DM001-1CH164
>>> >Serial Number:      Z1E276YF
>>> >
>>> >Please suggest some more optimization
>>> >
>>> >Thanks,
>>> >Ankit Jain
>>> >
>>> >On Mon, Apr 15, 2013 at 5:11 PM, 谢良 <[EMAIL PROTECTED]> wrote:
>>> >
>>> >> First, it's probably helpless to set block size to 4KB, please refer
>>> to
>>> >> the beginning of HFile.java:
>>> >>
>>> >>  Smaller blocks are good
>>> >>  * for random access, but require more memory to hold the block index,
>>> >>and
>>> >> may
>>> >>  * be slower to create (because we must flush the compressor stream at