DynamoDB와 DynamoDB Accelerator(DAX) 정리

 

 

 

 

 

DynamoDB VS RDB 용어 및 개념 비교

 

 

RDB	DynamoDB
Tables	Tables
Rows	Items
Columns	Attributes
Primary Keys(Optional)	Primary Keys(Mandatory / Minimum One and Maximum Two Attribtues)
Indexes	Local Secondary Indexes
Views	Global Secondary Indexes

 

• Strict Schema VS Flexible Schema
• Predefined set of columns VS Unstructured data
• Each record has same number of columns VS Different records can have different number of columns
• Enforces strict ACID properties/Loss of flexibility VS Trades some ACID properties/Flexible data model
• Vertical Scaling/You scale by adding more power(faster hardware,CPU,RAM) VS Horizontal Scaling/You scale by adding more machines,partitions or low-cost hardware

 

 

 

읽기 정합성(Read Consistency)

• Strong Consistency(강력한 일관된 읽기) : 정확한 최신 데이터 제공
• Eventual Consistency(최종적 일관된 읽기) : 최신 반영이 안되있을지도 모르는 데이터, Strong Consistency에 비해 50% 저렴하다.

 

데이터 핸들링

1. Item-based Actions : 하나의 Item에 대해 write,delete,update 가능
2. Query : Read-only action, 한번의 요청으로 여러 Item 처리 가능
3. Scan : 모든 Item을 보는 기능, 고비용으로 사용을 최대한 지양해야함.
4. Primary Key, Sort Key로 Access Pattern을 만족할 수 없을때 Secondary Index를 사용한다.

 

 

 

 

 

용량 유닛(Capacity Unit)

• Capacity Unit : 1초당 읽거나 쓸 수 있는 데이터의 단위
• RCU / WCU

 

RCU : Read Capacity Units

1RCU : 초당 1번의 Strongly Consistent Read 혹은 초당 2번의 Eventually Consistent Read

=>1RCU로 초당 4KB까지 읽을 수 있다.

 

WCU : Write Capacity Units

1WCU : 최대 1KB 데이터 쓰기 용량

 

• RCU/WCU 예시

초당 10KB data를 읽는 RCU(Strong Consistency) : 10KB/4KB = 2.5 ⇒ rounded up ⇒ 3 RCUs

초당 10KB data를 읽는 RCU(Eventually Consistency) : 3 RCUs X 0.5 = 1.5 RCUs

초당 10KB data를 쓰기 위한 WCU : 10KB/1KB = 10 WCUs

초당 1.5KB data를 쓰기 위한 WCU : 1.5KB/1KB ⇒ 1.5 ⇒ rounded up ⇒ 2WCUs

 

 

• DynamoDB에서는 1 Paritition 당 1000 WCUs 혹은 3000 RCUs를 처리 - WCU, RCU 조정값에 따라 몇개의 파티션이 생성될지 알 수 있다.

 

[예시]

Provisioned Capacity : 500 RCUs and 500 WCUs

⇒ Number of Partitions ⇒ 500 RCUs/ 3000 + 500 WCUs/1000 = 0.67 ⇒ rounded up ⇒ 1 partition

New Capacity : 1000 RCUs and 1000 WCUs

⇒ Number of Partitions ⇒ 1000 RCUs/3000 + 1000 WCUs / 1000 = 1.33 ⇒ rounded up ⇒ 2 partitions

 

 

 

 

Local Secondary Indexes

• Local Secondary Index는 테이블 생성시 생성해주어야한다.
• 테이블당 5개까지 생성가능하다.
• 선택 기준

⇒ 같은 파티션키 사용이 요구될때 Sort Key를 수정하고싶을때

⇒ 추가적인 비용을 줄이고 싶을때

⇒ Strongly consistent index read가 필요할때(Strongly Consistent,Eventually Consistent Read 둘다 지원함)

 

Dept(Partition Key)	Emp Id(Sort Key)	Name	Age	Location	DOJ(Secondary Sort Key)
Training	1	Steve	26	SFO	08-03-2018
IT	2	Chris	24	NYC	18-02-2018
Sales	3	Tina	25	NYC	15-02-2018
Training	4	Bill	27	NJ	01-02-2018
IT	5	Alan	26	SFO	12-01-2018
Sales	6	Megan	24	NYC	01-01-2018

 

만약 위 테이블에서 DoJ에 Local Secondary Index를 적용한다면 IT부서에 일하고 있는 인력들의 리스트를 DoJ가 정렬된 형태로 만들 수 있다.

 

 

 

 

Global Secondary Indexes

• 파티션으로부터 독립적으로 보관되어 언제든지 생성가능하다.
• 테이블당 20개까지 생성가능하다. (19년도에는 5개까지 됬던듯.)
• Strongly Consistent read는 지원하지 않는다.
• duplicate item 가질 수 있음
• 선택 기준

⇒ 같거나 다른 파티션키 사용을 필요로 할때

⇒ 세밀한 throughput 통제가 필요할때 혹은 다른 partition key로 query해야 할 때

⇒ consistent index read가 필요할 때

 

Dept(Partition Key)	Emp Id(Sort Key)	Name	Age	Location(Seondary Partition Key)	DoJ(Seconary Sort Key)
Training	1	Steve	26	SFO	08-03-2018
IT	2	Chris	24	NYC	18-02-2018
Sales	3	Tina	25	NYC	15-02-2018
Training	4	Bill	27	NJ	01-02-2018
IT	5	Alan	26	SFO	12-01-2018
Sales	6	Megan	24	NYC	01-01-2018

 

만약 Location에 Global Secondary Index가 걸려있다면 ‘NYC’에서 일하는 인력들을 출력할 수 있을 것이다.

 

 

 

DynamoDB Accelerlator (DAX)

• In-Memory Caching Service
• Microsecond Latency
• Eventual Consistency Read만 가능
• Application과 DynamoDB 사이에서 proxy 역할

(Write 시)

DynamoDB에도 데이터를 쓴 후 DAX에도 데이터를 return해줌.

 

(Read 시)

[Cache Hit] : DAX가 데이터 가지고있을때 DynamoDB로 가지않고 바로 리턴

[Cache Miss] : DynamoDB로부터 데이터 리턴, update된 index Master Node에 반영

 

DynamoDB 적용 의사결정

 

규모가 매우 큰 데이터의 경우 RDB는 Cluster/Division 나누는 작업이 필요하지만 DynamoDB는 그에반해 latency가 적다.

Key 설계시 Single Table로 관리하면서 JOIN이 많이 발생하는 결과물을 빠르고 쉽게 가져쓸 수 있는 경우,페타바이트 규모의 데이터/트래픽이 많이 발생하는 경우 적용하기 좋다. 따라서 DB의 Size가 커진다면 DynamoDB가 유리하지만 국내에서 그정도 규모의 트래픽을 받는 회사는 매우적다.

한편 DAX 캐싱의 경우 도쿄 region만 제공되기에, ap-northeast-2 region의 EC2에서 도쿄 region의 DAX를 바라보는 구조는 네트워크 비용 + latency가 발생할 것으로 예상됨.

 

 

Udemy 강의자분께서 DynamoDB 사용해본 경험을 공유해주셨다.

하루에 50GB 처리 및 2백만 READ/WRITE 연산이 발생하는 SASS Service의 Trouble Shooting 사례는 다음과 같다.

⇒mysql 하나만 쓰다가 Database Lock 빈번하게 문제발생 ⇒ RDS DB로 하드웨어 업그레이드

⇒고객증가로 다시 Lock 문제 발생 => 데이터베이스 multi AZ 리플리케이션 적용 및 Read Replica 적용

⇒고객증가하니 또 문제 생김 ⇒ NOSQL dynamodb 전환하였더니 3년정도 운영하면서 사소한 문제도 잘 안생겨서 다른 서비스에서도 우선적으로 사용중이심.

 

 

Reference

 

https://www.udemy.com/course/dynamodb/

https://dynobase.dev/dynamodb-read-consistency/

https://velog.io/@soongjamm/Eventual-Consistency-란

https://blog.kico.co.kr/2022/03/17/aws-dynamodb/

https://www.youtube.com/watch?v=I7zcRxHbo98&ab_channel=AmazonWebServicesKorea