Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. [여기](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/ko_kr/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 데이터베이스가 있다고 가정해 보겠습니다. 미국 내 여러 주에 위치한 기상대에서 1시간마다 온도가 기록된다고 가정합니다. [고객 정의 파티셔닝 키](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/ko_kr/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**  
제조 공장에 있는 디바이스에서 1분마다 측정하여 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` 지표가 값으로 1,800,000,000,000나노초(30분)의 값을 반환한다고 가정해 보겠습니다. 즉, 쿼리는 지난 30분 동안의 데이터만 스캔했으며, 이는 상대적으로 좁은 임시 범위입니다. 이는 쿼리가 시간 파티셔닝을 효과적으로 정리할 수 있고 요청된 데이터만 검색했음을 나타내기 때문에 좋은 신호입니다.  
반대로 `QueryTemporalCoverage` 지표가 나노초 단위로 1년 값을 반환한 경우 쿼리가 테이블에서 1년 시간 범위를 스캔했음을 나타내며, 이는 효율성이 떨어집니다. 이는 쿼리가 시간 정리에 최적화되지 않았으며 시간 필터를 추가하여 쿼리를 개선할 수 있음을 시사할 수 있습니다.

다음 이미지는 잘못된 시간 정리를 보여줍니다.

![\[잘못된 시간 정리를 보여주는 QueryTemporalCoverage 지표에서 제공하는 결과입니다.\]](http://docs.aws.amazon.com/ko_kr/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)를 참조하세요.

**참고**  
쿼리 인사이트를 활성화하면 쿼리 속도가 초당 쿼리(QPS) 1개로 제한됩니다. 성능 영향을 방지하려면 쿼리를 프로덕션에 배포하기 전에 쿼리 평가 단계에서만 쿼리 인사이트를 활성화하는 것이 좋습니다.
쿼리 인사이트에 제공된 정보는 최종 일관성을 유지하지만, 새로운 데이터가 테이블로 지속적으로 수집됨에 따라 변경될 수 있습니다.

# 쿼리 인사이트 응답을 사용하여 쿼리 최적화
<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%만 스캔되고 있음을 나타냅니다. 쿼리는 테이블의 매우 작은 부분을 스캔하여 성능을 높이고 리소스 사용률을 줄입니다. 정리 효율성이 개선되면 쿼리가 이제 성능에 최적화되었음을 나타냅니다.