phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Reid <gabriel.r...@gmail.com>
Subject Re: Can't find some of our Phoenix primary keys in our HBase table when looking for row keys
Date Tue, 23 Aug 2016 19:02:20 GMT
Hi Tom,

What's the primary key definition of your table? Does it have salted row keys?

In the first example (the one that works) I see a leading byte on the
row key, which makes me think that you're using salting. In the second
example (the one that isn't working) I see the leading "\x00" being
added, but my guess (certainly if you're using salted row keys) is
that this isn't the correct salt byte for that row key.

If you are using salted row keys (or a composite primary key), then
the first byte of the row key that you use to look up the record in
HBase will have to be correctly filled in to take this into account.

- Gabriel

On Tue, Aug 23, 2016 at 7:52 PM, Squires, Tom (ELS-LON)
<tom.squires@elsevier.com> wrote:
> Hi there,
>
> If we scan our HBase table via hbase shell - limiting to just one result -
> we get:
>
> hbase(main):003:0* scan 'SCHEMA.DOCUMENTS', { LIMIT => 1 }
> ROW                                                           COLUMN+CELL
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:ADDED, timestamp=1471470328985, value=\x80\x00\x01GXU\xBA\x18
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:CONFIRMED, timestamp=1471470328985, value=\x81
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:DELETIONPENDING, timestamp=1471470328985, value=\x80
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4                      column=0:ID,
> timestamp=1471470328985, value=\x80\x00\x00\x01\x85\xDE\xE4\xD9
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:IMPORTER_ID, timestamp=1471470328985, value=\x80\x00\x00\x18
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:ISAUTHOR, timestamp=1471470328985, value=\x80
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:ISREAD, timestamp=1471470328985, value=\x80
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:ISSTARRED, timestamp=1471470328985, value=\x80
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:MODIFIED, timestamp=1471470328985,
> value=\x80\x00\x01GXW-0\x00\x00\x00\x00
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:MONTH, timestamp=1471470328985, value=\x80\x00\x00\x09
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:ONLYREFERENCE, timestamp=1471470328985, value=\x80
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:PROFILE_ID, timestamp=1471470328985, value=\xC4`\x09NH
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:PUBLISHED_IN, timestamp=1471470328985, value=A journal.
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:TITLE, timestamp=1471470328985, value=A title.
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:TYPE_ID, timestamp=1471470328985, value=\x80\x00\x00\x01
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4
> column=0:UNIQUE_ID, timestamp=1471470328985,
> value=fdc82767-106f-47bc-91b5-0df5d90fba72
> \x00000000cd-ba0c-39cb-9490-39ca6448d6e4                      column=0:_0,
> timestamp=1471470328985, value=x
> 1 row(s) in 0.2570 seconds
>
> We're able to get this row key from hbase shell directly:
>
> hbase(main):006:0> get 'SCHEMA.DOCUMENTS',
> "\x00000000cd-ba0c-39cb-9490-39ca6448d6e4"
> COLUMN                                                        CELL
> 0:ADDED
> timestamp=1471470328985, value=\x80\x00\x01GXU\xBA\x18
> 0:CONFIRMED
> timestamp=1471470328985, value=\x81
> 0:DELETIONPENDING
> timestamp=1471470328985, value=\x80
> 0:ID
> timestamp=1471470328985, value=\x80\x00\x00\x01\x85\xDE\xE4\xD9
> 0:IMPORTER_ID
> timestamp=1471470328985, value=\x80\x00\x00\x18
> 0:ISAUTHOR
> timestamp=1471470328985, value=\x80
> 0:ISREAD
> timestamp=1471470328985, value=\x80
> 0:ISSTARRED
> timestamp=1471470328985, value=\x80
> 0:MODIFIED
> timestamp=1471470328985, value=\x80\x00\x01GXW-0\x00\x00\x00\x00
> 0:MONTH
> timestamp=1471470328985, value=\x80\x00\x00\x09
> 0:ONLYREFERENCE
> timestamp=1471470328985, value=\x80
> 0:PROFILE_ID
> timestamp=1471470328985, value=\xC4`\x09NH
> 0:PUBLISHED_IN
> timestamp=1471470328985, value=A journal.
> 0:TITLE
> timestamp=1471470328985, value=A title.
> 0:TYPE_ID
> timestamp=1471470328985, value=\x80\x00\x00\x01
> 0:UNIQUE_ID
> timestamp=1471470328985, value=fdc82767-106f-47bc-91b5-0df5d90fba72
> 0:YEAR
> timestamp=1471470328985, value=\x80\x00\x07\xDD
> 0:_0
> timestamp=1471470328985, value=x
> 18 row(s) in 0.0750 seconds
>
> We are also able to look for this row key in Phoenix via a primary key
> lookup (same HBase cluster), and we find it successfully:
>
> 0: jdbc:phoenix:localhost:2181> select uuid from SCHEMA.DOCUMENTS where uuid
> = '000000cd-ba0c-39cb-9490-39ca6448d6e4';
> +---------------------------------------+
> |                 UUID                  |
> +---------------------------------------+
> | 000000cd-ba0c-39cb-9490-39ca6448d6e4  |
> +---------------------------------------+
> 1 row selected (0.085 seconds)
>
> However, if we pick a random row from Phoenix:
>
> 0: jdbc:phoenix:localhost:2181> select uuid from SCHEMA.DOCUMENTS limit 1;
> +---------------------------------------+
> |                 UUID                  |
> +---------------------------------------+
> | 0061b1a3-4e08-3b24-9fe3-a5d8c2e35455  |
> +---------------------------------------+
> 1 row selected (0.064 seconds)
>
> And look it up in HBase:
>
> hbase(main):005:0> get 'SCHEMA.DOCUMENTS',
> "\x000061b1a3-4e08-3b24-9fe3-a5d8c2e35455"
> COLUMN                                                         CELL
> 0 row(s) in 0.0040 seconds
>
> We don't get anything back. We are connected to the HBase master for all of
> the above queries. Are we doing something silly?  Is there something we're
> missing?
>
> Thanks,
> Tom
>
>
>
> ________________________________
>
> Elsevier Limited. Registered Office: The Boulevard, Langford Lane,
> Kidlington, Oxford, OX5 1GB, United Kingdom, Registration No. 1982084,
> Registered in England and Wales.

Mime
View raw message