phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4278) Implement pure client side transactional index maintenance
Date Thu, 08 Feb 2018 16:14:00 GMT

    [ 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)

Mime
View raw message