[jira] [Comment Edited] (HBASE-22622) WALKey Extended Attributes

["Geoffrey Jacoby (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872062#comment-16872062 ] 

Geoffrey Jacoby edited comment on HBASE-22622 at 6/25/19 6:26 AM:
------------------------------------------------------------------

[~Apache9] Updated the description to (I hope) make it a little clearer.

The example is just that, an example, and a bit oversimplified so it fits in a sentence or two. (See PHOENIX-5315 for a more complex example, if you're interested.) This JIRA, along with its sibling over at HBASE-22623, is just to add the capacity for coprocessors to optionally write extended metadata of their choice into WALKeys. What Phoenix or any other application chooses to do with it would then be up to them.

To answer your question though, Phoenix allows multiple logical views, which are treated like tables in SQL, to map to a single physical HBase table. (It also allows both a Phoenix table and one or more Phoenix local indexes to coexist in the same physical HBase table.) Phoenix coprocessors make sure that the Scans and Puts "just work" for this; if you're interested, it's described [here|http://phoenix.apache.org/views.html]. However, by the time you get to tailing a WAL Entry in a replication endpoint, all the Phoenix level schema information is gone. 

 


was (Author: gjacoby):
[~Apache9] Updated the description to (I hope) make it a little clearer.

The example is just that, an example, and a bit oversimplified so it fits in a sentence or two. (See PHOENIX-5315 for a more complex example, if you're interested.) This JIRA, along with its sibling over at HBASE-22623, is just to add the capacity for applications to optionally write extended metadata of their choice into WALKeys. What Phoenix or any other application chooses to do with it would then be up to them.

To answer your question though, Phoenix allows multiple logical views, which are treated like tables in SQL, to map to a single physical HBase table. (It also allows both a Phoenix table and one or more Phoenix local indexes to coexist in the same physical HBase table.) Phoenix coprocessors make sure that the Scans and Puts "just work" for this; if you're interested, it's described [here|http://phoenix.apache.org/views.html]. However, by the time you get to tailing a WAL Entry in a replication endpoint, all the Phoenix level schema information is gone. 

 

> WALKey Extended Attributes
> --------------------------
>
>                 Key: HBASE-22622
>                 URL: https://issues.apache.org/jira/browse/HBASE-22622
>             Project: HBase
>          Issue Type: New Feature
>          Components: wal
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>
> It would be useful if the WAL protobuf and WALKey class included an optional map of extended key/value attributes that downstream coprocessors could use to annotate WAL Entries. While standard HBase replication would not use them, custom replication endpoints could use the data to make filtering decisions or take actions.
> An example use case would be allowing a tool like Phoenix to annotate WAL.Entries to indicate that a given Entry is associated with a particular Phoenix view rather than the base Phoenix table. (Multiple logical views in Phoenix can map to the same physical HBase table.) A custom replication endpoint might choose to replicate some views but not others. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)