Amazon 키스페이스에서 테이블 작업 - Amazon Keyspaces(Apache Cassandra용)

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

Amazon 키스페이스에서 테이블 작업

이 단원에서는 Amazon Keyspaces (Apache Cassandra용) 에서 테이블 작업에 관한 세부 정보를 제공합니다.

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

Amazon Keyspaces 는 테이블 생성 및 삭제와 같은 DDL (Data Definition Language) 작업을 비동기식으로 수행합니다. 에서 새 테이블의 생성 상태를 모니터링할 수 있습니다.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에서 정적 열의 인코딩된 크기를 계산하려면 다음 지침을 따르십시오.

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

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

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

  • 클러스터링 열과 기본이 아닌 일반 키 열은 정적 데이터의 크기에 포함되지 않습니다. 행 내의 비정적 데이터의 크기를 추정하는 방법에 대한 자세한 내용은Amazon 키스페이스에서 행 크기 계산.

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

partition key columns + static columns + metadata = total encoded size of static data

모든 열이 정수 유형인 테이블의 다음 예를 생각해 보십시오. 테이블에는 두 개의 파티션 키 열, 두 개의 클러스터링 열, 일반 열 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 키스페이스에서 행 크기 계산를 클릭하고 결과를 추가합니다.

이 경우 총 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

모든 열이 정수 유형인 테이블의 다음 예를 생각해 보십시오. 테이블에는 두 개의 파티션 키 열, 두 개의 클러스터링 열, 일반 열 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 키스페이스에서 행 크기 계산. 이 예에서 행 업데이트의 총 크기는 134바이트입니다.

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

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

정적 데이터는 개별 행이 아닌 카산드라의 논리 파티션과 연결됩니다. Amazon Keyspaces의 논리 파티션은 여러 물리적 스토리지 파티션에 걸쳐서 크기가 사실상 바인딩 해제될 수 있습니다. 따라서 Amazon Keyspaces 미터는 정적 데이터와 비정적 데이터에 대한 작업을 별도로 작성합니다. 또한 정적 데이터와 비정적 데이터를 모두 포함하는 쓰기에는 데이터 일관성을 제공하기 위해 추가 기본 작업이 필요합니다.

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

다음은 정적 열이 있는 Amazon Keyspaces 테이블에 대해 프로비저닝된 처리량 용량 요구 사항을 계산할 때 필요한 RCU (읽기 용량 단위) 와 쓰기 용량 단위 (WCU) 를 추정하는 방법에 대한 세부 정보를 제공합니다. 다음 공식을 사용하여 테이블에서 정적 데이터와 비정적 데이터를 모두 포함하는 쓰기를 처리하는 데 필요한 용량을 예측할 수 있습니다.

2 x WCUs required for nonstatic data + 2 x WCUs required for static data

예를 들어 애플리케이션이 초당 27KB의 데이터를 쓰고 각 쓰기에 25.5 KB의 비정적 데이터와 1.5KB의 정적 데이터가 포함된 경우 테이블에는 56WCU (2 x 26 WCU + 2 x 2WCU) 가 필요합니다.

Amazon Keyspaces는 정적 및 비정적 데이터의 읽기를 여러 행의 읽기와 동일하게 측정합니다. 결과적으로 동일한 작업에서 정적 및 비정적 데이터를 읽는 가격은 읽기를 수행하기 위해 처리된 데이터의 집계 크기를 기반으로 합니다.

Amazon CloudWatch를 사용하여 서버리스 리소스를 모니터링하는 방법은 단원을 참조하십시오.아마존을 통한 아마존 Keyspaces 모니터링 CloudWatch.