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 michael_segel@hotmail.com
 designates 65.55.111.112 as permitted sender)
Message-ID: <BLU0-SMTP140C7D3EDED3692655849568F540@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Region hot spotting
From: Michael Segel <michael_segel@hotmail.com>
In-Reply-To: 
 <CAAT7MkozVXJCRGv6vO1HEWqoHNPPMmvaPySg3wv_ryogQQxxUQ@mail.gmail.com>
Date: Wed, 21 Nov 2012 15:21:34 -0600
Content-Transfer-Encoding: quoted-printable
References: <50ac8237.6a00450a.218d.49e2SMTPIN_ADDED@mx.google.com>
 <CAAT7MkqyW8DXt8XjMawNSQgKcY_htVUBVSqNzAvvRphx-HV-Vg@mail.gmail.com>
 <CAMVC6RNrcxys+jG5iqQD9FSNt3HRzY7NeRA+bCJU+4uoS-wcPA@mail.gmail.com>
 <CAAT7MkozVXJCRGv6vO1HEWqoHNPPMmvaPySg3wv_ryogQQxxUQ@mail.gmail.com>
To: user@hbase.apache.org

Salting is not a good idea and I don't know why people suggest it.=20

Case in point.... you want to fetch a single row/record back. Because =
the salt is arbitrary, you will need to send N number of get()s one for =
each salt value.=20
Doing a simple one way hash of the data, even appending the data, would =
be a better idea. Note that if you are worried about key length, you can =
do the hash and take the first N bytes and then append the row to it. It =
should give you enough of a spread of hash values that you don't have to =
worry about hotspots.=20

HTH

-Mike

On Nov 21, 2012, at 2:44 AM, ramkrishna vasudevan =
<ramkrishna.s.vasudevan@gmail.com> wrote:

> Hi
> This link is pretty much useful.  But still there too it says if you =
dont
> pre split you need to wait for the salting to help you from =
hotspotting
> till the region gets splitted.
>=20
> Mohammad just pointing this to say the usefulness of presplitting
> definitely your's is a good pointer to Ajay. :)
>=20
> Regards
> Ram
>=20
> On Wed, Nov 21, 2012 at 1:59 PM, Mohammad Tariq <dontariq@gmail.com> =
wrote:
>=20
>> Hello Ajay,
>>=20
>> You can use 'salting' if you don't want to presplit your table. You =
might
>> this link useful :
>>=20
>> =
http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting=
-despite-writing-records-with-sequential-keys/
>>=20
>> HTH
>>=20
>> Regards,
>>    Mohammad Tariq
>>=20
>>=20
>>=20
>> On Wed, Nov 21, 2012 at 1:49 PM, ramkrishna vasudevan <
>> ramkrishna.s.vasudevan@gmail.com> wrote:
>>=20
>>> Hotspotting is bound to happen until the region starts splitting and =
gets
>>> assigned to diff region servers.
>>>=20
>>> Regards
>>> Ram
>>>=20
>>> On Wed, Nov 21, 2012 at 12:49 PM, Ajay Bhosle
>>> <ajay.bhosle@relianceada.com>wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>>=20
>>>>=20
>>>> I am inserting some data in hbase which is getting hot spotted in a
>>>> particular server. The format of the row key is (0 or
>>>> 1)|[timestamp]_[sequence].  Basically I want to add log information =
to
>>>> hbase
>>>> and search the records based on range of dates.
>>>>=20
>>>>=20
>>>>=20
>>>> Can someone suggest any configuration changes or any ideas on how =
the
>> row
>>>> key should be design. I do not want to specify the splits while
>> creating
>>>> table.
>>>>=20
>>>>=20
>>>>=20
>>>> Thanks
>>>>=20
>>>> Ajay
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> The information contained in this electronic message (email) and =
any
>>>> attachments to this email are intended for the exclusive use of the
>>>> addressee(s) and access to this email by any one else is =
unauthorised.
>>> The
>>>> email may contain proprietary, confidential or privileged =
information
>> or
>>>> information relating to Reliance Group. If you are not the intended
>>>> recipient, please notify the sender by telephone, fax, or return =
email
>>> and
>>>> delete this communication and any attachments thereto, immediately =
from
>>>> your computer. Any dissemination, distribution, or copying of this
>>>> communication and the attachments thereto (in whole or part), in =
any
>>>> manner, is strictly prohibited and actionable at law. The recipient
>>>> acknowledges that emails are susceptible to alteration and their
>>> integrity
>>>> can not be guaranteed and that Company does not guarantee that any
>> e-mail
>>>> is virus-free and accept no liability for any damage caused by any
>> virus
>>>> transmitted by this email.
>>>>=20
>>>=20
>>=20