Amazon Timestream for LiveAnalytics와 유사한 기능을 원하는 경우 Amazon Timestream for InfluxDB를 고려해 보세요. 간소화된 데이터 수집과 실시간 분석을 위한 10밀리초 미만의 쿼리 응답 시간을 제공합니다. [여기](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)에서 자세히 알아보세요.

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 사용자 지정 복합 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증
<a name="customer-defined-partition-keys-schema-validation"></a>

Timestream for LiveAnalytics의 스키마 검증은 데이터베이스로 수집된 데이터가 지정된 스키마를 준수하는지 확인하여 수집 오류를 최소화하고 데이터 품질을 향상시키는 데 도움이 됩니다. 쿼리 성능 최적화를 목표로 고객 정의 파티션 키를 채택할 때 스키마 검증이 특히 유용합니다.

## 고객 정의 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증이란 무엇인가요?
<a name="customer-defined-partition-keys-schema-validation-what-is"></a>

Timestream for LiveAnalytics 스키마 검증은 사전 정의된 스키마를 기반으로 Timestream for LiveAnalytics 테이블로 수집되는 데이터를 검증하는 기능입니다. 이 스키마는 삽입되는 레코드의 파티션 키, 데이터 유형 및 제약 조건을 포함한 데이터 모델을 정의합니다.

고객 정의 파티션 키를 사용하는 경우 스키마 검증이 더욱 중요해집니다. 파티션 키를 사용하면 Timestream for LiveAnalytics에 데이터가 저장되는 방식을 결정하는 파티션 키를 지정할 수 있습니다. 사용자 지정 파티션 키를 사용하여 수신 데이터를 스키마에 대해 검증하면 데이터 일관성을 유지하고 오류를 조기에 탐지하고 Timestream for LiveAnalytics에 저장된 데이터의 전반적인 품질을 향상시킬 수 있습니다.

## 사용자 지정 복합 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증을 사용하는 방법
<a name="customer-defined-partition-keys-schema-validation-using"></a>

사용자 지정 복합 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증을 사용하려면 다음 단계를 따르세요.

**쿼리 패턴이 어떻게 될지 생각하기: **Timestream for LiveAnalytics 테이블의 스키마를 적절하게 선택하고 정의하려면 먼저 쿼리 요구 사항부터 파악해야 합니다.

**사용자 지정 복합 파티션 키 지정: **테이블을 생성할 때 사용자 지정 파티션 키를 지정합니다. 이 키는 테이블 데이터를 파티셔닝하는 데 사용될 속성을 결정합니다. 파티셔닝을 위해 차원 키와 측정 키 중에서 선택할 수 있습니다. 차원 키는 차원 이름을 기준으로 데이터를 파티셔닝하는 반면, 측정 키는 측정 이름을 기준으로 데이터를 파티셔닝합니다.

**적용 수준 설정: **적절한 데이터 파티셔닝과 그에 따른 이점을 보장하기 위해 Amazon Timestream for LiveAnalytics는 스키마의 각 파티션 키에 대한 적용 수준을 설정할 수 있도록 지원합니다. 적용 수준에 따라 레코드를 수집할 때 파티션 키 차원이 필수인지 선택 사항인지가 결정됩니다. 두 가지 옵션 중에서 선택할 수 있습니다. `REQUIRED`는 파티션 키가 수집된 레코드에 반드시 존재해야 함을 의미하며, `OPTIONAL`은 파티션 키가 존재하지 않아도 됨을 의미합니다. 고객 정의 파티션을 사용할 때는 데이터가 올바르게 파티셔닝되고 이 기능의 모든 이점을 누릴 수 있도록 `REQUIRED` 적용 수준을 사용하는 것이 좋습니다. 또한 스키마 생성 후 언제든지 적용 수준 구성을 변경하여 데이터 수집 요구 사항에 맞게 조정할 수 있습니다.

**데이터 수집: **Timestream for LiveAnalytics 테이블에 데이터를 수집할 때 스키마 검증 프로세스는 사용자 지정 복합 파티션 키를 사용하여 정의된 스키마에 대해 레코드를 검사합니다. 레코드가 스키마를 준수하지 않으면 Timestream for LiveAnalytics에서 검증 오류를 반환합니다.

**검증 오류 처리:** 검증 오류가 발생하면 Timestream for LiveAnalytics에서 오류 유형에 따라 `RejectedRecordsException` 또는 `ValidationException`을 반환합니다. 이러한 예외를 애플리케이션에서 처리하고, 잘못된 레코드를 수정하거나 수집을 재시도하는 등 적절한 조치를 취해야 합니다.

**적용 수준 업데이트: **필요한 경우 `UpdateTable` 작업을 사용하여 테이블 생성 후 파티션 키의 적용 수준을 업데이트할 수 있습니다. 그러나 테이블 생성 후에는 이름이나 유형과 같은 파티션 키 구성의 일부 측면은 변경할 수 없다는 점을 유의해야 합니다. 적용 수준을 `REQUIRED`에서 `OPTIONAL`로 변경하면 고객 정의 파티션 키로 선택한 속성의 존재 여부와 관계없이 모든 레코드가 수락됩니다. 반대로, 적용 수준을 `OPTIONAL`에서 `REQUIRED`로 변경하면 이 조건을 충족하지 않는 레코드에 대해 4xx 쓰기 오류가 발생할 수 있습니다. 따라서 테이블 생성 시 데이터의 파티셔닝 요구 사항에 따라 사용 사례에 적합한 적용 수준을 선택하는 것이 중요합니다.

## 사용자 지정 복합 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증을 사용해야 하는 경우
<a name="customer-defined-partition-keys-schema-validation-when-to-use"></a>

사용자 지정 복합 파티션 키를 사용한 Timestream for LiveAnalytics 스키마 검증은 데이터 일관성, 품질 및 최적화된 파티셔닝이 중요한 시나리오에서 사용해야 합니다. 데이터 수집 중 스키마를 적용하여 잘못된 분석이나 가치 있는 인사이트의 손실로 이어질 수 있는 오류와 불일치를 방지할 수 있습니다.

## 배치 로드 작업과의 상호 작용
<a name="customer-defined-partition-keys-schema-validation-when-to-use-batch-load"></a>

고객 정의 파티션 키가 있는 테이블로 데이터를 가져오도록 배치 로드 작업을 설정할 때 프로세스에 영향을 미칠 수 있는 몇 가지 시나리오가 있습니다.

1. 적용 수준이 `OPTIONAL`로 설정되면 작업 구성 시 파티션 키가 매핑되지 않은 경우 생성 흐름 중 콘솔에 알림이 표시됩니다. API 또는 CLI를 사용할 때는 이 알림이 표시되지 않습니다.

1. 적용 수준이 `REQUIRED`로 설정되어 있는 경우 파티션 키가 소스 데이터 열에 매핑되지 않으면 작업 생성이 거부됩니다.

1. 작업이 생성된 후 적용 수준이 `REQUIRED`로 변경되면 작업은 계속 실행되지만 파티션 키에 대한 적절한 매핑이 없는 레코드는 4xx 오류와 함께 거부됩니다.

## 예약된 쿼리와의 상호 작용
<a name="customer-defined-partition-keys-schema-validation-when-to-use-scheduled-query"></a>

집계, 롤업 및 기타 형태의 사전 처리된 데이터를 계산하여 고객 정의 파티션 키가 있는 테이블에 저장하기 위해 예약된 쿼리 작업을 설정할 때 프로세스에 영향을 줄 수 있는 몇 가지 시나리오가 있습니다.

1. 적용 수준이 `OPTIONAL`로 설정되면 작업 구성 시 파티션 키가 매핑되지 않은 경우 알림이 표시됩니다. API 또는 CLI를 사용할 때는 이 알림이 표시되지 않습니다.

1. 적용 수준이 `REQUIRED`로 설정되어 있는 경우 파티션 키가 소스 데이터 열에 매핑되지 않으면 작업 생성이 거부됩니다.

1. 작업이 생성된 후 적용 수준이 `REQUIRED`로 변경되고 예약된 쿼리 결과에 파티션 키 차원이 포함되지 않으면 해당 작업의 모든 후속 반복이 실패합니다.