ここに関連する質問がいくつかあります。
- ストリームに関する DynamoDB ドキュメントには次のように記載されています。
アプリケーションが複数のシャードからのレコードを並行して処理できるように、シャードはその親テーブルでの高レベルの書き込みアクティビティに応じて分割される場合があります。
私の理解では、シャードが 2 つの子シャードに分割されると、DynamoDB は親シャードへの書き込みを停止し、ラウンドロビン方式で両方の子シャードへの書き込みを開始します。この場合、どうすればレコードの時系列を確立できますか? 両方の子シャードを読み取り、アプリケーション層でレコード シーケンス番号によってレコードを並べ替える必要がありますか? ある時点で 2 番目の子が 2 つの孫シャードに分割された場合はどうなりますか? レコードを順番に取得する前に、子シャードと孫シャードの両方を読み取る必要がありますか?
- 前述のドキュメントには次のように記載されています。
シャードには系列 (親と子) があるため、アプリケーションは子シャードを処理する前に常に親シャードを処理する必要があります。
ドキュメントで提供されている低レベルの DynamoDB ストリーム API の例を見ると、// Get the shards in the streamコメントの下で、コードが単に特定のストリームのすべてのシャードを取得し、リストを反復処理することがわかります。親子関係を気にせずにシャードを分割できます。
レコードのリストを時系列で取得したい場合、特定のストリームからすべてのレコードを読み取り、アプリケーション層のレコード シーケンス番号で並べ替える必要があるということですか?
- DynamoDB ストリームから時系列のレコード順を取得しようとするのは、まったく悪い考えですか? 私が解決しようとしている具体的な問題について私に聞かないでください。私はここで理論化しています。
アップデート：
上記の質問は、過去 24 時間のストリーム レコードの処理について考えていたときに思い浮かびました。しかし、そもそもなぜ過去 24 時間のストリーム データを処理したいのでしょうか?
ストリームは、そもそもリアルタイムのテーブル変更処理のために構築されていると思います。また、Lambda 関数をトリガーしてストリーム レコードをリアルタイムで処理することは、より理にかなっています。
過去 24 時間のストリーム レコードを処理するための唯一のユース ケースは、何らかのストリーム レコード処理障害回復 (非常に迅速に検出された障害) です。
おまけの質問:
- 過去 24 時間の DynamoDB ストリームを掘り下げたいユースケースを思いつきますか?