🎪

DynamoDB Immersion Day - History & How it works

AWS end-to-end Data Strategy

The Amazon NoSQL Journey

DynamoDB

Primary Key(Partition Key + Sort Key)

Global Secondary Index(GSI)

GetItem Consitency

AWS end-to-end Data Strategy

•

집계가 주라고 하면 RDS보다 Redshift가 빠르다…

◦

ROI를 고려해서 Redshift 선택

•

Zero-ETL (’23 2월 기준)

◦

Aurora → Redshift 로 데이터 이동

The Amazon NoSQL Journey

•

NoSQL

◦

관계형 DB의 부족한 부분을 채워주는 역할…

•

DocumentDB

◦

MongoDB와 호환성

◦

Value = JSON

◦

스키마리스

◦

DAX

▪

DynamoDB에 Query를 수행시 Query와 결과를 캐싱 

•

ElastiCache

◦

Redis > memcached

◦

In-Memory DB

•

Neptune

◦

Graph

◦

관계에 대한 정보를 별도로 저장한다.(RDB랑 다른점..)

•

Timestream

◦

Time-Series

◦

수집: 메모리,, 오래된 데이터는 SSD로..

◦

Time window 기반 분석 가능

•

QLDB

◦

BMW  중고차 랩에서 사용

•

Scale-out

•

대용량 데이터, 요청에 관계없이 Scale-out을 통한 안정적인(일정한 성능, ms응답) 서비스 제공
→ DynamoDB 특징

DynamoDB

•

Region Resource

•

집계에 맞지 않을 수 있다.

•

DynamoDB는 OLTP 이다.

◦

OLTP vs OLAP

◦

OLTP - 심플데이터 넣고 빼고

◦

OLAP - 분석, 집계등을 통해 인사이트 도출

▪

OLAP 업무와 맞지 않다.

•

Access Pattern(키) 디자인 잘해야 한다.

•

PartiQL(a SQL-compatible query language)

◦

SQL 처럼 보이는 쿼리

•

백업 지원

◦

Point-in-time recovery(PITR)

▪

최대 35일전까지 복원됨.

▪

매 5분마다 Snapshot

◦

복원시 특정 시점의 데이터를 새로운 인스턴스(테이블)를 생성해서 복원한다.

▪

Snapshot 정보는 아마도 S3에 저장하지 않을까….

▪

복원된다고 기존 테이블에 Overwrite하지는 않는다.

•

DynamoDB Stream 

◦

Lambda 등과 연계 지원

•

CloudTrail을 통한 Audit 지원(API Call)

•

NoSQL Workbench for Amazon DynamoDB

◦

https://www.amazonaws.cn/en/dynamodb/nosql-workbench/

•

Table - Item(row) - Attribute(column)

◦

Table 이 각 독립된 객체이다 = RDB에서 Database 정도 레

◦

Single Table내에서 독립적으로 처리!!

◦

데이터는 DynamoDB 에서 사용하는 JSON형식으로 저장. JSON과 유사하나 Data Type이 있다.

•

테이블 생성시

◦

RCU, WCU의 limit 값보다 작다면 파티션은 1개부터 시작한다!!

•

Table은 3개의 복사본으로 별도 저장!

◦

하나의 Region내 3 AZ 로 복사~

◦

데이터는 10GB 사이즈의 파티션에 저장됨.

▪

AZ가 10Gbps 로 네트워크 연결되어있어.. 

▪

장애 발생시 1초 이내 복구를 위해 10G단위로 세그먼트

•

데이터가 늘어나면… 

◦

파티션이 늘어난다.

•

사용자가 늘어나면… 

◦

파티션마다 처리할 수 있는 용량을 가지고 있다. RCU, WCU

◦

RCU: max limit 3000

◦

WCU: max limit 1000

◦

예> RCU: 500, WCU: 100

▪

파티션이 5개라고 하면 동일하게 나눔. 각각 100 RCU, 20 WCU

◦

하나의 파티션이 Max Limit을 넘게 되거나 10GB 가 넘는경우 

▪

파티션 Split, RCU, WCU용량 even으로 나눠짐.

▪

쪼개진다고 무조건 좋냐??

▪

하나의 파티션으로 처리하는것이 베스트다…. (Max Limit)

▪

파티션이 늘어나면 줄지는 않는다.

•

Bulk로드가 있어 RCU,WCU를 Max Limit을 넘게 설정하고 사용하면

◦

Max Limit 넘는 만큼 Partion Split이 발생한다.

◦

작업 이후 RCU, WCU를 줄이게 되면 줄여진 용량이 Partion에 동일하게 분산된다.

•

Bursting

◦

설정한 용량보다 덜 사용한 것을 사용량이 많은 부분에 사용.

◦

Bursting으로 커버 안되면 Auto Scaling 사용

▪

Auto Scaling

•

Table에 min, max, target utilization

Primary Key(Partition Key + Sort Key)

•

Primary Key = Partition Key + Sort Key

•

Partition Key

◦

Unique Key를 사용하는 것이 데이터가 Even하고 들어간다.~

•

Sort Key

◦

Partition 내에서의 정렬

•

Attribute

Global Secondary Index(GSI)

•

GSI = Materialized View(데이터를 가지고 있는 View)

•

GSI = 20개까지 생성가능.

◦

Eventually Consistence만 가능

•

LSI(Local Secondary Index) = 5개까지 생성가능.

◦

테이블 생성시에만 생성가능
→ Partition Key를 포함(공유)해서 Index 생성

•

Scan vs Query

◦

Scan

▪

전체 데이터를 Full Scan 후 Filtering..

◦

Query

▪

내가 원하는 데이터만 가져온다…

▪

Primary Key 기준으로 조회시 Query.

GetItem Consitency

•

Write할 때 

◦

Master + 1 Replica 사용 후 응답 준다

◦

Transactional Consistence

•

Read할 때 

◦

Eventually Consistence

◦

Strongly Consistence (Eventually Consistence보다 2배 더 많은 리소스를 사용한다.)

•

RCU

◦

1 read/sec 8K

◦

Eventually Consistence 

◦

Strongly Consitence (비용 2배, 4K)

•

WCU

◦

1 write/sec 1K

◦

Standard Consistence

◦

Transactional Consitence (비용 2배, 0.5K)

•

RCU, WCU 제약으로 인해 Item 크기 확인이 필요하다!!

•

RR: Request Router

◦

Table 단위의 Capacity를 먼저 확인한다.
→ 부족하면 Throttling 발생

◦

Read 요청시 해당 데이터가 어떤 파티션에 있는지 알려준다!!