Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Is it necessary to set MD5 on rowkey?


Copy link to this message
-
Re: Is it necessary to set MD5 on rowkey?
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>>
>>> On Wed, Dec 19, 2012 at 1:26 PM, David Arthur <[EMAIL PROTECTED]> 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
>>>
>>
>>
>
>

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB