数据 IO 和加密
对象大小会对 IBM Cloud® Object Storage 性能产生重大影响。 选择适合您工作负载的方法。
多重部件传输
在典型情况下,多部分上载和下载是一种非常高效的方法,用于将传输分解为许多并行事务。 根据对象大小,通常建议部件大小为 100MB。 在任何情况下,将部件大小设置为 4MiB 的倍数最有效,以优化数据摄取和流出 COS。
与 AWS S3一样,使用多部分传输提供以下优势:
- 提高了吞吐量-您可以并行上载部件以提高吞吐量。
- 从任何网络问题快速恢复-较小的部件大小可将由于网络错误而重新启动失败上载的影响降至最低。
- 暂停和恢复对象上载-随时间推移上载对象部件。 启动多重部件上载后,多重部件上载不会到期; 必须显式完成或必须异常中止多重部件上载。
- 在确定最终对象大小之前开始上载-可以在创建对象时上载该对象。
由于多重部件传输的额外复杂性,建议使用相应的 S3 库,工具或 SDK,为受管多重部件传输提供支持:
- IBM COS SDK for Java
- IBM COS SDK for Python
- IBM COS SDK for Javascript(Node.js)
- IBM COS SDK for Go
- IBM COS Plug-in for IBM Cloud CLI
- S3FS-FUSE
虽然没有用于多部分下载的专用 API,但可以在 GET
请求中使用 Range
头来只读对象的特定部分,并且可以并行发出许多有范围的读取,就像上载部分时一样。 下载完所有部件后,可以并置这些部件,并且可以检查完整对象的完整性。 如前所述,建议使用 SDK 或其他工具,以避免手动管理这些传输的复杂性。
通过将小文件聚集到更大的数据结构 (例如 [Parquet]) 中,可以更好地处理需要存储大量非常小的对象的工作流程。
对于大小大于 200mb 的对象,尤其是在不太稳定的网络中,或者在存在包丢失问题的非常长的距离中,Aspera High-Speed Transfer 可以提供出色的性能。 Aspera 传输还可以在单个请求中高效上载嵌套目录结构。
对批处理删除进行调速
S3 API 提供了一种用于通过单个批处理删除请求最多删除 1,000 个对象的机制。 建议对这些请求客户机端进行调速,以最大限度降低 COS 系统中的性能下降的可能性。 当发出的删除次数对于系统而言过高时,客户机将接收到 HTTP 503 错误,并带有指示“慢速”的错误消息。
一致性影响
IBM Cloud Object Storage System 保证所有对象操作的即时一致性,包括对象写入,覆盖,删除,多部分操作和 ACL 修改。 存储区创建也立即一致。 存储区元数据和配置最终是一致的,与其他对象存储系统一样,这意味着在高度分布式系统中的更改可能不会在短时间内同步。 发生这种情况的原因是元数据高速缓存提供了显着的性能优势,并且还防止了拒绝服务攻击的可能性。
某些应用程序将覆盖同一对象,或者在短时间内重复删除并重写同一对象。 这可能导致 COS 系统中的索引发生争用,应该避免。 在极少数情况下,以非常高的频率使用相同的对象键 (名称) 覆盖长时间的数据是应用程序设计的关键方面,另一个存储平台 (文件,块,noSQL等) 可能是更好的选择。
存在检查
应用程序可能希望在写入对象之前检查该对象是否存在或是否已修改。 这通常会导致应用程序逻辑效率低下,将发送 HEAD 请求,后跟 PUT 或 GET 请求。 这种反模式会导致网络和服务器资源的浪费,因此不应该这样做。
请使用条件请求头,而不是在某个函数中使用 HEAD 请求作为存在检查。 这些标准 HTTP 头将比较 MD5 散列或时间戳记以确定是否应继续执行数据操作。 有关更多信息,请参阅“条件请求”。
使用条件请求
在发出读取或写入数据的请求时,可以对该请求设置条件以避免不必要的操作。 这是使用以下前置条件 HTTP 头完成的: If-Match
,If-None-Match
,If-Modified-Since
和 If-Unmodified-Since
。
通常最好使用 If-Match
,因为 Last-Modified
值的粒度仅以秒为单位,并且可能不足以避免某些应用程序中的竞争情况。
使用 If-Match
在对象 PUT
,HEAD
或 GET
请求上,If-Match
头将检查所提供的 Etag
(对象内容的MD5 散列) 是否与所提供的 Etag
值匹配。 如果此值匹配,那么操作将继续。 如果匹配失败,那么系统将返回 412 Precondition Failed
错误。
If-Match 最常与状态更改方法 (例如,POST,PUT 和 DELETE) 配合使用,以防止在多个用户代理程序可能在同一资源上并行执行操作时发生意外覆盖 (即,防止 "丢失更新" 问题)。
使用 If-None-Match
在对象 PUT
,HEAD
或 GET
请求上,If-None-Match
头将检查所提供的 Etag
(对象内容的MD5 散列) 是否与所提供的 Etag
值匹配。 如果此值不匹配,那么操作将继续。 如果匹配成功,那么系统将在 PUT
上返回 412 Precondition Failed
错误,在 GET
或 HEAD
上返回 304 Not Modified
错误。
If-None-Match 主要用于条件 GET 请求中,以支持以最小事务开销量高效更新高速缓存的信息。 当客户机希望更新一个或多个具有实体标记的已存储响应时,客户机 SHOULD 在发出 GET 请求时生成一个 If-None-Match 头字段,其中包含这些实体标记的列表; 这允许接收方服务器发送 304 (未修改) 响应以指示其中一个已存储的响应何时与所选表示相匹配。
使用 If-modified-since
在对象 HEAD
或 GET
请求上,If-Modified-Since
头将检查对象的 Last-Modified
值 (例如 Sat, 14 March 2020 19:43:31 GMT
) 是否比提供的值更新。 如果对象已修改,那么操作将继续执行。 如果尚未修改对象,那么系统将返回 304 Not Modified
。
If-modified-since 通常用于两个不同的用途: 允许对没有
Etag
的高速缓存表示进行有效更新,并将 Web 遍历的作用域限制为最近更改的资源。
使用 If-Unmodified-since
在对象 PUT
,HEAD
或 GET
请求上,If-Unmodified-Since
头将检查对象的 Last-Modified
值 (例如 Sat, 14 March 2020 19:43:31 GMT
) 是否等于或早于提供的值。 如果尚未修改对象,那么操作将继续。 如果 Last-Modified
值是最新的,那么系统将在 PUT
上返回 412 Precondition Failed
错误,在 GET
或 HEAD
上返回 304 Not Modified
错误。
If-Unmodified-since 最常用于状态更改方法 (例如,POST,PUT 和 DELETE),以防止在多个用户代理程序可能对未提供实体标记及其表示的资源并行执行操作 (即,防止 "丢失更新" 问题) 时发生意外覆盖。 如果所选表示与先前请求中已存储 (或部分存储) 的表示不匹配,那么也可以将其与安全方法配合使用以异常中止请求。
重试策略
虽然大多数库和 SDK 将自动处理重试逻辑,但在编写直接使用 API 来正确处理瞬态错误的软件时必须小心。 最重要的是,必须提供适当的重试逻辑,以在接收到 503 错误时实现指数级回退。
Cypher 调整
IBM COS 支持各种密码设置来加密传输中的数据。 并非所有密码设置都具有相同级别的性能,通常使用 TLS 会导致性能下降。 建议使用以下密码设置 (按优先级降序排列):
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA