DynamoDBで複数のテーブルを使用する場合

DyanmoDBのベストプラクティスにより、次のことが明確になります。

DynamoDBアプリケーションでは、できるだけ少ないテーブルを維持する必要があります。ほとんどの適切に設計されたアプリケーションは、1つのテーブルのみを必要とします。

私がDyanmoDBを扱うのを見たほとんどすべてのチュートリアルがマルチテーブル設計を持っていることは、それから面白いと思います。

しかし、これは実際にはどういう意味ですか？

ユーザー、プロジェクト、ドキュメントという3つの主要エンティティを持つ単純なアプリケーションを考えてみましょう。ユーザーは複数のプロジェクトを所有し、プロジェクトには複数のドキュメントを含めることができます。通常、ユーザーのプロジェクトとプロジェクトのドキュメントを照会する必要があります。読み取りは書き込みの数を大幅に上回ります。

素朴なチュートリアルのテーブルデザインでは、3つのテーブルを使用します。

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

簡単に折り畳んProjectでDocument1つのDocumentsテーブルにすることができます。

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

しかし、なぜそこで停止するのですか？1つのテーブルですべてを統治しないのはなぜですか？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番目の2つのテーブルのデザインの方が優れていますか？

2番目のテーブルを追加するのはどの時点で正しいでしょうか。

はい、あなたが言っていることをするのは合法です。どちらも実際です。ここにはない変数がいくつかあり、データモデルの実行方法をガイドするのに役立ちます。

1. このアプリケーションとデータモデルを使用して、どのようなスケールを実現しようとしていますか？
2. アプリケーションのアクセスパターンのうち、それらのパターン間の読み取りの比率はどのくらいですか。どちらが最も多くヒットするかを意味します。
3. リストするアクセスパターンのうち、1秒間に何回実行されますか？

たとえば、すべての読み取りの80％がプロジェクトのユーザーを見つけることであり、それが30,000 /秒で発生する必要があるが、アプリケーションでそれほど多くの人々がそのステップに進んでプロジェクトのドキュメントを見つけない場合、読み取り全体の20％であり、2000読み取り/秒にすぎない場合があります。最初の1つはアプリケーションの「ホットパス」であり、最適化する必要があります。

また、DynamoDBのような非リレーショナルデータベースを使用すると、アプリケーションがデータをどのように使用してアクセスするかを最適化できます。データベースへのデータの格納方法について多くのことを心配する必要があるリレーショナルデータベースとは異なります。