[AWS] DynamoDB: 데이터 모델링 방법론

#AWS

DynamoDB에서 테이블 구조를 설계하는 권장사항을 정리해본다.

일반적으로 DB를 설계한다고 하면, 기능/데이터 단위로 테이블을 각각 만드는 경우가 흔하다. 하지만 Dynamo에서는 그러한 형태가 권장되지는 않는다.

엄밀한 의미에서의 관계형 구조와 정합성이 필요하다면 우선 RDB를 사용하길 바란다. DynamoDB는 그런 것을 위한 것이 아니다.

Partition Key와 Sort Key

dynamoDB는 파티션 키와 정렬 키라는 2가지 기본키 단위를 제공한다.
파티션 키는 필수고, 정렬키는 optional 옵션이다.

Unique 제약 단위가 조금 특이한데

파티션 키만 쓴다면 파티션 키를 기준으로 Unique함이 보장된다. 같은 파티션 키의 값은 중복될 수 없다.
파티션 키와 정렬키를 동시에 쓴다면 파티션키+정렬키 기준으로 복합 Unique가 보장된다. 파티션 키가 같아도 정렬 키가 다르면 별개의 데이터로 잘 들어간다.

그래서 그냥 대충 쓴다고 하면 파티션 키를 하나만 두고서 key-value로 단순하게 쓰는 것도 이상한 선택은 아니다.
하지만 뭔가 모델링을 제대로 해서 쓰고 싶다면 정렬 키를 사용해서 관계를 다루는 것이 조금 더 일반적인 방법이다.

뭔가 여러개의 데이터 단위가 있다면, Dynamo는 그것을 한 테이블에 구겨넣는 것을 권장한다.

예를 들면, 이런 식이다.
아래는 각각의 게임 계정이 있고, 계정마다 갑옷, 무기, 로그인 데이터 등 다양한 엔티티 단위를 포함하는 경우의 모델링 예제다.

https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/WorkingWithItemCollections.html
파티션 키가 가장 중심이 되는 데이터 단위의 Unique ID가 된다. 이 경우에는 실질적인 UserID다.

그리고 UserID에 종속되는 데이터들은 모두 정렬 키를 기준으로 별도 row로 저장된다. 여기서는 정렬 키가 각 하위 엔티티 속성을 나타내는 메타 정보가 되었다.

UserID, 그러니까 파티션 키를 기준으로 조회를 하는 경우가 빈번한 사용 패턴이라면, 비용과 성능이 매우 효율적이다.
예를 들어, 특정 UserID에 속하는 Row를 한번에 조회하는 경우가 잦다면 읽기 비용 단위(RCU)가 낮게 잡히고, 한번에 가져오기 때문에 레이턴시도 적다.

근데 UserID 기반의 엔티티 구조는 어떻게 짤 수 있다고 쳐도, N:M 같은 구조는 어떻게 구현해야 할까?
일단, DynamoDB에서는 여러가지 스키마를 다루는 데에 자질구레한 테크닉을 좀 권장하는 편이다.

예를 들면, 이런 식으로 # 같은 구분자를 끼고서 파티션 키를 구성하게끔 하는 것이다.
아래는 user에 대해서 팔로워 관계를 구성한 간단한 예제다.

https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/data-modeling-schema-social-network.html
user 12345의 팔로워라는 파티션 키에, 팔로우한 userID를 sort key 목록으로 저장한 것이다.
좀 이상해보이지만 이런 형태를 권장한다.

위에서 단점으로 꼽았듯이, 관계가 깊거나 복잡하다면 Single 테이블만으로는 감당하기 어렵다.
그런 경우에는 엔티티별로 테이블을 분리하는 수 밖에 없다.

이 경우에 대해서는 달리 설명할 것이 없다.