[database] Amazon DynamoDB

DB 선택 큰 그림은 database-overview.

One-Line Summary

Amazon DynamoDB는 완전관리형 서버리스 NoSQL key-value/document DB로, 어떤 규모에서도 한 자릿수 밀리초 지연을 낸다. 프로비저닝할 서버가 없고 자동으로 확장된다. 시험 핵심은 키 설계 / 용량 모드(On-demand vs Provisioned) / GSI vs LSI / Streams / DAX / Global Tables / TTL 이다.

뭔지 (What / Why)

관계형 DB는 스키마·JOIN·수직 확장이 강점이지만, 초대규모 트래픽에서 일정한 저지연을 내긴 어렵다. DynamoDB는 반대 방향이다 — 스키마 유연, JOIN 없음, 대신 키 기반 접근으로 무한에 가깝게 수평 확장하며 지연이 일정하다.

"key-value/document · 서버리스 · 초대규모 · 일정한 ms 지연"이면 DynamoDB. "복잡한 JOIN·트랜잭션 리포팅"이면 관계형(RDS/Aurora).

Abbreviations

약어	풀네임	의미
`PK`	Partition Key	파티션(해시) 키
`SK`	Sort Key	정렬 키
`GSI`	Global Secondary Index	전역 보조 인덱스
`LSI`	Local Secondary Index	로컬 보조 인덱스
`RCU/WCU`	Read/Write Capacity Unit	읽기/쓰기 용량 단위
`DAX`	DynamoDB Accelerator	DynamoDB 전용 인메모리 캐시
`TTL`	Time To Live	항목 자동 만료

키(Key) 설계 — 접근의 기본 (빈출)

DynamoDB는 기본 키로 항목을 찾는다. 키 설계가 성능을 좌우한다.

키 유형	구성	특징
Partition key만	PK	PK 값이 파티션을 결정, 값이 유일해야
Partition + Sort key	PK + SK	같은 PK 안에서 SK로 정렬·범위 조회(예: user의 시간순 주문)

항목(item) 크기 최대 400KB. 큰 객체는 S3에 두고 포인터만 저장.
읽기 일관성: 기본 최종 일관성(eventually consistent), 옵션으로 강력한 일관성(strongly consistent).

용량 모드 — On-demand vs Provisioned (빈출)

모드	언제	과금
On-demand	트래픽 예측 불가/급변, 운영 최소	요청당 과금(피크 자동 대응)
Provisioned	트래픽 예측 가능, 비용 최적화	RCU/WCU 지정(+ Auto Scaling 옵션)

"트래픽을 예측 못 함/스파이크" = On-demand. "꾸준하고 예측 가능·비용 최적화" = Provisioned(+Auto Scaling).

보조 인덱스 — GSI vs LSI (빈출)

기본 키가 아닌 다른 속성으로 조회하려면 보조 인덱스가 필요하다.

	GSI (Global)	LSI (Local)
파티션 키	다른 PK 가능	같은 PK, 다른 SK
생성 시점	언제든 추가/삭제	테이블 생성 시에만
용량	자체 RCU/WCU	테이블 용량 공유
일관성	최종 일관성만	강력한 일관성 가능

"완전히 다른 속성으로 조회" = GSI. "같은 PK 안에서 다른 정렬 키" = LSI. GSI가 더 유연해 실무·시험에서 더 자주.

DynamoDB Streams (빈출 — 변경 이벤트)

테이블의 항목 수준 변경(생성/수정/삭제) 을 시간순 로그로 남긴다(24시간 보존).

item 변경 → Streams → Lambda 트리거(CDC) / 집계 / 복제

대표 패턴: 변경 시 Lambda 실행(알림·파생 테이블 갱신·검색 색인).
Global Tables의 내부 메커니즘이기도 하다.

"DynamoDB 항목 변경에 반응/near real-time change capture" = Streams (+ Lambda).

DAX — DynamoDB Accelerator

DynamoDB 전용 인메모리 캐시. 읽기 지연을 밀리초 → 마이크로초로.

항목	내용
대상	DynamoDB만
효과	읽기 지연 microsecond, 읽기 폭주 완화
적합	read-heavy·반복 조회·버스트 읽기

DynamoDB 캐시는 DAX, 범용 캐시는 ElastiCache. "DynamoDB microsecond reads" = DAX.

Global Tables — 멀티 리전 액티브-액티브

여러 리전에 양방향 복제되는 테이블. 각 리전에서 읽고 쓸 수 있어 글로벌 저지연을 낸다(내부적으로 Streams 사용).

"multi-region active-active, 글로벌 사용자 저지연 읽기/쓰기" = Global Tables.

그 밖에 알아둘 것

기능	내용
TTL	지정 시간 지난 항목 자동 삭제(만료 세션·로그 정리, 무료)
Transactions	여러 항목에 ACID 보장
백업	온디맨드 백업 + PITR(35일)
Export to S3	테이블을 S3로 내보내 Athena 등으로 분석(테이블 부하 없이)

실무 활용 사례

서버리스 앱 백엔드: Lambda + DynamoDB(+API Gateway)로 무상태 확장.
세션/장바구니/게임 상태: 키 기반 저지연 저장.
이벤트 파이프라인: Streams → Lambda로 변경 전파.
글로벌 서비스: Global Tables로 리전별 저지연.
만료 데이터 자동 정리: TTL로 세션/임시 데이터 삭제.

Common Wrong Directions

오답 방향	왜 부족한가
JOIN·복잡 SQL 리포팅을 DynamoDB로	관계형이면 RDS/Aurora
다른 속성 조회에 테이블 풀스캔	GSI(또는 LSI) 설계
예측 불가 트래픽에 고정 Provisioned	On-demand(또는 Auto Scaling)
DynamoDB 캐시에 ElastiCache	DynamoDB 전용은 DAX
변경 이벤트 처리를 폴링으로	Streams + Lambda
글로벌 저지연 쓰기에 단일 리전	Global Tables
큰(>400KB) 객체를 그대로 저장	S3에 두고 포인터만

Exam Triggers

문제에서 이런 표현이 나오면	떠올릴 것
"serverless NoSQL key-value/document"	DynamoDB
"single-digit millisecond at any scale"	DynamoDB
"unpredictable/spiky traffic, no capacity planning"	On-demand
"query by a non-key attribute"	GSI (또는 LSI)
"react to item changes / CDC"	Streams (+Lambda)
"microsecond reads for DynamoDB"	DAX
"multi-region active-active"	Global Tables
"auto-expire old items"	TTL
"analyze DynamoDB data in S3/Athena"	Export to S3

Memory Sentence

DynamoDB는 서버리스 NoSQL key-value/document로 어떤 규모에서도 ms 지연. 키(PK/SK)로 접근하고, 다른 속성 조회는 GSI(유연)·LSI(같은 PK). 용량은 예측불가=On-demand·예측가능=Provisioned. 변경 이벤트는 Streams+Lambda, 캐시는 DAX(마이크로초), 글로벌은 Global Tables, 만료는 TTL, 분석은 Export to S3.