Amazon Keyspaces에서 테이블로 작업하기 - Amazon Keyspaces(Apache Cassandra용)

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

Amazon Keyspaces에서 테이블로 작업하기

이 섹션에서는 Amazon Keyspaces(Apache Cassandra용)의 테이블 작업에 대한 세부 정보를 제공합니다.

Amazon Keyspaces에서 테이블 생성

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 Keyspaces에서 멀티 리전 테이블 사용하기

다중 리전 테이블에는 다음 두 가지 방법 중 하나로 쓰기 처리 용량이 구성되어 있어야 합니다.

  • WRU (쓰기 요청 단위) 단위로 측정되는 온디맨드 용량 모드

  • Auto Scaling이 포함된 프로비저닝된 용량 모드 (쓰기 용량 단위 (WCU) 단위로 측정

Auto Scaling과 함께 프로비저닝된 용량 모드 또는 온디맨드 용량 모드를 사용하면 멀티 리전 테이블에 대해 복제된 쓰기를 수행할 수 있는 충분한 용량을 확보할 수 있습니다. AWS 리전

참고

지역 중 하나에서 테이블의 용량 모드를 변경하면 모든 복제본의 용량 모드가 변경됩니다.

기본적으로 Amazon Keyspace는 멀티 리전 테이블에 온디맨드 모드를 사용합니다. 온디맨드 모드를 사용하면 애플리케이션에서 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. Amazon Keyspaces는 이전에 도달한 트래픽 수준으로 워크로드를 늘리거나 줄일 때 워크로드를 즉시 수용합니다. 워크로드의 트래픽 수준이 새로운 최고점에 도달하면 Amazon Keyspace는 워크로드를 수용하도록 빠르게 적응합니다.

테이블에 프로비저닝된 용량 모드를 선택하는 경우 애플리케이션에 필요한 초당 읽기 용량 단위 (RCU) 및 쓰기 용량 단위 (WCU) 수를 구성해야 합니다.

다중 지역 테이블의 처리 용량 요구 사항을 계획하려면 먼저 각 지역에 필요한 초당 WCU 수를 추정해야 합니다. 그런 다음 테이블이 복제되는 모든 지역의 쓰기를 추가하고 이 합계를 사용하여 각 지역의 용량을 프로비저닝합니다. 이는 한 지역에서 수행되는 모든 쓰기가 각 복제 지역에서도 반복되어야 하기 때문에 필요합니다.

테이블 용량이 충분하지 않아 모든 지역의 쓰기를 처리할 수 없는 경우 용량 예외가 발생합니다. 또한 지역 간 복제 대기 시간도 늘어날 것입니다.

예를 들어 미국 동부 (버지니아 북부) 에서 초당 5개, 미국 동부 (오하이오) 에서 초당 10개, 유럽 (아일랜드) 에서 초당 5개가 예상되는 다중 지역 테이블의 경우 테이블은 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 유럽 (아일랜드) 등 각 지역에서 20개의 WCU를 사용할 것으로 예상해야 합니다. 즉, 이 예시에서는 각 테이블 복제본에 대해 20개의 WCU를 프로비저닝해야 합니다. Amazon을 사용하여 테이블의 용량 사용량을 모니터링할 수 CloudWatch 있습니다. 자세한 설명은 아마존을 통한 아마존 키스페이스 모니터링 CloudWatch 섹션을 참조하세요.

각 다중 지역 쓰기 요금은 WCU의 1.25배로 청구되므로 이 예에서는 총 75개의 WCU에 대한 요금이 청구됩니다. 요금에 대한 자세한 내용은 Amazon Keyspaces(Apache Cassandra용) 요금을 참조하세요.

Amazon Keyspaces Auto Scaling을 통한 프로비저닝 용량에 대한 자세한 내용은 을 참조하십시오. Amazon Keyspaces 자동 크기 조정을 통해 처리 용량을 자동으로 관리합니다.

참고

테이블이 Auto Scaling과 함께 프로비저닝된 용량 모드에서 실행되는 경우, 프로비저닝된 쓰기 용량은 각 지역의 Auto Scaling 설정 내에서 유동적으로 허용될 수 있습니다.

Amazon Keyspaces의 정적 열

클러스터링 열이 있는 Amazon Keyspaces 테이블에서 STATIC 키워드를 사용하여 정적 열을 생성할 수 있습니다. 정적 열에 저장된 값은 논리적 파티션의 모든 행에서 공유됩니다. 이 열의 값을 업데이트하면 Amazon Keyspaces는 파티션의 모든 행에 변경 사항을 자동으로 적용합니다.

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

Amazon Keyspaces의 논리적 파티션당 정적 열 크기 계산

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

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

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

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

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

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

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 Keyspaces에서의 행 크기 계산의 예제와 같이 행 업데이트 크기를 계산하고 결과를 더합니다.

이 경우 총 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 Keyspaces에서의 행 크기 계산의 단계에 따라 비정적 데이터의 업데이트를 기반으로 인코딩된 행의 총 크기를 추가합니다. 이 예제에서 행 업데이트의 총 크기는 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 + 2 x 2WCU)가 필요합니다.

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

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