No.  Per Store in each Region, there is an ebb and flow of StoreFiles. I was
just thinking that the slow table perhaps had may store files present.  I
was asking you to check it out by listing the hbase directory content.

St.Ack

2010/1/20 <[email protected]>

> More region means more store files?
> More and more store files will increase query time even after adding more
> region servers, right?
>
> Fleming Chiu(邱宏明)
> 707-6128
> [email protected]
> 週一無肉日吃素救地球(Meat Free Monday Taiwan)
>
>
>
>
>
>                       [email protected]
>                      om                       To:
> [email protected]
>                      Sent by:                 cc:      (bcc: Y_823910/TSMC)
>                      [email protected]        Subject: Re: HBase reading
> performance
>                      om
>
>
>                      2010/01/21 12:49
>                      AM
>                      Please respond to
>                      hbase-user
>
>
>
>
>
>
> 2010/1/20 <[email protected]>
>
> > Hi,
> >
> > There are two tables table1,table2 in my cluster.
> >
> > table1 with two column family, 40 qualifier, 147 regions
> > table1 with two column family, 34 qualifier,  77 regions
> >
> > In no cache situation, 4 region sever with 2G RAM
> >
> > Get table1 1285 rows , taken 133 sec, avg:0.103
> > Get table2 1279 rows , taken  48 sec, avg:0.037
> >
> > More RAM makes hbase go faster, presuming some data locality.
>
> Can you figure what the difference between the two tables is?  Is it that
> the first has more store files (try doing a -lsr on the hbase directory in
> hdfs).  I presume the two tables are scattered over the same 4 node
> cluster?   So, its not a hw difference.
>
> St.Ack
>
>
>
> > As to the above result, taht table with more region took more time for
> > getting each row.
> > If we scale region server out to 15 machine(4 cores, 12G RAM),
> > will it be possible to lower the average time of table1?
> >
>
>
>
>
>
> > Thanks
> >
> > Fleming Chiu(邱宏明)
> > 707-6128
> > [email protected]
> > 週一無肉日吃素救地球(Meat Free Monday Taiwan)
> >
> >
> >
> >
> ---------------------------------------------------------------------------
> >                                                         TSMC PROPERTY
> >  This email communication (and any attachments) is proprietary
> information
> >  for the sole use of its
> >  intended recipient. Any unauthorized review, use or distribution by
> anyone
> >  other than the intended
> >  recipient is strictly prohibited.  If you are not the intended
> recipient,
> >  please notify the sender by
> >  replying to this email, and then delete this email and any copies of it
> >  immediately. Thank you.
> >
> >
> ---------------------------------------------------------------------------
> >
> >
> >
> >
>
>
>
>
>
>  ---------------------------------------------------------------------------
>                                                          TSMC PROPERTY
>  This email communication (and any attachments) is proprietary information
>  for the sole use of its
>  intended recipient. Any unauthorized review, use or distribution by anyone
>  other than the intended
>  recipient is strictly prohibited.  If you are not the intended recipient,
>  please notify the sender by
>  replying to this email, and then delete this email and any copies of it
>  immediately. Thank you.
>
>  ---------------------------------------------------------------------------
>
>
>
>

Reply via email to