要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间，以实现实时分析。点击[此处](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)了解更多信息。

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

# 使用查询见解优化 Amazon Timestream 中的查询
<a name="using-query-insights"></a>

查询见解是一项性能调优功能，可帮助优化查询、提升查询性能并降低成本。借助查询见解，您可以评测查询在时间、基于时间和空间分区键的修剪效率。使用查询见解，您还可以确定需要改进的领域，从而提升查询性能。此外，借助查询见解，您可以评估查询在利用时间基准索引和分区键索引优化数据检索方面的有效性。如需优化查询性能，必须对控制查询执行的时间和空间参数进行微调。

**Topics**
+ [查询见解的优势](#query-insights-benefits)
+ [优化 Amazon Timestream 中的数据访问](query-insights-optimize-data-access-pattern.md)
+ [在 Amazon Timestream 中启用查询见解](enable-query-insights.md)
+ [使用查询见解响应以优化查询](optimize-query-using-query-insights.md)

## 查询见解的优势
<a name="query-insights-benefits"></a>

使用查询见解具有以下主要优势：
+ **识别效率低下的查询**：查询见解提供有关对查询所访问表进行基于时间和基于属性的修剪的信息。这些信息有助于您识别访问效率不佳的表。
+ **优化数据模型和分区**：您可以使用查询见解信息访问和微调数据模型和分区策略。
+ **调优查询**：查询见解突出显示如何更有效地使用索引。

# 优化 Amazon Timestream 中的数据访问
<a name="query-insights-optimize-data-access-pattern"></a>

您可以使用 Timestream 分区方案或数据组织技术优化 Amazon Timestream 中的数据访问模式。

**Topics**
+ [Timestream 分区架构](#query-insights-optimize-data-access-partitioning-scheme)
+ [数据整理](#query-insights-optimize-data-access-data-org)

## Timestream 分区架构
<a name="query-insights-optimize-data-access-partitioning-scheme"></a>

Amazon Timestream 使用高度可扩展的分区架构，其中每个 Timestream 表可包含数百、数千甚至数百万个独立分区。高度可用的分区跟踪和索引服务可以管理分区，最大限度地减少故障的影响，并增强系统的弹性。

![\[Timestream 分区架构\]](http://docs.aws.amazon.com/zh_cn/timestream/latest/developerguide/images/QueryInsights/ts-partitioning-scheme.png)


## 数据整理
<a name="query-insights-optimize-data-access-data-org"></a>

Timestream 将摄取的每个数据点存储在单个分区中。将数据摄取到 Timestream 表时，Timestream 会根据数据中的时间戳、分区键及其他上下文属性自动创建分区。除按时间对数据进行分区（时间分区）以外，Timestream 还会根据选定的分区键和其他维度（空间分区）对数据进行分区。此方法旨在分发写入流量，并实现对查询数据的有效修剪。

查询见解功能为查询的修剪效率提供宝贵的见解，其中包括查询空间覆盖率和查询时间覆盖率。

**Topics**
+ [QuerySpatialCoverage](#query-insights-data-org-query-spatial-cvg)
+ [QueryTemporalCoverage](#query-insights-data-org-query-temporal-cvg)

### QuerySpatialCoverage
<a name="query-insights-data-org-query-spatial-cvg"></a>

该[QuerySpatialCoverage](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_QuerySpatialCoverage.html)指标提供了对已执行查询的空间覆盖范围的见解，以及空间修剪效率最低的表。这些信息可帮助识别分区策略中需要改进的领域，从而增强空间剪枝效果。`QuerySpatialCoverage` 指标的值介于 0 和 1 之间。指标的值越低，空间轴上的查询修剪效果就越理想。例如，值为 0.1 表示查询扫描 10% 的空间轴。值为 1 表示查询扫描 100% 的空间轴。

**Example 使用查询见解分析查询的空间覆盖范围**  
假设您具有存储天气数据的 Timestream 数据库。假设美国不同州的气象站每小时记录一次温度。假设您选择 `State` 作为[客户定义的分区键](customer-defined-partition-keys.md)（CDPK），用于按州对数据进行分区。  
假设您执行查询，以检索加利福尼亚州所有气象站在特定日期下午 2 点至下午 4 点之间的平均温度。以下示例显示用于此场景的查询。  

```
SELECT AVG(temperature) 
FROM "weather_data"."hourly_weather"
WHERE time >= '2024-10-01 14:00:00' AND time < '2024-10-01 16:00:00' 
  AND state = 'CA';
```
使用查询见解功能，您可以分析查询的空间覆盖范围。假设 `QuerySpatialCoverage` 指标返回的值为 0.02。这表示查询仅扫描 2% 的空间轴，效率较高。在此情况下，该查询能够有效地缩减空间范围，仅检索加利福尼亚州的数据，而忽略其他州的数据。  
相反，如果 `QuerySpatialCoverage` 指标返回的值为 0.8，则表示查询扫描 80% 的空间轴，效率较低。这可能表明需要改进分区策略以优化空间修剪。例如，您可以选择将城市或区域作为分区键，而不是州作为分区键。通过分析 `QuerySpatialCoverage` 指标，您可以发现优化分区策略和提升查询性能的机会。

下图显示空间修剪效果不佳的情况。

![\[QuerySpatialCoverage 指标提供的结果显示空间修剪效果不佳。\]](http://docs.aws.amazon.com/zh_cn/timestream/latest/developerguide/images/QueryInsights/QuerySpatialCoverageMetricResult.png)


要提高空间修剪效率，可执行以下一项或两项操作：
+ 在查询中添加 `measure_name`、默认分区密钥或使用 CDPK 谓词。
+ 如果您已添加上文所述的属性，请移除这些属性或子句周围的函数，例如 `LIKE`。

### QueryTemporalCoverage
<a name="query-insights-data-org-query-temporal-cvg"></a>

`QueryTemporalCoverage` 指标提供对已执行查询所扫描时间范围的见解，包括扫描时间范围最大的表。`QueryTemporalCoverage` 指标的值表示以纳秒为单位的时间范围。该指标的值越低，时间范围上的查询修剪就越理想。例如，扫描表中最近几分钟数据的查询比扫描整个时间范围的查询性能更高。

**Example**  
假设您具备 Timestream 数据库，用于存储 IoT 传感器数据，该数据库每分钟采集一次位于制造工厂的设备测量值。假设您已按 `device_ID` 对数据进行分区。  
假设您执行查询，以检索过去 30 分钟内特定设备的平均传感器读数。以下示例显示用于此场景的查询。  

```
SELECT AVG(sensor_reading) 
FROM "sensor_data"."factory_1"
WHERE device_id = 'DEV_123' 
  AND time >= NOW() - INTERVAL 30 MINUTE and time < NOW();
```
使用查询见解功能，您可以分析查询所扫描的时间范围。假设 `QueryTemporalCoverage` 指标返回的值为 1800000000000 纳秒（30 分钟）。这意味着该查询仅扫描过去 30 分钟的数据，这是相对狭窄的时间范围。这是个好兆头，说明查询能够有效地修剪时间分区，仅检索请求的数据。  
相反，如果 `QueryTemporalCoverage` 指标返回的值为 1 年（以纳秒为单位），这表示查询扫描表中一年的时间范围，效率较低。这可能表明该查询未针对时间修剪进行优化，可通过添加时间筛选器以改进查询。

下图显示时间修剪效果不佳的情况。

![\[QueryTemporalCoverage 指标提供的结果显示时间修剪效果不佳。\]](http://docs.aws.amazon.com/zh_cn/timestream/latest/developerguide/images/QueryInsights/QueryTemporalCoverageMetricResult.png)


要改进时间修剪效果，建议您执行以下一项或全部操作：
+ 在查询中添加缺失的时间谓词，并确保这些时间谓词能够对所需时间窗口进行修剪。
+ 移除时间谓词周围的函数，例如 `MAX()`。
+ 向所有子查询添加时间谓词。如果子查询涉及连接大型表或执行复杂操作，这一点就显得尤为重要。

# 在 Amazon Timestream 中启用查询见解
<a name="enable-query-insights"></a>

您可以为查询启用查询见解，相关见解将直接通过查询响应提供。启用查询见解无需额外基础设施，也不会产生任何额外费用。启用查询见解后，查询响应中除返回查询结果外，还会返回与查询性能相关的元数据字段。您可以利用这些信息优化查询，从而提升查询性能并降低查询成本。

有关启用查询见解的信息，请参阅[运行查询](console_timestream.md#console_timestream.queries.using-console)。

要查看启用查询见解后返回的响应示例，请参阅[计划查询示例](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_ExecuteScheduledQuery.html#API_query_ExecuteScheduledQuery_Examples)。

**注意**  
启用查询见解后，会将查询速率限制为每秒 1 次查询（QPS）。为避免影响性能，强烈建议您仅在查询的评估阶段启用查询见解，切勿在将查询部署到生产环境前启用该功能。
查询见解中提供的信息具有最终一致性，这表示随着新数据持续被摄取到表中，这些信息可能会发生变化。

# 使用查询见解响应以优化查询
<a name="optimize-query-using-query-insights"></a>

假设你正在使用 Amazon Timestream LiveAnalytics 来监控不同地点的能耗。假设您的数据库中有两个表，名为 `raw-metrics` 和 `aggregate-metrics`。

`raw-metrics` 表存储设备级别的详细能耗数据，包含以下列：
+ Timestamp
+ 州，例如，华盛顿州
+ 设备 ID
+ 能源消耗

该表的数据是按 minute-by-minute粒度收集和存储的。该表将 `State` 用作 CDPK。

`aggregate-metrics` 表存储计划查询的结果，每小时汇总一次所有设备的能耗数据。此表包含以下列：
+ Timestamp
+ 州，例如，华盛顿州
+ 总能耗量

`aggregate-metrics` 表以小时为单位存储这些数据。该表将 `State` 用作 CDPK。

**Topics**
+ [查询过去 24 小时的能耗情况](#query-energy-consumption-data)
+ [针对时间范围优化查询](#optimize-query-temporal-range)
+ [优化查询的空间覆盖](#optimize-query-spatial-coverage)
+ [提高查询性能](#improved-query-performance)

## 查询过去 24 小时的能耗情况
<a name="query-energy-consumption-data"></a>

假设您想提取华盛顿过去 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%）。这表明空间筛选条件并未得到有效利用。

如果您的查询访问多个表，则查询见解会针对访问模式最差的表提供指标。

## 针对时间范围优化查询
<a name="optimize-query-temporal-range"></a>

根据查询见解响应，您可以优化查询的时间范围，如下例所示。

```
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%，效率低下。以下部分介绍如何优化查询的空间覆盖。

## 优化查询的空间覆盖
<a name="optimize-query-spatial-coverage"></a>

根据查询见解响应，您可以优化查询的空间覆盖，如下例所示。

```
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
```

## 提高查询性能
<a name="improved-query-performance"></a>

优化查询后，查询见解会提供以下信息：
+ `aggregate-metrics` 表的时间修剪为 23 小时。这表示仅扫描时间范围内的 23 小时。
+ `aggregate-metrics` 表的空间修剪为 0.02。这表明仅扫描该表空间范围内 2% 的数据。该查询仅扫描表中极小部分数据，从而实现快速性能并降低资源利用率。修剪效率的提高表明查询现在已针对性能进行优化。