Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# クエリインサイトレスポンスを使用したクエリの最適化
<a name="optimize-query-using-query-insights"></a>

Amazon Timestream for LiveAnalytics を使用して、さまざまな場所のエネルギー消費をモニタリングしているとします。`raw-metrics` と `aggregate-metrics` という名前のデータベースに 2 つのテーブルがあるとします。

この `raw-metrics` テーブルには、詳細なエネルギーデータがデバイスレベルで保存され、次の列が含まれます。
+ タイムスタンプ
+ 州 (例: ワシントン)
+ デバイス ID
+ エネルギー消費量

このテーブルのデータは、分単位の粒度で収集され、保存されます。テーブルは `State` を CDPK として使用します。

この `aggregate-metrics` テーブルには、スケジュールされたクエリの結果が保存され、すべてのデバイスのエネルギー消費データを毎時集計します。このテーブルには次の列が含まれます。
+ タイムスタンプ
+ 州 (例: ワシントン)
+ 合計エネルギー消費量

この `aggregate-metrics` テーブルには、このデータが 1 時間単位の粒度で保存されます。テーブルは `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% のみがスキャンされていることを示します。クエリはテーブルのごく一部をスキャンするため、高速なパフォーマンスとリソース使用率の減少につながります。プルーニング効率が向上したことは、クエリのパフォーマンスが最適化されるようになったことを示します。