[jira] [Commented] (PHOENIX-1261) Update stats table asynchronously

["James Taylor (JIRA)" <ji...@apache.org>]

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

James Taylor commented on PHOENIX-1261:
---------------------------------------

I think the best/easiest way to do this is to by default run the entire UPDATE STATISTICS command asynchronously. To do this, we can:
- have a new SYNC keyword
- change the grammar to tack on an optional [ASYNC | SYNC] to UPDATE STATISTICS
- the default will be ASYNC
- change existing unit tests to specify the SYNC keyword
- in UngroupedAggregateRegionObserver, instead of calculating stats inline, queue the work instead (as determined by new boolean flag). We'd still want to set the timestamp in SYSTEM.STATS to prevent stats from being calculated too frequently. We could just instantiate StatisticsCollector and queue that, as the constructor sets the timestamp.
- just return a row count of zero when running asynchronously.

This will prevent the client from having to create a new connection with a larger RPC timeout.

WDYT, [~samarthjain]?

> Update stats table asynchronously
> ---------------------------------
>
>                 Key: PHOENIX-1261
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1261
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Samarth Jain
>             Fix For: 4.7.0
>
>
> Instead of writing the the stats table directly in the thread performing major compaction, we should instead write to it asynchronously, perhaps using the same asynchronous mechanism used by tracing. Apparently HBase used to have a "custodian" table where they'd write as compaction and other background tasks were running, and this leads to bad things happening if the table being written to can't be reached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)