[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16873510#comment-16873510
]
Andrew Purtell commented on HBASE-22622:
----------------------------------------
We could add cell tags to the special row marker cell that Phoenix uses and
search for this cell in every WALedit but then this metadata will be persisted
to the local table at least, perhaps remote table too if we don’t or can’t
rewrite the cell before shipping it. That is wasteful. We only need this
information when processing the WAL entry in replication.
It seems really simple to annotate the WALkey, in comparison to existing
alternates like cell tags or adding synthetic cells to carry metadata, which
then need compensatory tricks to somehow avoid persisting them in the table, or
acceptance of storage bloat. Surely we don’t need to have the Phoenix schema
detail duplicated in every row...
> 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)
