테이블, 항목 및 기본 키

Amazon DynamoDB는 모든 규모에서 한 자릿수 밀리초 성능을 제공하도록 설계된 완전 관리형 서버리스 키-값 및 문서 데이터베이스입니다. 관계형 데이터베이스와 달리 DynamoDB는 스키마가 없습니다. 기본 키가 있기만 하면 각 항목은 서로 다른 속성 집합을 가질 수 있습니다.

DynamoDB는 SQL 테이블과 유사한 최상위 컨테이너인 테이블에 데이터를 저장합니다. 테이블은 여러 AZ의 여러 스토리지 노드에 자동으로 분산되므로 사용자가 별도로 구성하지 않아도 기본 중복성이 제공됩니다.

DynamoDB 테이블에는 항목 모음이 저장되며, 각 항목은 속성 모음입니다. 속성은 형식이 지정된 값입니다. 문자열(String)(S), 숫자(Number)(N), 이진(Binary)(B), 부울(Boolean)(BOOL), Null(NULL), 목록(List)(L), 맵(Map)(M), 집합(Set) 형식(SS, NS, BS)이 있습니다.

테이블의 모든 항목에는 기본 키 속성이 포함되어야 하며, 다른 모든 속성은 선택 사항이고 항목마다 다를 수 있습니다. 단일 항목의 크기는 모든 속성 이름과 값을 포함하여 최대 400 KB입니다.

단순 기본 키는 파티션 키(해시 키라고도 함)라는 단일 속성으로 구성됩니다. DynamoDB는 파티션 키 값에 내부 해시 함수를 적용하여 항목이 저장될 스토리지 파티션을 결정합니다. 파티션 키 값이 같은 모든 항목은 함께 저장됩니다.

단순 기본 키를 사용하면 테이블의 두 항목이 같은 파티션 키 값을 가질 수 없습니다. 파티션 키가 각 항목을 고유하게 식별하기 때문입니다. 이 설계는 사용자 ID나 주문 ID처럼 항상 고유 식별자로 데이터에 액세스하는 테이블에 적합합니다.

복합 기본 키는 파티션 키와 정렬 키(범위 키라고도 함)를 함께 사용합니다. 파티션 키가 같은 항목은 함께 저장되고 정렬 키 값에 따라 정렬되므로 파티션 내에서 범위 쿼리를 수행할 수 있습니다.

이 설계는 매우 유연합니다. 정렬 키가 다르기만 하면 여러 항목이 같은 파티션 키를 공유할 수 있습니다. 예를 들어 Orders 테이블에서 CustomerId를 파티션 키로, OrderDate를 정렬 키로 사용하면 고객의 모든 주문을 날짜순으로 쿼리할 수 있습니다.

올바른 파티션 키를 선택하는 것은 DynamoDB 설계에서 가장 중요한 결정입니다. 좋은 파티션 키는 카디널리티(서로 다른 값의 수)가 높고 파티션 전체에 액세스가 고르게 분산됩니다. 잘못된 선택은 한 파티션에 트래픽이 지나치게 집중되는 핫 파티션을 만들어 처리량 제한을 일으킵니다.

피해야 할 안티 패턴은 부울 플래그(값이 두 개뿐임), 오늘 작성된 항목을 모두 하나로 묶는 날짜, 카디널리티가 낮은 상태 필드를 사용하는 것입니다. 좋은 선택으로는 사용자 ID, 장치 ID, 임의 UUID 또는 tenantId#entityType과 같은 복합 값이 있습니다.

DynamoDB의 세 가지 기본 항목 작업은 다음과 같습니다.

• PutItem: 새 항목을 쓰거나 동일한 기본 키를 가진 기존 항목을 완전히 교체합니다
• GetItem: 정확한 기본 키로 단일 항목을 가져옵니다(전체 키가 필요하며, 복합 키인 경우 파티션 키와 정렬 키가 모두 필요합니다)
• DeleteItem: 정확한 기본 키로 항목을 삭제합니다

세 작업 모두 항목 수준에서 원자적으로 수행됩니다. 기본적으로 GetItem은 최종적 일관성 읽기를 사용합니다. --consistent-read를 추가하면 항상 가장 최근에 기록된 값을 반환하는 강한 일관성 읽기가 강제됩니다.

UpdateItem은 PutItem과 달리 기존 항목 전체를 교체하지 않고 특정 속성을 수정합니다. 속성을 추가하거나 삭제하고, 숫자 속ים에 대해 원자적으로 산술 연산을 수행할 수 있습니다(예: 카운터 증가).

조건식을 사용하면 조건이 참인 경우에만 작업이 성공하도록 지정할 수 있습니다. 예를 들어 항목의 상태가 현재 PENDING인 경우에만 항목을 업데이트할 수 있습니다. 이는 트랜잭션 없이 낙관적 잠금 패턴을 구현하며, DynamoDB의 주요 설계 기법입니다.

Query는 동일한 파티션 키 값을 공유하는 항목을 가져오며, 선택적으로 정렬 키 조건으로 필터링할 수 있습니다. Query는 대상 파티션만 읽으므로 효율적입니다. begins_with, between, =, <, >와 같은 정렬 키 조건을 사용하여 파티션 내 결과를 좁힐 수 있습니다.

Scan은 테이블의 모든 항목을 읽은 다음 선택적 필터 식을 적용합니다. Scan은 대규모 테이블에서 비용이 많이 들므로 운영 환경의 쿼리 패턴에서는 피해야 합니다. Scan을 자주 사용해야 한다면 테이블 설계를 재검토하거나 전역 보조 인덱스를 추가하십시오.

DynamoDB는 여러 AZ에 데이터 사본 3개를 저장합니다. 최종 일관성 읽기(기본값)는 최근 쓰기 작업이 아직 모든 사본에 전파되지 않은 경우 약간 오래된 값을 반환할 수 있지만, 강한 일관성 읽기에 필요한 읽기 용량 단위의 절반만 소비합니다.

강한 일관성 읽기는 항상 가장 최근에 커밋된 쓰기 결과를 반환하지만 RCU의 2배 비용이 들며 Global Secondary Index에서는 사용할 수 없습니다. 처리량이 높고 읽기 작업이 많은 워크로드에는 최종 일관성 읽기를 선택하고, 애플리케이션에 항상 최신 데이터가 필요한 경우에만 강한 일관성 읽기를 사용하십시오.

DynamoDB는 ACID 트랜잭션을 TransactWriteItems 및 TransactGetItems를 통해 지원합니다. 하나의 트랜잭션으로 여러 항목과 여러 테이블에 걸쳐 최대 100개의 쓰기 작업을 그룹화할 수 있으며, 모든 작업이 성공하거나 모두 원자적으로 롤백되도록 보장합니다.

계정 간 송금(한 항목에서 차감하고 다른 항목에 추가)이나 좌석 예약(가용성을 확인하고 원자적으로 예약)과 같은 상황에 트랜잭션을 사용하십시오. 트랜잭션은 일반 RCU/WCU의 2배 비용이 들므로 여러 항목에 걸친 원자성이 실제로 필요한 경우에만 사용하십시오.

DynamoDB의 항목당 400KB 제한은 데이터 모델링 방식에 영향을 줍니다. 큰 페이로드(예: 이미지, 대형 문서)는 바이너리 데이터를 S3에 저장하고 DynamoDB에는 S3 객체 키만 저장하십시오. 깊게 중첩된 계층형 데이터의 경우 단일 테이블 설계를 사용하여 각 노드 유형을 고유한 파티션 키 패턴으로 모델링하십시오. 하나의 테이블에 여러 엔터티 유형을 저장하고, 파티션 키 접두사와 정렬 키 패턴으로 유형을 구분하는 방식입니다.

단일 테이블 설계는 테이블 수를 줄이고 관련 항목을 동일한 파티션에 함께 배치하여 효율적인 접근 패턴을 구현합니다. 이는 복잡한 접근 패턴에서 운영 오버헤드를 줄이고 성능을 향상시키는 고급 기법입니다.

이 단원에서 다룬 AWS 솔루션 아키텍트(SAA-C03) 개념에 대한 이해도를 확인해 보십시오.

이 단원에서는 다음을 배웠습니다. DynamoDB 테이블에는 스키마가 없는 항목이 저장되며 항목 크기는 400KB로 제한됩니다. 단순 기본 키는 파티션 키만 사용하고, 복합 키에는 범위 쿼리를 위한 정렬 키가 추가됩니다. 또한 카디널리티가 높은 파티션 키는 핫 파티션을 방지합니다. 효율적인 데이터 접근을 위해 Scan 대신 Query를 사용하십시오. 다음 단원에서는 프로비저닝 용량 모드와 온디맨드 용량 모드를 살펴봅니다.