このトピックでは、Object Storage Service (OSS) で使用される基本的な用語について説明します。
バケット
バケットは、OSSに保存されているオブジェクトのコンテナです。 OSS内のすべてのオブジェクトはバケットに含まれます。 リージョン、アクセス制御リスト (ACL) 、ストレージクラスなど、バケットにさまざまなプロパティを設定できます。 ストレージクラスは、異なるアクセスパターンを持つデータを格納する必要がある場合に便利です。
OSSは、オブジェクトに階層構造ではなくフラット構造を使用します。 各オブジェクトはバケットに属します。
複数のバケットを作成することができます。
バケット名は、Alibaba Cloudアカウント内のOSSで一意である必要があります。 バケットの作成後にバケット名を変更することはできません。
説明すべてのAlibaba Cloudアカウントで作成されたバケットの名前を同じにすることはできません。 たとえば、ユーザーAがexampleという名前のバケットを作成した場合、他のユーザーはexampleという名前の別のバケットを作成できません。
バケットには、無制限の数のオブジェクトを保存できます。
バケットの名前は、次の命名規則に準拠している必要があります。
名前には、小文字、数字、ハイフン (-) のみを使用できます。
名前の先頭と末尾は、小文字または数字である必要があります。
名前の長さは 3 ~ 63 文字である必要があります。
オブジェクト
オブジェクトは、OSS内の最小データ単位です。 OSSにアップロードされたファイルはオブジェクトと呼ばれます。 通常のファイルシステムとは異なり、OSSのオブジェクトは階層構造ではなくフラット構造に格納されます。 オブジェクトは、キー、メタデータ、およびオブジェクトに格納されたデータから構成される。 バケット内の各オブジェクトは、キーによって一意に識別されます。 オブジェクトメタデータは、ファイルタイプやエンコード形式など、オブジェクトのプロパティを定義するキーと値のペアのグループです。 OSSのオブジェクトにカスタムユーザーメタデータを指定することもできます。
オブジェクトのライフサイクルは、オブジェクトのアップロードで始まり、削除で終わります。 追加可能なオブジェクトを除いて、オブジェクトのライフサイクルのすべての段階でオブジェクトのコンテンツを変更することはできません。 オブジェクトのコンテンツを変更するには、新しいオブジェクトをアップロードして既存のオブジェクトを置き換える必要があります。 新しいオブジェクトは、コンテンツを変更するオブジェクトと同じ名前でなければなりません。
オブジェクトの名前は、次の規則に準拠している必要があります。
名前はUTF-8でエンコードする必要があります。
名前は1 ~ 1,023文字である必要があります。
名前を、スラッシュ (/) またはバックスラッシュ (\) で始めることはできません。
説明オブジェクト名では、大文字と小文字が区別されます。 特に明記されていない限り、OSSドキュメントはすべてのオブジェクトまたはファイルをオブジェクトとして参照します。
オブジェクトキー
さまざまなプログラミング言語のOSS SDKでは、オブジェクトキー、キー、およびオブジェクト名はオブジェクトの完全パスを示します。 オブジェクトに対して操作を実行するときは、オブジェクトの完全パスを指定する必要があります。 たとえば、オブジェクトをバケットにアップロードする場合、ObjectKeyは、オブジェクトの拡張子を含む完全なパスを示します。
オブジェクト型
オブジェクトは、オブジェクトの作成方法に基づいて次のタイプに分類できます。
正常
このタイプのオブジェクトは、シンプルアップロードを使用して作成されます。 オブジェクトは、オブジェクトのアップロード後にのみ読み取ることができ、変更することはできません。 既存のオブジェクトのコンテンツを変更するには、既存のオブジェクトと同じ名前のオブジェクトをアップロードして、既存のオブジェクトを上書きする必要があります。 シンプルアップロードでは、サイズが5 GB未満のオブジェクトをアップロードできます。 簡易アップロードは、単一のHTTPリクエストを送信してオブジェクトをアップロードできるシナリオに適しています。 詳細は、「簡易アップロード (Simple upload)」をご参照ください。
マルチパート
このタイプのオブジェクトは、マルチパートアップロードを使用して作成されます。 オブジェクトは、オブジェクトのアップロード後にのみ読み取ることができ、変更することはできません。 既存のオブジェクトのコンテンツを変更するには、既存のオブジェクトと同じ名前のオブジェクトをアップロードして、既存のオブジェクトを上書きする必要があります。 マルチパートアップロードは、大きなオブジェクトのアップロードを高速化でき、ネットワーク状態が不安定で、オブジェクトサイズが不明なシナリオに適しています。 詳しくは、「マルチパートアップロード」をご参照ください。
追加可能
このタイプのオブジェクトは、追加アップロードを使用して作成されます。 追加アップロードを使用すると、ビデオデータが生成された直後に同じオブジェクトにビデオデータをアップロードできます。 追加アップロードは、ビデオ監視やライブストリーミングなどの分野で生成されるリアルタイムのビデオストリームに適しています。 詳細については、「アップロードの追加」をご参照ください。
オブジェクトを別のオブジェクトタイプに変換することはできません。 たとえば、通常のオブジェクトをマルチパートオブジェクトや追加可能オブジェクトに変換することはできません。
リージョン
リージョンは、OSSがサービスを提供する物理的な場所です。 バケットを作成するときに、バケットに最も頻繁にアクセスするコストまたは場所に基づいてリージョンを選択できます。 ほとんどの場合、地理的に近い場所からOSSにアクセスすると、アクセス速度が速くなります。 詳細は、「リージョンとエンドポイント」をご参照ください。
バケットの作成時にバケットのリージョンを指定する必要があります。 バケットの作成後、そのリージョンは変更できません。 バケット内のすべてのオブジェクトは、バケットが配置されているリージョンに格納されます。 リージョンは、オブジェクトレベルではなくバケットレベルで設定します。
エンドポイント
エンドポイントは、OSS へのアクセスに使用されるドメイン名です。 OSSは、データへのアクセスに使用できるリージョン固有のエンドポイントを提供します。 OSS API操作を使用して、さまざまなリージョンのデータを管理できます。 リージョンには、内部ネットワークを介したアクセスとインターネットを介したアクセスのそれぞれに異なるエンドポイントがあります。 たとえば、中国 (杭州) リージョンの OSS データにアクセスするために使用されるパブリックエンドポイントは oss-cn-hangzhou.aliyuncs.com であり、内部エンドポイントは oss-cn-hangzhou-internal.aliyuncs.com です。 詳細は、「リージョンとエンドポイント」をご参照ください。
AccessKey ペア
AccessKeyペアは、リクエスタの認証に使用されます。 AccessKey ペアは、AccessKey ID と AccessKey Secret で構成されます。 OSSは、AccessKeyペアを使用して対称暗号化を実装し、要求者のIDを検証します。 AccessKey ID は、ユーザーの識別に使用されます。 AccessKey Secret は、署名文字列の暗号化と認証に使用されます。 AccessKey Secret は、機密情報として扱う必要があります。 OSS は、以下の方法で取得した AccessKey ペアをサポートしています。
バケット所有者によって適用されたAccessKeyペア。
Resource Access Management (RAM) を使用してバケット所有者によって付与されたAccessKeyペア。
Security Token Service (STS) を使用してバケット所有者によって付与されたAccessKeyペア。
詳細については、「AccessKeyペアの取得」をご参照ください。
原子性と強い一貫性
原子性
OSSのオブジェクト操作はアトミックです。 操作は中間状態なしで成功または失敗します。 オブジェクトがアップロードされると、アップロードの前または後にデータを取得できます。 部分的または破損したデータは取得できません。
強力な整合性
OSS でのオブジェクト操作には、高い一貫性があります。 たとえば、アップロード (PUT) の成功応答を受け取った場合、アップロードされたオブジェクトをすぐに読み取ることができ、冗長性のためにオブジェクトのレプリカが作成されます。 したがって、read-after-write操作を実行したときにデータが取得されないシナリオはありません。 同様に、オブジェクトを削除すると、オブジェクトとそのレプリカは存在しなくなります。
データ冗長メカニズム
データ冗長メカニズムは、ハードウェア障害が発生したときにデータの耐久性と可用性を保証するために、消失符号化に基づいて実装されます。
OSS でオブジェクトに対して実行される操作は、非常に安定しています。 たとえば、アップロードまたはレプリケーションの成功応答を受け取った場合、アップロードされたオブジェクトをすぐに読み取ることができ、冗長性のためにオブジェクトのレプリカが作成されます。
データが完全に送信されるように、OSSはネットワークトラフィックパケットのチェックサムを計算して、クライアントとサーバー間でパケットが送信されるときのエラーをチェックします。
OSSのデータ冗長化メカニズムは、2つのストレージ機能が同時に損傷した場合でも、データの損失を防ぐことができます。
OSSは定期的にレプリカのチェックを実行し、破損したデータを回復して、データの耐久性と可用性を確保します。
OSSは定期的にデータの整合性を検証し、エラーやハードウェア障害によるデータの破損を検出します。 データが部分的に破損または失われた場合、OSSはデータのレプリカを使用してデータを復元します。