使用查询见解响应优化查询 - Amazon Timestream
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

从2025年6月20日起,亚马逊Timestream版 LiveAnalytics 将不再向新客户开放。如果您想使用亚马逊 Timestream LiveAnalytics,请在该日期之前注册。现有客户可以继续照常使用该服务。有关更多信息,请参阅 Amazon Timestream 以了解 LiveAnalytics 可用性变更。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用查询见解响应优化查询

假设你正在使用 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-metricsaggregate-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

查询见解响应提供以下信息:

  • 时间范围:查询扫描的表的时间范围超出了 365 天。aggregate-metrics这表明临时过滤的使用效率低下。

  • 空间覆盖率:查询扫描了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%。该查询只扫描了极小一部分表,从而提高了性能并降低了资源利用率。修剪效率的提高表明查询现在已针对性能进行了优化。