Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、こちらを参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
クエリインサイトレスポンスを使用したクエリの最適化
Amazon Timestream for LiveAnalytics を使用して、さまざまな場所のエネルギー消費をモニタリングしているとします。raw-metrics と aggregate-metrics という名前のデータベースに 2 つのテーブルがあるとします。
この raw-metrics テーブルには、詳細なエネルギーデータがデバイスレベルで保存され、次の列が含まれます。
-
タイムスタンプ
-
州 (例: ワシントン)
-
デバイス ID
-
エネルギー消費量
このテーブルのデータは、分単位の粒度で収集され、保存されます。テーブルは State を CDPK として使用します。
この aggregate-metrics テーブルには、スケジュールされたクエリの結果が保存され、すべてのデバイスのエネルギー消費データを毎時集計します。このテーブルには次の列が含まれます。
-
タイムスタンプ
-
州 (例: ワシントン)
-
合計エネルギー消費量
この aggregate-metrics テーブルには、このデータが 1 時間単位の粒度で保存されます。テーブルは State を CDPK として使用します。
過去 24 時間のエネルギー消費量のクエリ
過去 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%) をスキャンしました。これは、空間フィルタリングが効果的に活用されていないことを示しています。
クエリが複数のテーブルを利用する場合、クエリインサイトは、最適ではないアクセスパターンのテーブルのメトリクスを提供します。
時間範囲のクエリの最適化
クエリインサイトのレスポンスに基づいて、次の例に示すように、時間範囲のクエリを最適化できます。
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% のみがスキャンされていることを示します。クエリはテーブルのごく一部をスキャンするため、高速なパフォーマンスとリソース使用率の減少につながります。プルーニング効率が向上したことは、クエリのパフォーマンスが最適化されるようになったことを示します。