Is it necessary to set MD5 on rowkey?

[bigdata <bi...@outlook.com>]

Many articles tell me that MD5 rowkey or part of it is good method to balance the records stored in different parts. But If I want to search some sequential rowkey records, such as date as rowkey or partially. I can not use rowkey filter to scan a range of date value one time on the date by MD5. How to balance this issue? 
Thanks.

 		 	   		  

RE: Is it necessary to set MD5 on rowkey?

[bigdata <bi...@outlook.com>]

Thanks to all of you! 
Actually, I want to make some reports about device access times daily and some selected days range. I design a table like this:
row key:  date_deviceid
this rowkey can help me calculate daily login devices count. I can add a prefix (such as 2 digital bytes of MD5(date)), and calculate a special day quickly. But when I calculate for a range time, it is not suitable.It's hard to balance it because I think I have 50% for daily reports and another 50% for range reports.
But another question is I have a report about daily new deviceid count (never access system before), it means that I should use deviceid for search condition with all date. I've met several problems like this: I use a rowkey for one query but no way for another query. I should create another rowkey format for other query. But question is I can not create two original tables with different rowkey!!!
Any suggestions? Or better solutions for my questions? Thanks

> Subject: Re: Is it necessary to set MD5 on rowkey?
> From: michael_segel@hotmail.com
> Date: Tue, 18 Dec 2012 07:52:53 -0600
> To: user@hbase.apache.org
> 
> 
> Hi,
> 
> First, the use of a 'Salt' is a very, very bad idea and I would really hope that the author of that blog take it down.
> While it may solve an initial problem in terms of region hot spotting, it creates another problem when it comes to fetching data. Fetching data takes more effort.
> 
> With respect to using a hash (MD5 or SHA-1) you are creating a more random key that is unique to the record.  Some would argue that using MD5 or SHA-1 that mathematically you could have a collision, however you could then append the key to the hash to guarantee uniqueness. You could also do things like take the hash and then truncate it to the first byte and then append the record key. This should give you enough randomness to avoid hot spotting after the initial region completion and you could pre-split out any number of regions. (First byte 0-255 for values, so you can program the split... 
> 
> 
> Having said that... yes, you lose the ability to perform a sequential scan of the data.  At least to a point.  It depends on your schema. 
> 
> Note that you need to think about how you are primarily going to access the data.  You can then determine the best way to store the data to gain the best performance. For some applications... the region hot spotting isn't an important issue. 
> 
> Note YMMV
> 
> HTH
> 
> -Mike
> 
> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
> 
> > Hello,
> > 
> > There is middle term betwen sequecial keys (hot spoting risk) and md5
> > (heavy scan):
> >  * you can use composed keys with a field that can segregate data
> > (hostname, productname, metric name) like OpenTSDB
> >  * or use Salt with a limited number of values (example
> > substr(md5(rowid),0,1) = 16 values)
> >    so that a scan is a combination of 16 filters on on each salt values
> >    you can base your code on HBaseWD by sematext
> > 
> > http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> >       https://github.com/sematext/HBaseWD
> > 
> > Cheers,
> > 
> > 
> > 2012/12/18 bigdata <bi...@outlook.com>
> > 
> >> Many articles tell me that MD5 rowkey or part of it is good method to
> >> balance the records stored in different parts. But If I want to search some
> >> sequential rowkey records, such as date as rowkey or partially. I can not
> >> use rowkey filter to scan a range of date value one time on the date by
> >> MD5. How to balance this issue?
> >> Thanks.
> >> 
> >> 
> > 
> > 
> > 
> > 
> > -- 
> > Damien HARDY
> 
 		 	   		  

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

I think you missed the point. 
You seem to think that salting is ok. 
I want you to walk through an example so that we can discuss it. ;-)


On Dec 19, 2012, at 2:51 PM, lars hofhansl <lh...@yahoo.com> wrote:

> Doesn't Alex' blog post do that?
> 
> 
> 
> 
> ________________________________
> From: Michael Segel <mi...@hotmail.com>
> To: user@hbase.apache.org; lars hofhansl <lh...@yahoo.com> 
> Sent: Wednesday, December 19, 2012 11:46 AM
> Subject: Re: Is it necessary to set MD5 on rowkey?
> 
> Ok, 
> 
> Maybe I'm missing something.
> Why don't you walk me through the use of a salt example. 
> 
> 
> On Dec 19, 2012, at 12:37 PM, lars hofhansl <lh...@yahoo.com> wrote:
> 
>> I would disagree here.
>> It depends on what you are doing and blanket statements about "this is very, very bad" typically do not help.
>> 
>> Salting (even round robin) is very nice to distribute write load *and* it gives you a natural way to parallelize scans assuming scans are of reasonable size.
>> 
>> If the typical use case is point gets then hashing or inverting keys would be preferable. As usual: It depends.
>> 
>> -- Lars
>> 
>> 
>> 
>> ________________________________
>> From: Michael Segel <mi...@hotmail.com>
>> To: user@hbase.apache.org 
>> Sent: Tuesday, December 18, 2012 3:29 PM
>> Subject: Re: Is it necessary to set MD5 on rowkey?
>> 
>> Alex, 
>> And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets. 
>> 
>> Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact. 
>> 
>> There are other options like inverting the numeric key ... 
>> 
>> And of course doing nothing. 
>> 
>> Using a salt as part of the design pattern is bad. 
>> 
>> With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key. 
>> Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.
>> 
>> 
>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:
>> 
>>> Mike,
>>> 
>>> Please read *full post* before judge. In particular, "Hash-based
>>> distribution" section. You can find the same in HBaseWD small README file
>>> [1] (not sure if you read it at all before commenting on the lib). Round
>>> robin is mainly for explaining the concept/idea (though not only for that).
>>> 
>>> Thank you,
>>> Alex Baranau
>>> ------
>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>>> Solr
>>> 
>>> [1] https://github.com/sematext/HBaseWD
>>> 
>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>> <mi...@hotmail.com>wrote:
>>> 
>>>> Quick answer...
>>>> 
>>>> Look at the salt.
>>>> Its just a number from a round robin counter.
>>>> There is no tie between the salt and row.
>>>> 
>>>> So when you want to fetch a single row, how do you do it?
>>>> ...
>>>> ;-)
>>>> 
>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> @Mike:
>>>>> 
>>>>> I'm the author of that post :).
>>>>> 
>>>>> Quick reply to your last comment:
>>>>> 
>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>>> idea" in more specific way than "Fetching data takes more effort". Would
>>>> be
>>>>> helpful for anyone who is looking into using this approach.
>>>>> 
>>>>> 2) The approach described in the post also says you can prefix with the
>>>>> hash, you probably missed that.
>>>>> 
>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>>> Please re-read the question: the intention is to distribute the load
>>>> while
>>>>> still being able to do "partial key scans". The blog post linked above
>>>>> explains one possible solution for that, while your answer doesn't.
>>>>> 
>>>>> @bigdata:
>>>>> 
>>>>> Basically when it comes to solving two issues: distributing writes and
>>>>> having ability to read data sequentially, you have to balance between
>>>> being
>>>>> good at both of them. Very good presentation by Lars:
>>>>> 
>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>> ,
>>>>> slide 22. You will see how this is correlated. In short:
>>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>>> writes, while compromises ability to do range scans efficiently
>>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>>> scans (less efficiently than normal range scans, of course, but still
>>>> good
>>>>> enough in many cases) while providing worse distribution of writes
>>>>> 
>>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>>> could be derived from hashed values, etc.) you can balance between
>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>> 
>>>>> Hope this helps
>>>>> 
>>>>> Alex Baranau
>>>>> ------
>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>> -
>>>>> Solr
>>>>> 
>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>> michael_segel@hotmail.com>wrote:
>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>>> hope that the author of that blog take it down.
>>>>>> While it may solve an initial problem in terms of region hot spotting,
>>>> it
>>>>>> creates another problem when it comes to fetching data. Fetching data
>>>> takes
>>>>>> more effort.
>>>>>> 
>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>> random
>>>>>> key that is unique to the record.  Some would argue that using MD5 or
>>>> SHA-1
>>>>>> that mathematically you could have a collision, however you could then
>>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>>> things like take the hash and then truncate it to the first byte and
>>>> then
>>>>>> append the record key. This should give you enough randomness to avoid
>>>> hot
>>>>>> spotting after the initial region completion and you could pre-split out
>>>>>> any number of regions. (First byte 0-255 for values, so you can program
>>>> the
>>>>>> split...
>>>>>> 
>>>>>> 
>>>>>> Having said that... yes, you lose the ability to perform a sequential
>>>> scan
>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>> 
>>>>>> Note that you need to think about how you are primarily going to access
>>>>>> the data.  You can then determine the best way to store the data to gain
>>>>>> the best performance. For some applications... the region hot spotting
>>>>>> isn't an important issue.
>>>>>> 
>>>>>> Note YMMV
>>>>>> 
>>>>>> HTH
>>>>>> 
>>>>>> -Mike
>>>>>> 
>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>> wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>>> (heavy scan):
>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>> * or use Salt with a limited number of values (example
>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>    so that a scan is a combination of 16 filters on on each salt values
>>>>>>>    you can base your code on HBaseWD by sematext
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>     https://github.com/sematext/HBaseWD
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> 
>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>> 
>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>>> balance the records stored in different parts. But If I want to search
>>>>>> some
>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>>> not
>>>>>>>> use rowkey filter to scan a range of date value one time on the date
>>>> by
>>>>>>>> MD5. How to balance this issue?
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Damien HARDY
>>>>>> 
>>>>>> 

Re: Is it necessary to set MD5 on rowkey?

[lars hofhansl <lh...@yahoo.com>]

Doesn't Alex' blog post do that?




________________________________
 From: Michael Segel <mi...@hotmail.com>
To: user@hbase.apache.org; lars hofhansl <lh...@yahoo.com> 
Sent: Wednesday, December 19, 2012 11:46 AM
Subject: Re: Is it necessary to set MD5 on rowkey?
 
Ok, 

Maybe I'm missing something.
Why don't you walk me through the use of a salt example. 


On Dec 19, 2012, at 12:37 PM, lars hofhansl <lh...@yahoo.com> wrote:

> I would disagree here.
> It depends on what you are doing and blanket statements about "this is very, very bad" typically do not help.
> 
> Salting (even round robin) is very nice to distribute write load *and* it gives you a natural way to parallelize scans assuming scans are of reasonable size.
> 
> If the typical use case is point gets then hashing or inverting keys would be preferable. As usual: It depends.
> 
> -- Lars
> 
> 
> 
> ________________________________
> From: Michael Segel <mi...@hotmail.com>
> To: user@hbase.apache.org 
> Sent: Tuesday, December 18, 2012 3:29 PM
> Subject: Re: Is it necessary to set MD5 on rowkey?
> 
> Alex, 
> And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets. 
> 
> Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact. 
> 
> There are other options like inverting the numeric key ... 
> 
> And of course doing nothing. 
> 
> Using a salt as part of the design pattern is bad. 
> 
> With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key. 
> Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.
> 
> 
> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:
> 
>> Mike,
>> 
>> Please read *full post* before judge. In particular, "Hash-based
>> distribution" section. You can find the same in HBaseWD small README file
>> [1] (not sure if you read it at all before commenting on the lib). Round
>> robin is mainly for explaining the concept/idea (though not only for that).
>> 
>> Thank you,
>> Alex Baranau
>> ------
>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>> Solr
>> 
>> [1] https://github.com/sematext/HBaseWD
>> 
>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>> <mi...@hotmail.com>wrote:
>> 
>>> Quick answer...
>>> 
>>> Look at the salt.
>>> Its just a number from a round robin counter.
>>> There is no tie between the salt and row.
>>> 
>>> So when you want to fetch a single row, how do you do it?
>>> ...
>>> ;-)
>>> 
>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> @Mike:
>>>> 
>>>> I'm the author of that post :).
>>>> 
>>>> Quick reply to your last comment:
>>>> 
>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>> idea" in more specific way than "Fetching data takes more effort". Would
>>> be
>>>> helpful for anyone who is looking into using this approach.
>>>> 
>>>> 2) The approach described in the post also says you can prefix with the
>>>> hash, you probably missed that.
>>>> 
>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>> Please re-read the question: the intention is to distribute the load
>>> while
>>>> still being able to do "partial key scans". The blog post linked above
>>>> explains one possible solution for that, while your answer doesn't.
>>>> 
>>>> @bigdata:
>>>> 
>>>> Basically when it comes to solving two issues: distributing writes and
>>>> having ability to read data sequentially, you have to balance between
>>> being
>>>> good at both of them. Very good presentation by Lars:
>>>> 
>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>> ,
>>>> slide 22. You will see how this is correlated. In short:
>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>> writes, while compromises ability to do range scans efficiently
>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>> scans (less efficiently than normal range scans, of course, but still
>>> good
>>>> enough in many cases) while providing worse distribution of writes
>>>> 
>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>> could be derived from hashed values, etc.) you can balance between
>>>> distributing writes efficiency and ability to run fast range scans.
>>>> 
>>>> Hope this helps
>>>> 
>>>> Alex Baranau
>>>> ------
>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>> -
>>>> Solr
>>>> 
>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>> michael_segel@hotmail.com>wrote:
>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>> hope that the author of that blog take it down.
>>>>> While it may solve an initial problem in terms of region hot spotting,
>>> it
>>>>> creates another problem when it comes to fetching data. Fetching data
>>> takes
>>>>> more effort.
>>>>> 
>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>> random
>>>>> key that is unique to the record.  Some would argue that using MD5 or
>>> SHA-1
>>>>> that mathematically you could have a collision, however you could then
>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>> things like take the hash and then truncate it to the first byte and
>>> then
>>>>> append the record key. This should give you enough randomness to avoid
>>> hot
>>>>> spotting after the initial region completion and you could pre-split out
>>>>> any number of regions. (First byte 0-255 for values, so you can program
>>> the
>>>>> split...
>>>>> 
>>>>> 
>>>>> Having said that... yes, you lose the ability to perform a sequential
>>> scan
>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>> 
>>>>> Note that you need to think about how you are primarily going to access
>>>>> the data.  You can then determine the best way to store the data to gain
>>>>> the best performance. For some applications... the region hot spotting
>>>>> isn't an important issue.
>>>>> 
>>>>> Note YMMV
>>>>> 
>>>>> HTH
>>>>> 
>>>>> -Mike
>>>>> 
>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>> (heavy scan):
>>>>>> * you can use composed keys with a field that can segregate data
>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>> * or use Salt with a limited number of values (example
>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>   so that a scan is a combination of 16 filters on on each salt values
>>>>>>   you can base your code on HBaseWD by sematext
>>>>>> 
>>>>>> 
>>>>> 
>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>    https://github.com/sematext/HBaseWD
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> 
>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>> 
>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>> balance the records stored in different parts. But If I want to search
>>>>> some
>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>> not
>>>>>>> use rowkey filter to scan a range of date value one time on the date
>>> by
>>>>>>> MD5. How to balance this issue?
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Damien HARDY
>>>>> 
>>>>> 
>>> 

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Ok, 

Maybe I'm missing something.
Why don't you walk me through the use of a salt example. 


On Dec 19, 2012, at 12:37 PM, lars hofhansl <lh...@yahoo.com> wrote:

> I would disagree here.
> It depends on what you are doing and blanket statements about "this is very, very bad" typically do not help.
> 
> Salting (even round robin) is very nice to distribute write load *and* it gives you a natural way to parallelize scans assuming scans are of reasonable size.
> 
> If the typical use case is point gets then hashing or inverting keys would be preferable. As usual: It depends.
> 
> -- Lars
> 
> 
> 
> ________________________________
> From: Michael Segel <mi...@hotmail.com>
> To: user@hbase.apache.org 
> Sent: Tuesday, December 18, 2012 3:29 PM
> Subject: Re: Is it necessary to set MD5 on rowkey?
> 
> Alex, 
> And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets. 
> 
> Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact. 
> 
> There are other options like inverting the numeric key ... 
> 
> And of course doing nothing. 
> 
> Using a salt as part of the design pattern is bad. 
> 
> With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key. 
> Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.
> 
> 
> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:
> 
>> Mike,
>> 
>> Please read *full post* before judge. In particular, "Hash-based
>> distribution" section. You can find the same in HBaseWD small README file
>> [1] (not sure if you read it at all before commenting on the lib). Round
>> robin is mainly for explaining the concept/idea (though not only for that).
>> 
>> Thank you,
>> Alex Baranau
>> ------
>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>> Solr
>> 
>> [1] https://github.com/sematext/HBaseWD
>> 
>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>> <mi...@hotmail.com>wrote:
>> 
>>> Quick answer...
>>> 
>>> Look at the salt.
>>> Its just a number from a round robin counter.
>>> There is no tie between the salt and row.
>>> 
>>> So when you want to fetch a single row, how do you do it?
>>> ...
>>> ;-)
>>> 
>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> @Mike:
>>>> 
>>>> I'm the author of that post :).
>>>> 
>>>> Quick reply to your last comment:
>>>> 
>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>> idea" in more specific way than "Fetching data takes more effort". Would
>>> be
>>>> helpful for anyone who is looking into using this approach.
>>>> 
>>>> 2) The approach described in the post also says you can prefix with the
>>>> hash, you probably missed that.
>>>> 
>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>> Please re-read the question: the intention is to distribute the load
>>> while
>>>> still being able to do "partial key scans". The blog post linked above
>>>> explains one possible solution for that, while your answer doesn't.
>>>> 
>>>> @bigdata:
>>>> 
>>>> Basically when it comes to solving two issues: distributing writes and
>>>> having ability to read data sequentially, you have to balance between
>>> being
>>>> good at both of them. Very good presentation by Lars:
>>>> 
>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>> ,
>>>> slide 22. You will see how this is correlated. In short:
>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>> writes, while compromises ability to do range scans efficiently
>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>> scans (less efficiently than normal range scans, of course, but still
>>> good
>>>> enough in many cases) while providing worse distribution of writes
>>>> 
>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>> could be derived from hashed values, etc.) you can balance between
>>>> distributing writes efficiency and ability to run fast range scans.
>>>> 
>>>> Hope this helps
>>>> 
>>>> Alex Baranau
>>>> ------
>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>> -
>>>> Solr
>>>> 
>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>> michael_segel@hotmail.com>wrote:
>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>> hope that the author of that blog take it down.
>>>>> While it may solve an initial problem in terms of region hot spotting,
>>> it
>>>>> creates another problem when it comes to fetching data. Fetching data
>>> takes
>>>>> more effort.
>>>>> 
>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>> random
>>>>> key that is unique to the record.  Some would argue that using MD5 or
>>> SHA-1
>>>>> that mathematically you could have a collision, however you could then
>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>> things like take the hash and then truncate it to the first byte and
>>> then
>>>>> append the record key. This should give you enough randomness to avoid
>>> hot
>>>>> spotting after the initial region completion and you could pre-split out
>>>>> any number of regions. (First byte 0-255 for values, so you can program
>>> the
>>>>> split...
>>>>> 
>>>>> 
>>>>> Having said that... yes, you lose the ability to perform a sequential
>>> scan
>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>> 
>>>>> Note that you need to think about how you are primarily going to access
>>>>> the data.  You can then determine the best way to store the data to gain
>>>>> the best performance. For some applications... the region hot spotting
>>>>> isn't an important issue.
>>>>> 
>>>>> Note YMMV
>>>>> 
>>>>> HTH
>>>>> 
>>>>> -Mike
>>>>> 
>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>> (heavy scan):
>>>>>> * you can use composed keys with a field that can segregate data
>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>> * or use Salt with a limited number of values (example
>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>   so that a scan is a combination of 16 filters on on each salt values
>>>>>>   you can base your code on HBaseWD by sematext
>>>>>> 
>>>>>> 
>>>>> 
>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>     https://github.com/sematext/HBaseWD
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> 
>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>> 
>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>> balance the records stored in different parts. But If I want to search
>>>>> some
>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>> not
>>>>>>> use rowkey filter to scan a range of date value one time on the date
>>> by
>>>>>>> MD5. How to balance this issue?
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Damien HARDY
>>>>> 
>>>>> 
>>> 

Re: Is it necessary to set MD5 on rowkey?

[lars hofhansl <lh...@yahoo.com>]

I would disagree here.
It depends on what you are doing and blanket statements about "this is very, very bad" typically do not help.

Salting (even round robin) is very nice to distribute write load *and* it gives you a natural way to parallelize scans assuming scans are of reasonable size.

If the typical use case is point gets then hashing or inverting keys would be preferable. As usual: It depends.

-- Lars



________________________________
 From: Michael Segel <mi...@hotmail.com>
To: user@hbase.apache.org 
Sent: Tuesday, December 18, 2012 3:29 PM
Subject: Re: Is it necessary to set MD5 on rowkey?
 
Alex, 
And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets. 

Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact. 

There are other options like inverting the numeric key ... 

And of course doing nothing. 

Using a salt as part of the design pattern is bad. 

With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key. 
Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.


On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:

> Mike,
> 
> Please read *full post* before judge. In particular, "Hash-based
> distribution" section. You can find the same in HBaseWD small README file
> [1] (not sure if you read it at all before commenting on the lib). Round
> robin is mainly for explaining the concept/idea (though not only for that).
> 
> Thank you,
> Alex Baranau
> ------
> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
> Solr
> 
> [1] https://github.com/sematext/HBaseWD
> 
> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
> <mi...@hotmail.com>wrote:
> 
>> Quick answer...
>> 
>> Look at the salt.
>> Its just a number from a round robin counter.
>> There is no tie between the salt and row.
>> 
>> So when you want to fetch a single row, how do you do it?
>> ...
>> ;-)
>> 
>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>> wrote:
>> 
>>> Hello,
>>> 
>>> @Mike:
>>> 
>>> I'm the author of that post :).
>>> 
>>> Quick reply to your last comment:
>>> 
>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>> idea" in more specific way than "Fetching data takes more effort". Would
>> be
>>> helpful for anyone who is looking into using this approach.
>>> 
>>> 2) The approach described in the post also says you can prefix with the
>>> hash, you probably missed that.
>>> 
>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>> Please re-read the question: the intention is to distribute the load
>> while
>>> still being able to do "partial key scans". The blog post linked above
>>> explains one possible solution for that, while your answer doesn't.
>>> 
>>> @bigdata:
>>> 
>>> Basically when it comes to solving two issues: distributing writes and
>>> having ability to read data sequentially, you have to balance between
>> being
>>> good at both of them. Very good presentation by Lars:
>>> 
>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>> ,
>>> slide 22. You will see how this is correlated. In short:
>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>> writes, while compromises ability to do range scans efficiently
>>> * having very limited number of 'salt' prefixes still allows to do range
>>> scans (less efficiently than normal range scans, of course, but still
>> good
>>> enough in many cases) while providing worse distribution of writes
>>> 
>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>> could be derived from hashed values, etc.) you can balance between
>>> distributing writes efficiency and ability to run fast range scans.
>>> 
>>> Hope this helps
>>> 
>>> Alex Baranau
>>> ------
>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>> -
>>> Solr
>>> 
>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>> michael_segel@hotmail.com>wrote:
>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>> hope that the author of that blog take it down.
>>>> While it may solve an initial problem in terms of region hot spotting,
>> it
>>>> creates another problem when it comes to fetching data. Fetching data
>> takes
>>>> more effort.
>>>> 
>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>> random
>>>> key that is unique to the record.  Some would argue that using MD5 or
>> SHA-1
>>>> that mathematically you could have a collision, however you could then
>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>> things like take the hash and then truncate it to the first byte and
>> then
>>>> append the record key. This should give you enough randomness to avoid
>> hot
>>>> spotting after the initial region completion and you could pre-split out
>>>> any number of regions. (First byte 0-255 for values, so you can program
>> the
>>>> split...
>>>> 
>>>> 
>>>> Having said that... yes, you lose the ability to perform a sequential
>> scan
>>>> of the data.  At least to a point.  It depends on your schema.
>>>> 
>>>> Note that you need to think about how you are primarily going to access
>>>> the data.  You can then determine the best way to store the data to gain
>>>> the best performance. For some applications... the region hot spotting
>>>> isn't an important issue.
>>>> 
>>>> Note YMMV
>>>> 
>>>> HTH
>>>> 
>>>> -Mike
>>>> 
>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>> (heavy scan):
>>>>> * you can use composed keys with a field that can segregate data
>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>> * or use Salt with a limited number of values (example
>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>  so that a scan is a combination of 16 filters on on each salt values
>>>>>  you can base your code on HBaseWD by sematext
>>>>> 
>>>>> 
>>>> 
>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>    https://github.com/sematext/HBaseWD
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> 
>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>> 
>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>> balance the records stored in different parts. But If I want to search
>>>> some
>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>> not
>>>>>> use rowkey filter to scan a range of date value one time on the date
>> by
>>>>>> MD5. How to balance this issue?
>>>>>> Thanks.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Damien HARDY
>>>> 
>>>> 
>> 
>> 

Re: Is it necessary to set MD5 on rowkey?

[Alex Baranau <al...@gmail.com>]

> Plus, it's kind of a game or data puzzle -- how to
> use the data's nature to your advantage :)

Well said :), +1!

Re previous Qs about how/when salting with round-robin may differ from
taking first byte of a hash or similar ( and is more preferable to use):
0) you don't care about single gets (huge amount of cases) and one/more of
the following:
1) (very arguable) you want very-very even distribution
2) (very arguable) you don't want to spend time calculating hash from very
long keys
3) (might be the only "real" reason) you want more control to which buckets
(and hence Regions, RSs) you want to generate more write load in general or
at any particular point in time (see also [1] for one example when you may
wont that)

There may be more. That's from the top of my head.

To prevent/stop "holly war": yes, in majority of the cases you will use
hash-based solution. At least in the beginning and in simplest cases.

Alex Baranau
------
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr

[1] http://search-hadoop.com/m/TjkXd11qhLS

On Wed, Dec 19, 2012 at 6:04 PM, David Arthur <mu...@gmail.com> wrote:

> I wasn't really intending to describe a schema for a "webtable", but
> rather coming up with a contrived example of a compound key where you want
> to avoid hotspotting.
>
> The point, which has been reiterated a few times, is that there is not one
> solution for all row key requirements. Hashing/salting is just another tool
> in the tool belt.
>
>
>
> On 12/19/12 5:28 PM, Andrew Purtell wrote:
>
>> I generally agree. I built a webtable design once. We dropped the scheme
>> and reversed the domain to support "suffix glob" type queries over a group
>> of related hosts. There is then a natural hotspot at "com" but salting
>> would only have dispersed queries that should go to one row (or a group of
>> adjacent rows) over multiple regionservers, actually hurting query
>> efficiency. Instead we set the region split threshold low in the
>> beginning,
>> under the assumption that the resulting splits in the keyspace from the
>> initial stream of URLs would approximate the overall distribution, then
>> turned up the split threshold when entering production steady state.
>>
>>
>> On Wed, Dec 19, 2012 at 2:15 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>>
>>  On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <mu...@gmail.com> wrote:
>>>
>>>  Let's say you want to decompose a url into domain and path to include in
>>>> your row key.
>>>>
>>>> You could of course just use the url as the key, but you will see
>>>> hotspotting since most will start with "http".
>>>>
>>>
>>> Doesn't the original Bigtable paper [0] design around this problem by
>>> dropping the protocol and only storing the domain? *goes to check* Yes,
>>> it
>>> does.
>>>
>>> Personally, I've never encountered an HBase schema design problem where
>>> salting really nailed it. It's an okay place to start with initial
>>> designs,
>>> especially if you don't know your data well. I'm a big fan of using the
>>> natural variance in the data itself to solve this problem. OpenTSDB does
>>> this quite well, IMHO. Plus, it's kind of a game or data puzzle -- how to
>>> use the data's nature to your advantage :)
>>>
>>> Just my 2¢
>>> -n
>>>
>>> [0]:
>>>
>>> http://static.**googleusercontent.com/**external_content/untrusted_**
>>> dlcp/research.google.com/en/**us/archive/bigtable-osdi06.pdf<http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf>
>>>
>>>
>>
>>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

And there's the rub. 

Hashing is one thing. 
Salting is another. 

Hashing good. Salting bad. 
That simple. BTW, truncating the hash and appending the key falls in to hashing. 

This is probably a good definition of where the term salt comes from: "In cryptography, a salt consists of random bits, creating one of the inputs to a one-way function."
This is actually taken from Wikipedia. 

Again, using a salt not a good idea, very bad idea and shouldn't be recommended. 

HTH

-Mike

On Dec 19, 2012, at 5:04 PM, David Arthur <mu...@gmail.com> wrote:

> I wasn't really intending to describe a schema for a "webtable", but rather coming up with a contrived example of a compound key where you want to avoid hotspotting.
> 
> The point, which has been reiterated a few times, is that there is not one solution for all row key requirements. Hashing/salting is just another tool in the tool belt.
> 
> 
> On 12/19/12 5:28 PM, Andrew Purtell wrote:
>> I generally agree. I built a webtable design once. We dropped the scheme
>> and reversed the domain to support "suffix glob" type queries over a group
>> of related hosts. There is then a natural hotspot at "com" but salting
>> would only have dispersed queries that should go to one row (or a group of
>> adjacent rows) over multiple regionservers, actually hurting query
>> efficiency. Instead we set the region split threshold low in the beginning,
>> under the assumption that the resulting splits in the keyspace from the
>> initial stream of URLs would approximate the overall distribution, then
>> turned up the split threshold when entering production steady state.
>> 
>> 
>> On Wed, Dec 19, 2012 at 2:15 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>> 
>>> On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <mu...@gmail.com> wrote:
>>> 
>>>> Let's say you want to decompose a url into domain and path to include in
>>>> your row key.
>>>> 
>>>> You could of course just use the url as the key, but you will see
>>>> hotspotting since most will start with "http".
>>> 
>>> Doesn't the original Bigtable paper [0] design around this problem by
>>> dropping the protocol and only storing the domain? *goes to check* Yes, it
>>> does.
>>> 
>>> Personally, I've never encountered an HBase schema design problem where
>>> salting really nailed it. It's an okay place to start with initial designs,
>>> especially if you don't know your data well. I'm a big fan of using the
>>> natural variance in the data itself to solve this problem. OpenTSDB does
>>> this quite well, IMHO. Plus, it's kind of a game or data puzzle -- how to
>>> use the data's nature to your advantage :)
>>> 
>>> Just my 2¢
>>> -n
>>> 
>>> [0]:
>>> 
>>> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf
>>> 
>> 
>> 
> 
> 

Re: Is it necessary to set MD5 on rowkey?

[David Arthur <mu...@gmail.com>]

I wasn't really intending to describe a schema for a "webtable", but 
rather coming up with a contrived example of a compound key where you 
want to avoid hotspotting.

The point, which has been reiterated a few times, is that there is not 
one solution for all row key requirements. Hashing/salting is just 
another tool in the tool belt.


On 12/19/12 5:28 PM, Andrew Purtell wrote:
> I generally agree. I built a webtable design once. We dropped the scheme
> and reversed the domain to support "suffix glob" type queries over a group
> of related hosts. There is then a natural hotspot at "com" but salting
> would only have dispersed queries that should go to one row (or a group of
> adjacent rows) over multiple regionservers, actually hurting query
> efficiency. Instead we set the region split threshold low in the beginning,
> under the assumption that the resulting splits in the keyspace from the
> initial stream of URLs would approximate the overall distribution, then
> turned up the split threshold when entering production steady state.
>
>
> On Wed, Dec 19, 2012 at 2:15 PM, Nick Dimiduk <nd...@gmail.com> wrote:
>
>> On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <mu...@gmail.com> wrote:
>>
>>> Let's say you want to decompose a url into domain and path to include in
>>> your row key.
>>>
>>> You could of course just use the url as the key, but you will see
>>> hotspotting since most will start with "http".
>>
>> Doesn't the original Bigtable paper [0] design around this problem by
>> dropping the protocol and only storing the domain? *goes to check* Yes, it
>> does.
>>
>> Personally, I've never encountered an HBase schema design problem where
>> salting really nailed it. It's an okay place to start with initial designs,
>> especially if you don't know your data well. I'm a big fan of using the
>> natural variance in the data itself to solve this problem. OpenTSDB does
>> this quite well, IMHO. Plus, it's kind of a game or data puzzle -- how to
>> use the data's nature to your advantage :)
>>
>> Just my 2¢
>> -n
>>
>> [0]:
>>
>> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf
>>
>
>

Re: Is it necessary to set MD5 on rowkey?

[Andrew Purtell <ap...@apache.org>]

I generally agree. I built a webtable design once. We dropped the scheme
and reversed the domain to support "suffix glob" type queries over a group
of related hosts. There is then a natural hotspot at "com" but salting
would only have dispersed queries that should go to one row (or a group of
adjacent rows) over multiple regionservers, actually hurting query
efficiency. Instead we set the region split threshold low in the beginning,
under the assumption that the resulting splits in the keyspace from the
initial stream of URLs would approximate the overall distribution, then
turned up the split threshold when entering production steady state.


On Wed, Dec 19, 2012 at 2:15 PM, Nick Dimiduk <nd...@gmail.com> wrote:

> On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <mu...@gmail.com> wrote:
>
> > Let's say you want to decompose a url into domain and path to include in
> > your row key.
> >
> > You could of course just use the url as the key, but you will see
> > hotspotting since most will start with "http".
>
>
> Doesn't the original Bigtable paper [0] design around this problem by
> dropping the protocol and only storing the domain? *goes to check* Yes, it
> does.
>
> Personally, I've never encountered an HBase schema design problem where
> salting really nailed it. It's an okay place to start with initial designs,
> especially if you don't know your data well. I'm a big fan of using the
> natural variance in the data itself to solve this problem. OpenTSDB does
> this quite well, IMHO. Plus, it's kind of a game or data puzzle -- how to
> use the data's nature to your advantage :)
>
> Just my 2¢
> -n
>
> [0]:
>
> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Is it necessary to set MD5 on rowkey?

[Nick Dimiduk <nd...@gmail.com>]

On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <mu...@gmail.com> wrote:

> Let's say you want to decompose a url into domain and path to include in
> your row key.
>
> You could of course just use the url as the key, but you will see
> hotspotting since most will start with "http".


Doesn't the original Bigtable paper [0] design around this problem by
dropping the protocol and only storing the domain? *goes to check* Yes, it
does.

Personally, I've never encountered an HBase schema design problem where
salting really nailed it. It's an okay place to start with initial designs,
especially if you don't know your data well. I'm a big fan of using the
natural variance in the data itself to solve this problem. OpenTSDB does
this quite well, IMHO. Plus, it's kind of a game or data puzzle -- how to
use the data's nature to your advantage :)

Just my 2¢
-n

[0]:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/bigtable-osdi06.pdf

Re: Is it necessary to set MD5 on rowkey?

[Michel Segel <mi...@hotmail.com>]

This what wrote:
>> If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to
>> retrieve the row.
>> If you do something like a salt that uses only  a preset of N combinations,
>> you will have to do N get()s in order to fetch the row.
>> 

By definition the salt is a random number which is the first part of the one way crypt() function.
Using some modulo function is the second half of what I said. ;-)


Sent from a remote device. Please excuse any typos...

Mike Segel

On Dec 19, 2012, at 7:35 PM, Jean-Marc Spaggiari <je...@spaggiari.org> wrote:

> I have to disagree with the *FULL* *TABLE* *SCAN* in order to retrieve the row.
> 
> If I know that I have one byte salting between 1 and 10, I will have
> to do 10 gets to get the row. And they will most probably all be on
> different RS, so it will not be more than 1 get per server. This will
> take almost the same time as doing a simple get.
> 
> I understand your point that salting is inducting some bad things, but
> on the other side, it's easy and can still be usefull. Hash will allow
> you a direct access with one call, but you still need to calculate the
> hash. So what's faster? Calculate the hash and do one call to one
> server? Or go directly with one call to multiple servers? It all
> depend on the way you access your data.
> 
> Personnaly, I'm using hash almost everwhere, but I still understand
> that some people might be able to use salting for their specific
> purposes.
> 
> JM
> 
> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>> Ok,
>> 
>> Lets try this one more time...
>> 
>> If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to
>> retrieve the row.
>> If you do something like a salt that uses only  a preset of N combinations,
>> you will have to do N get()s in order to fetch the row.
>> 
>> This is bad. VERY BAD.
>> 
>> If you hash the row, you will get a consistent value each time you hash the
>> key.  If you use SHA-1, the odds of a collision are mathematically possible,
>> however highly improbable. So people have recommended that they append the
>> key to the hash to form the new key. Here, you might as well as truncate the
>> hash to just the most significant byte or two and the append the key. This
>> will give you enough of an even distribution that you can avoid hot
>> spotting.
> 

Re: Is it necessary to set MD5 on rowkey?

[Jean-Marc Spaggiari <je...@spaggiari.org>]

I have to disagree with the *FULL* *TABLE* *SCAN* in order to retrieve the row.

If I know that I have one byte salting between 1 and 10, I will have
to do 10 gets to get the row. And they will most probably all be on
different RS, so it will not be more than 1 get per server. This will
take almost the same time as doing a simple get.

I understand your point that salting is inducting some bad things, but
on the other side, it's easy and can still be usefull. Hash will allow
you a direct access with one call, but you still need to calculate the
hash. So what's faster? Calculate the hash and do one call to one
server? Or go directly with one call to multiple servers? It all
depend on the way you access your data.

Personnaly, I'm using hash almost everwhere, but I still understand
that some people might be able to use salting for their specific
purposes.

JM

2012/12/19, Michael Segel <mi...@hotmail.com>:
> Ok,
>
> Lets try this one more time...
>
> If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to
> retrieve the row.
> If you do something like a salt that uses only  a preset of N combinations,
> you will have to do N get()s in order to fetch the row.
>
> This is bad. VERY BAD.
>
> If you hash the row, you will get a consistent value each time you hash the
> key.  If you use SHA-1, the odds of a collision are mathematically possible,
> however highly improbable. So people have recommended that they append the
> key to the hash to form the new key. Here, you might as well as truncate the
> hash to just the most significant byte or two and the append the key. This
> will give you enough of an even distribution that you can avoid hot
> spotting.
>
> So if I use the hash, I can effectively still get the row of data back with
> a single get(). Otherwise its a full table scan.
>
> Do you see the difference?
>
>
> On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <je...@spaggiari.org>
> wrote:
>
>> Hi Mike,
>>
>> If in your business case, the only thing you need when you retreive
>> your data is to do full scan over MR jobs, then you can salt with
>> what-ever you want. Hash, random values, etc.
>>
>> If you know you have x regions, then you can simply do a round-robin
>> salting, or a random salting over those x regions.
>>
>> Then when you run your MR job, you discard the first bytes, and do
>> what you want with your data.
>>
>> So I also think that salting can still be usefull. All depend on what
>> you do with your data.
>>
>> Must my opinion.
>>
>> JM
>>
>> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>>> Ok...
>>>
>>> So you use a random byte or two at the front of the row.
>>> How do you then use get() to find the row?
>>> How do you do a partial scan()?
>>>
>>> Do you start to see the problem?
>>> The only way to get to the row is to do a full table scan. That kills
>>> HBase
>>> and you would be better off going with a partitioned Hive table.
>>>
>>> Using a hash of the key or a portion of the hash is not a salt.
>>> That's not what I have a problem with. Each time you want to fetch the
>>> key,
>>> you just hash it, truncate the hash and then prepend it to the key. You
>>> will
>>> then be able to use get().
>>>
>>> Using a salt would imply using some form of a modulo math to get a round
>>> robin prefix.  Or a random number generator.
>>>
>>> That's the issue.
>>>
>>> Does that make sense?
>>>
>>>
>>>
>>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>>>
>>>> Let's say you want to decompose a url into domain and path to include
>>>> in
>>>> your row key.
>>>>
>>>> You could of course just use the url as the key, but you will see
>>>> hotspotting since most will start with "http". To mitigate this, you
>>>> could
>>>> add a random byte or two at the beginning (random salt) to improve
>>>> distribution of keys, but you break single record Gets (and Scans
>>>> arguably). Another approach is to use a hash-based salt: hash the whole
>>>> key and use a few of those bytes as a salt. This fixes Gets but Scans
>>>> are
>>>> still not effective.
>>>>
>>>> One approach I've taken is to hash only a part of the key. Consider the
>>>> following key structure
>>>>
>>>> <2 bytes of hash(domain)><domain><path>
>>>>
>>>> With this you get 16 bits for a hash-based salt. The salt is
>>>> deterministic
>>>> so Gets work fine, and for a single domain the salt is the same so you
>>>> can
>>>> easily do Scans across a domain. If you had some further structure to
>>>> your
>>>> key that you wished to scan across, you could do something like:
>>>>
>>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>>>
>>>> It really boils down to identifying your access patterns and read/write
>>>> requirements and constructing a row key accordingly.
>>>>
>>>> HTH,
>>>> David
>>>>
>>>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>>>> Alex,
>>>>> And that's the point. Salt as you explain it conceptually implies that
>>>>> the number you are adding to the key to ensure a better distribution
>>>>> means that you will have inefficiencies in terms of scans and gets.
>>>>>
>>>>> Using a hash as either the full key, or taking the hash, truncating it
>>>>> and appending the key may screw up scans, but your get() is intact.
>>>>>
>>>>> There are other options like inverting the numeric key ...
>>>>>
>>>>> And of course doing nothing.
>>>>>
>>>>> Using a salt as part of the design pattern is bad.
>>>>>
>>>>> With respect to the OP, I was discussing the use of hash and some
>>>>> alternatives to how to implement the hash of a key.
>>>>> Again, doing nothing may also make sense too, if you understand the
>>>>> risks
>>>>> and you know how your data is going to be used.
>>>>>
>>>>>
>>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> Please read *full post* before judge. In particular, "Hash-based
>>>>>> distribution" section. You can find the same in HBaseWD small README
>>>>>> file
>>>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>>>> Round
>>>>>> robin is mainly for explaining the concept/idea (though not only for
>>>>>> that).
>>>>>>
>>>>>> Thank you,
>>>>>> Alex Baranau
>>>>>> ------
>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>> ElasticSearch
>>>>>> -
>>>>>> Solr
>>>>>>
>>>>>> [1] https://github.com/sematext/HBaseWD
>>>>>>
>>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>>>> <mi...@hotmail.com>wrote:
>>>>>>
>>>>>>> Quick answer...
>>>>>>>
>>>>>>> Look at the salt.
>>>>>>> Its just a number from a round robin counter.
>>>>>>> There is no tie between the salt and row.
>>>>>>>
>>>>>>> So when you want to fetch a single row, how do you do it?
>>>>>>> ...
>>>>>>> ;-)
>>>>>>>
>>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau
>>>>>>> <al...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> @Mike:
>>>>>>>>
>>>>>>>> I'm the author of that post :).
>>>>>>>>
>>>>>>>> Quick reply to your last comment:
>>>>>>>>
>>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very,
>>>>>>>> very
>>>>>>>> bad
>>>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>>>> Would
>>>>>>> be
>>>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>>>
>>>>>>>> 2) The approach described in the post also says you can prefix with
>>>>>>>> the
>>>>>>>> hash, you probably missed that.
>>>>>>>>
>>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>>>> guy.
>>>>>>>> Please re-read the question: the intention is to distribute the
>>>>>>>> load
>>>>>>> while
>>>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>>>> above
>>>>>>>> explains one possible solution for that, while your answer doesn't.
>>>>>>>>
>>>>>>>> @bigdata:
>>>>>>>>
>>>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>>>> and
>>>>>>>> having ability to read data sequentially, you have to balance
>>>>>>>> between
>>>>>>> being
>>>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>>>
>>>>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>>>> ,
>>>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>>>> distributing
>>>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>>>> range
>>>>>>>> scans (less efficiently than normal range scans, of course, but
>>>>>>>> still
>>>>>>> good
>>>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>>>
>>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>>>> (which
>>>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>>>>>
>>>>>>>> Hope this helps
>>>>>>>>
>>>>>>>> Alex Baranau
>>>>>>>> ------
>>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>>>> ElasticSearch
>>>>>>> -
>>>>>>>> Solr
>>>>>>>>
>>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>>>> michael_segel@hotmail.com>wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>>>> really
>>>>>>>>> hope that the author of that blog take it down.
>>>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>>>> spotting,
>>>>>>> it
>>>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>>>> data
>>>>>>> takes
>>>>>>>>> more effort.
>>>>>>>>>
>>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a
>>>>>>>>> more
>>>>>>> random
>>>>>>>>> key that is unique to the record.  Some would argue that using MD5
>>>>>>>>> or
>>>>>>> SHA-1
>>>>>>>>> that mathematically you could have a collision, however you could
>>>>>>>>> then
>>>>>>>>> append the key to the hash to guarantee uniqueness. You could also
>>>>>>>>> do
>>>>>>>>> things like take the hash and then truncate it to the first byte
>>>>>>>>> and
>>>>>>> then
>>>>>>>>> append the record key. This should give you enough randomness to
>>>>>>>>> avoid
>>>>>>> hot
>>>>>>>>> spotting after the initial region completion and you could
>>>>>>>>> pre-split
>>>>>>>>> out
>>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>>>> program
>>>>>>> the
>>>>>>>>> split...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>>>> sequential
>>>>>>> scan
>>>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>>>
>>>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>>>> access
>>>>>>>>> the data.  You can then determine the best way to store the data
>>>>>>>>> to
>>>>>>>>> gain
>>>>>>>>> the best performance. For some applications... the region hot
>>>>>>>>> spotting
>>>>>>>>> isn't an important issue.
>>>>>>>>>
>>>>>>>>> Note YMMV
>>>>>>>>>
>>>>>>>>> HTH
>>>>>>>>>
>>>>>>>>> -Mike
>>>>>>>>>
>>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>>>>> wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and
>>>>>>>>>> md5
>>>>>>>>>> (heavy scan):
>>>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
>>>>>>>>>> values
>>>>>>>>>> you can base your code on HBaseWD by sematext
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>>>    https://github.com/sematext/HBaseWD
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>>>
>>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good
>>>>>>>>>>> method
>>>>>>>>>>> to
>>>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>>>> search
>>>>>>>>> some
>>>>>>>>>>> sequential rowkey records, such as date as rowkey or partially.
>>>>>>>>>>> I
>>>>>>>>>>> can
>>>>>>>>> not
>>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>>>> date
>>>>>>> by
>>>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Damien HARDY
>>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Nick,

Yes there is an implied definition of  the term 'salting' which to those with a CS or Software Engineering background will take to heart.
However it goes beyond this definition. 

Per Lars and Alex, they are talking about bucketing the data.  Again this is not a good idea. 
As you point out even using a modulo function( eg  the % math symbol  45%10 = 5) you are still creating a certain nondeterministic value in the key. 

While this buckets the results in to 10 buckets, you no longer can do a single partial scan or a single get() to find that row. 

This is what is implied in 'salting' .

Now this is much different than taking the hash, truncating the hash and then appending the key. ( hash(key).toString.substring[1,2]+key) [Ok not code but you get the idea]
Using this, I can still use a single get() to fetch the row if I know the key.  Again, with Salting you can't do that.

What I find troublesome is that there are better design patterns which solve the same problem. 

HTH

-Mike

On Dec 20, 2012, at 12:15 PM, Nick Dimiduk <nd...@gmail.com> wrote:

> I think there's some hair-splitting going on here. The term "salting," by
> strict definition [0] from the cryptographic context, means the
> introduction of randomness to produce a one-way encoding of a value. The
> technique for rowkey design described here does not include the
> introduction of said randomness, nor is it a one-way operation. Instead, it
> divides the input more or less evenly across a fixed number of buckets.
> 
> If you've introduced one-way randomness, you have no way to reproduce the
> rowkey after it's been inserted. Thus, accessing a specific row would be
> O(n) where n is the number of rows in the table -- you'd have to scan the
> table looking for the desired row. Use of a bucketing technique, on the
> other hand, adds a small amount of computation to calculate the true
> rowkey, making access to a single row a O(1) + C vs the number of rows in
> the table.
> 
> -n
> 
> [0]: http://en.wikipedia.org/wiki/Salt_(cryptography)
> 
> On Thu, Dec 20, 2012 at 5:20 AM, Michael Segel <mi...@hotmail.com>wrote:
> 
>> Lars,
>> 
>> Ok... he's talking about buckets.
>> 
>> So when you have N buckets, what is the least number of get()s do you need
>> to fetch the single row?
>> (Hint: The answer is N)
>> 
>> How many scans? (N again)
>> 
>> Do you disagree?
>> 
>> 
>> On Dec 19, 2012, at 8:06 PM, lars hofhansl <lh...@yahoo.com> wrote:
>> 
>>> Mike, please think about what you write before you write it.
>>> You will most definitely not need a full table scan (much less a *FULL*
>> *TABLE* *SCAN* ;-) ).
>>> 
>>> Read Alex's blog post again, it's a good post (IMHO). He is talking
>> about buckets.
>>> 
>>> 
>>> -- Lars
>>> 
>>> 
>>> 
>>> ________________________________
>>> From: Michael Segel <mi...@hotmail.com>
>>> To: user@hbase.apache.org
>>> Sent: Wednesday, December 19, 2012 5:23 PM
>>> Subject: Re: Is it necessary to set MD5 on rowkey?
>>> 
>>> Ok,
>>> 
>>> Lets try this one more time...
>>> 
>>> If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to
>> retrieve the row.
>>> If you do something like a salt that uses only  a preset of N
>> combinations, you will have to do N get()s in order to fetch the row.
>>> 
>>> This is bad. VERY BAD.
>>> 
>>> If you hash the row, you will get a consistent value each time you hash
>> the key.  If you use SHA-1, the odds of a collision are mathematically
>> possible, however highly improbable. So people have recommended that they
>> append the key to the hash to form the new key. Here, you might as well as
>> truncate the hash to just the most significant byte or two and the append
>> the key. This will give you enough of an even distribution that you can
>> avoid hot spotting.
>>> 
>>> So if I use the hash, I can effectively still get the row of data back
>> with a single get(). Otherwise its a full table scan.
>>> 
>>> Do you see the difference?
>>> 
>>> 
>>> On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <
>> jean-marc@spaggiari.org> wrote:
>>> 
>>>> Hi Mike,
>>>> 
>>>> If in your business case, the only thing you need when you retreive
>>>> your data is to do full scan over MR jobs, then you can salt with
>>>> what-ever you want. Hash, random values, etc.
>>>> 
>>>> If you know you have x regions, then you can simply do a round-robin
>>>> salting, or a random salting over those x regions.
>>>> 
>>>> Then when you run your MR job, you discard the first bytes, and do
>>>> what you want with your data.
>>>> 
>>>> So I also think that salting can still be usefull. All depend on what
>>>> you do with your data.
>>>> 
>>>> Must my opinion.
>>>> 
>>>> JM
>>>> 
>>>> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>>>>> Ok...
>>>>> 
>>>>> So you use a random byte or two at the front of the row.
>>>>> How do you then use get() to find the row?
>>>>> How do you do a partial scan()?
>>>>> 
>>>>> Do you start to see the problem?
>>>>> The only way to get to the row is to do a full table scan. That kills
>> HBase
>>>>> and you would be better off going with a partitioned Hive table.
>>>>> 
>>>>> Using a hash of the key or a portion of the hash is not a salt.
>>>>> That's not what I have a problem with. Each time you want to fetch the
>> key,
>>>>> you just hash it, truncate the hash and then prepend it to the key.
>> You will
>>>>> then be able to use get().
>>>>> 
>>>>> Using a salt would imply using some form of a modulo math to get a
>> round
>>>>> robin prefix.  Or a random number generator.
>>>>> 
>>>>> That's the issue.
>>>>> 
>>>>> Does that make sense?
>>>>> 
>>>>> 
>>>>> 
>>>>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>>>>> 
>>>>>> Let's say you want to decompose a url into domain and path to include
>> in
>>>>>> your row key.
>>>>>> 
>>>>>> You could of course just use the url as the key, but you will see
>>>>>> hotspotting since most will start with "http". To mitigate this, you
>> could
>>>>>> add a random byte or two at the beginning (random salt) to improve
>>>>>> distribution of keys, but you break single record Gets (and Scans
>>>>>> arguably). Another approach is to use a hash-based salt: hash the
>> whole
>>>>>> key and use a few of those bytes as a salt. This fixes Gets but Scans
>> are
>>>>>> still not effective.
>>>>>> 
>>>>>> One approach I've taken is to hash only a part of the key. Consider
>> the
>>>>>> following key structure
>>>>>> 
>>>>>> <2 bytes of hash(domain)><domain><path>
>>>>>> 
>>>>>> With this you get 16 bits for a hash-based salt. The salt is
>> deterministic
>>>>>> so Gets work fine, and for a single domain the salt is the same so
>> you can
>>>>>> easily do Scans across a domain. If you had some further structure to
>> your
>>>>>> key that you wished to scan across, you could do something like:
>>>>>> 
>>>>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>>>>> 
>>>>>> It really boils down to identifying your access patterns and
>> read/write
>>>>>> requirements and constructing a row key accordingly.
>>>>>> 
>>>>>> HTH,
>>>>>> David
>>>>>> 
>>>>>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>>>>>> Alex,
>>>>>>> And that's the point. Salt as you explain it conceptually implies
>> that
>>>>>>> the number you are adding to the key to ensure a better distribution
>>>>>>> means that you will have inefficiencies in terms of scans and gets.
>>>>>>> 
>>>>>>> Using a hash as either the full key, or taking the hash, truncating
>> it
>>>>>>> and appending the key may screw up scans, but your get() is intact.
>>>>>>> 
>>>>>>> There are other options like inverting the numeric key ...
>>>>>>> 
>>>>>>> And of course doing nothing.
>>>>>>> 
>>>>>>> Using a salt as part of the design pattern is bad.
>>>>>>> 
>>>>>>> With respect to the OP, I was discussing the use of hash and some
>>>>>>> alternatives to how to implement the hash of a key.
>>>>>>> Again, doing nothing may also make sense too, if you understand the
>> risks
>>>>>>> and you know how your data is going to be used.
>>>>>>> 
>>>>>>> 
>>>>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <alex.baranov.v@gmail.com
>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Mike,
>>>>>>>> 
>>>>>>>> Please read *full post* before judge. In particular, "Hash-based
>>>>>>>> distribution" section. You can find the same in HBaseWD small README
>>>>>>>> file
>>>>>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>>>>>> Round
>>>>>>>> robin is mainly for explaining the concept/idea (though not only for
>>>>>>>> that).
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Alex Baranau
>>>>>>>> ------
>>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>> ElasticSearch
>>>>>>>> -
>>>>>>>> Solr
>>>>>>>> 
>>>>>>>> [1] https://github.com/sematext/HBaseWD
>>>>>>>> 
>>>>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>>>>>> <mi...@hotmail.com>wrote:
>>>>>>>> 
>>>>>>>>> Quick answer...
>>>>>>>>> 
>>>>>>>>> Look at the salt.
>>>>>>>>> Its just a number from a round robin counter.
>>>>>>>>> There is no tie between the salt and row.
>>>>>>>>> 
>>>>>>>>> So when you want to fetch a single row, how do you do it?
>>>>>>>>> ...
>>>>>>>>> ;-)
>>>>>>>>> 
>>>>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <
>> alex.baranov.v@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> @Mike:
>>>>>>>>>> 
>>>>>>>>>> I'm the author of that post :).
>>>>>>>>>> 
>>>>>>>>>> Quick reply to your last comment:
>>>>>>>>>> 
>>>>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very,
>> very
>>>>>>>>>> bad
>>>>>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>>>>>> Would
>>>>>>>>> be
>>>>>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>>>>> 
>>>>>>>>>> 2) The approach described in the post also says you can prefix
>> with
>>>>>>>>>> the
>>>>>>>>>> hash, you probably missed that.
>>>>>>>>>> 
>>>>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>>>>>> guy.
>>>>>>>>>> Please re-read the question: the intention is to distribute the
>> load
>>>>>>>>> while
>>>>>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>>>>>> above
>>>>>>>>>> explains one possible solution for that, while your answer
>> doesn't.
>>>>>>>>>> 
>>>>>>>>>> @bigdata:
>>>>>>>>>> 
>>>>>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>>>>>> and
>>>>>>>>>> having ability to read data sequentially, you have to balance
>> between
>>>>>>>>> being
>>>>>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>>>>> 
>>>>>>>>> 
>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>>>>>> ,
>>>>>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>>>>>> distributing
>>>>>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>>>>>> range
>>>>>>>>>> scans (less efficiently than normal range scans, of course, but
>> still
>>>>>>>>> good
>>>>>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>>>>> 
>>>>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>>>>>> (which
>>>>>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>>>>>> distributing writes efficiency and ability to run fast range
>> scans.
>>>>>>>>>> 
>>>>>>>>>> Hope this helps
>>>>>>>>>> 
>>>>>>>>>> Alex Baranau
>>>>>>>>>> ------
>>>>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>>>>>> ElasticSearch
>>>>>>>>> -
>>>>>>>>>> Solr
>>>>>>>>>> 
>>>>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>>>>>> michael_segel@hotmail.com>wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>>>>>> really
>>>>>>>>>>> hope that the author of that blog take it down.
>>>>>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>>>>>> spotting,
>>>>>>>>> it
>>>>>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>>>>>> data
>>>>>>>>> takes
>>>>>>>>>>> more effort.
>>>>>>>>>>> 
>>>>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a
>> more
>>>>>>>>> random
>>>>>>>>>>> key that is unique to the record.  Some would argue that using
>> MD5
>>>>>>>>>>> or
>>>>>>>>> SHA-1
>>>>>>>>>>> that mathematically you could have a collision, however you could
>>>>>>>>>>> then
>>>>>>>>>>> append the key to the hash to guarantee uniqueness. You could
>> also
>>>>>>>>>>> do
>>>>>>>>>>> things like take the hash and then truncate it to the first byte
>> and
>>>>>>>>> then
>>>>>>>>>>> append the record key. This should give you enough randomness to
>>>>>>>>>>> avoid
>>>>>>>>> hot
>>>>>>>>>>> spotting after the initial region completion and you could
>> pre-split
>>>>>>>>>>> out
>>>>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>>>>>> program
>>>>>>>>> the
>>>>>>>>>>> split...
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>>>>>> sequential
>>>>>>>>> scan
>>>>>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>>>>> 
>>>>>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>>>>>> access
>>>>>>>>>>> the data.  You can then determine the best way to store the data
>> to
>>>>>>>>>>> gain
>>>>>>>>>>> the best performance. For some applications... the region hot
>>>>>>>>>>> spotting
>>>>>>>>>>> isn't an important issue.
>>>>>>>>>>> 
>>>>>>>>>>> Note YMMV
>>>>>>>>>>> 
>>>>>>>>>>> HTH
>>>>>>>>>>> 
>>>>>>>>>>> -Mike
>>>>>>>>>>> 
>>>>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dhardy@viadeoteam.com
>>> 
>>>>>>>>> wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> 
>>>>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk)
>> and
>>>>>>>>>>>> md5
>>>>>>>>>>>> (heavy scan):
>>>>>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
>>>>>>>>>>>> values
>>>>>>>>>>>> you can base your code on HBaseWD by sematext
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>> 
>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>>>>>    https://github.com/sematext/HBaseWD
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>>>>> 
>>>>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good
>> method
>>>>>>>>>>>>> to
>>>>>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>>>>>> search
>>>>>>>>>>> some
>>>>>>>>>>>>> sequential rowkey records, such as date as rowkey or
>> partially. I
>>>>>>>>>>>>> can
>>>>>>>>>>> not
>>>>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>>>>>> date
>>>>>>>>> by
>>>>>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Damien HARDY
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>> 
>> 

Re: Is it necessary to set MD5 on rowkey?

[Nick Dimiduk <nd...@gmail.com>]

I think there's some hair-splitting going on here. The term "salting," by
strict definition [0] from the cryptographic context, means the
introduction of randomness to produce a one-way encoding of a value. The
technique for rowkey design described here does not include the
introduction of said randomness, nor is it a one-way operation. Instead, it
divides the input more or less evenly across a fixed number of buckets.

If you've introduced one-way randomness, you have no way to reproduce the
rowkey after it's been inserted. Thus, accessing a specific row would be
O(n) where n is the number of rows in the table -- you'd have to scan the
table looking for the desired row. Use of a bucketing technique, on the
other hand, adds a small amount of computation to calculate the true
rowkey, making access to a single row a O(1) + C vs the number of rows in
the table.

-n

[0]: http://en.wikipedia.org/wiki/Salt_(cryptography)

On Thu, Dec 20, 2012 at 5:20 AM, Michael Segel <mi...@hotmail.com>wrote:

> Lars,
>
> Ok... he's talking about buckets.
>
> So when you have N buckets, what is the least number of get()s do you need
> to fetch the single row?
> (Hint: The answer is N)
>
> How many scans? (N again)
>
> Do you disagree?
>
>
> On Dec 19, 2012, at 8:06 PM, lars hofhansl <lh...@yahoo.com> wrote:
>
> > Mike, please think about what you write before you write it.
> > You will most definitely not need a full table scan (much less a *FULL*
> *TABLE* *SCAN* ;-) ).
> >
> > Read Alex's blog post again, it's a good post (IMHO). He is talking
> about buckets.
> >
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> > From: Michael Segel <mi...@hotmail.com>
> > To: user@hbase.apache.org
> > Sent: Wednesday, December 19, 2012 5:23 PM
> > Subject: Re: Is it necessary to set MD5 on rowkey?
> >
> > Ok,
> >
> > Lets try this one more time...
> >
> > If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to
> retrieve the row.
> > If you do something like a salt that uses only  a preset of N
> combinations, you will have to do N get()s in order to fetch the row.
> >
> > This is bad. VERY BAD.
> >
> > If you hash the row, you will get a consistent value each time you hash
> the key.  If you use SHA-1, the odds of a collision are mathematically
> possible, however highly improbable. So people have recommended that they
> append the key to the hash to form the new key. Here, you might as well as
> truncate the hash to just the most significant byte or two and the append
> the key. This will give you enough of an even distribution that you can
> avoid hot spotting.
> >
> > So if I use the hash, I can effectively still get the row of data back
> with a single get(). Otherwise its a full table scan.
> >
> > Do you see the difference?
> >
> >
> > On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <
> jean-marc@spaggiari.org> wrote:
> >
> >> Hi Mike,
> >>
> >> If in your business case, the only thing you need when you retreive
> >> your data is to do full scan over MR jobs, then you can salt with
> >> what-ever you want. Hash, random values, etc.
> >>
> >> If you know you have x regions, then you can simply do a round-robin
> >> salting, or a random salting over those x regions.
> >>
> >> Then when you run your MR job, you discard the first bytes, and do
> >> what you want with your data.
> >>
> >> So I also think that salting can still be usefull. All depend on what
> >> you do with your data.
> >>
> >> Must my opinion.
> >>
> >> JM
> >>
> >> 2012/12/19, Michael Segel <mi...@hotmail.com>:
> >>> Ok...
> >>>
> >>> So you use a random byte or two at the front of the row.
> >>> How do you then use get() to find the row?
> >>> How do you do a partial scan()?
> >>>
> >>> Do you start to see the problem?
> >>> The only way to get to the row is to do a full table scan. That kills
> HBase
> >>> and you would be better off going with a partitioned Hive table.
> >>>
> >>> Using a hash of the key or a portion of the hash is not a salt.
> >>> That's not what I have a problem with. Each time you want to fetch the
> key,
> >>> you just hash it, truncate the hash and then prepend it to the key.
> You will
> >>> then be able to use get().
> >>>
> >>> Using a salt would imply using some form of a modulo math to get a
> round
> >>> robin prefix.  Or a random number generator.
> >>>
> >>> That's the issue.
> >>>
> >>> Does that make sense?
> >>>
> >>>
> >>>
> >>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
> >>>
> >>>> Let's say you want to decompose a url into domain and path to include
> in
> >>>> your row key.
> >>>>
> >>>> You could of course just use the url as the key, but you will see
> >>>> hotspotting since most will start with "http". To mitigate this, you
> could
> >>>> add a random byte or two at the beginning (random salt) to improve
> >>>> distribution of keys, but you break single record Gets (and Scans
> >>>> arguably). Another approach is to use a hash-based salt: hash the
> whole
> >>>> key and use a few of those bytes as a salt. This fixes Gets but Scans
> are
> >>>> still not effective.
> >>>>
> >>>> One approach I've taken is to hash only a part of the key. Consider
> the
> >>>> following key structure
> >>>>
> >>>> <2 bytes of hash(domain)><domain><path>
> >>>>
> >>>> With this you get 16 bits for a hash-based salt. The salt is
> deterministic
> >>>> so Gets work fine, and for a single domain the salt is the same so
> you can
> >>>> easily do Scans across a domain. If you had some further structure to
> your
> >>>> key that you wished to scan across, you could do something like:
> >>>>
> >>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
> >>>>
> >>>> It really boils down to identifying your access patterns and
> read/write
> >>>> requirements and constructing a row key accordingly.
> >>>>
> >>>> HTH,
> >>>> David
> >>>>
> >>>> On 12/18/12 6:29 PM, Michael Segel wrote:
> >>>>> Alex,
> >>>>> And that's the point. Salt as you explain it conceptually implies
> that
> >>>>> the number you are adding to the key to ensure a better distribution
> >>>>> means that you will have inefficiencies in terms of scans and gets.
> >>>>>
> >>>>> Using a hash as either the full key, or taking the hash, truncating
> it
> >>>>> and appending the key may screw up scans, but your get() is intact.
> >>>>>
> >>>>> There are other options like inverting the numeric key ...
> >>>>>
> >>>>> And of course doing nothing.
> >>>>>
> >>>>> Using a salt as part of the design pattern is bad.
> >>>>>
> >>>>> With respect to the OP, I was discussing the use of hash and some
> >>>>> alternatives to how to implement the hash of a key.
> >>>>> Again, doing nothing may also make sense too, if you understand the
> risks
> >>>>> and you know how your data is going to be used.
> >>>>>
> >>>>>
> >>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <alex.baranov.v@gmail.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>> Mike,
> >>>>>>
> >>>>>> Please read *full post* before judge. In particular, "Hash-based
> >>>>>> distribution" section. You can find the same in HBaseWD small README
> >>>>>> file
> >>>>>> [1] (not sure if you read it at all before commenting on the lib).
> >>>>>> Round
> >>>>>> robin is mainly for explaining the concept/idea (though not only for
> >>>>>> that).
> >>>>>>
> >>>>>> Thank you,
> >>>>>> Alex Baranau
> >>>>>> ------
> >>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
> ElasticSearch
> >>>>>> -
> >>>>>> Solr
> >>>>>>
> >>>>>> [1] https://github.com/sematext/HBaseWD
> >>>>>>
> >>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
> >>>>>> <mi...@hotmail.com>wrote:
> >>>>>>
> >>>>>>> Quick answer...
> >>>>>>>
> >>>>>>> Look at the salt.
> >>>>>>> Its just a number from a round robin counter.
> >>>>>>> There is no tie between the salt and row.
> >>>>>>>
> >>>>>>> So when you want to fetch a single row, how do you do it?
> >>>>>>> ...
> >>>>>>> ;-)
> >>>>>>>
> >>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <
> alex.baranov.v@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello,
> >>>>>>>>
> >>>>>>>> @Mike:
> >>>>>>>>
> >>>>>>>> I'm the author of that post :).
> >>>>>>>>
> >>>>>>>> Quick reply to your last comment:
> >>>>>>>>
> >>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very,
> very
> >>>>>>>> bad
> >>>>>>>> idea" in more specific way than "Fetching data takes more effort".
> >>>>>>>> Would
> >>>>>>> be
> >>>>>>>> helpful for anyone who is looking into using this approach.
> >>>>>>>>
> >>>>>>>> 2) The approach described in the post also says you can prefix
> with
> >>>>>>>> the
> >>>>>>>> hash, you probably missed that.
> >>>>>>>>
> >>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
> >>>>>>>> guy.
> >>>>>>>> Please re-read the question: the intention is to distribute the
> load
> >>>>>>> while
> >>>>>>>> still being able to do "partial key scans". The blog post linked
> >>>>>>>> above
> >>>>>>>> explains one possible solution for that, while your answer
> doesn't.
> >>>>>>>>
> >>>>>>>> @bigdata:
> >>>>>>>>
> >>>>>>>> Basically when it comes to solving two issues: distributing writes
> >>>>>>>> and
> >>>>>>>> having ability to read data sequentially, you have to balance
> between
> >>>>>>> being
> >>>>>>>> good at both of them. Very good presentation by Lars:
> >>>>>>>>
> >>>>>>>
> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
> >>>>>>> ,
> >>>>>>>> slide 22. You will see how this is correlated. In short:
> >>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
> >>>>>>>> distributing
> >>>>>>>> writes, while compromises ability to do range scans efficiently
> >>>>>>>> * having very limited number of 'salt' prefixes still allows to do
> >>>>>>>> range
> >>>>>>>> scans (less efficiently than normal range scans, of course, but
> still
> >>>>>>> good
> >>>>>>>> enough in many cases) while providing worse distribution of writes
> >>>>>>>>
> >>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
> >>>>>>>> (which
> >>>>>>>> could be derived from hashed values, etc.) you can balance between
> >>>>>>>> distributing writes efficiency and ability to run fast range
> scans.
> >>>>>>>>
> >>>>>>>> Hope this helps
> >>>>>>>>
> >>>>>>>> Alex Baranau
> >>>>>>>> ------
> >>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
> >>>>>>>> ElasticSearch
> >>>>>>> -
> >>>>>>>> Solr
> >>>>>>>>
> >>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
> >>>>>>> michael_segel@hotmail.com>wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
> >>>>>>>>> really
> >>>>>>>>> hope that the author of that blog take it down.
> >>>>>>>>> While it may solve an initial problem in terms of region hot
> >>>>>>>>> spotting,
> >>>>>>> it
> >>>>>>>>> creates another problem when it comes to fetching data. Fetching
> >>>>>>>>> data
> >>>>>>> takes
> >>>>>>>>> more effort.
> >>>>>>>>>
> >>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a
> more
> >>>>>>> random
> >>>>>>>>> key that is unique to the record.  Some would argue that using
> MD5
> >>>>>>>>> or
> >>>>>>> SHA-1
> >>>>>>>>> that mathematically you could have a collision, however you could
> >>>>>>>>> then
> >>>>>>>>> append the key to the hash to guarantee uniqueness. You could
> also
> >>>>>>>>> do
> >>>>>>>>> things like take the hash and then truncate it to the first byte
> and
> >>>>>>> then
> >>>>>>>>> append the record key. This should give you enough randomness to
> >>>>>>>>> avoid
> >>>>>>> hot
> >>>>>>>>> spotting after the initial region completion and you could
> pre-split
> >>>>>>>>> out
> >>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
> >>>>>>>>> program
> >>>>>>> the
> >>>>>>>>> split...
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Having said that... yes, you lose the ability to perform a
> >>>>>>>>> sequential
> >>>>>>> scan
> >>>>>>>>> of the data.  At least to a point.  It depends on your schema.
> >>>>>>>>>
> >>>>>>>>> Note that you need to think about how you are primarily going to
> >>>>>>>>> access
> >>>>>>>>> the data.  You can then determine the best way to store the data
> to
> >>>>>>>>> gain
> >>>>>>>>> the best performance. For some applications... the region hot
> >>>>>>>>> spotting
> >>>>>>>>> isn't an important issue.
> >>>>>>>>>
> >>>>>>>>> Note YMMV
> >>>>>>>>>
> >>>>>>>>> HTH
> >>>>>>>>>
> >>>>>>>>> -Mike
> >>>>>>>>>
> >>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dhardy@viadeoteam.com
> >
> >>>>>>> wrote:
> >>>>>>>>>> Hello,
> >>>>>>>>>>
> >>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk)
> and
> >>>>>>>>>> md5
> >>>>>>>>>> (heavy scan):
> >>>>>>>>>> * you can use composed keys with a field that can segregate data
> >>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
> >>>>>>>>>> * or use Salt with a limited number of values (example
> >>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
> >>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
> >>>>>>>>>> values
> >>>>>>>>>> you can base your code on HBaseWD by sematext
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> >>>>>>>>>>     https://github.com/sematext/HBaseWD
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
> >>>>>>>>>>
> >>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good
> method
> >>>>>>>>>>> to
> >>>>>>>>>>> balance the records stored in different parts. But If I want to
> >>>>>>>>>>> search
> >>>>>>>>> some
> >>>>>>>>>>> sequential rowkey records, such as date as rowkey or
> partially. I
> >>>>>>>>>>> can
> >>>>>>>>> not
> >>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
> >>>>>>>>>>> date
> >>>>>>> by
> >>>>>>>>>>> MD5. How to balance this issue?
> >>>>>>>>>>> Thanks.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Damien HARDY
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>>>
> >>>
> >>>
>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Lars,

Ok... he's talking about buckets.

So when you have N buckets, what is the least number of get()s do you need to fetch the single row? 
(Hint: The answer is N)

How many scans? (N again) 

Do you disagree? 


On Dec 19, 2012, at 8:06 PM, lars hofhansl <lh...@yahoo.com> wrote:

> Mike, please think about what you write before you write it.
> You will most definitely not need a full table scan (much less a *FULL* *TABLE* *SCAN* ;-) ).
> 
> Read Alex's blog post again, it's a good post (IMHO). He is talking about buckets.
> 
> 
> -- Lars
> 
> 
> 
> ________________________________
> From: Michael Segel <mi...@hotmail.com>
> To: user@hbase.apache.org 
> Sent: Wednesday, December 19, 2012 5:23 PM
> Subject: Re: Is it necessary to set MD5 on rowkey?
> 
> Ok, 
> 
> Lets try this one more time... 
> 
> If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to retrieve the row. 
> If you do something like a salt that uses only  a preset of N combinations, you will have to do N get()s in order to fetch the row. 
> 
> This is bad. VERY BAD.
> 
> If you hash the row, you will get a consistent value each time you hash the key.  If you use SHA-1, the odds of a collision are mathematically possible, however highly improbable. So people have recommended that they append the key to the hash to form the new key. Here, you might as well as truncate the hash to just the most significant byte or two and the append the key. This will give you enough of an even distribution that you can avoid hot spotting. 
> 
> So if I use the hash, I can effectively still get the row of data back with a single get(). Otherwise its a full table scan.
> 
> Do you see the difference? 
> 
> 
> On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <je...@spaggiari.org> wrote:
> 
>> Hi Mike,
>> 
>> If in your business case, the only thing you need when you retreive
>> your data is to do full scan over MR jobs, then you can salt with
>> what-ever you want. Hash, random values, etc.
>> 
>> If you know you have x regions, then you can simply do a round-robin
>> salting, or a random salting over those x regions.
>> 
>> Then when you run your MR job, you discard the first bytes, and do
>> what you want with your data.
>> 
>> So I also think that salting can still be usefull. All depend on what
>> you do with your data.
>> 
>> Must my opinion.
>> 
>> JM
>> 
>> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>>> Ok...
>>> 
>>> So you use a random byte or two at the front of the row.
>>> How do you then use get() to find the row?
>>> How do you do a partial scan()?
>>> 
>>> Do you start to see the problem?
>>> The only way to get to the row is to do a full table scan. That kills HBase
>>> and you would be better off going with a partitioned Hive table.
>>> 
>>> Using a hash of the key or a portion of the hash is not a salt.
>>> That's not what I have a problem with. Each time you want to fetch the key,
>>> you just hash it, truncate the hash and then prepend it to the key. You will
>>> then be able to use get().
>>> 
>>> Using a salt would imply using some form of a modulo math to get a round
>>> robin prefix.  Or a random number generator.
>>> 
>>> That's the issue.
>>> 
>>> Does that make sense?
>>> 
>>> 
>>> 
>>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>>> 
>>>> Let's say you want to decompose a url into domain and path to include in
>>>> your row key.
>>>> 
>>>> You could of course just use the url as the key, but you will see
>>>> hotspotting since most will start with "http". To mitigate this, you could
>>>> add a random byte or two at the beginning (random salt) to improve
>>>> distribution of keys, but you break single record Gets (and Scans
>>>> arguably). Another approach is to use a hash-based salt: hash the whole
>>>> key and use a few of those bytes as a salt. This fixes Gets but Scans are
>>>> still not effective.
>>>> 
>>>> One approach I've taken is to hash only a part of the key. Consider the
>>>> following key structure
>>>> 
>>>> <2 bytes of hash(domain)><domain><path>
>>>> 
>>>> With this you get 16 bits for a hash-based salt. The salt is deterministic
>>>> so Gets work fine, and for a single domain the salt is the same so you can
>>>> easily do Scans across a domain. If you had some further structure to your
>>>> key that you wished to scan across, you could do something like:
>>>> 
>>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>>> 
>>>> It really boils down to identifying your access patterns and read/write
>>>> requirements and constructing a row key accordingly.
>>>> 
>>>> HTH,
>>>> David
>>>> 
>>>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>>>> Alex,
>>>>> And that's the point. Salt as you explain it conceptually implies that
>>>>> the number you are adding to the key to ensure a better distribution
>>>>> means that you will have inefficiencies in terms of scans and gets.
>>>>> 
>>>>> Using a hash as either the full key, or taking the hash, truncating it
>>>>> and appending the key may screw up scans, but your get() is intact.
>>>>> 
>>>>> There are other options like inverting the numeric key ...
>>>>> 
>>>>> And of course doing nothing.
>>>>> 
>>>>> Using a salt as part of the design pattern is bad.
>>>>> 
>>>>> With respect to the OP, I was discussing the use of hash and some
>>>>> alternatives to how to implement the hash of a key.
>>>>> Again, doing nothing may also make sense too, if you understand the risks
>>>>> and you know how your data is going to be used.
>>>>> 
>>>>> 
>>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Mike,
>>>>>> 
>>>>>> Please read *full post* before judge. In particular, "Hash-based
>>>>>> distribution" section. You can find the same in HBaseWD small README
>>>>>> file
>>>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>>>> Round
>>>>>> robin is mainly for explaining the concept/idea (though not only for
>>>>>> that).
>>>>>> 
>>>>>> Thank you,
>>>>>> Alex Baranau
>>>>>> ------
>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>>>> -
>>>>>> Solr
>>>>>> 
>>>>>> [1] https://github.com/sematext/HBaseWD
>>>>>> 
>>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>>>> <mi...@hotmail.com>wrote:
>>>>>> 
>>>>>>> Quick answer...
>>>>>>> 
>>>>>>> Look at the salt.
>>>>>>> Its just a number from a round robin counter.
>>>>>>> There is no tie between the salt and row.
>>>>>>> 
>>>>>>> So when you want to fetch a single row, how do you do it?
>>>>>>> ...
>>>>>>> ;-)
>>>>>>> 
>>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> @Mike:
>>>>>>>> 
>>>>>>>> I'm the author of that post :).
>>>>>>>> 
>>>>>>>> Quick reply to your last comment:
>>>>>>>> 
>>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very
>>>>>>>> bad
>>>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>>>> Would
>>>>>>> be
>>>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>>> 
>>>>>>>> 2) The approach described in the post also says you can prefix with
>>>>>>>> the
>>>>>>>> hash, you probably missed that.
>>>>>>>> 
>>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>>>> guy.
>>>>>>>> Please re-read the question: the intention is to distribute the load
>>>>>>> while
>>>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>>>> above
>>>>>>>> explains one possible solution for that, while your answer doesn't.
>>>>>>>> 
>>>>>>>> @bigdata:
>>>>>>>> 
>>>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>>>> and
>>>>>>>> having ability to read data sequentially, you have to balance between
>>>>>>> being
>>>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>>> 
>>>>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>>>> ,
>>>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>>>> distributing
>>>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>>>> range
>>>>>>>> scans (less efficiently than normal range scans, of course, but still
>>>>>>> good
>>>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>>> 
>>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>>>> (which
>>>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>>>>> 
>>>>>>>> Hope this helps
>>>>>>>> 
>>>>>>>> Alex Baranau
>>>>>>>> ------
>>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>>>> ElasticSearch
>>>>>>> -
>>>>>>>> Solr
>>>>>>>> 
>>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>>>> michael_segel@hotmail.com>wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>>>> really
>>>>>>>>> hope that the author of that blog take it down.
>>>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>>>> spotting,
>>>>>>> it
>>>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>>>> data
>>>>>>> takes
>>>>>>>>> more effort.
>>>>>>>>> 
>>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>>>>> random
>>>>>>>>> key that is unique to the record.  Some would argue that using MD5
>>>>>>>>> or
>>>>>>> SHA-1
>>>>>>>>> that mathematically you could have a collision, however you could
>>>>>>>>> then
>>>>>>>>> append the key to the hash to guarantee uniqueness. You could also
>>>>>>>>> do
>>>>>>>>> things like take the hash and then truncate it to the first byte and
>>>>>>> then
>>>>>>>>> append the record key. This should give you enough randomness to
>>>>>>>>> avoid
>>>>>>> hot
>>>>>>>>> spotting after the initial region completion and you could pre-split
>>>>>>>>> out
>>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>>>> program
>>>>>>> the
>>>>>>>>> split...
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>>>> sequential
>>>>>>> scan
>>>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>>> 
>>>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>>>> access
>>>>>>>>> the data.  You can then determine the best way to store the data to
>>>>>>>>> gain
>>>>>>>>> the best performance. For some applications... the region hot
>>>>>>>>> spotting
>>>>>>>>> isn't an important issue.
>>>>>>>>> 
>>>>>>>>> Note YMMV
>>>>>>>>> 
>>>>>>>>> HTH
>>>>>>>>> 
>>>>>>>>> -Mike
>>>>>>>>> 
>>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>>>>> wrote:
>>>>>>>>>> Hello,
>>>>>>>>>> 
>>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and
>>>>>>>>>> md5
>>>>>>>>>> (heavy scan):
>>>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
>>>>>>>>>> values
>>>>>>>>>> you can base your code on HBaseWD by sematext
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>>>     https://github.com/sematext/HBaseWD
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>>> 
>>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method
>>>>>>>>>>> to
>>>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>>>> search
>>>>>>>>> some
>>>>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I
>>>>>>>>>>> can
>>>>>>>>> not
>>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>>>> date
>>>>>>> by
>>>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>>>> Thanks.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Damien HARDY
>>>>>>>>> 
>>>>>>> 
>>>> 
>>>> 
>>> 
>>> 

Re: Is it necessary to set MD5 on rowkey?

[lars hofhansl <lh...@yahoo.com>]

Mike, please think about what you write before you write it.
You will most definitely not need a full table scan (much less a *FULL* *TABLE* *SCAN* ;-) ).

Read Alex's blog post again, it's a good post (IMHO). He is talking about buckets.


-- Lars



________________________________
 From: Michael Segel <mi...@hotmail.com>
To: user@hbase.apache.org 
Sent: Wednesday, December 19, 2012 5:23 PM
Subject: Re: Is it necessary to set MD5 on rowkey?
 
Ok, 

Lets try this one more time... 

If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to retrieve the row. 
If you do something like a salt that uses only  a preset of N combinations, you will have to do N get()s in order to fetch the row. 

This is bad. VERY BAD.

If you hash the row, you will get a consistent value each time you hash the key.  If you use SHA-1, the odds of a collision are mathematically possible, however highly improbable. So people have recommended that they append the key to the hash to form the new key. Here, you might as well as truncate the hash to just the most significant byte or two and the append the key. This will give you enough of an even distribution that you can avoid hot spotting. 

So if I use the hash, I can effectively still get the row of data back with a single get(). Otherwise its a full table scan.

Do you see the difference? 


On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <je...@spaggiari.org> wrote:

> Hi Mike,
> 
> If in your business case, the only thing you need when you retreive
> your data is to do full scan over MR jobs, then you can salt with
> what-ever you want. Hash, random values, etc.
> 
> If you know you have x regions, then you can simply do a round-robin
> salting, or a random salting over those x regions.
> 
> Then when you run your MR job, you discard the first bytes, and do
> what you want with your data.
> 
> So I also think that salting can still be usefull. All depend on what
> you do with your data.
> 
> Must my opinion.
> 
> JM
> 
> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>> Ok...
>> 
>> So you use a random byte or two at the front of the row.
>> How do you then use get() to find the row?
>> How do you do a partial scan()?
>> 
>> Do you start to see the problem?
>> The only way to get to the row is to do a full table scan. That kills HBase
>> and you would be better off going with a partitioned Hive table.
>> 
>> Using a hash of the key or a portion of the hash is not a salt.
>> That's not what I have a problem with. Each time you want to fetch the key,
>> you just hash it, truncate the hash and then prepend it to the key. You will
>> then be able to use get().
>> 
>> Using a salt would imply using some form of a modulo math to get a round
>> robin prefix.  Or a random number generator.
>> 
>> That's the issue.
>> 
>> Does that make sense?
>> 
>> 
>> 
>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>> 
>>> Let's say you want to decompose a url into domain and path to include in
>>> your row key.
>>> 
>>> You could of course just use the url as the key, but you will see
>>> hotspotting since most will start with "http". To mitigate this, you could
>>> add a random byte or two at the beginning (random salt) to improve
>>> distribution of keys, but you break single record Gets (and Scans
>>> arguably). Another approach is to use a hash-based salt: hash the whole
>>> key and use a few of those bytes as a salt. This fixes Gets but Scans are
>>> still not effective.
>>> 
>>> One approach I've taken is to hash only a part of the key. Consider the
>>> following key structure
>>> 
>>> <2 bytes of hash(domain)><domain><path>
>>> 
>>> With this you get 16 bits for a hash-based salt. The salt is deterministic
>>> so Gets work fine, and for a single domain the salt is the same so you can
>>> easily do Scans across a domain. If you had some further structure to your
>>> key that you wished to scan across, you could do something like:
>>> 
>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>> 
>>> It really boils down to identifying your access patterns and read/write
>>> requirements and constructing a row key accordingly.
>>> 
>>> HTH,
>>> David
>>> 
>>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>>> Alex,
>>>> And that's the point. Salt as you explain it conceptually implies that
>>>> the number you are adding to the key to ensure a better distribution
>>>> means that you will have inefficiencies in terms of scans and gets.
>>>> 
>>>> Using a hash as either the full key, or taking the hash, truncating it
>>>> and appending the key may screw up scans, but your get() is intact.
>>>> 
>>>> There are other options like inverting the numeric key ...
>>>> 
>>>> And of course doing nothing.
>>>> 
>>>> Using a salt as part of the design pattern is bad.
>>>> 
>>>> With respect to the OP, I was discussing the use of hash and some
>>>> alternatives to how to implement the hash of a key.
>>>> Again, doing nothing may also make sense too, if you understand the risks
>>>> and you know how your data is going to be used.
>>>> 
>>>> 
>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Mike,
>>>>> 
>>>>> Please read *full post* before judge. In particular, "Hash-based
>>>>> distribution" section. You can find the same in HBaseWD small README
>>>>> file
>>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>>> Round
>>>>> robin is mainly for explaining the concept/idea (though not only for
>>>>> that).
>>>>> 
>>>>> Thank you,
>>>>> Alex Baranau
>>>>> ------
>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>>> -
>>>>> Solr
>>>>> 
>>>>> [1] https://github.com/sematext/HBaseWD
>>>>> 
>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>>> <mi...@hotmail.com>wrote:
>>>>> 
>>>>>> Quick answer...
>>>>>> 
>>>>>> Look at the salt.
>>>>>> Its just a number from a round robin counter.
>>>>>> There is no tie between the salt and row.
>>>>>> 
>>>>>> So when you want to fetch a single row, how do you do it?
>>>>>> ...
>>>>>> ;-)
>>>>>> 
>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> @Mike:
>>>>>>> 
>>>>>>> I'm the author of that post :).
>>>>>>> 
>>>>>>> Quick reply to your last comment:
>>>>>>> 
>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very
>>>>>>> bad
>>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>>> Would
>>>>>> be
>>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>> 
>>>>>>> 2) The approach described in the post also says you can prefix with
>>>>>>> the
>>>>>>> hash, you probably missed that.
>>>>>>> 
>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>>> guy.
>>>>>>> Please re-read the question: the intention is to distribute the load
>>>>>> while
>>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>>> above
>>>>>>> explains one possible solution for that, while your answer doesn't.
>>>>>>> 
>>>>>>> @bigdata:
>>>>>>> 
>>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>>> and
>>>>>>> having ability to read data sequentially, you have to balance between
>>>>>> being
>>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>> 
>>>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>>> ,
>>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>>> distributing
>>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>>> range
>>>>>>> scans (less efficiently than normal range scans, of course, but still
>>>>>> good
>>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>> 
>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>>> (which
>>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>>>> 
>>>>>>> Hope this helps
>>>>>>> 
>>>>>>> Alex Baranau
>>>>>>> ------
>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>>> ElasticSearch
>>>>>> -
>>>>>>> Solr
>>>>>>> 
>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>>> michael_segel@hotmail.com>wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>>> really
>>>>>>>> hope that the author of that blog take it down.
>>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>>> spotting,
>>>>>> it
>>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>>> data
>>>>>> takes
>>>>>>>> more effort.
>>>>>>>> 
>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>>>> random
>>>>>>>> key that is unique to the record.  Some would argue that using MD5
>>>>>>>> or
>>>>>> SHA-1
>>>>>>>> that mathematically you could have a collision, however you could
>>>>>>>> then
>>>>>>>> append the key to the hash to guarantee uniqueness. You could also
>>>>>>>> do
>>>>>>>> things like take the hash and then truncate it to the first byte and
>>>>>> then
>>>>>>>> append the record key. This should give you enough randomness to
>>>>>>>> avoid
>>>>>> hot
>>>>>>>> spotting after the initial region completion and you could pre-split
>>>>>>>> out
>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>>> program
>>>>>> the
>>>>>>>> split...
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>>> sequential
>>>>>> scan
>>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>> 
>>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>>> access
>>>>>>>> the data.  You can then determine the best way to store the data to
>>>>>>>> gain
>>>>>>>> the best performance. For some applications... the region hot
>>>>>>>> spotting
>>>>>>>> isn't an important issue.
>>>>>>>> 
>>>>>>>> Note YMMV
>>>>>>>> 
>>>>>>>> HTH
>>>>>>>> 
>>>>>>>> -Mike
>>>>>>>> 
>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and
>>>>>>>>> md5
>>>>>>>>> (heavy scan):
>>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
>>>>>>>>> values
>>>>>>>>> you can base your code on HBaseWD by sematext
>>>>>>>>> 
>>>>>>>>> 
>>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>>    https://github.com/sematext/HBaseWD
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>> 
>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method
>>>>>>>>>> to
>>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>>> search
>>>>>>>> some
>>>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I
>>>>>>>>>> can
>>>>>>>> not
>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>>> date
>>>>>> by
>>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>>> Thanks.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Damien HARDY
>>>>>>>> 
>>>>>> 
>>> 
>>> 
>> 
>> 
> 

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Ok, 

Lets try this one more time... 

If you salt, you will have to do a *FULL* *TABLE* *SCAN* in order to retrieve the row. 
If you do something like a salt that uses only  a preset of N combinations, you will have to do N get()s in order to fetch the row. 

This is bad. VERY BAD.

If you hash the row, you will get a consistent value each time you hash the key.  If you use SHA-1, the odds of a collision are mathematically possible, however highly improbable. So people have recommended that they append the key to the hash to form the new key. Here, you might as well as truncate the hash to just the most significant byte or two and the append the key. This will give you enough of an even distribution that you can avoid hot spotting. 

So if I use the hash, I can effectively still get the row of data back with a single get(). Otherwise its a full table scan.

Do you see the difference? 


On Dec 19, 2012, at 7:11 PM, Jean-Marc Spaggiari <je...@spaggiari.org> wrote:

> Hi Mike,
> 
> If in your business case, the only thing you need when you retreive
> your data is to do full scan over MR jobs, then you can salt with
> what-ever you want. Hash, random values, etc.
> 
> If you know you have x regions, then you can simply do a round-robin
> salting, or a random salting over those x regions.
> 
> Then when you run your MR job, you discard the first bytes, and do
> what you want with your data.
> 
> So I also think that salting can still be usefull. All depend on what
> you do with your data.
> 
> Must my opinion.
> 
> JM
> 
> 2012/12/19, Michael Segel <mi...@hotmail.com>:
>> Ok...
>> 
>> So you use a random byte or two at the front of the row.
>> How do you then use get() to find the row?
>> How do you do a partial scan()?
>> 
>> Do you start to see the problem?
>> The only way to get to the row is to do a full table scan. That kills HBase
>> and you would be better off going with a partitioned Hive table.
>> 
>> Using a hash of the key or a portion of the hash is not a salt.
>> That's not what I have a problem with. Each time you want to fetch the key,
>> you just hash it, truncate the hash and then prepend it to the key. You will
>> then be able to use get().
>> 
>> Using a salt would imply using some form of a modulo math to get a round
>> robin prefix.  Or a random number generator.
>> 
>> That's the issue.
>> 
>> Does that make sense?
>> 
>> 
>> 
>> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>> 
>>> Let's say you want to decompose a url into domain and path to include in
>>> your row key.
>>> 
>>> You could of course just use the url as the key, but you will see
>>> hotspotting since most will start with "http". To mitigate this, you could
>>> add a random byte or two at the beginning (random salt) to improve
>>> distribution of keys, but you break single record Gets (and Scans
>>> arguably). Another approach is to use a hash-based salt: hash the whole
>>> key and use a few of those bytes as a salt. This fixes Gets but Scans are
>>> still not effective.
>>> 
>>> One approach I've taken is to hash only a part of the key. Consider the
>>> following key structure
>>> 
>>> <2 bytes of hash(domain)><domain><path>
>>> 
>>> With this you get 16 bits for a hash-based salt. The salt is deterministic
>>> so Gets work fine, and for a single domain the salt is the same so you can
>>> easily do Scans across a domain. If you had some further structure to your
>>> key that you wished to scan across, you could do something like:
>>> 
>>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>> 
>>> It really boils down to identifying your access patterns and read/write
>>> requirements and constructing a row key accordingly.
>>> 
>>> HTH,
>>> David
>>> 
>>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>>> Alex,
>>>> And that's the point. Salt as you explain it conceptually implies that
>>>> the number you are adding to the key to ensure a better distribution
>>>> means that you will have inefficiencies in terms of scans and gets.
>>>> 
>>>> Using a hash as either the full key, or taking the hash, truncating it
>>>> and appending the key may screw up scans, but your get() is intact.
>>>> 
>>>> There are other options like inverting the numeric key ...
>>>> 
>>>> And of course doing nothing.
>>>> 
>>>> Using a salt as part of the design pattern is bad.
>>>> 
>>>> With respect to the OP, I was discussing the use of hash and some
>>>> alternatives to how to implement the hash of a key.
>>>> Again, doing nothing may also make sense too, if you understand the risks
>>>> and you know how your data is going to be used.
>>>> 
>>>> 
>>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Mike,
>>>>> 
>>>>> Please read *full post* before judge. In particular, "Hash-based
>>>>> distribution" section. You can find the same in HBaseWD small README
>>>>> file
>>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>>> Round
>>>>> robin is mainly for explaining the concept/idea (though not only for
>>>>> that).
>>>>> 
>>>>> Thank you,
>>>>> Alex Baranau
>>>>> ------
>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>>> -
>>>>> Solr
>>>>> 
>>>>> [1] https://github.com/sematext/HBaseWD
>>>>> 
>>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>>> <mi...@hotmail.com>wrote:
>>>>> 
>>>>>> Quick answer...
>>>>>> 
>>>>>> Look at the salt.
>>>>>> Its just a number from a round robin counter.
>>>>>> There is no tie between the salt and row.
>>>>>> 
>>>>>> So when you want to fetch a single row, how do you do it?
>>>>>> ...
>>>>>> ;-)
>>>>>> 
>>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> @Mike:
>>>>>>> 
>>>>>>> I'm the author of that post :).
>>>>>>> 
>>>>>>> Quick reply to your last comment:
>>>>>>> 
>>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very
>>>>>>> bad
>>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>>> Would
>>>>>> be
>>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>> 
>>>>>>> 2) The approach described in the post also says you can prefix with
>>>>>>> the
>>>>>>> hash, you probably missed that.
>>>>>>> 
>>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>>> guy.
>>>>>>> Please re-read the question: the intention is to distribute the load
>>>>>> while
>>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>>> above
>>>>>>> explains one possible solution for that, while your answer doesn't.
>>>>>>> 
>>>>>>> @bigdata:
>>>>>>> 
>>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>>> and
>>>>>>> having ability to read data sequentially, you have to balance between
>>>>>> being
>>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>> 
>>>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>>> ,
>>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>>> distributing
>>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>>> range
>>>>>>> scans (less efficiently than normal range scans, of course, but still
>>>>>> good
>>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>> 
>>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>>> (which
>>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>>>> 
>>>>>>> Hope this helps
>>>>>>> 
>>>>>>> Alex Baranau
>>>>>>> ------
>>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>>> ElasticSearch
>>>>>> -
>>>>>>> Solr
>>>>>>> 
>>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>>> michael_segel@hotmail.com>wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>>> really
>>>>>>>> hope that the author of that blog take it down.
>>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>>> spotting,
>>>>>> it
>>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>>> data
>>>>>> takes
>>>>>>>> more effort.
>>>>>>>> 
>>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>>>> random
>>>>>>>> key that is unique to the record.  Some would argue that using MD5
>>>>>>>> or
>>>>>> SHA-1
>>>>>>>> that mathematically you could have a collision, however you could
>>>>>>>> then
>>>>>>>> append the key to the hash to guarantee uniqueness. You could also
>>>>>>>> do
>>>>>>>> things like take the hash and then truncate it to the first byte and
>>>>>> then
>>>>>>>> append the record key. This should give you enough randomness to
>>>>>>>> avoid
>>>>>> hot
>>>>>>>> spotting after the initial region completion and you could pre-split
>>>>>>>> out
>>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>>> program
>>>>>> the
>>>>>>>> split...
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>>> sequential
>>>>>> scan
>>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>> 
>>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>>> access
>>>>>>>> the data.  You can then determine the best way to store the data to
>>>>>>>> gain
>>>>>>>> the best performance. For some applications... the region hot
>>>>>>>> spotting
>>>>>>>> isn't an important issue.
>>>>>>>> 
>>>>>>>> Note YMMV
>>>>>>>> 
>>>>>>>> HTH
>>>>>>>> 
>>>>>>>> -Mike
>>>>>>>> 
>>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and
>>>>>>>>> md5
>>>>>>>>> (heavy scan):
>>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>> so that a scan is a combination of 16 filters on on each salt
>>>>>>>>> values
>>>>>>>>> you can base your code on HBaseWD by sematext
>>>>>>>>> 
>>>>>>>>> 
>>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>>    https://github.com/sematext/HBaseWD
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>> 
>>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method
>>>>>>>>>> to
>>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>>> search
>>>>>>>> some
>>>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I
>>>>>>>>>> can
>>>>>>>> not
>>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>>> date
>>>>>> by
>>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>>> Thanks.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Damien HARDY
>>>>>>>> 
>>>>>> 
>>> 
>>> 
>> 
>> 
> 

Re: Is it necessary to set MD5 on rowkey?

[Jean-Marc Spaggiari <je...@spaggiari.org>]

Hi Mike,

If in your business case, the only thing you need when you retreive
your data is to do full scan over MR jobs, then you can salt with
what-ever you want. Hash, random values, etc.

If you know you have x regions, then you can simply do a round-robin
salting, or a random salting over those x regions.

Then when you run your MR job, you discard the first bytes, and do
what you want with your data.

So I also think that salting can still be usefull. All depend on what
you do with your data.

Must my opinion.

JM

2012/12/19, Michael Segel <mi...@hotmail.com>:
> Ok...
>
> So you use a random byte or two at the front of the row.
> How do you then use get() to find the row?
> How do you do a partial scan()?
>
> Do you start to see the problem?
> The only way to get to the row is to do a full table scan. That kills HBase
> and you would be better off going with a partitioned Hive table.
>
> Using a hash of the key or a portion of the hash is not a salt.
> That's not what I have a problem with. Each time you want to fetch the key,
> you just hash it, truncate the hash and then prepend it to the key. You will
> then be able to use get().
>
> Using a salt would imply using some form of a modulo math to get a round
> robin prefix.  Or a random number generator.
>
> That's the issue.
>
> Does that make sense?
>
>
>
> On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:
>
>> Let's say you want to decompose a url into domain and path to include in
>> your row key.
>>
>> You could of course just use the url as the key, but you will see
>> hotspotting since most will start with "http". To mitigate this, you could
>> add a random byte or two at the beginning (random salt) to improve
>> distribution of keys, but you break single record Gets (and Scans
>> arguably). Another approach is to use a hash-based salt: hash the whole
>> key and use a few of those bytes as a salt. This fixes Gets but Scans are
>> still not effective.
>>
>> One approach I've taken is to hash only a part of the key. Consider the
>> following key structure
>>
>> <2 bytes of hash(domain)><domain><path>
>>
>> With this you get 16 bits for a hash-based salt. The salt is deterministic
>> so Gets work fine, and for a single domain the salt is the same so you can
>> easily do Scans across a domain. If you had some further structure to your
>> key that you wished to scan across, you could do something like:
>>
>> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
>>
>> It really boils down to identifying your access patterns and read/write
>> requirements and constructing a row key accordingly.
>>
>> HTH,
>> David
>>
>> On 12/18/12 6:29 PM, Michael Segel wrote:
>>> Alex,
>>> And that's the point. Salt as you explain it conceptually implies that
>>> the number you are adding to the key to ensure a better distribution
>>> means that you will have inefficiencies in terms of scans and gets.
>>>
>>> Using a hash as either the full key, or taking the hash, truncating it
>>> and appending the key may screw up scans, but your get() is intact.
>>>
>>> There are other options like inverting the numeric key ...
>>>
>>> And of course doing nothing.
>>>
>>> Using a salt as part of the design pattern is bad.
>>>
>>> With respect to the OP, I was discussing the use of hash and some
>>> alternatives to how to implement the hash of a key.
>>> Again, doing nothing may also make sense too, if you understand the risks
>>> and you know how your data is going to be used.
>>>
>>>
>>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com>
>>> wrote:
>>>
>>>> Mike,
>>>>
>>>> Please read *full post* before judge. In particular, "Hash-based
>>>> distribution" section. You can find the same in HBaseWD small README
>>>> file
>>>> [1] (not sure if you read it at all before commenting on the lib).
>>>> Round
>>>> robin is mainly for explaining the concept/idea (though not only for
>>>> that).
>>>>
>>>> Thank you,
>>>> Alex Baranau
>>>> ------
>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>> -
>>>> Solr
>>>>
>>>> [1] https://github.com/sematext/HBaseWD
>>>>
>>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>>> <mi...@hotmail.com>wrote:
>>>>
>>>>> Quick answer...
>>>>>
>>>>> Look at the salt.
>>>>> Its just a number from a round robin counter.
>>>>> There is no tie between the salt and row.
>>>>>
>>>>> So when you want to fetch a single row, how do you do it?
>>>>> ...
>>>>> ;-)
>>>>>
>>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> @Mike:
>>>>>>
>>>>>> I'm the author of that post :).
>>>>>>
>>>>>> Quick reply to your last comment:
>>>>>>
>>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very
>>>>>> bad
>>>>>> idea" in more specific way than "Fetching data takes more effort".
>>>>>> Would
>>>>> be
>>>>>> helpful for anyone who is looking into using this approach.
>>>>>>
>>>>>> 2) The approach described in the post also says you can prefix with
>>>>>> the
>>>>>> hash, you probably missed that.
>>>>>>
>>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata
>>>>>> guy.
>>>>>> Please re-read the question: the intention is to distribute the load
>>>>> while
>>>>>> still being able to do "partial key scans". The blog post linked
>>>>>> above
>>>>>> explains one possible solution for that, while your answer doesn't.
>>>>>>
>>>>>> @bigdata:
>>>>>>
>>>>>> Basically when it comes to solving two issues: distributing writes
>>>>>> and
>>>>>> having ability to read data sequentially, you have to balance between
>>>>> being
>>>>>> good at both of them. Very good presentation by Lars:
>>>>>>
>>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>>> ,
>>>>>> slide 22. You will see how this is correlated. In short:
>>>>>> * having md5/other hash prefix of the key does better w.r.t.
>>>>>> distributing
>>>>>> writes, while compromises ability to do range scans efficiently
>>>>>> * having very limited number of 'salt' prefixes still allows to do
>>>>>> range
>>>>>> scans (less efficiently than normal range scans, of course, but still
>>>>> good
>>>>>> enough in many cases) while providing worse distribution of writes
>>>>>>
>>>>>> In the latter case by choosing number of possible 'salt' prefixes
>>>>>> (which
>>>>>> could be derived from hashed values, etc.) you can balance between
>>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>>>
>>>>>> Hope this helps
>>>>>>
>>>>>> Alex Baranau
>>>>>> ------
>>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase -
>>>>>> ElasticSearch
>>>>> -
>>>>>> Solr
>>>>>>
>>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>>> michael_segel@hotmail.com>wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would
>>>>>>> really
>>>>>>> hope that the author of that blog take it down.
>>>>>>> While it may solve an initial problem in terms of region hot
>>>>>>> spotting,
>>>>> it
>>>>>>> creates another problem when it comes to fetching data. Fetching
>>>>>>> data
>>>>> takes
>>>>>>> more effort.
>>>>>>>
>>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>>> random
>>>>>>> key that is unique to the record.  Some would argue that using MD5
>>>>>>> or
>>>>> SHA-1
>>>>>>> that mathematically you could have a collision, however you could
>>>>>>> then
>>>>>>> append the key to the hash to guarantee uniqueness. You could also
>>>>>>> do
>>>>>>> things like take the hash and then truncate it to the first byte and
>>>>> then
>>>>>>> append the record key. This should give you enough randomness to
>>>>>>> avoid
>>>>> hot
>>>>>>> spotting after the initial region completion and you could pre-split
>>>>>>> out
>>>>>>> any number of regions. (First byte 0-255 for values, so you can
>>>>>>> program
>>>>> the
>>>>>>> split...
>>>>>>>
>>>>>>>
>>>>>>> Having said that... yes, you lose the ability to perform a
>>>>>>> sequential
>>>>> scan
>>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>>>
>>>>>>> Note that you need to think about how you are primarily going to
>>>>>>> access
>>>>>>> the data.  You can then determine the best way to store the data to
>>>>>>> gain
>>>>>>> the best performance. For some applications... the region hot
>>>>>>> spotting
>>>>>>> isn't an important issue.
>>>>>>>
>>>>>>> Note YMMV
>>>>>>>
>>>>>>> HTH
>>>>>>>
>>>>>>> -Mike
>>>>>>>
>>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and
>>>>>>>> md5
>>>>>>>> (heavy scan):
>>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>>> * or use Salt with a limited number of values (example
>>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>>  so that a scan is a combination of 16 filters on on each salt
>>>>>>>> values
>>>>>>>>  you can base your code on HBaseWD by sematext
>>>>>>>>
>>>>>>>>
>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>>     https://github.com/sematext/HBaseWD
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>>>
>>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method
>>>>>>>>> to
>>>>>>>>> balance the records stored in different parts. But If I want to
>>>>>>>>> search
>>>>>>> some
>>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I
>>>>>>>>> can
>>>>>>> not
>>>>>>>>> use rowkey filter to scan a range of date value one time on the
>>>>>>>>> date
>>>>> by
>>>>>>>>> MD5. How to balance this issue?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Damien HARDY
>>>>>>>
>>>>>
>>
>>
>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Ok...

So you use a random byte or two at the front of the row.
How do you then use get() to find the row? 
How do you do a partial scan()? 

Do you start to see the problem? 
The only way to get to the row is to do a full table scan. That kills HBase and you would be better off going with a partitioned Hive table. 

Using a hash of the key or a portion of the hash is not a salt.
That's not what I have a problem with. Each time you want to fetch the key, you just hash it, truncate the hash and then prepend it to the key. You will then be able to use get().

Using a salt would imply using some form of a modulo math to get a round robin prefix.  Or a random number generator.

That's the issue. 

Does that make sense? 



On Dec 19, 2012, at 3:26 PM, David Arthur <mu...@gmail.com> wrote:

> Let's say you want to decompose a url into domain and path to include in your row key.
> 
> You could of course just use the url as the key, but you will see hotspotting since most will start with "http". To mitigate this, you could add a random byte or two at the beginning (random salt) to improve distribution of keys, but you break single record Gets (and Scans arguably). Another approach is to use a hash-based salt: hash the whole key and use a few of those bytes as a salt. This fixes Gets but Scans are still not effective.
> 
> One approach I've taken is to hash only a part of the key. Consider the following key structure
> 
> <2 bytes of hash(domain)><domain><path>
> 
> With this you get 16 bits for a hash-based salt. The salt is deterministic so Gets work fine, and for a single domain the salt is the same so you can easily do Scans across a domain. If you had some further structure to your key that you wished to scan across, you could do something like:
> 
> <2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>
> 
> It really boils down to identifying your access patterns and read/write requirements and constructing a row key accordingly.
> 
> HTH,
> David
> 
> On 12/18/12 6:29 PM, Michael Segel wrote:
>> Alex,
>> And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets.
>> 
>> Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact.
>> 
>> There are other options like inverting the numeric key ...
>> 
>> And of course doing nothing.
>> 
>> Using a salt as part of the design pattern is bad.
>> 
>> With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key.
>> Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.
>> 
>> 
>> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:
>> 
>>> Mike,
>>> 
>>> Please read *full post* before judge. In particular, "Hash-based
>>> distribution" section. You can find the same in HBaseWD small README file
>>> [1] (not sure if you read it at all before commenting on the lib). Round
>>> robin is mainly for explaining the concept/idea (though not only for that).
>>> 
>>> Thank you,
>>> Alex Baranau
>>> ------
>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>>> Solr
>>> 
>>> [1] https://github.com/sematext/HBaseWD
>>> 
>>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>>> <mi...@hotmail.com>wrote:
>>> 
>>>> Quick answer...
>>>> 
>>>> Look at the salt.
>>>> Its just a number from a round robin counter.
>>>> There is no tie between the salt and row.
>>>> 
>>>> So when you want to fetch a single row, how do you do it?
>>>> ...
>>>> ;-)
>>>> 
>>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> @Mike:
>>>>> 
>>>>> I'm the author of that post :).
>>>>> 
>>>>> Quick reply to your last comment:
>>>>> 
>>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>>> idea" in more specific way than "Fetching data takes more effort". Would
>>>> be
>>>>> helpful for anyone who is looking into using this approach.
>>>>> 
>>>>> 2) The approach described in the post also says you can prefix with the
>>>>> hash, you probably missed that.
>>>>> 
>>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>>> Please re-read the question: the intention is to distribute the load
>>>> while
>>>>> still being able to do "partial key scans". The blog post linked above
>>>>> explains one possible solution for that, while your answer doesn't.
>>>>> 
>>>>> @bigdata:
>>>>> 
>>>>> Basically when it comes to solving two issues: distributing writes and
>>>>> having ability to read data sequentially, you have to balance between
>>>> being
>>>>> good at both of them. Very good presentation by Lars:
>>>>> 
>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>>> ,
>>>>> slide 22. You will see how this is correlated. In short:
>>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>>> writes, while compromises ability to do range scans efficiently
>>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>>> scans (less efficiently than normal range scans, of course, but still
>>>> good
>>>>> enough in many cases) while providing worse distribution of writes
>>>>> 
>>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>>> could be derived from hashed values, etc.) you can balance between
>>>>> distributing writes efficiency and ability to run fast range scans.
>>>>> 
>>>>> Hope this helps
>>>>> 
>>>>> Alex Baranau
>>>>> ------
>>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>>> -
>>>>> Solr
>>>>> 
>>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>>> michael_segel@hotmail.com>wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>>> hope that the author of that blog take it down.
>>>>>> While it may solve an initial problem in terms of region hot spotting,
>>>> it
>>>>>> creates another problem when it comes to fetching data. Fetching data
>>>> takes
>>>>>> more effort.
>>>>>> 
>>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>>> random
>>>>>> key that is unique to the record.  Some would argue that using MD5 or
>>>> SHA-1
>>>>>> that mathematically you could have a collision, however you could then
>>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>>> things like take the hash and then truncate it to the first byte and
>>>> then
>>>>>> append the record key. This should give you enough randomness to avoid
>>>> hot
>>>>>> spotting after the initial region completion and you could pre-split out
>>>>>> any number of regions. (First byte 0-255 for values, so you can program
>>>> the
>>>>>> split...
>>>>>> 
>>>>>> 
>>>>>> Having said that... yes, you lose the ability to perform a sequential
>>>> scan
>>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>> 
>>>>>> Note that you need to think about how you are primarily going to access
>>>>>> the data.  You can then determine the best way to store the data to gain
>>>>>> the best performance. For some applications... the region hot spotting
>>>>>> isn't an important issue.
>>>>>> 
>>>>>> Note YMMV
>>>>>> 
>>>>>> HTH
>>>>>> 
>>>>>> -Mike
>>>>>> 
>>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>>> wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>>> (heavy scan):
>>>>>>> * you can use composed keys with a field that can segregate data
>>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>> * or use Salt with a limited number of values (example
>>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>>  so that a scan is a combination of 16 filters on on each salt values
>>>>>>>  you can base your code on HBaseWD by sematext
>>>>>>> 
>>>>>>> 
>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>>     https://github.com/sematext/HBaseWD
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> 
>>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>> 
>>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>>> balance the records stored in different parts. But If I want to search
>>>>>> some
>>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>>> not
>>>>>>>> use rowkey filter to scan a range of date value one time on the date
>>>> by
>>>>>>>> MD5. How to balance this issue?
>>>>>>>> Thanks.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Damien HARDY
>>>>>> 
>>>> 
> 
> 

Re: Is it necessary to set MD5 on rowkey?

[David Arthur <mu...@gmail.com>]

Let's say you want to decompose a url into domain and path to include in 
your row key.

You could of course just use the url as the key, but you will see 
hotspotting since most will start with "http". To mitigate this, you 
could add a random byte or two at the beginning (random salt) to improve 
distribution of keys, but you break single record Gets (and Scans 
arguably). Another approach is to use a hash-based salt: hash the whole 
key and use a few of those bytes as a salt. This fixes Gets but Scans 
are still not effective.

One approach I've taken is to hash only a part of the key. Consider the 
following key structure

<2 bytes of hash(domain)><domain><path>

With this you get 16 bits for a hash-based salt. The salt is 
deterministic so Gets work fine, and for a single domain the salt is the 
same so you can easily do Scans across a domain. If you had some further 
structure to your key that you wished to scan across, you could do 
something like:

<2 bytes of hash(domain)><domain><2 bytes of hash(path)><path>

It really boils down to identifying your access patterns and read/write 
requirements and constructing a row key accordingly.

HTH,
David

On 12/18/12 6:29 PM, Michael Segel wrote:
> Alex,
> And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets.
>
> Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact.
>
> There are other options like inverting the numeric key ...
>
> And of course doing nothing.
>
> Using a salt as part of the design pattern is bad.
>
> With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key.
> Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.
>
>
> On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:
>
>> Mike,
>>
>> Please read *full post* before judge. In particular, "Hash-based
>> distribution" section. You can find the same in HBaseWD small README file
>> [1] (not sure if you read it at all before commenting on the lib). Round
>> robin is mainly for explaining the concept/idea (though not only for that).
>>
>> Thank you,
>> Alex Baranau
>> ------
>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>> Solr
>>
>> [1] https://github.com/sematext/HBaseWD
>>
>> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
>> <mi...@hotmail.com>wrote:
>>
>>> Quick answer...
>>>
>>> Look at the salt.
>>> Its just a number from a round robin counter.
>>> There is no tie between the salt and row.
>>>
>>> So when you want to fetch a single row, how do you do it?
>>> ...
>>> ;-)
>>>
>>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> @Mike:
>>>>
>>>> I'm the author of that post :).
>>>>
>>>> Quick reply to your last comment:
>>>>
>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>> idea" in more specific way than "Fetching data takes more effort". Would
>>> be
>>>> helpful for anyone who is looking into using this approach.
>>>>
>>>> 2) The approach described in the post also says you can prefix with the
>>>> hash, you probably missed that.
>>>>
>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>> Please re-read the question: the intention is to distribute the load
>>> while
>>>> still being able to do "partial key scans". The blog post linked above
>>>> explains one possible solution for that, while your answer doesn't.
>>>>
>>>> @bigdata:
>>>>
>>>> Basically when it comes to solving two issues: distributing writes and
>>>> having ability to read data sequentially, you have to balance between
>>> being
>>>> good at both of them. Very good presentation by Lars:
>>>>
>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>>> ,
>>>> slide 22. You will see how this is correlated. In short:
>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>> writes, while compromises ability to do range scans efficiently
>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>> scans (less efficiently than normal range scans, of course, but still
>>> good
>>>> enough in many cases) while providing worse distribution of writes
>>>>
>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>> could be derived from hashed values, etc.) you can balance between
>>>> distributing writes efficiency and ability to run fast range scans.
>>>>
>>>> Hope this helps
>>>>
>>>> Alex Baranau
>>>> ------
>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>>> -
>>>> Solr
>>>>
>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>>> michael_segel@hotmail.com>wrote:
>>>>> Hi,
>>>>>
>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>> hope that the author of that blog take it down.
>>>>> While it may solve an initial problem in terms of region hot spotting,
>>> it
>>>>> creates another problem when it comes to fetching data. Fetching data
>>> takes
>>>>> more effort.
>>>>>
>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>>> random
>>>>> key that is unique to the record.  Some would argue that using MD5 or
>>> SHA-1
>>>>> that mathematically you could have a collision, however you could then
>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>> things like take the hash and then truncate it to the first byte and
>>> then
>>>>> append the record key. This should give you enough randomness to avoid
>>> hot
>>>>> spotting after the initial region completion and you could pre-split out
>>>>> any number of regions. (First byte 0-255 for values, so you can program
>>> the
>>>>> split...
>>>>>
>>>>>
>>>>> Having said that... yes, you lose the ability to perform a sequential
>>> scan
>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>
>>>>> Note that you need to think about how you are primarily going to access
>>>>> the data.  You can then determine the best way to store the data to gain
>>>>> the best performance. For some applications... the region hot spotting
>>>>> isn't an important issue.
>>>>>
>>>>> Note YMMV
>>>>>
>>>>> HTH
>>>>>
>>>>> -Mike
>>>>>
>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>>> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>> (heavy scan):
>>>>>> * you can use composed keys with a field that can segregate data
>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>> * or use Salt with a limited number of values (example
>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>   so that a scan is a combination of 16 filters on on each salt values
>>>>>>   you can base your code on HBaseWD by sematext
>>>>>>
>>>>>>
>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>      https://github.com/sematext/HBaseWD
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>
>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>> balance the records stored in different parts. But If I want to search
>>>>> some
>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>> not
>>>>>>> use rowkey filter to scan a range of date value one time on the date
>>> by
>>>>>>> MD5. How to balance this issue?
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Damien HARDY
>>>>>
>>>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Alex, 
And that's the point. Salt as you explain it conceptually implies that the number you are adding to the key to ensure a better distribution means that you will have inefficiencies in terms of scans and gets. 

Using a hash as either the full key, or taking the hash, truncating it and appending the key may screw up scans, but your get() is intact. 

There are other options like inverting the numeric key ... 

And of course doing nothing. 

Using a salt as part of the design pattern is bad. 

With respect to the OP, I was discussing the use of hash and some alternatives to how to implement the hash of a key. 
Again, doing nothing may also make sense too, if you understand the risks and you know how your data is going to be used.


On Dec 18, 2012, at 11:36 AM, Alex Baranau <al...@gmail.com> wrote:

> Mike,
> 
> Please read *full post* before judge. In particular, "Hash-based
> distribution" section. You can find the same in HBaseWD small README file
> [1] (not sure if you read it at all before commenting on the lib). Round
> robin is mainly for explaining the concept/idea (though not only for that).
> 
> Thank you,
> Alex Baranau
> ------
> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
> Solr
> 
> [1] https://github.com/sematext/HBaseWD
> 
> On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
> <mi...@hotmail.com>wrote:
> 
>> Quick answer...
>> 
>> Look at the salt.
>> Its just a number from a round robin counter.
>> There is no tie between the salt and row.
>> 
>> So when you want to fetch a single row, how do you do it?
>> ...
>> ;-)
>> 
>> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
>> wrote:
>> 
>>> Hello,
>>> 
>>> @Mike:
>>> 
>>> I'm the author of that post :).
>>> 
>>> Quick reply to your last comment:
>>> 
>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>> idea" in more specific way than "Fetching data takes more effort". Would
>> be
>>> helpful for anyone who is looking into using this approach.
>>> 
>>> 2) The approach described in the post also says you can prefix with the
>>> hash, you probably missed that.
>>> 
>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>> Please re-read the question: the intention is to distribute the load
>> while
>>> still being able to do "partial key scans". The blog post linked above
>>> explains one possible solution for that, while your answer doesn't.
>>> 
>>> @bigdata:
>>> 
>>> Basically when it comes to solving two issues: distributing writes and
>>> having ability to read data sequentially, you have to balance between
>> being
>>> good at both of them. Very good presentation by Lars:
>>> 
>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
>> ,
>>> slide 22. You will see how this is correlated. In short:
>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>> writes, while compromises ability to do range scans efficiently
>>> * having very limited number of 'salt' prefixes still allows to do range
>>> scans (less efficiently than normal range scans, of course, but still
>> good
>>> enough in many cases) while providing worse distribution of writes
>>> 
>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>> could be derived from hashed values, etc.) you can balance between
>>> distributing writes efficiency and ability to run fast range scans.
>>> 
>>> Hope this helps
>>> 
>>> Alex Baranau
>>> ------
>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
>> -
>>> Solr
>>> 
>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
>> michael_segel@hotmail.com>wrote:
>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>> hope that the author of that blog take it down.
>>>> While it may solve an initial problem in terms of region hot spotting,
>> it
>>>> creates another problem when it comes to fetching data. Fetching data
>> takes
>>>> more effort.
>>>> 
>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more
>> random
>>>> key that is unique to the record.  Some would argue that using MD5 or
>> SHA-1
>>>> that mathematically you could have a collision, however you could then
>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>> things like take the hash and then truncate it to the first byte and
>> then
>>>> append the record key. This should give you enough randomness to avoid
>> hot
>>>> spotting after the initial region completion and you could pre-split out
>>>> any number of regions. (First byte 0-255 for values, so you can program
>> the
>>>> split...
>>>> 
>>>> 
>>>> Having said that... yes, you lose the ability to perform a sequential
>> scan
>>>> of the data.  At least to a point.  It depends on your schema.
>>>> 
>>>> Note that you need to think about how you are primarily going to access
>>>> the data.  You can then determine the best way to store the data to gain
>>>> the best performance. For some applications... the region hot spotting
>>>> isn't an important issue.
>>>> 
>>>> Note YMMV
>>>> 
>>>> HTH
>>>> 
>>>> -Mike
>>>> 
>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>> (heavy scan):
>>>>> * you can use composed keys with a field that can segregate data
>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>> * or use Salt with a limited number of values (example
>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>  so that a scan is a combination of 16 filters on on each salt values
>>>>>  you can base your code on HBaseWD by sematext
>>>>> 
>>>>> 
>>>> 
>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>     https://github.com/sematext/HBaseWD
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> 
>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>> 
>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>> balance the records stored in different parts. But If I want to search
>>>> some
>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>> not
>>>>>> use rowkey filter to scan a range of date value one time on the date
>> by
>>>>>> MD5. How to balance this issue?
>>>>>> Thanks.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Damien HARDY
>>>> 
>>>> 
>> 
>> 

Re: Is it necessary to set MD5 on rowkey?

[Alex Baranau <al...@gmail.com>]

Mike,

Please read *full post* before judge. In particular, "Hash-based
distribution" section. You can find the same in HBaseWD small README file
[1] (not sure if you read it at all before commenting on the lib). Round
robin is mainly for explaining the concept/idea (though not only for that).

Thank you,
Alex Baranau
------
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr

[1] https://github.com/sematext/HBaseWD

On Tue, Dec 18, 2012 at 12:24 PM, Michael Segel
<mi...@hotmail.com>wrote:

> Quick answer...
>
> Look at the salt.
> Its just a number from a round robin counter.
> There is no tie between the salt and row.
>
> So when you want to fetch a single row, how do you do it?
> ...
> ;-)
>
> On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com>
> wrote:
>
> > Hello,
> >
> > @Mike:
> >
> > I'm the author of that post :).
> >
> > Quick reply to your last comment:
> >
> > 1) Could you please describe why "the use of a 'Salt' is a very, very bad
> > idea" in more specific way than "Fetching data takes more effort". Would
> be
> > helpful for anyone who is looking into using this approach.
> >
> > 2) The approach described in the post also says you can prefix with the
> > hash, you probably missed that.
> >
> > 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
> > Please re-read the question: the intention is to distribute the load
> while
> > still being able to do "partial key scans". The blog post linked above
> > explains one possible solution for that, while your answer doesn't.
> >
> > @bigdata:
> >
> > Basically when it comes to solving two issues: distributing writes and
> > having ability to read data sequentially, you have to balance between
> being
> > good at both of them. Very good presentation by Lars:
> >
> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012
> ,
> > slide 22. You will see how this is correlated. In short:
> > * having md5/other hash prefix of the key does better w.r.t. distributing
> > writes, while compromises ability to do range scans efficiently
> > * having very limited number of 'salt' prefixes still allows to do range
> > scans (less efficiently than normal range scans, of course, but still
> good
> > enough in many cases) while providing worse distribution of writes
> >
> > In the latter case by choosing number of possible 'salt' prefixes (which
> > could be derived from hashed values, etc.) you can balance between
> > distributing writes efficiency and ability to run fast range scans.
> >
> > Hope this helps
> >
> > Alex Baranau
> > ------
> > Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch
> -
> > Solr
> >
> > On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <
> michael_segel@hotmail.com>wrote:
> >
> >>
> >> Hi,
> >>
> >> First, the use of a 'Salt' is a very, very bad idea and I would really
> >> hope that the author of that blog take it down.
> >> While it may solve an initial problem in terms of region hot spotting,
> it
> >> creates another problem when it comes to fetching data. Fetching data
> takes
> >> more effort.
> >>
> >> With respect to using a hash (MD5 or SHA-1) you are creating a more
> random
> >> key that is unique to the record.  Some would argue that using MD5 or
> SHA-1
> >> that mathematically you could have a collision, however you could then
> >> append the key to the hash to guarantee uniqueness. You could also do
> >> things like take the hash and then truncate it to the first byte and
> then
> >> append the record key. This should give you enough randomness to avoid
> hot
> >> spotting after the initial region completion and you could pre-split out
> >> any number of regions. (First byte 0-255 for values, so you can program
> the
> >> split...
> >>
> >>
> >> Having said that... yes, you lose the ability to perform a sequential
> scan
> >> of the data.  At least to a point.  It depends on your schema.
> >>
> >> Note that you need to think about how you are primarily going to access
> >> the data.  You can then determine the best way to store the data to gain
> >> the best performance. For some applications... the region hot spotting
> >> isn't an important issue.
> >>
> >> Note YMMV
> >>
> >> HTH
> >>
> >> -Mike
> >>
> >> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com>
> wrote:
> >>
> >>> Hello,
> >>>
> >>> There is middle term betwen sequecial keys (hot spoting risk) and md5
> >>> (heavy scan):
> >>> * you can use composed keys with a field that can segregate data
> >>> (hostname, productname, metric name) like OpenTSDB
> >>> * or use Salt with a limited number of values (example
> >>> substr(md5(rowid),0,1) = 16 values)
> >>>   so that a scan is a combination of 16 filters on on each salt values
> >>>   you can base your code on HBaseWD by sematext
> >>>
> >>>
> >>
> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> >>>      https://github.com/sematext/HBaseWD
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> 2012/12/18 bigdata <bi...@outlook.com>
> >>>
> >>>> Many articles tell me that MD5 rowkey or part of it is good method to
> >>>> balance the records stored in different parts. But If I want to search
> >> some
> >>>> sequential rowkey records, such as date as rowkey or partially. I can
> >> not
> >>>> use rowkey filter to scan a range of date value one time on the date
> by
> >>>> MD5. How to balance this issue?
> >>>> Thanks.
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Damien HARDY
> >>
> >>
>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Quick answer... 

Look at the salt. 
Its just a number from a round robin counter. 
There is no tie between the salt and row.

So when you want to fetch a single row, how do you do it? 
...
;-) 

On Dec 18, 2012, at 11:12 AM, Alex Baranau <al...@gmail.com> wrote:

> Hello,
> 
> @Mike:
> 
> I'm the author of that post :).
> 
> Quick reply to your last comment:
> 
> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
> idea" in more specific way than "Fetching data takes more effort". Would be
> helpful for anyone who is looking into using this approach.
> 
> 2) The approach described in the post also says you can prefix with the
> hash, you probably missed that.
> 
> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
> Please re-read the question: the intention is to distribute the load while
> still being able to do "partial key scans". The blog post linked above
> explains one possible solution for that, while your answer doesn't.
> 
> @bigdata:
> 
> Basically when it comes to solving two issues: distributing writes and
> having ability to read data sequentially, you have to balance between being
> good at both of them. Very good presentation by Lars:
> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
> slide 22. You will see how this is correlated. In short:
> * having md5/other hash prefix of the key does better w.r.t. distributing
> writes, while compromises ability to do range scans efficiently
> * having very limited number of 'salt' prefixes still allows to do range
> scans (less efficiently than normal range scans, of course, but still good
> enough in many cases) while providing worse distribution of writes
> 
> In the latter case by choosing number of possible 'salt' prefixes (which
> could be derived from hashed values, etc.) you can balance between
> distributing writes efficiency and ability to run fast range scans.
> 
> Hope this helps
> 
> Alex Baranau
> ------
> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
> Solr
> 
> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:
> 
>> 
>> Hi,
>> 
>> First, the use of a 'Salt' is a very, very bad idea and I would really
>> hope that the author of that blog take it down.
>> While it may solve an initial problem in terms of region hot spotting, it
>> creates another problem when it comes to fetching data. Fetching data takes
>> more effort.
>> 
>> With respect to using a hash (MD5 or SHA-1) you are creating a more random
>> key that is unique to the record.  Some would argue that using MD5 or SHA-1
>> that mathematically you could have a collision, however you could then
>> append the key to the hash to guarantee uniqueness. You could also do
>> things like take the hash and then truncate it to the first byte and then
>> append the record key. This should give you enough randomness to avoid hot
>> spotting after the initial region completion and you could pre-split out
>> any number of regions. (First byte 0-255 for values, so you can program the
>> split...
>> 
>> 
>> Having said that... yes, you lose the ability to perform a sequential scan
>> of the data.  At least to a point.  It depends on your schema.
>> 
>> Note that you need to think about how you are primarily going to access
>> the data.  You can then determine the best way to store the data to gain
>> the best performance. For some applications... the region hot spotting
>> isn't an important issue.
>> 
>> Note YMMV
>> 
>> HTH
>> 
>> -Mike
>> 
>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
>> 
>>> Hello,
>>> 
>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>> (heavy scan):
>>> * you can use composed keys with a field that can segregate data
>>> (hostname, productname, metric name) like OpenTSDB
>>> * or use Salt with a limited number of values (example
>>> substr(md5(rowid),0,1) = 16 values)
>>>   so that a scan is a combination of 16 filters on on each salt values
>>>   you can base your code on HBaseWD by sematext
>>> 
>>> 
>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>      https://github.com/sematext/HBaseWD
>>> 
>>> Cheers,
>>> 
>>> 
>>> 2012/12/18 bigdata <bi...@outlook.com>
>>> 
>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>> balance the records stored in different parts. But If I want to search
>> some
>>>> sequential rowkey records, such as date as rowkey or partially. I can
>> not
>>>> use rowkey filter to scan a range of date value one time on the date by
>>>> MD5. How to balance this issue?
>>>> Thanks.
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Damien HARDY
>> 
>> 

Re: Is it necessary to set MD5 on rowkey?

[Damien Hardy <dh...@viadeoteam.com>]

Using a custom InputFormat with dedicated getsplit() allow you to use a
single scan object when initiating job. It is cloned later by each
mapper setting startrow and stoprow according the list returned by
getsplit().

Getsplit would return a list of couple (startrow, stoprow) calculated
based on regions and slat. Actually in HBaseW it runs the getsplit from
TabelInputFormat for each salt value.

The size of the list returned by getsplit() determine the number of mappers.

Best regards,

-- 
Damien

Le 17/12/2013 10:57, bigdata a écrit :
> Thanks for your reply, Damien.
> So this solution still use one scan object, and sent it to initTableMapperJob?
> Does modified getsplit() function set the salt Bucket number to the number of mapper?If I set 256 salt buckets, and the mapper number will be 256, right?
> 
> Another question is can this bucket number be changed? Like 16 at first, when data became large, I expand it to 32, or 64? 
> Thanks.
> 
>> Date: Tue, 17 Dec 2013 10:21:13 +0100
>> From: dhardy@viadeoteam.com
>> To: user@hbase.apache.org
>> Subject: Re: Is it necessary to set MD5 on rowkey?
>>
>> Hello,
>>
>> yes you need 256 scans range or a full (almost) scan with combination of
>> filters for each 256 ranges
>> (https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/FilterList.Operator.html#MUST_PASS_ONE)
>>
>> For mapreduce, the getsplit() method should be modified from
>> TableInputFormatBase to handle salt values.
>> This is what is done in
>> https://github.com/sematext/HBaseWD/blob/master/src/main/java/com/sematext/hbase/wd/WdTableInputFormat.java
>> (to return on HBaseWD example)
>>
>> So a mapper (several if a salt value cover many regions) is dedicated
>> for each salt value like simple TableInoutFormart would do without salt.
>>
>> Best regards.
>>
>> -- 
>> Damien
>>
>>
>> Le 17/12/2013 09:36, bigdata a écrit :
>>> Hello,
>>> @Alex Baranau
>>> Thanks for your salt solution. In my understanding, the salt solution is divide the data into several partial(if 2 letters,00~FF, then 255 parts will be devided). My question is when I want to scan data, do I need scan 256 times for the following situation:rowkey:  salt prefix (00~FF) + date + xxx
>>> And If I want do mapreduce on this table, if the initTableMapperJob(List<Scan>,...) is OK?
>>> If example of scan the salted table is appreciated!
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Date: Tue, 18 Dec 2012 12:12:37 -0500
>>>> Subject: Re: Is it necessary to set MD5 on rowkey?
>>>> From: alex.baranov.v@gmail.com
>>>> To: user@hbase.apache.org
>>>>
>>>> Hello,
>>>>
>>>> @Mike:
>>>>
>>>> I'm the author of that post :).
>>>>
>>>> Quick reply to your last comment:
>>>>
>>>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>>>> idea" in more specific way than "Fetching data takes more effort". Would be
>>>> helpful for anyone who is looking into using this approach.
>>>>
>>>> 2) The approach described in the post also says you can prefix with the
>>>> hash, you probably missed that.
>>>>
>>>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>>>> Please re-read the question: the intention is to distribute the load while
>>>> still being able to do "partial key scans". The blog post linked above
>>>> explains one possible solution for that, while your answer doesn't.
>>>>
>>>> @bigdata:
>>>>
>>>> Basically when it comes to solving two issues: distributing writes and
>>>> having ability to read data sequentially, you have to balance between being
>>>> good at both of them. Very good presentation by Lars:
>>>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
>>>> slide 22. You will see how this is correlated. In short:
>>>> * having md5/other hash prefix of the key does better w.r.t. distributing
>>>> writes, while compromises ability to do range scans efficiently
>>>> * having very limited number of 'salt' prefixes still allows to do range
>>>> scans (less efficiently than normal range scans, of course, but still good
>>>> enough in many cases) while providing worse distribution of writes
>>>>
>>>> In the latter case by choosing number of possible 'salt' prefixes (which
>>>> could be derived from hashed values, etc.) you can balance between
>>>> distributing writes efficiency and ability to run fast range scans.
>>>>
>>>> Hope this helps
>>>>
>>>> Alex Baranau
>>>> ------
>>>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>>>> Solr
>>>>
>>>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>>>> hope that the author of that blog take it down.
>>>>> While it may solve an initial problem in terms of region hot spotting, it
>>>>> creates another problem when it comes to fetching data. Fetching data takes
>>>>> more effort.
>>>>>
>>>>> With respect to using a hash (MD5 or SHA-1) you are creating a more random
>>>>> key that is unique to the record.  Some would argue that using MD5 or SHA-1
>>>>> that mathematically you could have a collision, however you could then
>>>>> append the key to the hash to guarantee uniqueness. You could also do
>>>>> things like take the hash and then truncate it to the first byte and then
>>>>> append the record key. This should give you enough randomness to avoid hot
>>>>> spotting after the initial region completion and you could pre-split out
>>>>> any number of regions. (First byte 0-255 for values, so you can program the
>>>>> split...
>>>>>
>>>>>
>>>>> Having said that... yes, you lose the ability to perform a sequential scan
>>>>> of the data.  At least to a point.  It depends on your schema.
>>>>>
>>>>> Note that you need to think about how you are primarily going to access
>>>>> the data.  You can then determine the best way to store the data to gain
>>>>> the best performance. For some applications... the region hot spotting
>>>>> isn't an important issue.
>>>>>
>>>>> Note YMMV
>>>>>
>>>>> HTH
>>>>>
>>>>> -Mike
>>>>>
>>>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>>>> (heavy scan):
>>>>>>  * you can use composed keys with a field that can segregate data
>>>>>> (hostname, productname, metric name) like OpenTSDB
>>>>>>  * or use Salt with a limited number of values (example
>>>>>> substr(md5(rowid),0,1) = 16 values)
>>>>>>    so that a scan is a combination of 16 filters on on each salt values
>>>>>>    you can base your code on HBaseWD by sematext
>>>>>>
>>>>>>
>>>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>>>       https://github.com/sematext/HBaseWD
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>>>
>>>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>>>> balance the records stored in different parts. But If I want to search
>>>>> some
>>>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>>>> not
>>>>>>> use rowkey filter to scan a range of date value one time on the date by
>>>>>>> MD5. How to balance this issue?
>>>>>>> Thanks.
>>
>  		 	   		  
> 

-- 
Damien HARDY
IT Infrastructure Architect
Viadeo - 30 rue de la Victoire - 75009 Paris - France
PGP : 45D7F89A

RE: Is it necessary to set MD5 on rowkey?

[bigdata <bi...@outlook.com>]

Thanks for your reply, Damien.
So this solution still use one scan object, and sent it to initTableMapperJob?
Does modified getsplit() function set the salt Bucket number to the number of mapper?If I set 256 salt buckets, and the mapper number will be 256, right?

Another question is can this bucket number be changed? Like 16 at first, when data became large, I expand it to 32, or 64? 
Thanks.

> Date: Tue, 17 Dec 2013 10:21:13 +0100
> From: dhardy@viadeoteam.com
> To: user@hbase.apache.org
> Subject: Re: Is it necessary to set MD5 on rowkey?
> 
> Hello,
> 
> yes you need 256 scans range or a full (almost) scan with combination of
> filters for each 256 ranges
> (https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/FilterList.Operator.html#MUST_PASS_ONE)
> 
> For mapreduce, the getsplit() method should be modified from
> TableInputFormatBase to handle salt values.
> This is what is done in
> https://github.com/sematext/HBaseWD/blob/master/src/main/java/com/sematext/hbase/wd/WdTableInputFormat.java
> (to return on HBaseWD example)
> 
> So a mapper (several if a salt value cover many regions) is dedicated
> for each salt value like simple TableInoutFormart would do without salt.
> 
> Best regards.
> 
> -- 
> Damien
> 
> 
> Le 17/12/2013 09:36, bigdata a écrit :
> > Hello,
> > @Alex Baranau
> > Thanks for your salt solution. In my understanding, the salt solution is divide the data into several partial(if 2 letters,00~FF, then 255 parts will be devided). My question is when I want to scan data, do I need scan 256 times for the following situation:rowkey:  salt prefix (00~FF) + date + xxx
> > And If I want do mapreduce on this table, if the initTableMapperJob(List<Scan>,...) is OK?
> > If example of scan the salted table is appreciated!
> > Thanks.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >> Date: Tue, 18 Dec 2012 12:12:37 -0500
> >> Subject: Re: Is it necessary to set MD5 on rowkey?
> >> From: alex.baranov.v@gmail.com
> >> To: user@hbase.apache.org
> >>
> >> Hello,
> >>
> >> @Mike:
> >>
> >> I'm the author of that post :).
> >>
> >> Quick reply to your last comment:
> >>
> >> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
> >> idea" in more specific way than "Fetching data takes more effort". Would be
> >> helpful for anyone who is looking into using this approach.
> >>
> >> 2) The approach described in the post also says you can prefix with the
> >> hash, you probably missed that.
> >>
> >> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
> >> Please re-read the question: the intention is to distribute the load while
> >> still being able to do "partial key scans". The blog post linked above
> >> explains one possible solution for that, while your answer doesn't.
> >>
> >> @bigdata:
> >>
> >> Basically when it comes to solving two issues: distributing writes and
> >> having ability to read data sequentially, you have to balance between being
> >> good at both of them. Very good presentation by Lars:
> >> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
> >> slide 22. You will see how this is correlated. In short:
> >> * having md5/other hash prefix of the key does better w.r.t. distributing
> >> writes, while compromises ability to do range scans efficiently
> >> * having very limited number of 'salt' prefixes still allows to do range
> >> scans (less efficiently than normal range scans, of course, but still good
> >> enough in many cases) while providing worse distribution of writes
> >>
> >> In the latter case by choosing number of possible 'salt' prefixes (which
> >> could be derived from hashed values, etc.) you can balance between
> >> distributing writes efficiency and ability to run fast range scans.
> >>
> >> Hope this helps
> >>
> >> Alex Baranau
> >> ------
> >> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
> >> Solr
> >>
> >> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:
> >>
> >>>
> >>> Hi,
> >>>
> >>> First, the use of a 'Salt' is a very, very bad idea and I would really
> >>> hope that the author of that blog take it down.
> >>> While it may solve an initial problem in terms of region hot spotting, it
> >>> creates another problem when it comes to fetching data. Fetching data takes
> >>> more effort.
> >>>
> >>> With respect to using a hash (MD5 or SHA-1) you are creating a more random
> >>> key that is unique to the record.  Some would argue that using MD5 or SHA-1
> >>> that mathematically you could have a collision, however you could then
> >>> append the key to the hash to guarantee uniqueness. You could also do
> >>> things like take the hash and then truncate it to the first byte and then
> >>> append the record key. This should give you enough randomness to avoid hot
> >>> spotting after the initial region completion and you could pre-split out
> >>> any number of regions. (First byte 0-255 for values, so you can program the
> >>> split...
> >>>
> >>>
> >>> Having said that... yes, you lose the ability to perform a sequential scan
> >>> of the data.  At least to a point.  It depends on your schema.
> >>>
> >>> Note that you need to think about how you are primarily going to access
> >>> the data.  You can then determine the best way to store the data to gain
> >>> the best performance. For some applications... the region hot spotting
> >>> isn't an important issue.
> >>>
> >>> Note YMMV
> >>>
> >>> HTH
> >>>
> >>> -Mike
> >>>
> >>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
> >>>> (heavy scan):
> >>>>  * you can use composed keys with a field that can segregate data
> >>>> (hostname, productname, metric name) like OpenTSDB
> >>>>  * or use Salt with a limited number of values (example
> >>>> substr(md5(rowid),0,1) = 16 values)
> >>>>    so that a scan is a combination of 16 filters on on each salt values
> >>>>    you can base your code on HBaseWD by sematext
> >>>>
> >>>>
> >>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> >>>>       https://github.com/sematext/HBaseWD
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> 2012/12/18 bigdata <bi...@outlook.com>
> >>>>
> >>>>> Many articles tell me that MD5 rowkey or part of it is good method to
> >>>>> balance the records stored in different parts. But If I want to search
> >>> some
> >>>>> sequential rowkey records, such as date as rowkey or partially. I can
> >>> not
> >>>>> use rowkey filter to scan a range of date value one time on the date by
> >>>>> MD5. How to balance this issue?
> >>>>> Thanks.
> 
 		 	   		  

Re: Is it necessary to set MD5 on rowkey?

[Damien Hardy <dh...@viadeoteam.com>]

Hello,

yes you need 256 scans range or a full (almost) scan with combination of
filters for each 256 ranges
(https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/filter/FilterList.Operator.html#MUST_PASS_ONE)

For mapreduce, the getsplit() method should be modified from
TableInputFormatBase to handle salt values.
This is what is done in
https://github.com/sematext/HBaseWD/blob/master/src/main/java/com/sematext/hbase/wd/WdTableInputFormat.java
(to return on HBaseWD example)

So a mapper (several if a salt value cover many regions) is dedicated
for each salt value like simple TableInoutFormart would do without salt.

Best regards.

-- 
Damien


Le 17/12/2013 09:36, bigdata a écrit :
> Hello,
> @Alex Baranau
> Thanks for your salt solution. In my understanding, the salt solution is divide the data into several partial(if 2 letters,00~FF, then 255 parts will be devided). My question is when I want to scan data, do I need scan 256 times for the following situation:rowkey:  salt prefix (00~FF) + date + xxx
> And If I want do mapreduce on this table, if the initTableMapperJob(List<Scan>,...) is OK?
> If example of scan the salted table is appreciated!
> Thanks.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Date: Tue, 18 Dec 2012 12:12:37 -0500
>> Subject: Re: Is it necessary to set MD5 on rowkey?
>> From: alex.baranov.v@gmail.com
>> To: user@hbase.apache.org
>>
>> Hello,
>>
>> @Mike:
>>
>> I'm the author of that post :).
>>
>> Quick reply to your last comment:
>>
>> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
>> idea" in more specific way than "Fetching data takes more effort". Would be
>> helpful for anyone who is looking into using this approach.
>>
>> 2) The approach described in the post also says you can prefix with the
>> hash, you probably missed that.
>>
>> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
>> Please re-read the question: the intention is to distribute the load while
>> still being able to do "partial key scans". The blog post linked above
>> explains one possible solution for that, while your answer doesn't.
>>
>> @bigdata:
>>
>> Basically when it comes to solving two issues: distributing writes and
>> having ability to read data sequentially, you have to balance between being
>> good at both of them. Very good presentation by Lars:
>> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
>> slide 22. You will see how this is correlated. In short:
>> * having md5/other hash prefix of the key does better w.r.t. distributing
>> writes, while compromises ability to do range scans efficiently
>> * having very limited number of 'salt' prefixes still allows to do range
>> scans (less efficiently than normal range scans, of course, but still good
>> enough in many cases) while providing worse distribution of writes
>>
>> In the latter case by choosing number of possible 'salt' prefixes (which
>> could be derived from hashed values, etc.) you can balance between
>> distributing writes efficiency and ability to run fast range scans.
>>
>> Hope this helps
>>
>> Alex Baranau
>> ------
>> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
>> Solr
>>
>> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:
>>
>>>
>>> Hi,
>>>
>>> First, the use of a 'Salt' is a very, very bad idea and I would really
>>> hope that the author of that blog take it down.
>>> While it may solve an initial problem in terms of region hot spotting, it
>>> creates another problem when it comes to fetching data. Fetching data takes
>>> more effort.
>>>
>>> With respect to using a hash (MD5 or SHA-1) you are creating a more random
>>> key that is unique to the record.  Some would argue that using MD5 or SHA-1
>>> that mathematically you could have a collision, however you could then
>>> append the key to the hash to guarantee uniqueness. You could also do
>>> things like take the hash and then truncate it to the first byte and then
>>> append the record key. This should give you enough randomness to avoid hot
>>> spotting after the initial region completion and you could pre-split out
>>> any number of regions. (First byte 0-255 for values, so you can program the
>>> split...
>>>
>>>
>>> Having said that... yes, you lose the ability to perform a sequential scan
>>> of the data.  At least to a point.  It depends on your schema.
>>>
>>> Note that you need to think about how you are primarily going to access
>>> the data.  You can then determine the best way to store the data to gain
>>> the best performance. For some applications... the region hot spotting
>>> isn't an important issue.
>>>
>>> Note YMMV
>>>
>>> HTH
>>>
>>> -Mike
>>>
>>> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> There is middle term betwen sequecial keys (hot spoting risk) and md5
>>>> (heavy scan):
>>>>  * you can use composed keys with a field that can segregate data
>>>> (hostname, productname, metric name) like OpenTSDB
>>>>  * or use Salt with a limited number of values (example
>>>> substr(md5(rowid),0,1) = 16 values)
>>>>    so that a scan is a combination of 16 filters on on each salt values
>>>>    you can base your code on HBaseWD by sematext
>>>>
>>>>
>>> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>>>>       https://github.com/sematext/HBaseWD
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> 2012/12/18 bigdata <bi...@outlook.com>
>>>>
>>>>> Many articles tell me that MD5 rowkey or part of it is good method to
>>>>> balance the records stored in different parts. But If I want to search
>>> some
>>>>> sequential rowkey records, such as date as rowkey or partially. I can
>>> not
>>>>> use rowkey filter to scan a range of date value one time on the date by
>>>>> MD5. How to balance this issue?
>>>>> Thanks.

RE: Is it necessary to set MD5 on rowkey?

[bigdata <bi...@outlook.com>]

Hello,
@Alex Baranau
Thanks for your salt solution. In my understanding, the salt solution is divide the data into several partial(if 2 letters,00~FF, then 255 parts will be devided). My question is when I want to scan data, do I need scan 256 times for the following situation:rowkey:  salt prefix (00~FF) + date + xxx
And If I want do mapreduce on this table, if the initTableMapperJob(List<Scan>,...) is OK?
If example of scan the salted table is appreciated!
Thanks.









> Date: Tue, 18 Dec 2012 12:12:37 -0500
> Subject: Re: Is it necessary to set MD5 on rowkey?
> From: alex.baranov.v@gmail.com
> To: user@hbase.apache.org
> 
> Hello,
> 
> @Mike:
> 
> I'm the author of that post :).
> 
> Quick reply to your last comment:
> 
> 1) Could you please describe why "the use of a 'Salt' is a very, very bad
> idea" in more specific way than "Fetching data takes more effort". Would be
> helpful for anyone who is looking into using this approach.
> 
> 2) The approach described in the post also says you can prefix with the
> hash, you probably missed that.
> 
> 3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
> Please re-read the question: the intention is to distribute the load while
> still being able to do "partial key scans". The blog post linked above
> explains one possible solution for that, while your answer doesn't.
> 
> @bigdata:
> 
> Basically when it comes to solving two issues: distributing writes and
> having ability to read data sequentially, you have to balance between being
> good at both of them. Very good presentation by Lars:
> http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
> slide 22. You will see how this is correlated. In short:
> * having md5/other hash prefix of the key does better w.r.t. distributing
> writes, while compromises ability to do range scans efficiently
> * having very limited number of 'salt' prefixes still allows to do range
> scans (less efficiently than normal range scans, of course, but still good
> enough in many cases) while providing worse distribution of writes
> 
> In the latter case by choosing number of possible 'salt' prefixes (which
> could be derived from hashed values, etc.) you can balance between
> distributing writes efficiency and ability to run fast range scans.
> 
> Hope this helps
> 
> Alex Baranau
> ------
> Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
> Solr
> 
> On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:
> 
> >
> > Hi,
> >
> > First, the use of a 'Salt' is a very, very bad idea and I would really
> > hope that the author of that blog take it down.
> > While it may solve an initial problem in terms of region hot spotting, it
> > creates another problem when it comes to fetching data. Fetching data takes
> > more effort.
> >
> > With respect to using a hash (MD5 or SHA-1) you are creating a more random
> > key that is unique to the record.  Some would argue that using MD5 or SHA-1
> > that mathematically you could have a collision, however you could then
> > append the key to the hash to guarantee uniqueness. You could also do
> > things like take the hash and then truncate it to the first byte and then
> > append the record key. This should give you enough randomness to avoid hot
> > spotting after the initial region completion and you could pre-split out
> > any number of regions. (First byte 0-255 for values, so you can program the
> > split...
> >
> >
> > Having said that... yes, you lose the ability to perform a sequential scan
> > of the data.  At least to a point.  It depends on your schema.
> >
> > Note that you need to think about how you are primarily going to access
> > the data.  You can then determine the best way to store the data to gain
> > the best performance. For some applications... the region hot spotting
> > isn't an important issue.
> >
> > Note YMMV
> >
> > HTH
> >
> > -Mike
> >
> > On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
> >
> > > Hello,
> > >
> > > There is middle term betwen sequecial keys (hot spoting risk) and md5
> > > (heavy scan):
> > >  * you can use composed keys with a field that can segregate data
> > > (hostname, productname, metric name) like OpenTSDB
> > >  * or use Salt with a limited number of values (example
> > > substr(md5(rowid),0,1) = 16 values)
> > >    so that a scan is a combination of 16 filters on on each salt values
> > >    you can base your code on HBaseWD by sematext
> > >
> > >
> > http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> > >       https://github.com/sematext/HBaseWD
> > >
> > > Cheers,
> > >
> > >
> > > 2012/12/18 bigdata <bi...@outlook.com>
> > >
> > >> Many articles tell me that MD5 rowkey or part of it is good method to
> > >> balance the records stored in different parts. But If I want to search
> > some
> > >> sequential rowkey records, such as date as rowkey or partially. I can
> > not
> > >> use rowkey filter to scan a range of date value one time on the date by
> > >> MD5. How to balance this issue?
> > >> Thanks.
> > >>
> > >>
> > >
> > >
> > >
> > >
> > > --
> > > Damien HARDY
> >
> >
 		 	   		  

Re: Is it necessary to set MD5 on rowkey?

[Alex Baranau <al...@gmail.com>]

Hello,

@Mike:

I'm the author of that post :).

Quick reply to your last comment:

1) Could you please describe why "the use of a 'Salt' is a very, very bad
idea" in more specific way than "Fetching data takes more effort". Would be
helpful for anyone who is looking into using this approach.

2) The approach described in the post also says you can prefix with the
hash, you probably missed that.

3) I believe your answer, "use MD5 or SHA-1" doesn't help bigdata guy.
Please re-read the question: the intention is to distribute the load while
still being able to do "partial key scans". The blog post linked above
explains one possible solution for that, while your answer doesn't.

@bigdata:

Basically when it comes to solving two issues: distributing writes and
having ability to read data sequentially, you have to balance between being
good at both of them. Very good presentation by Lars:
http://www.slideshare.net/larsgeorge/hbase-advanced-schema-design-berlin-buzzwords-june-2012,
slide 22. You will see how this is correlated. In short:
* having md5/other hash prefix of the key does better w.r.t. distributing
writes, while compromises ability to do range scans efficiently
* having very limited number of 'salt' prefixes still allows to do range
scans (less efficiently than normal range scans, of course, but still good
enough in many cases) while providing worse distribution of writes

In the latter case by choosing number of possible 'salt' prefixes (which
could be derived from hashed values, etc.) you can balance between
distributing writes efficiency and ability to run fast range scans.

Hope this helps

Alex Baranau
------
Sematext :: http://blog.sematext.com/ :: Hadoop - HBase - ElasticSearch -
Solr

On Tue, Dec 18, 2012 at 8:52 AM, Michael Segel <mi...@hotmail.com>wrote:

>
> Hi,
>
> First, the use of a 'Salt' is a very, very bad idea and I would really
> hope that the author of that blog take it down.
> While it may solve an initial problem in terms of region hot spotting, it
> creates another problem when it comes to fetching data. Fetching data takes
> more effort.
>
> With respect to using a hash (MD5 or SHA-1) you are creating a more random
> key that is unique to the record.  Some would argue that using MD5 or SHA-1
> that mathematically you could have a collision, however you could then
> append the key to the hash to guarantee uniqueness. You could also do
> things like take the hash and then truncate it to the first byte and then
> append the record key. This should give you enough randomness to avoid hot
> spotting after the initial region completion and you could pre-split out
> any number of regions. (First byte 0-255 for values, so you can program the
> split...
>
>
> Having said that... yes, you lose the ability to perform a sequential scan
> of the data.  At least to a point.  It depends on your schema.
>
> Note that you need to think about how you are primarily going to access
> the data.  You can then determine the best way to store the data to gain
> the best performance. For some applications... the region hot spotting
> isn't an important issue.
>
> Note YMMV
>
> HTH
>
> -Mike
>
> On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:
>
> > Hello,
> >
> > There is middle term betwen sequecial keys (hot spoting risk) and md5
> > (heavy scan):
> >  * you can use composed keys with a field that can segregate data
> > (hostname, productname, metric name) like OpenTSDB
> >  * or use Salt with a limited number of values (example
> > substr(md5(rowid),0,1) = 16 values)
> >    so that a scan is a combination of 16 filters on on each salt values
> >    you can base your code on HBaseWD by sematext
> >
> >
> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
> >       https://github.com/sematext/HBaseWD
> >
> > Cheers,
> >
> >
> > 2012/12/18 bigdata <bi...@outlook.com>
> >
> >> Many articles tell me that MD5 rowkey or part of it is good method to
> >> balance the records stored in different parts. But If I want to search
> some
> >> sequential rowkey records, such as date as rowkey or partially. I can
> not
> >> use rowkey filter to scan a range of date value one time on the date by
> >> MD5. How to balance this issue?
> >> Thanks.
> >>
> >>
> >
> >
> >
> >
> > --
> > Damien HARDY
>
>

Re: Is it necessary to set MD5 on rowkey?

[Michael Segel <mi...@hotmail.com>]

Hi,

First, the use of a 'Salt' is a very, very bad idea and I would really hope that the author of that blog take it down.
While it may solve an initial problem in terms of region hot spotting, it creates another problem when it comes to fetching data. Fetching data takes more effort.

With respect to using a hash (MD5 or SHA-1) you are creating a more random key that is unique to the record.  Some would argue that using MD5 or SHA-1 that mathematically you could have a collision, however you could then append the key to the hash to guarantee uniqueness. You could also do things like take the hash and then truncate it to the first byte and then append the record key. This should give you enough randomness to avoid hot spotting after the initial region completion and you could pre-split out any number of regions. (First byte 0-255 for values, so you can program the split... 


Having said that... yes, you lose the ability to perform a sequential scan of the data.  At least to a point.  It depends on your schema. 

Note that you need to think about how you are primarily going to access the data.  You can then determine the best way to store the data to gain the best performance. For some applications... the region hot spotting isn't an important issue. 

Note YMMV

HTH

-Mike

On Dec 18, 2012, at 3:33 AM, Damien Hardy <dh...@viadeoteam.com> wrote:

> Hello,
> 
> There is middle term betwen sequecial keys (hot spoting risk) and md5
> (heavy scan):
>  * you can use composed keys with a field that can segregate data
> (hostname, productname, metric name) like OpenTSDB
>  * or use Salt with a limited number of values (example
> substr(md5(rowid),0,1) = 16 values)
>    so that a scan is a combination of 16 filters on on each salt values
>    you can base your code on HBaseWD by sematext
> 
> http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
>       https://github.com/sematext/HBaseWD
> 
> Cheers,
> 
> 
> 2012/12/18 bigdata <bi...@outlook.com>
> 
>> Many articles tell me that MD5 rowkey or part of it is good method to
>> balance the records stored in different parts. But If I want to search some
>> sequential rowkey records, such as date as rowkey or partially. I can not
>> use rowkey filter to scan a range of date value one time on the date by
>> MD5. How to balance this issue?
>> Thanks.
>> 
>> 
> 
> 
> 
> 
> -- 
> Damien HARDY

Re: Is it necessary to set MD5 on rowkey?

[Damien Hardy <dh...@viadeoteam.com>]

Hello,

There is middle term betwen sequecial keys (hot spoting risk) and md5
(heavy scan):
  * you can use composed keys with a field that can segregate data
(hostname, productname, metric name) like OpenTSDB
  * or use Salt with a limited number of values (example
substr(md5(rowid),0,1) = 16 values)
    so that a scan is a combination of 16 filters on on each salt values
    you can base your code on HBaseWD by sematext

http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
       https://github.com/sematext/HBaseWD

Cheers,


2012/12/18 bigdata <bi...@outlook.com>

> Many articles tell me that MD5 rowkey or part of it is good method to
> balance the records stored in different parts. But If I want to search some
> sequential rowkey records, such as date as rowkey or partially. I can not
> use rowkey filter to scan a range of date value one time on the date by
> MD5. How to balance this issue?
> Thanks.
>
>




-- 
Damien HARDY

Re: Is it necessary to set MD5 on rowkey?

[Doug Meil <do...@explorysmedical.com>]

Hi there-

You don't want a filter for this, use a Scan with the lead portion of the
key.

http://hbase.apache.org/book.html#datamodel

See "5.7.3. Scans"

On a related topic, this is a utility in process to make composite key
construction easier.

https://issues.apache.org/jira/browse/HBASE-7221





On 12/18/12 4:20 AM, "bigdata" <bi...@outlook.com> wrote:

>Many articles tell me that MD5 rowkey or part of it is good method to
>balance the records stored in different parts. But If I want to search
>some sequential rowkey records, such as date as rowkey or partially. I
>can not use rowkey filter to scan a range of date value one time on the
>date by MD5. How to balance this issue?
>Thanks.
>
>