[
https://issues.apache.org/jira/browse/PHOENIX-4278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16357137#comment-16357137
]
ASF GitHub Bot commented on PHOENIX-4278:
-----------------------------------------
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/291#discussion_r166985377
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
---
@@ -850,19 +849,12 @@ private void addCoprocessors(byte[] tableName,
HTableDescriptor descriptor, PTab
&& !SchemaUtil.isMetaTable(tableName)
&& !SchemaUtil.isStatsTable(tableName)) {
if (isTransactional) {
- if
(!descriptor.hasCoprocessor(PhoenixTransactionalIndexer.class.getName())) {
-
descriptor.addCoprocessor(PhoenixTransactionalIndexer.class.getName(), null,
priority, null);
- }
--- End diff --
The coprocessor is already installed on existing tables. Removing the
addCoprocessor only impacts a new table being created. Eventually, we could
have some code that runs at upgrade time which removes the coprocessor from
existing tables, but we could only do this after we know all clients have been
upgraded.
If we want to handle the old client, new server situation, it's slightly
more complicated (but not too bad). We have an optimization that conditionally
performs an RPC before the batch mutation which contains all the index metadata
information (if there are more than a threshold number of mutations being
batched). This information is then cached on the RS and looked up by the UUID
we store on the Put. That's to prevent having to put information on *every*
single mutation. So we'd have to add this attribute to the ServerCache or
conditionally add the attribute to the mutation (depending on if we're doing
the extra RPC or not).
> Implement pure client side transactional index maintenance
> ----------------------------------------------------------
>
> Key: PHOENIX-4278
> URL: https://issues.apache.org/jira/browse/PHOENIX-4278
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Ohad Shacham
> Priority: Major
> Attachments: PHOENIX-4278.4.x-HBase-1.3.v1.patch
>
>
> The index maintenance for transactions follows the same model as non
> transactional tables - coprocessor based on data table updates that looks up
> previous row value to perform maintenance. This is necessary for non
> transactional tables to ensure the rows are locked so that a consistent view
> may be obtained. However, for transactional tables, the time stamp oracle
> ensures uniqueness of time stamps (via transaction IDs) and the filtering
> handles a scan seeing the "true" last committed value for a row. Thus,
> there's no hard dependency to perform this on the server side.
> Moving the index maintenance to the client side would prevent any RS->RS RPC
> calls (which have proved to be troublesome for HBase). It would require
> returning more data to the client (i.e. the prior row value), but this seems
> like a reasonable tradeoff.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
