配額與限制
這份文件列出 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 控制台或 Google Cloud CLI,找出 BigQuery 配額和系統限制的指標名稱和配額 ID (也稱為「限制名稱」):
控制台
在 Google Cloud 控制台,前往「Quotas & System Limits」(配額與系統限制) 頁面。
按一下 「Filter」(篩選器),選取「Service」(服務),然後選取要檢查的 BigQuery 服務,例如「BigQuery API」、「BigQuery Reservation API」或「BigQuery Storage API」。
在表格標題中,按一下「 Column display options」(資料欄顯示選項),選取「Metric」(指標) 和「Limit name」(限制名稱),然後按一下「OK」(確定)。
gcloud
請執行 gcloud beta quotas info list 指令。
gcloud beta quotas info list --project=PROJECT_ID_OR_NUMBER \
--service=SERVICE_NAME \
--format="table(metric, name, quota_id, dimensions)"
更改下列內容:
PROJECT_ID_OR_NUMBER: Google Cloud 專案 ID 或專案編號。SERVICE_NAME:要檢查的 BigQuery 服務名稱:- 核心 BigQuery API:
bigquery.googleapis.com - Storage Read API 和 Storage Write API (gRPC):
bigquerystorage.googleapis.com - BigQuery Reservation API:
bigqueryreservation.googleapis.com - BigQuery Migration API:
bigquerymigration.googleapis.com - BigQuery 資料移轉服務 API:
bigquerydatatransfer.googleapis.com - BigQuery Connection API:
bigqueryconnection.googleapis.com - BigLake API:
biglake.googleapis.com - BigQuery sharing (原 Analytics Hub) API:
analyticshub.googleapis.com - BigQuery Data Policy API:
bigquerydatapolicy.googleapis.com
工作
無論是透過 Google Cloud 控制台、bq 指令列工具,還是使用 REST API 或用戶端程式庫,BigQuery 代為執行的工作都適用配額和限制。
待處理工作
BigQuery 待處理工作有以下限制:
| 系統限制 | 預設 | 附註 |
|---|---|---|
| 待處理工作數量上限 | 每個專案和區域 50,000 項工作 | 可處於待處理狀態的並行工作數量。此上限無法提高。詳情請參閱「排解 BigQuery 配額錯誤」。 |
查詢工作
下列配額適用於透過執行互動式查詢、排定查詢,以及使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作,自動建立的查詢工作。
如需疑難排解資訊,請參閱 BigQuery 疑難排解頁面。
配額
指標和配額 ID
預設
附註
每日查詢用量
指標:
bigquery.googleapis.com/quota/query/usage
配額 ID: QueryUsagePerDay
200 TiB
這項配額僅適用於隨選查詢定價模式。專案每天最多可執行 200 TiB 的查詢。你隨時可以變更這項限制。如要進一步瞭解費用控管,請參閱「建立自訂查詢配額」。
每位使用者每日查詢用量
指標:
bigquery.googleapis.com/quota/query/usage
配額 ID: QueryUsagePerUserPerDay
無限制
這項配額僅適用於隨選查詢定價模式。根據預設,使用者每天可執行的查詢 TiB 數量沒有限制。你隨時可以設定上限。無論每位使用者的用量限制為何,專案中所有使用者的總用量都不得超過每日查詢用量上限。如要進一步瞭解費用控管,請參閱「建立自訂查詢配額」。
GoogleSQL 聯合查詢跨區域位元組數 (每日)
指標:
bigquery.googleapis.com/quota/query/cloud_sql_federated_query_cross_region_bytes
配額 ID: CloudSqlFederatedQueryCrossRegionBytesPerDay
1 TB
如果
BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同,則查詢屬於跨區域查詢。您的專案每天最多可執行 1 TB 的跨區域查詢。請參閱「Cloud SQL 聯合查詢」。
BigQuery Omni 每天移轉的位元組數
指標:
bigquery.googleapis.com/quota/query/cross_cloud_transfer_bytes
配額 ID: CrossCloudTransferBytesPerDay
1 TB
您每天最多可以從 Amazon S3 值區或 Azure Blob 儲存體移轉 1 TB 的資料。
BigQuery Omni 每日查詢結果總大小
指標:
bigquery.googleapis.com/quota/query/omni_query_bytes
配額 ID: OmniQueriesBytesPerDay
1 TB
專案的查詢結果大小總計為每天 1 TB。
詳情請參閱「BigQuery Omni 限制」。
下列系統限制適用於透過執行互動式查詢、排定查詢和使用 jobs.query 和查詢類型 jobs.insert API 方法提交的工作自動建立的查詢工作:
執行 DDL 陳述式來變更全域設定選項時,每 10 秒最多可執行五個陳述式。這項限制適用於下列 DDL 陳述式: 查詢或多陳述式查詢最多可執行 6 小時,然後就會失敗。不過,如果發生伺服器重新啟動等暫時性問題,BigQuery 可能會在內部重試查詢工作。BigQuery 最多可嘗試執行查詢三次,每次嘗試最多可執行 6 小時。因此,查詢的總執行時間可能會超過 6 小時 (最多 18 小時)。如要確認工作是否已重試,可以查看下列信號: 詳情請參閱查詢疑難排解說明文件中的「執行時間」一節。
系統限制
值
附註
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
排入佇列的互動式查詢數量上限
1,000 次查詢
專案最多可將 1,000 項互動式查詢排入佇列。
超過這項限制的其他互動式查詢會傳回配額錯誤。如要排解這些錯誤,請參閱「避免大量互動式查詢的限制」。
排入佇列的批次查詢數量上限
20,000 項查詢
專案最多可將 20,000 項批次查詢排入佇列。如果額外的批次查詢超過這項限制,系統會傳回配額錯誤。
Bigtable 外部資料來源的互動式查詢並行數量上限
16 項查詢
專案最多可對 Bigtable 外部資料來源同時執行十六項查詢。
包含遠端函式的並行查詢數量上限
10 項查詢
每個專案最多可使用
遠端函式同時執行十項查詢。
並行多重陳述式查詢數量上限
1,000 項多陳述式查詢
專案最多可同時執行 1,000 項多重陳述式查詢。如要瞭解與多重陳述式查詢相關的其他配額和限制,請參閱「 多重陳述式查詢」。
含有 UDF 的並行舊版 SQL 查詢數量上限
6 項查詢
您的專案最多可以同時執行六項含有 user-defined function (UDF) 的舊版 SQL 查詢。這項限制包含互動式和批次查詢。含有 UDF 的互動式查詢也會計入互動式查詢的並行限制。這項限制不適用於 GoogleSQL 查詢。
每日查詢大小限制
無限制
根據預設,每日查詢大小沒有限制。不過,您可以建立自訂配額,控管每日查詢用量或每位使用者每日查詢用量,藉此限制使用者可查詢的資料量。
每日目的地資料表更新限制
請參閱「每日資料表作業數量上限」。
查詢工作中對目的地資料表的更新,會計入目的地資料表每日資料表作業數量上限。目的地資料表更新包括附加和覆寫作業,這些作業是由您使用 Google Cloud 控制台、bq 指令列工具,或呼叫
jobs.query 和查詢類型 jobs.insert API 方法執行的查詢所執行。
查詢/多重陳述式查詢執行時間限制
6 小時
INFORMATION_SCHEMA:在 INFORMATION_SCHEMA.JOBS 檢視畫面中,查看 final_execution_duration_ms 欄。如果 start_time 和 end_time 之間的差異明顯大於 final_execution_duration_ms,則表示查詢已重試。JobStatistics 物件中,查看 finalExecutionDurationMs 欄位。如果 startTime 和 endTime 之間的差異明顯大於 finalExecutionDurationMs,則表示查詢已重試。CREATE MODEL 工作的預設逾時時間為 24 小時,但時間序列、AutoML 和超參數調整工作的逾時時間為 48 小時。
每項查詢參照的資源數量上限
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 秒
如果採用隨選定價模式,每掃描 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 資料列大小上限
10 MiB
查詢 Microsoft Azure 或 AWS 資料時,資料列大小上限為 10 MiB。詳情請參閱「BigQuery Omni 限制」一節。
全域查詢轉移
每秒 2 GiB
全域查詢使用的傳輸頻寬,依專案和區域組合計算
雖然排定的查詢會使用 BigQuery 資料移轉服務的功能,但排定的查詢並非移轉作業,因此不受載入工作限制規範。
擷取工作
下列配額適用於使用 bq 指令列工具、 Google Cloud 控制台或擷取類型 jobs.insert API 方法,從 BigQuery 擷取資料的工作:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每天擷取的位元組數上限 |
指標: bigquery.googleapis.com/quota/extract/bytes配額 ID: ExtractBytesPerDay
|
50 TiB |
每日 50 TiB 的限制 (ExtractBytesPerDay) 是防範濫用的限制,僅適用於使用免費共用運算單元集區的擷取工作。使用共用運算單元集區,每天最多可從專案擷取 50 TiB 的資料,無須付費。您可以設定 Cloud Monitoring 警告政策,在擷取位元組數量時傳送通知。擷取工作不受每日 50 TiB 的限制,如果您執行下列任一操作,則可超過此限制:
|
| 每日擷取工作數量上限 |
指標: bigquery.googleapis.com/quota/extract/count配額 ID: ExtractJobsPerDay
|
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 項載入工作。 |
| 每個資料表的資料欄數量上限 | 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 小時。 |
預留項目
預留項目適用下列配額:
配額
指標和配額 ID
預設
附註
歐盟區域的運算單元總數
指標:
bigqueryreservation.googleapis.com/total_slots_eu
配額 ID: TotalSlotsPerProjectEU
5,000 個運算單元
您在歐盟多區域中,可透過 Google Cloud 控制台購買的 BigQuery 運算單元數量上限。
美國區域的運算單元總數
指標:
bigqueryreservation.googleapis.com/total_slots_us
配額 ID: TotalSlotsPerProjectUS
10,000 個運算單元
您在美國多區域中,可透過 Google Cloud 控制台購買的 BigQuery 運算單元數量上限。
us-east1 區域的運算單元總數
指標:
bigqueryreservation.googleapis.com/total_slots
配額 ID: TotalSlotsPerProject
4,000 個運算單元
您可以使用 Google Cloud 控制台,在所列區域購買的 BigQuery 運算單元數量上限。
下列區域的運算單元總數:
asia-south1、asia-southeast1、europe-west2、us-central1、us-west1
指標:
bigqueryreservation.googleapis.com/total_slots
配額 ID: TotalSlotsPerProject
2,000 個運算單元
您可以使用 Google Cloud 控制台,在各個列出的區域中購買 BigQuery 運算單元,數量上限如下。
下列區域的運算單元總數:
asia-east1、asia-northeast1、asia-northeast3、asia-southeast2、australia-southeast1、europe-north1、europe-west1、europe-west3、europe-west4、northamerica-northeast1、us-east4、southamerica-east1
指標:
bigqueryreservation.googleapis.com/total_slots
配額 ID: TotalSlotsPerProject
1,000 個運算單元
您可以使用 Google Cloud 控制台,在各個列出的區域中購買 BigQuery 運算單元,數量上限如下。
BigQuery Omni 區域的運算單元總數
指標:
bigqueryreservation.googleapis.com/totalslotsOMNI_REGION (例如 bigqueryreservation.googleapis.com/total_slots_aws-us-east-1)
配額 ID: TotalSlotsPerProjectOMNI_REGION (例如 TotalSlotsPerProjectAwsUSEast1)
100 個運算單元
您可以使用 Google Cloud 控制台,在 BigQuery Omni 區域購買的 BigQuery 運算單元數量上限。
所有其他區域的運算單元總數
指標:
bigqueryreservation.googleapis.com/total_slots
配額 ID: TotalSlotsPerProject
500 個運算單元
您可以使用 Google Cloud 控制台,在其他各區域購買的 BigQuery 運算單元數量上限。
運算單元預留項目的管理專案數量
指標:
bigqueryreservation.googleapis.com/total_admin_projects
配額 ID: TotalAdminProjectsPerOrganization
每個組織 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, 000 萬個檔案,包括與所有萬用字元 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 個複製項目,就會達到上限。 |
瀏覽次數
下列配額和限制適用於檢視表和materialized view。
邏輯檢視表
BigQuery 標準檢視表適用下列限制:
| 系統限制 | 預設 | 附註 |
|---|---|---|
| 巢狀檢視層級數量上限 | 16 個等級 |
BigQuery 支援最多 16 層的巢狀檢視表。您可以建立最多達到這個上限的檢視表,但查詢最多只能有 15 個層級。如果超過上限,BigQuery 會傳回 INVALID_INPUT 錯誤。 |
| 用於定義檢視表的 GoogleSQL 查詢長度上限 | 25.6 萬個字元 | 定義檢視表的單一 GoogleSQL 查詢長度上限為 256 K 個字元。這項限制適用於單一查詢,不包含查詢中參照的檢視長度。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| 檢視表說明的長度上限 | 16,384 個半形字元 | 為檢視表新增說明時,文字長度不得超過 16,384 個字元。 |
materialized view
BigQuery materialized view 適用下列限制:
| 系統限制 | 預設 | 附註 |
|---|---|---|
| 基礎資料表參照 (相同專案) | 100 個 materialized view | 每個基礎資料表最多可由同一專案中的 100 個 materialized view 參照。 |
| 基礎資料表參照 (整個組織) | 500 個 materialized view | 整個組織中,每個基礎資料表最多可由 500 個 materialized view 參照。 |
| 每個資料集的授權檢視表數量上限 | 請參閱「資料集」。 | |
| materialized view 說明的長度上限 | 16,384 個半形字元 | 為 materialized view 新增說明時,文字長度不得超過 16,384 個字元。 |
| materialized view 重新整理工作執行時間限制 | 12 小時 | materialized view 重新整理工作最多可執行 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 億列 |
資料表最多可有 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 項查詢 | 專案最多可同時執行六個包含 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 functions 第 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 functions 第 1 代) | 9 分鐘 | 您可以為第 1 代 Cloud Run 函式的個別 HTTP 叫用設定時間限制,但上限為 9 分鐘。如果超過 Cloud Run 函式第 1 代設定的時間限制,可能會導致 HTTP 叫用失敗和查詢失敗。 |
| HTTP 叫用時間限制 (Cloud Run functions 第 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 | Notebooks 是透過 Dataform 建立及管理。 任何建立或修改筆記本的操作,都會計入這項配額。這項配額與已儲存的查詢共用。舉例來說,如果您在 1 秒內對筆記本進行 50 次變更,並對已儲存的查詢進行 50 次變更,就會達到配額上限。 |
已儲存的查詢
所有 Dataform 配額和限制都適用於已儲存的查詢。此外,也須遵守下列限制:
| 系統限制 | 預設 | 注意事項 |
|---|---|---|
| 已儲存的查詢大小上限 | 10 MB | |
| 每秒傳送至 Dataform 的要求數量上限 | 100 | 已儲存的查詢是透過 Dataform 建立及管理。任何建立或修改已儲存的查詢的動作,都會計入這項配額。這項配額與筆記本共用。舉例來說,如果您在 1 秒內對筆記本進行 50 次變更,並對已儲存的查詢進行 50 次變更,就會達到配額上限。 |
data manipulation language
BigQuery data manipulation language (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 項資料列存取政策。 |
| 每項查詢的資料列存取政策數量上限 | 6,000 項政策 | 一項查詢最多可存取 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
工作有以下限制:
| 系統限制 | 預設 | 附註 |
|---|---|---|
每項專案每 48 小時可執行 CREATE MODEL
次陳述式查詢 |
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 的單一區域 |
不適用於佈建輸送量 9,300,000 (DSQ),適用於平均有 500 個輸入詞元和 50 個輸出詞元的呼叫 |
||
gemini-2.5-pro |
US 和 EU 多區域Google 模型端點位置中 gemini-2.5-pro 的單一區域 |
不適用於佈建輸送量 7,600,000 (DSQ),適用於平均有 500 個輸入詞元和 50 個輸出詞元的呼叫 |
||
AI.IFAI.SCOREAI.CLASSIFY |
多種 gemini-2.5-* 模型 |
US和EU多區域Google 模型端點位置中 gemini-2.5-* models支援的任何單一區域 |
沒有設定配額。配額由動態共用配額 (DSQ)1 決定 | 10,000,000 (呼叫時,每個輸入列平均有 500 個詞元,輸出則有 50 個詞元)。 |
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 次要求,不需人工核准。假設每次呼叫的每個輸入資料列平均有 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 |
AI.GENERATE_EMBEDDING 或
ML.GENERATE_EMBEDDING,當使用遠端模型而非 gemini-embedding-2 模型時 |
5,000,000 | 1,440,000 | 5 |
每日權杖數量限制
透過 BigQuery 生成式 AI 函式存取大型語言模型時,權杖用量有下列每日上限。這些限制適用於全球所有區域,您可以要求調整。 詳情請參閱「使用權杖配額控管費用」。
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每日 AI 輸入詞元 |
指標: bigquery.googleapis.com/quota/query/ai_input_tokens配額 ID: GenAiInputTokensPerDay
|
200,000,000,000 | LLM 使用的輸入詞元。適用於每項專案,每日計算。 |
| 每位使用者每天的 AI 輸入權杖 |
指標: bigquery.googleapis.com/quota/query/ai_input_tokens配額 ID: GenAiInputTokensPerUserPerDay
|
150,000,000,000 | LLM 使用的輸入詞元。適用於每位使用者每天在每項專案中的用量。 |
| 每日 AI 輸出詞元數量 |
指標: bigquery.googleapis.com/quota/query/ai_output_tokens配額 ID: GenAiOutputTokensPerDay
|
20,000,000,000 | LLM 使用的輸出和思考詞元。適用於每項專案,每日計算。 |
| 每位使用者每天的 AI 輸出詞元數量 |
指標: bigquery.googleapis.com/quota/query/ai_output_tokens配額 ID: GenAiOutputTokensPerUserPerDay
|
15,000,000,000 | LLM 使用的輸出和思考詞元。適用於每位使用者每天在每項專案中的用量。 |
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 次查詢,因此查詢 100,000 列資料大約需要 100 分鐘。為什麼工作執行時間較長?
即使輸入資料相同,工作執行時間也可能不同。在 Agent Platform 中,遠端程序呼叫 (RPC) 有不同的優先順序,以免配額用盡。如果配額不足,優先順序較低的 RPC 會等待,如果處理時間過長,可能會失敗。
如何解讀每項工作的資料列配額?
在 BigQuery 中,查詢最多可執行六小時。支援的資料列數量上限取決於這段時間和您的 Agent Platform 每分鐘查詢數配額,以確保 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 (核心) 要求適用下列配額:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每日要求數 |
指標: bigquery.googleapis.com/unlimited_requests配額 ID: UnlimitedRequestsPerDayPerProject
|
無限制 | 您的專案每天可以提出無限數量的 BigQuery API 要求。 |
每分鐘最多 tabledata.list 個位元組
|
指標: bigquery.googleapis.com/quota/tabledata/list_bytes_us、bigquery.googleapis.com/quota/tabledata/list_bytes_eu、bigquery.googleapis.com/quota/tabledata/list_bytes_regional配額 ID: ListBytesPerSecondUs、ListBytesPerSecondEu、ListBytesPerSecondRegional
|
多區域 7.5 GB;所有其他區域 3.7 GB |
在 us 和 eu 多區域中,您的專案使用 tabledata.list 每分鐘最多可傳回 7.5 GB 的資料表資料列資料,在所有其他區域中則為每分鐘 3.7 GB。這項配額適用於包含所讀取資料表的專案。其他 API (包括
jobs.getQueryResults,以及從
jobs.query 和
jobs.insert 擷取結果) 也可能耗用這項配額。如需疑難排解資訊,請參閱疑難排解頁面。
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 要求適用下列配額:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每分鐘讀取要求數 |
指標: bigqueryconnection.googleapis.com/read_requests配額 ID: ReadRequestsPerMinutePerProject
|
每分鐘 1,000 項要求 | 您的專案每分鐘最多可向讀取連線資料的 BigQuery Connection API 方法提出 1,000 項要求。 |
| 每分鐘寫入要求數 |
指標: bigqueryconnection.googleapis.com/write_requests配額 ID: WriteRequestsPerMinutePerProject
|
每分鐘 100 項要求 | 您的專案每分鐘最多可向 BigQuery Connection API 方法提出 100 項要求,建立或更新連線。 |
| 每分鐘建立的 BigQuery Omni 連線數 |
指標: bigqueryconnection.googleapis.com/bq_omni_connection_creations配額 ID: BQOmniConnectionsCreatedPerMinute
|
每分鐘建立 10 個連線 | 您的專案每分鐘最多可在 AWS 和 Azure 建立 10 個 BigQuery Omni 連線。 |
| BigQuery Omni 連線用途 |
指標: bigqueryconnection.googleapis.com/bq_omni_connection_uses配額 ID: BQOmniConnectionUsesPerMinute
|
每分鐘 500 次連線 | 專案每分鐘最多可使用 BigQuery Omni 連線 500 次。這適用於使用連線存取 AWS 帳戶的操作,例如查詢資料表。 |
BigQuery Migration API
下列配額適用於 BigQuery Migration API。在大多數情況下,系統會套用下列預設值。專案的預設值可能有所不同:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| EDWMigration Service 每分鐘列出要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_list_requests配額 ID: ListRequestsPerMinutePerProject
|
12,000 項要求 | 您的專案每分鐘最多可提出 12,000 項 Migration API 清單要求。 |
| 每位使用者每分鐘的 EDWMigration Service 清單要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_list_requests配額 ID: ListRequestsPerMinutePerProjectPerUser
|
2,500 項要求 | 每位使用者每分鐘最多可提出 2,500 項 Migration API 清單要求。 |
| EDWMigration Service 每分鐘 GET 要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_get_requests配額 ID: GetRequestsPerMinutePerProject
|
25,000 項要求 | 專案每分鐘最多可提出 25,000 項 Migration API Get 要求。 |
| 每位使用者每分鐘的 EDWMigration Service GET 要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_get_requests配額 ID: GetRequestsPerMinutePerProjectPerUser
|
2,500 項要求 | 每位使用者每分鐘最多可提出 2,500 項 Migration API Get 要求。 |
| EDWMigration Service 每分鐘其他要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_other_requests配額 ID: OtherRequestsPerMinutePerProject
|
25 項要求 | 您的專案每分鐘最多可提出 25 項其他 Migration API 要求。 |
| 每位使用者每分鐘的 EDWMigration Service 其他要求數 |
指標: bigquerymigration.googleapis.com/edwmigration_service_other_requests配額 ID: OtherRequestsPerMinutePerProjectPerUser
|
5 項要求 | 每位使用者每分鐘最多可提出 5 項其他 Migration API 要求。 |
| 每分鐘互動式 SQL 翻譯要求數 |
指標: bigquerymigration.googleapis.com/sql_translation_translate_requests配額 ID: TranslationRequestsPerMinutePerProject
|
200 項要求 | 專案每分鐘最多可提出 200 項 SQL 翻譯服務要求。 |
| 每位使用者每分鐘的互動式 SQL 翻譯要求數 |
指標: bigquerymigration.googleapis.com/sql_translation_translate_requests配額 ID: TranslationRequestsPerMinutePerProjectPerUser
|
50 項要求 | 每位使用者每分鐘最多可提出 50 項 SQL 翻譯服務要求。 |
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 Reservation API
BigQuery Reservation API 要求適用下列配額:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每個區域每分鐘的要求數 |
指標: bigqueryreservation.googleapis.com/requests配額 ID: RequestsPerMinutePerProjectPerRegion
|
100 項要求 | 在每個區域中,專案每分鐘最多可對 BigQuery Reservation API 方法發出 100 次呼叫。 |
各區域每分鐘的 SearchAllAssignments 呼叫次數
|
指標: bigqueryreservation.googleapis.com/search_all_assignments_requests配額 ID: SearchAllAssignmentsRequestsPerMinutePerProjectPerRegion
|
100 個要求 |
在每個區域中,專案每分鐘最多可對
SearchAllAssignments 方法發出 100 次呼叫。 |
每位使用者在各區域每分鐘對 SearchAllAssignments 提出的要求數
|
指標: bigqueryreservation.googleapis.com/search_all_assignments_requests配額 ID: SearchAllAssignmentsRequestsPerMinutePerProjectPerUserPerRegion
|
10 項要求 |
每位使用者每分鐘在每個區域最多可對
SearchAllAssignments 方法發出 10 次呼叫。 |
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 中使用 Identity and Access Management 功能擷取及設定 IAM 政策,以及測試 IAM 權限時,適用下列配額。資料控制語言 (DCL) 陳述式會計入 SetIAMPolicy 配額。
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
每位使用者每分鐘 IamPolicy 項要求 |
指標: bigquery.googleapis.com/iam_policy_requests配額 ID: IamPolicyRequestsPerMinutePerUser
|
每位使用者每分鐘 1,500 項要求 | 每位使用者每分鐘最多可對每項專案提出 1,500 項要求。 |
每項專案每分鐘 IamPolicy 項要求 |
指標: bigquery.googleapis.com/iam_policy_requests配額 ID: IamPolicyRequestsPerMinutePerProject
|
每項專案每分鐘 3,000 個要求 | 專案每分鐘最多可提出 3,000 項要求。 |
每項專案每分鐘的單一區域 SetIAMPolicy 要求數 |
指標: bigquery.googleapis.com/set_iam_policy_requests配額 ID: SetIamPolicyRequestsPerMinutePerProject
|
每項專案每分鐘 1,000 個要求 | 單一區域專案每分鐘最多可提出 1,000 項要求。 |
每項專案每分鐘的多區域SetIAMPolicy要求數 |
指標: bigquery.googleapis.com/set_iam_policy_requests_global配額 ID: SetIamPolicyRequestsPerMinutePerProjectGlobal
|
每項專案每分鐘 2,000 個要求 | 多區域專案每分鐘最多可提出 2,000 項要求。 |
每項專案每分鐘的 Omni 區域SetIAMPolicy要求數 |
指標: bigquery.googleapis.com/set_iam_policy_requests_OMNI_REGION (例如 bigquery.googleapis.com/set_iam_policy_requests_aws-us-east-1)配額 ID: SetIamPolicyRequestsPerMinutePerProjectOMNI_REGION (例如 SetIamPolicyRequestsPerMinutePerProjectAwsUsEast1)
|
每項專案每分鐘 200 個要求 | Omni-region 專案每分鐘最多可提出 200 項要求。 |
Storage Read API
下列配額適用於 BigQuery Storage Read API 要求:
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 每位使用者每分鐘的讀取資料層要求數 |
指標: bigquerystorage.googleapis.com/data_plane_requests配額 ID: DataPlaneRequestsPerMinutePerProjectPerUser
|
25,000 項要求 |
每位使用者每分鐘最多可對每項專案發出 25,000 次 ReadRows 呼叫。 |
| 並行讀取連線數量上限 |
指標: bigquerystorage.googleapis.com/read/max_concurrent_connections_us、bigquerystorage.googleapis.com/read/max_concurrent_connections_eu、bigquerystorage.googleapis.com/read/max_concurrent_connections_region配額 ID: MaxConcurrentReadConnectionsPerProjectUS、MaxConcurrentReadConnectionsPerProjectEU、MaxConcurrentReadConnectionsPerProjectRegion
|
多區域 2,000 個;區域 400 個 |
每項專案的並行 ReadRows 連線數量上限。us 和 eu 多區域的預設值為 2,000 個連線,其他區域則為 400 個連線。實際連線可用性可能會因整個區域的服務負載和需求而有所波動。這項動態調整機制可確保資源公平分配,並維持所有使用者的服務穩定性。如果串流因公平性而關閉,或達到連線限制,您會收到 RESOURCE_EXHAUSTED 錯誤 (HTTP 429)。配額提高要求 (QIR) 的審查依據,是專案過往的使用模式,以及區域內資源的一般可用性。 |
| 每位使用者每分鐘的讀取控制層要求數 |
指標: bigquerystorage.googleapis.com/control_plane_requests配額 ID: ControlPlaneRequestsPerMinutePerProjectPerUser
|
5,000 項要求 |
每位使用者每分鐘最多可對每項專案執行 5,000 次 Storage Read API 中繼資料作業呼叫。中繼資料呼叫包括 CreateReadSession 和 SplitReadStream 方法。 |
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 可能會減少佈建的配額。
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
| 並行寫入連線 |
指標: bigquerystorage.googleapis.com/write/max_active_streams、bigquerystorage.googleapis.com/write/max_active_streams_eu、bigquerystorage.googleapis.com/write/max_active_streams_region配額 ID: ConcurrentWriteConnectionsPerProject、ConcurrentWriteConnectionsPerProjectEU、ConcurrentWriteConnectionsPerProjectRegion
|
單一區域 5,000 個;多區域 20,000 個 |
並行連線配額是根據發出 Storage Write API (gRPC) 要求的用戶端專案計算,而非包含 BigQuery 資料集資源的專案。啟動專案是與 API 金鑰或服務帳戶相關聯的專案。專案在單一區域可同時運作 5,000 個連線,在 連線應長期存在,並用於傳送盡可能多的要求。不建議使用短期連線,這可能會導致並行連線配額用量增加。為方便計算配額,建議您將連線生命週期設為至少幾分鐘。 在 Java 或 Go 中使用預設串流時,建議使用 Storage Write API (gRPC) 多工處理,透過共用連線寫入多個目的地資料表,減少所需的整體連線數量。如果您使用 Beam 連接器,並採用至少一次語意,則可將 UseStorageApiConnectionPool 設為 您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據所在區域選取並行連線限制名稱。選項包括 |
| 處理量 |
指標: bigquerystorage.googleapis.com/write/append_bytes、bigquerystorage.googleapis.com/write/append_bytes_eu、bigquerystorage.googleapis.com/write/append_bytes_region配額 ID: AppendBytesThroughputPerProject、AppendBytesThroughputPerProjectEU、AppendBytesThroughputPerProjectRegion
|
多區域每秒 3 GB 處理量;區域每秒 300 MB |
在 us 和 eu 多區域中,每項專案最多可串流 3 GBps 的資料,在其他區域則可串流 300 MBps 的資料。您可以在 Cloud Monitoring 中查看專案的用量配額和限制指標。根據所在區域選取處理量限制名稱。選項分別為 |
CreateWriteStream 項要求
|
指標: bigquerystorage.googleapis.com/write/create_stream_requests、bigquerystorage.googleapis.com/write/create_stream_requests_eu、bigquerystorage.googleapis.com/write/create_stream_requests_region配額 ID: CreateWriteStreamRequestsPerMinutePerProject、CreateWriteStreamRequestsPerMinutePerProjectEU、CreateWriteStreamRequestsPerMinutePerProjectRegion
|
每項專案每區域每小時 10,000 個串流 |
每項專案在每個區域每小時最多可呼叫 CreateWriteStream 10,000 次。如果不需要僅一次語意,建議使用預設串流。這項配額是以小時為單位,但 Google Cloud 控制台顯示的指標是以分鐘為單位。 |
| 待處理的串流位元組 |
指標: bigquerystorage.googleapis.com/write/pending_stream_bytes、bigquerystorage.googleapis.com/write/pending_stream_bytes_eu、bigquerystorage.googleapis.com/write/pending_stream_bytes_region配額 ID: PendingWriteStreamBytesPerProject、PendingWriteStreamBytesPerProjectEU、PendingWriteStreamBytesPerProjectRegion
|
多區域 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 可能會減少佈建的配額。
| 配額 | 指標和配額 ID | 預設 | 附註 |
|---|---|---|---|
us 和 eu 多區域中,每個專案每秒的位元組數上限 |
指標: bigquery.googleapis.com/quota/streaming/insert_bytes_us、bigquery.googleapis.com/quota/streaming/insert_bytes_eu配額 ID: StreamingInsertBytesPerSecondUs、StreamingInsertBytesPerSecondEu
|
每秒 1 GB |
專案每秒最多可串流 1 GB。這項配額會在指定的多區域內累計。換句話說,在多區域中,每秒串流至特定專案所有資料表的位元組總和上限為 1 GB。如果超過這項限制,系統會傳回 如有需要,您可以與 Cloud Customer Care 聯絡,要求提高配額。請盡早提出提高配額的要求,最晚應在需要配額的兩週前提出。配額增加需要一段時間才會生效,尤其是大幅增加的情況。 |
| 所有其他位置每項專案每秒位元組數上限 |
指標: bigquery.googleapis.com/quota/streaming/insert_bytes配額 ID: StreamingInsertBytesPerSecond
|
每秒 300 MB |
除了 如有需要,您可以與 Cloud Customer Care 聯絡,要求提高配額。請盡早提出提高配額的要求,最晚應在需要配額的兩週前提出。配額增加需要一段時間才會生效,尤其是大幅增加的情況。 |
使用 BigQuery Storage Write API (REST) 將資料串流至 BigQuery 時,適用下列系統限制:
| 系統限制 | 值 | 附註 |
|---|---|---|
| 資料列大小上限 | 10 MB |
如果超過這個值,就會發生 invalid 錯誤。 |
| HTTP 要求大小限制 | 10 MB |
超過這個值會導致 invalid 錯誤。在內部,要求會從 HTTP JSON 轉譯為內部資料結構。翻譯後的資料結構有強制的大小限制。我們很難預測產生的內部資料結構大小,但如果將 HTTP 要求保持在 10 MB 以下,就不太可能達到內部限制。 |
| 每項要求的資料列數量上限 | 50,000 列 | 建議上限為 500 個資料列。批次處理可提高效能和處理量,但會增加每項要求的延遲時間。如果每個要求的資料列太少,且每個要求的負擔過重,可能會導致擷取效率不彰。如果每項要求的資料列過多,處理量可能會下降。請使用具代表性的資料 (結構定義和資料大小) 進行實驗,判斷資料的理想批次大小。 |
insertId 欄位長度
|
128 個字元 |
如果超過這個值,就會發生 invalid 錯誤。 |
如需更多串流配額,請參閱「申請提高配額」。
頻寬
下列配額適用於跨區域資料集複製頻寬:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的初始補充跨區域資料集複製頻寬上限,該區域具有從主要副本到次要副本的跨區域資料輸出。 | 每個組織在每個區域可有 10 GiBps 的實體資料 | |
| 每個區域中,從主要副本到次要副本的跨區域資料輸出,持續跨區域資料集複製頻寬上限。 | 每個組織在每個區域可有 5 GiBps 的實體傳輸量 | |
| 每個區域的跨區域資料集複製作業頻寬上限,該區域具有從主要副本到次要副本的跨區域資料輸出。 | 每個組織在每個區域可有 5 GiBps 的實體傳輸量 | 強化型跨區域資料集複製頻寬配額不適用於初始回填作業。 |
如果專案的跨區域資料集複製頻寬超過特定配額,受影響專案的跨區域資料集複製作業可能會停止,並顯示 rateLimitExceeded 錯誤,其中包含超出配額的詳細資料。
下列配額適用於跨區域資料表複製頻寬:
| 配額 | 預設 | 附註 |
|---|---|---|
| 每個區域的複製頻寬上限,其中有從來源資料表到目的地資料表的跨區域資料輸出。 | 每個組織的每個區域配對 2 個實體 GiBps。 |