RDS/DDS (Dynamo DB) / 데이터베이스 캐싱

DB_intro

AWS의 관리형 데이터베이스와 비관리형 데이터베이스 차이

DB_managed_not_managed

완전 관리형 데이터베이스인 경우는 사용자는 쿼리 최적화에 신경쓰면된다.!

Amazone Aurora

완전 관리형, 관계형 데이터베이스로 MySQL과 PostgreSQL과 호환된다. - MySQL 처리량의 최대 5배, PostgreSQL의 처리량의 최대 3배까지 처리 - 오픈소스이면서 상용수준의 performance를 내는 것이 목적이다. - 자동으로 3개의 가용 영역에 6개의 복제본을 생성한다. 이런 이유로 생성시 multi AZ를 선택하는 옵션이 없음. - DB도 내부적으로 EC2 기반으로 만들기 때문에 생성시 알아서 EC2를 생성하고 그 위에 올려준다.

DB_aurora DB_rds_security

Dynamo DB

완전관리형, 비관계형 데이터베이스 - 이벤트 중심 프로그래밍 (서버리스 컴퓨팅) - 특별한 설정을 하지 않으면 최종적 일관된 읽기를 사용한다.
- 최종적 일관된 읽기 (Eventually Consistent Read)
  
  ex. 게임해서 순위가 정해지는데 이겼는데 순위가 아직 안바껴 있고 다시 조회하면 바껴있는상황.
- 강력한 일관된 읽기 (Strongly Consistent Rad)

DB_dynamodb_security

DynamoDB 특징

DB_ddb_partition

Record가 아닌 Item (항목) 으로 표현한다.
Colume을 Attribute (속성)으로 표현한다.
PK : Partition Key (Primary Key와 같은 역할을 한다. )
복합 키를 마들때 SK ( Sort key) 와 조합하여 사용될 수 있다.
테이블 데이터는 파티션 키에 따라 파티션에 저장된다.
DDB 는 내부적으로 분산환경으로 작동하는데 그렇기 때문에 읽기 및 쓰기의 일관성을 알아보자.

C + P (Consistency + Partitioning) = 강력한 일관성 제공

⇒ 복제본 3개가 있는 경우, 업데이트가 일어나면서 다른 트랜잭션에 값을 요청하는 경우, 항상 최신값으로 응답하는 것을 보장한다.! → 여러 차례 질의하기 때문에 비용이 더 든다. 1 RCU

A + P (Availability + Partitioning) = 최종 일관성 제공

⇒ 복제본 3개가 있는 경우, 업데이트가 일어나면서 다른 트랜잭션에 값을 요청하는 경우, 아직 업데이트가 되지 않은 인스턴스에서 응답을 하는경우 업데이트된 값이 아닌 옛날값이 돌아올 수도 있다 !! → 0.5 RCU → 특별한 설정을 하지 않으면 DDB의 default이다.

성능

DB_ddb_rcu_wcu

→ 5KB를 읽어온다고 하였을 때, C+P 의 경우 4 + 1 이니까 총 2RCU가 나오고, A+P의 경우 1RCU가 된다.

만일 완전 서버리스로 만든다면 ?
1. 람다 : 컴퓨팅
2. ddb : db서버
3. s3 : obj storage
4. fargate : container

보조 인덱스

보조 인덱스로 쿼리를 할 수 있는데 보조 인덱스의 유형은 다음 두개로 나뉜다.
1. 로컬 보조 인덱스 (Local Secondary Index : LSI)
  - 파티션 테이블에도 PK를 동일하게 가는 경우
  - 어느 테이블에 요청이 가도 요청 카운트를 합산한다.
2. 글로벌 보조 인덱스 (Gobal Secondary Index : GSI)
  - 원본 테이블의 보조 인덱스가 파티션 테이블의 PK가 된다.
  - PK가 다르기 때문에 요청 카운트를 달리 센다.

DB_ddb_local_index DB_ddb_global_index

DDB API

PutItem : 없으면 생성, 있으면 overwrite.
GetItem
UpdateItem : Upsert로 동작한다. 있으면 업데이트 없으면 생성.
DeleteItem
Scan → Select와 비슷하지만 모든 항목, 인덱스를 읽기 때문에 상용에서는 사용하지 않기~
BatchGetItem, BatchWriteItem
- 1 ~ 10까지 작업하고 get을 시켰을때 5번이 중간에 죽어도, 독립된 실행단위이기 때문에 모두 실행하고 최종 결과를 알려주게 된다.
TransactionGetItems, TransactionWriteItems
- 1 ~10까지 작업목록을 주고, 진행중에 문제가 생기면 모두 롤백된다.

DDB를 효율적으로 사용하는법~

콜드 데이트와 핫 데이터

분기별로 더 이상 접근이 많이 되지 않는 아이들은 여러 테이블들로 쪼개서 해 놓는다. 테이블의 개수에 따른 비용이 발생하는 것이 아니라, 얼만큼 데이터가 들어있는냐가 좌우한다.

전용 캐시 (Daynamo DB Accelorator : DAX)

만일 키가 없으면 ( TTL 만료로 ?) 알아서 ddb에게 물어보고 값을 가져오고 자기 자신에도 저장하는 역할을 한다.

LSI

partition key 가 원본 테이블과 같음
생성시점은 원본 테이블이 생성될때 함께 생성된다.
성능은 rcu, wcu를 원본 테이블과 공유한다.

GSI

원본테이블과 다름(보조인덱스사용)
생성시점은 제약이 없다
rcu, wcu 새롭게 할당
최종일관성만 제공한다.

스트림

ddm의 스트림!! 다이나모디비에는 전용 스트림이 있다.
a:1, b:2 c:3 이렇게 잇을때 put을 할때 테이블에 변경이 일어나면, 스트림이 변경사항을 자동으로 기록하게 되어잇다. (default로 비활성화 되어있다.) 쌓인 데이터는 24시간이 지나면 없어진다.
람다의 트리거가 될 수 있다.
글로벌 테이블을 트리거 할 수 있다.
- 서울, 도쿄, 싱가폴에 동일한 테이블이 3개가 있다고 했을때, 스트림을 모두 켜놓았다. 연결되어 있는 이런 글로벌 테이블에게 변경되어 있는 내용을 싱크시켜주는 기능이다.