Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Fri, 28 Jul 2017 04:53:00 +0000 (UTC)
From: "Samarth Jain (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13090645.1501196949000.33739.1501217580160@Atlassian.JIRA>
In-Reply-To: <JIRA.13090645.1501196949000@Atlassian.JIRA>
References: <JIRA.13090645.1501196949000@Atlassian.JIRA> <JIRA.13090645.1501196949030@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4051) Prevent out-of-order updates for
 mutable index updates
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 28 Jul 2017 04:53:10 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16104454#comment-16104454 ] 

Samarth Jain commented on PHOENIX-4051:
---------------------------------------

bq. For an UPSERT VALUES, the timestamp is gotten from the server at commit time. This is done so that the timestamp is consistent across all rows being written.

I don't think this actually happens in practice. In doMiniBatchMutation HBase tries to acquire as many locks as it can. For the mutations in the batch for which it is able to acquire row locks, it sets the same timestamp. For the ones it is not able to, it comes back and tries to acquire locks again in which case the timestamp ends up being different from the first attempt. This happens more often when there are concurrent updates to the same rows.

> Prevent out-of-order updates for mutable index updates
> ------------------------------------------------------
>
>                 Key: PHOENIX-4051
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4051
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>         Attachments: PHOENIX-4051_v1.patch
>
>
> Out-of-order processing of data rows during index maintenance causes mutable indexes to become out of sync with regard to the data table. Here's a simple example to illustrate the issue:
> # Assume table T(K,V) and index X(V,K).
> # Upsert T(A, 1) at t10. Index updates: Put X(1,A) at t10.
> # Upsert T(A, 3) at t30. Index updates: Delete X(1,A) at t29, Put X(3,A) at t30.
> # Upsert T(A,2) at t20. Index updates: Delete X(1,A) at t19, Put X(2,A) at t20, Delete X(2,A) at t29
> Ideally, we'd want to remove the Delete X(1,A) at t29 since this isn't correct in terms of timeline consistency, but we can't do that with HBase without support for deleting/undoing Delete markers. 
> The above is not what is occurring. Instead, when T(A,2) comes in, the Put X(2,A) will occur at t20, but the Delete won't occur. This causes more index rows than data rows, essentially making it invalid.
> A quick fix is to reset the timestamp of the data table mutations to the current time within the preBatchMutate call, when the row is exclusively locked. This skirts the issue because then timestamps won't overlap.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)