配額與限制
這份文件列出 BigQuery 適用的配額和系統限制。
- 「配額」有預設值,但通常可以申請調整。
- 「系統限制」是固定值,無法變更。
Google Cloud 使用配額來確保公平性,並減少資源使用量和可用性出現劇烈波動的情況。配額會限制 Google Cloud 專案可使用的Google Cloud 資源數量,且適用多種資源類型,包括軟硬體和網路元件。舉例來說,配額可能會限制能向特定服務發出的 API 呼叫次數、專案可同時使用的負載平衡器數量,或是可建立的專案數量。配額機制可防止服務過載,保障Google Cloud 使用者社群的權益,同時也有助於您管理自己的 Google Cloud 資源。
Cloud Quotas 系統具備以下功能:
如果嘗試使用的資源量超過配額限制,系統通常會阻擋該資源的存取活動,您所執行的工作就會失敗。
配額的計算通常是以 Google Cloud 專案為基準。在某個專案中使用資源,不會影響另一個專案的可用配額。在同一個 Google Cloud 專案內,所有應用程式和 IP 位址會共用配額。
詳情請參閱「Cloud Quotas 總覽」。
BigQuery 資源也有「系統限制」, 而且無法變更。
部分錯誤訊息會指出可提高的配額或限制,其他錯誤訊息則會指出無法提高的配額或限制。達到硬性限制表示您需要為工作負載導入暫時或永久的替代方案,或是最佳做法。即使配額或限制可以增加,也建議您這麼做。如要進一步瞭解這兩種錯誤,請參閱「排解配額和限制錯誤」。
根據預設,BigQuery 配額和限制會以每個專案為單位套用。如果配額和限制適用於不同基準,系統會標示出來;例如每個資料表的欄數上限,或是每個使用者的並行 API 要求數上限。具體政策會因資源供應狀況、使用者個人資料、服務使用情形和其他因素而有不同,並隨時可能變更,恕不另行通知。
配額補充
在一天當中,系統會定時為您補充每日配額,以便達到控管頻率限制行為的目標。另外,系統也會間歇性重新整理,以免在配額耗盡時發生服務長時間中斷的狀況。一般來說,系統在幾分鐘內即可提供更多配額,並非一天僅全面補充一次。
申請提高配額
如要調整大部分配額,請使用 Google Cloud 控制台。詳情請參閱「要求調整配額」。
如需在 Google Cloud 控制台中申請提高配額的逐步指南,請按一下「Guide me」(逐步引導):
設定配額用量上限
如要瞭解如何建立配額覆寫,藉此限制特定資源的用量,請參閱「建立配額覆寫」。
所需權限
如要在Google Cloud 控制台中查看及更新 BigQuery 配額,您需要與任何 Google Cloud配額相同的權限。詳情請參閱Google Cloud 配額權限。
疑難排解
如要瞭解如何排解配額和限制相關錯誤,請參閱「排解 BigQuery 配額錯誤」。
工作
無論是使用 Google Cloud 主控台、bq 指令列工具,還是透過程式使用 REST API 或用戶端程式庫執行工作,BigQuery 代表您執行的工作都會受到配額和限制規範。
待處理工作
以下限制適用於 BigQuery 中待處理的工作:
| 限制 | 預設 | 附註 |
|---|---|---|
| 待處理工作數量上限 | 每個區域每項專案 50,000 項工作 | 可處於待處理狀態的並行工作數量。此上限無法提高。詳情請參閱「排解 BigQuery 配額錯誤」。 |
查詢工作
以下配額適用於您在執行互動式查詢、排程查詢時自動建立的查詢工作,以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作。
如需疑難排解資訊,請參閱 BigQuery 疑難排解頁面。
| 配額 | 預設 | 附註 |
|---|---|---|
| 每日查詢用量 | 200 Tebibytes (TiB) | 這項配額僅適用於隨選查詢定價模式。 您的專案每天最多可執行 200 TiB 的查詢。您可以隨時變更這項限制。如要進一步瞭解費用控管,請參閱「建立自訂查詢配額」。 在 Google Cloud 控制台中查看配額 |
| 每位使用者每天的查詢用量 | 無限制 | 這項配額僅適用於隨選查詢定價模式。 使用者每日可執行的查詢量沒有預設上限,您可以隨時設定上限。無論使用者上限為何,專案中所有使用者的總用量絕不會超過每日查詢用量上限。如要進一步瞭解費用控管,請參閱「建立自訂查詢配額」。 在 Google Cloud 控制台中查看配額 |
| GoogleSQL 聯合查詢每日跨區域位元組數 | 1 TB | 如果
BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同,就會視為跨區域查詢。您的專案每日可執行高達 1 TB 的跨地區查詢。請參閱 Cloud SQL 聯合查詢。 在 Google Cloud 控制台中查看配額 |
| BigQuery Omni 每日傳輸的位元組數 | 1 TB |
您每天最多可從 Amazon S3 值區或 Azure Blob 儲存體轉移 1 TB 的資料。
在 Google Cloud 控制台中查看配額 |
| 每個區域配對的每日全域查詢傳輸位元組數 | 180 TB | 使用全域查詢時,每個地區配對每天最多可轉移 180 TB 的資料。 |
| 每個專案的全球查詢複製工作 | 10,000 |
執行全域查詢時,每個專案最多可執行 10,000 項複製工作,在區域之間複製資料。一項全域查詢可能會觸發多項複製作業。
在 Google Cloud 控制台中查看配額 |
| 全域查詢中單一複製工作傳輸的位元組數 | 100 GB | 如果複製工作是全域查詢的一部分,則無法轉移超過 100 GB 的資料。 |
| 更新全域專案層級選項 | 5 |
執行變更全域設定選項的 DDL 陳述式時,每 10 秒最多可執行五個陳述式。這項限制適用於下列 DDL 陳述式: |
以下限制適用於您在執行互動式查詢、排程查詢時自動建立的查詢工作,以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作:
| 限制 | 預設 | 附註 |
|---|---|---|
| 佇列中的互動式查詢數量上限 | 1,000 次查詢 | 您的專案最多可將 1,000 個互動式查詢加入佇列。 如果互動式查詢超出這項限制,系統會傳回配額錯誤。如要排解這些錯誤,請參閱「避免大量互動式查詢超出限制」。 |
| 佇列中的批次查詢數量上限 | 20,000 次查詢 | 您的專案最多可將 20,000 個批次查詢加入佇列。如果額外的批次查詢超出這項限制,系統會傳回配額錯誤。 |
| 對 Bigtable 外部資料來源進行互動式查詢的並行查詢數量上限 | 16 項查詢 | 您的專案最多可對單一 Bigtable 外部資料來源執行 16 個並行查詢。 |
| 包含遠端函式的並行查詢數量上限 | 10 項查詢 | 每個專案最多可使用 遠端函式執行十個並行查詢。 |
| 並行多陳述式查詢數量上限 | 1,000 個多陳述式查詢 | 您的專案最多可同時執行 1,000 個多重陳述式查詢。如要瞭解與多重陳述式查詢相關的其他配額和限制,請參閱「 多重陳述式查詢」。 |
| 包含 UDF 的舊版 SQL 查詢並行數量上限 | 6 項查詢 | 您的專案最多可同時執行六個包含使用者定義函式 (UDF) 的舊版 SQL 查詢。這項限制同時適用於互動式和批次查詢。包含 UDF 的互動式查詢也會計入互動式查詢的並行限制。這項限制不適用於 GoogleSQL 查詢。 |
| 每日查詢量限制 | 無限制 | 預設情況下,每日查詢大小沒有限制。不過,您可以建立自訂配額,設定使用者可查詢的資料量上限,藉此控管每日查詢用量或每位使用者每日查詢用量。 |
| 每日目的地資料表更新限制 | 請參閱每日資料表作業數量上限。 |
查詢工作中的目的地資料表更新次數,會計入目的地資料表每日資料表作業次數上限。目的地資料表更新包括使用 Google Cloud 主控台、bq 指令列工具或透過呼叫 jobs.query 和查詢類型 jobs.insert API 方法執行查詢時執行的附加作業和覆寫作業。 |
| 查詢/多重陳述式查詢執行時間限制 | 6 小時 |
查詢或多重陳述式查詢最多可執行 6 小時,然後就會失敗。不過,有時系統會重新嘗試執行查詢。每項查詢最多可嘗試執行三次,每次嘗試最多可執行 6 小時。因此,查詢的總執行時間可能會超過 6 小時。
|
| 每個查詢參照的資源數量上限 | 1,000 項資源 |
完全展開後,查詢最多可參照 1,000 個不重複的資料表、不重複的檢視區塊、不重複的
使用者定義函式 (UDF) 和不重複的資料表函式。這項限制包括:
|
| SQL 查詢字元長度上限 | 1,024k 個字元 |
SQL 查詢的長度上限為 1,024,000 個字元。這項限制包含註解和空白字元。如果查詢過長,您會收到下列錯誤訊息:The query is too large.為遵守這項限制,請考慮以查詢參數取代大型陣列或清單,並將長查詢分成多個查詢。 |
| 未解析的舊版 SQL 查詢長度上限 | 256 KB |
未解析的舊版 SQL 查詢長度上限為 256 KB。如果查詢較長,您會收到以下錯誤訊息:The query
is too large.
如要遵守這項限制,請考慮以查詢參數取代大型陣列或清單。
|
| 未解析的 GoogleSQL 查詢長度上限 | 1 MB |
未解析的 GoogleSQL 查詢長度上限為 1 MB。如果查詢較長,您會收到以下錯誤訊息:The query is too
large.
如要符合這項限制,請考慮以查詢參數取代大型陣列或清單。
|
| 已解析的舊版和 GoogleSQL 查詢長度上限 | 12 MB | 就已解析的查詢而言,查詢參照的所有檢視表和萬用字元資料表的長度也會計入該查詢的長度限制額度。 |
| GoogleSQL 查詢參數數量上限 | 10,000 個參數 | GoogleSQL 查詢最多可有 10,000 個參數。 |
| 要求大小上限 | 10 MB | 要求大小最多可達 10 MB,包括查詢參數等額外屬性。 |
| 回覆大小上限 | 10 GB 的已壓縮檔 | 大小會因資料壓縮率而異。實際的回應大小可能會遠超過 10 GB。將很大的查詢結果寫入目的地資料表時,回應大小沒有上限。 |
| 資料列大小上限 | 100 MB | 資料列大小上限為約略值,因為這項限制是根據資料列資料的內部呈現方式而定。系統會在查詢工作執行作業的某些階段對資料列大小設定上限。 |
| 資料表、查詢結果或檢視表定義中的資料欄上限 | 10,000 欄 | 資料表、查詢結果或檢視表定義最多可有 10,000 個資料欄。包括巢狀和重複的資料欄。已刪除的資料欄仍會計入資料欄總數。如果您刪除欄,可能要等到總數重設,才會收到配額錯誤訊息。 |
| 以量計價的並行運算單元數上限 |
每個專案 2,000 個運算單元 每個機構 20,000 個運算單元 |
以量計價的專案最多可有 2,000 個並行運算單元。 機構層級的並行時段上限為 20,000 個。 如果機構的總需求量超過 20,000 個運算單元,BigQuery 會盡量在機構內的專案之間公平分配運算單元。BigQuery 運算單元會由單一專案中的所有查詢共用。BigQuery 可能會透過爆發功能提供高於這項限制的運算單元數量,藉此加快查詢速度。實際容量視情況而定。 如要查看您使用的運算單元數量,請參閱使用 Cloud Monitoring 監控 BigQuery。 |
| 以量計價模式下,每個掃描資料的 CPU 使用量上限 | 每掃描 1 MiB 需 256 個 CPU 秒數 |
以量計價方案的查詢每掃描 1 MiB 的資料,最多可使用約 256 秒的 CPU 時間。如果查詢處理的資料量過大,導致 CPU 負荷過重,查詢就會失敗並顯示 billingTierLimitExceeded 錯誤。
詳情請參閱「
錯誤訊息」。 |
| 多陳述式交易資料表異動 | 100 個表格 | 一項 交易最多可變動 100 個資料表中的資料。 |
| 多陳述式交易分割區修改 | 100,000 次分區修改 | 一筆 交易最多可執行 100,000 次分區修改作業。 |
| BigQuery Omni 查詢結果大小上限 | 20 GiB 未壓縮 | 查詢 Microsoft Azure 或 AWS 資料時,結果大小上限為 20 GiB 邏輯位元組。如果查詢結果大於 20 GiB,建議將結果匯出至 Amazon S3 或 Blob 儲存空間。詳情請參閱 BigQuery Omni 限制。 |
| BigQuery Omni 每日查詢結果總大小 | 1 TB | 每個專案的查詢結果總大小為每天 1 TB。
詳情請參閱 BigQuery Omni 限制。 |
| BigQuery Omni 的資料列大小上限 | 10 MiB | 查詢 Microsoft Azure 或 AWS 資料時,資料列大小上限為 10 MiB。詳情請參閱 BigQuery Omni 限制。 |
| 轉移全域查詢 | 2 GiB/秒 | 每個專案、每個區域配對的全域查詢所用移轉頻寬 |
雖然已排定的查詢會使用 BigQuery 資料移轉服務功能,但這類查詢並非移轉作業,也不受載入工作限制的限制。
擷取工作
以下限制適用於使用 bq 指令列工具、 Google Cloud 控制台或解壓縮類型 jobs.insert API 方法,從 BigQuery 擷取資料的工作。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每日擷取位元組數上限 | 50 TiB |
使用共用運算單元集區,即可每日從專案中擷取最高 50 TiB(太位元組) 的資料,無須支付費用。您可以設定 Cloud Monitoring 警告政策,在擷取的位元組數達到特定門檻時收到通知。如要每天擷取超過 50 TiB(太位元組) 的資料,請執行下列其中一項操作:
|
| 每日擷取工作數上限 | 100,000 項擷取工作 |
每個專案每天最多可執行 100,000 項擷取作業。
如要每天執行超過 10 萬項擷取作業,請採取下列任一做法:
|
| 單一檔案可擷取的資料表大小上限 | 1 GB | 您最多可將 1 GB 的資料表資料擷取至單一檔案。如要擷取超過 1 GB 的資料,請使用 萬用字元將資料擷取到多個檔案。將資料擷取至多個檔案時,各個檔案的大小會有所差異。在某些情況下,輸出檔案的大小會超過 1 GB。 |
| 每個擷取工作 萬用字元 URI | 500 個 URI | 擷取工作最多可有 500 個萬用字元 URI。 |
如要進一步瞭解如何查看目前的擷取工作用量,請參閱「查看目前的配額用量」。如需疑難排解資訊,請參閱「匯出疑難排解」。
載入工作
以下限制適用於您使用Google Cloud 主控台、bq 指令列工具或載入類型 jobs.insert API 方法,將資料載入 BigQuery 時。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個資料表每日載入的工作數量 | 1,500 項工作 | 載入工作 (包括失敗的載入工作) 會計入目的地資料表每日的資料表作業次數上限。如要瞭解標準資料表和分區資料表每天的資料表作業數量限制,請參閱「資料表」一文。 |
| 每日載入的工作數量 | 100,000 項工作 | 每 24 小時,專案最多可補充 100,000 個載入工作配額。 失敗的載入作業會計入這項限制。在某些情況下,如果前一天的配額未完全用盡,您可以在 24 小時內執行超過 100,000 個載入作業。 |
| 每個資料表的欄數上限 | 10,000 欄 | 每個資料表最多可有 10,000 個資料欄。包括巢狀和重複的資料欄。 |
| 每個載入作業的大小上限 | 15 TB | 所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案的總大小最多可達 15 TB。這項限制不適用於有預留項目的工作。 |
| 工作設定中的來源 URI 數量上限 | 10,000 個 URI | 工作設定最多可有 10,000 個來源 URI。 |
| 每項載入工作的檔案數量上限 | 10,000,000 個檔案 | 載入工作最多可有 1000 萬個檔案,包括與所有萬用字元 URI 相符的所有檔案。 |
| 來源 Cloud Storage 值區中的檔案數量上限 | 大約 60,000,000 個檔案 | 載入工作可從最多約 6,000 萬個檔案的 Cloud Storage 值區讀取資料。 |
| 載入工作執行時間限制 | 6 小時 | 如果載入工作執行時間超過六小時,就會失敗。 |
| Avro:檔案資料區塊大小上限 | 16 MB | Avro 檔案資料區塊的大小上限為 16 MB。 |
| CSV:儲存格大小上限 | 100 MB | CSV 儲存格大小上限為 100 MB。 |
| CSV:資料列大小上限 | 100 MB | CSV 列的大小上限為 100 MB。 |
| CSV:檔案大小上限 - 壓縮 | 4 GB | 壓縮後的 CSV 檔案大小上限為 4 GB。 |
| CSV:檔案大小上限 - 未壓縮 | 5 TB | 未壓縮 CSV 檔案的大小上限為 5 TB。 |
| 以換行符號分隔的 JSON (ndJSON):最大列大小 | 100 MB | ndJSON 列的大小上限為 100 MB。 |
| ndJSON:檔案大小上限 - 壓縮 | 4 GB | 壓縮後的 ndJSON 檔案大小上限為 4 GB。 |
| ndJSON:檔案大小上限 - 未壓縮 | 5 TB | 未壓縮 ndJSON 檔案的大小上限為 5 TB。 |
如果更新頻率過高,導致您經常超出載入工作限制,請考慮改為 將資料串流至 BigQuery。
如要瞭解如何查看目前的載入工作用量,請參閱「查看目前的配額用量」。
BigQuery 資料移轉服務載入工作配額注意事項
BigQuery 資料移轉服務移轉作業建立的載入工作,會計入 BigQuery 的載入工作配額。因此,請務必留意您在各項專案中啟動的移轉作業數量,以免移轉與其他載入工作產生 quotaExceeded 錯誤。
您可以使用以下公式估算移轉作業所需的載入工作數量:
Number of daily jobs = Number of transfers x Number of tables x
Schedule frequency x Refresh window
在上述公式中:
Number of transfers是您在專案中啟用的移轉作業設定檔數量。Number of tables是各個移轉作業類型建立的資料表數量,資料表數量因移轉作業的類型而異:- Campaign Manager 移轉作業會建立大約 25 個資料表。
- Google Ads 移轉作業會建立大約 60 個資料表。
- Google Ad Manager 移轉作業會建立大約 40 個資料表。
- Google Play 移轉作業會建立大約 25 個資料表。
- Search Ads 360 移轉作業會建立大約 50 個資料表。
- YouTube 移轉作業會建立大約 50 個資料表。
Schedule frequency說明了移轉作業的執行頻率。視移轉作業類型而定,移轉作業的執行時間表可能不同:Refresh window是資料移轉作業中包含的天數,輸入 1 即代表不會每日執行補充作業。
複製工作
以下限制適用於複製資料表的 BigQuery 工作,包括建立標準資料表、資料表副本或資料表快照副本的工作,以及建立資料表副本或資料表快照副本的工作。這些限制適用於使用 Google Cloud 主控台、bq 指令列工具或jobs.insert 方法建立的工作,這些方法會在工作設定中指定 copy 欄位。無論複製工作成功與否,都會計入這些限制。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個目的地資料表每日的複製工作數量 | 請參閱「每日資料表作業數量」。 | |
| 每日複製工作數量 | 100,000 項工作 | 每個專案每天最多可執行 100,000 項複製作業。 |
| 每個目的地資料表每日的跨區域複製工作數量 | 100 項工作 | 每個專案每天最多可為目的地資料表執行 100 項跨區域複製工作。 |
| 每日跨區域複製工作數 | 2,000 項工作 | 每個專案每日最多可執行 2,000 個跨區域複製作業。 |
| 要複製的來源資料表數量 | 1,200 個來源資料表 | 每個複製工作最多可複製 1,200 個來源資料表。 |
如要瞭解如何查看目前的複製工作用量,請參閱「複製工作 - 查看目前的配額用量」。如要瞭解如何排解複製工作問題,請參閱「每個專案每日複製工作數上限配額錯誤」。
以下限制適用於 複製資料集:
| 限制 | 預設 | 附註 |
|---|---|---|
| 來源資料集中的資料表數上限 | 25,000 個表格 | 來源資料集最多可包含 25,000 個資料表。 |
| 每次複製作業可複製到同區域目的地資料集的資料表數量上限 | 20,000 個表格 | 專案每次最多可複製 20,000 個資料表到同地區的目的地資料集。如果來源資料集包含超過 20,000 個資料表,BigQuery 資料移轉服務會排定依序執行作業,每次複製最多 20,000 個資料表,直到所有資料表都複製完畢為止。這些執行作業預設間隔 24 小時,使用者可自訂間隔,最短為 12 小時。 |
| 每次複製作業最多可複製到不同區域的目的地資料集 | 1,000 個表格 | 專案每次最多可複製 1,000 個資料表到其他區域的目的地資料集。如果來源資料集包含超過 1,000 個資料表,BigQuery 資料移轉服務會排定依序執行作業,每次複製最多 1,000 個資料表,直到所有資料表都複製完畢為止。這些執行作業會以 24 小時的預設間隔分隔,使用者可自訂間隔,最短為 12 小時。 |
預留項目
下列配額適用於預訂:
| 配額 | 預設 | 附註 |
|---|---|---|
| 歐盟地區的總席位數 | 5,000 個運算單元 |
您可以使用 Google Cloud 控制台,在歐盟多區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
| 美國區域的運算單元總數 | 10,000 個運算單元 |
您可以使用 Google Cloud 控制台,在美國多區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
us-east1 區域的運算單元總數
|
4,000 個運算單元 |
您可以在列出的區域中,使用 Google Cloud 控制台購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
下列地區的運算單元總數:
|
2,000 個運算單元 |
您可以在 Google Cloud 控制台中,為每個列出的區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
下列地區的運算單元總數:
|
1,000 個運算單元 |
您可以在 Google Cloud 控制台中,於每個列出的區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
| BigQuery Omni 區域的運算單元總數 | 100 個運算單元 |
您可以使用 Google Cloud 控制台,在 BigQuery Omni 區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
| 所有其他地區的總空位數 | 500 個運算單元 |
使用 Google Cloud 控制台在每個其他區域購買的 BigQuery 運算單元數量上限。 在 Google Cloud 控制台中查看配額 |
以下限制適用於預訂:
| 限制 | 值 | 附註 |
|---|---|---|
| 運算單元預留項目的 管理專案數量 | 每個機構 10 個專案 | 組織內可包含預留項目或特定位置/區域運算單元有效承諾的專案數量上限。 |
| 標準版預留項目數量上限 | 每項專案 10 個預留項目 | 每個機構的每個位置 / 區域,管理專案的 Standard 版預留項目數量上限。 |
| Enterprise 或 Enterprise Plus 版的預留項目數量上限 | 每項專案 200 個預留項目 | 機構中每個管理專案在特定位置 / 區域的 Enterprise 或 Enterprise Plus 版本預留項目數量上限。 |
與 CONTINUOUS 工作類型預留項目指派相關聯的預留項目運算單元數量上限。 |
500 個運算單元 |
如要建立工作類型為 CONTINUOUS 的保留項目指派作業,相關聯的保留項目不得超過 500 個時段。 |
資料集
以下限制適用於 BigQuery資料集:
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料集數量上限 | 無限制 | 專案可擁有的資料集數量沒有限制。 |
| 每個資料集的資料表數量 | 無限制 | 如使用 API 呼叫,當資料集中的資料表數接近 50,000 個時,列舉效能會下降。 Google Cloud 控制台最多可為每個資料集顯示 50,000 個資料表。 |
| 資料集存取控制清單中的授權資源數量 | 2,500 項資源 |
資料集的存取控制清單最多可有 2,500 個授權資源,包括授權檢視表、授權資料集和授權函式。 如果授權檢視區塊數量過多而超出上限,建議將檢視區塊分組到授權資料集中。設計新的 BigQuery 架構 (尤其是多租戶架構) 時,建議將相關檢視區塊分組到授權資料集中。 |
| 每個資料集每 10 秒的資料集更新作業數量 | 5 項作業 |
專案每 10 秒最多可執行五項資料集更新作業。
資料集更新限制適用於下列項目執行的所有中繼資料更新作業:
|
| 資料集說明的長度上限 | 16,384 個半形字元 | 為資料集新增說明文字時,最多可以輸入 16,384 個字元。 |
資料表
所有資料表
以下限制適用於所有 BigQuery 資料表。
| 限制 | 預設 | 附註 |
|---|---|---|
| 欄名稱長度上限 | 300 個半形字元 | 欄名不得超過 300 個字元。 |
| 資料欄說明的長度上限 | 1,024 個字元 | 您在資料欄中新增說明時,最多可以輸入 1,024 個字元。 |
| 巢狀記錄深度上限 | 15 個等級 |
RECORD 類型的資料欄可以包含巢狀 RECORD 型別,也稱為子項記錄。巢狀結構深度上限為 15 層。
這項限制與記錄是否為純量或陣列形式 (重複) 無關。
|
| 資料表說明的長度上限 | 16,384 個半形字元 | 為表格新增說明文字時,最多可以輸入 16,384 個字元。 |
如要瞭解如何排解資料表配額或限制相關問題,請參閱 BigQuery 疑難排解頁面。
標準資料表
以下限制適用於 BigQuery 標準 (內建)資料表:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每日資料表修改次數 | 1,500 項修改 | 每個專案每天最多可修改每個資料表 1,500 次。 載入工作、複製工作或 查詢工作附加或覆寫資料表資料時,會計為對資料表進行一次修改。這個限制無法變更。 DML 陳述式不計入每日資料表修改次數。 系統會排除串流資料,且不會計入每日資料表修改次數。 |
| 每個資料表的資料表中繼資料更新作業頻率上限 | 每 10 秒 5 項作業 |
每個資料表每 10 秒最多可進行五項資料表中繼資料更新作業。這項限制適用於下列項目執行的所有資料表中繼資料更新作業:
DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。請注意,雖然 DML 陳述式會計入這項限制,但如果達到限制,DML 陳述式不會受到限制。DML 作業有專屬的速率限制。
如果超過這項限制,系統會顯示類似
|
| 每個資料表的欄數上限 | 10,000 欄 | 每個資料表、查詢結果或檢視表定義最多可有 10,000 個資料欄,包括巢狀和重複的資料欄。 |
外部資料表
以下限制適用於以 Parquet、ORC、Avro、CSV 或 JSON 格式將資料儲存在 Cloud Storage 的 BigQuery 資料表:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個外部資料表的來源 URI 數量上限 | 10,000 個 URI | 每個外部資料表最多可有 10,000 個來源 URI。 |
| 每個外部資料表的檔案數量上限 | 10,000,000 個檔案 | 外部資料表最多可有 1000 萬個檔案,包括與所有萬用字元 URI 相符的所有檔案。 |
| 每個外部資料表在 Cloud Storage 中儲存資料的大小上限 | 600 TB | 外部資料表在所有輸入檔案中最多可有 600 TB。這項限制適用於儲存在 Cloud Storage 的檔案大小;這個大小不同於查詢定價公式使用的大小。如果是外部分區資料表,這項限制會在 分區修剪後套用。 |
| 來源 Cloud Storage 值區中的檔案數量上限 | 大約 3 億個檔案 | 外部資料表最多可參照包含約 3 億個檔案的 Cloud Storage bucket。如果是外部分區資料表,這項限制會在 分區修剪前套用。 |
分區資料表
以下限制適用於 BigQuery 已分割資料表。
分區限制適用於下列所有載入工作、複製工作和查詢工作:將資料附加至目的地分區或覆寫目的地分區。
單一工作可能會影響多個分區。舉例來說,查詢工作和載入工作可以寫入多個分區。
BigQuery 會透過受工作影響的分區數量來判斷工作占用的限制。不過,串流資料插入並不會影響這項限制。
如要瞭解如何採取策略,確保不超過已分割資料表的限制,請參閱「 排解配額錯誤」。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個分區資料表的分區數量 | 10,000 個分割區 | 每個已分割的資料表最多可有 10,000 個分區。如果超出這個限制,請考慮使用 分群,而不是分區。 |
| 單一工作修改的分區數量 | 4,000 個分區 | 每個工作作業 (查詢或載入作業) 最多可影響 4,000 個分區。 BigQuery 會拒絕任何嘗試修改超過 4,000 個分區的查詢或載入工作。 |
| 每個分區資料表每天在擷取時間內可修改分區的次數 | 11,000 項修改 |
專案每天最多可進行 11,000 次分割區修改。 分區修改是指在分區資料表中附加、更新、刪除或截斷資料。每種資料修改類型都會計為一次分區修改。舉例來說,刪除一列資料會計為一次分區修改,刪除整個分區也會計為一次修改。如果您從一個分區刪除一列資料,然後插入另一個分區,這會計為兩次分區修改。 使用 DML 陳述式或串流 API 進行的修改,不會計入每日分區修改次數。 |
| 每個依資料欄分區的資料表每日可修改分區的次數 | 30,000 項修改 | 您的專案每天最多可對資料欄分區資料表進行 30,000 次分區修改。 DML 陳述式「不會」計入每日分區修改次數。 串流資料不會計入每日分區修改次數。 |
| 每個分區資料表的資料表中繼資料更新作業頻率上限 | 每 10 秒 50 次修改 |
每個分區資料表每 10 秒最多可進行 50 次修改。這項限制適用於所有分區資料表中繼資料更新作業,包括下列項目執行的作業:
DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。
如果超過這項限制,系統會顯示類似
如要找出計入這項限制的作業,可以 檢查記錄。 |
| 範圍分區的可能範圍數量 | 10,000 個範圍 | 範圍分區資料表最多可有 10,000 個可能的範圍。 建立資料表時,這項限制會套用至分區規格。建立資料表後,這項限制也會套用至實際的分區數量。 |
資料表本機副本
以下限制適用於 BigQuery資料表副本:
| 限制 | 預設 | 附註 |
|---|---|---|
| 鏈結中的複製和快照數量上限 | 3 個資料表副本或快照 | 複製和快照的組合最多只能有 3 層。複製或建立基本資料表的快照時,您只能再複製或建立結果兩次;嘗試第三次複製或建立結果快照時,會發生錯誤。舉例來說,您可以建立基礎資料表的副本 A、建立副本 A 的快照 B,以及建立快照 B 的副本 C。如要建立第三層級複製或快照的其他副本,請改用複製作業。 |
| 基本資料表的副本和快照數量上限 | 1,000 個資料表副本或快照 | 特定基本資料表現有的副本和快照總數不得超過 1,000 個。舉例來說,如果您有 600 個快照和 400 個副本,就會達到上限。 |
資料表快照
以下限制適用於 BigQuery資料表快照:
| 限制 | 預設 | 附註 |
|---|---|---|
| 並行資料表快照工作數量上限 | 100 項工作 | 您的專案最多可同時執行 100 個表格快照工作。 |
| 每日可執行的資料表快照工作數量上限 | 50,000 項工作 | 每個專案每天最多可執行 50,000 個資料表快照工作。 |
| 每個資料表每日可執行的資料表快照作業數量上限 | 50 項工作 | 每個專案每天最多可為每個資料表執行 50 個資料表快照工作。 |
| 每個資料表快照每 10 秒可更新中繼資料的次數上限。 | 5 則更新 | 專案每 10 秒最多可更新資料表快照的中繼資料五次。 |
| 鏈結中的複製和快照數量上限 | 3 個資料表副本或快照 | 複製和快照的組合深度上限為 3。複製或建立基本資料表的快照時,您只能再複製或建立結果兩次;嘗試第三次複製或建立結果快照時,會發生錯誤。舉例來說,您可以建立基礎資料表的副本 A、建立副本 A 的快照 B,以及建立快照 B 的副本 C。如要建立第三層級複製或快照的其他副本,請改用複製作業。 |
| 基本資料表的副本和快照數量上限 | 1,000 個資料表副本或快照 | 特定基本資料表現有的副本和快照總數不得超過 1,000 個。舉例來說,如果您有 600 個快照和 400 個副本,就會達到上限。 |
瀏覽次數
邏輯檢視表
以下限制適用於 BigQuery 標準檢視區塊:
| 限制 | 預設 | 附註 |
|---|---|---|
| 巢狀檢視表層級數量上限 | 16 個等級 |
BigQuery 最多支援 16 層的巢狀檢視表。您最多可以建立這個數量的檢視區塊,但查詢最多只能有 15 個層級。如果超過上限,BigQuery 會傳回 INVALID_INPUT 錯誤。 |
| 用於定義檢視表的 GoogleSQL 查詢長度上限 | 256 K 個字元 | 定義檢視表的單一 GoogleSQL 查詢長度不得超過 256,000 個字元。這項限制適用於單一查詢,不包含查詢中參照的檢視區塊長度。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| 檢視畫面說明的長度上限 | 16,384 個半形字元 | 為檢視區塊新增說明文字時,最多可以輸入 16,384 個字元。 |
具體化檢視表
以下限制適用於 BigQuery 具體化檢視區塊:
| 限制 | 預設 | 附註 |
|---|---|---|
| 基底資料表參照 (相同專案) | 100 個具體化檢視表 | 每個基礎資料表最多可由同一專案中的 100 個具體化檢視區塊參照。 |
| 基底資料表參照 (整個機構) | 500 個具體化檢視表 | 整個機構最多可有 500 個具體化檢視區塊參照每個基本資料表。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| 具體化檢視表說明的長度上限 | 16,384 個半形字元 | 為具體化檢視表新增說明文字時,最多可以輸入 16,384 個字元。 |
| materialized view 重新整理工作執行時間限制 | 12 小時 | 具體化檢視區塊重新整理作業最多可執行 12 小時,之後就會失敗。 |
搜尋索引
以下限制適用於 BigQuery 搜尋索引:
| 限制 | 預設 | 附註 |
|---|---|---|
每個專案每天在每個區域的 CREATE INDEX DDL 陳述式數量 |
500 項作業 |
每個專案每天在一個區域內最多可發出 500 次 CREATE INDEX DDL 作業。
|
| 每天每個資料表的搜尋索引 DDL 陳述式數量 | 20 項作業 |
每個專案每天最多可對每個資料表發出 20 個 CREATE INDEX 或 DROP INDEX DDL 作業。
|
| 機構可建立搜尋索引的資料表資料總大小上限 (不透過預留項目執行) | 多個區域:100 TB;所有其他區域:20 TB |
如果貴機構中含有索引的資料表總大小低於所在區域的限制,您就可以為資料表建立搜尋索引:US和 EU 多地區為 100 TB,所有其他地區為 20 TB。如果索引管理工作在您自己的預訂中執行,則不適用這項限制。 |
| 每個資料表以資料欄精細度建立索引的資料欄數 | 每個資料表 63 欄 |
表格最多可有 63 欄,且 index_granularity 設為 COLUMN。透過設定 default_index_column_granularity 選項以 COLUMN 精細程度建立索引的資料欄,會計入這項限制。以 GLOBAL 細微程度建立索引的資料欄數量沒有限制。詳情請參閱以資料欄精細度建立索引。 |
向量索引
以下限制適用於 BigQuery 向量索引:
| 限制 | 預設 | 附註 |
|---|---|---|
| 基本資料表資料列數量下限 | 5,000 列 | 表格至少要有 5,000 列,才能建立向量索引。 |
索引類型 IVF 的基本資料表列數上限 |
10,000,000,000 列 |
資料表最多可有 10,000,000,000 列,以建立 IVF 向量索引 |
索引類型的基本資料表列數上限 TREE_AH
|
200,000,000 列 |
資料表最多可有 200,000,000 列,以建立 TREE_AH 向量索引 |
分區索引類型的基本資料表列數上限
TREE_AH |
總共 10,000,000,000 個資料列 每個分區 200,000,000 個資料列 |
資料表最多可有 10,000,000,000 列,每個分區最多可有 200,000,000 列,以建立TREE_AH分區向量索引。
|
| 已建立索引的資料欄中陣列的大小上限 | 4,096 個元素 | 要建立索引的資料欄陣列最多可有 4,096 個元素。 |
| 向量索引填入作業的資料表大小下限 | 10 MB | 如果是在小於 10 MB 的資料表上建立向量索引,系統就不會填入索引。同樣地,如果從向量索引資料表刪除資料,導致資料表大小低於 10 MB,向量索引就會暫時停用。無論您是否為索引管理作業使用自己的預留項目,都會發生這種情況。向量索引資料表的大小再次超過 10 MB 時,系統就會自動填入索引。 |
每個專案每天在每個區域的 CREATE VECTOR INDEX DDL 陳述式數量 |
500 項作業 |
每個專案每天最多可針對每個區域發出 500 個 CREATE VECTOR INDEX 作業。
|
| 每個資料表每日的向量索引 DDL 陳述式數量 | 10 項作業 |
每個資料表每天最多可發出 10 個 CREATE VECTOR INDEX 或 DROP VECTOR INDEX 作業。 |
| 每個機構可建立向量索引的資料表資料總大小上限 (不透過預留空間執行) | 6 TB | 如果貴機構中含有索引的資料表總大小未超過 6 TB,您就可以為資料表建立向量索引。如果索引管理工作是在您自己的預訂項目中執行,則不受這項限制影響。 |
處理常式
以下配額與限制適用於常式。
使用者定義函式
以下限制適用於 GoogleSQL 查詢中暫時性和永久的 使用者定義函式 (UDF)。
。| 限制 | 預設 | 附註 |
|---|---|---|
| 每列輸出內容的上限 | 5 MB | 處理單一資料列時,JavaScript UDF 輸出的資料量上限約為 5 MB。 |
| 使用 JavaScript UDF 時,舊版 SQL 查詢的並行上限 | 6 項查詢 | 您的專案最多可有六個並行舊版 SQL 查詢,其中包含 JavaScript 中的 UDF。這項限制同時適用於互動式查詢和批次查詢。這項限制不適用於 GoogleSQL 查詢。 |
| 每個查詢的 JavaScript UDF 資源數量上限 | 50 項資源 | 查詢工作最多可以有 50 個 JavaScript UDF 資源,例如內嵌程式碼 blob 或外部檔案。 |
| 內嵌程式碼 blob 大小上限 | 32 KB | UDF 中的內嵌程式碼 blob 大小上限為 32 KB。 |
| 每項外部程式碼資源的大小上限 | 1 MB | 每項 JavaScript 程式碼資源的大小上限為 1 MB。 |
永久性 UDF 適用下列限制:
| 限制 | 預設 | 附註 |
|---|---|---|
| UDF 名稱長度上限 | 256 個半形字元 | UDF 名稱長度上限為 256 個字元。 |
| 引數數量上限 | 256 個引數 | UDF 最多可有 256 個引數。 |
| 引數名稱長度上限 | 128 個字元 | UDF 引數名稱的長度上限為 128 個字元。 |
| UDF 參考鏈深度上限 | 16 筆參考資料 | UDF 參照鏈最多可有 16 個參照。 |
STRUCT 類型引數或輸出內容的深度上限 |
15 個等級 |
STRUCT 類型的 UDF 引數或輸出內容最多可有 15 個層級。 |
每個 UDF 的 STRUCT 型別引數或輸出內容中的欄位數量上限 |
1,024 個欄位 |
UDF 的 STRUCT 類型引數和輸出內容最多可有 1024 個欄位。 |
CREATE FUNCTION陳述式中的 JavaScript 程式庫數量上限 |
50 個程式庫 |
一個 CREATE FUNCTION 陳述式最多可有 50 個 JavaScript 程式庫。 |
| 加入的 JavaScript 程式庫路徑長度上限 | 5,000 個字元 | UDF 中包含的 JavaScript 程式庫路徑長度上限為 5,000 個字元。 |
| 每個 UDF 每 10 秒的更新頻率上限 | 5 則更新 | 專案每 10 秒最多可更新 UDF 五次。 |
| 每個資料集的授權 UDF 數量上限 | 請參閱「資料集」。 | |
| Python UDF:每個區域每項專案的圖片儲存位元組數 | 10 GiB | 特定專案和區域中,Python UDF 使用的所有容器映像檔總大小 (以位元組為單位)。 |
| Python UDF:變動限制 | 每分鐘 30 次 | 每個專案的每個區域,每分鐘最多可建立或更新 30 次 Python UDF。 |
| Python UDF:並行 Python UDF 數量上限 | 10 | 每個專案最多可執行 10 個參照 Python UDF 的並行查詢。 |
遠端函式
以下限制適用於 BigQuery 中的遠端函式。
如需疑難排解資訊,請參閱「含有遠端函式的並行查詢數量上限」。
| 限制 | 預設 | 附註 |
|---|---|---|
| 包含遠端函式的並行查詢數量上限 | 10 項查詢 | 每個專案最多可使用 遠端函式執行十個並行查詢。 |
| 輸入內容大小上限 | 5 MB | 單一資料列中所有輸入引數的總大小上限為 5 MB。 |
| HTTP 回應大小限制 (Cloud Run 函式第 1 代) | 10 MB | Cloud Run 函式第 1 代的 HTTP 回應本文大小上限為 10 MB。超過這個值會導致查詢失敗。 |
| HTTP 回應大小限制 (Cloud Run functions 第 2 代或 Cloud Run) | 15 MB | Cloud Run 函式第 2 代或 Cloud Run 的 HTTP 回應本文大小上限為 15 MB。如果超過這個值,查詢就會失敗。 |
| HTTP 叫用時間上限 (Cloud Run 函式第 1 代) | 9 分鐘 | 您可以為個別 HTTP 呼叫設定 Cloud Run 函式第 1 代的時間限制,但時間限制最多為 9 分鐘。 如果超過為第 1 代 Cloud Run 函式設定的時間限制,可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 叫用時間限制 (Cloud Run 函式第 2 代或 Cloud Run) | 20 分鐘 | 個別 HTTP 叫用第 2 代 Cloud Run 函式或 Cloud Run 的時間限制。超過這個值可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 呼叫重試次數上限 | 20 | 對 Cloud Run 函式第 1 代、第 2 代或 Cloud Run 進行個別 HTTP 叫用的重試次數上限。如果超過這個值,可能會導致 HTTP 呼叫失敗和查詢失敗。 |
資料表函式
以下限制適用於 BigQuery資料表函式:
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料表函式名稱長度上限 | 256 個字元 | 資料表函式的名稱長度上限為 256 個字元。 |
| 引數名稱長度上限 | 128 個字元 | 資料表函式引數名稱的長度上限為 128 個字元。 |
| 引數數量上限 | 256 個引數 | 資料表函式最多可有 256 個引數。 |
| 資料表函式參考鏈深度上限 | 16 筆參考資料 | 表格函式參照鏈最多可有 16 個參照。 |
引數或 STRUCT 類型輸出內容的深度上限 - 15 層 |
15 個等級 |
資料表函式的 STRUCT 引數最多可有 15 個層級。同樣地,資料表函式輸出內容中的 STRUCT 記錄最多可達 15 層。 |
每個資料表函式引數或傳回資料表中的欄位數量上限 (STRUCT 類型) |
1,024 個欄位 |
資料表函式的 STRUCT 引數最多可有 1,024 個欄位。同樣地,資料表函式輸出中的 STRUCT 記錄最多可有 1,024 個欄位。 |
| 傳回資料表中的欄數上限 | 1,024 欄 | 資料表函式傳回的資料表最多可有 1,024 個資料欄。 |
| 傳回資料表欄名稱的長度上限 | 128 個字元 | 傳回表格中的欄名長度上限為 128 個字元。 |
| 每個資料表函式每 10 秒的更新次數上限 | 5 則更新 | 專案每 10 秒最多可更新資料表函式五次。 |
預存 Apache Spark 程序
以下限制適用於 Apache Spark 適用的 BigQuery 預存程序:
| 限制 | 預設 | 注意事項 |
|---|---|---|
| 並行預存程序查詢數量上限 | 50 | 每個專案最多可執行 50 個並行的預存程序查詢。 |
| 使用中的 CPU 數量上限 | 12,000 | 每個專案最多可使用 12,000 個 CPU。已處理的查詢不會計入這項限制。 每個專案的每個位置最多可使用 2,400 個 CPU,但下列位置除外:
在這些地區,每個專案每個地點最多可使用 500 個 CPU。 如果您在多區域位置和同一地理區域的單一區域位置中執行並行查詢,查詢可能會耗用相同的並行 CPU 配額。 |
| 使用中標準永久磁碟的總大小上限 | 204.8 TB | 每個專案的每個位置最多可使用 204.8 TB 的標準永久磁碟。已處理的查詢不會計入這項限制。 如果您在多區域位置和同一地理區域的單一區域位置中執行並行查詢,查詢可能會耗用相同的標準永久磁碟配額。 |
筆記本
所有 Dataform 配額與限制和 Colab Enterprise 配額與限制,都適用於 BigQuery 中的筆記本。此外,也適用下列限制:
| 限制 | 預設 | 注意事項 |
|---|---|---|
| 筆記本大小上限 | 20 MB |
筆記本的大小是內容、中繼資料和編碼額外用量的總和。 如要查看筆記本內容大小,請展開筆記本標題,依序點選「查看」和「筆記本資訊」。 |
| 每秒傳送至 Dataform 的要求數量上限 | 100 | 筆記本是透過 Dataform 建立及管理。 建立或修改筆記本的任何動作都會計入這項配額。 這項配額與已儲存的查詢共用。舉例來說,如果您在 1 秒內對筆記本進行 50 次變更, 並對已儲存的查詢進行 50 次變更,就會達到配額上限。 |
已儲存的查詢
所有 Dataform 配額和限制均適用於已儲存的查詢。此外,還須遵守下列限制:
| 限制 | 預設 | 注意事項 |
|---|---|---|
| 已儲存的查詢大小上限 | 10 MB | |
| 每秒傳送至 Dataform 的要求數量上限 | 100 | 您可以透過 Dataform 建立及管理已儲存的查詢。 建立或修改已儲存的查詢的任何動作,都會計入這項配額。這項配額與筆記本共用。舉例來說,如果您在 1 秒內對筆記本和已儲存的查詢各進行 50 項變更,就會達到配額上限。 |
資料操縱語言
以下限制適用於 BigQuery資料操縱語言 (DML) 陳述式:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每日 DML 陳述式 | 無限制 |
專案每天可執行的 DML 陳述式數量沒有限制。
DML 陳述式不會計入分區資料表的每日資料表修改次數,也不會計入每日分區資料表修改次數。 DML 陳述式有下列限制,請注意。 |
每個資料表每日並行 INSERT DML 陳述式數 |
1,500 份對帳單 |
系統會立即執行提交的前 1,500 則 INSERT 陳述式。達到這個上限後,寫入資料表的 INSERT 陳述式並行數會限制為 10。其他 INSERT 陳述式會新增至 PENDING 佇列。在任何時間點,最多可針對資料表排隊 100 個 INSERT 陳述式。當 INSERT 陳述式完成時,下一個 INSERT 陳述式會從佇列中移除並執行。如果必須更頻繁地執行 DML INSERT 陳述式,
請考慮使用 Storage Write API 將資料串流至資料表。
|
| 每個資料表的並行變動 DML 陳述式數 | 2 個陳述式 |
BigQuery 最多會為每個資料表並行執行兩個變動 DML 陳述式 (UPDATE、DELETE 和 MERGE)。資料表的其他變動 DML 陳述式會排入佇列。 |
| 每個資料表已加入佇列的變動 DML 陳述式 | 20 份對帳單 | 資料表最多可有 20 個變動 DML 陳述式排入佇列,等待執行。如果為資料表提交其他變異 DML 陳述式,這些陳述式就會失敗。 |
| DML 陳述式在佇列中的時間上限 | 7 小時 | 互動式優先順序 DML 陳述式最多可在佇列中等待七小時。如果陳述式在七小時後仍未執行,就會失敗。 |
| 每個資料表的 DML 陳述式頻率上限 | 每 10 秒 25 則陳述式 |
每個資料表每 10 秒最多可執行 25 個 DML 陳述式。INSERT 和變動 DML 陳述式都會計入這項限制。 |
如要進一步瞭解變動 DML 陳述式,請參閱 INSERT DML 並行和 UPDATE, DELETE, MERGE DML 並行。
多陳述式查詢
以下限制適用於 BigQuery 中的多重陳述式查詢。
| 限制 | 預設 | 附註 |
|---|---|---|
| 並行多陳述式查詢數量上限 | 1,000 個多陳述式查詢 | 您的專案最多可同時執行 1,000 個多重陳述式查詢。 |
| 累計時間限制 | 24 小時 | 多重陳述式查詢的累計時間限制為 24 小時。 |
| 對帳單時間限制 | 6 小時 | 多重陳述式查詢中個別陳述式的時間限制為 6 小時。 |
查詢中的遞迴 CTE
以下限制適用於 BigQuery 中的遞迴一般資料表運算式 (CTE)。
| 限制 | 預設 | 附註 |
|---|---|---|
| 疊代次數上限 | 500 次疊代 | 遞迴 CTE 可以執行這麼多次反覆運算。如果超過上限,系統就會產生錯誤。如要解決疊代次數限制問題,請參閱「排解疊代次數限制錯誤」。 |
資料列層級安全性
以下限制適用於 BigQuery資料列層級存取政策:
| 限制 | 預設 | 注意事項 |
|---|---|---|
| 每個資料表的資料列存取政策數量上限 | 400 項政策 | 資料表最多可有 400 項列存取政策。 |
| 每個查詢的資料列存取政策數量上限 | 6000 項政策 | 查詢最多可存取 6000 項資料列存取政策。 |
每項政策每 10 秒最多可執行的 CREATE / DROP DDL 陳述式數量 |
5 份對帳單 |
每 10 秒,專案最多可對每個資料列存取政策資源發出五個 CREATE 或 DROP 陳述式。 |
每個資料表每 10 秒 DROP ALL ROW ACCESS POLICIES 陳述式 |
5 份對帳單 |
每 10 秒內,專案的每個資料表最多可發出五個 DROP ALL ROW ACCESS POLICIES
陳述式。
|
資料政策
以下限制適用於資料欄層級的動態資料遮蓋:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個政策標記的資料政策數量上限。 | 每個政策標記最多 8 項政策 | 每個政策標記最多可有八項資料政策。其中一項政策可用於資料欄層級存取權控管機制。系統不支援重複的遮蓋運算式。 |
BigQuery ML
以下限制適用於 BigQuery ML。
查詢工作
使用 BigQuery ML 陳述式和函式的 GoogleSQL 查詢工作,皆適用所有查詢工作配額和限制。
CREATE MODEL 個陳述式
下列限制適用於CREATE MODEL工作:
| 限制 | 預設 | 附註 |
|---|---|---|
CREATE MODEL
每項專案每 48 小時的陳述式查詢數 |
20,000 個陳述式查詢 | 部分模型是透過 Vertex AI 服務訓練而成,這些服務有自己的資源和配額管理機制。 |
| 執行時間限制 | 24 或 48 小時 | CREATE MODEL
工作逾時預設為 24 小時,但時間序列、AutoML 和超參數調整工作除外,這些工作會在 48 小時後逾時。 |
生成式 AI 功能
以下限制適用於使用 Agent Platform 大型語言模型 (LLM) 的函式。詳情請參閱「函式配額定義」。
每分鐘要求數上限
下列限制適用於使用每分鐘要求數限制的 Agent Platform 模型。
| 函式 | 型號 | 區域 | 每分鐘要求數 | 每個工作的資料列數 |
|---|---|---|---|---|
AI.GENERATE_TEXTML.GENERATE_TEXTAI.GENERATE_TABLEAI.GENERATEAI.GENERATE_BOOLAI.GENERATE_DOUBLEAI.GENERATE_INT
|
gemini-2.0-flash-lite-001 |
US 和 EU 多區域如 Google 模型端點位置所述的單一區域 gemini-2.0-flash-lite-001 |
沒有設定配額。配額由動態共用配額 (DSQ)1 和佈建輸送量2決定 | 透過佈建輸送量 DSQ 為 10,500,000,通話平均有 500 個輸入權杖和 50 個輸出權杖 |
gemini-2.0-flash-001 |
US 和 EU 多區域如 Google 模型端點位置所述的單一區域 gemini-2.0-flash-001 |
不適用於佈建輸送量 DSQ 為 10,200,000,適用於平均有 500 個輸入權杖和 50 個輸出權杖的通話 |
||
gemini-2.5-flash |
US 和 EU 多區域如 Google 模型端點位置所述的單一區域 gemini-2.5-flash |
不適用於佈建輸送量 DSQ 為 9,300,000,適用於平均有 500 個輸入權杖和 50 個輸出權杖的通話 |
||
gemini-2.5-pro |
US 和 EU 多區域如 Google 模型端點位置所述的單一區域 gemini-2.5-pro |
透過佈建輸送量佈建時不適用 DSQ 為 7,600,000,適用於平均有 500 個輸入權杖和 50 個輸出權杖的通話 |
||
AI.IFAI.SCOREAI.CLASSIFY |
各種 gemini-2.5-* 模型 |
US 和 EU 多區域gemini-2.5-* models
Google 模型端點位置支援的任何單一區域 |
無設定配額。配額由動態共用配額 (DSQ)1決定。 | 如果每次呼叫的輸入資料列平均有 500 個詞元,輸出詞元有 50 個,則為 10,000,000 個詞元。 |
AI.AGG
|
各種 Gemini 模型 | 查看地點 | 未設定配額。配額由動態共用配額 (DSQ)1決定。 | 20,000,000 |
AI.GENERATE_TEXTML.GENERATE_TEXT |
Anthropic Claude | 請參閱依模型和區域劃分的配額 | 請參閱依模型和區域劃分的配額 | 每分鐘要求數 * 60 * 6 |
| Llama | 請參閱 Llama 模型區域供應情形和配額 | 請參閱 Llama 模型區域供應情形和配額 | ||
| Mistral AI | 請參閱 Mistral AI 模型區域供應情形和配額 | 請參閱 Mistral AI 模型區域供應情形和配額 | ||
AI.GENERATE_EMBEDDING5AI.EMBEDAI.SIMILARITYAI.SEARCHVECTOR_SEARCHML.GENERATE_EMBEDDING5 |
text-embeddingtext-multilingual-embedding |
支援遠端機型的所有區域 | 1,5003,4 | 如果每個輸入列平均有 50 個權杖,則為 80,000,000 如果每個輸入列平均有 600 個權杖,則為 14,000,000 |
multimodalembedding |
支援的歐洲單一地區 | 1203 | 43,200 | |
| 支援的歐洲單一區域以外的區域 | 6003 | 216,000 | ||
gemini-embedding-2-preview |
us-central1 和 US 多區域 |
4,0003 | 1,440,000 |
1 使用 DSQ 時,系統不會預先定義用量配額限制。DSQ 會提供大量共用資源集區的存取權,並根據資源的即時可用性和特定模型的需求量,動態分配資源。如果活躍客戶較多,每位客戶的處理量就會減少。同樣地,如果活躍客戶較少,每位客戶的處理量可能會增加。
2 佈建輸送量是固定費用、固定期限的訂閱方案,提供多種期限長度。佈建輸送量可讓您為 Agent Platform 支援的生成式 AI 模型預留處理量。
3 如要提高配額,請在 Agent Platform 中申請調整每分鐘查詢次數配額。配額值提高後,系統需要 30 分鐘才能完成傳播。
4 您可以將 Agent Platform text-embedding 和 text-multilingual-embedding 模型的配額提高至 10,000 RPM,無須手動核准。根據每次呼叫的每個輸入資料列平均有 50 個權杖,這可讓每個工作處理的資料列數增加至 5 億以上。
5:每個專案最多可同時執行 5 項作業。
如要進一步瞭解 Agent Platform LLM 的配額,請參閱「Agent Platform 生成式 AI 配額限制」。
每分鐘權杖數上限
下列限制適用於使用每分鐘權杖數限制的 Agent Platform 模型:
| 功能 | 每分鐘符記數 | 每個工作的列數 | 同時執行的工作數量 |
|---|---|---|---|
透過 gemini-embedding-001 模型使用遠端模型時,
AI.GENERATE_EMBEDDING 或
ML.GENERATE_EMBEDDING |
10,000,000 | 12,000,000,每列平均 300 個符記 | 5 |
透過 gemini-embedding-2-preview 模型使用遠端模型時,
AI.GENERATE_EMBEDDING 或
ML.GENERATE_EMBEDDING |
5,000,000 | 1,440,000 | 5 |
Cloud AI 服務功能
使用 Cloud AI 服務的函式有下列限制:
| 功能 | 每分鐘要求數 | 每個工作的列數 | 同時執行的工作數量 |
|---|---|---|---|
ML.PROCESS_DOCUMENT,文件平均有五十頁 |
600 | 100,000 (以每份輸入文件平均 50 頁為準) | 5 |
ML.TRANSCRIBE |
200 | 10,000 次 (以每個輸入音訊檔案的平均長度為 1 分鐘計算) | 5 |
ML.ANNOTATE_IMAGE |
1,800 | 648,000 | 5 |
ML.TRANSLATE |
6,000 | 2,160,000 | 5 |
ML.UNDERSTAND_TEXT |
600 | 21,600 | 5 |
如要進一步瞭解 Cloud AI 服務 API 的配額,請參閱下列文件:
- Cloud Translation API 配額與限制
- Vision API 配額與限制
- Natural Language API 配額和限制
- Document AI 配額與限制
- Speech-to-Text 配額與限制
函式配額定義
以下列出生成式 AI 和 Cloud AI 服務功能適用的配額:
- 呼叫 Agent Platform 模型的函式會使用一項 Agent Platform 配額,也就是每分鐘查詢次數 (QPM)。在此情況下,查詢是指函式對 Agent Platform 模型 API 發出的要求呼叫。QPM 配額適用於基礎模型,以及該模型的所有版本、ID 和微調版本。如要進一步瞭解 Agent Platform 模型配額,請參閱「Agent Platform 上的生成式 AI 配額限制」。
- 呼叫 Cloud AI 服務的函式會使用目標服務的要求配額。詳情請參閱指定 Cloud AI 服務的配額參考資料。
BigQuery ML 使用下列配額:
每分鐘要求數。這項配額限制的是,函式每分鐘可對 Agent Platform 模型或 Cloud AI 服務的 API 發出的要求呼叫數。這項限制適用於每個專案,且使用相同模型端點的所有工作都會共用這項配額。
由於 Gemini 模型使用動態共用配額 (DSQ),因此對 Agent Platform Gemini 模型的呼叫沒有預先定義的使用配額限制。DSQ 提供大量共用資源集區的存取權,並根據資源的即時可用性和特定模型的需求,動態分配資源。
每分鐘權杖數:此配額限制函式每分鐘可傳送至 Agent Platform 模型 API 的權杖數量。這項限制適用於每個專案。
對於呼叫 Agent Platform 基礎模型的函式,每分鐘的權杖數量會因 Agent Platform 模型端點、版本和區域而異,也取決於專案的信譽。這個配額在概念上與 Agent Platform 使用的 QPM 配額相同。
每個工作處理的資料列數。
Rows per job值可做為效能基準,估算單一工作專用專案模型端點資源時的處理容量。實際處理的資料列數取決於許多因素,包括模型輸入要求的大小、模型輸出回應的大小,以及動態共用配額的可用性。以下範例顯示一些常見情境:對於
gemini-2.0-flash-lite-001端點,AI.GENERATE_TEXT或ML.GENERATE_TEXT函式可處理的資料列數量取決於輸入和輸出權杖數量。如果呼叫的平均輸入權杖數量為 2,000,且輸出權杖數量上限為 50,則服務可處理約 760 萬列。如果平均輸入權杖數量為 10,000,且輸出權杖數量上限為 3,000,則可處理的資料列數量會減少至約 100 萬列。同樣地,如果呼叫的平均輸入權杖數為 2,000,且輸出權杖數上限為 50,則
gemini-2.0-flash-001端點可處理 440 萬列;但如果呼叫的輸入權杖數為 10,000,且輸出權杖數為 3,000,則只能處理約 100 萬列。相較於長文件,
ML.PROCESS_DOCUMENT函式可處理的短文件列數較多。相較於長音訊片段,
ML.TRANSCRIBE函式可處理的短音訊片段工作列數較多。
同時執行的工作數量。這項配額是每項專案的限制,規定特定函式可同時執行的 SQL 查詢數量。
下列範例說明如何解讀一般情況下的配額限制:
我在 Agent Platform 的配額為 1,000 QPM,因此查詢 100,000 列資料大約需要 100 分鐘。為什麼工作執行時間較長?
即使輸入資料相同,工作執行時間也可能有所不同。在 Agent Platform 中,遠端程序呼叫 (RPC) 的優先順序各不相同,可避免配額耗盡。配額不足時,優先順序較低的 RPC 會等待,如果處理時間過長,可能會失敗。
如何解讀每個工作配額的資料列?
在 BigQuery 中,查詢最多可執行六小時。為確保 BigQuery 能在六小時內完成查詢處理作業,支援的列數上限取決於這段時間和您的 Agent Platform QPM 配額。由於查詢通常無法使用完整配額,因此這個數字會低於 QPM 配額乘以 360。
如果我在資料表上執行批次推論作業,但資料列數超過作業配額 (例如 10,000,000 列),會發生什麼情況?
BigQuery 只會處理每個工作配額的列數。系統只會針對該列數的成功 API 呼叫收費,而不是表格中的完整 10,000,000 列。對於其餘列,BigQuery 會以
A retryable error occurred: the maximum size quota per query has reached錯誤回應要求,該錯誤會傳回結果的status欄。您可以使用這組 SQL 指令碼或這個 Dataform 套件,反覆呼叫推論,直到所有列都成功處理為止。我需要處理的資料列數量遠超過每個工作的配額。如果將資料列分散到多個查詢,並同時執行這些查詢,是否會有幫助?
否,因為這些查詢會耗用相同的 BigQuery ML 每分鐘要求配額和 Agent Platform QPM 配額。如果有多個查詢都符合每個工作的資料列配額和並行執行工作數配額,累積處理量就會用盡每分鐘要求配額。
BigQuery Graph
以下限制適用於 BigQuery Graph:
| 限制 | 預設 | 附註 |
|---|---|---|
| 圖表參照的資料表數量上限 | 1,000 個表格 | 在節點和邊緣定義中,圖表最多可參照 1,000 個節點和邊緣資料表。 |
| 每個節點或邊緣資料表的索引鍵欄數上限 | 16 欄 | 您可以在圖表的節點或邊緣資料表上,定義最多使用 16 個資料欄的索引鍵。 |
| 每個節點參照的欄數上限 | 16 欄 | 來源鍵或目的地鍵最多可參照圖表中節點資料表的 16 個資料欄。 |
| 每個邊緣參照的資料欄數量上限 | 16 欄 | 邊緣的來源鍵或目的地鍵最多可參照邊緣資料表的 16 個資料欄。 |
| 圖表上的標籤數量上限 | 1,000 個標籤 | 您最多可以在圖表上定義 1,000 個節點和邊緣標籤。 |
| 每個節點或邊緣定義的標籤數量上限 | 20 個標籤 | 您可以在圖表的節點或邊緣上定義最多 20 個標籤。 |
| 圖表上定義的屬性數量上限 | 5,000 個資源 | 您可以在圖表上定義最多 5,000 個屬性。 |
| 每個標籤定義的屬性數量上限 | 1,000 個資源 | 圖表中的每個標籤最多可定義 1,000 個屬性。 |
BI Engine
以下限制適用於 BigQuery BI Engine。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個專案/每個位置的保留項目大小上限 (BigQuery BI Engine) | 250 GiB | 每個專案/每個位置的預設預留項目大小上限為 250 GiB。 您可以 要求提高專案的預留容量上限。 大多數區域都可提高預留容量,但視要求提高的容量大小而定,可能需要 3 個以上工作天。 如有緊急要求,請與您的 Google Cloud代表或 Cloud Customer Care 聯絡。 |
| 每個查詢的資料列數量上限 | 70 億 | 每個查詢的資料列數量上限。 |
BigQuery sharing (舊稱 Analytics Hub)
以下限制適用於 BigQuery sharing (舊稱 Analytics Hub):
| 限制 | 預設 | 附註 |
|---|---|---|
| 每項專案的資料交換數量上限 | 500 次交換 | 每個專案最多可建立 500 個資料交換。 |
| 每個資料交換的商家資訊數量上限 | 1,000 筆房源資訊 | 資料交換庫最多可建立 1,000 個產品資訊。 |
| 每個共用資料集可連結的資料集數量上限 | 1,000 個連結的資料集 | 所有 BigQuery sharing 訂閱者加總,每個共用資料集最多可有 1,000 個連結的資料集。 |
Knowledge Catalog 自動探索
以下限制適用於 Knowledge Catalog 自動探索功能:
| 限制 | 預設 | 附註 |
|---|---|---|
| 探索掃描支援的每個 Cloud Storage 值區,最多可有 BigQuery、BigLake 或外部資料表 | 每個值區 1000 個 BigQuery 資料表 | 每個 Cloud Storage bucket 最多可建立 1,000 個 BigQuery 資料表。 |
API 配額與限制
這些配額和限制適用於 BigQuery API 要求。
BigQuery API
下列配額適用於 BigQuery API (核心) 要求:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每日要求數 | 無限制 |
您的專案每天可發出無限次數的 BigQuery API 要求。 在 Google Cloud 控制台中查看配額 |
每分鐘最多
tabledata.list 位元組
|
多區域為 7.5 GB;所有其他區域為 3.7 GB |
在 us 和 eu 多個地區,您的專案每分鐘最多可透過 tabledata.list 傳回 7.5 GB 的資料表列資料,在所有其他地區,每分鐘最多可傳回 3.7 GB 的資料表列資料。這項配額適用於包含正在讀取的資料表的專案。包含
jobs.getQueryResults 與會透過
jobs.query 和
jobs.insert 擷取結果的其他 API 也會耗用這項配額。如需疑難排解資訊,請參閱疑難排解頁面。
在 Google Cloud 控制台中查看配額 BigQuery Storage Read API
的持續處理量遠高於 |
以下限制適用於 BigQuery API (核心) 要求:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每位使用者每種方法每秒可發出的 API 要求數上限 | 100 個要求 |
使用者每秒最多可向 API 方法提出 100 個 API 要求。
如果使用者每秒對方法發出超過 100 項要求,可能會遇到速率限縮的情況。這項限制不適用於串流資料插入。 如需疑難排解資訊,請參閱「疑難排解頁面」。 |
| 每位使用者的並行 API 要求數量上限 | 300 項要求 | 如果使用者發出超過 300 項並行要求,可能會遇到速率限縮的情況。這項限制不適用於串流資料插入。 |
| 要求標頭大小上限 | 16 KiB |
BigQuery API 要求最多可達 16 KiB,包括要求網址和所有標頭。這項限制不適用於要求主體,例如 POST 要求。 |
每秒最多
jobs.get 個要求
|
1,000 項要求 |
您的專案每秒最多可提出 1,000 項jobs.get要求。 |
jobs.query 回應大小上限
|
20 MB |
根據預設,每個結果頁面中 jobs.query 傳回的資料列數量並無上限。不過,回應大小最多不能超過 20 MB。如要改變傳回的資料列數量,請使用 maxResults 參數。 |
資料列大小上限
jobs.getQueryResults |
20 MB | 資料列大小上限為約略值,因為此限制是根據列資料的內部呈現方式而定。轉碼期間會強制執行這項限制。 |
每秒最多
projects.list 個要求
|
10 項要求 |
使用者每秒最多可提出 10 個要求。
projects.list |
每秒最多可發出
tabledata.list 要求 |
1,000 項要求 |
您的專案每秒最多可提出 1,000 項 tabledata.list要求。 |
每個
tabledata.list 回應的資料列數量上限
|
100,000 列 |
tabledata.list 呼叫最多可傳回 100,000 個資料表列。
詳情請參閱「使用 API 逐頁瀏覽結果」。 |
資料列大小上限
tabledata.list |
100 MB | 資料列大小上限為約略值,因為此限制是根據列資料的內部呈現方式而定。轉碼期間會強制執行這項限制。 |
每秒最多
tables.insert 個要求
|
10 項要求 |
使用者每秒最多可提出 10 個 tables.insert 要求。
tables.insert 方法會在資料集中建立新的空白資料表。 |
BigQuery Connection API
以下配額適用於 BigQuery Connection API 要求:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每分鐘讀取要求數 | 每分鐘 1,000 個要求 |
您的專案每分鐘最多可對 BigQuery Connection API 方法發出 1,000 項要求,以讀取連線資料。 在 Google Cloud 控制台中查看配額 |
| 每分鐘寫入要求數 | 每分鐘 100 個要求 |
您的專案每分鐘最多可對 BigQuery Connection API 方法發出 100 個要求,以建立或更新連線。 在 Google Cloud 控制台中查看配額 |
| 每分鐘建立的 BigQuery Omni 連線數 | 每分鐘建立 10 個連線 | 您的專案每分鐘最多可在 AWS 和 Azure 建立 10 個 BigQuery Omni 連線。 |
| BigQuery Omni 連線使用 | 每分鐘 500 個連線 | 您的專案每分鐘最多可使用 500 次 BigQuery Omni 連線。這類作業包括使用連線存取 AWS 帳戶,例如查詢資料表。 |
BigQuery Migration API
以下限制適用於 BigQuery Migration API:
| 限制 | 預設 | 附註 |
|---|---|---|
| 批次 SQL 翻譯的個別檔案大小 | 10 MB |
每個來源和中繼資料檔案的大小上限為 10 MB。
這項限制不適用於 dwh-migration-dumper 指令列擷取工具產生的中繼資料 ZIP 檔案。 |
| 批次 SQL 翻譯的來源檔案總大小 | 1 GB | 上傳至 Cloud Storage 的所有輸入檔案總大小上限為 1 GB。包括所有來源檔案,以及您選擇納入的所有中繼資料檔案。 |
| 互動式 SQL 翻譯的輸入字串大小 | 1 MB | 您輸入的互動式 SQL 翻譯字串不得超過 1 MB。使用 Translation API 執行互動式翻譯時,這項限制適用於所有字串輸入的總大小。 |
| 互動式 SQL 轉譯的設定檔大小上限 | 50 MB |
Cloud Storage 中的個別中繼資料檔案 (已壓縮) 和 YAML 設定檔不得超過 50 MB。如果檔案大小超過 50 MB,互動式翻譯工具會在翻譯期間略過該設定檔,並產生錯誤訊息。如要縮減中繼資料檔案大小,其中一個方法是在產生中繼資料時,使用 —database 或 –schema 旗標篩選資料庫。 |
| 每小時的 Gemini 建議數量上限 | 1,000 (未使用時最多可累積至 10,000) | 如有需要,請與 Cloud Customer Care 聯絡,要求增加配額。 |
以下配額適用於 BigQuery Migration API。在大多數情況下,系統會套用下列預設值。專案的預設值可能不同:
| 配額 | 預設 | 附註 |
|---|---|---|
|
每分鐘 EDWMigration Service List 要求數 每位使用者每分鐘的 EDWMigration 服務清單要求數 |
12,000 項要求 2,500 項要求 |
您的專案每分鐘最多可以提出 12,000 次 Migration API List 要求。 每位使用者每分鐘最多可提出 2,500 個 Migration API List 要求。 在 Google Cloud 控制台中查看配額 |
|
每分鐘 EDWMigration 服務 Get 要求數 每位使用者每分鐘的 EDWMigration 服務 Get 要求數 |
25,000 項要求 2,500 項要求 |
您的專案每分鐘最多可提出 25,000 項 Migration API Get 要求。 每位使用者每分鐘最多可提出 2,500 個 Migration API Get 要求。 在 Google Cloud 控制台中查看配額 |
|
EDWMigration Service Other Requests per minute EDWMigration Service Other Requests per minute per user |
25 項要求 5 項要求 |
您的專案每分鐘最多可發出 25 個其他 Migration API 要求。 每位使用者每分鐘最多可提出 5 項其他 Migration API 要求。 在 Google Cloud 控制台中查看配額 |
|
每分鐘的互動式 SQL 翻譯要求數 每位使用者每分鐘的互動式 SQL 翻譯要求數 |
200 項要求 50 項要求 |
您的專案每分鐘最多可提出 200 個 SQL 翻譯服務要求。 每位使用者每分鐘最多可提出 50 個其他 SQL 轉譯服務要求。 在 Google Cloud 控制台中查看配額 |
BigQuery Reservation API
以下配額適用於 BigQuery Reservation API 要求:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域每分鐘的要求數 | 100 個要求 |
每個專案每分鐘每個區域的 BigQuery Reservation API 方法呼叫總數最多為 100 次。 在 Google Cloud 控制台中查看配額 |
每個區域每分鐘的 SearchAllAssignments 通話次數
|
100 個要求 |
每個專案每分鐘最多可對每個區域的
SearchAllAssignments 方法發出 100 次呼叫。
在 Google Cloud 控制台中查看配額 |
每位使用者每個地區每分鐘的 SearchAllAssignments 要求數 |
10 項要求 |
每位使用者每分鐘最多可對每個區域的
SearchAllAssignments 方法發出 10 次呼叫。
在 Google Cloud 控制台中查看配額 (在 Google Cloud 控制台搜尋結果中,搜尋「每個使用者」」。) |
BigQuery Data Policy API
| 限制 | 預設 | 附註 |
|---|---|---|
通話次數上限為
dataPolicies.list
次。
|
每項專案每分鐘 400 項要求 每個機構每分鐘 600 項要求 |
|
dataPolicies.testIamPermissions 呼叫次數上限。
|
每項專案每分鐘 400 項要求 每個機構每分鐘 600 項要求 |
|
| 讀取要求數量上限。 |
每項專案每分鐘 1,200 個要求 每機構每分鐘 1,800 個要求 |
這包括對
dataPolicies.get
和
dataPolicies.getIamPolicy 的呼叫。
|
| 寫入要求數量上限。 |
每項專案每分鐘 600 個要求 每個機構每分鐘 900 個要求 |
這包括對下列項目的呼叫: |
IAM API
在 BigQuery 中使用身分與存取權管理功能,擷取及設定 IAM 政策,並測試 IAM 權限時,適用下列配額。資料控管語言 (DCL) 陳述式會計入 SetIAMPolicy 配額。
| 配額 | 預設 | 附註 |
|---|---|---|
每位使用者每分鐘 IamPolicy 個要求 |
每位使用者每分鐘 1,500 個要求 | 每位使用者每項專案每分鐘最多可提出 1,500 個要求。 在 Google Cloud 控制台中查看配額 |
每項專案每分鐘 IamPolicy 個要求 |
每項專案每分鐘 3,000 個要求 | 專案每分鐘最多可提出 3,000 個要求。 在 Google Cloud 控制台中查看配額 |
單一區域
SetIAMPolicy 每項專案每分鐘的要求數 |
每項專案每分鐘 1,000 個要求 | 單一區域專案每分鐘最多可提出 1,000 個要求。 在 Google Cloud 控制台中查看配額 |
多區域
每項專案每分鐘 SetIAMPolicy 個要求 |
每項專案每分鐘 2,000 個要求 | 多區域專案每分鐘最多可提出 2,000 個要求。 在 Google Cloud 控制台中查看配額 |
全區域
SetIAMPolicy 每項專案每分鐘的要求數 |
每項專案每分鐘 200 個要求 | 您的多區域專案每分鐘最多可提出 200 個要求。 在 Google Cloud 控制台中查看配額 |
Storage Read API
以下配額適用於 BigQuery Storage Read API 要求:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每位使用者每分鐘的讀取資料平面要求數 | 25,000 項要求 |
每位使用者每分鐘最多可發出 25,000 個 ReadRows 呼叫,每個專案皆適用此限制。在 Google Cloud 控制台中查看配額 |
| 並行讀取連線數上限 | 多區域 2,000 個;區域 400 個 |
每項專案的並行 ReadRows 連線數上限。
預設值為 us 和 eu 多區域的 2,000 個連線,以及其他區域的 400 個連線。實際連線可用性可能會因整個區域的整體服務負載和需求而波動。這項動態調整機制可確保資源分配公平,並維持所有使用者的服務穩定性。如果串流因公平性而關閉,或是達到連線上限,您會收到 RESOURCE_EXHAUSTED 錯誤 (HTTP 429)。我們會根據專案過去的用量模式,以及區域內資源的普遍可用性,審查配額提高要求 (QIR)。 在 Google Cloud 控制台中查看配額 |
| 每位使用者每分鐘的讀取控制層要求數 | 5,000 項要求 |
每位使用者每項專案每分鐘最多可以發出 5,000 個 Storage Read API 中繼資料作業呼叫。中繼資料呼叫包括 CreateReadSession 和 SplitReadStream 方法。在 Google Cloud 控制台中查看配額 |
以下限制適用於 BigQuery Storage Read API 要求:
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料列/篩選條件長度上限 | 1 MB |
使用 Storage Read API CreateReadSession 呼叫時,每列或篩選條件的長度上限為 1 MB。 |
| 序列化資料大小上限 | 128 MB |
使用 Storage Read API ReadRows 呼叫時,個別 ReadRowsResponse 訊息中的資料序列化表示法不得超過 128 MB。 |
| 每個串流的記憶體用量上限 | 1.5 GB | 每個串流的記憶體上限為約略值,因為這項限制是根據資料列資料的內部呈現方式而定。如果單一資料列使用的記憶體超過 1.5 GB,串流可能會失敗。詳情請參閱「排解資源超出限制的問題」。 |
Storage Write API
下列配額適用於 Storage Write API 要求。您可以在資料夾層級套用下列配額。這些配額會經過彙整,並在所有子專案之間共用。如要啟用這項設定,請洽詢 Cloud Customer Care 團隊。
如果您打算要求調整配額,請在要求中附上配額錯誤訊息,以加快處理速度。如果配額使用率長期偏低 (超過一年),BigQuery 可能會調降您佈建的配額。
| 配額 | 預設 | 附註 |
|---|---|---|
| 並行寫入連線 | 單一區域 5,000 個;多區域 20,000 個 |
並行連線配額的依據是啟動 Storage Write API 要求的用戶端專案,而非包含 BigQuery 資料集資源的專案。啟動專案是與 API 金鑰或服務帳戶相關聯的專案。 您的專案可在一個區域中處理 5,000 個並行連線,或在 連線應維持長時間,並盡可能用於傳送多個要求。我們不建議使用存續時間較短的連線,因為這可能會導致並行連線配額用量增加。為方便配額結算,建議連線生命週期至少要幾分鐘。 在 Java 或 Go 中使用預設串流時,建議使用Storage Write API 多路複用,透過共用連線寫入多個目的地資料表,以減少所需的整體連線數量。如果您使用Beam 連接器搭配至少一次語意,可以將 UseStorageApiConnectionPool 設為 您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。請根據所在區域選取並行連線限制名稱。選項包括 |
| 處理量 | 多區域的輸送量為每秒 3 GB;區域的輸送量為每秒 300 MB |
在 us 和 eu 多地區中,每個專案最多可串流 3 GBps,在其他地區則為 300 MBps。在 Google Cloud 控制台中查看配額 您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。請根據所在區域選取處理量限制名稱。選項包括 |
CreateWriteStream 要求
|
每項專案每區域每小時 10,000 個串流 |
在每個地區中,每項專案每小時最多可呼叫 CreateWriteStream 10,000 次。如果您不需要僅一次語意,請考慮使用
預設串流。
這項配額以小時為單位,但 Google Cloud 控制台顯示的指標以分鐘為單位。 |
| 待處理的串流位元組數 | 多區域為 10 TB;區域為 1 TB |
每次觸發提交作業時,您最多可以在 us 和 eu 多地區提交 10 TB 的資料,在其他地區則為 1 TB。這項配額沒有配額報表。
|
下列限制適用於 Storage Write API 要求:
| 限制 | 預設 | 附註 |
|---|---|---|
| 批次提交 | 每個資料表 10,000 個串流 |
您可以在每次 BatchCommitWriteStream 呼叫中提交最多 10,000 個串流。
|
AppendRows
要求大小
|
20 MB | 要求大小上限為 20 MB。 |
串流資料插入
使用舊版串流 API 將資料串流至 BigQuery 時,適用下列配額和限制。如要瞭解如何避免超出這些限制,請參閱「排解配額錯誤」。如果超出這些配額,BigQuery 會傳回 quotaExceeded 錯誤。如果配額使用率長期偏低 (超過一年),BigQuery 可能會調降您佈建的配額。
| 限制 | 預設 | 附註 |
|---|---|---|
在 us 和 eu 多地區中,每項專案每秒的位元組數上限 |
每秒 1 GB |
您的專案每秒最多可串流 1 GB 的資料。這項配額會在指定的多區域中持續累計。換句話說,在多區域中,特定專案每秒串流至所有資料表的位元組總和上限為 1 GB。
如果超出這項限制,系統就會產生 如有需要,請與 Cloud Customer Care 聯絡,申請提高配額。請盡早提出增加額度的要求,最晚要在需要額度前兩週提出。配額增加需要一段時間才會生效,如果增加幅度較大,所需時間會更長。 |
| 在其他所有位置,每項專案每秒的位元組數上限 | 每秒 300 MB |
在
如果超出這項限制,系統就會產生 如有需要,請與 Cloud Customer Care 聯絡,申請提高配額。請盡早提出增加額度的要求,最晚要在需要額度前兩週提出。配額增加需要一段時間才會生效,如果增加幅度較大,所需時間會更長。 |
| 資料列大小上限 | 10 MB |
如果超過這個值,系統就會產生 invalid 錯誤。
|
| HTTP 要求大小上限 | 10 MB |
如果超過這個值,系統就會產生 內部會將要求從 HTTP JSON 轉譯為內部資料結構。轉譯的資料結構具有專屬的大小限制。預估產生的內部資料結構大小並非易事,但如果您的 HTTP 要求不超過 10 MB,應該不太會達到內部限制。 |
| 每項要求的資料列數量上限 | 50,000 列 | 建議上限為 500 個資料列。批次處理可以將效能和總處理量提高到一定程度,但每項要求的處理時間皆會有所延遲。如果每項要求的資料列數量過少,要求產生的工作負擔可能會導致擷取作業效率低落。如果每項要求的資料列數量過多,總處理量可能會減少。使用代表性資料 (結構定義和資料大小) 進行實驗,找出資料的理想批量大小。 |
insertId 欄位長度
|
128 個字元 |
如果超過這個值,系統就會產生 invalid 錯誤。
|
如需額外的串流配額,請參閱「要求增加配額」。
頻寬
下列配額適用於複製頻寬:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的初始回填複製頻寬上限,這些區域的資料會從主要副本跨區域輸出至次要副本。 | 每個機構在每個區域的實體 GiBps 為 10 | |
| 每個區域的持續複製作業頻寬上限,這些區域的資料會從主要副本輸出至次要副本。 | 每個機構在每個區域的實體 GiBps 為 5 | |
| 每個區域的強化型複製頻寬上限,這些區域的資料會從主要備用資源跨區域輸出至次要備用資源。 | 每個機構在每個區域的實體 GiBps 為 5 | 強化型複製功能的頻寬配額不適用於初始回填作業。 |
如果專案的複製頻寬超過特定配額,受影響專案的複製作業可能會停止,並顯示 rateLimitExceeded 錯誤,其中包含超過配額的詳細資料。