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

[jira] [Resolved] (PHOENIX-6150) Repair ahead global indexes after concurrent mutations

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

Kadir OZDEMIR resolved PHOENIX-6150.
------------------------------------
    Resolution: Not A Problem

> Repair ahead global indexes after concurrent mutations
> ------------------------------------------------------
>
>                 Key: PHOENIX-6150
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6150
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Kadir OZDEMIR
>            Priority: Major
>
> Concurrent mutations processed by the IndexRegionObserver coproc leave (mutable global) index rows in the unverified state and these unverified rows are repaired by the GlobalIndexChecker coproc when they are read (i.e., scanned).  However, we do not have to wait for the scan operations to repair these unverified rows. IndexRegionObserver can repair them asynchronously soon after they written. There are two main reasons for proactively repairing index rows. 
> Efficient Repair: Repairing index rows within IndexRegionObserver eliminates RPCs to read data table rows as IndexRegionObserver will read data table rows locally. 
> Faster Scans:  Read repair by GlobalIndexChecker is done one index row at a time and each repair can take several tens of milliseconds. This adds additional latency on the scan operations. Reducing the number of such read repairs will improve scan performance.  
> This repair ahead can be optional and configurable.  We can also have metrics to monitor the number of index rows repaired ahead.



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