クラウドコンピューティング愛好家へのご挨拶。
Windows Azure Blob StorageサービスとGoogle Cloud Storageサービスの比較を見ることをお勧めします（著者はAmazon AS3についても言及することを忘れないでください）。
Google App EngineストレージとWindows Azureストレージを比較する記事を書くといいと思いました。 この記事では、
Windows Azure Blob Storageと
Google Cloud Storageを比較し
ます 。
シリーズの最初の部分-Windows AzureテーブルストレージとAmazon DynamoDBの比較パート2-Windows Azure Blob StorageとAmazon Simple Storage Service（S3）を比較する-パートIパート3-Windows Azure Blob StorageとAmazon Simple Storage Service（S3）の比較–パートII、概要略語：
Windows Azure Blob Storage- WABSおよび
Google Cloud Storage -
GCS、 Amazon S3 -
AS3概念的には、WABSとGCSは同様の機能を提供します-簡単に言えば、両方のシステムは大量の非構造化データ（通常はファイルの形式）を保存できるクラウドファイルシステムです。
どちらのシステムも、通常はREST APIのラッパーである高レベル言語のファイルとフォルダーおよびその他のライブラリを操作するためのREST APIを提供します。 APIの各リリースには独自のバージョンがあり、WABSには日付値があり、GCSには番号があります。 執筆時点では、WABSバージョンは
2011-08-18で 、GCSは
バージョン2.0でした。
2つのシステムの同様の機能：
- 両方のシステムは、2レベルの階層を持つクラウドベースのファイルシステムです。
- どちらのシステムでも、大量のデータを長期間、安価に保存できます。
- 両方のシステムは、コンテンツを不正アクセスから保護します。
- 両方のシステムは、データを保護するためのアクセス制御メカニズムを提供します。 GCSでは、これらはWABSのACLとクエリ文字列認証 -ACL と共有アクセス署名です。
- どちらのシステムでも、ソースオブジェクトの任意の数のバージョンを保存できますが、2つのシステムのバージョン管理メカニズムは異なります。
コンセプトの
これらの2つのサービスについて詳しく説明する前に、いくつかの概念を明確にすることが重要だと思います。 WABSおよびGCSの基本概念に精通している場合は、このセクションをスキップできます。
BLOBコンテナーとバスケット ：これらのサービスがクラウド内のファイルシステムである場合、WABS BLOBコンテナーとGCSバケットをフォルダーまたはディレクトリと見なしてください。 WABSストレージアカウントまたはGCSアカウントでは、ブロブまたはオブジェクトをそれぞれ含めることができる0個以上のブロブコンテナーとバスケットを使用できます。
コメント：
- ネストされたblobコンテナやバスケットなどはありません。 どちらのサービスも、ネストなしで2レベルの階層を提供します。 ただし、どちらのシステムでも、プレフィックスを使用してフォルダー階層の錯覚を作成できます。
- コンテナとバスケットの数に制限はありません。
- 両方のシステムは、リソースリクエストをログに記録する機能を提供します。この機能は、GCSでは「ログ記録」、WABSでは「ストレージ分析」と呼ばれます。 違いは、GCSではログがバスケットレベルで機能するのに対して、WABSではログはストレージアカウントレベルで機能することです。 GCSでは、ロギングデータは、ロギングがオンになったときに自動的に作成される事前定義されたテーブルとコンテナーの、WABSの個別のユーザー定義バスケットに配置されます。
BLOB
とオブジェクト ：WABS BLOBとGCSオブジェクトは、BLOBコンテナーとバスケットにあるクラウドファイルシステム内のファイルです。
コメント：
- 格納されるBLOBとオブジェクトの数に制限はありませんが、GCSではこの数は単純に不明ですが、WABSではこの数はストレージアカウントのサイズ（100 Tb）によって制限されます。
- WABSのオブジェクトの最大サイズは1 TBであり、GCSでは定義されていません。
- WABSには2種類のBLOBがあります：ブロック（ストリーミング（写真、ビデオ、ドキュメントなど）に便利で最大サイズが200 GB）、およびページ（ランダムアクセス/記録操作に便利で最大サイズが1 TB）です。 ページBLOBを使用する一般的なケースは、Windows Azureの役割でVHDをディスクとしてマウントすることです。 GCSにはそのような分離はありません。
- 両方のシステムは、豊富なブロブとオブジェクト管理機能を提供します。 他の操作をコピー、ダウンロード、ダウンロード、および実行できます。
- 両方のシステムは、コンテンツを不正アクセスから保護する機能を提供します。アクセス制御リストメカニズムはGCSでより詳細に構成され、バスケット内の各ファイルに対して独自のACLを作成できます。 WABSでは、すべてがBLOBコンテナーレベルで発生します。
最も重要な2つの機能はダウンロードとダウンロードです。まずそれらについて説明し、次に他の機能を比較しましょう。
BLOBとオブジェクトの読み込み
コンテナとバスケットにブロブとオブジェクトをロードすることについて話しましょう。 ロードメカニズムは2つあります。1つのリクエストのフレームワーク内でブロブまたはオブジェクトを完全にダウンロードするか、それらを断片に分割できます（ブロックまたはWABSページ。GCSでは特別な名前はありません）。
1回のリクエストでダウンロード
ダウンロードしたデータが小さく、接続速度が良い場合、1回の要求でこのデータを完全にダウンロードできます。 WABSはこれに
Put Blobを使用します。 GCS-
PUT Objectまたは
POST Objectで 。
ピースをロードする
単一のリクエストで完全にロードするには非効率的なビッグデータを共有できます。 どちらのシステムでも、データを断片（WABSのブロックまたはページ、GCSでは特別な名前を持たない）に分割し、徐々にロードすることができます。 WABSでは、ブロックBLOBの場合、ページBLOBの
Put Blockおよび
Put Block Listを使用する必要があります-Put
Page 。 GCSは、このために
POST Objectおよび
Put Object関数を使用します。
データをチャンクでロードするかどうかを決定できる理由は多数あります。
- 非常に大きなデータをロードする必要があります。 WABSでは、1ブロックのBLOBは200 GBに制限され、ページBLOBは1 TBであることに注意してください。GCSでは、最大5 TBのオブジェクトを1つ持つことができます。 このようなボリュームは、1つの要求でロードするのは実用的ではありません。
- 接続速度が遅い。
- 両方のシステムは、数百および数千のユーザーのリクエストを同時に処理するように設計されたクラウドサービスです。両方のシステムが設定された制限より長く実行されると、リクエストが制限されます-WABSでは、1 MBのデータをダウンロードするのに10分です。
- ビッグデータを断片に分割すると、並列読み込みが可能になります（それぞれ、データの読み込みが速くなります）。
- ピースのロードが破損している場合、そのロードを繰り返すことができますが、単一のリクエストでロードする大きなデータのロードが失敗した場合、すべてを再度ダウンロードする必要があり、非効率的です。
- システムの制限-WABSでは、サイズが64 MBを超える場合、1回のリクエストでデータをダウンロードできません。
各システムにデータを断片的にロードする方法を見てみましょう。 たとえば、100 MBのファイルをチャンクでアップロードしたいとします。
綿棒
各ピースのサイズが1 MBであるとします（同じサイズのピースを用意する必要はありませんが）-100個をダウンロードする必要があります。 ブロックBLOBを取得します。各ブロック（ピース）には一意の識別子（BlockId）があります。 ロードするには、
Put Block関数を使用します。 BlockIdは、最大サイズが64バイトのBase64エンコード文字列です。 すべてのBlockId（この例では100）は同じ長さでなければなりません。 ブロックをロードする順番は関係ありません-並行してロードできます。 ブロックをロードした後、WABSはそれをリポジトリのどこかに置き、7日間保存します。 すべてのブロックをロードした後、
Put Block Listを呼び出して
、これらのブロックを確認（コミット）します。 この関数が呼び出されるまでブロブに連絡することはできません。また、7日以内にブロックを確認しないと、システムによってブロックが削除されます。 BlockIdリストの順序に基づいて関数を呼び出した後、WABSはblobを再作成し、利用可能としてマークします。 BlockIdの値は関係ありません（すべてGUIDにすることができます）が、Putブロックリストを使用するときにBlockIdを送信する順序は重要です。
制限事項：
- Blobは最大50,000ブロックに分割できます。
- BLOBには、常に100,000の未確認ブロックを含めることができます。
- 未確認のブロックのセットは、サイズが400 GBを超えることはできません。
- 1つのBLOBのすべてのBlockIdブロックは同じ長さでなければなりません。 それらがblock8、block9、block11と等しくなる状況は受け入れられません。
- BlockIdの最大長は64バイトです。
Gcs
GCSの場合、大きなファイルをまとめてダウンロードすることを「
再開可能なアップロード 」と呼びます。 最初に、
POSTオブジェクトを呼び出してブートプロセスを開始したことをGCSに伝える必要があります
。 通常、この関数はHTMLフォームを使用してファイルをアップロードするために使用されますが、この場合、ファイルを定義しません。 ダウンロードプロセスを開始したことをGCSに伝えるリクエストヘッダーを定義できます。 ダウンロードが完了すると、GCSは、ダウンロードプロセスを一意に識別するアップロードIDを含む応答を返します。 このIdは、ピースをロードするときに必要になるため、保存する必要があります。 次に、
Put Object関数を使用してファイルをダウンロードし、Upload Idとオブジェクトのコンテンツを渡してみる必要があります。 すべてがうまくいった場合、GCSは200 OkのHTTPコードで応答しますが、操作が失敗した場合、ダウンロードしたバイト数をGCSに問い合わせる必要があります。 GCSは、308 Resume Incomplete HTTPコードを返します。 さらに、Put Objectを使用してデータのロードを続行できます。
考え：
- 200 OKコードを取得することを期待して、ファイル全体をロードしようとしている関数のオブジェクトを返す最初の呼び出しを取り除くことができると思います。 100 MBのファイルをダウンロードしようとしても、一度にロードされないことは間違いありません。 ファイル全体をダウンロードしようとする代わりに、最初の2つのステップをスキップして、このファイルの一部をダウンロードし、そのステータスを取得してからリロードするか、次の部分をダウンロードできます。
- ロードされたバイト数を要求するときにGCSがRangeヘッダーを返すときに、GCSでチャンクを並列にロードする方法がわからない。 WABSにはBlockIdがあり、AS3には部品番号があり、並列読み込みタスクを容易にします。
BLOBとオブジェクトをダウンロードする
ブロブとオブジェクトをダウンロードする方法を見てみましょう。 これには2つのメカニズムがあります。1つの要求でblobまたはオブジェクト全体をダウンロードするか、分割してダウンロードします。
各システムには、WABSで
Blobを
取得し 、GCSで
Objectを
取得するダウンロード機能が1つだけあります。
1回のリクエストでダウンロード
データが小さく、接続速度が良い場合は、WABSのGet BlobとGCSのGET Objectを使用してオブジェクトを完全にダウンロードできます。
分割してダウンロードする
オブジェクトが大きく、一度にダウンロードできるかどうかわからない場合は、同じ機能を使用して、Rangeヘッダーを追加し、ダウンロードに必要なバイト範囲を決定して、ピースをダウンロードできます。
ダウンロードプロセス：
- オブジェクトのサイズを決定します。 たとえば、100 MBの「重さ」があります。
- ピースのサイズを決定します。 たとえば、1 MBのピースをダウンロードすると便利です。
- Get BlobまたはGet Objectを呼び出し、対応する値をRangeヘッダーに渡します。 連続してダウンロードする場合、最初のリクエストにはこのヘッダーの値「0-1048575」（0-1 Mb）、2番目のリクエスト-「1048576-2097151」（1-2 Mb）などが含まれます。
- ダウンロードしたら、作品をどこかに置きます。
- すべてのピースをダウンロードした後、空の100 MBファイルを作成し、このファイルにダウンロードしたピースを入力します。
WABS、AS3、GCSの共通点
3つのシステムすべてに共通のポイントがあります。たとえば、次のとおりです。
- 3つのシステムはすべて、2レベルの階層を持つクラウドベースのファイルシステムです。
- 3つのシステムはすべて、大量のデータを長期間、安価に保存できます。
- 3つのシステムはすべて2レベルの階層を提供します（AS3 / GCSのバスケット/オブジェクトとWABSのBLOBコンテナー/ BLOB）。
- 3つのシステムはすべて、独自のサービスと対話するためのRESTfulインターフェイスと、通常はRESTラッパーである高レベル言語のライブラリを提供します。
AS3と共通
GCSについて最初に読んだとき、GCSとAS3には多くの共通点があることがわかりました。たとえば：
- 1つの用語：両方のシステムは、バスケットやオブジェクト（WABSではblobコンテナーおよびblobと呼ばれます）などの類似の用語を使用します。
- 同じ操作名：両方のシステムが同じ操作名を使用します。 たとえば、バスケットのリストを返すAPIの関数は、両方のシステムでGETサービスと呼ばれます。
- 同じ価格構造：両方のシステムの価格構造は似ています。 WABSでは、すべてのトランザクションは同じであり、AS3とGCSにはトランザクションコストがありますが、実行される操作によって異なります。
- 1つのホスティングスタイル： 両方のシステムが virtual-hosted-style（例：http://mybucket.s3.amazon.com/myobject ）およびpath-style（例：http：//s3-eu-west-1.amazonawsをサポートしています。 com / mybucket / myobject ）、WABSはパススタイルのみをサポートします（例：http: //myaccount.blob.core.windows.net/myblobcontainer/myblob）。
- 類似の一貫性モデル：両方のシステムが類似の一貫性モデルを提供します。 たとえば、両方のシステムは、すべてのPUT要求に対して強力な読み取り後書き込み堅牢性モデルを提供し、最終的にはすべてのリスト（GET）操作に対して堅牢な安定性を提供します。
GCSのユニークな瞬間
GCSの基本的な機能について説明し始めたとき、GCSはWABSやAS3よりも機能が少ないように見えますが、GCSには他のプラットフォームにはない機能があります。 例：
価格
両方のシステムを使用する場合、「資本」コストはありません。 価格設定モデルは比較的単純で、消費に基づいています。 どちらのシステムでも、請求書は使用量に基づいて請求され、3つのコンポーネントで構成されます。
- トランザクションの数 ：支払は、行われたトランザクションの数に従って行われます-大まかに言って、1つのトランザクションはシステム内の1つの関数呼び出しです。 2つのシステムには大きな違いがあります-WABSでは 、トランザクションコストは固定（ 10,000トランザクション あたり0.01ドル）です 。GCSでは 、トランザクション のタイプによって異なります。 PUT、COPY、POST、LISTの各操作を実行する場合、トランザクションごとに高い価格（1000トランザクションあたり0.01ドル）を支払い、GETなどでは低い価格（10,000トランザクションあたり0.01ドル）を支払います。 削除リクエストは書かれていませんが、GCSでは無料であると想定しています。
- ストレージ ：各システムに保存されているデータの量に対して支払います。
- トラフィック ：システムとの間で転送されるデータの量に対して支払います。 執筆時点では、両方のシステムが無料の着信トラフィックを提供しています。 データ転送の費用がGCSの同じデータセンター内で支払われるかどうかは言及されていません。
特別な価格設定モデルも利用でき、両方のシステムが異なる支払いパッケージを提供します。 価格の詳細-https
: //www.windowsazure.com/en-us/pricing/details/（WABSの場合）および
https://developers.google.com/storage/docs/pricingandterms（GCSの場合）。
機能
この表は、WABSおよびGCSが提供する機能をまとめたものです。 両方のシステムでサポートされている機能のみが含まれています。
次の表に、WABSでのみサポートされる機能を示します。
これらの関数をさらに詳しく考えてみましょう。
この関数は、新しいBLOBコンテナーまたはバスケットを作成します。
留意すべき重要な点は、BLOBコンテナーはストレージアカウントに限定され、GCSバスケットはGCSプロジェクトに限定されることです。 WABSストレージアカウントを作成するとき、その場所（データセンター）を決定し、ブロブコンテナーは特定の地理的場所の特定のデータセンターに配置されます。 GCSでバスケットを作成するときに、このバスケットを作成する地域を決定するため、必要に応じて、GCSのすべてのデータセンターにバスケットを配布できます。 WABSで同じことを行うには、コンテナを配置するデータセンターごとにストレージアカウントを作成する必要があります。
BLOBコンテナーとバスケットにはいくつかの命名規則があり、それらは下の表にまとめられています。
| 綿棒
| Gcs
|
最小/最大長のタイトル
| 3/63
| 3/63
|
大文字と小文字の区別
| 小文字
| 小文字
|
許可されたキャラクター
| 英数字とハイフン（-）
| 英数字、ハイフン（-）、およびピリオド（。）
|
その他の命名規則：
- blobコンテナーの名前は、ハイフンではなく、文字または数字で始まる必要があります。一方、ハイフンの後、文字または数字は再び移動する必要があり、複数の連続したハイフンは許可されません。
- GCSバスケット名は、ドットで区切られたラベルで構成されている必要があります。各ラベルの先頭と末尾は小文字または数字である必要があり、バスケット名はIPアドレス（127.0.0.1など）のようには見えません。
- バスケットの名前には3〜63文字を含めることができますが、名前にドットが含まれる場合、バスケットの名前はポイント数を考慮して最大222文字にすることができます。
- バスケット名をgoogプレフィックスで始めることはできません。
注：
| 綿棒
| Gcs
|
コンテナのリスト/ GETサービス
| はい
| はい
|
この関数は、GCSで認証された所有者に属するすべてのBLOBコンテナーまたはバスケットのリストを返します。
コメント：
- WABSでこの関数を1回呼び出すと、最大5000のコンテナーが返されます;ストレージアカウントにさらにコンテナーがある場合は、継続トークンも返されます。 デフォルトでは、WABSは最大5000個のコンテナーを返しますが、より小さい数を指定できます。 GCSではこの金額について言及していません。
- WABSでは、選択に該当するコンテナの名前で始まるプレフィックスを使用して、サーバー側のフィルタリングを実行できます。
- WABSでは、リストとともにblobコンテナーのメタデータを返すかどうかを指定できます。
この関数は、ブロブコンテナーまたはバスケットを削除します。
コメント：
- この操作は同期のように見えるかもしれませんが、実際にはそうではありません。 BLOBコンテナーを削除する要求を送信すると、削除のマークが付けられ、アクセスできなくなります。その後、ガベージコレクションプロセス中に削除されるため、コンテナーを削除する実際の時間は、このコンテナー内のデータのサイズによって異なります。 私の経験では、非常に大きなコンテナの削除には数時間かかる場合があり、この時点で同じ名前のコンテナを作成しようとするとエラーが発生します（競合エラー-HTTP 409）。 この点で、この時点で何をすべきかを計画する必要があります。
- GCSでは、ごみ箱 は空にしてから削除する必要があります。 まず、バスケットからすべてのオブジェクトを削除してから、それを削除する必要があります。 それ以外の場合、409 Conflict エラーが返され ます。
| 綿棒
| Gcs
|
リストBLOB / GETバケット（リストオブジェクト）
| はい
| はい
|
この関数は、コンテナまたはバスケット内のブロブとオブジェクトのリストを取得するために使用されます。 システム内の関数は、次の場合に同じことを行います。
- 両方の機能により、結果の選択を目的のオブジェクト数に制限できます。
- 両方の関数には、1回の関数呼び出しで返すことができるオブジェクトの最大数があります-WABSでは5000、GCSでは1000です。
- どちらの関数もセパレーターをサポートしています。 セパレーターは、ブロブまたはオブジェクトをグループ化するシンボルです。 最も一般的に使用される区切り文字は/です。 前述のように、両方のシステムは2レベルの階層をサポートしており、セパレーターを使用すると、フォルダータイプ階層の錯覚を作成できます。 たとえば、次のオブジェクトがあります：images / a.png、images / b.png、images / c.png、logs / 1.txt、logs / 2.txt、files.txt。 関数を呼び出して区切り文字/を渡す場合、両方のシステムが次の値を返します：images、logs、files.txt。
- どちらの機能も、プレフィックスを使用したサーバー側のフィルタリングをサポートしています。 リクエストにプレフィックスが含まれる場合、両方のシステムは、このプレフィックスで始まる名前を持つオブジェクトを返します。 上記の例を使用して、セパレータなしで接頭辞「images」を渡すと、両方のシステムは次の値を返します：images / a.png、images / b.png、images / c.png。
- 両方の関数は、実際には継続トークンであるマーカーを使用でき、このマーカーで始まるオブジェクトのリストの受信を開始する必要があることを両方のシステムに示すために使用されます。
- 両方のシステムは、アルファベット順にオブジェクトを返します。
違い：
- WABSの1つの関数呼び出しは、最大5000のBLOB、GCS-1000オブジェクトを返します。
- リストを受け取ったら、ブロブのスナップショットを返す必要があることをWABSに示すことができます。 GCSはこれを行うことができません。
- リストを受け取ったら、ブロブに対してメタデータを返す必要があることをWABSに示すことができます。 GCSでは、オブジェクトのメタデータは返されません-これにはHEADオブジェクトを使用する必要があります。
- リストを受け取ったら、まだ確認されていない（コミットされていない）BLOBのリストを返す必要があることをWABSに示すことができます。 部分的にロードされると、GCSはすでに完全にロードされているオブジェクトのみを返すことができます。
- この関数を使用して、バケットのACLまたはCORS設定を取得できます。
| 綿棒
| Gcs
|
コンテナACL / PUTバケットの設定（ACLまたはCORS）
| はい
| はい
|
この関数は、コンテナまたはバスケットのACLを指定するために使用され、WABSで1つ以上のアクセスポリシーを指定することもできます。 CORSはGCSでも設定できます（ただし、CORSとACLは同じリクエストで設定できません）。
BLOBコンテナーの場合、ACL値は次のようになります。
バスケットの場合、ACLは次のものと等しくなります。
- 読み取り ：バスケット内のオブジェクトのリストを取得できます。
- WRITE : , .
- FULL _ CONTROL : READ, WRITE.
GCSで便利なのは、ユーザーに異なるアクセス許可セットを与えることができることです。たとえば、user1にはREAD ACLを、user2にはWRITE ACLを、WABSにはそのような柔軟性はなく、アクセス許可はblobコンテナーにのみ設定されます。WABSの便利な点は、ACLに加えて、このコンテナの一時的な許可セットを定義するコンテナに対して最大5つのアクセスポリシーを設定できることです。たとえば、ブロブコンテナに対する書き込み権限を持つアクセスポリシーを作成できます。これは1日のみ有効です。ポリシーを使用すると、署名付きの特別なURLを生成してユーザーに提供できます（柔軟な共有アクセス署名機能）。署名を使用すると、一定の期間、より詳細なレベルでコンテナおよびBLOBにアクセス権を発行できます。 | 綿棒
| Gcs
|
コンテナーACLの取得/バケットの取得（ACLまたはCORS）
| はい
| はい
|
この関数は、blobコンテナーまたはバスケットのACLを取得するために使用されます。WABSでは、この関数はコンテナーに定義されたアクセスポリシーも返します。バスケットのACLを取得するには、文字列パラメーター「acl」でGET Bucketを呼び出して、文字列パラメーター「cors」でCORSを取得する必要があります。どちらも指定されていない場合、バスケット内のオブジェクトのリストが返されます。 | 綿棒
| Gcs
|
Blob / PUTオブジェクトを配置
| はい
| はい
|
この関数は、ブロブをブロブコンテナーに、オブジェクトをバスケットに追加します。
この関数を使用して、GCSの既存のオブジェクトにACLを指定したり、あるバスケットから別のバスケットにオブジェクトをコピーしたりできます。コメント：
- 両方のシステムで、関数は既存のオブジェクトを指定された名前で上書きします。
- どちらのシステムでも、オブジェクトのプロパティ（キャッシュコントロール、コンテンツタイプなど）を定義できます。
- どちらのシステムでも、MD5コンテンツのハッシュを送信してデータの一貫性を確認できます。
- GCSでは、オブジェクトを作成するときに、オブジェクトにACLを設定できますが、WABSではできません。
- どちらのシステムでも、キーと値のペアのコレクションの形式で、ブロブとオブジェクトのメタデータを指定できます。WABSでは、このメタデータの最大サイズは8 Kbですが、GCSでは不明です。
- , . Put Page.
- GCS .
- , , 64 . , Put Block Put Block List.
- WABSでは、この関数が正常に完了するために満たす必要がある前提条件を決定できます（If - Modified - Since、If - Unmodified - Since、If - Match、If - None - Match）。
この関数は、HTMLフォームを使用して指定されたバスケットにオブジェクトを追加します。POSTはPUTの代替であり、ブラウザがオブジェクトをロードできるようにします。HTTPヘッダーを使用してPUTに渡されるパラメーターは、暗号化されたmultipart / form-dataメッセージの本文としてPOSTから渡されます。 | 綿棒
| Gcs
|
Get Blob / GET Object
| はい
| はい
|
この機能により、コンテナまたはバスケットからblobをダウンロードできます。コメント：
- , Range.
- WABS .
- GCS ACL.
- , ( If - Modified - Since , If - Unmodified - Since , If - Match , If - None - Match ).
- – / .
| 綿棒
| GCS
|
Delete Blob/DELETE Object
| はい
| はい
|
この関数は、BLOBまたはオブジェクトをリポジトリから削除します。コメント：
- WABSでは、この機能を使用して、ソースを削除せずにスナップショットのみを削除できます。ソースが削除されると、そのスナップショットもすべて削除されます。
- この関数は、特定のBLOBバージョンを削除するために使用できます。このためには、WABSでBLOBスナップショットの日付/時刻を指定する必要があります。
・WABSでは、この関数を正常に完了するために満たす必要がある前提条件を決定できます（If- Modified- Since、If- Unmodified- Since、If- Match、If- None- Match）。 | 綿棒
| Gcs
|
Blobのコピー/オブジェクトの配置-コピー
| はい
| はい
|
この関数は、ブロブまたはオブジェクトを元の場所からどこかにコピーします。コメント：
・両方のシステムでは、この機能を正常に完了するために満たす必要のある前提条件を決定できます（If- Modified- Since、If- Unmodified- Since、If- Match、If- None- Match）。これらの条件は、WABSのソースと最終コピー、およびGCSのソースの両方で定義できます。・WABSでは、1つのストレージアカウント内でのみ、コンテナーからコンテナーにオブジェクトをコピーできます。GCSにはそのような制限はありません。交換が行われるバスケットが同じプロジェクトに属している場合、オブジェクトがコピーされます。ただし、APIを使用してチャンクをロードするオブジェクトを作成した場合、オブジェクトをリージョン間でコピーすることはできません。・両方のシステムでは、既存のメタデータをコピーするか、最終コピーのメタデータを指定できます。- GCSでは、コピー時に特定のACLが削除され、デフォルトのACLがオブジェクトに設定されます。カスタムACLは、適切なリクエストヘッダーを使用してコピープロセス中に決定できます。
ヒント：- 両方のシステムは、オブジェクトの名前変更をサポートしていません。オブジェクトの名前を変更するには、最初にオブジェクトをコピーしてから削除します。
- Blobまたはオブジェクトバージョンを「現在の」バージョンに「アップグレード」することもできます。これを行うには、バージョン管理されたblob（スナップショットを指す）またはオブジェクト（バージョンIDを指す）と最終コピーをバージョン管理されていないblobまたはコピー元として指定します。
| 綿棒
| Gcs
|
Blobプロパティの取得/ HEADオブジェクト
| はい
| はい
|
この関数は、blobプロパティとオブジェクトメタデータを取得するために使用されますが、blobまたはオブジェクトのコンテンツは返しません。コメント：
- WABSでBlobプロパティを取得し、GCSでHEADオブジェクトを取得すると、BLOBまたはオブジェクトのユーザー定義のメタデータ、標準HTTPプロパティ、およびシステムプロパティのセットが返されます。
- WABS , ( If - Modified - Since , If - Unmodified - Since , If - Match , If - None - Match ).
- . / . , .
- WABS, Get Blob Metadata.
| 綿棒
| GCS
|
Get Blob Metadata/HEAD Object
| はい
| はい
|
この関数は、ブロブまたはオブジェクトのユーザー定義のメタデータを返します。この関数を使用して、特定のバージョンのblobまたはオブジェクトのプロパティを取得できます。この情報を取得するには、WABSでスナップショットBLOBの日付/時刻を指定する必要があります。まとめ
この記事で見たように、両方のシステムは同様の機能セットを提供しますが、一部の機能はあるシステムに存在し、別のシステムには存在しません。それにもかかわらず、機能の大きな違いについて話すことはできません。翻訳者からのメモこのレビューを読んで、Googleがラプスダを構築するのではなく合理的で成功したアマゾンの道を進むことを合理的に決定したという感覚-これはいくつかのパラメーターのほぼ完全なアイデンティティによって証明されます。Amazonが2006年にサービスを開始し、2010年にGoogleがサービスを開始したことを考えると、そうだったかもしれません。ただし、Googleには他のサービスにはない優れた機能がいくつかあります。たとえば、同じCORSです。一般的に、一時的なコンテキストでのGoogleおよびMicrosoftサービスの開発のペースは、Amazonのペースよりも速いと言うこともできます。次の資料が開発され次第、間違いなく翻訳し、あなたの注意を引き付けます。