下列清單概略說明 BigQuery 在頻率和配額方面的限制。
BigQuery 對接收要求的頻率設有上限,並且會根據每個專案的狀況限定可用的配額。具體規定會因資源供應狀況、使用者結構、服務使用記錄和其他因素而有不同,並隨時可能變更,恕不另行通知。
查詢工作
以下限制適用於您在執行互動式查詢時自動建立的查詢工作,以及使用 jobs.query 和查詢類型 jobs.insert 方法呼叫時透過程式提交的工作。
- 互動式查詢的並行頻率限制:100 個並行查詢
如果查詢結果是從查詢快取傳回,則該查詢會在 BigQuery 判斷快取命中的期間計入此項限制。模擬測試查詢則不會計入這項限制配額。您可以使用 --dry_run
旗標或透過在查詢工作中設定 dryRun
屬性,指定模擬測試查詢。
這是專案層級的限制。如要提高配額上限,請與支援團隊聯絡或與銷售人員聯絡。
- 對 Cloud Bigtable 外部資料來源進行互動式查詢的並行頻率限制:4 個並行查詢
系統限制您只能對 Cloud Bigtable 外部資料來源執行 4 個並行查詢。
- 舊版 SQL 查詢包含使用者定義函式 (UDF) 時的並行頻率限制:6 個並行查詢
就包含 UDF 的舊版 SQL 查詢而言,並行頻率限制同時適用於互動式查詢及批次查詢,包含 UDF 的互動式查詢也會計入互動式查詢的並行頻率限制。不過,這項限制不適用於標準 SQL 查詢。
- 跨區域聯合式查詢:每個專案每日 1 TB
如果 BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同,就會視為跨區域查詢。每個專案每日可執行高達 1 TB 的跨地區查詢。 詳情請參閱 Cloud SQL 聯合式查詢。
- 每日查詢量限制:預設為無限制
您可以藉由設定自訂配額來指定使用者可以查詢的資料量上限。
- 每日目的地資料表更新限制:每個資料表每天可更新 1,500 次
查詢工作中的目的地資料表須符合每個資料表每日最多更新 1,500 次的限制。目的地資料表更新包括使用 Cloud Console、bq
指令列工具或透過呼叫 jobs.query
和查詢類型 jobs.insert
API 方法進行查詢時執行的附加作業和覆寫作業。
- 查詢/指令碼執行時間限制:6 小時
這項限制無法變更。在某些情況下,可以重新嘗試執行查詢。重試查詢時可以再多執行六個小時,且最多可重試三次。這可能會造成總執行時間超過六小時。
每個查詢參照的資料表數量上限:1,000 個
未解析的舊版 SQL 查詢長度上限:256 KB
未解析的標準 SQL 查詢長度上限:1 MB
已解析的舊版和標準 SQL 查詢長度上限:12 MB
就已解析的查詢而言,查詢參照的所有檢視表和萬用字元資料表的長度也會計入該查詢的長度限制額度。
標準 SQL 查詢參數數量上限:10,000 個
回應大小上限:壓縮後 10 GB1
1大小會因資料壓縮率而異。實際的回應大小可能會遠超過 10 GB。
將很大的查詢結果寫入目的地資料表時,回應大小沒有上限。
- 資料列大小上限:100 MB2
2資料列大小上限為約略值,因為此限制是根據資料列資料的內部呈現方式而定。系統會在查詢工作執行作業的某些階段對資料列大小設定上限。
資料表、查詢結果或檢視表定義中的資料欄數量上限:10,000 個
每個以量計價專案的並行運算單元數量上限:2,000 個
BigQuery 運算單元會由單一專案中的所有查詢共用。BigQuery 可能會透過爆發功能提供高於此限制的運算單元數量,藉此加快查詢速度。
如要查看您使用的運算單元數量,請參閱使用 Cloud Monitoring 監控 BigQuery 的相關說明。
- 對 Cloud Bigtable 外部資料來源的並行查詢數上限:4 個
如要瞭解 SQL 查詢中使用者定義函式適用的限制,請參閱 UDF 的限制一節。
- 已排定的查詢
雖然已排定的查詢會使用 BigQuery 資料移轉服務功能,但這類查詢並非移轉作業,也不受載入工作配額的限制。這類查詢的 BigQuery 配額和限制與手動查詢相同。
載入工作
以下限制適用於透過 Cloud Console 或 bq
指令列工具載入資料時自動建立的工作。這些限制也適用於使用載入類型 jobs.insert
API 方法透過程式提交的載入工作。
以下限制在載入資料到 BigQuery 時適用。
- 每個資料表每日載入的工作數量:1,500 個 (包括失敗的載入作業)
- 每個專案每日載入的工作數量:100,000 個 (包括失敗的載入作業)
- 資料列和儲存格大小限制:
資料格式 上限 CSV 100 MB (資料列和儲存格大小) JSON 100 MB (資料列大小) - 每個資料表的欄數上限:10,000 個
- 檔案大小上限:
檔案類型 已壓縮 未壓縮 CSV 4 GB 5 TB JSON 4 GB 5 TB - 每個載入工作的大小上限:所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案共 15 TB
- 工作設定中的來源 URI 數量上限:10,000 個 URI
- 每個載入工作的檔案數量上限:共 1000 萬個檔案,與任何萬用字元 URI 相符的所有檔案都會計入限制額度
- 載入工作執行時間限制:6 小時
- 除了位在美國的資料集之外,您必須從與資料集位在相同地區的 Cloud Storage 值區載入資料 (值區可以是多地區值區,也可以是與資料集位在同一地區的單一地區值區)。您可以從任何區域將資料載入位在美國的資料集。
詳情請參閱將資料載入 BigQuery 的簡介。
複製工作
以下限制適用於在 BigQuery 中複製資料表的情況。這些限制適用於透過 bq
指令列工具或 Cloud Console 複製資料時自動建立的工作,也適用於使用複製類型 jobs.insert
API 方法透過程式提交的複製工作。
- 每個目的地資料表每日的複製工作數量:1,000 個 (包括失敗的作業)
- 每個專案每日的複製工作數量:100,000 個 (包括失敗的作業)
匯出工作
以下限制適用於從 BigQuery 匯出資料的工作。以下限制適用於透過 bq
指令列工具或 Cloud Console 匯出資料時自動建立的工作,以及使用載入類型 jobs.insert
API 方法透過程式提交的匯出工作。
- 每日匯出作業量:每項專案 100,000 個匯出作業,且每天最多 50 TB (也就是所有匯出作業的資料量總計不得超過 50 TB)
- 萬用字元 URI:每個匯出作業 500 個萬用字元 URI
如要每天匯出超過 50 TB 的資料,請使用 BigQuery Storage API。
資料集限制
以下限制適用於資料集:
每項專案的資料集數量:無限制
- 每個資料集的資料表數量:無限制
- 如使用 API 呼叫,當資料集中的資料表數接近 50,000 個時,列舉效能會下降。Cloud Console 最多可為每個資料集顯示 50,000 個資料表。
- 資料集存取控制清單中的授權檢視表數量上限 - 2,500 個
- 您可以建立授權檢視表來限制對來源資料的存取權。授權檢視表須使用 SQL 查詢來建立,該查詢可排除您不希望使用者在查詢檢視表時看到的資料欄。您最多可以新增 2,500 個授權檢視表到資料集的存取控制清單 (ACL)。
- 資料集中繼資料更新作業的頻率上限:每個資料集每 10 秒可更新 5 次
- 資料集中繼資料更新限制適用於使用 Cloud Console、
bq
指令列工具,或透過呼叫datasets.insert
、datasets.patch
或datasets.update
API 方法執行的所有中繼資料更新作業。
- 資料集說明的長度上限:16,384 個字元
- 為資料集新增說明文字時,最多可以輸入 16,384 個字元。
資料表限制
以下限制適用於 BigQuery 資料表。
所有資料表
- 資料欄說明的長度上限:1,024 個字元
您在資料欄中新增說明時,最多可以輸入 1,024 個字元。
標準資料表
- 每日資料表作業數量上限:1,500 個
不論執行的作業是將資料附加至資料表或截斷資料表,每個資料表每天的作業數量上限為 1,500 個。
下列所有載入工作、複製工作和查詢工作均會計入資料表作業數量的配額限制:將資料附加至目的地資料表、覆寫目的地資料表,或是使用 DML INSERT
、UPDATE
、DELETE
或 MERGE
陳述式將資料寫入資料表。請注意,雖然 DML 陳述式會計入這項配額,卻「不受」這項配額限制。換句話說,DML 陳述式會計入每日作業數量的配額限制,但 DML 陳述式不會因超出配額限制而失敗。
舉例來說,如果您執行 500 項將資料附加至 mytable
的複製工作,以及 1,000 項將資料附加至 mytable
的查詢工作,就會達到配額上限。
- 資料表中繼資料更新作業的頻率上限:每個資料表每 10 秒可更新 5 次
資料表中繼資料更新限制適用於使用 Cloud Console、bq
指令列工具、用戶端程式庫、透過呼叫 tables.insert
、tables.patch
或 tables.update
API 方法,或執行 ALTER TABLE
DDL 陳述式來進行的所有中繼資料更新作業。這項限制也適用於工作輸出作業。這是一個暫時錯誤,您可以透過指數輪詢重試。此限制不適用於 DML 作業。
- 資料表、查詢結果或檢視表定義中的資料欄數量上限:10,000 個
分區資料表
每個分區資料表的分區數量上限:4,000 個
單一工作可修改的分區數量上限:4,000 個
每個工作作業 (查詢或載入作業) 最多可影響 4,000 個分區。BigQuery 會拒絕影響範圍超過 4,000 個分區的所有查詢及載入工作。
- 每個擷取時間分區資料表的分區修改次數上限:5,000 次
- 每個資料欄分區資料表的分區修改次數上限:30,000 次
在單一擷取時間分區資料表中,您每天最多總共可進行 5,000 次分區修改;如果是資料欄分區資料表,則總共可進行 30,000 次分區修改。您可以對分區中的資料執行附加或覆寫作業,藉此修改分區。修改分區的作業項目包括:載入工作、將結果寫入分區的查詢,或是修改分區中資料的 DML 陳述式 (INSERT
、DELETE
、UPDATE
或 MERGE
)。
單一工作可能會影響多個分區。例如,DML 陳述式可以更新多個分區中的資料 (同時適用於擷取時間和分區資料表)。查詢工作和載入工作也可以將資料寫入多個分區,但這項功能僅限於分區資料表。請注意,雖然 DML 陳述式會計入這項配額,卻「不受」這項配額限制。換句話說,DML 陳述式會計入每日作業數量的配額限制,但 DML 陳述式不會因超出配額限制而失敗。BigQuery 會透過受工作影響的分區數量來判斷工作占用的配額。不過,串流資料插入並不會影響這個配額。
- 分區作業頻率上限:每 10 秒 50 次分區作業
外部資料表
以下限制適用於以 Parquet、ORC、Avro、CSV 或 JSON 格式將資料儲存在 Cloud Storage 的資料表。
- 每個外部資料表的來源 URI 數量上限:10,000 個 URI
- 每個外部資料表的檔案數量上限:共 1000 萬個檔案,與任何萬用字元 URI 相符的所有檔案都會計入限制額度
- 在所有輸入檔案中,每個外部資料表在 Cloud Storage 中儲存資料的大小上限:600 TB
這項限制適用於儲存在 Cloud Storage 的檔案大小;這個大小不同於查詢定價公式使用的大小。如果是外部分區資料表,這項限制會在分區修剪後套用。
檢視表限制
- 巢狀檢視表層級數量上限:16 層
BigQuery 最多支援 16 層的巢狀檢視表。如果巢狀層級超過 16 層,會傳回 INVALID_INPUT
錯誤。
- 用於定義檢視表的標準 SQL 查詢長度上限:256,000 個字元
建立檢視表時,標準 SQL 查詢的文字不得超過 256,000 個字元。
- 資料集存取控制清單 (ACL) 中的授權檢視表數量上限:2,500 個
您可以建立授權檢視表來限制對來源資料的存取權。授權檢視表須使用 SQL 查詢來建立,該查詢可排除您不希望使用者在查詢檢視表時看到的資料欄。您最多可以新增 2,500 個授權檢視表到資料集的存取控制清單 (ACL)。
UDF 的限制
以下限制適用於 SQL 查詢中暫時性和永久的使用者定義函式。
- JavaScript UDF 處理單一資料列時輸出的資料量:約 5 MB 或更少。
- 舊版 SQL 查詢包含使用者定義函式 (UDF) 時的並行頻率限制:6 個並行查詢。
- 查詢工作中內嵌程式碼 blob 或外部檔案等 JavaScript UDF 資源的數量上限:50 項。
- 每個內嵌程式碼 blob 的大小上限:32 KB。
- 每項外部程式碼資源的大小上限:1 MB。
就包含使用者定義函式的舊版 SQL 查詢而言,並行頻率限制同時適用於互動式查詢及批次查詢,包含 UDF 的互動式查詢也會計入互動式查詢的並行頻率限制。不過,這項限制不適用於標準 SQL 查詢。
以下限制適用於永久性使用者定義函式。
- 函式名稱的長度上限:256 個字元
- 引數的數量上限:256 個
- 引數名稱的長度上限:128 個字元
- 使用者定義函式參考鏈深度上限:16 層
- 引數或 STRUCT 類型輸出內容的深度上限:15 層
- 引數或各個 UDF STRUCT 類型輸出內容中的欄位數量上限:1,024 個
- 每項查詢的不重複 UDF 加資料表參照數量上限:1,000 項。完全展開之後,每個 UDF 可以參照的不重複資料表和 UDF 數量加總不超過 1,000 個。
- CREATE FUNCTION 陳述式中的 JavaScript 程式庫數量上限:50 個
- 加入的 JavaScript 程式庫路徑長度上限:5,000 個字元
- 每個 UDF 的更新頻率上限:每 10 秒 5 次。函式建立完成之後,您可以更新每個函式,頻率上限為每 10 秒 5 次。
- 每個內嵌程式碼 blob 的大小上限為 32 KB。
- 每項 JavaScript 程式碼資源的大小上限為 1 MB。
資料操縱語言陳述式
BigQuery DML 陳述式無配額限制。
不過,DML 陳述式會計入每日資料表作業數量和每日分區修改次數上限。DML 陳述式「不會」因超出配額限制而失敗。
此外,DML 陳述式受資料表中繼資料更新作業的頻率上限所限制。一旦超出限制,請在每次重試之間使用指數輪詢重試作業。
串流資料插入
以下限制適用於將串流資料插入 BigQuery 的情況。
如果在插入資料列時未在 insertId
欄位中填入資料,則適用下列配額規定。詳情請參閱停用盡可能清除重複的功能。如果想要提高串流擷取配額限制,建議採用這種方式來使用 BigQuery。
- 每秒位元組數上限:1 GB:如果您未在
insertId
欄位中替插入的每個資料列填入資料,則每項專案每秒最多只能使用 1 GB 資料量。此為專案層級的限制,並不適用於個別資料表。超過這個數量時,系統就會產生quotaExceeded
錯誤。
如果在插入資料列時已在 insertId
欄位中填入資料,則適用下列配額規定。
- 在
us
和eu
多地區中,每項專案每秒的資料列數量上限:500,000 個 - 如果您已在
insertId
欄位中替插入的每個資料列填入資料,則在us
和eu
的多地區中,每項專案每秒最多只能使用 500,000 列。在指定的多地區中,這項配額會持續累計。換句話說,在多地區中特定專案每秒串流至所有資料表的資料列總和上限為 500,000 個。此外,每個資料表每秒也有 100,000 個資料列的上限。
每項專案或每個資料表超過限制時,系統就會產生quotaExceeded
錯誤。
- 在
- 在其他所有位置,每項專案每秒的資料列數量上限為:100,000 個
- 如果您已在
insertId
欄位中替插入的每個資料列填入資料,則在us
和eu
多地區以外的所有位置中,每項專案或每個資料表每秒最多只能使用 100,000 列。在指定的地區中,這項配額會持續累計。換句話說,在某個地區中特定專案每秒串流至所有資料表的資料列總和上限為 100,000 個。
超過這個數量時,系統就會產生quotaExceeded
錯誤。
- 每個資料表每秒資料列數量上限為:100,000 個
- 如果您已在
insertId
欄位中替插入的每個資料列填入資料,則每個資料表每秒最多只能使用 100,000 列。
超過這個數量時,系統就會產生quotaExceeded
錯誤。
- 每秒位元組數上限:100 MB
- 如果您已在
insertId
欄位中為插入的每個資料列填入資料,則每個資料表每秒最多只能使用 100 MB 的資料。
超過這個數量時,系統就會產生quotaExceeded
錯誤。
無論您是否在 insertId
欄位中填入資料,都適用下列額外的串流配額:
- 資料列大小上限:5 MB
- 如果超過這個值,系統就會產生
invalid
錯誤。
- HTTP 要求大小上限:10 MB (請參閱附註)
- 如果超過這個值,系統就會產生
invalid
錯誤。
- 每項要求的資料列數量上限:每項要求 10,000 個資料列
- 建議上限為 500 個資料列。以批次方式處理要求可以將成效和總處理量提高至一定程度,但每項要求都會發生延遲。如果每項要求的資料列數量過少,要求產生的工作負擔可能會導致擷取作業效率低落。當每項要求的資料列數量過多時,總處理量可能會減少。
我們建議每項要求最多使用 500 個資料列,但使用代表性資料 (結構定義和資料大小) 進行實驗可以協助您找出理想的批次大小。
insertId
欄位長度:128- 如果超過這個值,系統就會產生
invalid
錯誤。
如果專案需要更多串流配額,您可以停用盡可能清除重複的功能。如果想要將配額提高到超出上限,可以在 Google Cloud Console 中提交要求。我們預計會在 2 至 3 個工作天內回覆您的要求。
API 要求
所有 API 要求
以下限制適用於所有 BigQuery API 要求:
- 每位使用者每秒的 API 要求數量:100 個
- 如果您每秒發出超過 100 項要求,可能會遇到速率限縮的情況。這項限制不適用於串流資料插入。
- 每位使用者的並行 API 要求數量:300 個
- 如果您對單一使用者發出超過 300 次並行要求,可能會遇到速率限縮的情況。這項限制不適用於串流資料插入。
tabledata.list
要求
tabledata.list
方法會從一組指定的資料列中擷取資料表資料。包含 jobs.getQueryResults 與會透過 jobs.query 和 jobs.insert 擷取結果的其他 API 可能也會耗用這個 API 的配額。以下限制適用於 tabledata.list
要求:
- 每個專案的
tabledata.list
查詢數量上限:每秒 500 個 - 呼叫
tabledata.list
時,每秒最多可為每項專案提交 500 個要求。
- 每個專案的
- 在每個專案中呼叫
tabledata.list
而傳回的每秒位元組數上限:每秒 60 MB - 當您呼叫
tabledata.list
時,每個專案每秒最多可傳回 60 MB 的資料表列資料。這項限制適用於系統正在讀取的資料表所屬的專案。
- 在每個專案中呼叫
- 在每個專案中呼叫
tabledata.list
而傳回的每秒資料列數量上限:每秒 150,000 列 - 當您呼叫
tabledata.list
時,每個專案每秒最多可傳回 150,000 個資料表列。這項限制適用於系統正在讀取的資料表所屬的專案。
- 在每個專案中呼叫
tables.insert
要求
tables.insert
方法會在資料集中建立新的空白資料表。以下限制適用於 tables.insert
要求:
- 每個專案的每秒要求數量上限:10 項 - 當您呼叫
tables.insert
時,每秒最多可為每個專案建立 10 項要求。這項限制適用於建立資料表的陳述式 (例如CREATE TABLE
DDL 陳述式),以及將結果寫入目的地資料表的查詢。
projects.list
要求
projects.list
方法會列出您可以存取的所有專案。以下限制適用於 projects.list
要求:
- 每個專案的每秒要求數量上限:2 個。呼叫
projects.list
時,每秒最多可為每個專案建立 2 個要求。
jobs.get
要求
jobs.get
方法會傳回特定工作的相關資訊。以下限制適用於 jobs.get
要求:
- 每個專案的每秒要求數量上限:1,000 個。呼叫
jobs.get
時,每秒最多可為每個專案建立 1,000 個要求。
jobs.query
要求
jobs.query
方法會同步執行 SQL 查詢,並在查詢於指定的逾時時間內完成時傳回查詢結果。
- 回應大小上限:10 MB。根據預設,每個結果頁面傳回的資料列數量並沒有上限。然而,回應大小最多不能超過 10 MB。如要改變傳回的資料列數量,請使用
maxResults
參數。
IAM API 要求
在 BigQuery 使用身分與存取權管理功能來擷取與設定 IAM 政策並測試 IAM 權限時,適用下列限制:
在 Google Cloud 專案層級,每位使用者每秒發出的要求限定在 25 個。
在 Google Cloud 專案層級,每秒所能發出的要求限定在 50 個。
如果您的專案需要更多 IAM 配額,您可以透過 Google Cloud Console 提交申請。我們預計會在 2 至 3 個工作天內回覆您的申請。
BigQuery Storage API 要求
以下限制適用於使用 BigQuery Storage API 執行 ReadRows
呼叫:
- 每分鐘的
ReadRows
呼叫次數上限:5,000 次。使用 BigQuery Storage API 讀取資料時,每個專案每位使用者每分鐘的呼叫次數限定在 5,000 次ReadRows
。
以下限制適用於使用 BigQuery Storage API 的所有其他方法呼叫:
- 每分鐘 API 呼叫的次數上限:1,000 次。每個專案每位使用者每分鐘所能發出的 BigQuery Storage API 呼叫次數限定在 1,000 次。
系統什麼時候會補充配額?
在一天當中,系統會定時為您補充每日配額,以便達到控管頻率限制行為的目標。另外,系統也會間歇性重新整理,以免在配額耗盡時發生服務長時間中斷的狀況。一般來說,系統在幾分鐘內即可提供更多配額,並非一天僅全面補充一次。
疑難排解
如要瞭解對配額限制相關錯誤進行疑難排解的相關資訊,請參閱排解 BigQuery 配額錯誤。
設定配額用量上限
如要瞭解如何限制特定資源的用量,避免超出 Google 指定的上限,請參閱設定用量上限。