Amazon Keyspaces 작업: Amazon Keyspaces 작업 - Amazon Keyspaces(Apache Cassandra용)
테이블 생성고정 기둥

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

Amazon Keyspaces 작업: Amazon Keyspaces 작업

이 섹션에서는 Amazon Keyspaces (Apache Cassandra용) 에서 작업을 가집니다.

Amazon 키스페이스에서 테이블 생성

Amazon Keyspaces (Amazon Keyspaces) 작업을 Amazon Keyspaces (DDL) 작업을 Amazon Keyspaces (DDL) 작업을 Amazon Keyspaces (DDL) 작업을. 에서 새 테이블의 생성 상태를 모니터링하여 테이블이AWS Management Console 보류 중이거나 활성 상태일 때를 알 수 있습니다. 시스템 스키마 테이블을 사용하여 프로그래밍 방식으로 새 테이블의 생성 상태를 모니터링할 수도 있습니다.

테이블은 사용할 준비가 되면 시스템 스키마에서 활성 상태로 표시됩니다. 새 테이블을 사용할 준비가 되었을 때 확인하기 위한 권장 설계 패턴은 Amazon Keyspaces 시스템 스키마 테이블 (system_schema_mcs.*) 을 폴링하는 것입니다. 테이블의 DDL 명령문 목록은 CQL 언어 참조의테이블 섹션을 참조하십시오.

다음 쿼리는 테이블 상태를 보여줍니다.

SELECT keyspace_name, table_name, status FROM system_schema_mcs.tables WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';

아직 생성 중이고 보류 중인 테이블의 경우 쿼리 출력은 다음과 같습니다.


keyspace_name | table_name | status
--------------+------------+--------
   mykeyspace |    mytable | CREATING

성공적으로 생성되어 활성 상태인 테이블의 경우 쿼리 출력은 다음과 같습니다.


keyspace_name | table_name | status
--------------+------------+--------
   mykeyspace |    mytable | ACTIVE

Amazon 키스페이스의 정적 컬럼

Amazon Keyspaces 테이블의 열을 정적으로 선언하면 이 열에 저장된 값이 논리적 파티션의 모든 행 간에 공유됩니다. 이 열의 값을 업데이트하면 Amazon Keyspaces는 변경 사항을 파티션의 모든 행에 자동으로 적용합니다.

이 섹션에서는 정적 열에 쓸 때 인코딩된 데이터 크기를 계산하는 방법을 설명합니다. 이 프로세스는 행의 비정적 열에 데이터를 쓰는 프로세스와는 별도로 처리됩니다. 정적 데이터에 대한 크기 할당량 외에도 정적 열에 대한 읽기 및 쓰기 작업은 테이블의 측정 및 처리 용량에도 독립적으로 영향을 미칩니다.

Amazon 키스페이스의 논리적 파티션당 정적 열 크기 계산

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

  • 파티션 키는 최대 2,048바이트의 데이터를 포함할 수 있습니다. 파티션 키의 각 키 열에는 최대 3바이트의 메타데이터가 필요합니다. 이러한 메타데이터 바이트는 파티션당 1MB의 정적 데이터 크기 할당량에 포함됩니다. 정적 데이터의 크기를 계산할 때는 각 파티션 키 열이 전체 3바이트의 메타데이터를 사용한다고 가정해야 합니다.

  • 데이터 유형에 따라 정적 열 데이터 값의 원시 크기를 사용합니다. 데이터 형식에 대한 자세한 내용은 데이터 유형 단원을 참조하세요.

  • 메타데이터의 정적 데이터 크기에 104바이트를 추가합니다.

  • 클러스터링 열과 기본이 아닌 일반 키 열은 정적 데이터 크기에 포함되지 않습니다. 행 내 비정적 데이터의 크기를 추정하는 방법을 알아보려면 을 참조하십시오Amazon Keyspace에서의 행 크기 계산.

정적 열의 인코딩된 총 크기는 다음 공식을 기반으로 합니다.

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_col1) 의 첫 번째 열 크기를 계산합니다.

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes

    2. 파티션 키 (pk_col2) 의 두 번째 열 크기를 계산합니다.

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes

    3. 두 열을 모두 추가하여 파티션 키 열의 총 예상 크기를 구합니다.

      7 bytes + 7 bytes = 14 bytes for the partition key columns

  2. 정적 열의 크기를 추가합니다. 이 예제에서는 정수 (4바이트 필요) 를 저장하는 정적 열이 하나뿐입니다.

  3. 마지막으로 정적 열 데이터의 인코딩된 총 크기를 구하려면 기본 키 열 및 정적 열의 바이트를 추가하고 메타데이터에 104바이트를 추가합니다.

    14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.

동일한 명령문을 사용하여 정적 및 비정적 데이터를 업데이트할 수도 있습니다. 쓰기 작업의 전체 크기를 추정하려면 먼저 비정적 데이터 업데이트의 크기를 계산해야 합니다. 그런 다음 의 예와 같이 행 업데이트의 크기를 계산하고 결과를 추가합니다.Amazon Keyspace에서의 행 크기 계산

이 경우 총 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바이트입니다.

  2. 의 단계에 따라 비정적 데이터의 업데이트를 기준으로 행의 총 인코딩된 크기 크기를 추가합니다Amazon Keyspace에서의 행 크기 계산. 이 예제에서 행 업데이트의 총 크기는 134바이트입니다.

    122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.

Amazon 키스페이스에서 정적 데이터의 읽기/쓰기 작업 측정

정적 데이터는 개별 행이 아니라 Cassandra의 논리적 파티션과 연결됩니다. Amazon Keyspaces의 논리적 파티션은 여러 물리적 스토리지 파티션에 걸쳐 있으므로 크기가 거의 제한되지 않을 수 있습니다. 따라서 Amazon Keyspace는 정적 데이터와 비정적 데이터에 대한 쓰기 작업을 별도로 측정합니다. 또한 정적 데이터와 비정적 데이터를 모두 포함하는 쓰기에는 데이터 일관성을 유지하기 위한 추가 기본 작업이 필요합니다.

정적 데이터와 비정적 데이터 모두에 대해 혼합 쓰기 작업을 수행하면 두 개의 별도 쓰기 작업이 발생합니다. 하나는 비정적 데이터용이고 다른 하나는 정적 데이터용입니다. 이는 온디맨드 및 프로비저닝된 읽기/쓰기 용량 모드 모두에 적용됩니다.

다음 예제는 정적 열이 있는 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+ 2 x 2WCU) 가 필요합니다.

Amazon Keyspace는 정적 및 비정적 데이터의 읽기를 여러 행의 읽기와 동일하게 측정합니다. 따라서 동일한 작업에서 정적 및 비정적 데이터를 읽는 데 드는 비용은 읽기를 수행하기 위해 처리된 데이터의 총 크기를 기반으로 합니다.

Amazon에서 서버리스 리소스를 모니터링하는 방법을 CloudWatch 알아보려면 을 참조하십시오아마존을 통한 아마존 키스페이스 모니터링 CloudWatch.