You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Viraj Jasani (Jira)" <ji...@apache.org> on 2021/01/29 11:54:00 UTC

[jira] [Updated] (PHOENIX-6160) Simplifying concurrent mutation handling for global Indexes

     [ https://issues.apache.org/jira/browse/PHOENIX-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Viraj Jasani updated PHOENIX-6160:
----------------------------------
    Fix Version/s:     (was: 4.x)
                   4.16.0

> Simplifying concurrent mutation handling for global Indexes
> -----------------------------------------------------------
>
>                 Key: PHOENIX-6160
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6160
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Kadir OZDEMIR
>            Assignee: Kadir OZDEMIR
>            Priority: Major
>             Fix For: 5.1.0, 4.16.0
>
>         Attachments: PHOENIX-6160.4.x.001.patch, PHOENIX-6160.4.x.002.patch, PHOENIX-6160.master.001.patch
>
>
> Please see the attached design document for the proposed simplification. The proposed design is simpler to understand and does not require a special handling of partial concurrent updates without indexed columns.
> One of the desired features for global indexes is to support atomic operations (ON_DUPLICATE_KEY statements). We have found that it is quite difficult to build such a feature on the current design as we need to add more case handling to the current design to handle data table update ordering issues. The proposed design does not require us to do changes on concurrent mutation handling for such features.
> The proposed design almost eliminates unverified index rows due to concurrent mutations. The index rows are left unverified only when batches fail to complete the data table updates. This leads to read performance improvement as repairing unverified rows is costly and each row repair adds several tens of milliseconds to the overall scan latency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)