ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aravindan Vijayan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-17382) Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
Date Wed, 22 Jun 2016 21:11:16 GMT

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

Aravindan Vijayan updated AMBARI-17382:
---------------------------------------
    Affects Version/s: 2.4.0

> Migrate AMS queries to use ROW_TIMESTAMP instead of native timerange hint
> -------------------------------------------------------------------------
>
>                 Key: AMBARI-17382
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17382
>             Project: Ambari
>          Issue Type: Bug
>    Affects Versions: 2.4.0
>            Reporter: Aravindan Vijayan
>            Assignee: Aravindan Vijayan
>            Priority: Critical
>              Labels: ambari-metrics
>             Fix For: 2.4.0
>
>
> With PHOENIX-914, there is a change in implementation , As earlier, timestamp range was
passed as a hint to the query to get advantage of native timerange optimization in hbase but
with new implementation we can mark the timestamp column in the schema as a ROW_TIMESTAMP
and pass timestamp range with “where” clause only to achieve equivalent performance and
better accuracy.
> For eq:-
> With earlier implementation , AMS forms query like this:-
> SELECT /*+ NATIVE_TIME_RANGE(1448029523000) */ METRIC_NAME, APP_ID, INSTANCE_ID, SERVER_TIME,
UNITS, METRIC_SUM, HOSTS_COUNT, METRIC_MAX, METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME
IN ('regionserver.Server.totalRequestCount', 'regionserver.Server.blockCacheCountHitPercent',
'regionserver.Server.regionCount', 'regionserver.Server.compactionQueueLength', 'regionserver.Server.storeFileCount',
'master.Server.averageLoad')) AND APP_ID = 'ams-hbase' AND SERVER_TIME >= 1448029643000
AND SERVER_TIME < 1448033243 ORDER BY METRIC_NAME, SERVER_TIME LIMIT 11520
> But with PHOENIX-914 :-
> Declare SERVER_TIME as ROW_TIMESTAMP in schema:-
> CREATE TABLE DESTINATION_METRICS_TABLE (SERVER_TIME DATE not null, METRIC_ID  CHAR(15)
not null, METRIC_VALUE bigint … CONSTRAINT PK PRIMARY KEY(CREATED_DATE ROW_TIMESTAMP, METRIC_ID…))
…;
> And remove hint from the query:-
> SELECT  METRIC_NAME, APP_ID, INSTANCE_ID, SERVER_TIME, UNITS, METRIC_SUM, HOSTS_COUNT,
METRIC_MAX, METRIC_MIN FROM METRIC_AGGREGATE WHERE (METRIC_NAME IN ('regionserver.Server.totalRequestCount',
'regionserver.Server.blockCacheCountHitPercent', 'regionserver.Server.regionCount', 'regionserver.Server.compactionQueueLength',
'regionserver.Server.storeFileCount', 'master.Server.averageLoad')) AND APP_ID = 'ams-hbase'
AND SERVER_TIME >= 1448029643000 AND SERVER_TIME < 1448033243 ORDER BY METRIC_NAME,
SERVER_TIME LIMIT 11520
> The plan is to go ahead with support for both the old and the new phoenix native timestamp
support and toggle based on whether the AMS tables were created using ROW_TIMESTAMP or not.



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

Mime
View raw message