資料 IO 和加密

物件大小可能會對 IBM Cloud® Object Storage 效能產生重大影響。 選擇適合您工作負載的方法。

多組件傳送

在一般狀況下，多部分上傳及下載是一種非常有效的方法，可將傳送分割成許多平行交易。 視物件大小而定，通常建議使用部分大小 100MB。 在任何情況下，最有效率的方法是將組件大小設為 4MiB 的倍數，以最佳化送入及送出 COS 的資料。

與 AWS S3一樣，使用多組件傳送提供下列優點:

  • 提高傳輸量-您可以平行上傳組件以提高傳輸量。
  • 從任何網路問題快速回復-較小的組件大小可將因網路錯誤而重新啟動失敗上傳的影響降到最低。
  • 暫停及回復物件上傳-在一段時間內上傳物件組件。 一旦起始多組件上傳，多組件上傳就沒有期限; 必須明確完成，否則必須中斷多組件上傳。
  • 在已知最終物件大小之前開始上傳-可以在建立物件時上傳該物件。

由於多組件傳送的額外複雜性，建議使用提供受管理多組件傳送支援的適當 S3 程式庫、工具或 SDK:

雖然沒有用於多組件下載的專用 API，但可以在 GET 要求中使用 Range 標頭來僅讀取物件的特定部分，並且可以平行發出許多範圍讀取，就像上傳組件時一樣。 下載所有組件之後，就可以連結它們，並且可以檢查完整物件的完整性。 如前所述，建議使用 SDK 或其他工具，以避免手動管理這些傳送的複雜性。

透過將小型檔案聚集至較大的資料結構 (例如 [Parquet])，可以更好地處理需要儲存大量非常小型物件的工作流程。

對於大小大於 200mb 的物件，尤其是在較不穩定的網路中，或在需要考量封包流失的長距離範圍內，Aspera High-Speed Transfer 可以提供卓越效能。  Aspera 傳送也可以在單一要求內有效地上傳巢狀目錄結構。

節流控制批次刪除

S3 API 提供使用單一批次刪除要求來刪除最多 1,000 個物件的機制。 建議節流控制這些要求用戶端，以將 COS 系統內的貶損效能機會降至最低。  當發出的刪除數對系統而言太高時，用戶端會收到 HTTP 503 錯誤，錯誤訊息指出「減速」。

一致性影響

IBM Cloud Object Storage System 保證所有物件作業 (包括物件寫入、改寫、刪除、多組件作業及 ACL 修改) 的立即一致性。 儲存區建立也會立即一致。  與其他物件儲存體系統一樣，儲存區 meta 資料及配置最終會一致，這表示高分散式系統中的變更可能在短時間內不會同步。 這是因為 meta 資料快取提供顯著的效能好處，同時也防止阻斷服務攻擊的可能性。

部分應用程式會改寫相同的物件，或在短時間內反覆地刪除並重寫相同的物件。 這可能會導致 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 要求中，以啟用快取資訊的有效更新，且具有最小交易額外負擔量。 當用戶端想要更新有實體標籤的一或多個儲存回應時，用戶端應該在提出 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 錯誤時實作指數回復。

密碼調整

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