Thanks for you explanation William, now I understand.
Really appreciated!
在 2016年05月31日 09:41, William 写道:
Hi, 金砖
For signed data types, phoenix will flip the first bit to guarantee
the expected sort order for binary comparison. For example:
100, its binary: 0x00 00 00 64
-100, its binary: 0xFF FF FF 9C
As we all know, 100 is greater than -100, but their sort order by
binary comparison is 0xFF FF FF 9C > 0x00 00 00 64.
So we cannot simply store the original bytes to hbase, we have to
flip the first byte (the sign byte) so that their binary sort order is
as expected.
100 -> 0x00 00 00 64 -> flip the first byte: 0x80 00 00 64
-100 -> 0xFF FF FF 9C -> flip the first byte: 0x7F FF FF 9C
Actually we store 0x80 00 00 64 for 100, 0x7F FF FF 9C for -100, so
the binary comparison result is the same as the original values.
The code is in PInteger.IntCodec#decodeInt(), encodeInt(), as well
as other numeric data types like PLong, PShort, etc.
As long as you are using hbase to store signed values, this is one
issue you must look into, no matter you are using phoenix or not.
For unsigned data types, phoenix does the same thing as
Bytes.toBytes. So when you import existing hbase table to phoenix, you
should flip the first byte for signed data and do nothing for unsigned
data.
I hope this will help you solve your problem.
Thanks.
William.
At 2016-05-30 22:24:15, "Christian Hellström" <[email protected]>
wrote:
Because HBase does not store metadata, which Phoenix needs to be a
true SQL skin.
On 30 May 2016 1:30 p.m., "金砖" <[email protected]
<mailto:[email protected]>> wrote:
hi, ALL:
Recently I'm importing existing hbase table to phoenix and
I found out phoenix toBytes
method(org.apache.phoenix.schema.types.PInteger.toBytes) is
different to hbase(org.apache.hadoop.hbase.util.Bytes.toBytes).
And document says only support hbase positive values.
Why not just use hbase to bytes? And hbase negative values is
supported?
