如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。[在這裡](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**
+ [時間串流分割方案](#query-insights-optimize-data-access-partitioning-scheme)
+ [資料整理](#query-insights-optimize-data-access-data-org)

## 時間串流分割方案
<a name="query-insights-optimize-data-access-partitioning-scheme"></a>

Amazon Timestream 使用高度可擴展的分割方案，其中每個 Timestream 資料表可以有數百個、數千個或甚至數百萬個獨立分割區。高可用性的分割區追蹤和索引服務可管理分割區，將故障的影響降至最低，並讓系統更具彈性。

![\[時間串流分割方案\]](http://docs.aws.amazon.com/zh_tw/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_tw/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**  
假設您有一個存放 IoT 感應器資料的 Timestream 資料庫，每分鐘從位於製造工廠的裝置進行測量。假設您已依 分割資料`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_tw/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 for LiveAnalytics 來監控不同位置的能源消耗。假設您在名為 `raw-metrics`和 的資料庫中有兩個資料表`aggregate-metrics`。

`raw-metrics` 資料表會在裝置層級存放詳細的能源資料，並包含下列資料欄：
+ 時間戳記
+ 狀態，例如 Washington
+ 裝置 ID
+ 能源消耗

此資料表的資料會以minute-by-minute的精細程度收集和儲存。資料表使用 `State`做為 CDPK。

`aggregate-metrics` 資料表會儲存排程查詢的結果，以每小時彙總所有裝置的能源消耗資料。此資料表包含下列資料欄：
+ 時間戳記
+ 狀態，例如 Washington
+ 總能耗

`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%。查詢會掃描極少部分的資料表，進而快速提升效能並降低資源使用率。改善的剔除效率表示查詢現在已針對效能進行最佳化。