본문 바로가기

aws

(AWS DynamoDB)(NoSQL) 비즈니스에 맞는 스키마 설계



DynamoDB 스키마 설계



먼저 설계에 앞서 알아야할 부분을 말씀드리자면
  • DynamoDB는 NoSQL이고, RDBMS와 NoSQL 설계는 다릅니다.
  • DynamoDB의 경우, 대답해야 할 질문을 알기 전까지는 스키마 설계를 시작할 수 없습니다.
  • 사전에 비즈니스 문제와 애플리케이션 사용 사례를 이해해야 합니다.
  • DynamoDB 애플리케이션에서는 가능한 적은 수의 테이블을 유지해야 합니다. 대부분의 잘 설계된 애플리케이션은 단 하나의 테이블만 요구합니다.
저희 팀이 DynamoDB를 적용하며 스키마 설계단계에서 가장 많은 시행착오를 겪었던 부분이
RDBMS를 설계하던 기존 방식과 다른 방식으로 접근하지 못했던 것이었습니다.

 



 

잘못된 설계의 예시

 

저희 회사 서비스의 일부분을 말씀드리면,
Content Creator (사내에서는 Collector로 명명) 가 있고 그 Creator는 컨텐츠에 모금을 받을 수 있는 배너를 추가하여 
구독자가 암호화폐로 해당 Content Creator에게  송금할 수 있습니다.
이에 따라 필요한 테이블 목록과 스키마를 정의하였습니다.



* PK – PartionKey , SK – SortKey

 

총 3개의 테이블이 필요하고, 복합 키를 사용해야 한다고 판단하였습니다. 
또한 데이터가 객체로 저장되기 때문에 PrimaryKey만 설정해주고 나머지는 속성으로 추가하도록 설계하였습니다.

하지만 위 설계는 AWS 레퍼런스에서 설명했던 잘 설계된 어플리케이션은 하나의 테이블만을 요구한다는 조건에 매우 어긋나고 PrimaryKey의 사용도 잘못된 것이었습니다.

 

 


 

설계 수정

 

설계 수정에 앞서 먼저 AWS에서 제공한 이상적인 설계의 예시입니다.




이 예시를 보며 긴 회의를 거쳐 설계를 수정하였습니다.

 

처음 예시를 보았을 때, 테이블이 하나라는 것과 PK , SK의 사용이 잘 이해되지 않았는데 가장 큰 이유는
PK, SK 밑의 셀에 적힌 HR_EMPLOYEE , OE-ORDER 가 Key의 Name이 아니라, Value 라는 것을 몰랐기 때문이었습니다.

한 테이블에 여러 PK와 SK를 어떻게 설정하느냐는 고민을 하던 저희는 이 사실을 알고난후 모든것이 이해되고 설계 수정이 
빠르게 이루어 졌습니다.

 



수정 후 스키마




PK의 Value값에 따라 Collector를 구분하고 SK의 Value값에 따라 Details정보인지, Remittance 정보인지 구분합니다.

DynamoDB는 PartionKey에 따라서 물리적 Storage가 결정되기 때문에 한 Collector에 관련된 정보는 같은 공간에 저장되어 
데이터 접근이 용이하도록 관리될 것입니다.





마치며


이제 기본적인 테이블 설계는 완료되었습니다.
다음 단계는 비용과 속도를 고려하여 Index, transaction limits 설정 등이 필요할 것입니다.

 




이상으로 포스팅을 마칩니다.
다음에 더 좋은 내용으로 만나요~

99746B455BE9272912 (450×90)
By RyanKim (Overnodes Devloper)