开发者 API 调用
OSS 支持 RESTFUL API 形式调用,基本上服务端控制台上的功能配置,都可以通过 API 完成配置操作。也可以通过 OpenAPI 对文件进行集群的管理,结果用户访问控制台(RAM policy)加强客户的安全屏蔽,目前支持的 API 如下;
开发者 SDK 调用
如果用户端不想自己计算鉴权,直接利用 SDK 封装的 API 工具集,免去鉴权的复杂计算
支持 JAVA、 python、PHP 、GO 、C 、C# 、C++、Ruby 等
热点存储优化
OSS 后端采用的不是 hash key 的方式存储,而是采用了 LSM Tree 结构,系统性能是靠分裂分区扩展的。这种场景要求用户在存储 OSS 内容时,在文件命名上要避开热点前缀。用户如果前缀带了类似日期信息热点前缀,可能导致在切换月份的时候从N个分区跳变到压力集中到一个分区;
细节约定
OSS按照文件名UTF-8编码的顺序对用户数据进行自动分区,从而能够处理海量文件,以及承载高速率的客户请求。不过,如果您在上传大量文件时,在命名上使用了顺序前缀(如时间戳或字母顺序),可能会导致大量文件索引集中存储于某个特定分区。这样,当您的请求速率超过2000次/秒时(下载、上传、删除、拷贝、获取元数据信息等操作算1次操作,批量删除N个文件、列举N个文件等操作算N次操作),会带来如下后果:
- 该分区成为热点分区,导致分区的I/O能力被耗尽,或被系统自动限制请求速率。
- 热点分区的存在会触发系统进行持续的分区数据再均衡,这个过程可能会延长请求处理时间。
以上情况会降低OSS的水平扩展效果,导致客户的请求速率受限。
要解决这个问题,就要消除文件名中的顺序前缀。您可以在文件名前缀中引入某种随机性,这样文件索引(以及 I/O 负载)就会均匀分布在多个分区。
下面提供了几个将顺序前缀改为随机性前缀的方法示例。
sample-bucket-01/2017-11-11/customer-1/file1
sample-bucket-01/2017-11-11/customer-2/file2
sample-bucket-01/2017-11-11/customer-3/file3
...
sample-bucket-01/2017-11-12/customer-2/file4
sample-bucket-01/2017-11-12/customer-5/file5
sample-bucket-01/2017-11-12/customer-7/file6
...
针对这种情况,可以对客户ID计算哈希,即MD5(customer-id) ,并取若干字符的哈希前缀作为文件名的前缀。假如取4个字符的哈希前缀,结果如下:
sample-bucket-01/2c99/2017-11-11/customer-1/file1
sample-bucket-01/7a01/2017-11-11/customer-2/file2
sample-bucket-01/1dbd/2017-11-11/customer-3/file3
...
sample-bucket-01/7a01/2017-11-12/customer-2/file4
sample-bucket-01/b1fc/2017-11-12/customer-5/file5
sample-bucket-01/2bb7/2017-11-12/customer-7/file6
...