DynamoDB でシンプルなログ記録サービスを作成しています。
user_id
ハッシュとtimestamp
(Unix エポック int) 範囲をキーとするログ テーブルがあります。
サービスのユーザーがアカウントを終了する場合、範囲の値に関係なく、テーブル内のすべての項目を削除する必要があります。
この種の操作を実行するための推奨される方法は何ですか (削除するアイテムが何百万もある可能性があることを念頭に置いてください)?
私の知る限り、選択肢は次のとおりです。
A:Scan
返された各アイテムに対してdeleteを呼び出して、アイテムがなくなるまで操作を実行します。
B:BatchGet
操作を実行し、各項目に対して削除を再度呼び出して、項目がなくなるまで続けます。
どちらも時間がかかりそうなので、私にはひどいように思えます。
理想的には、LogTable.DeleteItem(user_id)
範囲を指定せずに - を呼び出して、すべてを削除してもらうことです。
ベストアンサー1
理想的には、
LogTable.DeleteItem(user_id)
範囲を指定せずに - を呼び出して、すべてを削除してもらうことです。
確かに、これは理解できる要求です。AWS チームによって、このような高度な操作が時間の経過とともに追加される可能性はあります (AWS チームには、最初は限定された機能セットから始めて、顧客のフィードバックに基づいて拡張機能を評価するという歴史があります)。ただし、少なくともフルスキャンのコストを回避するには、次のことを行う必要があります。
- 使用
Query
それよりもScan
すべてのアイテムを取得しますuser_id
。これは、使用されているハッシュ/範囲のプライマリキーの組み合わせに関係なく機能します。これは、とHashKeyValue
がRangeKeyCondition
このAPIの別々のパラメータであり、前者は複合主キーのハッシュ コンポーネントの属性値。。
- ここでも通常どおりクエリ API ページングを処理する必要があることに注意してください。
ExclusiveStartKey
パラメータを参照してください。
以前のクエリを続行するアイテムの主キー。以前のクエリでは
LastEvaluatedKey
、結果セットのサイズまたは Limit パラメータが原因でクエリが完了する前にクエリ操作が中断された場合に、この値を として提供できます。 をLastEvaluatedKey
新しいクエリ要求で返すことで、その時点から操作を続行できます。
- 返されたすべてのアイテムをループし、
DeleteItem
いつものように
- アップデート: 最も可能性が高い
BatchWriteItem
このようなユースケースにはより適しています (詳細は下記を参照)。
アップデート
強調されているようにイヴァント、BatchWriteItem
手術置くことができますまたは削除1 回の API 呼び出しで複数のテーブルにまたがる複数の項目 [強調は筆者による]:
1 つのアイテムをアップロードするには、API を使用できます。
PutItem
また、1 つのアイテムを削除するには、API を使用できますDeleteItem
。ただし、Amazon Elastic MapReduce (EMR) から大量のデータをアップロードしたり、別のデータベースから Amazon DynamoDB にデータを移行したりするなど、大量のデータをアップロードまたは削除する場合は、この API が効率的な代替手段となります。
ただし、これには依然としていくつかの関連する制限があり、最も重要なのは以下の点です:
1回のリクエストでの最大操作数— 合計で最大 25 個の put または delete 操作を指定できますが、合計リクエスト サイズは 1 MB (HTTP ペイロード) を超えることはできません。
アトミック操作ではない— で指定された個々の操作は
BatchWriteItem
アトミックですが、BatchWriteItem
全体としては「ベスト エフォート」操作であり、アトミック操作ではありません。つまり、リクエストではBatchWriteItem
、一部の操作は成功し、他の操作は失敗する可能性があります。[...]
それでも、これは明らかに、今回のようなユースケースでは潜在的に大きな利益をもたらす可能性があります。