View a markdown version of this page

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

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

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

인접 목록 설계 패턴

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

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

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

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

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

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

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

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

구체화된 그래프 패턴

많은 애플리케이션이 피어 간 순위, 엔터티 간 관계, 이웃 엔터티 상태를 이해해야 합니다. 애플리케이션에서 이러한 유형의 그래프 스타일 워크플로를 사용하는 경우 다음 스키마 설계 패턴을 고려하세요.

실제 사례로 소셜 네트워킹 애플리케이션을 생각해 볼 수 있습니다. 이 애플리케이션에서 사람들은 타인과 관계를 맺고, 기술을 보유하고, 특정 장소에 거주하고, 관련 날짜(예: 생년월일)를 갖습니다. 각 개인은 그래프의 노드입니다. 우정과 같은 개인 간의 연결은 엣지입니다. 개인 및 해당 속성(기술, 장소, 날짜) 간의 연결도 엣지입니다.

구체화된 그래프 패턴을 사용하면 노드와 엣지를 단일 DynamoDB 테이블에 저장하고 관계를 효율적으로 순회할 수 있습니다. 다음 다이어그램은 이 소셜 네트워킹 그래프를 모델링하는 방법을 보여줍니다. 첫 번째 다이어그램은 기본 테이블 구조를 보여줍니다. 다음 다이어그램은 글로벌 보조 인덱스 프로젝션을 보여줍니다.

DynamoDB의 구체화된 그래프 패턴에 대한 기본 테이블 스키마로, 사람을 파티션 키로 보여주고, 해당 엣지를 각 파티션 내의 항목으로 보여줍니다.
날짜, 이름, 장소 및 기술 쿼리를 위한 오버로드된 데이터 속성을 기반으로 구축된 DynamoDB의 첫 번째 글로벌 보조 인덱스 프로젝션입니다.
역방향 조회를 위한 TypeTarget 복합 키를 기반으로 구축된 DynamoDB의 두 번째 글로벌 보조 인덱스 프로젝션입니다.

이 테이블은 다음 키 구조를 사용합니다.

  • 파티션 키 – 엔터티 ID(예: Person-1, Person-2)입니다. 각 파티션에는 1개의 노드 항목과 여러 개의 엣지 항목이 포함됩니다.

  • 정렬 키 – 노드 항목의 경우 엔터티의 고유 ID입니다. 엣지 항목의 경우 엣지 유형과 대상을 결합한 복합 값입니다(예: Friend-Person-2 또는 Skill-DynamoDB).

엣지 항목에는 TargetType 속성이 포함되어 있습니다. 이는 기본 테이블 및 두 번째 글로벌 보조 인덱스의 항목을 식별하는 복합 키 'TypeTarget'을 형성합니다. 예를 들어 'Person-1은 Person-2의 친구임'은 Type=Friend, Target=Person-2TypeTarget=Friend-Person-2를 생성합니다.

첫 번째 글로벌 보조 인덱스는 Data 속성에 빌드됩니다. 이 속성은 글로벌 보조 인덱스 오버로딩을 사용하여 동일한 인덱스 내에서 여러 속성 유형을 인덱싱합니다.

  • Dates – 생년월일, 가입 날짜(예: 1971-12-21)

  • Names – 표시 이름(예: Ana Carolina Silva)

  • Places – 위치(예: Seattle)

  • Skills – 역량(예: DynamoDB)

이 단일 글로벌 보조 인덱스를 사용하여 특정 날짜에 태어난 모든 사람, 특정 위치에 있는 모든 사람 또는 특정 기술을 보유한 모든 사람을 쿼리할 수 있습니다.

두 번째 글로벌 보조 인덱스는 역방향 조회를 위한 파티션 키로 TypeTarget을 사용합니다. 예를 들어 TypeTarget=Friend-Person-2를 쿼리하여 Person-2를 친구로 나열한 모든 사람을 찾을 수 있습니다.

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

이렇게 디자인 패턴을 결합하면 고효율 실시간 그래프 워크플로를 위한 견고한 데이터 저장소를 구현할 수 있습니다. 이를 사용하여 추천 엔진, 소셜 네트워킹 애플리케이션, 노드 순위, 하위 트리 집계 및 기타 일반적인 그래프 사용 사례에 대한 고성능 이웃 개체 상태 및 엣지 집계 쿼리를 빌드할 수 있습니다.

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

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

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

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

참고

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