DynamoDB에서 여러 테이블을 언제 사용해야합니까?

DyanmoDB 모범 사례를 통해 다음 사항을 명확하게 알 수 있습니다.

DynamoDB 애플리케이션에서 가능한 적은 테이블을 유지해야합니다. 가장 잘 설계된 응용 프로그램은 하나의 테이블 만 필요합니다.

나는 DyanmoDB를 다루는 모든 단일 자습서가 다중 테이블 디자인을 가지고 있다는 것이 재미 있다는 것을 알게되었습니다.

그러나 이것이 실제로 무엇을 의미합니까?

사용자, 프로젝트 및 문서의 세 가지 주요 엔터티가있는 간단한 응용 프로그램을 살펴 보겠습니다. 사용자는 여러 프로젝트를 소유하며 프로젝트는 여러 문서를 가질 수 있습니다. 우리는 일반적으로 사용자를위한 프로젝트와 프로젝트를위한 문서를 쿼리해야합니다. 많은 수의 쓰기를 상당한 마진으로 읽습니다.

순진한 자습서의 테이블 디자인에는 세 개의 테이블이 사용됩니다.

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

우리는 아주 쉽게 무너질 수 Project및 Document하나 개에 Documents테이블 :

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

그런데 왜 거기서 멈춰? 왜 하나의 테이블이 그들을 모두 지배하지 않습니까? User이 모든 것의 근원 이기 때문에 ...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

그런 다음 email사용자 레코드 조회 document-id필드와 직접 문서 조회 필드에 대한 글로벌 인덱스를 갖게 됩니다.

그것이 작동하는 방식입니까? 그런 종류가 다른 종류의 데이터를 같은 테이블에 넣는 것이 합법적입니까? 아니면 두 번째, 2 테이블 디자인이 더 나은 접근 방법입니까?

어떤 시점에서 두 번째 테이블을 추가하는 것이 옳습니까?

그렇습니다, 당신이 말하는 것을하는 것이 합법적입니다. 둘 다 실제로입니다. 여기에없는 몇 가지 변수가 있으며 데이터 모델을 수행하는 방법을 안내하는 데 도움이 될 수 있습니다.

1. 이 응용 프로그램 및 데이터 모델을 통해 어떤 규모의 규모를 원하십니까?
2. 응용 프로그램의 액세스 패턴 중에서 해당 패턴 간의 읽기 비율은 얼마입니까? 어느 것이 다른 것보다 가장 큰 의미인지.
3. 나열된 액세스 패턴 중에서 초당 몇 번이나 수행됩니까?

예를 들어, 모든 읽기의 80 %가 프로젝트에서 사용자를 찾아야하는데 초당 30,000 회 발생해야하지만 응용 프로그램에서 그 단계를 더 진행하여 프로젝트에 대한 문서를 찾는 사람은 많지 않습니다. 전체 읽기의 20 %이며 초당 2000 회 읽기만 가능합니다. 첫 번째는 응용 프로그램의 "핫 경로"이며 최적화해야합니다.

또한 이러한 방식으로 DynamoDB와 같은 비 관계형 데이터베이스를 사용하면 애플리케이션이 데이터를 사용하고 액세스하는 방식을 최적화 할 수 있으며 데이터베이스에 저장되는 방식에 대해 걱정해야하는 관계형 데이터베이스는 아닙니다.