配額與限制

BigQuery 對接收要求的頻率設有上限，並且會根據每個專案的狀況限定可用的配額。具體規定會因資源供應狀況、使用者個人資料、服務使用記錄和其他因素而有不同，並隨時可能變更，恕不另行通知。

下方清單概略說明系統目前在頻率和配額方面的限制。

查詢工作

以下限制適用於您在執行互動式查詢時自動建立的查詢工作，以及使用 jobs.query 和查詢類型 jobs.insert 方法呼叫時透過程式提交的工作。

如果查詢結果是從查詢快取傳回，則該查詢會在 BigQuery 判斷快取命中的期間計入此項限制。模擬測試查詢則「不」會計入這項限制配額。您可以使用 --dry_run 旗標或透過在查詢工作中設定 dryRun 屬性，指定模擬測試查詢。

這是專案層級的限制。如要提高配額，請與支援小組聯絡或與銷售人員聯絡。

  • 對 Bigtable 外部資料來源進行互動式查詢的並行頻率限制：4 個並行查詢

您最多只能對單一 Bigtable 外部資料來源執行 4 個並行查詢。

  • 舊版 SQL 查詢包含使用者定義函式 (UDF) 時的並行頻率限制：6 個並行查詢

就包含 UDF 的舊版 SQL 查詢而言，並行頻率限制同時適用於互動式查詢及批次查詢，包含 UDF 的互動式查詢也會計入互動式查詢的並行頻率限制。不過，這項限制不適用於標準 SQL 查詢。

  • 跨地區聯合式查詢：每個專案每日 1 TB

如果 BigQuery 查詢處理位置和 Cloud SQL 執行個體位置不同，就會視為跨地區查詢。每個專案每日可執行高達 1 TB 的跨地區查詢。 詳情請參閱 Cloud SQL 聯合式查詢。

  • 每日查詢量限制：預設為無限制

您可以藉由設定自訂配額來指定使用者可以查詢的資料量上限。

  • 每日目的地資料表更新限制：每個資料表每天可更新 1,500 次

查詢工作中的目的地資料表須遵守每個資料表每日可更新 1,500 次的限制。目的地資料表更新包括使用主控台、BigQuery 傳統網頁版 UI、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 的相關說明。

  • 對單一 Bigtable 外部資料來源進行查詢的並行查詢數量上限：4 個

如要瞭解 SQL 查詢中使用者定義函式適用的限制，請參閱 UDF 的限制一節。

載入工作

以下限制適用於使用指令列工具、Cloud Console 或 BigQuery 傳統網頁版 UI 載入資料時自動建立的工作。這些限制也適用於使用載入類型 jobs.insert API 方法透過程式提交的載入工作。

以下限制在載入資料到 BigQuery 時適用。

  • 每個資料表每日載入的工作數量 - 1,500 個 (包括失敗的載入作業)
  • 每個專案每日載入的工作數量：100,000 個 (包括失敗的載入作業)
    • 您不能提高每個資料表每日 1,500 個載入工作的上限。
  • 資料列和儲存格大小限制：
    資料格式 上限
    CSV 100 MB (資料列和儲存格大小)
    JSON 100 MB (資料列大小)
  • 每個資料表的欄數上限：10,000 個
  • 檔案大小上限：
    檔案類型 已壓縮 未壓縮
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
    Avro 系統不支援壓縮的 Avro 檔案，但支援壓縮的資料區塊。BigQuery 支援 DEFLATE 與 Snappy 轉碼器。 5 TB (檔案標頭 1 MB)
  • 每個載入工作的大小上限：所有 CSV、JSON、Avro、Parquet 和 ORC 輸入檔案共 15 TB
  • 工作設定中的來源 URI 數量上限：10,000 個 URI
  • 每個載入工作的檔案數量上限：共 1000 萬個檔案，與任何萬用字元 URI 相符的所有檔案都會計入限制額度
  • 載入工作執行時間限制：6 小時
  • 除了位在美國的資料集之外，您必須從與資料集位在相同地區的 Cloud Storage 值區載入資料 (值區可以是多地區值區，也可以是與資料集位在同一地區的單一地區值區)。您可以從任何地區將資料載入位在美國的資料集。

詳情請參閱將資料載入 BigQuery 的簡介。

複製工作

以下限制適用於在 BigQuery 中複製資料表的情況。這些限制適用於透過指令列工具、主控台或 BigQuery 傳統網頁版 UI 複製資料時自動建立的工作，也適用於使用複製類型 jobs.insert API 方法透過程式提交的複製工作。

  • 每個目的地資料表每日的複製工作數量：1,000 個 (包括失敗的作業)
  • 每個專案每日的複製工作數量：100,000 個 (包括失敗的作業)

匯出工作

以下限制適用於從 BigQuery 匯出資料的工作。以下限制適用於使用指令列工具、主控台或 BigQuery 傳統網頁版 UI 匯出資料時自動建立的工作，以及使用載入類型 jobs.insert API 方法透過程式提交的匯出工作。

  • 每日匯出作業量：每項專案 100,000 個匯出作業，且每天最多 10 TB (也就是所有匯出作業的資料量總計不得超過 10 TB)

    • 如要每天匯出超過 10 TB 的資料，請使用 BigQuery Storage API。

  • 萬用字元 URI：每個匯出作業 500 個萬用字元 URI

資料集限制

以下限制適用於資料集：

  • 每個專案的資料集數量：無限制
    儘管每個專案的資料集數量不受配額限制，但是當專案中的資料集接近數千個時，傳統網頁版 UI 的效能會開始降低，列出資料集的速度也會變慢。
  • 每個資料集的資料表數量：無限制
    資料集中的資料表接近 50,000 個或數量更多時，列舉資料表的速度會變慢。無論您使用 API 呼叫還是 BigQuery 傳統網頁版 UI，列舉效能都會受到影響。目前，GCP Console 中的 BigQuery 網頁版 UI 僅允許您每個資料集顯示 50,000 個資料表。如要提高 BigQuery 傳統網頁版 UI 的效能，請使用 ?minimal 參數，限制每個專案僅顯示 30,000 個資料表。您可以按照以下格式將這項參數新增至 BigQuery 傳統網頁版 UI 的網址：https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal。
  • 資料集存取控制清單 (ACL) 中的授權檢視表數量上限：2,500 個
    您可以建立授權檢視表來限制對來源資料的存取權。授權檢視表須使用 SQL 查詢來建立，該查詢可排除您不希望使用者在查詢檢視表時看到的資料欄。您最多可以新增 2,500 個授權檢視表到資料集的存取控制清單 (ACL)。
  • 資料集中繼資料更新作業的頻率上限：每個資料集每 10 秒可更新 5 次
    資料集中繼資料更新限制適用於使用主控台、BigQuery 傳統網頁版 UI、bq 指令列工具，或透過呼叫 datasets.insert、datasets.patch 或 datasets.update API 方法執行的所有中繼資料更新作業。
  • 資料集說明的長度上限：16,384 個字元
    為資料集新增說明文字時，最多可以輸入 16,384 個字元。

資料表限制

以下限制適用於 BigQuery 資料表。

所有資料表

  • 資料欄說明的長度上限：16,384 個字元

您在資料欄中新增說明時，最多可以輸入 16,384 個字元。

標準資料表

  • 每日資料表作業數量上限：1,500 個

不論執行的作業是將資料附加至資料表或截斷資料表，每個資料表每天的作業數量上限為 1,500 個。

下列所有載入工作、複製工作和查詢工作皆會計入資料表作業次數的配額限制：將資料附加至目的地資料表、覆寫目的地資料表，或是使用 DML INSERT、UPDATE、DELETE 或 MERGE 陳述式將資料寫入資料表。請注意，雖然 DML 陳述式可使用這項配額，但不會受到這項配額的限制。換句話說，DML 陳述式不會因超出配額限制而失敗。

舉例來說，如果您執行 500 個將資料附加至 mytable 的複製工作，以及 1,000 個將資料附加至 mytable 的查詢工作，就會達到配額上限。

  • 資料表中繼資料更新作業的頻率上限：每個資料表每 10 秒可更新 5 次

資料表中繼資料更新限制適用於使用 Cloud Console、BigQuery 傳統網頁版 UI、bq 指令列工具、用戶端程式庫、透過呼叫 tables.insert、tables.patch 或 tables.update API 方法，或執行 ALTER TABLE DDL 陳述式來進行的所有中繼資料更新作業。這項限制也適用於工作輸出作業。

  • 資料表、查詢結果或檢視表定義中的資料欄數量上限：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 陳述式不會因超出配額限制而失敗。 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 K 個字元

建立檢視表時，標準 SQL 查詢的文字不得超過 256 K 個字元。

  • 資料集存取控制清單 (ACL) 中的授權檢視表數量上限：2,500 個

您可以建立授權檢視表來限制對來源資料的存取權。授權檢視表須使用 SQL 查詢來建立，該查詢可排除您不希望使用者在查詢檢視表時看到的資料欄。您最多可以新增 2,500 個授權檢視表到資料集的存取控制清單 (ACL)。

UDF 的限制

以下限制適用於 SQL 查詢中暫時性和永久性的使用者定義函式。

  • 處理單一資料列時，JavaScript UDF 輸出的資料量：約 5 MB 或更低。
  • 舊版 SQL 查詢包含使用者定義函式 (UDF) 時的並行頻率限制：6 個並行查詢。

    • 就包含 UDF 的舊版 SQL 查詢而言，並行頻率限制同時適用於互動式查詢及批次查詢，包含 UDF 的互動式查詢也會計入互動式查詢的並行頻率限制。不過，這項限制不適用於標準 SQL 查詢。

  • 查詢工作中內嵌程式碼 blob 或外部檔案等 JavaScript UDF 資源的數量上限：50 項。
  • 每個內嵌程式碼 blob 的大小上限：32 KB。
  • 每項外部程式碼資源的大小上限：1 MB。

以下限制適用於永久性使用者定義函式。
  • 函式名稱的長度上限：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 陳述式無配額限制。

串流資料插入

以下限制適用於將串流資料插入 BigQuery 的情況。

如果您在插入資料列時未在 insertId 欄位中填入資料，則適用下列配額規定。詳情請參閱停用盡可能清除重複的功能。

  • 每秒位元組數上限：1 GB：如果您未在 insertId 欄位中為插入的每個資料列填入資料，則每項專案每秒最多只能使用 1 GB 資料量。此為專案層級的限制，並不適用於個別資料表。超過這個數量時，系統就會產生 quotaExceeded 錯誤。

如果您在插入資料列時已在 insertId 欄位中填入資料，則適用下列配額規定。

  • 每秒資料列數量上限：100,000 個
    如果您已在 insertId 欄位中為插入的每個資料列填入資料，則各專案或資料表每秒最多只能使用 100,000 個資料列。這項配額會持續累計。您可以將全部的配額用於單一資料表，或是將配額用於一項專案中多個資料表的資料串流。

    超過這個數量時，系統就會產生 quotaExceeded 錯誤。
  • 每秒位元組數上限：100 MB
    如果您已在 insertId 欄位中為插入的每個資料列填入資料，則每個資料表每秒最多只能使用 100 MB 的資料。

    超過這個數量時，系統就會產生 quotaExceeded 錯誤。

無論您是否在 insertId 欄位中填入資料，都適用下列額外的串流配額：

  • 資料列大小上限：1 MB
    如果超過這個值，系統就會產生 invalid 錯誤。
  • HTTP 要求大小上限：10 MB (請參閱附註)
    如果超過這個值，系統就會產生 invalid 錯誤。
  • 每項要求的資料列數量上限：每項要求 10,000 個資料列
    建議上限為 500 個資料列。以批次方式處理要求可以將成效和總處理量提高至一定程度，但每項要求都會發生延遲。如果每項要求的資料列數量過少，要求產生的工作負擔可能會導致擷取作業效率低落。當每項要求的資料列數量過多時，總處理量可能會減少。

    我們建議每項要求最多使用 500 個資料列，但使用代表性資料 (結構定義和資料大小) 進行實驗可以協助您找出理想的批次大小。
  • insertId 欄位長度：128
    如果超過這個值，系統就會產生 invalid 錯誤。

如果您的專案需要更多串流配額，您可以透過 Google Cloud Console 提交要求。您可以設定串流資料的自訂配額 (以 50,000 個資料列為單位遞增)。我們預計會在 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 要求：

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 參數。

BigQuery Storage API 要求

以下限制適用於使用 BigQuery Storage API 的 ReadRows 呼叫：

  • 每分鐘的 ReadRows 呼叫次數上限：5,000 次。使用 BigQuery Storage API 讀取資料時，每個專案每位使用者每分鐘最多可以呼叫 ReadRows 5,000 次。

以下限制適用於使用 BigQuery Storage API 的所有其他方法呼叫：

  • 每分鐘 API 呼叫的次數上限：1,000 次 - 每個專案每位使用者每分鐘的 BigQuery Storage API 呼叫次數上限為 1,000 次。

系統什麼時候會補充配額？

在一天當中，系統會定時為您補充每日配額，以便達到控管頻率限制行為的目標。另外，系統也會間歇性重新整理，以免在配額耗盡時發生服務長時間中斷的狀況。一般來說，系統在幾分鐘內即可提供更多配額，並非一天僅全面補充一次。

錯誤代碼

配額及限制錯誤會傳回 403 或 400 HTTP 回應碼。如需錯誤代碼和疑難排解步驟的完整清單，請參閱排解錯誤一文。

設定配額使用量上限

如要瞭解如何限制特定資源的用量，使其不超過 Google 指定的上限，請參閱設定使用量上限一文。