Amazon DynamoDB - Overview
- Non-relational Key-Value store
- 클라우드 완전 관리형, 서버리스, NoSQL 데이터베이스
- Fast, Flexible, Cost-effective, Fault Tolerant, Secure
- Multi-region, multi-master database (Global Tables)
- Backup and restore with PITR (Point-in-time Recovery)
- 모든 규모에서 한 자리수 밀리초 성능 제공(Single-digit millisecond performance at any scale)
- DAX를 사용한 In-memory 캐싱 (DynamoDB Accelerator, microsecond latency)
- API를 통한 CRUD (Create/Read/Update/Delete) 작업 지원
- 여러 테이블에 걸친 Transaction 지원 (ACID support)
- 직접 분석 쿼리 없음 (No joins)
- 효율적인 설계 및 성능을 위해 Access Pattern을 알아야 함
Demo
DynamoDB Terminology Compared to SQL
SQL / RDBMS | DynamoDB |
Tables | Tables |
Rows | Items |
Columns | Attributes |
Primary Keys - 다중 열 및 선택 사항 |
Primary Keys - 필수, 최소 1개 및 최대 2개의 속성 |
Indexs | Local Secondary Indexes |
Views | Global Secondary Indexes |
DynamoDB Tables
- Tables은 최상위 Entity
- 엄격한 테이블간 관계 없음 (Independent Entities)
- Table 수준에서 성능 제어
- JSON으로 저장된 테이블 항목 (DynamoDB-specific JSON)
- 기본키(Primary key)는 필수, 나머지 스키마는 유연함(flexible)
- 기본키(Primary Key)는 단순(simple) 또는 복합(composite) 일수 있다.
- 단순키(Simple Key)는 단일 속성 (=partition key or hash key)
- 복합키(Composite Key)는 두 가지 속성(=partition/hash key + sort/range key)
- 키가 아닌 속성(including secondary key attributes)은 선택 사항(Optional)
DynamoDB Table Items
단순 기본 키(Simple Primary Key)가 있는 테이블
{
"partition_key":"...",
"attribute_1":"...",
"attribute_2":"..."
}
{
"partition_key":"...",
"attribute_1":"...",
"attribute_4":"...",
"attribute_5":"..."
}
복합 기본 키(Composite Primary Key)가 있는 테이블
{
"partition_key":"...",
"sort_key":"...",
"attribute_1":"...",
"attribute_3":"..."
}
{
"partition_key":"...",
"sort_key":"...",
"attribute_3":"...",
"attribute_4":"..."
}
DynamoDB의 Data Type
- Scalar Types
- 정확히 하나의 값
- 예: 문자열(string), 숫자(number), 이진(binary), boolean, Null
- Keys 또는 index 속성은 문자열, 숫자 및 이진(binary) Scalar 유형만 지원
- Set Types
- 다중 스칼라 값 (Multiple scalar values)
- 예: 문자열 집합(string set), 숫자 집합 (number set and binary set
- Document Types
- 중첩된 속성(nested attributes)이 있는 복잡한 구조
- 예: 목록 및 지도
AWS Global Infrastructure
- 전 세계 여러 AWS 리전 보유
- 각 지역에는 하나 이상의 AZ(Availability Zones)가 존재
- 각 AZ에는 하나 이상의 시설(=Data Centers)
- DynamoDB AWS region 내의 여러 시설 간에 데이터를 자동으로 복제
- 준 실시간 복제(Real-time Replication)
- AZ는 독립적인 장애 Doamin 역할을 함
DynamoDB Consistency(일관성)
- 읽기 일관성(Read Consistency):
강력한 일관성(strong consistency), 최종 일관성(eventual consistency) 및 트랜잭선( transaction) - 쓰기 일관성(Write Consistency):
표준(standard) 및 트랜잭션(transaction)
- 강력한 일관성(Strong Consistency)
최신 데이터
명시적으로 요청해야 함 - 최종 일관성(Eventual Consistency)
최신 데이터 사본을 반영하거나 반영하지 않을 수 있음
모든 작업에 대한 기본 일관성
강력한 일관성(Strong consistency)보다 50% 저렴 - 트랜잭션 읽기 및 쓰기 (Transactional Reads and Writes)
단일 AWS 계정 및 리전 내의 하나 이상의 테이블에서 ACID 지원
강력한 일관된(Strong Consistency) 읽기 비용의 2배
표준 쓰기(Standard Write) 비용의 2배
Strongly Consistent Read vs Eventually Consistent Read
- 최종 일관된 읽기(Eventually Consistent Read): 쓰기 직후에 읽는 경우 복제로 인해 예기치 않은 응답을 받을 수 있음
- 강력한 일관된 읽기(Strongly Consistent Read): 쓰기 직후에 읽어도 올바른 데이털르 얻을 수 있음.
- 기본: DynamoDB는 최종 읽관된 읽기(Eventually Consistent Reads)를 사용하지만 GetItem, Query & Scan은 True로 설정할 수 있는 "ConsistentRead" parameter를 제공
DynamoDB Transactions - 트랜잭션 일관성(transactional consistency)
- 계정 잔액 테이블(AccountBalance Table)
Account_id | balance | Last_transaction_ts |
Acct_21 | 230 | 1562503085 |
Acct_45 | 120 | 1562503085 |
- 은행 거래 테이블(BankTransactions Table)
Transaction_id | Transaction_time | From_account_id | To_account_id | value |
Tx_12345 | 1561483349 | Acct_45 | Acct_21 | 45 |
Tx_23456 | 1562503085 | Acct_21 | Acct_45 | 100 |
- 트랜잭션은 두 테이블 모두에 Write가 되거나 모두 되지 않는 것
DynamoDB Pricing Model
Provisioned Capacity
- 프로비저닝한 용량에 대해 비용 지불 (= 초당 읽기 및 쓰기 수)
- Auto-Scaling을 사용하여 프로비저닝된 용량 조정 가능
- 용량 단위(Capacity Units) 사용:
읽기 용량 단위 (Read Capacity Units(RCUs)) and 쓰기 용량 단위 (Write Capacity Units (WCUs)) - 프로비저닝된 용량을 초과하여 소비하면 Throttling(사용 제한) 발생할 수 있음
- 1년 또는 3년 약정을 통한 할인에 예약 용량(Reserved Capacity) 사용
(100 RCU 및 WCU당 1회 요금 + 시간당 요금 부과)
On-Demand Capacity
- 요청당 비용 지불 (=애플리케이션에서 수행하는 읽기 및 쓰기 요청 수)
- 용량 단위(Capacity Unit)를 프로비저닝할 필요가 없음
- DynamoDB는 증가 또는 감소하는 워크로드를 즉시 수용
- 요청 단위(Request Units) 사용: 읽기 요청 단위(Read Request Units) 및 쓰기 요청 단위 (Write Request Units)
- On-Demand 모드에서는 예약 용량(Reserved Capacity) 사용 불가
- 처리량 계산을 위해 요청 단위(request unit)는 용량 단위(capacity unit)와 동일
- storage, backup, replication, streams, caching, data transfer out은 추가 요금 발생
DynamoDB Throughput
Provisioned Capacity mode
- 용량 단위(Capacity Units) 사용
1 용량 단위 (capacity unit) = 1 요청/초 (request/sec) - RCUs (읽기 용량 단위, Read Capacity Units)
4KB 블록에서 마지막 블록은 항상 반올림
1 강력한 일관된 테이블 (strongly consistent table) 읽기/초 (read/sec) = 1 RCU
2 최종 일관된 테이블 (eventually consistent table) 읽기/초 (reads/sec) = 1 RCU
1 트랜잭션 읽기/초 (transactional read/sec) = 2 RCUs - WCUs (Write Capacity Units)
1KB 블록에서 마지막 블록은 항상 반올림
1 테이블 쓰기/초 (write/sec) = 1 WCU
1 트랜잭션 쓰기/초 (transactional write/sec) = 2 WCUs
On-Demand Capacity mode
- 요청 단위 사용 (Request Units)
계산 목적의 용량 단위와 동일 - RRUs (읽기 요청 단위, Read Request Units)
4KB 블록에서 마지막 블록은 항상 반올림
1 강력하게 일관된(Strongly Consistent) 테이블 읽기 요청 = 1 RRU
2 최종 일관성(Eventually Consistent) 테이블 읽기 요청 = 1 RRU
1 트랜잭션 읽기/초 = 2 RRU - WRUs (쓰기 요청 단위, Write Request Units)
1KB 블록에서 마지막 블록은 항상 반올림
1 테이블 쓰기 요청 = 1 WRU
1 트랜잭션 쓰기 요청 = 2 WRU
Provisioned Capacity vs On-Demand Mode
Provisioned Capacity Mode | On-Demand Capacity Mode |
일반적으로 Production 환경에서 사용 | 일반적으로 개발/테스트 환경 또는 소규모 애플리케이션에서 사용 |
예측 가능한 트래픽이 있을 때 사용 | 가변적이고 예측할 수 없는 트래픽이 있을 때 사용 |
비용 절감을 위해 안정적이고 예측 가능한 트래픽이 있는 경우 예약 용량 사용을 고려 | 테이블에서 이전 최대 트래픽의 최대 2배를 즉시 수용 |
소비가 급증하면 조절(Throttling) 발생 가능 | 30분 이내 이전 Peak의 2배를 초과하면 조절(Throttling) 발생 가능 |
Ondemand Capacity Mode에 비해 비용 효율적 | 2배 이상 driving 하기 전에 최소 30분 이상 Space Traffic 증가하는 것을 권장 |
Example 1: Calculating Capacity Units
15KB Item을 읽고(read) 쓰기(write)위한 용량 단위(capacity units) 계산
- 강력한 일관성(Strong Consistency)의 RCUs:
- 15KB/4KB = 3.75 => 반올림 => 4 RCU
- 최종 일관성(eventual consistency)의 RCUs:
- (1/2) x 4 RCUs = 2 RCUs
- 트랜잭션 읽기용 RCUs:
- 2 x 4 RCUs = 8 RCUs
- WCUs:
- 15KB/1KB = 15 WCUs
- 트랜잭션 쓰기용 WCUs:
- 2 x 15 WCUs = 30WCUs
Example 2: Calculating Capacity Units
1.5KB 항목을 읽고 쓰기 위한 용량 단위 계산
- 강력한 일관성(Strong Consistency)의 RCUs::
- 1.5KB/4KB = 0.375 => rounded up => 1 RCU
- 최종 일관성(eventual consistency)의 RCUs:
- (1/2) x 1 RCUs = 0.5 RCU => rounded up = 1 RCU
- 트랜잭션 읽기용 RCUs:
- 2 x 1 RCU = 2 RCUs
- WCUs:
- 1.5KB/1KB = 1.5 => rounded up => 2 WCUs
- 트랜잭션 쓰기용 WCUs::
- 2 x 2 WCUs = 4 WCUs
Example 3: 처리량(Throughput) 계산
A DynamoDB 테이블에는 10개의 RCU와 10개의 WCU 용량이 Provisioning 되어 있다, Application이 지원할 수 있는 처리량을 계산:
- Read throughput with strong consistency = 4KB x 10 = 40KB/sec
- Read throughput (eventual) = 2 (40KB/sec) = 80KB/sec
- Transactional read througput = (1/2) x (40KB/sec) = 20KB/sec
- Write throughput = 1KB x 10 = 10KB/sec
- Transactional write throughput = (1/2) x (10KB/sec) = 5KB/sec
DynamoDB Burst Capacity
- 간헐적인 Burst 또는 Spike 제공
- 5분 또는 300초 동안의 사용되지 않는 Read 및 Write 용량
- 빠르게 소모 가능
- 의존해서는 안됨.
DynamoDB Adaptive Capacity
- 총 프로비저닝된 용량 = 초당 600 WCUs
- 파티션당 프로비저닝된 용량 = 200 WCUs per sec
- 사용되지 않은 용량 = 200 WCUs per sec
- Hot 파티션은 할당된 용량을 초과하여 이러한 초당 200개 미사용 WCU 소비 가능
- 이 이상의 소비는 조절(Throttling)으로 이어짐
- 비 균일(Non-uniform) 워크로드(Workloads)의 경우 자동으로 작동하며 실시간으로 적용
- 무보증
DynamoDB LSI (Local Secondary Index)
- 최대 5개의 LSI 정의
- 테이블읭 기본 인덱스(Primary Index)와 동일한 파티션/해시 키 속성을 갖음
- 테이블의 기본 인덱스(Primary Index)와 다른 정렬키(Sort Key)/범위(Range Key)가 있음
- 정렬키(Sort Key)와 범위키(Range Key)(=복합키, Composite Key)가 반드시 있어야 함
- Indexing된 항목(Item)은 10GB보다 작아야 함.
- 오직 테이블 생성시에만 생성되며 그 이후 삭제 불가
- 단일 파티션 쿼리만 가능(해쉬키로 지정)
- 최종(Eventual) / 강력(Strong) / Transaction 일관성(Consistency) 지원
- 기본 테이블의 프로비저닝된 처리량을 사용
- 속성(Attributes)이 Index에 프로젝션되지 않은 경우에도 모든 테이블 속성을 쿼리할 수 있음
(전체 또는 최대 20개의 개별 속성을 프로젝션 할 수 있음)
DynamoDB GSI (Global Secondary Index)
- 최대 20개의 GSI 정의 가능 (Soft limit)
- 테이블의 기본 인덱스와 같거나 다른 파티션/해쉬 키를 갖을 수 있음
- 테이블의 기본 인덱스와 같거나 다른 정렬/범위 키를 갖을 수 있음
- 정렬/범위 키 생략 가능(=단순 및 복합)
- 인덱싱된 항목에 대한 크기 제한 없음
- 언제든지 생성하거나 삭제 가능, 하지만 한번에 하나의 GSI만 삭제 가능
- 파티션 전체에 쿼리 가능 (전체 테이블에 대해)
- 최종 일관성(Eventual Consistency)만 지원
- 자체 프로비저닝된 처리량 보유
- 프로젝션된 속성만 쿼리 가능 (Index에 포함된 속성)
When to choose which index?
Local Secondary Indexs | Global Secondary Indexes |
애플리케이션에 테이블과 동일한 파티션 키가 필요한 경우 | 애플리케이션이 테이블과 다르거나 동일한 파티션 키를 필요로 하는 경우 |
추가비용을 피해야 하는 경우 | 애플리케이션에 더 정밀한 처리량 제어가 필요한 경우 |
애플리케이션에 강력한 일관된(Strong Consistency) Index 읽기가 필요한 경우 | 애플리케이션에 최종 일관된(Eventual Consistency) Index 읽기만 필요한 경우 |
DynamoDB Indexes and Throttling
Local Secondary Indexes | Global Secondary Indexes |
기본 테이블의 WCU와 RCU 사용 | 쓰기가 GSI에서 throttle(조절)되면 메인 Table이 Throtle 됨 (메인 테이블의 WCU가 정상인 경우) |
특별한 조절 고려 사항 없음 | GSI 파티션 키를 신중하게 선택 |
WCU 용량을 신중하게 할당 |
Simple design patterns with DynamoDB
- 1:1, 1:N, N:N과 같은 다양한 Entity Relationship을 모델링 할 수 있음
- 플레이어의 게임 상태 저장 - 1:1 모델링, 1:N 모델링
user_id를 PK(기본키)로, game_id를 SK(정렬키)로 1:N 모델링 - 선수들의 게임 이력 - 1:N 모델링
user_id는 PK, game_ts는 SK(1:N 모델링) - 게임 리더 보드 - N:M 모델링
game_id가 PK이고 점수가 SK인 GSI
DynamoDB Write Sharding
- Candidate A와 Candidate B의 두 후보자가 있는 투표 신청서가 있다고 가정
- Candidate_Id의 파티션 키를 사용하면 파티션이 두개뿐이므로 파티션 문제 발생
- 솔루션: 접미사 추가(일반적으로 임의의 접미사(suffix), 때로는 계산된 접미사(suffix))
Error and Exceptions in DynamoDB
- Common Exceptions
- 액세스 거부 예외 (Access Denied Exception)
- 조건부 확인 실패 예외 (Conditional Check Failed Exception)
- 항목 수집 크기 제한 초과 예외 (Item Collection Size Limit Exceeded Exception)
- 제한 초과 예외 (Limit Exceeded Exception)
- 사용 중인 리소스 예외 (Resource In Use Exception)
- 검증 예외 (Validation Exception)
- 프로비저닝 처리량 예외 초과
오류 재시도
지수 백오프
'AWS Database > AWS DynamoDB' 카테고리의 다른 글
[AWS Certificate]-DynamoDB Backup & Restore (0) | 2022.01.09 |
---|---|
[AWS Certificate]-DynamoDB Accelerator (DAX) (0) | 2022.01.08 |
[AWS Certificate]-DynamoDB Storing Larger Item (0) | 2022.01.08 |
[AWS Certificate]-DynamoDB Best Practice (0) | 2022.01.08 |
[AWS Certificate]-DynamoDB Partition (0) | 2022.01.08 |