Cloud Storage 是一項高度可擴充的服務，採用自動調整資源配置技術，可達到極高的要求比率。這個頁面將說明資源調度的最佳做法，以及如何充分發揮 Cloud Storage 支援的效能。
自動調整資源配置
Cloud Storage 屬於多用戶群服務，意思是多個使用者要共用同一組基礎資源。為充分運用這些共用資源，儲存空間的初始 IO 容量為：
- 每秒約 1,000 個物件寫入要求，包括上傳、更新和刪除物件。請注意，Cloud Storage 對重複寫入「相同」物件名稱的限制也較低。
- 每秒約 5000 個物件讀取要求，包括列出物件、讀取物件資料，以及讀取物件中繼資料。
這些初始讀取和寫入速率平均為 1 MB 物件每月寫入 2.5 PB，讀取 13 PB。當特定 bucket 的要求比率增加時，Cloud Storage 會自動調度資源，並將要求負載分散到多個伺服器，自動增加該 bucket 的 IO 容量。
負載重新分配時間
當值區接近 IO 容量上限時，Cloud Storage 通常會在幾分鐘內偵測到，並相應地在更多伺服器之間重新分配負載。因此，如果 bucket 的要求率增加速度快於 Cloud Storage 執行這項重新分配作業的速度，您可能會遇到暫時性限制，特別是延遲時間和錯誤率較高的情況。如要避免遇到這類延遲或錯誤，請按照下文指示逐漸提高要求比率。
物件索引鍵編列
Cloud Storage 支援一致的物件列舉，讓使用者輕鬆對 Cloud Storage 執行資料處理工作流程。為提供一致的物件清單，Cloud Storage 會維護每個 bucket 的物件鍵索引。這個索引會依字典順序儲存，並在物件寫入或從 bucket 刪除時更新。如果新增及刪除的物件鍵都位於索引的一小部分範圍內，自然會增加爭用的機率。
Cloud Storage 會偵測這類爭用情形 (也稱為熱點)，並自動將受影響索引範圍的負載重新分配到多部伺服器。這個做法就像是調度值區的 IO 容量資源，存取新範圍的索引時 (例如按新的前置詞寫入物件)，您應按照下文指示逐漸提高要求比率；否則可能會出現延遲時間增加及錯誤率提高的暫時性問題。
最佳做法
下列各節提供最佳做法，說明如何提高要求率、選擇物件金鑰，以及分配要求，避免 bucket 受到暫時限制。請注意，除了這些每個 bucket 的考量事項，位於相同位置和專案的 bucket 也適用合併頻寬限制。
逐漸提高要求比率
為確保 Cloud Storage 自動調度資源功能一律提供最佳效能，如果值區在幾天內未達到高要求比率，或有新的物件索引鍵範圍，請逐步提高要求比率。不過如果您的要求比率低於每秒 1,000 次寫入要求或每秒 5,000 次讀取要求，就不需要採取逐步提高的做法。如果預期要求比率會超過這些門檻，請先將要求比率設為低於或接近門檻，然後逐步提高比率，每 20 分鐘最多提高一倍。
如果遇到任何問題，例如延遲或錯誤率增加，請暫停升級或暫時降低要求比率，讓 Cloud Storage 有更多時間擴充 bucket。在下列情況下，您應以指數輪詢方式重試要求：
- 收到
408和429回應代碼的錯誤。 - 收到含有
5xx回應代碼的錯誤。
相較於未啟用階層命名空間的 bucket，啟用階層命名空間的 bucket 讀取和寫入物件的初始每秒查詢次數 (QPS) 限制最多可提高 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 中大量上傳或刪除資料；不管是上傳或刪除，您可能都無法變更物件名稱。不過，您倒是可以決定上傳或刪除物件的順序，讓寫入或刪除比率儘可能達到最高。
如果要這麼做，您應將上傳或刪除作業分配給多個前置詞。舉例來說，假設您每個資料夾底下有很多資料夾和檔案待上傳，那麼從多個資料夾平行上傳，再隨機選擇要上傳的資料夾及檔案，會是比較好的策略。這個做法能讓系統在整個索引鍵範圍更平均分配負載，進而讓您在初次提高比率後達到高要求比率。
後續步驟
- 查看 Cloud Storage 儲存空間配額和限制。
- 瞭解向 Cloud Storage 傳送要求的建議重試策略。