要获得与亚马逊 Timestream 类似的功能 LiveAnalytics,可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间,以实现实时分析。点击此处了解更多信息。
本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用查询见解响应以优化查询
假设你正在使用 Amazon Timestream LiveAnalytics 来监控不同地点的能耗。假设您的数据库中有两个表,名为 raw-metrics 和 aggregate-metrics。
raw-metrics 表存储设备级别的详细能耗数据,包含以下列:
-
Timestamp
-
州,例如,华盛顿州
-
设备 ID
-
能源消耗
该表的数据是按 minute-by-minute粒度收集和存储的。该表将 State 用作 CDPK。
aggregate-metrics 表存储计划查询的结果,每小时汇总一次所有设备的能耗数据。此表包含以下列:
-
Timestamp
-
州,例如,华盛顿州
-
总能耗量
aggregate-metrics 表以小时为单位存储这些数据。该表将 State 用作 CDPK。
查询过去 24 小时的能耗情况
假设您想提取华盛顿过去 24 小时内的总能耗量。要查找这些数据,您可以同时利用以下两个表的优势:raw-metrics 和 aggregate-metrics。aggregate-metrics表 提供过去 23 小时的每小时能耗数据,而 raw-metrics 表提供过去 1 小时的每分钟数据。通过对这两个表进行查询,您可以完整且准确地了解华盛顿过去 24 小时内的能耗情况。
SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE rm.time >= ago(1h) and rm.time < now()
此示例查询仅用于说明目的,可能无法直接使用。该示例旨在演示概念,但您可能需要根据具体使用案例或环境进行修改。
执行此查询后,您可能会发现查询响应时间比预期更慢。要确定此性能问题的根本原因,您可以使用查询见解功能,以分析查询的性能并优化其执行过程。
以下示例显示查询见解响应。
queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 1.0, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/raw-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value:31540000000000000 //365 days, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590
查询见解响应提供以下信息:
-
时间范围:查询针对
aggregate-metrics表实施扫描的时间范围超出 365 天。这表明时间筛选条件的使用效率低下。 -
空间覆盖:查询扫描
raw-metrics表的整个空间范围(100%)。这表明空间筛选条件并未得到有效利用。
如果您的查询访问多个表,则查询见解会针对访问模式最差的表提供指标。
针对时间范围优化查询
根据查询见解响应,您可以优化查询的时间范围,如下例所示。
SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE am.time >= ago(23h) and am.time < now() AND rm.time >= ago(1h) and rm.time < now() AND rm.state = 'Washington'
如果再次运行 QueryInsights 命令,该命令会返回以下响应。
queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 1.0, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value: 82800000000000 //23 hours, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590
此响应显示 aggregate-metrics 表的空间覆盖仍为 100%,效率低下。以下部分介绍如何优化查询的空间覆盖。
优化查询的空间覆盖
根据查询见解响应,您可以优化查询的空间覆盖,如下例所示。
SELECT am.time, am.state, am.total_energy_consumption, rm.time, rm.state, rm.device_id, rm.energy_consumption FROM "metrics"."aggregate-metrics" am LEFT JOIN "metrics"."raw-metrics" rm ON am.state = rm.state WHERE am.time >= ago(23h) and am.time < now() AND am.state ='Washington' AND rm.time >= ago(1h) and rm.time < now() AND rm.state = 'Washington'
如果再次运行 QueryInsights 命令,该命令会返回以下响应。
queryInsightsResponse={ QuerySpatialCoverage: { Max: { Value: 0.02, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics, PartitionKey: [State] } }, QueryTemporalRange: { Max: { Value: 82800000000000 //23 hours, TableArn: arn:aws:timestream:us-east-1:123456789012:database/metrics/table/aggregate-metrics } }, QueryTableCount: 2, OutputRows: 83, OutputBytes: 590
提高查询性能
优化查询后,查询见解会提供以下信息:
-
aggregate-metrics表的时间修剪为 23 小时。这表示仅扫描时间范围内的 23 小时。 -
aggregate-metrics表的空间修剪为 0.02。这表明仅扫描该表空间范围内 2% 的数据。该查询仅扫描表中极小部分数据,从而实现快速性能并降低资源利用率。修剪效率的提高表明查询现在已针对性能进行优化。