本文将向您介绍对象存储OSS产品中涉及的几个基本概念,以便于您更好地理解OSS产品。

存储空间(Bucket)

存储空间是用户用于存储对象(Object)的容器,所有的对象都必须隶属于某个存储空间。存储空间具有各种配置属性,包括地域、访问权限、存储类型等。用户可以根据实际需求,创建不同类型的存储空间来存储不同的数据。

  • 同一个存储空间的内部是扁平的,没有文件系统的目录等概念,所有的对象都直接隶属于其对应的存储空间。
  • 每个用户可以拥有多个存储空间。
  • 存储空间的名称在OSS范围内必须是全局唯一的,一旦创建之后无法修改名称。
  • 存储空间内部的对象数目没有限制。

存储空间的命名规范如下:

  • 只能包括小写字母、数字和短划线(-)。
  • 必须以小写字母或者数字开头和结尾。
  • 长度必须在3~63字节之间。

对象(Object)

对象是OSS存储数据的基本单元,也被称为OSS的文件。和传统的文件系统不同,对象没有文件目录层级结构的关系。对象由元信息(Object Meta),用户数据(Data)和文件名(Key)组成,并且由存储空间内部唯一的Key来标识。对象元信息是一组键值对,表示了对象的一些属性,比如最后修改时间、大小等信息,同时用户也可以在元信息中存储一些自定义的信息。

对象的生命周期是从上传成功到被删除为止。在整个生命周期内,除通过追加方式上传的Object可以通过继续追加上传写入数据外,其他方式上传的Object内容无法编辑,您可以通过重复上传同名的对象来覆盖之前的对象。

对象的命名规范如下:

  • 使用UTF-8编码。
  • 长度必须在1~1023字节之间。
  • 不能以正斜线(/)或者反斜线(\)开头。
    说明 对象名称需要区分大小写。如无特殊说明,本文档中的对象、文件称谓等同于Object。

ObjectKey

在各语言SDK中,ObjectKey、Key以及ObjectName是同一概念,均表示对Object执行相关操作时需要填写的Object名称。例如向某一存储空间上传Object时,ObjectKey表示上传的Object所在存储空间的完整名称,即包含文件后缀在内的完整路径,如填写为abc/efg/123.jpg。

Region(地域)

Region表示OSS的数据中心所在物理位置。用户可以根据费用、请求来源等选择合适的地域创建Bucket。一般来说,距离用户更近的Region访问速度更快。详情请参见OSS已经开通的Region

Region是在创建Bucket的时候指定的,一旦指定之后就不允许更改。该Bucket下所有的Object都存储在对应的数据中心,目前不支持Object级别的Region设置。

Endpoint(访问域名)

Endpoint表示OSS对外服务的访问域名。OSS以HTTP RESTful API的形式对外提供服务,当访问不同的Region的时候,需要不同的域名。通过内网和外网访问同一个Region所需要的Endpoint也是不同的。例如杭州Region的外网Endpoint是oss-cn-hangzhou.aliyuncs.com,内网Endpoint是oss-cn-hangzhou-internal.aliyuncs.com。具体的内容请参见各个Region对应的Endpoint

AccessKey(访问密钥)

AccessKey简称AK,指的是访问身份验证中用到的AccessKeyId和AccessKeySecret。OSS通过使用AccessKeyId和AccessKeySecret对称加密的方法来验证某个请求的发送者身份。AccessKeyId用于标识用户;AccessKeySecret是用户用于加密签名字符串和OSS用来验证签名字符串的密钥,必须保密。对于OSS来说,AccessKey的来源有:

  • Bucket的拥有者申请的AccessKey。
  • 被Bucket的拥有者通过RAM授权给第三方请求者的AccessKey。
  • 被Bucket的拥有者通过STS授权给第三方请求者的AccessKey。

更多AccessKey介绍请参见创建AccessKey

强一致性

Object操作在OSS上具有原子性,操作要么成功要么失败,不会存在有中间状态的Object。OSS保证用户一旦上传完成之后读到的Object是完整的,OSS不会返回给用户一个部分上传成功的Object。

Object操作在OSS同样具有强一致性,用户一旦收到了一个上传(PUT)成功的响应,该上传的Object就已经立即可读,并且Object的冗余数据已经写成功。不存在一种上传的中间状态,即read-after-write却无法读取到数据。对于删除操作也是一样的,用户删除指定的Object成功之后,该Object立即变为不存在。

数据冗余机制

OSS使用基于纠删码、多副本的数据冗余存储机制,将每个对象的不同冗余存储在同一个区域内多个设施的多个设备上,确保硬件失效时的数据持久性和可用性。
  • OSS Object操作具有强一致性,用户一旦收到了上传或复制成功的响应,则该上传的Object就已经立即可读,且数据已经冗余写入到多个设备中。
  • OSS会通过计算网络流量包的校验和,验证数据包在客户端和服务端之间传输中是否出错,保证数据完整传输。
  • OSS的冗余存储机制,可支持两个存储设施并发损坏时,仍维持数据不丢失。
    • 当数据存入OSS后,OSS会检测和修复丢失的冗余,确保数据持久性和可用性。
    • OSS会周期性地通过校验等方式验证数据的完整性,及时发现因硬件失效等原因造成的数据损坏。当检测到数据有部分损坏或丢失时,OSS会利用冗余的数据,进行重建并修复损坏数据。

OSS与文件系统的对比

对比项 OSS 文件系统
数据模型 OSS是一个分布式的对象存储服务,提供的是一个Key-Value对形式的对象存储服务。 文件系统是一种典型的树状索引结构。
数据获取 根据Object的名称(Key)唯一的获取该Object的内容。

虽然用户可以使用类似test1/test.jpg的名字,但是这并不表示用户的Object是保存在test1目录下面的。对于OSS来说,test1/test.jpg仅仅只是一个字符串,和a.jpg这种并没有本质的区别。因此不同名称的Object之间的访问消耗的资源是类似的。

一个名为test1/test.jpg的文件,访问过程需要先访问到test1这个目录,然后再在该目录下查找名为test.jpg的文件。
优势 支持海量的用户并发访问。 支持文件的修改,比如修改指定偏移位置的内容、截断文件尾部等。也支持文件夹的操作,比如重命名目录、删除目录、移动目录等非常容易。
劣势 OSS保存的Object不支持修改(追加写Object需要调用特定的接口,生成的Object也和正常上传的Object类型上有差别)。用户哪怕是仅仅需要修改一个字节也需要重新上传整个Object。

OSS可以通过一些操作来模拟类似文件夹的功能,但是代价非常昂贵。比如重命名目录,希望将test1目录重命名成test2,那么OSS的实际操作是将所有以test1/开头的Object都重新复制成以test2/开头的Object,这是一个非常消耗资源的操作。因此在使用OSS的时候要尽量避免类似的操作。

受限于单个设备的性能。访问越深的目录消耗的资源也越大,操作拥有很多文件的目录也会非常慢。

因此,将OSS映射为文件系统是非常低效的,也是不建议的做法。如果一定要挂载成文件系统的话,建议尽量只做写新文件、删除文件、读取文件这几种操作。使用OSS应该充分发挥其优点,即海量数据处理能力,优先用来存储海量的非结构化数据,比如图片、视频、文档等。

以下是OSS与文件系统的概念对比:

对象存储 OSS 文件系统
Object 文件
Bucket 主目录
Region
Endpoint
AccessKey
多级目录
GetService 获取主目录列表
GetBucket 获取文件列表
PutObject 写文件
AppendObject 追加写文件
GetObject 读文件
DeleteObject 删除文件
修改文件内容
CopyObject (目的和源相同) 修改文件属性
CopyObject 复制文件
重命名文件