DynamoDB의 관계형 데이터를 모델링하는 첫 번째 단계
참고
NoSQL 설계에는 RDBMS 설계와 다른 사고 방식이 요구됩니다. RDBMS의 경우, 액세스 패턴을 생각하지 않고 정규화된 데이터 모델을 생성할 수 있습니다. 그런 후 나중에 새로운 질문과 쿼리에 대한 요구 사항이 생길 때 이를 확장할 수 있습니다. 대조적으로 Amazon DynamoDB의 경우 대답해야 할 질문을 모르기 전까지는 스키마 설계를 시작할 수 없습니다. 사전에 비즈니스 문제와 애플리케이션 사용 사례를 이해해야 합니다.
효율적으로 확장되는 DynamoDB 테이블 설계를 시작하려면, 몇 단계를 거쳐야 하는 데 먼저 지원해야 하는 OSS/BSS(운영 지원 시스템 및 비즈니스 지원 시스템)에서 요구되는 액세스 패턴을 파악해야 합니다.
새 애플리케이션의 경우, 활동과 목표에 대한 사용자 사례를 검토합니다. 파악한 다양한 사용 사례를 문서화하고, 여기에 필요한 액세스 패턴을 분석합니다.
기존 애플리케이션의 경우, 쿼리 로그를 분석해 현재 시스템을 사용하고 있는 사람의 수와 핵심 액세스 패턴을 파악해야 합니다.
이런 프로세스를 끝내면 다음과 같은 형태를 가진 목록이 준비되어야 합니다.
| 패턴 번호 | 액세스 패턴 설명 |
|---|---|
| 1 | 직원 ID별로 직원 세부 정보 조회 |
| 2 | 직원 이름별 직원 세부 정보 쿼리 |
| 3 | 직원의 전화번호 찾기 |
| 4 | 고객의 전화번호 찾기 |
| 5 | 날짜 범위 내에서 고객에 대한 주문 가져오기 |
| 6 | 날짜 범위 내의 모든 미결 주문 표시 |
| 7 | 최근 채용된 모든 직원 표시 |
| 8 | 창고의 모든 직원 찾기 |
| 9 | 제품 주문 시 모든 항목 가져오기 |
| 10 | 모든 웨어하우스에서 제품에 대한 인벤토리 가져오기 |
| 11 | 계정 담당자별로 고객 가져오기 |
| 12 | 계정 담당자별로 주문 가져오기 |
| 13 | 직함으로 직원 가져오기 |
| 14 | 제품 및 창고별로 인벤토리 가져오기 |
| 15 | 전체 제품 인벤토리 가져오기 |
실제 사용하는 애플리케이션의 경우, 목록이 훨씬 더 길 것입니다. 그러나 이는 프로덕션 환경에서 찾을 수 있는 다양하고 복잡한 쿼리 패턴을 보여줍니다.
DynamoDB 스키마 설계에 대한 최신 접근 방식은 집계 지향 원칙을 사용하여 엄격한 개체 경계가 아닌 액세스 패턴을 기반으로 데이터를 그룹화합니다. 이 접근 방식은 다음과 같이 여러 설계 패턴을 고려합니다.
단일 테이블 설계 - 복합 정렬 키, 오버로드된 글로벌 보조 인덱스 및 인접 목록 패턴을 사용하여 여러 엔터티 유형을 하나의 테이블에 저장
다중 테이블 설계 - 독립된 운영 특성과 낮은 액세스 상관관계를 가진 엔터티에 대해 별도의 테이블을 교차 엔터티 쿼리에 대한 전략적 GSI와 함께 사용
집계 설계 - 항상 함께 액세스할 때 관련 데이터 임베딩(주문 + OrderItems) 또는 관계 식별을 위한 항목 컬렉션 사용(제품 + 인벤토리)
이러한 접근 방식 중에서 선택하는 방법은 특정 액세스 패턴, 데이터 특성 및 운영 요구 사항에 따라 달라집니다. 이런 요소들을 사용해 데이터를 구조화, 애플리케이션이 테이블이나 인덱스에 대한 한 번의 쿼리로 특정 액세스 패턴에 필요한 것을 검색하도록 만들 수 있습니다.
참고
단일 테이블 설계와 다중 테이블 설계 중에서 선택하는 것은 특정 요구 사항에 따라 달라집니다. 단일 테이블 설계는 개체의 액세스 상관관계가 높고 운영 특성이 유사한 경우에 적합합니다. 다중 테이블 설계는 엔터티에 독립적인 운영 요구 사항, 다양한 액세스 패턴이 있거나 명확한 운영 경계가 필요한 경우에 선호됩니다. 이 가이드의 예제는 전략적 집계 및 비정규화를 사용하는 다중 테이블 접근 방식을 보여줍니다.
DynamoDB용 NoSQL Workbench를 사용하여 파티션 키 설계를 시각화하려면 NoSQL Workbench로 데이터 모델 빌드 섹션을 참조하세요.
