Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of kiran.sarvabhotla@gmail.com
 designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADcMMgHa99ZkRHRtj8opL5MNNGxRYCA11_t4yBBpYW8_LgCXCA@mail.gmail.com>
References: 
 <CAMBJfVnO38-6iDMTyB1j8OfU_1QwydCWQqm9Yx4+VhZ9GZRbzg@mail.gmail.com>
	<CADcMMgHa99ZkRHRtj8opL5MNNGxRYCA11_t4yBBpYW8_LgCXCA@mail.gmail.com>
Date: Wed, 6 Mar 2013 12:30:04 +0530
Message-ID: 
 <CAMBJfVnSBYG0iTnJD=KSinurtW3o6ojdzNALAN=3FmA1E8z+dw@mail.gmail.com>
Subject: Re: Miserable Performance of gets
From: kiran <kiran.sarvabhotla@gmail.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7bf0c332bcd6d304d73c231f

--047d7bf0c332bcd6d304d73c231f
Content-Type: text/plain; charset=ISO-8859-1

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

--047d7bf0c332bcd6d304d73c231f--