AMAZON DynamoDB 키 디자인 패턴

• DynamoDB는 해쉬함수를 적용해서 파티션을 나누어서 알아서 저장함

키 디자인 시 고려해야할 DynamoDB의 제약 조건

• 어플리케이션의 필요에 따라 읽기 일관성을 충분히 고려해야함

• DynamoDB는 하나의 로우에서 하나의 글자만 바뀌어도 전체를 바꾸기 때문에 아이템 크기는 줄이고 갯수를 늘리는게 좋음

• RDBMS는 쿼리 or ORM을 이용하지만 NoSQL은 API를 이용하여 데이터를 가져옴

Secondary Index

Modeling Tenet

• Entity 별로 테이블 만드는거 아님 NoSql은 하나의 테이블로 시작

• 테이블 갯수는 최대한 줄이는게 좋다

• NoSQL의 키 디자인은 10명이 디자인하면 10명 다 다르게 나옴(RDBMS는 규칙이 있어서 비슷하게 나오지만) → 그래서 Review, Repeat, Review …

• RDBMS는 데이터 액세스 보다는 정규화에 초점을 맞춤
• 디스크 가격이 비싸서 용량을 적게 차지하기 위해서

정규화, 비정규화

• #을 이용해서 복합키 만들 수 있음

• UI에 따라 PK를 그대로 정하기

싱글 테이블 디자인

• 어플리케이션의 모든 엔티티를 하나의 테이블에서 할 수 있도록

• 운영 부담 적어짐.

• 시계열 데이터나 엔티티 별로 접근 패턴이 다르면 좋지 않음

• 테이블 많아지면 손이 많이간다. 관리 힘들어

싱글 테이블 디자인 예제 - 이커머스 애플리케이션 디자인

• ERD는 RDB에서 그리는거라 생각하지만, 1:1, 1:N 이런 관계들 그래도 대략적으로 봐야함. 필드 값까지는 필요없고

• RDB로 시작하고 스케일업 하다가 샤딩이냐 NoSQL이냐 를 고민하게 됨

• attribute에 EntityType을 이용하기!

• PK와 SK에 왜 동일한 값이? — SK에 값을 넣어야 해서 동일한 값을 넣은 것