인코딩된 열 크기 추정 데이터 유형을 기반으로 데이터 값의 인코딩 크기 추정 Amazon Keyspaces 기능이 행 크기에 미치는 영향 고려 올바른 공식을 선택하여 행의 인코딩된 크기를 계산합니다.행 크기 계산 예제

Amazon Keyspaces에서 행 크기 추정

Amazon Keyspaces는 한 자릿수 밀리초의 읽기 및 쓰기 성능을 제공하고 여러 AWS 가용 영역에 걸쳐 데이터를 내구성 있게 저장하는 완전 관리형 스토리지를 제공합니다. Amazon Keyspaces는 모든 행과 프라이머리 키 열에 메타데이터를 연결하여 효율적인 데이터 액세스와 고가용성을 지원합니다.

이 주제에서는 Amazon Keyspaces에서 인코딩된 행 크기를 추정하는 방법에 대한 세부 정보를 제공합니다. 인코딩된 행 크기는 청구서 및 할당량 사용량을 계산할 때 사용됩니다. 테이블에 대해 프로비저닝된 처리량 용량 요구 사항을 추정할 때 인코딩된 행 크기를 사용할 수도 있습니다.

Amazon Keyspaces 내에서 인코딩된 행 크기를 계산하려는 경우 다음 지침을 사용할 수 있습니다.

인코딩된 열 크기 추정

이 섹션에서는 Amazon Keyspaces에서 인코딩된 열 크기를 추정하는 방법을 보여줍니다.

일반 열 - 기본 키, 클러스터링 열 또는 STATIC 열이 아닌 열인 일반 열의 경우 데이터 유형에 따라 셀 데이터의 원시 크기를 사용하고 필요한 메타데이터를 추가합니다. Amazon Keyspaces가 데이터 유형 값과 메타데이터를 저장하는 방법의 데이터 유형과 몇 가지 주요 차이점은 다음 단원에 나와 있습니다.
파티션 키 열 - 파티션 키에는 최대 2,048바이트의 데이터가 포함될 수 있습니다. 파티션 키의 각 키 열에는 최대 3바이트의 메타데이터가 필요합니다. 행 크기를 계산할 때는 각 파티션 키 열이 전체 3바이트의 메타데이터를 사용한다고 가정해야 합니다.
클러스터링 열 - 클러스터링 열은 최대 850바이트의 데이터를 저장할 수 있습니다. 데이터 값의 크기 외에도 각 클러스터링 열에는 메타데이터에 대한 데이터 값 크기의 최대 20%가 필요합니다. 행 크기를 계산할 때는 클러스터링 열 데이터 값 5바이트당 메타데이터 1바이트를 추가해야 합니다.

참고
효율적인 쿼리 및 내장 인덱싱을 지원하기 위해 Amazon Keyspaces는 각 파티션 키 및 클러스터링 키 열의 데이터 값을 두 번 저장합니다.
열 이름 - 각 열 이름에 필요한 공간은 열 식별자를 사용하여 저장되고 열에 저장된 각 데이터 값에 추가됩니다. 열 식별자의 스토리지 값은 테이블의 전체 열 수에 따라 달라집니다.
- 1-62개 열: 1바이트
- 63-124개 열: 2바이트
- 125-186개 열: 3바이트
62개 열을 추가할 때마다 1바이트를 추가합니다. Amazon Keyspaces에서는 단일 INSERT 또는 UPDATE 문으로 최대 225개의 일반 열을 수정할 수 있다는 점에 유의하세요. 자세한 내용은 Amazon Keyspaces 서비스 할당량 단원을 참조하십시오.

데이터 유형을 기반으로 데이터 값의 인코딩 크기 추정

이 섹션에서는 Amazon Keyspaces에서 서로 다른 데이터 유형의 인코딩된 크기를 추정하는 방법을 보여줍니다.

문자열 유형 - Cassandra ASCII, TEXT및 VARCHAR 문자열 데이터 유형은 모두 UTF-8 바이너리 인코딩이 포함된 유니코드를 사용하여 Amazon Keyspaces에 저장됩니다. Amazon Keyspaces의 문자열 크기는 UTF-8 인코딩 바이트 수와 같습니다.
숫자 유형 - Cassandra INT, BIGINTSMALLINT, 및 TINYINT 데이터 유형은 Amazon Keyspaces에 최대 38개의 유효 숫자로 가변 길이의 데이터 값으로 저장됩니다. 앞과 끝의 0은 잘립니다. 이러한 데이터 유형의 크기는 유효 숫자 2자리당 약 1바이트+1바이트입니다.
블롭 유형 - Amazon KeyspacesBLOB의 A는 값의 원시 바이트 길이와 함께 저장됩니다.
부울 유형 - Boolean 값 또는 Null 값의 크기는 1바이트입니다.
컬렉션 유형 - 콘텐츠에 관계없이와 같은 컬렉션 데이터 유형을 저장LIST하거나 3바이트의 메타데이터가 MAP 필요한 열입니다. LIST 또는 MAP의 크기는 (열 ID) + 합계(중첩 요소 크기) + (3바이트)입니다. 빈 LIST 또는 MAP의 크기는 (열 ID) + (3바이트)입니다. 또한 각 개별 LIST 또는 MAP 요소에는 1바이트의 메타데이터를 필요로 합니다.
사용자 정의 유형 - 사용자 정의 유형(UDT)은 내용에 관계없이 메타데이터에 3바이트가 필요합니다. 각 UDT 요소에 대해 Amazon Keyspaces에는 1바이트의 메타데이터가 추가로 필요합니다.

의 인코딩된 크기를 계산하려면의 필드에 field value 대해 field name 및 로 UDT시작합니다UDT.
- 필드 이름 - 최상위 레벨의 각 필드 이름은 식별자를 사용하여 UDT 저장됩니다. 식별자의 스토리지 값은 최상위의 전체 필드 수에 따라 달라지UDT며 1~3바이트 사이일 수 있습니다.
  - 1~62개 필드: 1바이트
  - 63~124개 필드: 2바이트
  - 125~최대 필드: 3바이트
- 필드 값 - 최상위 수준의 필드 값을 저장하는 데 필요한 바이트는 저장된 데이터 유형에 UDT 따라 다릅니다.
  - Scalar 데이터 형식 - 스토리지에 필요한 바이트는 일반 열에 저장된 동일한 데이터 형식과 동일합니다.
  - 고정 UDT - 고정 중첩된 각 UDT에 대해 중첩된 UDT의 크기는 CQL 바이너리 프로토콜과 동일합니다. 중첩된의 경우 각 필드(비어 있는 필드 포함)에 대해 UDT4바이트가 저장되며 저장된 필드의 값은 필드 값의 CQL 이진 프로토콜 직렬화 형식입니다.
  - 동결된 컬렉션:
    
    LIST 및 SET- 중첩된 고정 LIST 또는의 경우 컬렉션의 각 요소에 대해 SET4바이트와 컬렉션 값의 CQL 이진 프로토콜 직렬화 형식이 저장됩니다.
    MAP – 중첩된 고정의 경우 MAP각 키-값 페어에는 다음과 같은 스토리지 요구 사항이 있습니다.
    
    각 키에 대해 4바이트를 할당한 다음 키의 CQL 이진 프로토콜 직렬화 형식을 추가합니다.
    각 값에 대해 4바이트를 할당한 다음 값의 CQL 이진 프로토콜 직렬화 형식을 추가합니다.
FROZEN 키워드 - 고정 컬렉션 내에 중첩된 고정 컬렉션의 경우 Amazon Keyspaces는 메타 데이터에 대해 추가 바이트를 요구하지 않습니다.
STATIC 키워드 - STATIC 열 데이터는 최대 행 크기인 1MB에 포함되지 않습니다. 정적 열의 데이터 크기를 계산하려면 Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산 섹션을 참조하세요.

Amazon Keyspaces 기능이 행 크기에 미치는 영향 고려

이 섹션에서는 Amazon Keyspaces의 기능이 행의 인코딩된 크기에 미치는 영향을 보여줍니다.

클라이언트 측 타임스탬프 - 클라이언트 측 타임스탬프는 기능이 켜져 있을 때 각 행의 모든 열에 대해 저장됩니다. 이러한 타임스탬프는 약 20~40바이트(데이터에 따라 다름)를 차지하며 행의 스토리지 및 처리량 비용에 영향을 줍니다. 클라이언트 측 타임스탬프에 대한 자세한 내용은 섹션을 참조하세요Amazon Keyspaces의 클라이언트 측 타임스탬프.

올바른 공식을 선택하여 행의 인코딩된 크기를 계산합니다.

이 섹션에서는 Amazon Keyspaces의 데이터 행에 대한 스토리지 또는 용량 처리량 요구 사항을 추정하는 데 사용할 수 있는 다양한 공식을 보여줍니다.

데이터 행의 인코딩된 총 크기는 목표에 따라 다음 공식 중 하나를 기반으로 추정할 수 있습니다.

처리량 용량 - 필요한를 평가하기 위해 행의 인코딩된 크기를 추정하려면read/write request units (RRUs/WRUs) or read/write capacity units (RCUs/WCUs:
```
total encoded size of row = partition key columns + clustering columns + regular columns
```
스토리지 크기 -를 예측하기 위해 행의 인코딩된 크기를 추정하려면 행의 스토리지에 필요한 메타데이터를 BillableTableSizeInBytes추가합니다.
```
total encoded size of row = partition key columns + clustering columns + regular columns + row metadata (100 bytes)
```

중요

모든 열 메타데이터(예: 열 ID, 파티션 키 메타데이터, 클러스터링 열 메타데이터, 클라이언트 측 타임스탬프 및 행 메타데이터)는 최대 행 크기인 1MB에 포함됩니다.

행 크기 계산 예제

모든 열의 유형이 정수인 다음 테이블을 예로 들어 보겠습니다. 테이블에는 파티션 키 열 2개, 클러스터링 열 2개, 일반 열 1개가 있습니다. 이 테이블에는 5개의 열이 있으므로 열 이름 식별자에 필요한 공간은 1바이트입니다.


CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, primary key((pk_col1, pk_col2),ck_col1, ck_col2));

이 예제에서는 다음 문과 같이 테이블에 행을 쓸 때의 데이터 크기를 계산합니다.


INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1) values(1,2,3,4,5);

이 쓰기 작업에 필요한 총 바이트를 추정하려면 다음 단계를 사용하면 됩니다.

열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 파티션 키 열의 크기를 계산합니다. 모든 파티션 키 열에 대해 이 과정을 반복합니다.
1. 파티션 키(pk_col1)의 첫 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
2. 파티션 키(pk_col2)의 두 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 1 byte for the column id + 3 bytes for partition key metadata = 8 bytes
```
3. 두 열을 모두 더하여 파티션 키 열의 총 예상 크기를 구합니다.
```
8 bytes + 8 bytes = 16 bytes for the partition key columns
```
열에 저장된 데이터 유형의 바이트와 메타데이터 바이트를 더하여 클러스터링 열의 크기를 계산합니다. 모든 클러스터링 열에 대해 이 과정을 반복합니다.
1. 클러스터링 열(ck_col1)의 첫 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id  = 6 bytes
```
2. 클러스터링 열(ck_col2)의 두 번째 열 크기를 계산합니다.
```
(2 bytes for the integer data type) x 2 + 20% of the data value (2 bytes) for clustering column metadata + 1 byte for the column id = 6 bytes
```
3. 두 열을 모두 더하여 클러스터링 열의 총 예상 크기를 구합니다.
```
6 bytes + 6 bytes = 12 bytes for the clustering columns
```
일반 열의 크기를 더합니다. 이 예제에서는 한 자리 정수를 저장하는 열이 하나뿐이며 이 경우 열 ID로 2바이트에 1바이트가 필요합니다.
마지막으로 인코딩된 총 행 크기를 가져오려면 모든 열의 바이트를 합산합니다. 스토리지의 청구 가능 크기를 추정하려면 행 메타데이터에 100바이트를 추가합니다.
```
16 bytes for the partition key columns + 12 bytes for clustering columns + 3 bytes for the regular column + 100 bytes for row metadata = 131 bytes.
```

Amazon을 사용하여 서버리스 리소스를 모니터링하는 방법은 섹션을 CloudWatch참조하세요Amazon을 사용하여 Amazon Keyspaces 모니터링 CloudWatch.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

서버리스 리소스 관리

용량 소비 추정