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 >> Inconsistencies in comparisons using KeyComparator


Copy link to this message
-
Inconsistencies in comparisons using KeyComparator
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)
0000000000000000ffffffffffffffffffffffffffffffff616c1b to
0000000000000000ffffffffffffffffffffffffffffffff61741b

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

000000000000000000000000000000000000000000000000616c1b to
0000000000000000000000000000000000000000000000061741b

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
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