Object Storage Service (OSS) stores data as objects in a flat namespace—every object is identified by a unique key, not a file path. A file system, by contrast, organizes data in a hierarchical directory tree and lets you modify files in place. Understanding this difference helps you use OSS correctly and avoid applying file system assumptions to object storage.
How OSS and file systems differ
The table below compares the two storage models across four dimensions.
| OSS | File system | |
|---|---|---|
| Data model | Stores data as key-value pairs in a distributed object storage system. Each object has a unique key (also called an object name). | Organizes data in a hierarchical directory structure (tree). |
| Data retrieval | Retrieves objects by key. OSS uses a flat namespace—an object named test1/test.jpg is not stored inside a directory called test1. The string test1/test.jpg is no different from example.jpg in terms of storage structure. Requests for objects with different keys consume similar resources. | Traverses the directory tree to locate a file. To access test1/test.jpg, the system enters the test1 directory first, then reads the file. |
| Strengths | Supports a high number of concurrent operations. Designed for storing and processing large amounts of unstructured data—images, videos, and documents. | Files can be modified in place (at a specified offset or truncated from the end). Folder operations such as rename, move, and delete work natively. |
| Limitations | Objects cannot be modified. Any content change requires a specific API operation, and the resulting object has a different type from a normally uploaded object. Even a single-byte change requires re-uploading the entire object. Simulated directory operations are expensive: renaming a directory from test1 to test2 copies every object whose key starts with test1/ and renames each copy to use the test2/ prefix. This consumes substantial bandwidth, storage, and compute resources. We recommend that you do not perform such operations. | Performance is bounded by the underlying device. Accessing files in deeply nested directories consumes more resources and takes more time. |
When to use OSS
OSS is optimized for storing and processing large amounts of unstructured data such as images, videos, and documents. If your workload fits one of these patterns, OSS is a good fit.
Do not use OSS as a drop-in replacement for a file system. If your workload requires frequent in-place edits or deep directory operations, a file system is a better choice. If you must use OSS for file-like access patterns, limit operations to reads, writes, and deletes to keep performance and costs predictable.
OSS concepts and their file system equivalents
The table below maps OSS terminology to the closest file system equivalent.
Some OSS concepts (region, endpoint, and AccessKey) have no direct file system parallel. Conversely, multilevel directories do not exist in OSS.
| OSS | File system equivalent |
|---|---|
| object | file |
| bucket | home directory |
| region | — |
| endpoint | — |
| AccessKey | — |
| — | multilevel directory |
| GetService | list home directories |
| GetBucket | list files |
| PutObject | create a file |
| AppendObject | append data to an existing file |
| GetObject | read a file |
| DeleteObject | delete a file |
| — | modify file content |
| CopyObject (same source and destination) | modify file attributes |
| CopyObject (different source and destination) | copy a file |
| Rename | rename a file |