[
https://issues.apache.org/jira/browse/HBASE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13748944#comment-13748944
]
Andrew Purtell commented on HBASE-9291:
---------------------------------------
{quote}
The use case where the above are necessary in Phoenix include:
1) Hash joins, where the results of the smaller side of a join scan are
packaged up and sent to each region server, and
2) Secondary indexing, where the metadata of knowing a) which column
family/column qualifier pairs and b) which part of the row key contributes to
which indexes are sent to each region server that will process a batched put.
[...]
For both these cases, it'd be a cache at the RegionServer level. All the
regions would get this information from this cache.
{quote}
I'm wondering if any HBase changes are needed. Can you create an Endpoint, call
it first to transmit the large data along with a "join ID", and then pass the
join ID only on the operationAttribute, that your Observer(s) would look for,
and finally manage that RegionServer level cache with a singleton for that
purpose? Now as a consequence there would be the additional round trip for the
Exec call, but given the data you want to send over and cache for many
additional invocations is large, the overhead would be small.
> Enable client to setAttribute that is sent once to each region server
> ---------------------------------------------------------------------
>
> Key: HBASE-9291
> URL: https://issues.apache.org/jira/browse/HBASE-9291
> Project: HBase
> Issue Type: New Feature
> Components: IPC/RPC
> Reporter: James Taylor
>
> Currently a Scan and Mutation allow the client to set its own attributes that
> get passed through the RPC layer and are accessible from a coprocessor. This
> is very handy, but breaks down if the amount of information is large, since
> this information ends up being sent again and again to every region. Clients
> can work around this with an endpoint "pre" and "post" coprocessor invocation
> that:
> 1) sends the information and caches it on the region server in the "pre"
> invocation
> 2) invokes the Scan or sends the batch of Mutations, and then
> 3) removes it in the "post" invocation.
> In this case, the client is forced to identify all region servers (ideally,
> all region servers that will be involved in the Scan/Mutation), make extra
> RPC calls, manage the caching of the information on the region server,
> age-out the information (in case the client dies before step (3) that clears
> the cached information), and must deal with the possibility of a split
> occurring while this operation is in-progress.
> Instead, it'd be much better if an attribute could be identified as a "region
> server" attribute in OperationWithAttributes and the HBase RPC layer would
> take care of doing the above.
> The use case where the above are necessary in Phoenix include:
> 1) Hash joins, where the results of the smaller side of a join scan are
> packaged up and sent to each region server, and
> 2) Secondary indexing, where the metadata of knowing a) which column
> family/column qualifier pairs and b) which part of the row key contributes to
> which indexes are sent to each region server that will process a batched put.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
