DynamoDB 테이블의 다대다 관계 관리 모범 사례 - Amazon DynamoDB

DynamoDB 테이블의 다대다 관계 관리 모범 사례

인접 목록은 Amazon DynamoDB의 다대다 관계 모델링에 유용한 설계 패턴입니다. 대체로 DynamoDB에 그래프 데이터(노드 및 엣지)를 표시하는 방법을 제공합니다.

인접 목록 설계 패턴

특정 애플리케이션의 여러 개체 간 관계가 다대다 관계일 때, 이런 관계를 인접 목록으로 모델링할 수 있습니다. 이 패턴에서는 파티션 키를 사용하여 모든 최상위 개체(그래프 모델의 노드와 비슷)를 표현합니다. 다른 개체(그래프의 엣지)와의 관계는 대상 개체 ID(대상 노드)에 정렬 키 값을 설정해 파티션 내에서 하나의 항목으로 표시합니다.

이런 패턴은 데이터 중복을 최소화하고, 쿼리 패턴을 단순화시켜 대상 개체(대상 노드의 엣지)와 연결된 모든 개체(노드)를 찾을 수 있다는 점이 장점입니다.

실제 이런 패턴을 유용하게 사용하는 사례는 인보이스 여러 요금 청구 항목이 있는 인보이스 시스템입니다. 하나의 요금 항목이 여러 인보이스에 속할 수 있습니다. 이 예제의 파티션 키는 InvoiceID 또는 BillID입니다. BillID 파티션에는 청구서와 관련된 모든 속성이 포함되어 있습니다. InvoiceID 파티션에는 인보이스별 속성이 저장된 항목과 인보이스에 롤업된 각 BillID에 대한 항목이 있습니다.

스키마는 다음과 같습니다.

결제 인접 목록의 테이블 스키마에 대한 예

앞서 스키마를 사용하여 특정 인보이스의 요금 항목을 테이블 기본 키를 사용해 쿼리할 수 있다는 것을 확인할 수 있습니다. 특정 요금 항목의 일부가 포함된 모든 인보이스를 찾으려면 테이블 정렬 키에 글로벌 보조 인덱스를 생성합니다.

글로벌 보조 인덱스의 프로젝션은 다음과 같습니다.

결제 인접 목록의 GSI 프로젝션에 대한 예

구체화된 그래프 패턴

피어 간 순위, 개체 간 공통 관계, 이웃 개체 상태, 기타 그래프 스타일 워크스타일에 대한 이해를 토대로 빌드되는 애플리케이션이 많습니다. 이런 유형의 애플리케이션에 대해서는 다음 스키마 설계 패턴을 고려하세요.

그래프에 대한 예 1번
그래프에 대한 예 2번
그래프에 대한 예 3번

앞의 스키마는 그래프의 엣지와 노드를 정의하는 항목이 포함된 데이터 파티션 세트로 정의한 그래프 데이터의 구조를 보여주고 있습니다. 엣지 항목에는 TargetType 속성이 포함되어 있습니다. 이러한 속성들을 "TypeTarget"이라는 복합 키의 일부로 사용하여 기본 테이블이나 보조 글로벌 보조 인덱스의 파티션에 있는 항목을 식별할 수 있습니다.

첫 번째 글로벌 보조 인덱스는 Data 속성에 빌드됩니다. 이 속성은 앞서 설명한 글로벌 보조 인덱스 오버로딩을 사용하여 Dates, Names, Places, Skills 등 몇몇 속성 유형을 인덱스합니다. 효과적으로 4개의 속성들을 인덱싱하는 글로벌 보조 인덱스입니다.

테이블에 항목들을 삽입하면, 지능형 샤딩 전략을 사용하여 필요한 만큼 많은 글로벌 보조 인덱스의 논리적 파티션에 크게 집계된(Birthdate, Skill) 항목 세트를 배포, '핫' 읽기/쓰기 문제를 방지할 수 있습니다.

이렇게 디자인 패턴을 결합해서 고효율 실시간 그래프 워크플로우를 위한 데이터 스토어를 구현합니다. 이런 워크플로우는 고성능의 이웃 개체 상태와 소셜 네트워킹 애플리케이션의 추천 엔진에 대한 엣지 집계 쿼리, 노드 순위, 하위 트리 집계, 기타 범용 그래프 사용 사례를 제공할 수 있습니다.

실시간의 데이터 일관성이 중요하지 않은 사용 사례인 경우, 예약한 Amazon EMR 프로세스를 사용해 워크플로우에 관련 그래프를 요약 집계해서 엣지를 채울 수 있습니다. 애플리케이션이 엣지가 그래프에 추가된 때를 즉시 알 필요가 없다면, 예약된 프로세스를 사용해 결과를 집계할 수 있습니다.

일정 수준의 일관성을 유지하기 위해 설계에 Amazon DynamoDB Streams 및 AWS Lambda를 포함하여 엣지 업데이트를 처리할 수 있습니다. 또한 Amazon EMR 작업을 사용하여 정기적인 간격으로 결과를 확인할 수 있습니다. 다음 다이어그램에 이런 방식이 설명되어 있습니다. 실시간 쿼리 비용이 높고 개별 사용자의 업데이트를 즉시 파악할 필요성이 낮은 소셜 네트워킹 애플리케이션에 많이 사용되고 있습니다.

그래프 워크플로우를 보여주는 다이어그램

IT 서비스 관리(ITSM) 및 보안 애플리케이션은 일반적으로 복잡한 엣지들이 통합되어 구성된 개체 상태 변경에 실시간으로 응답할 필요가 있습니다. 이런 애플리케이션에는 두 번째와 세 번째 수준의 관계나 복잡한 엣지 통과에 대해 실시간으로 다중 노드 집계를 지원할 수 있는 시스템이 필요합니다. 사용 사례에 이런 유형의 실시간 그래프 쿼리 워크플로우가 필요하다면, 워크플로우 관리에 Amazon Neptune 사용을 고려하는 것이 좋습니다.

참고

연결성이 높은 데이터 세트를 쿼리하거나 여러 노드를 통과해야 하는 쿼리(멀티 홉 쿼리라고도 함)를 몇 밀리초의 지연 시간으로 실행해야 하는 경우 Amazon Neptune을 사용하는 것이 좋습니다. Amazon Neptune은 수십억 개의 관계를 저장하고 몇 밀리초의 지연 시간으로 그래프를 쿼리하도록 최적하된 특수 목적 고성능 그래프 데이터베이스 엔진입니다.