[DynamoDB] Partitions
DynamoDB는 aws에서 제공하는 schemaless인 nosql형식의 데이터베이스이지만, 완전히 schemaless이지는 않습니다. 그 이유는 유저가 DynamoDB에 테이블을 생성하려고 할때, 파티션 키(partition key) 라는 primary key를 꼭 생성해주어야 하기 때문입니다.
DynamoDB에는 2종류의 primary key가 있는데, 하나는 simple primary key로, 파티션 키로만 구성된 키를 말합니다. 아래의 테이블은 simple primary key의 예제입니다.
또 다른 primary key로는 composite primary key 라고 불리는 키로, 파티션 키와 정렬 키(sorting key)로 이루어져 있는 키입니다. 아래의 테이블은 composite primary key의 예제입니다.
DynamoDB 테이블에 아이템에 관한 요청이 들어올때, 가장 먼저 요청을 처리하는 곳은 request router라고 불리우는 frontend service입니다. 이 request routere는 직접 데이터를 저장하는 고은 아니고, 요청이 들어오면 해당 테이블과 파티션의 metadata를 읽고, 파티션 키를 hasing한 후, 해당 hashed value를 기준으로 알맞는 파티션에 요청을 보내는 역할을 합니다. 아래의 그림은 PutItem 요청이 들어왔을때, request router의 동작원리를 시각화한 것입니다.
DynamoDB가 요청을 받고 파티션 키를 hash하는 이유는, partition을 hash값으로 고르게 나눔으로써, hot partition을 방지하고자하기 때문입니다.
* Hot Partition이란, 다른 파티션들보다 특정 소수의 파티션에 요청이 몰려서 throttling이 발생하는 경우를 의미합니다.
DynamoDB로 들어오는 요청들이 hashing이되고 나면, request router가 해당 요청의 partition을 찾는데 걸리는 time complexity 는 O(1)입니다.
이렇게 hash에 의한 partitioning은 horizontal scaling에서 아주 큰 장점이 되는데, 아무리 많은 파티션이 존재한다 해도, request router는 O(1)이라는 엄청난 속도와 정확성으로 파티션을 찾고, terabyte 단위의 데이터가 와도 이를 파티션의 최대 저장용량인 10GB로 쪼개서 저장함으로, 큰 데이터를 손쉽게 다룰수 있는 사이즈의 데이터로 분리해서 저장합니다.
Adaptive Capacity
DynamoDB에서 하나의 파티션에 provisoned된 RCUs나 WCUs를 넘을시, throttling이 발생하게 되는데요, 이러한 throttling을 방지하고자 2018년 DynamoDB는 adaptive capacity라는 개념을 소개합니다. 이는 위에서 설명한 hot partition으로 인한 throttling을 DynamoDB측에서 자동으로 해결해주기 위해 만들어진 개념으로, adaptive capacity는 모든 테이블에 자동으로 활성화가 되어있습니다.
Adaptive capcity는 각 파티션에 동등한 양의 RCU와 WCU를 프로비져닝하기 보다는 다른 파티션보다 더 많은 양의 요청을 수행하는 hot partition에 더 많은 RCU와 WCU를 다른 파티션들로부터 재분배 함으로써, throttling을 발생시키지 않고, 계속해서 read나 write 과같은 요청을 수행할 수 있게 도와줍니다. 아래의 그림은 adaptive capacity의 동작원리 입니다.
위의 그림에서 볼 수 있듯이, 해당 테이블의 Total provisioned capcity 는 400WCUs이고, 각 파티션들은 동등하게 100WCUs를 가지고 있습니다. 하지만 Partition4가 150WCUs의 요청을 받게 되면서 원래 provisioned된 100WCUs를 넘어가 hot partition이 되었고, 여기서 adaptive capcity가 Partition4가 남은 작업을 위해 필요한 50WCUs를 다른 파티션들로부터 가져와서 throttling을 발생시키지 않고 작업을 수행하게 도와줍니다.
Adaptive capcity는 하나의 파티션에 최대 3,000 RCUs나 1,000 WCUs 요청이 왔을때만 동작하고, 이를 넘을시에는 throttling을 피할 수 없게 됩니다.
만약 하나 이상의 item에 너무 많은 요청이 계속적으로 들어온다면, adaptive capcity는 해당 item들을 각각의 다른 파티션으로 옮겨서 해당 item들 때문에 파티션에 throttling이 걸리지 않게 도와줍니다. 따라서 만약 당신의 application이 하나 혹은 하나 이상의 frequently accessed item이 있다면, adaptive capcity는 해당 item들을 각각의 다른 파티션들로 배정하면서, 최대한 throttling을 방지할 것입니다.
하지만, 위에서도 말했듯이, 이렇게 frequently accessed item을 isolate한 파티션에 3,000 RCUs나 1,000WCUs를 초과하는 요청이 들어온다면, throttling은 피할 수 없고, 이런 경우는 파티션키를 변경하는 방법 밖에는 없습니다.
따라서, throttling을 방지하기 위해서 adaptive capcity의 역할도 크지만, 테이블을 생성할 때, 아이템들이 각각의 파티션에 고루 분배될 수 있게 해줄 적절한 파티션 키를 찾는게 가장 중요합니다.
References
Best Practices for Designing and Using Partition Keys Effectively - Amazon DynamoDB
Best Practices for Designing and Using Partition Keys Effectively The primary key that uniquely identifies each item in an Amazon DynamoDB table can be simple (a partition key only) or composite (a partition key combined with a sort key). Generally speakin
docs.aws.amazon.com
Everything you need to know about DynamoDB Partitions
Understanding DynamoDB partitions will make you a better user of DynamoDB. In this post, you'll learn how DynamoDB partitions work and how they should affect your data modeling.
www.alexdebrie.com