2016-12-05 3 views
0

ユーザーを扱うモデルを想定します。ユーザーはUsersという表に格納されます。すべてのユーザーは、固有の識別子(パーティションキー)によって一意に識別されます。すべてのユーザーは、Reportsテーブルに格納されている0個以上のレポートを保持している可能性があります。私はReportsテーブルを設計するための2つの方法のDynamoDB:UUIDと組み合せNatural ID +タイムスタンプ

を考えることができます:

  1. UUIDからなるパーティション・キー
  2. パーティションのユーザー自然識別子からなるキーと、タイムスタンプからなるソートキーレポートは、ミリ秒レベルのタイムスタンプ精度の

に作成されたとき、それは、複数のレポートが同じミリ秒の間、特定のユーザーのために生成することができないと仮定しても安全である(第2の精度もあるべきです 安全)。

推奨されるアプローチは何ですか?

答えて

1

ユーザーごとのレポートの分布によって異なります。ユーザーがそれぞれ非常に少ないレポート(それぞれ<100)を持つのが一般的である場合、またはすべてのユーザーがほぼ同じ数のレポートを持つ場合は、ユーザーIDとタイムスタンプを使用できます。

しかし、一部のユーザーが過半数のレポートをたくさん持っていることが予想される場合は、ユーザーIDでレコードを検索するためにGSIでUUIDを選択する必要があります。

+0

ありがとうございます!ユーザーあたりのレポートの配布がどのように決定に影響を与えるべきかを詳しく教えてください。ユーザーあたりのレポート数が多い場合、ナチュラルID +タイムスタンプを「悪い」ソリューションとするのはなぜですか? –

+0

DynamoDBは、一様分布で非常によくスケールされます。つまり、アイテムのキーが無作為になるほど、あなたはより良い選択肢になります。コンポジットキー(パーティション+ソート)を使用する場合は、各パーティションキーにほぼ同数のアイテムを用意することをお勧めします。 –

+0

私のパーティションキーは、十分にランダムでなければならない個人的な識別子です。ユーザーあたりのレポートの数はユーザーによって異なりますが、比較的低くなります。私は、レポートがさまざまなパーティションにうまく分散されることを理解しています。ありがとう! –