問題タブ [amazon-dynamodb-index]

dynamodb のページネーションで大きな問題が 1 つ見つかりました。- 次のパラメーターを使用してクエリ操作を実行します

これにより、結果は4つの投稿のみになります。bcos は、最新の 6 レコードを読み取り、最も一般的なページネーションの方法である filterExpression を適用します。最初の 6 レコードは、2 つの不一致条件レコードで構成されます。これを克服する方法はありますか

「RefNumber」、「status」、「Date」のテーブルがあります。「RefNumber」はパーティションキー、「Status」はソートキーなので、どちらも主キーになります。

このレコードを取得した後、「ステータス」を「1」に更新したいと思います。複数のワーカーが DynamoDB レコードを読み取っています。2 つのワーカーが同じレコードを処理するのを避けるために、ConditionExpression を使用して「ステータス」を「1」で取得および更新します。更新が成功した場合、ワーカーはそれ以外の場合はスキップします。

私の質問は、dynamodb の主キーの一部である属性値を更新するのは良い設計ですか?

https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/で説明されているように、パーティション キーは一意である必要があります。

トピックへのサブスクリプションを保存する必要があるアプリケーションを構築しています (チャット アプリを考えてください)。これらの何百万ものサブスクリプションをデータベースに格納する必要があり、サブスクライバーにメッセージを送信する必要があるときはいつでも、アプリケーションはテーブルからすべてのサブスクライバーを取得する必要があります。

素朴なアプローチ

単純なアプローチは、次のような主キーを設計することです。

SUBSCRIPTIONS|<topic>

次に、ソートキーは、サブスクリプションの<topic>時間、地域、およびその他のいくつかの基準ですべてのサブスクリプションを並べ替えます。

残念ながら、パーティション キーは一意ではありませんが、すべてのサブスクリプションを瞬時にフェッチできます。

また、テーブルの最大サイズを考慮すると、パーティションで保持できるサブスクリプションの数にハード リミットが設定されるため、この設計の一般的なサブスクリプションの最大数になります。したがって、これはスケーラビリティに失敗するように設計されています。

別

それを設計する他の方法は、次のようなものを使用することです

SUBSCRIPTIONS|<clientId>

クライアントごとにすべてのサブスクリプションを個別に保持<topic>し、ソートキーに移動します。これにより、テーブルのスケーリング (パーティショニング) が大幅に改善されますが、特定の<topic>.

ここではインデックスが役立つかもしれませんが、インデックスは複数のパーティションにどのようにスケーリングするのでしょうか? そしてそれはどのように機能しますか？