Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. [여기](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` 테이블은 디바이스 수준에서 세부 에너지 데이터를 저장하며 다음 열을 포함합니다.
+ 타임스탬프
+ State(예: Washington)
+ 디바이스 ID
+ 에너지 소비

이 테이블의 데이터는 분 단위로 수집되고 저장됩니다. 테이블은 `State`를 CDPK로 사용합니다.

`aggregate-metrics` 테이블은 예약된 쿼리의 결과를 저장하여 모든 디바이스의 에너지 소비 데이터를 매시간 집계합니다. 이 테이블에는 다음 열이 있습니다.
+ 타임스탬프
+ State(예: 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%만 스캔되고 있음을 나타냅니다. 쿼리는 테이블의 매우 작은 부분을 스캔하여 성능을 높이고 리소스 사용률을 줄입니다. 정리 효율성이 개선되면 쿼리가 이제 성능에 최적화되었음을 나타냅니다.