Object Storage Service:Terms in OSS

Bucket

A bucket is a container for objects that are stored in OSS. Every object in OSS is contained in a bucket. You can configure various properties for a bucket, including the region, access control list (ACL), and storage class. Storage classes are useful when you need to store data that have different access patterns.

• OSS uses a flat structure rather than a hierarchical structure for objects. Each object belongs to a bucket.

• You can create multiple buckets.

• A bucket name must be unique in OSS within an Alibaba Cloud account. Bucket names cannot be changed after the buckets are created.

  Note

  The names of buckets created by all Alibaba Cloud accounts cannot be the same. For example, if User A creates a bucket named example, other users cannot create another bucket named example.

• A bucket can contain an unlimited number of objects.

The name of a bucket must comply with the following naming conventions:

• The name can contain only lowercase letters, digits, and hyphens (-).

• The name must start and end with a lowercase letter or a digit.

• The name must be 3 to 63 characters in length.

Object

Objects are the smallest data unit in OSS. Files uploaded to OSS are called objects. Unlike typical file systems, objects in OSS are stored in a flat structure instead of a hierarchical structure. An object is composed of a key, metadata, and the data stored in the object. Each object in a bucket is uniquely identified by the key. Object metadata is a group of key-value pairs that define the properties of an object, such as the file type and encoding format. You can also specify custom user metadata for objects in OSS.

The lifecycle of an object starts when the object is uploaded, and ends when the object is deleted. Aside from appendable objects, you cannot modify the content of an object in all stages of the lifecycle of an object. To modify the content of an object, you must upload a new object to replace the existing object. The new object must have the same name as the object whose content you want to modify.

The name of an object must comply with the following conventions:

• The name must be encoded in UTF-8.

• The name must be 1 to 1,023 characters in length.

• The name cannot start with a forward slash (/) or a backslash (\).

  Note

  Object names are case-sensitive. Unless otherwise stated, the OSS documentation refers to all objects or files as objects.

Object key

In OSS SDKs for different programming languages, object key, key, and object name indicate the full path of the object. You must specify the full path of an object when you perform operations on the object. For example, when you upload an object to a bucket, ObjectKey indicates the full path that includes the extension of the object, such as abc/efg/123.jpg.

Object types

Objects can be classified into the following types based on how the objects are created:

• Normal

  Objects of this type are created by using simple upload. The objects can only be read and cannot be modified after the objects are uploaded. To modify the content of an existing object, you must upload an object that has the same name as the existing object to overwrite the existing object. Simple upload allows you to upload an object that is smaller than 5 GB in size. Simple upload is suitable for scenarios in which you can upload an object by sending a single HTTP request. For more information, see Simple upload.

• Multipart

  Objects of this type are created by using multipart upload. The objects can only be read and cannot be modified after the objects are uploaded. To modify the content of an existing object, you must upload an object that has the same name as the existing object to overwrite the existing object. Multipart upload is suitable for scenarios in which you can accelerate the upload of large objects, the network condition is unstable, and the object size is unknown. For more information, see Multipart upload.

• Appendable

  Objects of this type are created by using append upload. You can use append upload to upload video data to the same object immediately after the video data is generated. Append upload is suitable for real-time video streams generated in fields such as video surveillance and live streaming. For more information, see Append upload.

Region

A region is a physical location from which OSS provides services. When you create a bucket, you can select a region based on the cost or location from which the bucket is most frequently accessed. In most cases, when you access OSS from a geographically closer location, the access speed is faster. For more information, see Regions and endpoints.

The region of a bucket must be specified when the bucket is created. After the bucket is created, its region cannot be changed. All objects in the bucket are stored in the region in which the bucket is located. Regions are configured for buckets instead of objects.

Endpoint

An endpoint is a domain name used to access OSS. OSS provides region-specific endpoints that you can use to access your data. You can manage your data in different regions by using OSS API operations. A region has different endpoints for access over the internal network and for access over the Internet. For example, the public endpoint used to access OSS data in the China (Hangzhou) region is oss-cn-hangzhou.aliyuncs.com, and the internal endpoint is oss-cn-hangzhou-internal.aliyuncs.com. For more information, see Regions and endpoints.

AccessKey pair

An AccessKey pair is used to authenticate a requester. An AccessKey pair consists of an AccessKey ID and an AccessKey secret. OSS uses an AccessKey pair to implement symmetric encryption and verify the identity of a requester. The AccessKey ID is used to identify a user. The AccessKey secret is used to encrypt and verify the signature string. The AccessKey secret must be kept confidential. OSS supports AccessKey pairs obtained by using the following methods:

• AccessKey pairs applied for by the bucket owner.

• AccessKey pairs granted by the bucket owner by using Resource Access Management (RAM).

• AccessKey pairs granted by the bucket owner by using Security Token Service (STS).

For more information, see Obtain an AccessKey pair.

Atomicity and strong consistency

• Atomicity

  Object operations in OSS are atomic. Operations are either successful or failed without intermediate states. When an object is uploaded, you can get either the data before or after the upload. You cannot obtain partial or corrupted data.

• Strong consistency

  Object operations in OSS are highly consistent. For example, when you receive an upload (PUT) success response, you can immediately read the uploaded object, and replicas of the object are created for redundancy. Therefore, there are no scenarios in which data is not obtained when you perform the read-after-write operation. Similarly, after you delete an object, the object and its replicas no longer exist.

Data redundancy mechanism