DynamoDB 아이템 크기 한도 (400 KB)

단일 DynamoDB 아이템은 최대 400 KB의 데이터를 담을 수 있습니다. MongoDB(16 MB 문서)나 실질적 상한이 없는 관계형 행에서 온 사람에게 그 천장은 낮게 느껴지고 — 보통 어렵게 알게 됩니다. 수개월 동안 잘 되던 쓰기가 어느 아이템이 마침내 너무 커지는 바람에 ValidationException으로 갑자기 실패할 때 말이죠.

이 한도는 임의적이지 않고, 올릴 수 있는 할당량도 아닙니다. 모델링 제약이며, 이 한도에 부딪히는 아이템은 대개 데이터가 잘못 모델링되었다는 신호입니다.

DynamoDB의 최대 아이템 크기는 얼마인가요?

DynamoDB는 단일 아이템을 400 KB로 제한하며, 이는 올릴 수 없는 하드 한도입니다. 이 크기는 속성 이름과 값을 합산해서 계산하며, 모든 중첩 리스트·맵·셋 요소까지 포함합니다. 아이템은 대개 끝없이 커지는 임베디드 리스트처럼 무한정 증가하다가 한도에 부딪히며, 해결책은 압축이 아니라 모델링 — 즉 컬렉션을 별도 아이템으로 분리하는 것입니다.

• 아이템당 400 KB, 하드 캡. 조정 불가, 소프트 할당량도 아님.
• 크기 = 속성 이름 + 값, 합산. 긴 속성 이름은 모든 아이템에서 계산됩니다.
• 중첩과 셋도 계산됩니다. 리스트, 맵, 그리고 그 안의 중첩 값이 모두 쌓입니다.
• 흔한 원인은 무한정 증가 — 부모 아이템에 한도 없이 커지는 리스트를 박는 것.
• 해결책은 압축이 아니라 모델링. 커지는 컬렉션을 공유 파티션 키 아래 자체 아이템으로 분리하세요.

문제: 영원히 커지는 아이템

차량 함대를 추적하는데, 각 차량의 텔레메트리 측정값을 차량 아이템의 리스트로 저장하기로 했다고 합시다:

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

하루이틀은 괜찮습니다. 하지만 측정값은 몇 초마다 도착하고 멈추지 않으므로, 리스트는 한도 없이 커집니다. 결국 단일 차량 아이템이 400 KB를 넘고 그 아이템에 대한 모든 쓰기가 실패합니다 — 각 갱신이 (이제 과대해진) 아이템 전체를 다시 쓰기 때문에 그 차량의 텔레메트리를 더 이상 전혀 기록할 수 없게 됩니다.

버그는 크기 한도가 아닙니다. 무한정의 일대다 관계를 박은 리스트로 모델링한 것이 버그입니다. 그건 "다" 쪽이 한정적이고 작을 때만 통합니다.

실제로 400 KB에 포함되는 것

DynamoDB는 아이템의 총 크기를 다음의 합으로 측정합니다:

• 모든 속성 이름, UTF-8 인코딩. 수백만 아이템에 걸쳐 반복되는 20자 이름은 크기이자 지불하는 스토리지입니다 — 경험 많은 모델러가 속성 이름을 짧게 유지하는 이유입니다.
• 모든 속성 값. 문자열과 바이너리는 바이트 길이로, 숫자는 압축 인코딩으로, 불리언과 널은 아주 작은 고정 비용으로.
• 중첩 구조. 리스트나 맵은 자체 오버헤드 더하기 그 안의 모든 요소와 키의 크기를 맨 아래까지 계산합니다.

계획할 별도의 속성별 상한은 없습니다 — 아이템 전체가 400 KB 선에 맞섭니다. AWS 서비스 할당량 이 정확한 바이트 계산을 명시합니다.

한도가 존재하는 이유

큰 아이템은 옮기는 데 비쌉니다. DynamoDB 읽기는 4 KB 단위로 계량되므로 400 KB 아이템을 강하게 읽으면 100 RCU가 듭니다 — 그리고 아이템이 커질수록 읽기, 쓰기, 복제 모두가 느려지고 비싸집니다. 이 한도는 작고 표적화된 아이템 쪽으로 밀어붙이며, NoSQL 초심자가 관계형 습관으로 손을 뻗는 "거대한 덩어리 하나를 가져오는" 안티패턴에서 멀어지게 합니다.

우회 설계하기

함대 예시에서는 박는 것을 멈추세요. 각 측정값에 차량과 같은 파티션의 자체 아이템을 주고, 정렬 키의 타임스탬프로 순서를 매기세요:

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

이제 어떤 단일 아이템도 커지지 않고, 쓰기가 결코 한도를 넘지 않으며, VEHICLE#A1에 대한 단일 Query가 여전히 한 차량의 측정값을 하나의 정렬된 아이템 컬렉션으로 끌어옵니다. 한정된 하위 리스트(몇 개의 태그, 고정 구성 블록)는 박아도 괜찮고, 무한정인 것은 아이템이 됩니다.

DynoTable에서 아이템 크기 확인하기

형태를 확정하기 전에 대표적인 아이템의 무게를 재세요. DynoTable에서 아이템을 Quick View로 열면 아이템의 바이트 크기가 속성 옆에 표시됩니다 — 그래서 실제 데이터를 탐색하는 중에, 실패한 쓰기가 아니라 설계 시점에 너무 무거운 형태를 잡아냅니다.

브라우저에서 작업하고 싶다면 DynamoDB 아이템 크기 계산기로도 동일하게 할 수 있습니다. 붙여 넣은 샘플에서 정확한 KB와 각 읽기·쓰기가 소비할 RCU/WCU를 보고합니다.

함정과 다음 단계

• 트래픽과 함께 커지는 박힌 리스트를 주시하세요 — 그것이 전형적인 400 KB 시한폭탄입니다. 한정하거나 분리하세요.
• 속성 이름을 짧게 하세요 — 카디널리티 높은 아이템에서는 크기와 스토리지를 공짜로 되돌려받습니다.
• 큰 값은 S3에 둡니다. 큰 덩어리(이미지, 문서)는 S3에 저장하고 아이템에는 키만 유지하세요.
• 관련: 비정규화와 일대다 관계가 언제 박고 언제 분리할지를 다룹니다.

테이블 전체의 실제 아이템 크기를 한눈에 보고 싶으세요? DynoTable을 다운로드해서 데이터를 직접 살펴보세요.