[jira] [Updated] (PHOENIX-4924) Provide strong guarantee for Stats Write to prevent inconsistent and incomplete data issue

["Bin Shi (JIRA)" <ji...@apache.org>]

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

Bin Shi updated PHOENIX-4924:
-----------------------------
    Comment: was deleted

(was: h2. Conclusion:
 # The test result clearly shows that the change doesn't introduce any new performance regression and issues.
 # The test result clearly shows that the pattern of “Periodical query spikes” observed in blocking stats cache (see the design document [Use Asynchronous Refresh to Provide Non-blocking Phoenix Stats Cache|https://salesforce.quip.com/rxokAkVatiQO] for details) is gone.
 # When analyzing the noises in the test result of the Flighting, I suspected that it is because multiple loading stats async tasks are triggered for the same cached entry during the same period. By exploring the code base of Google Guava Cache, I found this negative case won't happen, because Google Guava Cache won't try to reload a cache entry when there is another thread performing the refresh.

h2. Test Result:
h3. Baseline 1st run

!x8q4HN0IRAZ0wAAAABJRU5ErkJggg==!
h3. Flighting 1st RUN

!B8EntiMHCbVvAAAAAElFTkSuQmCC!
h3. Baseline 4th Run

!0HRAABAKBQCCweRHwyX0jwmTzykK0PBAIBFYfgf8PqgsrMqhZgIIAAAAASUVORK5CYII=!
h3. Flighting 4th Run

!j8FfZ 2FQd2ugAAAABJRU5ErkJggg==!
h2.  )

> Provide strong guarantee for Stats Write to prevent inconsistent and incomplete data issue
> ------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4924
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4924
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Bin Shi
>            Assignee: Bin Shi
>            Priority: Major
>
> The Stats could be inconsistent and incomplete due to region servers going down, RPC failures when committing Guidepost data to Stats table and the lack of retry and atomic operation. The expected behavior from the Platform is “We need a strong guarantee that on stats write there are sufficient retries and monitoring in place so that stats writes are resilient such that we will not end up with inconsistent, partial or empty stats until the next run of UPDATE STATISTICS”. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)