데이터 모델링은 지정된 데이터베이스에서 애플리케이션이 데이터를 저장하는 방법을 설계하는 프로세스이다.
관계형 데이터베이스는 유연성을 위해 구축되었으며, 분석 애플리케이션에 매우 적합하다. 관계형 데이터 모델링에서는 엔터티에서 먼저 시작한다. 정규화된 관계형 모델이 있으면 애플리케이션에 필요한 모든 쿼리 패턴을 충족시킬 수 있다.
NoSQL(비관계형) 데이터베이스는 유연성이 아니라, 속도 및 확장성을 위해 설계되었다. 규모를 확장할 경우 관계형 데이터베이스는 성능이 저하될 수 있지만, DynamoDB와 같은 수평 확장 데이터베이스는 어떤 규모에서든 일관된 성능을 보장한다.
NoSQL 데이터베이스 에서 최상의 결과를 얻으려면 일반 관계형 데이터베이스에서 사고의 전환이 필요하다.
액세스 패턴에 집중하자 어떤 종류의 데이터 모델링을 수행하든, 애플리케이션에서 서로 다른 오브젝트나 엔터티 및 이들의 연결 방식이나 엔터티 간의 관계를 설명하는 엔터티-관계 다이어그램에서 시작한다. 관계형 데이터베이스에서 테이블에 직접 엔터티를 배치하고 외부 키를 사용하여 관계를 지정한다. 하지만 DynamoDB에서 테이블을 모델링 할 떄에는 액세스 패턴을 검토해야 한다. 먼저, 데이터에 액세스하는 방법을 질문하고, 액세스하는 형태로 데이터를 모델링 한다.
DynamoDB에 대한 요청 수 최적화 각 액세스 패턴은 DynamoDB에 하나의 요청만 요구하는 것이 이상적이다. 네트워크 요청이 느리고 이로 인해 애플리케이션에서 수행하는 네트워크 요청 수가 제한되기 때문이다. DynamoDB 에 대한 요청 수를 최적화 하려면 아래링크의 몇가지 핵심 개념을 이해해야 한다.
기본키
보조 인덱스
DynamoDB Transactions를 사용하여 복잡한 워크플로 관리
트랜잭션
관계형 모델에 현혹되지 않기 DynamoDB에서 시도하는 가장 일반적인 안티패턴(반복되는 문제에 대한 비효율적인 응답)은 다음과 같다. 1. 정규화 관계형 데이터베이스에서 사용하는 방법으로, 조인관계를 사용하기 위해 작은 단위로 테이블을 쪼개는 작업을 말한다. DynamoDB에서는 조인을 허용하지 않기 떄문에 정규화는 필요없다. 2. 테이블당 하나의 데이터 유형 아래에 사용할 예제에서도 보이듯 이 하나의 테이블에 User, Game 및 UserGameMapping 엔터티를 사용한다. 이러한 방식이 DynamoDB에 어울린다. 3. 너무 많은 보조인덱스 추가 액세스 패턴에 대해 보조 인덱스를 생성한다. DynamoDB에는 스키마가 없고, 이는 인덱스에도 적용된다. 이런 유연성을 활용해 여러 데이터 유형에서 하나의 보조 인덱스를 재사용한다. 이를 인덱스 오버로드 라고 한다.
아래 단계에서는 엔터티-관계 다이어그램을 구축하고 액세스 패턴을 미리 매핑한다. 이는 DynamoDB를 사용할 때 항상 첫 번째 단계여야 한다. 그리고 후속 모듈에서는 테이블 설계에서 이러한 액세스 패턴을 구현한다.