1. Object Storage: Your "Smart Cloud Warehouse"
1.1 Overview of Object Storage
A traditional file system is like your wardrobe at home: clothes are organized by "tops/pants/skirts" in layers. To find a shirt, you have to open the wardrobe → tops section → shirt compartment. This "hierarchical nesting" model becomes extremely cumbersome when the number of files explodes.
Object storage, on the other hand, is like modern warehousing logistics: every package has a unique "tracking number" (object key). You just provide the tracking number, and the warehouse robot can precisely retrieve it from a sea of packages.
Key Differences at a Glance:
| Dimension | Traditional File System | Object Storage |
|---|---|---|
| Organization | Hierarchical directory tree | Flat key-value pairs |
| Access Protocol | POSIX (local file operations) | HTTP/REST API |
| Scalability | Limited by single machine | Near-infinite horizontal scaling |
| Metadata | Basic attributes (size, time) | Rich custom metadata |
| Typical Use Case | Local office documents | Images/videos/backups/static assets |
1.2 Core Concepts of Object Storage
Bucket: Your "Warehouse Partition"
A bucket is the top-level container in object storage, equivalent to an independent namespace. All objects must be stored in a bucket.
Naming Rules (using Alibaba Cloud OSS as an example):
- Globally unique: cannot duplicate across all users of the cloud provider
- Can only contain lowercase letters, numbers, and hyphens
- Must start and end with a lowercase letter or number
- Length between 3-63 characters
Real-World Pitfall: A team once created dozens of buckets based on business lines, and were shocked when the monthly bill arrived—each bucket incurs minimum storage fees and request fees. Recommendation: plan buckets by combining "environment + purpose," such as prod-static-assets, dev-backup-archive.
Object: Your "Data Package"
An object is the basic unit of storage, consisting of three parts:
Key: The unique identifier of the object, equivalent to a "tracking number"
- Example:
images/avatar/2024/user123.jpg - Although it looks like a path, it's essentially just a string
- Example:
Data: The object's content itself
- Can be any binary data
- Size limits depend on the cloud provider (typically up to 5TB per object)
Metadata: Additional information describing the object
- System metadata: Content-Type, ETag, Last-Modified, etc.
- Custom metadata: e.g.,
x-oss-meta-owner,x-oss-meta-project
Access Control: Who Can Touch My "Warehouse"?
Object storage provides multiple layers of permission control:
| Layer | Control Method | Typical Use Case |
|---|---|---|
| Bucket-level | Bucket Policy | Block all external access, allow only specific IPs |
| Object-level | ACL (Access Control List) | Public images, private documents |
| Temporary Auth | STS (Security Token Service) | Frontend direct upload, mobile uploads |
Security Red Line: Never write AccessKey ID and AccessKey Secret in frontend code! The correct approach is: the frontend requests temporary STS credentials from your backend, and the backend returns temporary credentials with an expiration time after verifying the user's identity.