This topic describes basic terms used in Object Storage Service (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 a variety of attributes for a bucket, including its region, permissions, 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. 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 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 manipulatable 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 it. Each object in a bucket is uniquely identified by its key. Object metadata is a group of key-value pairs that define the properties of an object, such as the size of the object and the time when the object is last modified. You can also specify custom user metadata to 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 edit object data at any stage of the objects' lifecycle. To modify the content of an object, you must upload a new object to replace the existing object. The uploaded object must have the same name as the object you want to replace.
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 file as 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.
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 change 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 a single object that is smaller than 5 GB in size. Simple upload is suitable for scenarios where an object can be uploaded 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 change 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 where 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 a user accesses 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 this bucket are stored in the corresponding region. 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 the 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 through Resource Access Management (RAM).
- AccessKey pairs granted by the bucket owner through Security Token Service (STS).
For more information about AccessKey pairs, see Obtain an AccessKey pair.
Strong consistency
OSS guarantees atomic updates to all objects. Operations performed in OSS can either succeed or fail. When an object is updated and you attempt to retrieve the object, you will get either the data before or after the update, but never partial or corrupt data.
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 replicas of the object are created for redundancy. This ensures that you can always obtain data when you perform the read-after-write operation. Delete operations in OSS are also highly consistent. After a user deletes an object, the object and its replicas no longer exist.
Data redundancy mechanism
- Operations on objects in OSS are highly consistent. For example, when a user receives an upload or replication success response, the uploaded object can be immediately read, and replicas of the object are created for redundancy.
- To ensure that data is completely transmitted, OSS calculates the checksum of the network traffic packets to check 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.
- OSS periodically performs checks on replicas and recovers damaged data to ensure data durability and 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 the replicas of data.
Comparison between OSS and traditional file systems
| Item | OSS | Traditional file system |
|---|---|---|
| Data models | OSS is a distributed object storage service that stores data as key-value pairs. | A traditional file system uses a typical hierarchical structure for directory indexing. |
| Data retrieval | Objects in OSS are retrieved based on object names, which are also referred to as keys. Names do not carry special meanings in OSS. For example, an object named test1/test.jpg in OSS does not mean that the object is stored in a directory named test1. It simply means that the name of the object is test1/test.jpg, which is no different from an object named example.jpg. No additional overhead is required when you access objects that have different names. | To access a file named test1/test.jpg, you must access the test1 directory and find the test.jpg file from the directory. |
| Advantages | OSS supports high-concurrency operations. | Traditional file systems support file-level modifications, including modifying or truncating the content of a file. You can also modify directories, including renaming, deleting, and moving directories. |
| Disadvantages | Objects stored in OSS cannot be modified. A specific operation must be called to append an object. The generated objects are different from the objects uploaded by using other methods. To modify an object, you must re-upload the entire object. OSS can simulate hierarchical file system operations. However, these operations consume a large amount of resources. For example, when you rename a directory from test1 to test2, OSS creates replicas of all objects whose names contain the test1/ prefix and renames the replicas to replace test1/ with test2/. Then, OSS deletes the original objects. Therefore, we recommend that you do not perform hierarchical file system operations in OSS. | The performance of the file system is limited by the performance of the device where the file system resides. If you access files in deeper directories, a large amount of resources and time are consumed. |
We recommend that you do not map operations on OSS objects to file systems because this process 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 traditional file systems.
| OSS | Traditional 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 | Create files |
| AppendObject | Append data to an existing file |
| GetObject | Read files |
| DeleteObject | Delete files |
| N/A | Modify file content |
| CopyObject (same source and destination objects) | Modify file attributes |
| CopyObject (different source and destination objects) | Copy a file |
| N/A | Rename files |