DynamoDB는 AWS에서 제공하는 서버리스 기반의 Key-Value NoSQL이다.
DynamoDB는 실제 서버를 갖지 않고 사용한만큼만 비용을 지불하기 때문에 비용면에서 유리하다.
이러한 특징은 AWS Lambda와 같은 서버리스 서비스와 함께 사용할 때 시너지를 발휘한다.

파티션 키는 물리적인 공간인 파티션을 구분하기 위한 키이다.
동일한 파티션 키를 지닌 데이터는 물리적으로 가까운 위치에 저장된다. 이 경우 데이터를 구분하기 위하여 정렬키를 사용한다.
스케일이 아무리 커져도 주소를 알고 있어 데이터를 빠르게 가져올 수 있다.
파티션 키는 반드시 일치하는 값만 가져올 수 있다.
동일한 파티션 키를 사용하는 데이터를 정렬하기 위한 키이다.
타입으로는 Number, Binary, String 타입을 지원한다.
정렬을 통해 파티션 사이즈가 커져도 데이터를 빠르게 가져올 수 있다. (성능면에서 유리)
파티션 키와 달리 범위를 지정해 검색할 수 있다. 단, 정렬키로만 검색은 안되고 파티션 키와 함께 검색해야 한다.
DynamoDB의 검색은 파티션 키로 파티션을 검색하고, 해당 파티션에서 Sort Key로 데이터를 찾는다.

그럼 해당 테이블에서 Toy Story에 출연한 모든 배우의 데이터를 불러올 수 있을까?
불가능하다.
이는 DynamoDB의 중요한 특성으로 서로 다른 파티션의 데이터를 하나의 쿼리로 불러올 수 없다. 이를 위해 DynamoDB는 보조 인덱스라는 기능을 제공한다.
보조 인덱스는 로컬 보조 인덱스(Local Secondary Index, LSI), 글로벌 보조 인덱스(Global Secondary Index)로 나뉜다.
파티션 키는 동일하지만 정렬 키는 다른 인덱스이다.
같은 파티션에 있다는 점에서 로컬이다.
파티션 키와 정렬 키 모두 다른 인덱스이다.
파티션이 다르므로 글로벌이다.
DynamoDB는 싱글 테이블 디자인을 적극 추천한다. 이유는 RDBMS와 달리 NoSQL의 특성상 JOIN이 불가능하기 때문에 단일 요청으로 한 번에 원하는 데이터를 가져오려는 목적에 기인한다.

따라서 테이블을 하나로 관리하기 때문에 엑세스 패턴에 대한 요청 수도 줄일 수 있고, 여러 테이블에 비해 비용도 절감할 수 있지만 치명적인 단점이 있으니 새로운 엑세스 패턴을 수용하는데 어려움이 있다는 것이다. 테이블만 봐도 느낌이 올 수 있는데, 엑세스 패턴이 변경되는 경우 테이블의 모든 항목을 스캔하고 새 속성으로 업데이트하기 위해 ETL 프로세스를 수행해야 할 수도 있다. 따라서 DynamoDB의 모델링 과정에선 신중한 액세스 패턴 설계가 중요하다.
https://yoo11052.tistory.com/174
https://alphahackerhan.tistory.com/39
https://www.alexdebrie.com/posts/dynamodb-single-table/