配額與限制

本頁面說明 Cloud Storage 的配額與要求限制。

值區

  • 您在各項專案中建立或刪除值區之後,必須等待 2 秒左右的時間,才能繼續建立或刪除另一個值區。因此在大多數情況下,我們會建議您儘量減少使用值區而多使用物件。舉例來說,一般的設計原則是每位專案使用者僅使用一個值區。不過,如果您所設計的系統每秒會加入多位使用者,或是會透過機器人憑證建立物件,則可將多位使用者歸入同一個值區,並授予他們合適的權限,這樣您就不會被值區建立頻率的限制所束縛。

  • 如為高可用性應用程式,請儘量避免在其執行關鍵路徑上建立或刪除值區。值區名稱使用的是整體集中的命名空間,如果應用程式碰觸到這個命名空間,就會產生單點故障。基於這個原因和前述每 2 秒 1 項作業的頻率限制,我們會建議您為 Cloud Storage 中的高可用性服務預先建立所有必要值區。

  • 每個值區的更新頻率上限為每秒 1 次,因此您無法以更快的速度更新單一值區 (例如變更 CORS 設定)。

  • 每個值區最多只能允許 100 位成員擁有舊版身分與存取權管理角色

物件

  • 儲存在 Cloud Storage 中的個別物件有 5 TB 的大小限制。

  • 每個物件的更新頻率上限為每秒 1 次,因此您無法以更快的速度寫入單一物件。詳情請參閱「重要詞彙」中的物件不變原則

  • 同時寫入多個物件 (包括上傳、更新及刪除物件) 的作業沒有次數限制。值區一開始即可支援每秒約 1,000 次的寫入作業,之後則會視需求彈性調整

  • 物件讀取作業沒有次數限制。值區一開始即可支援每秒約 5,000 次的物件讀取作業,之後則會視需求彈性調整

  • 以可公開快取的物件而言,效能會大幅提升。如果您是透過單一物件控管多個用戶端,並想停用快取功能來提供最新資料,請採取以下步驟:

    • 建議將物件的 Cache-Control 中繼資料設定改為 public,並將 max-age 設為 15 至 60 秒。多數應用程式容許 1 分鐘的擴散時間,而較高的快取命中率將可大幅提升效能。

    • 透過與值區處在相同位置的 Google App Engine 應用程式傳輸 Proxy 資料。

    • 讓物件使用 Cache-Control: no-cache 指令,指定該物件不得存入邊緣快取以供後續要求使用。

    如要進一步瞭解 Cache-Control 指令,請參閱 RFC 7234: Cache-Control 一節。

  • 每個物件最多只能有 100 個存取控制清單 (ACL) 項目

  • 物件組合

    • 在單一組合要求中,您最多可以組合 32 個物件。

    • 儘管複合物件沒有組成元件的數量限制,不過與複合物件有關的 componentCount 中繼資料上限為 2,147,483,647。

    • 儲存在 Cloud Storage 中的複合物件有 5 TB 的總大小限制。

XML API 要求

  • 您在透過 XML API 傳送要求時,要求網址加上 HTTP 標頭的總資料量不得超過 16 KB。
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Storage
需要協助嗎?請前往我們的支援網頁