要求比率和存取權分配指南

Cloud Storage 是一項可高度擴充的服務，採用自動調整資源配置技術，能有效達到極高的要求比率。這個頁面將說明資源調度的最佳做法，以及如何充分發揮 Cloud Storage 支援的效能。

自動調整資源配置

Cloud Storage 屬於多用戶群服務，意思是多個使用者要共用同一組基礎資源。為了充分利用這些共用資源，值區的初始 IO 容量為：

  • 大約每秒 1,000 次物件寫入要求，包括上傳、更新及刪除物件。請注意，Cloud Storage 對於相同物件名稱的重複寫入次數，也有較小的限制。
  • 每秒約 5,000 個物件讀取要求，包括列出物件、讀取物件資料和讀取物件中繼資料。

這些初始讀取和寫入速率一個月平均可針對 1 MB 物件寫入 2.5 PB 及讀取 13 PB。當特定值區的要求比率不斷增加，Cloud Storage 會將要求負載分配給多個伺服器，自動提高該值區的 IO 容量。

負載重新分配時間

值區達到 IO 容量限制時，Cloud Storage 通常會數分鐘偵測一次，並根據當下情況將負載重新分配給更多伺服器。因此，要是您值區要求比率的增加速度快過 Cloud Storage 進行上述重新分配作業的速度，系統就可能會出現暫時限制，特別是會有延遲時間變長、錯誤率提高的問題。如要避免遇到這類延遲或錯誤，請按照下文指示逐漸提高要求比率。

物件索引鍵編列

Cloud Storage 支援一致的物件清單編列，這項功能可讓使用者輕鬆對 Cloud Storage 執行資料處理工作流程。為了提供一致的物件清單編列，Cloud Storage 會仔細維護每個值區的物件索引鍵清單。這份索引清單按字典編列順序儲存，要是值區內有物件寫入或刪除，清單也會一併更新。新增或刪除索引鍵落在小範圍索引的物件，很容易提高爭用情況發生的機率。

Cloud Storage 會偵測這類爭用情況 (也稱為熱點)，並自動將受影響索引範圍的負載重新分配到多個伺服器。這個做法就像是調度值區的 IO 容量資源，存取新範圍的索引時 (例如按新的前置詞寫入物件)，您應按照下文指示逐漸提高要求比率；否則可能會出現延遲時間增加及錯誤率提高的暫時性問題。

最佳做法

以下部分介紹如何逐步提高要求比率、選擇物件索引鍵，以及重分配要求來避免值區出現暫時限制。請注意，除了這些每個值區的考量事項外，位於相同位置和專案的值區也適用合併頻寬限制。

逐漸提高要求比率

為確保 Cloud Storage 的自動調整資源配置功能可以發揮最佳效能，您應找出數天內要求比率不高或有新物件索引鍵範圍的值區，再逐漸提高這些值區的要求比率。不過如果您的要求比率低於每秒 1,000 次寫入要求或每秒 5,000 次讀取要求，就不需要採取逐步提高的做法。假如您預期要求比率會超過以上門檻，應該先從稍低或接近門檻值的要求比率開始，接著再以低於 20 分鐘的間隔來逐步加倍要求比率。

如果您遇到諸如延遲時間變長或錯誤率增加這類的問題，請先暫停逐步提高要求比率，或先降低要求比率，讓 Cloud Storage 有更充裕的時間可以調度您的值區資源。在下列情況下，您應重試要求並採用指數輪詢：

  • 收到 408 和 429 回應代碼的錯誤。
  • 收到含有 5xx 回應代碼的錯誤。

啟用階層命名空間的 bucket，讀取和寫入物件的初始每秒查詢次數 (QPS) 上限，比未啟用階層命名空間的 bucket 高達 8 倍。初始 QPS 越高，就越容易擴充資料密集型工作負載，並提升總處理量。如要進一步瞭解如何為 bucket 啟用階層式命名空間，請參閱「建立已啟用階層式命名空間的 bucket」。

善用命名慣例，將負載平均分配到各索引鍵範圍

使用依編號或時間戳記順序排列的名稱時，索引範圍的自動調整資源配置作業會變慢。這是因為要求會不斷轉移到新的索引範圍，導致重新分配負載困難重重且缺乏效率。

如果想要維持高要求比率，請避免使用依序排列的名稱。採用完全隨機的物件命名慣例，可以讓負載分配發揮最佳效益。如果您想要在物件名稱中加入序號或時間戳記，只要在序號或時間戳記前加上雜湊值，就能達到隨機命名的效果。

舉例來說，您原本想用的物件名稱是：

my-bucket/2016-05-10-12-00-00/file1
my-bucket/2016-05-10-12-00-00/file2
my-bucket/2016-05-10-12-00-01/file3
...

您可以計算原始物件名稱的 MD5 雜湊值，然後將雜湊的前 6 個字元當做物件名稱的前置詞。這樣一來，新的物件名稱就變成：

my-bucket/2fa764-2016-05-10-12-00-00/file1
my-bucket/5ca42c-2016-05-10-12-00-00/file2
my-bucket/6e9b84-2016-05-10-12-00-01/file3
...

隨機前置字串越長，在讀取和寫入速率極高時，自動調度資源的效果就越好。舉例來說，如果前置字元為 1 個隨機十六進位值，則有效自動調整資源配置的範圍，會從每秒 5000/1000 次讀取/寫入，提高至每秒約 80000/16000 次讀取/寫入，因為前置字元有 16 個可能的值。如果您的用途不需要更高的速率，1 個字元的隨機前置字串與 2 個字元或更長的隨機前置字串一樣有效，都能提高要求速率。

在共用前置詞後加上隨機值，調度資源的範圍將限於該前置詞之內

請注意，隨機字串不一定要安排在物件名稱的開頭；就算是放在共用前置詞後面，系統也能自動調整資源配置，只不過效果將限於該前置詞的範圍內，值區其餘部分則不納入考量。

例如：

my-bucket/images/animals/4ce4c6af-6d27-4fa3-8a91-5701a8552705/1.jpg
my-bucket/images/animals/9a495e72-1d85-4637-a243-cbf3e4a90ae7/2.jpg
...
my-bucket/images/landscape/585356ac-ce89-47a8-bdd2-78a86b58fee6/1.jpg
my-bucket/images/landscape/2550ae5b-395e-4243-a29b-bbf5aece60ef/2.jpg
...
my-bucket/images/clouds/1.jpg
my-bucket/images/clouds/2.jpg
...

上述命名可讓系統有效地自動調度 images/animals 和 images/landscape, 內的物件資源，但是無法調度 images/clouds。

在依序排列的前置詞後加上隨機值的效果不大

如同上文所述，在共用前置詞後面加上隨機字串，只對該前置詞下的自動調整資源配置有幫助；而一旦要求轉移到新的前置詞，先前這個自動調整資源配置的好處也就無用武之地。尤其是前置詞採順序格式時，還可能會遇到一些問題。

舉例來說，假設您每小時在新的時間戳記前置詞下寫入一次檔案：

my-bucket/2016-05-10-00/cf9a7b95-0d2e-4466-9596-840ff388ddbd
my-bucket/2016-05-10-00/f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket/2016-05-10-00/646d8272-4a88-4dc2-b2d4-d537c778df41
...
my-bucket/2016-05-10-01/bdcba6de-ac25-4c27-8550-0d08f249e69d
my-bucket/2016-05-10-01/a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket/2016-05-10-01/d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...

雖然自動調整資源配置有助於提高一段時間內依據某前置詞的寫入比率，但是該比率在每小時一開始都會重設。這就會導致寫入比率效能欠佳，且延遲時間及錯誤率也會定期增加。如果您某段時間內需要在不同的前置詞下寫入檔案，請務必將新前置詞平均分配到整個索引鍵範圍，以免發生上述問題。

重新排序大量作業，將負載平均分配到索引鍵範圍

有時候您可能會想在 Cloud Storage 中大量上傳或刪除資料；不管是上傳或刪除，您可能都無法變更物件名稱。不過，您倒是可以決定上傳或刪除物件的順序，讓寫入或刪除比率儘可能達到最高。

如果要這麼做，您應將上傳或刪除作業分配給多個前置詞。舉例來說，假設您每個資料夾底下有很多資料夾和檔案待上傳，那麼從多個資料夾平行上傳，再隨機選擇要上傳的資料夾及檔案，會是比較好的策略。這個做法能讓系統在整個索引鍵範圍更平均分配負載，進而讓您在初次提高比率後達到高要求比率。

後續步驟