問題タブ [amazon-dynamodb-streams]

DynamoDB テーブルがあり、新しいレコードが追加されるたびに、古いデータを S3 にアーカイブしたいと考えています。そこで、AWS Lambda を利用できると考えました。したがって、ラムダ関数は、新しく追加/変更された新しいレコードを取得します。しかし、レコードをアップロードする必要があるs3パスの追加パラメーターを（ラムダ関数に）渡したいです。

1 つの方法は、ラムダ関数に渡したいものを別のテーブル/s3 に置くことです。ただし、これ (パラメーター) は、各レコードがメイン テーブルに挿入されるたびに変化します。したがって、ラムダ関数からこれを読み取ることはできません。(最初に挿入されたレコードに対してラムダ関数が実行されるまでに、さらにいくつかのレコードが挿入されます)

パラメータをラムダ関数に渡す方法はありますか?

PS:ラムダを非同期で実行したい。

ありがとう...

AWS DynamoDB は、テーブル アクティビティのキャプチャに役立つストリームを提供します。私の理解では、夢の変化を捉える流れはStream ARN -> Shards -> shardIterator -> Records. アプリケーションが Dynamo テーブルの変更を監視するには、上記のサイクルを実行し続ける必要があります。私のアプリケーションがリッスンできるこれらの変更とトリガーを監視できるフックによって、このフローを簡素化できるかどうか疑問に思っていました。上記のサイクルとアラートを実行できる AWS Lambda 統合があることは承知していますが、アプリケーションが AWS ラムダ アラートをリッスンできるかどうか疑問に思っていました。

npm パッケージdynamodb-streamを使用すると、変更を簡単に利用できますが、すべてのテーブル アクティビティをできるだけ速くキャプチャする必要がある場合、ポーリング メカニズムは最も効率的ではないようです。

次の明らかにバグのあるゲッターを含む Java コードを AWS Lambda に誤ってデプロイしました。

Lambda 関数は、15 秒と 320 Mo の制限で構成されています。これは、DynamoDB ストリームによってトリガーされます。問題のあるコードをデプロイした後、22 時 17 分頃に DynamoDB テーブルを変更したため、コードを実行しました。ログを確認したところ、前の関数から予想できるように、非常に長いスタック トレースを伴う従来の StackOverflowError が発生していました。しかし、これが実行を続け、さらにいくつかのスタック オーバーフロー エラー (CloudWatch のログ) を報告し続ける関数を停止しなかったことに驚きました。15秒の制限を過ぎても機能が停止しないことに気付いたとき、私はさらに心配しました. 手動で停止する方法が見つからなかったため、22 時 30 分頃に Lambda コンソールから単純に削除し、最終的に停止させました。

また、私は自分の DynamoDB テーブルに触れていないこと (そして他の誰もそれにアクセスできないこと) も、他の方法で Lambda 関数を実行しようとしたこともないと確信しています。削除するまで数分間実行し続けたのはなぜですか? 私は確かにもっと注意して、最初にローカルで事前テストを実行する必要がありましたが、期間制限は、到達すると何も実行されないことを保証するものではありませんか?

ご協力ありがとうございました。

Python で dynamodb ストリームからデータを読み取りたいのですが、これまでに見つけた代替手段は次のとおりです。

1. dynamodb ストリームの低レベル ライブラリ関数を使用します (ここで説明されているように): ただし、このソリューションは、アプリケーションがシャードなどの状態を維持する必要があるため、運用環境で維持することはほとんど不可能のようです。

2. Kinesis ストリームの読み取り用に設計されたKCL ライブラリを使用する: Python バージョンのライブラリは、dynamodb ストリームから読み取ることができないようです。

Pythonでdynamodbストリームを正常に処理するためのオプションは何ですか? （可能な例へのリンクは非常に役立ちます）

PS: ラムダ関数を使用して dynamodb を処理することを検討しましたが、このタスクでは、ラムダ関数では実行できない他のコンポーネントと対話する必要があるため、アプリケーションでストリームを読み取りたいと考えています。

こちらのgithub で公開されている DynamoDB Streams Kinesis Adapter には、次のコメントが付いたこの機能があります。

Kinesis モデルは、親シャードのマージ時に、隣接する親シャード ID を提供します。DynamoDB Streams はマージをサポートしていないため、これは常に null を返します。

私はこれを懸念しており、7 つのシャードの例を使用して私の懸念を説明します。簡単にするために、シャードに0から6までの名前を付けます。

0の親は保持ポリシーにより使用できなくなりました。1、2、3、4、5は DynamoDB テーブルのトラフィックが多いため兄弟であり、すべての親として0があり、 6は現在開いているシャードであり、 DynamoDB テーブルのトラフィック スパイクがダウンしたため、マージの結果でした。また、親は1 つしか持てないため、ランダムにその親は3であると仮定します。

つまり、上記の状態の DynamoDB ストリームに対してこのアダプターを使用してワーカーを開始すると、シャード0、3、および6の処理のみが開始されるということですか??