DynamoDB는 키-값 저장소인가요?
예 — DynamoDB는 키-값 저장소이자 문서 저장소이기도 합니다. 모든 항목은 기본 키(파티션 키, 선택적으로 정렬 키 포함)로 검색되므로 빠른 키 기반 조회가 가능합니다. 추가로 문서 유형(중첩 목록 및 맵)을 지원하므로 키-값 및 문서 데이터베이스로 작동합니다.
키-값 모델
각 항목에는 해당 항목을 고유하게 식별하는 기본 키가 있습니다. 해당 키의 GetItem은 한 자릿수 밀리초 단위의 직접 조회이며 스캔이 필요하지 않습니다. 이는 전형적인 키-값 액세스 패턴입니다.
문서 쪽
키 외에도 값은 400KB 항목 제한 내에서 최대 32레벨 깊이로 중첩된 맵(객체) 및 목록(배열)과 같은 풍부한 문서가 될 수 있습니다. 따라서 DynamoDB는 JSON과 유사한 문서 값을 포함하는 키-값 저장소가 됩니다.
문서가 반쯤 멈추는 곳
32레벨 상한은 실제적이지만(33레벨은 완전히 거부됨, with the exact error here), 깊이가 마음에 드는 경우는 거의 없습니다. 어드레싱은 입니다.
필드가 아닌 키로 읽습니다. ProjectionExpression은 DynamoDB가 읽는 것보다 회선을 통과하는 것의 범위를 좁힙니다. 긴 bio와 100개 요소 tags 목록을 포함하는 하나의 ~30KB 항목에서 강력하게 일관된 GetItem는 동일한 세 가지 방식으로 청구됩니다.
| 요청 | 반환됨 | ConsumedCapacity |
|---|---|---|
GetItem, 전체 항목 | 모든 것 | 8 |
ProjectionExpression: 'status' | 6바이트 값 1개 | 8 |
ProjectionExpression: 'profile.tags[0]' | 하나의 목록 요소 | 8 |
이는 키-값 저장소에 문서를 저장하여 수락하는 거래입니다. 액세스 단위와 청구 단위가 전체 항목입니다. 하나의 속성을 지속적으로 읽고 그 이웃이 큰 경우 해당 속성은 다른 항목에 속합니다.
키가 중요한 이유
읽기에는 키가 지정되므로 효율적인 조회는 단일 partition key 값을 고정하는 것부터 시작됩니다. 좋은 키를 설계하는 것은 DynamoDB 모델링의 핵심입니다.
키뿐만 아니라 값의 크기도 조정하세요
키-값 속도는 값이 액세스 패턴에 맞는다고 가정합니다. 400KB 항목은 한 필드를 프로젝션하든 전체 문서를 프로젝션하든 관계없이 읽는 데 드는 비용은 동일합니다. 위 섹션의 표에는 이미 ~30KB 항목에 대한 8 용량 단위가 표시되어 있습니다. S3에 큰 Blob을 저장하고 문서의 일부만 핫할 때 DynamoDB에 포인터를 유지합니다.
item size calculator 합계는 DynamoDB가 청구하는 방식으로 속성 이름과 값을 나타냅니다.
DynoTable에서: 엔터티 접두사를 한 눈에 읽을 수 있도록 그리드에서 USER#123 디코드와 같은 복합 파티션 키를 사용하고 행 빠른 보기(Space)는 위치를 잃지 않고 전체 문서를 엽니다. Querying tables를 참조하세요.
더 알아보기
DynamoDB composite primary key 및 how DynamoDB partition keys work의 키를 이해합니다. Download DynoTable는 키로 쿼리합니다.
참고 자료
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
위에 링크된 공식 AWS 문서를 기준으로 2026년 7월 13일에 마지막으로 확인되었습니다.
용량 수치는 2026-07-28에 DynamoDB Local 3.3.0(amazon/dynamodb-local:latest)을 기준으로 @aws-sdk/client-dynamodb 3.1095.0을 통해 측정되었으며 추정되지 않았습니다.