配額與限制
這份文件列出 BigQuery 適用的配額和系統限制。
- 「配額」有預設值,但通常可以申請調整。
- 「系統限制」是固定值,無法變更。
Google Cloud 使用配額來確保公平性,並減少資源使用量和可用性出現劇烈波動的情況。配額會限制 Google Cloud 專案可使用的Google Cloud 資源數量,配額適用多種資源類型,包括硬體、軟體和網路元件。舉例來說,配額可能會限制能向特定服務發出的 API 呼叫次數、專案可同時使用的負載平衡器數量,或是可建立的專案數量。配額機制可防止服務過載,保障Google Cloud 使用者社群的權益,同時也有助於您管理自己的 Google Cloud 資源。
Cloud Quotas 系統具備以下功能:
如果嘗試使用的資源量超過配額限制,系統通常會阻擋該資源的存取活動,您所執行的工作就會失敗。
配額的計算通常是以 Google Cloud 專案為基準。在某個專案中使用資源,不會影響另一個專案的可用配額。在同一個 Google Cloud 專案內,所有應用程式和 IP 位址會共用配額。
詳情請參閱「Cloud Quotas 總覽」。
BigQuery 資源也有「系統限制」,而且無法變更。
部分錯誤訊息會指出您可以提高的配額或限制,其他錯誤訊息則會指出無法提高的配額或限制。達到硬性限制表示您需要為工作負載實作暫時或永久的替代方案,或是最佳做法。即使配額或限制可以增加,也建議您這麼做。如要進一步瞭解這兩種錯誤,請參閱「排解配額和限制錯誤」。
運算單元配額用量計算
如果專案採用以運算能力計價的模式 (包括 BigQuery 版本),「Total number of slots」(運算單元總數) 配額的「Used」(已使用) 欄會反映特定區域的分配運算能力總量。這個值包含預訂中定義的所有基準運算單元,以及任何有效的容量承諾。由於基準配額是專用的可用資源,因此即使閒置,配額系統也會將其視為「已使用」。如要進一步瞭解這與資源監控有何不同,請參閱「瞭解運算單元指標」。
根據預設,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 控制台中查看配額 |
| 每位使用者每日的查詢用量 | 無限制 | 這項配額僅適用於隨選查詢定價模式。 使用者每天可執行的查詢 TiB 數量沒有預設限制。你隨時可以設定上限。無論每位使用者的用量限制為何,專案中所有使用者的總用量都不得超過每日查詢用量限制。如要進一步瞭解費用控管,請參閱「建立自訂查詢配額」。 在 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 控制台中查看配額 |
| 每項 BigQuery Omni 工作轉移的位元組數 | 60 GB |
在 BigQuery Omni 區域中執行 CREATE TABLE AS SELECT (CTAS) 或 INSERT INTO SELECT 陳述式,以便在跨雲端移轉期間篩選資料時,每項工作的移轉大小上限為 60 GB。這項限制也適用於 BigQuery Omni 聯結,這項功能會在背景執行 Omni CTAS 查詢,將資料移轉至 BigQuery 區域的暫時資料表。如要提高上限,請聯絡支援團隊。詳情請參閱「BigQuery Omni join 費用」。 |
| 每個區域配對每天透過全域查詢傳輸的位元組數 | 180 TB | 使用全域查詢時,每對區域之間每天最多可轉移 180 TB 的資料。如要申請提高配額,請與支援團隊聯絡。 |
| 每個專案的全域查詢複製工作 | 10,000 | 執行全域查詢時,每個專案最多可執行 10,000 個複製作業,在區域之間複製資料。一項全域查詢可能會觸發多項複製工作。 如要申請提高配額,請與支援團隊聯絡。 |
| 全域查詢中單一複製工作轉移的位元組數 | 100 GB | 根據預設,屬於全域查詢的單一複製工作最多可移轉 100 GB。如要申請提高上限,請與支援團隊聯絡。 |
| 全域專案層級選項更新 | 5 |
執行 DDL 陳述式來變更全域設定選項時,每 10 秒最多可執行五個陳述式。這項限制適用於下列 DDL 陳述式: |
下列限制適用於透過執行互動式查詢、排定查詢,以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作,自動建立的查詢工作:
| 限制 | 預設 | 附註 |
|---|---|---|
| 佇列中的互動式查詢數量上限 | 1,000 次查詢 | 您的專案最多可將 1,000 個互動式查詢加入佇列。 超過這項限制的其他互動式查詢會傳回配額錯誤。如要排解這些錯誤,請參閱「避免高量互動式查詢的限制」。 |
| 排入佇列的批次查詢數量上限 | 20,000 項查詢 | 專案最多可將 20,000 個批次查詢加入佇列。如果其他批次查詢超出這個上限,系統會傳回配額錯誤。 |
| Bigtable 外部資料來源的並行互動式查詢數量上限 | 16 項查詢 | 專案最多可對 Bigtable 外部資料來源同時執行十六項查詢。 |
| 包含遠端函式的並行查詢數量上限 | 10 項查詢 | 每個專案最多可同時執行十個 遠端函式查詢。 |
| 並行多重陳述式查詢數量上限 | 1,000 項多陳述式查詢 | 專案最多可同時執行 1,000 項多重陳述式查詢。如要瞭解與多重陳述式查詢相關的其他配額和限制,請參閱「 多重陳述式查詢」。 |
| 含有 UDF 的並行舊版 SQL 查詢數量上限 | 6 項查詢 | 您的專案最多可同時執行六項含有使用者定義函式 (UDF) 的舊版 SQL 查詢。這項限制包含互動式和批次查詢。含有 UDF 的互動式查詢也會計入互動式查詢的並行限制。這項限制不適用於 GoogleSQL 查詢。 |
| 每日查詢大小限制 | 無限制 | 根據預設,每日查詢大小沒有限制。不過,您可以建立自訂配額,控管每日查詢用量或每位使用者每日查詢用量,藉此限制使用者可查詢的資料量。 |
| 每日目的地資料表更新次數上限 | 請參閱「每日資料表作業數量上限」。 |
查詢工作中對目的地資料表的更新,會計入目的地資料表每日資料表作業數量上限。目的地資料表更新包括附加和覆寫作業,這些作業是由您使用 Google Cloud 控制台、bq 指令列工具,或呼叫 jobs.query 和查詢類型 jobs.insert API 方法執行的查詢所執行。 |
| 查詢/多重陳述式查詢執行時間限制 | 6 小時 |
查詢或多重陳述式查詢最多可執行 6 小時,然後就會失敗。不過,如果發生暫時性問題 (例如伺服器重新啟動),BigQuery 可能會在內部重試查詢工作。BigQuery 最多可嘗試執行查詢三次,每次嘗試最多可執行 6 小時。因此,查詢的總執行時間可能超過 6 小時 (最多 18 小時)。 如要確認工作是否已重試,可以查看下列信號:
詳情請參閱查詢疑難排解說明文件中的「執行時間」。
|
| 每個查詢參照的資源數量上限 | 1,000 項資源 |
查詢在完全展開後,最多可參照 1,000 個不重複的資料表、不重複的檢視區塊、不重複的
使用者定義函式 (UDF) 和不重複的資料表函式。這項限制包括:
|
| SQL 查詢字元長度上限 | 1,024k 個字元 |
SQL 查詢長度上限為 1,024k 個字元。這項限制包括註解和空白字元。如果查詢長度超過上限,系統會顯示下列錯誤: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 | 解析查詢長度限制包含查詢參照的所有檢視表和 Wildcard 資料表長度。 |
| 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 時間 |
在隨選定價模式下,每 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 的限制 (ExtractBytesPerDay) 是濫用防範限制,僅適用於使用免費共用運算單元集區的擷取作業。使用共用運算單元集區,每天最多可從專案擷取 50 TiB 的資料,無須付費。您可以設定 Cloud Monitoring 警告政策,在擷取位元組數量時提供通知。擷取工作不受每日 50 TiB 的限制,如果您執行下列任一操作,則可超過此限制:
|
| 每日擷取工作數量上限 | 100,000 項擷取工作 |
每日 100,000 項擷取工作的限制是為了防止濫用,僅適用於使用免費共用運算單元集區的擷取工作。使用共用運算單元集區,即可在專案中每日執行最多 100,000 項擷取工作,無須支付費用。 擷取工作不受每日 100,000 項工作的限制,如果您執行下列任一操作,則可超過此限制:
|
| 擷取至單一檔案的資料表大小上限 | 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 項載入工作。 |
| 每個資料表最多可有 250 欄 | 10,000 個資料欄 | 資料表最多可有 10,000 個資料欄。包括巢狀和重複的資料欄。 |
| 每個載入工作的最大大小 | 15 TB | 所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案的總大小上限為 15 TB。這項限制不適用於有預訂的作業。 |
| 工作設定中的來源 URI 數量上限 | 10,000 個 URI | 工作設定最多可有 10,000 個來源 URI。 |
| 每項載入工作的檔案數量上限 | 10,000,000 個檔案 | 載入工作最多可有 1, 000 萬個檔案,包括與所有萬用字元 URI 相符的所有檔案。 |
| 來源 Cloud Storage bucket 中的檔案數量上限 | 約 60,000,000 個檔案 | 載入工作可從 Cloud Storage bucket 讀取最多約 60,000,000 個檔案。 |
| 載入工作執行時間限制 | 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 個專案 | 組織內可包含特定位置/區域運算單元預留項目或有效承諾的專案數量上限。 |
| Standard 版預留項目數量上限 | 每項專案 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 個字元。 |
Tables
所有資料表
下列限制適用於所有 BigQuery 資料表。
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料欄名稱長度上限 | 300 個半形字元 | 欄名不得超過 300 個半形字元。 |
| 資料欄說明長度上限 | 1,024 個半形字元 | 為資料欄新增說明時,文字長度不得超過 1,024 個半形字元。 |
| 巢狀記錄的最大深度 | 15 個等級 |
RECORD 類型的資料欄可包含巢狀 RECORD 類型,也稱為「子」記錄。巢狀結構深度上限為 15 層。
無論記錄是純量或陣列 (重複),都適用這項限制。
|
| 資料表說明的長度上限 | 16,384 個半形字元 | 在資料表中新增說明時,文字長度上限為 16,384 個半形字元。 |
如需資料表配額或限制的疑難排解資訊,請參閱 BigQuery 疑難排解頁面。
標準資料表
BigQuery 標準 (內建) 資料表適用下列限制:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每天的資料表修改次數 | 1,500 項修改 | 每項專案每天最多可對每個資料表進行 1,500 次修改。 附加或覆寫資料表資料的載入工作、複製工作或 查詢工作,會計為對資料表進行一次修改。這個限制無法變更。 這項限制會以頻率限制的形式全天實施,而非一次分配單一配額。BigQuery 會定期補充可用配額。如果作業頻率過高,可能會耗盡可用配額,導致發生 如要提高高頻率擷取作業的效率,請考慮批次處理作業、在一段時間內平均分配工作,或遷移至 BigQuery Storage Write API (gRPC)。 系統會排除 DML 陳述式,且不會計入每日的資料表修改次數。 串流資料不計入每日資料表修改次數。 |
| 每個資料表的資料表中繼資料更新作業頻率上限 | 每 10 秒 5 項作業 |
每項專案每 10 秒最多可對每個資料表執行五項資料表中繼資料更新作業。這項限制適用於下列項目執行的所有資料表的中繼資料更新作業:
DELETE、INSERT、MERGE、TRUNCATE TABLE 或 UPDATE 陳述式將資料寫入資料表。請注意,雖然 DML 陳述式會計入這項限制,但達到限制時不會受到限制。DML 作業有專屬頻率限制。
如果超過這項限制,您會收到類似「 |
| 每個資料表最多可有幾欄 | 10,000 欄 | 每個資料表、查詢結果或檢視表定義最多可有 10,000 欄。包括巢狀和重複的資料欄。 |
外部資料表
如果 BigQuery 資料表的資料是以 Parquet、ORC、Avro、CSV 或 JSON 格式儲存在 Cloud Storage,則適用下列限制:
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個外部資料表的來源 URI 數量上限 | 10,000 個 URI | 每個外部資料表最多可有 10,000 個來源 URI。 |
| 每個外部資料表的檔案數量上限 | 10,000,000 個檔案 | 外部資料表最多可有 1 千萬個檔案,包括符合所有萬用字元 URI 的所有檔案。 |
| 每個外部資料表在 Cloud Storage 儲存的資料大小上限 | 600 TB | 外部資料表的所有輸入檔案最多可達 600 TB。這項限制適用於儲存在 Cloud Storage 的檔案大小,與查詢定價公式中使用的大小不同。如果是外部分區資料表,系統會在分區修剪後套用限制。 |
| 來源 Cloud Storage bucket 中的檔案數量上限 | 大約 3 億個檔案 | 外部資料表可參照 Cloud Storage bucket,其中最多可包含約 3 億個檔案。如果是外部分區資料表,系統會在 分區修剪前套用這項限制。 |
分區資料表
以下限制適用於 BigQuery 分區資料表。
分區限制適用於所有載入工作、複製工作和查詢工作的總和,這些工作會附加至或覆寫目的地分區。
單一工作可能會影響多個分區。例如,查詢工作和載入工作可以寫入多個分區。
BigQuery 會根據作業影響的分區數量,判斷作業消耗的限制量。串流插入作業不會影響這項限制。
如要瞭解如何確保分區資料表不超過限制,請參閱「 排解配額錯誤」。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每個分區資料表的分區數量 | 10,000 個分區 | 每個分區資料表最多可有 10,000 個分區。如果超出這個限制,建議除了分區外,也考慮使用 分群,或改用分群。 |
| 單一工作修改的分區數量 | 4,000 個分區 | 每項工作作業 (查詢或載入) 最多可影響 4,000 個分區。 如果查詢或載入工作嘗試修改超過 4,000 個分割區,BigQuery 會拒絕執行。 |
| 每個分區資料表在擷取期間每天的分區修改次數 | 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 個層級的巢狀檢視區塊。
您可以建立最多 16 層的檢視表,但查詢最多只能有 15 層。如果超過上限,BigQuery 會傳回 INVALID_INPUT 錯誤。 |
| 用於定義檢視表的 GoogleSQL 查詢長度上限 | 25.6 萬個字元 | 定義檢視區塊的單一 GoogleSQL 查詢長度不得超過 256 KB。這項限制適用於單一查詢,不包括查詢中參照的檢視區塊長度。 |
| 每個資料集的授權 view 數量上限 | 請參閱「資料集」。 | |
| 檢視表說明的長度上限 | 16,384 個半形字元 | 為檢視畫面新增說明時,文字長度不得超過 16,384 個字元。 |
具體化檢視表
BigQuery materialized view 適用下列限制:
| 限制 | 預設 | 附註 |
|---|---|---|
| 基礎資料表參照 (相同專案) | 100 個具體化檢視表 | 每個基礎資料表最多可由同一專案中的 100 個 materialized view 參照。 |
| 基礎資料表參照 (整個組織) | 500 個具體化檢視表 | 整個組織中,每個基礎資料表最多可由 500 個 materialized view 參照。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| materialized view 說明長度上限 | 16,384 個半形字元 | 為 materialized view 新增說明時,文字長度不得超過 16,384 個字元。 |
| materialized view 重新整理工作執行時間限制 | 12 小時 | 具體化檢視區塊重新整理工作最多可執行 12 小時,之後就會失敗。 |
搜尋索引
下列限制適用於 BigQuery 搜尋索引:
| 限制 | 預設 | 附註 |
|---|---|---|
每項專案在每個區域每天的 CREATE INDEX 或 ALTER INDEX DDL 陳述式數量 |
500 項作業 |
在一個區域內,您的專案每天最多可發出 500 項 CREATE INDEX 或 ALTER INDEX DDL 作業。 |
| 每個資料表每天的搜尋索引 DDL 陳述式數量 | 20 項作業 |
每個專案每天最多可針對每個資料表發出 20 項 CREATE INDEX、
ALTER 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 的基礎資料表資料列數量上限 |
2 億列 |
資料表最多只能有 2 億列,才能建立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 查詢中,臨時和永久 user-defined function (UDF) 皆適用下列限制。
| 限制 | 預設 | 附註 |
|---|---|---|
| 每列輸出內容上限 | 5 MB | JavaScript UDF 處理單一資料列時,最多可輸出約 5 MB 的資料。 |
| 使用 JavaScript UDF 的舊版 SQL 查詢並行數量上限 | 6 項查詢 | 專案最多可同時執行六個包含 JavaScript UDF 的舊版 SQL 查詢。這項限制包含互動式和批次查詢。這項限制不適用於 GoogleSQL 查詢。 |
| 每項查詢的 JavaScript UDF 資源數量上限 | 50 項資源 | 查詢作業最多可有 50 個 JavaScript UDF 資源,例如內嵌程式碼 Blob 或外部檔案。 |
| 內嵌程式碼 blob 的大小上限 | 32 KB | UDF 中的內嵌程式碼 blob 大小上限為 32 KB。 |
| 每個外部程式碼資源的大小上限 | 1 MB | 每個 JavaScript 程式碼資源的大小上限為 1 MB。 |
persistent 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 個字元。 |
| 每 10 秒內各 UDF 的更新頻率上限 | 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 分鐘。 如果超過 Cloud Run 函式第 1 代設定的時間限制,可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 叫用時間限制 (Cloud Run 函式第 2 代或 Cloud Run) | 20 分鐘 | 個別 HTTP 叫用 Cloud Run 函式 (第 2 代) 或 Cloud Run 的時間限制。超過這個值可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 叫用重試次數上限 | 20 | 對 Cloud Run 函式 (第 1 代、第 2 代或 Cloud Run) 的個別 HTTP 叫用作業,最多可重試的次數。超過這個值可能會導致 HTTP 叫用失敗和查詢失敗。 |
資料表函式
下列限制適用於 BigQuery資料表函式:
| 限制 | 預設 | 附註 |
|---|---|---|
| 資料表函式名稱長度上限 | 256 個字元 | 資料表函式的名稱長度上限為 256 個字元。 |
| 引數名稱長度上限 | 128 個字元 | 資料表函式引數名稱的長度上限為 128 個半形字元。 |
| 引數數量上限 | 256 個引數 | 資料表函式最多可有 256 個引數。 |
| 資料表函式參照鏈結的深度上限 | 16 份參考資料 | 資料表函式參照鏈的深度最多可達 16 個參照。 |
STRUCT 型別引數或輸出的最大深度
|
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 的標準永久磁碟。已處理的查詢不會計入這項限制。 如果您在多區域位置和位於相同地理區域的單一區域位置執行並行查詢,則查詢可能會耗用相同的標準永久磁碟配額。 |
Notebooks
BigQuery 中的筆記本適用所有 Dataform 配額和限制,以及 Colab Enterprise 配額和限制。此外,也須遵守下列限制:
| 限制 | 預設 | 注意事項 |
|---|---|---|
| 筆記本大小上限 | 20 MB |
筆記本的大小是內容、中繼資料和編碼額外用量的總和。 如要查看筆記本內容大小,請展開筆記本標題,依序點選「查看」和「筆記本資訊」。 |
| 每秒傳送至 Dataform 的要求數量上限 | 100 | 筆記本是透過 Dataform 建立及管理。 任何建立或修改筆記本的操作,都會計入這項配額。這項配額與已儲存的查詢共用。舉例來說,如果您在 1 秒內對筆記本和已儲存的查詢各進行 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 (gRPC) 將資料串流至資料表。
|
| 每個資料表可同時執行的變動 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 項政策 | 一項查詢最多可存取 6,000 項資料列存取政策。 |
每項政策每 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 多區域gemini-2.0-flash-001 中記錄的單一區域,請參閱「Google 模型端點位置」 |
不適用於佈建輸送量 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 多區域gemini-2.5-pro 中記錄的單一區域,請參閱「Google 模型端點位置」 |
佈建輸送量:不適用 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 |
US、EU 和 global |
未設定配額。配額取決於動態共用配額 (DSQ)1。 | 不適用 |
1 使用 DSQ 時,用量沒有預先定義的配額限制。DSQ 提供大型共用資源集區的存取權,並根據資源的即時可用性和特定模型客戶需求,動態分配資源。當活躍客戶數量增加時,每位客戶的處理量就會減少。同樣地,當活躍客戶較少時,每位客戶可能會獲得較高的處理量。
2 佈建輸送量是固定費用、定期的訂閱方案,提供多種期限長度。透過佈建輸送量,您可以為 Agent Platform 支援的生成式 AI 模型預留輸送量。
3 如要提高配額,請在 Agent Platform 申請調整 QPM 配額。配額值增加後,請等待 30 分鐘,讓系統完成傳播。
4 您可以將 Agent Platform text-embedding 和 text-multilingual-embedding 模型的配額提高至 10,000 RPM,不需手動核准。根據每次呼叫的輸入資料列平均有 50 個權杖,每項工作可處理的資料列數量將增加至 5 億筆以上。
5 這項函式限制每個專案最多只能同時執行 5 項工作。
如要進一步瞭解 Agent Platform LLM 的配額,請參閱「Agent Platform 的生成式 AI 配額限制」。
每分鐘權杖數上限
下列限制適用於每分鐘權杖數設有限制的 Agent Platform 模型:
| 功能 | 每分鐘詞元數 | 每項工作的資料列數 | 並行執行的工作數量 |
|---|---|---|---|
AI.GENERATE_EMBEDDING 或
ML.GENERATE_EMBEDDING (使用遠端模型而非 gemini-embedding-001 模型時) |
10,000,000 | 12,000,000,每列平均 300 個符記的呼叫 | 5 |
透過 gemini-embedding-2 模型使用遠端模型時,
AI.GENERATE_EMBEDDING 或
ML.GENERATE_EMBEDDING |
5,000,000 | 1,440,000 | 5 |
每日權杖數量上限
透過 BigQuery 生成式 AI 函式存取大型語言模型時,適用下列每日 Token 使用量限制。這些限制適用於全球所有地區,您可以要求調整。 詳情請參閱「使用權杖配額控管費用」。
| 配額名稱 | 指標 | 範圍 | 預設值 |
|---|---|---|---|
| 每日 AI 輸入權杖數 | LLM 使用的輸入內容詞元 | 每天每項專案 | 200,000,000,000 |
| 每位使用者每日的 AI 輸入權杖 | LLM 使用的輸入內容詞元 | 每項專案每位使用者每日 | 150,000,000,000 |
| 每日 AI 輸出詞元 | LLM 使用的輸出和思考詞元 | 每項專案每天 | 20,000,000,000 |
| 每位使用者每天的 AI 輸出權杖數 | LLM 使用的輸出和思考詞元 | 每位使用者每天每項專案 | 15,000,000,000 |
Cloud AI 服務函式
使用 Cloud AI 服務的函式有下列限制:
| 功能 | 每分鐘要求數 | 每項工作的資料列數 | 並行執行的工作數量 |
|---|---|---|---|
ML.PROCESS_DOCUMENT,文件平均長度為 50 頁 |
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 次查詢,因此查詢 10 萬列資料大約需要 100 分鐘。為什麼工作執行時間較長?
即使輸入資料相同,工作執行時間也可能不同。在 Agent Platform 中,遠端程序呼叫 (RPC) 的優先順序各不相同,可避免配額耗盡。如果配額不足,優先順序較低的 RPC 會等待,且如果處理時間過長,可能會失敗。
如何解讀每個工作配額的資料列?
在 BigQuery 中,查詢最多可執行六小時。支援的資料列數量上限取決於這項時間軸和 Agent Platform QPM 配額,確保 BigQuery 可以在六小時內完成查詢處理。由於查詢通常無法使用整個配額,因此這個數字會低於 QPM 配額乘以 360。
如果我在資料列數超過每個工作配額的表格上執行批次推論工作 (例如 10,000,000 列),會發生什麼情況?
BigQuery 只會處理工作配額中指定的資料列數。系統只會針對這 100 萬個資料列的成功 API 呼叫收費,而非資料表中的全部 1,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 bucket,最多可包含的 BigQuery、BigLake 或外部資料表數量 | 每個 bucket 1,000 個 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 的資料表資料列資料。這項配額適用於包含所讀取資料表的專案。其他 API (包括
jobs.getQueryResults,以及從
jobs.query 和
jobs.insert 擷取結果) 也會消耗這項配額。如需疑難排解資訊,請參閱疑難排解頁面。在 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 個連線 | 您的專案每分鐘最多可建立 10 個 BigQuery Omni 連線,AWS 和 Azure 總計。 |
| BigQuery Omni 連線用途 | 每分鐘 500 次連線 | 您的專案每分鐘最多可使用 BigQuery Omni 連線 500 次。這適用於使用連線存取 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 清單要求數 每位使用者每分鐘的 EDWMigration Service List 要求數 |
12,000 項要求 2,500 項要求 |
您的專案每分鐘最多可以提出 12,000 個 Migration API List 要求。 每位使用者每分鐘最多可提出 2,500 項 Migration API 清單要求。 在 Google Cloud 控制台中查看配額 |
|
EDWMigration Service 每分鐘的 Get 要求數 每位使用者每分鐘的 EDWMigration Service Get 要求數 |
25,000 項要求 2,500 項要求 |
您的專案每分鐘最多可提出 25,000 項 Migration API Get 要求。 每位使用者每分鐘最多可提出 2,500 項 Migration API Get 要求。 在 Google Cloud 控制台中查看配額 |
|
EDWMigration Service 每分鐘其他要求數 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
以下是 Data Policy API (預先發布版) 的限制:
| 限制 | 預設 | 附註 |
|---|---|---|
最多可呼叫 dataPolicies.list 次。 |
每項專案每分鐘 400 個要求 每個組織每分鐘 600 個要求 |
|
dataPolicies.testIamPermissions 呼叫次數上限。 |
每項專案每分鐘 400 個要求 每個組織每分鐘 600 個要求 |
|
| 讀取要求數量上限。 |
每項專案每分鐘 1200 個要求 每個組織每分鐘 1800 個要求 |
包括對 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 控制台中查看配額 |
Omni-region
每項專案每分鐘 SetIAMPolicy 項要求 |
每項專案每分鐘 200 個要求 | Omni-region 專案每分鐘最多可提出 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 (gRPC)
下列配額適用於 Storage Write API (gRPC) 要求。您可以在資料夾層級套用下列配額。這些配額會匯總,並在所有子專案之間共用。如要啟用這項設定,請與 Cloud Customer Care 團隊聯絡。
如果您打算要求調整配額,請在要求中附上配額錯誤訊息,以加快處理速度。如果配額使用率顯著偏低超過一年,BigQuery 可能會減少佈建的配額。
| 配額 | 預設 | 附註 |
|---|---|---|
| 並行寫入連線 | 單一區域 5,000 個;多區域 20,000 個 |
並行連線配額是根據發出 Storage Write API (gRPC) 要求的用戶端專案計算,而非包含 BigQuery 資料集資源的專案。啟動專案是與 API 金鑰或服務帳戶相關聯的專案。 您的專案可以在一個區域中處理 5,000 個並行連線,或在 連線應長期存在,並用於傳送盡可能多的要求。不建議使用短期連線,這可能會導致並行連線配額用量增加。為便於計算配額,建議您將連線生命週期設為至少幾分鐘。 在 Java 或 Go 中使用預設串流時,建議使用儲存空間寫入 API (gRPC) 多工處理,透過共用連線寫入多個目的地資料表,以減少所需的整體連線數量。如果您使用 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 (gRPC) 要求有下列限制:
| 限制 | 預設 | 附註 |
|---|---|---|
| 批次修訂版本 | 每個資料表 10,000 個串流 |
您可以在每次 BatchCommitWriteStream 呼叫中提交最多 10,000 個串流。
|
AppendRows
要求大小
|
20 MB | 要求大小上限為 20 MB。 |
串流資料即時插入
使用 BigQuery Storage Write API (REST) 將資料串流至 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 錯誤。
|
如需更多串流配額,請參閱「申請提高配額」。
頻寬
下列配額適用於跨區域資料集複製頻寬:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的初始補充跨區域資料集複製頻寬上限,這些區域具有從主要副本到次要副本的跨區域資料輸出。 | 每個組織在每個區域可享有 10 GiBps 的實體資料傳輸 | |
| 每個區域的進行中跨區域資料集複製作業頻寬上限,這些區域的跨區域資料會從主要副本輸出至次要副本。 | 每個組織在每個區域可有 5 GiBps 的實體傳輸量 | |
| 每個區域的跨區域資料集複製作業頻寬上限,這些區域會將跨區域資料從主要副本輸出至次要副本。 | 每個組織在每個區域可有 5 GiBps 的實體傳輸量 | 強化型跨區域資料集複製頻寬配額不適用於初始補充作業。 |
如果專案的跨區域資料集複製頻寬超過特定配額,受影響專案的跨區域資料集複製作業可能會停止,並顯示 rateLimitExceeded 錯誤,其中包含超出配額的詳細資料。
下列配額適用於跨區域資料表複製頻寬:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的複製頻寬上限,該區域的資料會從來源資料表跨區域輸出至目的地資料表。 | 每個組織的每個區域配對 2 個實體 GiBps。 |