Google Vault API 是一項共用服務,因此我們套用了配額與限制,以確保所有使用者都能合理使用這項服務,並維護 Google Workspace 系統的整體健康狀態。
產品數量上限
貴機構最多只能執行 20 項匯出作業。
API 要求配額
每個機構每分鐘允許所有專案及使用者讀取 600 個案件,包括透過 Vault API 和 vault.google.com 的要求。
下表列出每項專案每分鐘的要求限制:
每項專案每分鐘的讀取要求數 | |
---|---|
匯出、案件和已儲存的查詢 | 120 |
保留 | 228 |
長時間執行的作業 | 300 |
每項專案每分鐘的寫入要求數 | |
---|---|
匯出 | 20 |
保留 | 60 |
Matter 權限 | 30 |
Matter | 60 |
已儲存的查詢 | 45 |
每項專案每分鐘的搜尋 (計數) 要求數 | |
---|---|
搜尋次數 | 20 |
不同方法的配額用量
要求使用的配額會因呼叫的方法而異。下表列出各種方法的配額用量:
方法 | 配額費用 |
---|---|
matters.close matters.create matters.delete matters.reopen matters.update matters.undelete
|
1 個案件已讀取 1 個案件寫入 |
matters.count |
1 個 |
matters.get |
已讀取 1 個案件 |
matters.list |
10 次案件讀取 |
matters.addPermissions matters.removePermissions
|
1 個案件讀取 1 個案件寫入 1 個案件寫入權限 |
matters.exports.create |
1 次匯出讀取 10 次匯出寫入 |
matters.exports.delete |
1 次匯出寫入 |
matters.exports.get |
1 個匯出項目已讀取 |
matters.exports.list |
5 個匯出讀取 |
matters.holds.addHeldAccounts matters.holds.create matters.holds.delete matters.holds.removeHeldAccounts matters.holds.update
|
1 個案件已讀取 1 項案件寫入 1 項訴訟保留讀取狀態 1 項訴訟保留寫入 |
matters.holds.list |
1 個案件已讀取 3 個保留讀取 |
matters.holds.accounts.create matters.holds.accounts.delete matters.holds.accounts.list
|
1 個案件已讀取 1 項案件寫入 1 項訴訟保留讀取狀態 1 項訴訟保留寫入 |
matters.savedQueries.create matters.savedQueries.delete
|
1 個案件已讀取 1 項案件寫入 1 項已儲存的查詢讀取 1 項已儲存的查詢寫入 |
matters.savedQueries.get |
1 個案件已讀取 1 項已儲存的查詢 |
matters.savedQueries.list |
1 個案件已讀取 3 次已儲存的查詢讀取 |
operations.get |
1 項長時間執行的作業讀取作業 |
解決以時間為準的配額錯誤
如果超過每分鐘或個別機構的配額,通常會收到 429: Too many requests
HTTP 狀態碼回應。
如果是以時間為準的錯誤 (每 X 分鐘最多 N 個要求),我們建議您讓程式碼擷取例外狀況,並使用經過截斷的指數輪詢,確保裝置不會產生過多負載。
指數輪詢是網路應用程式的標準錯誤處理策略。指數輪詢演算法會以指數方式逐漸增加要求之間的等待時間來重試要求,最多可達輪詢時間上限。如果要求還是失敗,則要求之間的延遲時間會隨著時間增加,直到要求成功為止。
演算法範例
指數輪詢演算法會以指數方式重試要求,並將每次重試之間的等待時間增加到最長輪詢時間。例如:
- 向 Google Vault API 提出要求。
- 如果要求失敗,請等待 1 +
random_number_milliseconds
,然後重試要求。 - 如果要求失敗,請等待 2 +
random_number_milliseconds
,然後重試要求。 - 如果要求失敗,請等待 4 +
random_number_milliseconds
,然後重試要求。 - 依此類推,時間上限為
maximum_backoff
。 - 繼續等待和重試,直到重試次數上限,但不要增加每次重試的等待時間。
其中:
- 等待時間為
min(((2^n)+random_number_milliseconds), maximum_backoff)
,每次疊代 (要求) 時,n
會增加 1。 random_number_milliseconds
是小於或等於 1,000 的隨機毫秒數。這有助於避免多個用戶端在特定情況下同步處理並同時重試,避免在同步的 Wave 中傳送要求。random_number_milliseconds
的值會在每次重試要求後重新計算。maximum_backoff
通常是 32 或 64 秒,適當的值會因用途而異。
用戶端可以在達到 maximum_backoff
時間後繼續重試。之後重試時就不必繼續增加輪詢時間。舉例來說,如果用戶端使用的 maximum_backoff
時間為 64 秒,則達到這個值之後,用戶端可以每 64 秒重試一次。在某些情況下,用戶端應禁止無限期重試。
重試的等待時間和重試次數須視用途和網路狀況而定。
申請提高配額
視專案的資源用量而定,您可能會想要申請提高配額。服務帳戶的 API 呼叫將視為使用單一帳戶。我們不保證一定能核准您提出的配額增加要求。大量增加配額的要求可能需要較長時間才能通過核准。
並非所有專案的配額都相同。隨著 Google Cloud 的使用時間逐漸增加,配額可能也必須提高。如果您預期用量將大幅攀升,可以透過 Google Cloud 控制台的「配額」頁面主動要求調整配額。
詳情請參閱下列資源:
定價
Google Workspace 客戶不必支付額外費用,即可使用 Google Vault API。