Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](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/ja_jp/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 データベースがあるとします。米国のさまざまな州にある気象観測所から気温が毎時記録されると想定します。[ユーザー定義のパーティショニングキー](customer-defined-partition-keys.md) (CDPK) として `State` を選択し、州ごとにデータをパーティション化するとします。  
クエリを実行して、特定の日の午後 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/ja_jp/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 年の値をナノ秒単位で返した場合、クエリがテーブル内の 1 年間の時間範囲をスキャンしたことを示しており、効率は低くなります。この場合、クエリが時間プルーニング用に最適化されていないことを示唆しており、時間フィルターを追加することでクエリを改善できる可能性があります。

次の画像は、時間プルーニングが不十分なことを示しています。

![\[時間プルーニングが不十分なことを示す QueryTemporalCoverage メトリクスによって提供される結果。\]](http://docs.aws.amazon.com/ja_jp/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` という名前のデータベースに 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% のみがスキャンされていることを示します。クエリはテーブルのごく一部をスキャンするため、高速なパフォーマンスとリソース使用率の減少につながります。プルーニング効率が向上したことは、クエリのパフォーマンスが最適化されるようになったことを示します。