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 Plain View
HBase >> mail # user >> Inconsistencies in comparisons using KeyComparator


+
Alan Chaney 2013-04-01, 14:54
Copy link to this message
-
Re: Inconsistencies in comparisons using KeyComparator
That is an interesting (disturbing) find Alan.  Hopefully the fallback is
rare.  Did you have a technique for making the compare fallback to pure
java compare?

Thank you,
St.Ack
On Mon, Apr 1, 2013 at 7:54 AM, Alan Chaney <[EMAIL PROTECTED]> wrote:

> Hi
>
> I need to write some code that sorts row keys identically to HBase.
>
> I looked at the KeyValue.KeyComparator code, and it seems that, by
> default, HBase elects to use the 'Unsafe' comparator as the basis of its
> comparison, with a fall-back to to the PureJavaComparer should Unsafe not
> be available (for example, in tests.)
>
> However, I'm finding that the sort order from a call to
> KeyValue.KeyComparator appears to be inconsistent between the two forms.
>
> As an example, comparing:
>
> (first param) (second param)
> 0000000000000000ffffffffffffff**ffffffffffffffffff616c1b to
> 0000000000000000ffffffffffffff**ffffffffffffffffff61741b
>
> gives 1 for the default (presumably, Unsafe) call, and -1 using the
> PureJavaComparator.
>
> I would actually expect it to be a -ve number, based on the difference of
> 6c to 74 in the 3rd from last byte above.
>
> Similarly
>
> 000000000000000000000000000000**000000000000000000616c1b to
> 000000000000000000000000000000**0000000000000000061741b
>
> gives > 0 instead of < 0. The PureJavaComparator does a byte-by-byte
> comparison by
>
> Is this expected? From the definition of lexicographical compare that I
> found, I don't think so. There's no issue of signed comparison here,
> because 0x6c and 0x74 are still +ve byte values.
>
> Regards
>
> Alan
>
>
>
+
Alan Chaney 2013-04-01, 17:04
+
Ted Yu 2013-04-01, 18:37
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