Kadir Ozdemir created PHOENIX-7379:
--------------------------------------
Summary: Improve handling of concurrent index mutations with the
same timestamp
Key: PHOENIX-7379
URL: https://issues.apache.org/jira/browse/PHOENIX-7379
Project: Phoenix
Issue Type: Improvement
Reporter: Kadir Ozdemir
Assignee: Kadir Ozdemir
IndexRegionObserver after preparing the index updates just before releasing row
locks for a given batch checks if the current millisecond is the same as the
timestamp assigned for this batch. If so, its thread for this batch sleeps for
1 ms so that the next batch of updates does not get the same timestamp. Then,
it releases the row locks.
This is done to prevent having two different mutations with the same timestamp
on the same row since the order of these mutations on the data table and index
cannot be guaranteed to be same. If the order is not the same, then the data
table and index will be inconsistent.
One drawback of this approach is that if the index mutation preparation takes
less than 1 ms, then the data table mutation latency increases by 1 ms. Index
preparation takes more than 1 ms if IndexRegionObserver retrieves the current
state of the data table row from disk. However, if the row is cached in memory,
then the index preparation can easily take less than 1 ms. Also,
IndexRegionObserver does not need to retrieve the current row state for
uncovered indexes usually. For uncovered indexes, this logic almost always adds
1 ms to the mutation latency.
We can improve this by not sleeping proactively instead sleeping only when a
mutation on a row attempts to get the same timestamp of the previous mutation
on the same row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
