Table of content
1. 테이블
-
데이터 레코드의 집합
2. 항목(Item)
-
테이블에 있는 하나의 레코드 자체를 의미
3. 속성(Attribute)
-
기본적인 데이터 요소로 더 이상 나뉠 수 없는 것, 항목의 조각
-
속성에 대한 내포 속성은 32 깊이 까지 허용
-
대부분의 속성은 스칼라(하나의 값만 가질 수 있음)다.
4. primary key
DynamoDB의 PK는 두가지로 구성이 되어 있다.
출처 : https://aws.amazon.com/ko/blogs/database/choosing-the-right-dynamodb-partition-key
4.1 Partition Key
-
하나의 속성으로 구성되는 단순 기본 키
- Partition Key의 설계에 따라 데이터의 분산도가 달라진다.
-
Partition Key 선택 기준 (ex. 고객ID, 디바이스 ID, 모델 번호 …)
-
고유 값이 가장 많은 속성
-
균일한 비율로 무작위로 요청되는 속성
-
4.2. Sort Key (Range Key)
-
Partition Key와의 조합으로 복합 Primary Key를 구성할 수 있으며, 이를 이용하여 보다 유연하게 DynamoDB에 대한 요청을 처리할 수 있다.
-
Sort Key 선택 기준
-
1:n, M:N 관계 모델링
-
효율적 / 선택적 조회
-
범위 조회
-
5. Secondary Index
- Primary Key(Hash Key)만으로 DynamoDB에서 원하는 데이터에 대한 요청을 처리하는 것에 대해 비효율적인 엑세스 패턴이 발생할 수 있다.
- 이를 방지하고자 테이블에 대해 다른 엑세스 패턴을 설계할 수 있는 Secondary Index개념이 존재하며, RDB개념에서 "View"개념과 비슷하다.
- Secondary Index에는 GSI(Global Secondary Index) LSI(Local Secondary Index)가 존재한다.
- GSI의 default limit 개수는 20이다(Support Center를 통해 증가 요청 가능).
- LSI의 default limit 개수는 5이다.
|
GSI(Global Secondary Index) |
LSI(Local Secondary Index) |
키 속성 |
|
|
파티션 키 당 인덱싱 크기 제한 |
|
|
읽기 일관성 |
|
|
프로비저닝된 처리량 소비 |
|
|
프로젝션 |
|
|
6. WCU, RCU
- AWS의 기본 사상은 "쓰는만큼만 지불"하는 개념이다. 이 개념은 DynamoDB에도 그대로 적용되며, 읽기 및 쓰기하는 용량에 따라서 과금의 정도가 다르다.
- 읽기에 대한 용량을 RCU(Read Capacity Unit)라 부르고, 쓰기에 대한 용량을 WCU(Write Capacity Unit)라고 부른다.
- 프리티어로 25 WCU, 25 RCU가 제공된다.
- ex) 테이블 25개 생성, 각 테이블 별로 1 RCU, 1 WCU의 프로비저닝 된 용량을 할당 -> 총 25 RCU, 25 WCU Free Tier Limit을 넘지 않음
- ex) 테이블 2개 생성, 각 테이블 별로 15 RCU, 15 WCU의 프로비저닝 된 용량을 할당 -> 총 30 RCU, 30 WCU Free Tier를 제외한 나머지 5 RCU 및 5WCU에 대해 과금
6.1. RCU (Read Capacity Unit)
읽기의 경우, Default로 최종적 일관된 읽기가 적용된다.
-
최종적 일관된 읽기의 경우, 1RCU = 8 KB / s
-
강력한 일관된 읽기의 경우, 1RCU = 4 KB / s
6.2. WCU (Write Capacity Unit)
-
1 WCU = 1 KB / s
-
계산시, 1KB 단위로 올림하여 계산한다.
ex) item 크기가 3.6KB 항목 하나를 쓸 경우, 4KB로 계산하며, 4WCU를 소비한다.
6.3. 참고 - 일관성
최종적 일관된 읽기(Eventual Consistent Read)
테이블을 읽을 때, 응답은 최근 완료된 쓰기 작업의 결과를 반영하지 않을 수 있다. 그러므로, 응답에는 부실 데이터가 일부 포함될 수 있다.
강력한 일관된 읽기(Strongly Consistent Read)
성공한 모든 이전 쓰기 작업의 업데이트를 반영하여 최신 데이터를 기반으로 응답을 반환한다. 그러나 DynamoDB에서 이를 적용하면 다음과 같은 단점을 수반한다.
- 강력한 일관된 읽기는 최종적 일관된 읽기보다 지연 시간이 더 길 수도 있습니다.
- 글로벌 보조 인덱스에서는 강력히 일관된 읽기가 지원되지 않습니다.
- 강력한 일관된 읽기(strongly consistent read)는 네트워크 지연 또는 중단이 발생한 경우에 사용이 어려울 수 있습니다. 이 경우 DynamoDB는 서버 오류(HTTP 500)를 반환할 수도 있습니다.
7. 참고 문헌
-
https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/HowItWorks.html
-
https://www.slideshare.net/awskorea/nosql-elasticahe-dynamodb-aws-aws-devday2018
- https://aws.amazon.com/ko/blogs/database/choosing-the-right-dynamodb-partition-key/
'IT > NOSQL' 카테고리의 다른 글
[MongoDB] Timeseries Collection에 대한 연구 (1) | 2022.03.17 |
---|---|
[MongoDB] MongoDB Performance를 향상시키는 전략 (0) | 2021.09.22 |
[DynamoDB] Secondary Index 설계원칙 및 고려사항 (0) | 2020.02.18 |
[DynamoDB] Partition Key 설계 원칙 및 고려사항 (0) | 2020.01.23 |
NoSQL vs RDS (0) | 2019.11.19 |