AWS

Amazon DynamoDB Design Pattern

Chaein.P 2022. 5. 15. 20:54

이 포스트는 Amazon DynamoDB Workshop & Labs을 참고하여 정리한 study log 입니다.

Adjacency List Design Pattern

Amazon DynamoDB에서 다대다 관계를 모델링하는 데 유용한 설계 패턴이다. 그래프 데이터를 표현하는데 유용하다. 보통 그래프에서 node가 되는 데이터는 partition key로, 해당 node와 연결된 target node는 sort key로 표현할 수 있다. 이 패턴의 장점은 데이터 중복을 최소화하며 node와 연관되어있는 다른 데이터를 간단하게 query 할 수 있다는 점이다.

Schema Modeling

관계형 모델로 짜여진 영화 데이터를 비정규화하여 DynamoDB의 테이블 형식으로 바꿔보자.

1. Common Access Pattern 찾기

RDBMS 정규화 과정을 거칠 때 가장 먼저 비즈니스 로직을 정리해 테이블과 아이템을 추려내는 것처럼 DynamoDB 모델링을 할 때에는 일반적으로 가장 자주 사용된 접근 패턴을 정리해야한다.

accessPattern example

2. partition key, sort key 설정

아래는 영화 데이터 정보가 담긴 관계형 데이터 Schema이다.

IMDB Movie data schema

위 이미지를 보면 title_basics의 tconst가 모든 테이블을 연결하고 있다. 따라서 tconst 가 partition key가 된다. 그리고 sort key로 관계형 테이블의 관계를 표현해줄 수 있다. 예를 들어 title_principals는 영화 제작자/배우들의 정보를 가지고 있다. 이 테이블의 row는 DETL이라는 prefix를 붙여 나머지 정보를 item으로 추가할 수 있다. 개봉 지역 정보를 담은 title_akas 테이블은 REGN이라는 prefix를 붙여 sort key로 사용하고 row 정보는 item으로 추가한다.

3. GSI 설정

common access pattern 6번을 보면 actor와 년도를 기준으로 영화들을 검색하고 있다. 영화 크루 정보를 담은 title_principals와 해당 크루의 상세 정보를 담은 name_basics 테이블은 nconst라는 pk로 연결되어있다. 이 nconst를 partion key로 년도를 sort key로 하는 GSI를 설정한다.

DynamoDB Modeling 주의해야할 점

  • 정규화하지 말 것, 정규화는 서로 다른 테이블을 조인해야하고 조인은 쿼리 성능을 악화시킨다. 조회 성능이 가장 큰 장점인 DynamoDB에는 정규화가 적합하지 않다.
  • 하나의 테이블에 하나의 entity만 담지 않을 것, User, Game, UserGameMapping이라는 entity가 있다면 RDBMS에서는 각 entitiy가 모두 다른 테이블이었겠지만 DynamoDB에서는 하나의 테이블에 담을 수 있다.
  • Secondary Index를 남용하지 말것, 꼭 필요한 상황이 아니라면 단일 보조 인덱스만으로도 여러 데이터 속성을 쿼리할 수 있다.

Primary Key 디자인 best practice

  • 하나의 테이블에 위치한 서로 다른 entity들을 파악한다. primary key는 각 entity를 구분해주는 역할을 할 수 있다.
  • entity type을 구분하기 위해 prefix를 사용한다. ex. CUSTOMER#customerID, EMPLOYEE#employeeID
  • single-item 쿼리에 집중해 설계한뒤 multiple-items 쿼리가 필요하면 secondary index 를 활용한다.