phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4051) Prevent out-of-order updates for mutable index updates
Date Fri, 28 Jul 2017 01:43:00 GMT

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

James Taylor commented on PHOENIX-4051:
---------------------------------------

I think this patch prevents out-of-order mutations for a few reasons:
# For DELETE and UPSERT SELECT, when the statement is compiled, Phoenix uses the time stamp
it got back from the server when it checks that it has the latest metadata as the time stamp
for the mutations that the statement generates. 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. However, this could make it to the RS in a different order. This patch
is essentially ignoring the timestamp from the client and setting it on the RS instead.
# On the HBase side (and my knowledge is sketchy here), it seems like the code you indicated
will cause a region wide lock to be in place while the preBatchMutate call is made:
{code}
lock(this.updatesLock.readLock(), numReadyToWrite);
      locked = true;
{code}
By setting the time stamp here (really the first point we can set it), I don't think the rows
will change. I'm not sure what kind of row lock is gotten in 0.98, but it looks like only
a read lock is gotten in 1.3. Does that mean that the row can be modified with this lock in
place? 

It's seems that (1) is the biggest factor. Either way, it feels like a workaround to me. The
indexing code should generate the correct mutations when they're out of order. I've filed
PHOENIX-4052 for that.


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

Mime
View raw message