https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/で説明されているように、パーティション キーは一意である必要があります。
トピックへのサブスクリプションを保存する必要があるアプリケーションを構築しています (チャット アプリを考えてください)。これらの何百万ものサブスクリプションをデータベースに格納する必要があり、サブスクライバーにメッセージを送信する必要があるときはいつでも、アプリケーションはテーブルからすべてのサブスクライバーを取得する必要があります。
素朴なアプローチ
単純なアプローチは、次のような主キーを設計することです。
SUBSCRIPTIONS|<topic>
次に、ソートキーは、サブスクリプションの<topic>時間、地域、およびその他のいくつかの基準ですべてのサブスクリプションを並べ替えます。
残念ながら、パーティション キーは一意ではありませんが、すべてのサブスクリプションを瞬時にフェッチできます。
また、テーブルの最大サイズを考慮すると、パーティションで保持できるサブスクリプションの数にハード リミットが設定されるため、この設計の一般的なサブスクリプションの最大数になります。したがって、これはスケーラビリティに失敗するように設計されています。
別
それを設計する他の方法は、次のようなものを使用することです
SUBSCRIPTIONS|<clientId>
クライアントごとにすべてのサブスクリプションを個別に保持<topic>し、ソートキーに移動します。これにより、テーブルのスケーリング (パーティショニング) が大幅に改善されますが、特定の<topic>.
ここではインデックスが役立つかもしれませんが、インデックスは複数のパーティションにどのようにスケーリングするのでしょうか? そしてそれはどのように機能しますか？