[
https://issues.apache.org/jira/browse/PHOENIX-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143445#comment-14143445
]
James Taylor commented on PHOENIX-1270:
---------------------------------------
Thanks for the patch, [~daniel.M]. I like the idea, but my preference would be
to declare this on the table (as a property at DDL time). We could also support
changing the property value through ALTER TABLE. One caveat is that in most
cases we need to do the RPC anyway to get the server time which we use as the
max upper time range on scans so that we don't see new data as a query is
running. This system time is gotten from the same RPC that checks if the
metadata is in sync. Are you seeing this RPC show up as a pretty high overhead
in your perf analysis?
One other thought I had: when we start supporting transactions, we'll need an
RPC (though not an HBase RPC, so the cost will be lower) at the start of a
transaction to get the timestamp. This will replace the RPC I mention above to
get the system time. At this point, it'd be a good time to fold this feature in
as well, because then we'd definitely be saving the RPC to check whether or not
the metadata is in sync in this case.
Thoughts?
> Avoid retrieve metadata from server to gain performance
> -------------------------------------------------------
>
> Key: PHOENIX-1270
> URL: https://issues.apache.org/jira/browse/PHOENIX-1270
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: daniel meng
> Attachments: PHOENIX-1270.patch
>
>
> Now the SELECT or UPSERT(when autoCommit is TRUE) will need one extra RPC for
> retrieve metadata from RS. In some cases where metadata rarely changed and
> higher TPS is required, we should let the client have a choice to use cache
> directly for better performance. the attached patch do two :
> 1. enable metadata cache self refresh (switch by "phoenix.cache.autoRefresh")
> 2. client can use hint /\*+ALWAYS_USE_META_CACHE\*/ to force compiler to use
> cache frist
> thanks in advance for your advice
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
