[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872947#comment-16872947
]
Geoffrey Jacoby commented on HBASE-22622:
-----------------------------------------
[~Apache9] - Phoenix maintains its own schema. When you say "SELECT * FROM
FOO.BAR" in Phoenix, it does not resolve what FOO.BAR is using HBase's .META
table, but Phoenix's System.Catalog table. There are simple cases where the
logical table, view, or index name defined in System.Catalog might happen to
correspond 1:1 to a physical HBase table defined in .META. But in many cases
multiple Phoenix constructs map to a single physical HBase table. The design
was chosen out of a belief that HBase scales better with more regions on fewer
tables, and the desire to allow for very large numbers of logical tables and
views.
When doing a Phoenix query or statement, Phoenix has access to the JDBC
connection (which has tenant/user information) and the text of the SQL itself
to provide enough information to do the mapping between a logical Phoenix table
and a physical HBase table.
When in a replication endpoint, there are only WAL.Entries, which contain
WALKeys and WALEdits. The WALKey contains information about the physical HBase
region and table; the WALEdit contains the raw Cells. The JDBC connection and
the SQL statement that created those Cells are gone, so there's no longer
enough context to figure out which Phoenix object the WALEntry was originally
associated with.
As [~apurtell] says, this JIRA would allow Phoenix to annotate the WALKey with
the provenance metadata we're missing.
> 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)
