기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon Keyspaces의 정적 열에 대한 용량 소비 추정
클러스터링 열이 있는 Amazon Keyspaces 테이블에서 `STATIC` 키워드를 사용하여 정적 열을 생성할 수 있습니다. 정적 열에 저장된 값은 논리적 파티션의 모든 행에서 공유됩니다. 이 열의 값을 업데이트하면 Amazon Keyspaces는 파티션의 모든 행에 변경 사항을 자동으로 적용합니다.
이 섹션에서는 정적 열에 쓸 때 인코딩된 데이터 크기를 계산하는 방법을 설명합니다. 이 프로세스는 행의 비정적 열에 데이터를 쓰는 프로세스와는 별도로 처리됩니다. 정적 데이터에 대한 크기 할당량 외에도 정적 열에 대한 읽기 및 쓰기 작업은 테이블의 측정 및 처리량 용량에도 독립적으로 영향을 미칩니다. 정적 열 및 페이지가 매겨진 범위 읽기 결과를 사용할 때 Apache Cassandra와의 기능적 차이점은 [페이지 매김](functional-differences.md#functional-differences.paging) 섹션을 참조하세요.
**Topics**
+ [Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산](static-columns-estimate.md)
+ [Amazon Keyspaces의 정적 데이터에 대한 읽기/쓰기 작업에 대한 용량 처리량 요구 사항 추정](static-columns-metering.md)
# Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산
이 섹션에서는 Amazon Keyspaces의 인코딩된 정적 열 크기를 추정하는 방법에 대한 세부 정보를 제공합니다. 인코딩된 크기는 요금 및 할당량 사용량을 계산할 때 사용됩니다. 또한 테이블의 프로비저닝된 처리량 용량 요구 사항을 계산할 때는 인코딩된 크기를 사용해야 합니다. Amazon Keyspaces 내에서 인코딩된 정적 열 크기를 계산하려는 경우 다음 지침을 사용할 수 있습니다.
+ 파티션 키는 최대 2048바이트의 데이터를 포함할 수 있습니다. 파티션 키의 각 키 열에는 최대 3바이트의 메타데이터가 필요합니다. 이러한 메타데이터 바이트는 파티션당 1MB의 정적 데이터 크기 할당량에 포함됩니다. 정적 데이터 크기를 계산할 때는 각 파티션 키 열이 전체 3바이트의 메타데이터를 사용한다고 가정해야 합니다.
+ 데이터 유형에 따른 정적 열 데이터 값의 원시 크기를 사용합니다. 데이터 유형에 대한 자세한 내용은 [데이터 타입](cql.elements.md#cql.data-types) 섹션을 참조하세요.
+ 메타데이터의 정적 데이터 크기에 104바이트를 추가합니다.
+ 클러스터링 열과 일반, 기본이 아닌 키 열은 정적 데이터 크기에 포함되지 않습니다. 행 내 비정적 데이터의 크기를 추정하는 방법에 대한 자세한 내용은 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md) 섹션을 참조하세요.
인코딩된 정적 열의 총 크기는 다음 공식을 기반으로 합니다.
```
partition key columns + static columns + metadata = total encoded size of static data
```
모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개 및 정적 열 1개가 있습니다.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
이 예제에서는 다음 문의 정적 데이터 크기를 계산합니다.
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6);
```
이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.
1. 열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 파티션 키 열의 크기를 계산합니다. 모든 파티션 키 열에 대해 이 과정을 반복합니다.
1. 파티션 키(pk\$1col1)의 첫 번째 열 크기를 계산합니다.
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 파티션 키(pk\$1col2)의 두 번째 열 크기를 계산합니다.
```
4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
```
1. 두 열을 모두 더하여 파티션 키 열의 총 예상 크기를 구합니다.
```
7 bytes + 7 bytes = 14 bytes for the partition key columns
```
1. 정적 열의 크기를 더합니다. 이 예제에서는 정수를 저장하는 정적 열이 하나뿐입니다(4바이트 필요).
1. 마지막으로 정적 열 데이터의 인코딩된 총 크기를 구하려면 프라이머리 키 열과 정적 열의 바이트를 더하고 메타데이터에 대해 104바이트를 더 추가합니다.
```
14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.
```
동일한 문을 사용하여 정적 및 비정적 데이터를 업데이트할 수도 있습니다. 쓰기 작업의 총 크기를 추정하려면 먼저 비정적 데이터 업데이트의 크기를 계산해야 합니다. 그런 다음 [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md)의 예제와 같이 행 업데이트 크기를 계산하고 결과를 더합니다.
이 경우 총 2MB를 쓸 수 있습니다. 즉 1MB는 최대 행 크기 할당량이고 1MB는 논리적 파티션당 최대 정적 데이터 크기 할당량입니다.
동일한 문에서 정적 및 비정적 데이터의 총 업데이트 크기를 계산하려면 다음 공식을 사용하면 됩니다.
```
(partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row)
= total encoded size of data written
```
모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개 및 정적 열 1개가 있습니다.
```
CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2));
```
이 예제에서는 다음 문과 같이 테이블에 행을 쓸 때의 데이터 크기를 계산합니다.
```
INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7);
```
이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.
1. 앞에 표시된 대로 정적 데이터의 인코딩된 총 크기를 계산합니다. 이 예제에서는 122바이트입니다.
1. [Amazon Keyspaces에서 행 크기 추정](calculating-row-size.md)의 단계에 따라 비정적 데이터의 업데이트를 기반으로 인코딩된 행의 총 크기를 추가합니다. 이 예제에서 행 업데이트의 총 크기는 134바이트입니다.
```
122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.
```
# Amazon Keyspaces의 정적 데이터에 대한 읽기/쓰기 작업에 대한 용량 처리량 요구 사항 추정
Cassandra에서 정적 데이터는 개별 행이 아니라 논리적 파티션과 연결됩니다. Amazon Keyspaces의 논리적 파티션은 여러 물리적 스토리지 파티션에 걸쳐 있을 수 있으며 사실상 크기에 제한이 없습니다. 결과적으로 Amazon Keyspaces는 정적 데이터와 비정적 데이터에 대한 쓰기 작업을 별도로 측정합니다. 또한 정적 데이터와 비정적 데이터를 모두 포함하는 쓰기에는 데이터 일관성을 제공하기 위한 추가 기본 작업이 필요합니다.
정적 데이터와 비정적 데이터를 혼합하여 쓰기 작업을 수행하는 경우 두 개의 개별 쓰기 작업이 발생합니다. 하나는 비정적 데이터에 대한 것이고 다른 하나는 정적 데이터에 대한 것입니다. 이는 온디맨드 및 프로비저닝된 읽기/쓰기 용량 모드 모두에 적용됩니다.
다음 예제는 정적 열이 있는 Amazon Keyspaces의 테이블에 대해 프로비저닝된 처리량 용량 요구 사항을 계산할 때 필요한 읽기 용량 단위(RCU) 및 쓰기 용량 단위(WCU)를 추정하는 방법에 대한 세부 정보를 제공합니다. 다음 공식을 사용하여 정적 데이터와 비정적 데이터가 모두 포함된 쓰기를 테이블에서 처리하는 데 필요한 용량을 추정할 수 있습니다.
```
2 x WCUs required for nonstatic data + 2 x WCUs required for static data
```
예를 들어 애플리케이션이 초당 27KB의 데이터를 쓰고 각 쓰기에 25.5KB의 비정적 데이터와 1.5KB의 정적 데이터가 포함되는 경우 테이블에는 56WCU(2 x 26WCU \$1 2 x 2WCU)가 필요합니다.
Amazon Keyspaces는 여러 행의 읽기와 동일하게 정적 및 비정적 데이터의 읽기를 측정합니다. 따라서 동일한 작업에서 정적 및 비정적 데이터를 읽는 비용은 읽기를 수행하기 위해 처리된 데이터의 총 크기를 기준으로 합니다.
Amazon CloudWatch로 서버리스 리소스를 모니터링하는 방법을 알아보려면 [Amazon CloudWatch를 사용하여 Amazon Keyspaces 모니터링](monitoring-cloudwatch.md) 섹션을 참조하세요.