Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Pankaj Misra <pankaj.misra@impetus.co.in>
To: "user@hbase.apache.org" <user@hbase.apache.org>
CC: "ankitjaincs06@gmail.com" <ankitjaincs06@gmail.com>
Subject: RE: HBase Writes With Large Number of Columns
Thread-Topic: HBase Writes With Large Number of Columns
Thread-Index: Ac4peV5TRio8w+y7Qfupr9jhjGPRMf//pVQAgABgzpP//6vsgIAAYHsV
Date: Mon, 25 Mar 2013 18:03:01 +0000
Message-ID: <51BE77A7231E9E488E58380AFBD7727225EF194C@mail1.impetus.co.in>
References: <51BE77A7231E9E488E58380AFBD7727225EF1879@mail1.impetus.co.in>
	<CALte62yG4-+KAdGXEA8q999PnERvQDMBUH33_cR4R4ckBDBLoQ@mail.gmail.com>
	<51BE77A7231E9E488E58380AFBD7727225EF18C6@mail1.impetus.co.in>,<CALte62xETOYuFo=WzaRFGXLTUCLC5BbiyRtGaNQcdkpXu8HKwg@mail.gmail.com>
In-Reply-To: 
 <CALte62xETOYuFo=WzaRFGXLTUCLC5BbiyRtGaNQcdkpXu8HKwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Yes Ted, you are right, we are having table regions pre-split, and we see t=
hat both regions are almost evenly filled in both the tests.

This does not seem to be a regression though, since we were getting good wr=
ite rates when we had lesser number of columns.

Thanks and Regards
Pankaj Misra


________________________________________
From: Ted Yu [yuzhihong@gmail.com]
Sent: Monday, March 25, 2013 11:15 PM
To: user@hbase.apache.org
Cc: ankitjaincs06@gmail.com
Subject: Re: HBase Writes With Large Number of Columns

Copying Ankit who raised the same question soon after Pankaj's initial
question.

On one hand I wonder if this was a regression in 0.94.5 (though unlikely).

Did the region servers receive (relatively) same write load for the second
test case ? I assume you have pre-split your tables in both cases.

Cheers

On Mon, Mar 25, 2013 at 10:18 AM, Pankaj Misra
<pankaj.misra@impetus.co.in>wrote:

> Hi Ted,
>
> Sorry for missing that detail, we are using HBase version 0.94.5
>
> Regards
> Pankaj Misra
>
>
> ________________________________________
> From: Ted Yu [yuzhihong@gmail.com]
> Sent: Monday, March 25, 2013 10:29 PM
> To: user@hbase.apache.org
> Subject: Re: HBase Writes With Large Number of Columns
>
> If you give us the version of HBase you're using, that would give us some
> more information to help you.
>
> Cheers
>
> On Mon, Mar 25, 2013 at 9:55 AM, Pankaj Misra <pankaj.misra@impetus.co.in
> >wrote:
>
> > Hi,
> >
> > The issue that I am facing is around the performance drop of Hbase, whe=
n
> I
> > was having 20 columns in a column family Vs now when I am having 40
> columns
> > in a column family. The number of columns have doubled and the
> > ingestion/write speed has also dropped by half. I am writing 1.5 KB of
> data
> > per row across 40 columns.
> >
> > Are there any settings that I should look into for tweaking Hbase to
> write
> > higher number of columns faster?
> >
> > I would request community's help to let me know how can I write to a
> > column family with large number of columns efficiently.
> >
> > Would greatly appreciate any help /clues around this issue.
> >
> > Thanks and Regards
> > Pankaj Misra
> >
> > ________________________________
> >
> >
> >
> >
> >
> >
> > NOTE: This message may contain information that is confidential,
> > proprietary, privileged or otherwise protected by law. The message is
> > intended solely for the named addressee. If received in error, please
> > destroy and notify the sender. Any use of this email is prohibited when
> > received in error. Impetus does not represent, warrant and/or guarantee=
,
> > that the integrity of this communication has been maintained nor that t=
he
> > communication is free of errors, virus, interception or interference.
> >
>
> ________________________________
>
>
>
>
>
>
> NOTE: This message may contain information that is confidential,
> proprietary, privileged or otherwise protected by law. The message is
> intended solely for the named addressee. If received in error, please
> destroy and notify the sender. Any use of this email is prohibited when
> received in error. Impetus does not represent, warrant and/or guarantee,
> that the integrity of this communication has been maintained nor that the
> communication is free of errors, virus, interception or interference.
>

________________________________


NOTE: This message may contain information that is confidential, proprietar=
y, privileged or otherwise protected by law. The message is intended solely=
 for the named addressee. If received in error, please destroy and notify t=
he sender. Any use of this email is prohibited when received in error. Impe=
tus does not represent, warrant and/or guarantee, that the integrity of thi=
s communication has been maintained nor that the communication is free of e=
rrors, virus, interception or interference.