検索しましたが、満足のいく解決策が見つかりませんでした。
Minio/S3 にはディレクトリがなく、キーのみ (接頭辞付き) があります。ここまでは順調ですね。
今、これらのプレフィックスを変更する必要があります。単一のファイルではなく、非常に大きくなる可能性がある（実際には制限がない）束（たくさん）のファイル用です。
残念ながら、これらのストレージサーバーには次の概念がないようです (およびサポートしていません)。
- ファイル名を変更する
- ファイルを移動
実行する必要があるのは、ファイルごとです
- ファイルを新しいターゲットの場所にコピーします
- 古いソースの場所からファイルを削除します
私の与えられたデザインは次のようになります：
- ユーザーはファイルをbucketname/uploads/filename.extにアップロードします
- バックグラウンド プロセスがアップロードされたファイルを取得し、さらにいくつかのファイルを生成して、bucketname/temp/filename.ext にアップロードします。
- すべての処理が完了すると、アップロードされたファイルと処理されたファイルは、bucketname/processed/jobid/new-filenames... に移動されます。
パス プレフィックスは、オブジェクト作成通知を処理するときに使用され、それがアップロード (処理の開始)、一時 (すべてのファイルがアップロードされたかどうかの確認)、およびユーザーが削除するまでそれらを保持するための処理済み/ジョブ ID であるかどうかを区別します。
1000 個のファイルを新しい場所 (同じバケット内) に移動する必要があるタスクを想像してみてください。それらを 1 つずつコピーして削除すると、エラーが発生する可能性が高くなります。コピー操作中にストレージ容量が不足し、ロールバックの可能性がない接続エラーが発生しました。場所が異なるバケットになると、簡単にはなりません。
したがって、この古いデザインを使用すると、ファイルの名前を変更/移動する機会がありません。
新しい物理ファイルを作成せずに (使用済みストレージ スペースを複製せずに) ファイルをコピーする変更はありますか?
経験豊富なクラウド開発者なら、エラーの場合にロールバックを使用してこの一括コピーを行う方法のヒントを教えてください。
たとえば、1000 のファイル 517 が失敗した場合、機能的なロールバック メカニズムを使用してそのようなものを実装した人はいますか? それらをコピーして削除することは、うまくいかないようです。
現在、Minio サーバーと Minio dotnet ライブラリを使用しています。ただし、Amazon S3 と互換性があるため、このシナリオは Amazon S3 でも発生する可能性があります。