OSS SDK for Goを使用したラージオブジェクトのアップロード - Object Storage Service

ラージオブジェクトのアップロードの効率を向上させるために、object Storage Service (OSS) には、再開可能なアップロードとマルチパートアップロードの2つの方法があります。このトピックでは、上記のアップロード方法について説明し、さらに参照するために関連ドキュメントへのリンクを提供します。

使用上の注意

PutObjectなどの単純なアップロードを使用してラージオブジェクトをアップロードすると、次の問題が発生する可能性があります。

オブジェクトの最大サイズの制限: PutObject操作を呼び出して、サイズが5 GBを超えるオブジェクトをアップロードすることはできません。サイズが5 GBを超えるオブジェクトのアップロードに失敗します。
オブジェクトのアップロードに必要な時間: 大きなオブジェクトをアップロードするには、特にネットワーク接続が悪い場合に、長い時間が必要です。長期的なデータ伝送は、ネットワークの変動に対して脆弱であり、伝送の中断やタイムアウトの問題を引き起こす可能性があります。
メモリ消費量: 大きなオブジェクトをアップロードすると、特にメモリが小さい場合や環境が限られている場合にメモリ消費量が増加する可能性があり、システムの安定性とパフォーマンスに影響します。

したがって、大きなオブジェクトをアップロードするときの効率と信頼性を向上させるために、再開可能なアップロードまたはマルチパートアップロードを使用することを推奨します。

再開可能なアップロード

再開可能なアップロードは、特にネットワーク接続が不安定な場合やオブジェクトサイズが5 GBを超える場合に、大きなオブジェクトをアップロードするための効率的な方法です。再開可能なアップロードは、オブジェクトを複数のパーツに自動的に分割し、パーツを並行してアップロードします。再開可能なアップロード中、アップロードの進行状況はチェックポイントファイルに記録されます。オブジェクトのアップロードが中断された場合、オブジェクトはチェックポイントファイルに記録されている位置から再アップロードされます。オブジェクト全体を再アップロードする必要がないため、アップロードの効率と信頼性が大幅に向上します。

マルチパートアップロード

マルチパートアップロードは、ラージオブジェクトをアップロードする一般的な方法です。ラージオブジェクトを手動で複数のパーツに分割し、マルチパートアップロード操作を呼び出してパーツをアップロードする必要があります。再開可能なアップロードと比較して、マルチパートアップロードは柔軟性が高く、アップロードプロセス中にパーツのサイズを動的に調整してマルチパートアップロードタスクをキャンセルできます。マルチパートアップロードは、アップロードプロセスの詳細な管理が必要なシナリオに適しています。

メソッドの比較

項目	再開可能なアップロード	マルチパートアップロード
シナリオ	ユーザーは、大きなオブジェクトを簡単かつ迅速にアップロードしたいが、特定の詳細に集中したくない。	ユーザーはアップロードプロセスのきめ細かい管理を必要とし、技術的な能力を持っています。
同時アップロード	サポートされています。	サポートされています。
失敗した位置からのオブジェクトの再アップロード	サポートされています。チェックポイントファイルに記録されている位置からオブジェクトを再アップロードできます。	サポートされていません。チェックポイントファイルに記録されている位置からオブジェクトを直接再アップロードすることはできません。
部品サイズ	部品のサイズをプリセットする必要があります。	部品のサイズを動的に調整できます。
信頼性	高い。再開可能なアップロードは、ネットワーク変動によるアップロードの失敗を減らすことができます。	再開可能なアップロードより低い。失敗した部品を手動で解決する必要があります。
管理の難しさ	低い。 UploadFile操作のみを呼び出す必要があります。	高い。 InitiateMultipartUpload、UploadPart、およびCompleteMultipartUpload操作を呼び出す必要があります。
柔軟性	アップロード処理をきめ細かく管理することはできません。	高い。アップロードプロセスを手動で管理して、マルチパートアップロードタスクのリアルタイムモニタリングを容易にすることができます。
開発の難しさ	非常に低い。再開可能なアップロードタスクを完了するには、UploadFile操作を呼び出すだけです。	高い。ラージオブジェクトを手動で分割し、複数の操作を呼び出してマルチパートアップロードタスクを完了し、さまざまな例外を処理するための管理ロジックをさらに記述する必要があります。