DynamoDB도 DB인 만큼 데이터에 기준을 기본키(Primary Key)가 존재하는데 기존 RDBMS와는 좀 다르다.
DynamoDB의 기본키
DynamoDB의 기본키는 2가지로 나뉜다.
- PK - 하나의 Partiton Key
- PK + SK - Partiton Key 와 Sort Key의 조합
PK ( Partition Key )
PK는 DynamoDB에서 각 테이블에 실제 데이터가 어떠한 파티션으로 위치할지를 결정해주는 키라고한다.
각 테이블에서 데이터가 들어올때 AWS의 내장된 해시함수를 통해 해당 테이블에 할당된 파티션에 자동으로 분배해준다.
해당 파티션은 AWS에서 각 상황에 따라 자동으로 수를 조절해주는데 대표적인 상황으로는 2가지다.
- 특정 파티션에 들어오는 요청량이 파티션의 처리량을 넘어설 경우
- 특정 파티션의 용량이 허용치를 넘어선 경우
첫번째 경우의 파티션의 처리량 같은 경우에는 AWS 공식 사이트에 적힌 바로는 3000RCU , 1000WCU라고한다.
RCU WCU??
RCU - Read Capacity Unit, WCU - Write Capacity Unit
해당 단위는 AWS DynamoDB의 읽기 처리량, 쓰기 처리량을 나타낸다.
이 처리량은 데이터의 크기에 따라 결정되는데 대략적으로 4KB데이터가 있다고 할 때 1RCU로는 하나의 강력한 일관성 읽기 작업을 지원해주거나, 두개의 최종적 일관성 읽기 작업을 지원해준다.
1WCU 같은경우는 초당 1KB 데이터에 대해 쓰기 작업을 지원해준다.
예를 들어서 400KB 데이터가 있고 강력한 읽관성 읽기를 하는 상황에서 해당 데이터는 초당 100RCU를 소모하게된다. 하나의 독립된 파티션이 최대 3000RCU를 지원해준다고 하니 이 데이터의 경우 초당 최대 30개의 데이터를 읽을 수 있다는 것이다.
이렇게 특정 파티션이 가능한 처리량을 넘기면 자동으로 늘려서 재분배 시켜준다는.. 것으로 보인다.
- 강력한 일관성 - 모든 업데이트된 데이터를 즉시 읽어올 수 있음
- 최종적 일관성 - 모든 업데이트된 데이터를 읽더라도 즉시 반영은 안되지만 시간이 지나면 최종적으로는 업데이트 반영분이 적용됨
두번째 경우의 파티션 각 용량은 최대 10GB 까지 저장을 한다고 한다.
-> 다만 AWS 관계자분이 특정 파티션에 용량이 몰리게 된다면 DynamoDB 내부에서 또 자체적으로 메타데이터를 이용해서 해당 파티션을 또 나눠주는 작업이 백그라운드에서 이루어지기에 실상황에서 용량으로 인해 크리티컬한 상황은 피할수있다고한다.
특정값이 단일 PK에 몰리게되면 앞서 말한 처리량을 넘게되는 상황이 오고 그러면 당연히 AWS에선 처리못한다고 에러를 뱉어내게된다.
이렇듯 DynamoDB에서 PK는 어떤 값을 설정하냐에 따라 운영상황에서 효율적이냐 효율적이지 않냐를 결정하는 값 이기 때문에 설계단계부터 PK값을 잘 설정해줘야한다.
파티션 키 설계를 위한 권장 사항
- PK는 카디널리티가 높은 속성
PK는 각 데이터마다 파티션에 골고루 분배되어야한다. - PK를 복합키로 설정
customerid#productid#countrycode 처럼 #를 구분자로 두어 PK를 여러 속성의 조합으로 설정한다. - DAX를 활용
AWS DynamoDB에서 제공해주는 캐시의 일종인 DAX를 활용하면 특정 읽기작업이 많은 항목을 캐시하여 리소스를 아끼는것도 좋은방법이라고 한다.
->하지만 실제 관계자의 얘기로는 아직까진 DAX보다는 Elastic Cache 쪽에 대한 사용을 권장하고있다고한다. - 작업이 많아질 경우 PK에 랜덤한 숫자를 적는다.
https://aws.amazon.com/ko/blogs/database/choosing-the-right-dynamodb-partition-key/ 공식 사이트에서도 고려해볼만한 방법이라고 한다.
물론 난수로 할 경우 난수의 범위만큼 해당 데이터를 접근하기 위해 추가적인 쿼리를 하게될테니 이 또한 고려해야한다.
DynamoDB의 기본키는 아무래도 기존 RDBMS의 기본키와 많이 다르기에 잘 사용하려면 설계 단계부터 고려해야할 상황이 많은거같다.
