AWS DynamoDBをデータ収集アプリケーション用のデータストアとして使用したいと考えています。データスキーマは時間の経過とともに変化する可能性があります。DynamoDBの動的スキーマ
例えば、最初に、Itemは、人の属性を表すことができます。 {名前年齢}。しかし、後で、スキーマは{name、age、gender}を含むように変更することができます。
各スキーマの変更は追跡され、バージョン管理され、古いデータは移行する必要はありませんが、新しいデータとともにクエリを実行する必要があります。
各データスキーマの変更を独自のテーブルに格納することは、適切なパターンですか？テーブル間で集計されたデータを照会する簡単なメカニズムはありますか？
DynamoDBテーブルのスキーマは本質的に動的です。最初に設定する必要があるのは、キー名とタイプだけです。いつでもグローバルインデックスを追加することができます（異なるパーティションキーのインデックス）。しかし、ローカル索引は、同じパーティション・キーを持つがソート・キーは異なるため、表作成表に追加されます。この動的スキーマのために、新しいフィールドを追加したり、いつでもフィールドの追加を停止したりすることができます。
どのようにクエリするかを知っているテーブルを設計する必要があります。クエリは非常に制限されていますが、フィルタリングすることはできますが、それは高速で安価な操作ではありません。高速クエリは既存のインデックスに依存します。クエリは単一のテーブルからフェッチできます。結合/結合は利用できません。
テーブルスキャンは条件なしで実行され、フィルタのみが使用できます。フィルタでは、データはディスクからフェッチされますが、返されたセットから削除できます。コストと時間の両方で高価な操作です。キーを渡すクエリは、単一のパーティションからデータをフェッチするため、より高速です。そのため、パーティション（たとえば、ユーザーID）とソートキー（アイテムID）の両方でキーを設計することができます。 DynamoDBで複合キーを使用するのが通常です。
テーブル内のホットスポットを避けることも重要です。つまり、パーティションキーの内部にデータを公平に配備する必要があります。
参考：原因テーブル組合の欠如にhttp://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html
が、あなたはすべてのデータを保存するために複合キーを持つ単一のテーブルを持つことが適切であろうと思いますか？これは、時間の経過とともにさらに分割されてもよい（例えば、毎月の新しいテーブル、または他のグループ化）。 – J3Y
テーブル内に1つのテーブルを置いても問題ありません。ホットスポットは避けてください。 –
1か月あたりのテーブルは月ごとのデータの一般的なプラクティスです。たとえば、1年の再構築に12のクエリがかかるため、このデータをレポートに統合する必要はありません。 –