[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873542#comment-16873542
]
Andrew Purtell edited comment on HBASE-22622 at 6/26/19 5:33 PM:
-----------------------------------------------------------------
{quote}So now we have a Scan with both the appropriate table, projected
columns, and Filters.
{quote}
This is a great point and the crux of the matter. Phoenix views are projected
columns over an HBase base table. HBase doesn't know anything about these
projected columns, nor should it, so in contexts like replication where the
object and interfaces design is HBase-only, we need to import some additional
context. In replication, we have only WALentry, WALkey, and WALedit.
WALentry can be annotated with in-memory structures but they won't be
serialized and shipped to a remote replication context.
WALedit is just a bunch of cells. We can make synthetic cells or add cell tags
but with side effect this information is persisted to table storage (which we
neither need nor desire).
WALkey is protobufed, extensible, serialized, available in the replication
context where needed (and in other places where WAL entries might be
enumerated, which could be useful for future use cases), and not persisted to
the table. Seems relatively ideal given other options.
was (Author: apurtell):
{quote}So now we have a Scan with both the appropriate table, projected
columns, and Filters.
{quote}
This is a great point and the crux of the matter. Phoenix views are projected
columns over an HBase base table. HBase doesn't know anything about these
projected columns, nor should it, so in contexts like replication where the
object and interfaces design is HBase-only, we need to import some additional
context. In replication, we have only WALentry, WALkey, and WALedit.
WALentry can be annotated with in-memory structures but they won't be
serialized and shipped to a remote replication context.
WALedit is just a bunch of cells. We can make synthetic cells or add cell tags
but with side effect this information is persisted to table storage (which we
neither need nor desire).
WALkey is protobufed, extensible, serialized, available in the replication
context where needed, and not persisted to the table. Seems relatively ideal
given other options.
> 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)
