서버리스 아키텍처를 위한 Amazon DynamoDB (이기백, AWS)

항목 - 기타 속성의 모음. 하나의 행

항목을 구분하는 키 - 파티션키(PK와 유사)

년도 별로 저장할 때 정렬키를 사용해서 저장하면 효율적으로 저장가능.

DynamoDB - 테이블 + 파티션키 + 정렬키 를 사용..

파티션키가 중복이 되는 경우 정렬키를 사용해서 구분

정렬키를 이용해서 각각의 값을 정렬시켜서 데이터를 빠르게 정렬할 때 사용

파티션에 어떻게 저장되는 지는 알수 없다.(blackbox)

문서 모델로 저장...

데이터 항목이 중첩될 수 있다. 중첩은 32단계까지 가능하다.

파티션키만으로 구분이 안되니 시간(정렬키)와 같이 사용해서 항목 구분

최종적 일관성 - 5분 정도 있다가 바로 보여도 된다.

강력한 일관성 - 뱅킹 이체시 관련 데이터가 바로 보여야 한다.

--> DynamoDB는 둘다 지원하고 워크로드에 따라 선택한다.

최종적 일관성을 설정하는 경우. 가용 영역 A 또는 B에서 읽을 수 있다.

강력한 일관성을 설정하는 경우 최종적 일관성 읽기보다 2배정도 느린 성능을 보장.

비용 부과 단위 - 몇GB를 사용(저장)하냐 성능에 대한 비용 청구

성능을 구매해서 사용한다라고 보면 된다.

성능 지정 -

. 프로비저닝 5WCU / 5RCU (Auto Scaling 가능하다)

. 온디멘드 트랜잭션이 들어오는 족족 성능이 늘어나게 할수 있다.

* Query - Scan보다 효율적. 파티션 키를 기반으로 조회.

* Scan - 검색하고자 하는 부분이 속성.

테이블의 성능을 끌어올리는 방법은 - LSI, GSI 가 있다.

로컬보조인덱스 특징

파티션 키가 바뀌는 경우 - 글로벌 보조 인덱스

기존의 원본테이블의 성능을 상속 받지 않는다.

글로벌 테이블 - 다른 리전으로 백업 또는 동기화할 때 사용되는 테이블, 테이블 생성 후 묶는다.

--> 리전에 생성된 테이블 간 데이터 전송을 위한 채널 == 스트림

* 400 오류 - Application 오류. 필수 파라미터 잘못 설정. Provisioning 보다 크게 들어올때.

--> Application 수정 또는 재시도

* 500 오류 - DynamoDB 오류

--> backoff 알고리즘 적용(5초 요청, 이후 10초 후 재시도.. 이후 15초 재시도)를 사용해서 천천히 재시도...

미션 크리티컬한 경우 온디멘드 모드..

비동기식 동기화(복제) <- 스트림을 먼저 활성화해야함.

DynamoDB 성능 개선 2가지 방법

DynamoDB각 ms 정도 보장하는데. DAX를 사용한다면 micros 보장

파티션 키가 매우~~ 중요하다.

파티션에 균등하게 WCU/RCR가 분할된다.

성능을 늘리더라도 핫 파티션에 더 배정되지 않는다.

균등성있는 파티션 키를 사용해야한다.

데이터에 대한 Access 패턴을 고려한다.

데이터를 시간대별로 나눈다.

테이블과 성능을 공유하기 때문에 LSI를 사용해야함.

희소 인덱스(Sparsed Index) - 특정 속성에 값이 있는 항목만 인덱스에서 사용

* 균등성 있는 파티션 키 사용

동시성 제어

내부적으로 lambda함수가 데이터를 가져다가 동기화 대상 테이블에 업데이트

TTL 속성을 사용할 수 있다.

밀도가 높은 dynamodb 항목 -> 그룹화해서 최대한 1K로 맞춘다.