This topic describes several basic terms used in Object Storage Service (OSS).

bucket

The container for OSS objects. Each object in OSS is contained in a bucket. You can configure various attributes of a bucket, including the region, access control list (ACL), and storage class. You can create buckets of different storage classes to store data based on your requirements.

  • OSS does not use a hierarchical structure for objects, but instead uses a flat structure. 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.
  • A bucket can contain an infinite number of objects.

OSS supports the following bucket 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

The basic unit for data operations in OSS. Objects are also known as files. OSS does not use a hierarchical structure for objects, but instead uses a flat structure. All elements are stored as objects in buckets. However, OSS supports directories as a concept to group objects and simplify management. An object is composed of object metadata, user data, and a key. A key is used to identify an object in a bucket. Object metadata is a group of key-value pairs that define the properties of an object, such as the last modified time and the object size. You can also assign user metadata to the object.

The lifecycle of an object starts when the object is uploaded, and ends when the object is deleted. Throughout the lifecycle, content can be appended only to objects created by using append upload. If you want to modify the content of an object, you must upload a new object that has the same name as the existing object to replace the existing object.

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, objects and files mentioned in OSS documents are called objects.

ObjectKey

In SDKs for different programming languages, ObjectKey, Key, and ObjectName 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. For example, you can set ObjectKey to abc/efg/123.jpg.

region

The physical location of OSS resources. When you create a bucket, you can select a region based on the cost and source of the requests. In most cases, the closer a user is located from an OSS region, the faster the access. For more information, see Regions and endpoints.

A region is specified when a bucket is created. After a bucket is created, its region cannot be changed. All objects in this bucket are stored in the corresponding region. Regions are configured for buckets instead of objects.

endpoint

The domain name that is used to access OSS. OSS uses HTTP RESTful APIs to provide services. Different regions are accessed by using different endpoints. 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

The access credential that is used to identify the 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:

  • The bucket owner applies for an AccessKey pair.
  • The bucket owner uses Resource Access Management (RAM) to assign an AccessKey pair to a third party.
  • The bucket owner uses Security Token Service (STS) to assign an AccessKey pair to a third party.

For more information about AccessKey pairs, see Create an AccessKey pair.

strong consistency

The feature that requires object operations in OSS be atomic, which indicates that operations can either succeed or fail without intermediate states. To ensure that users can access only complete objects, OSS does not return partially uploaded objects.

Object operations in OSS are highly consistent. For example, when a user receives an upload (PUT) success response, the uploaded object can be immediately read, and copies of the object are created for redundancy. Therefore, the situations where data is not obtained when a user performs a read-after-write operation do not exist. The same is true for delete operations. After a user deletes an object, the object and its copies no longer exist.

data redundancy mechanism

The data redundancy mechanism that is implemented based on erasure coding and multiple replicas. Copies of each object are stored in different servers within the same region. This way, data durability and availability are ensured when hardware failures occur.
  • Operations on objects in OSS are highly consistent. For example, when a user receives an upload or copy success response, the uploaded object can be immediately read, and copies of the object are created for redundancy.
  • To ensure complete data transmission, OSS calculates the checksum of the network traffic packets and checks for errors when packets are transmitted between the client and the server.
  • The data redundancy mechanism of OSS can prevent data loss even when two storage facilities are damaged at the same time.
    • After data is stored in OSS, OSS regularly checks whether copies of the data are lost. Then, OSS recovers lost copies to ensure data durability and data availability.
    • OSS periodically verifies the integrity of data to detect data corruption caused by errors and hardware failures. If data is partially corrupted or lost, OSS recovers the data by using copies of the data.

Comparison between OSS and file systems

Item OSS File system
Data model OSS is a distributed object storage service that stores data as key-value pairs. A file system uses a typical tree structure for directory indexing.
Data retrieval Objects are retrieved based on unique object names (keys).

For example, the object name test1/test.jpg does not necessarily indicate that the object is stored in a directory named test1. In OSS, test1/test.jpg is only a string. test1/test.jpg is not essentially different from example.jpg. Therefore, similar amounts of resources are consumed regardless of which object you access.

To access a file named test1/test.jpg, you must first access the test1 directory and then query the test.jpg file in this directory.
Advantages OSS supports concurrent access from a large number of users. The file system supports modifications on files, such as modifying the content at a specified offset location or truncating the end of a file. It also supports directory operations such as rename, delete, and move directories.
Disadvantages Objects stored in OSS cannot be modified. A specific operation must be called to append an object. Generated objects are different from objects uploaded by using other methods. To modify an object, you must upload the entire object again.

OSS can simulate features similar to those of directories. However, such operations consume a large amount of resources. For example, if you want to rename the test1 directory to test2, OSS must copy all objects whose names start with test1/. Then, OSS creates objects whose names start with test2/. This operation consumes a large amount of resources. Therefore, we recommend that you do not perform such operations in OSS.

The performance of the file system is subject to the performance of a single device. More files and directories in the file system consume greater resources and take longer processing time.

We recommend that you do not map operations on OSS objects to file systems because it is inefficient. If you mount OSS as a file system, we recommend that you perform only add, delete, and read operations on objects. You can take advantage of OSS to process and store large amounts of unstructured data such as images, videos, and documents.

The following table describes the differences in some terms between OSS and file systems.

OSS File system
Object file
Bucket home directory
Region N/A
Endpoint N/A
AccessKey N/A
N/A multilevel directory
GetService obtain the list of home directories
GetBucket obtain the list of files
PutObject add a file
AppendObject append data to an existing file
GetObject read a file
DeleteObject delete a file
N/A modify file content
CopyObject (same destination and source objects) modify file attributes
CopyObject (different destination and source objects) copy a file
N/A rename a file