[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872957#comment-16872957
]
Geoffrey Jacoby edited comment on HBASE-22622 at 6/26/19 6:09 AM:
------------------------------------------------------------------
[~stack] - This JIRA has a related sibling, HBASE-22623, for adding any
necessary coprocessor hooks. If having a protobuf-based object as a parameter
to a coprocessor is a concern, I'm happy to have a hook (with a default no-op
of course) that asks the coproc to provide a map or list of key/value pairs
that then gets added into the WALKey by fixed non-overridable HBase code, so
the actual protobufs don't leak into RegionObserver.
As for Cell level tags, I'd expect that to logically work but not be doable for
storage / perf reasons, since even with a consistent hash of the tuple
[~apurtell] mentions, that's going to expand the data written to the WAL (and
the table!) by quite a bit, wouldn't it?
was (Author: gjacoby):
[~stack] - This JIRA has a related sibling, HBASE-22623, for adding any
necessary coprocessor hooks. If having a protobuf-based object as a parameter
to a coprocessor is a concern, I'm happy to have a hook (with a default no-op
of course) that asks the coproc to provide a map or list of key/value pairs
that then gets added into the WALKey by fixed non-overridable HBase code, so
the actual protobufs don't leak into RegionObserver.
As for Cell level tags, I'd expect that to logically work but not be doable for
storage / perf reasons, since even with a consistent hash of the tuple
[~apurtell] mentions, that's going to expand the data written to the WAL by
quite a bit, wouldn't it?
> 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)
