hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Miserable Performance of gets
Date Wed, 06 Mar 2013 07:02:27 GMT
If you profiled it, where did you find the time being spent?
St.Ack


On Tue, Mar 5, 2013 at 11:00 PM, kiran <kiran.sarvabhotla@gmail.com> wrote:

> Yes we profiled the gets after completing the scan only. We have 12
> regionservers. Each table i am doing gets has 40 regions.
>
>
> On Wed, Mar 6, 2013 at 12:21 PM, Stack <stack@duboce.net> wrote:
>
> > On Tue, Mar 5, 2013 at 8:36 PM, kiran <kiran.sarvabhotla@gmail.com>
> wrote:
> >
> > > Dear All,
> > >
> > > I had some miserable experience with gets (batch gets) in hbase. I have
> > two
> > > tables with different rowkeys, columns are distributed across the two
> > > tables.
> > >
> > > Currently what I am doing is scan over one table and get all the
> rowkeys
> > in
> > > the first table matching my filter. Then issue a batch get on another
> > table
> > > to retrieve some columns. But even for 20 gets, the performance is like
> > > miserable (almost a second or two for 20 gets which is not acceptable).
> > > But, scanning even on few thousands of rows is getting completed in
> > > milliseconds.
> > >
> > >
> > What happens if you do those 20 batch gets in isolation, apart from the
> > scan?  Do you still have miserable performance?
> >
> > What is your cluster setup like?  How many nodes?  How many regions?
> >
> >
> >
> > > My concern is for about 20 gets if it takes second or two,
> > > How can it scale ??
> > >
> >
> > Normally it does not take this long.  Lets figure out what is going on on
> > your setup.
> >
> > St.Ack
> >
>
>
>
> --
> Thank you
> Kiran Sarvabhotla
>
> -----Even a correct decision is wrong when it is taken late
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message