データのアップロード
ストレージをバケットに編成した後、データをアップロードしていくつかのオブジェクトを追加します。
ストレージの使用方法に応じて、異なる方法でデータをシステムに取り込むことができます。 データ・サイエンティストが分析用に大容量ファイルをいくつか使用したり、システム管理者がデータベース・バックアップをローカル・ファイルと同期させる必要があったり、開発者が数百万のファイルを読み書きする必要のあるソフトウェアを作成するといったことが考えられます。 これらの各シナリオには、データを取り込むためのさまざまな方法があることが役立ちます。
一部のアプリケーションでは、ユーザーまたはサービス ID を、バケット内の読み取りデータへのアクセス権限なしで、データのアップロードのみに制限することができます。 これは、オブジェクト・ライターの IAM 役割 を使用して行うことができます。
コンソールの使用
通常、Web ベースのコンソールを使用することは、最も一般的な Object Storage の使用法ではありません。 オブジェクトは 200 MB に制限され、ファイル名とキーは同一です。 複数のオブジェクトを同時にアップロードできます。ブラウザーでマルチスレッドが許可されている場合、各オブジェクトは複数のパートを並行して使用することによってアップロードされます。 もっと大きいオブジェクト・サイズおよびもっと高いパフォーマンス (ネットワーク要因による) が Aspera 高速転送によってサポートされます。
互換ツールの使用
ユーザーによっては、ストレージと対話するためにスタンドアロン・ユーティリティーを使用することが必要な場合があります。 Cloud Object Storage API は、 S3 API 操作の最も一般的なセットをサポートするため、多くの S3-compatible ツールは、 HMAC 資格情報 を使用して Object Storage に接続することもできます。
例として、ファイル・エクスプローラー (Cyberduck、Transmit など)、バックアップ・ユーティリティー (Cloudberry、Duplicati など)、コマンド・ライン・ユーティリティー (s3cmd、Minio Client など) があり、その他にも多くあります。
API の使用
Object Storage のほとんどのプログラマチック・アプリケーションは、SDK (例えば Java、node.js、または Python) または Cloud Object Storage API を使用します。 通常、オブジェクトは複数のパートでアップロードされます。その際、Transfer Manager クラスによって構成されたパート・サイズとパート番号が使用されます。
条件付き要求
データの読み取りまたは書き込み要求を行う場合、その要求に条件を設定して、不要な操作を回避することができます。 これは、事前条件 HTTP ヘッダー If-Match、 If-None-Match、 If-Modified-Since、および If-Unmodified-Since を使用して行われます。
通常は If-Match を使用することをお勧めします。これは、 Last-Modified 値の細分度が秒単位のみであり、一部のアプリケーションで競合状態を回避するには不十分な場合があるためです。
If-Match の使用
オブジェクト PUT、HEAD、または GET 要求では、 If-Match ヘッダー は、指定された Etag (オブジェクト内容のMD5 ハッシュ) が指定された Etag 値と一致するかどうかを検査します。 この値が一致すると、操作が続行されます。
マッチングが失敗すると、システムは 412 Precondition Failed エラーを返します。
If-Match は、状態変更メソッド (例えば、POST、PUT、DELETE) で最もよく使用されます。これは、複数のユーザー・エージェントが同じリソースに対して並行して動作している可能性がある場合 (つまり、「更新が失われた」問題を回避するため) に、偶発的に上書きされないようにするためです。
If-None-Match の使用
オブジェクト PUT、HEAD、または GET 要求では、 If-None-Match ヘッダー は、指定された Etag (オブジェクト内容のMD5 ハッシュ) が指定された Etag 値と一致するかどうかを検査します。 この値が一致しない場合、操作は続行されます。
一致が成功した場合、システムは PUT では 412 Precondition Failed エラーを返し、GET または HEAD では 304 Not Modified を返します。
If-None-Match は、条件付き GET 要求で主に使用され、キャッシュされた情報を最小限のトランザクション・オーバーヘッドで効率的に更新できるようにします。 クライアントが、エンティティー・タグを持つ 1 つ以上の保管済み応答を更新する必要がある場合、クライアントは、GET 要求を行うときに、それらのエンティティー・タグのリストを含む If-None-Match ヘッダー・フィールドを生成する必要があります。これにより、受信側サーバーは 304 (未変更) 応答を送信して、それらの保管応答の 1 つが選択表現と一致することを示すことができます。
If-Modified-Since の使用
オブジェクト HEAD または GET 要求では、 If-Modified-Since ヘッダー は、オブジェクトの Last-Modified 値 (例えば、 Sat, 14 March 2020 19:43:31 GMT) が指定された値より新しいかどうかを検査します。
オブジェクトが変更されている場合には, 操作は続行されます。 オブジェクトが変更されていない場合、システムは 304 Not Modified を返します。
If-Modified-Since は通常、次の 2 つの異なる目的で使用されます。1) エンティティー・タグを持たないキャッシュ済み表現の効率的な更新を許可するため。2) Web トラバーサルの有効範囲を最近変更されたリソースに制限するため。
If-Unmodified-Since の使用
オブジェクトの PUT、HEAD、または GET 要求では、 If-Unmodified-Since ヘッダー は、オブジェクトの Last-Modified 値 (例えば、 Sat, 14 March 2020 19:43:31 GMT) が指定された値と等しいか、それより前の値であるかを検査します。
オブジェクトが変更されていない場合、操作は続行されます。 Last-Modified 値の方が新しい場合、PUT では 412 Precondition Failed エラーが返され、GET または HEAD では 304 Not Modified エラーが返されます。
If-Unmodified-これは、ほとんどの場合、状態変更メソッド (POST、PUT、DELETE など) で使用されます。これは、複数のユーザー・エージェントが、エンティティー・タグにその表記を提供しないリソースに対して並行して動作している可能性がある場合に、偶発的に上書きされるのを防ぐためです (つまり、「更新なし」の問題を回避するためです)。 また、選択された表現が、前の要求で既に保管されている (または部分的に保管されている) 表現と一致しない場合に、安全な方法で要求を中止することもできます。