Kontingente und Limits

Überblick

In diesem Dokument sind die für BigQuery geltenden Kontingente und Limits aufgeführt.

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten.

Kontingente sind Teil eines Systems, das Folgendes tut:

  • Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
  • Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
  • Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
  • Eine Möglichkeit bietet, das Kontingent zu ändern oder anzufordern.

Wenn ein Kontingent überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Cloud-Projekt verwenden.

Für BigQuery-Ressourcen gelten außerdem Beschränkungen. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.

Standardmäßig gelten BigQuery-Kontingente und -Limits pro Projekt. Kontingente und Limits, die auf anderer Basis angewendet werden, sind entsprechend gekennzeichnet. Beispiel: die maximale Anzahl der Spalten pro Tabelle oder die maximale Anzahl gleichzeitiger API-Anfragen pro Nutzer. Die einzelnen Richtlinien können je nach Ressourcenverfügbarkeit, Nutzerprofil, Service Usage-Verlauf sowie weiteren Faktoren unterschiedlich sein und ohne Vorankündigung geändert werden.

Kontingentauffüllung

Die täglichen Kontingente werden den ganzen Tag über in regelmäßigen Intervallen aufgefüllt, um das Verhalten von Ratenbegrenzungen zu steuern. So werden auch längere Unterbrechungen durch aufgebrauchte Kontingente vermieden. Das Aufstocken dieser erfolgt – im Vergleich zu einer einzigen täglichen Gesamtauffüllung – meist schon innerhalb weniger Minuten.

Kontingenterhöhung anfordern

Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingent anfordern.

Klicken Sie auf Anleitung, um eine detaillierte Anleitung zum Anfordern einer Kontingenterhöhung in der Console zu erhalten:

Anleitung

Kontingentnutzung einschränken

Informationen zum Einschränken der Nutzung einer bestimmten Ressource durch Angabe eines kleineren Kontingents als die Standardeinstellung finden Sie unter Nutzung einschränken.

Erforderliche Berechtigungen

Zum Anzeigen und Aktualisieren Ihrer BigQuery-Kontingente in der Kontingent in der Console ansehen anzusehen benötigen Sie die gleichen Berechtigungen wie für alle Google Cloud-Kontingente. Weitere Informationen finden Sie unter Google Cloud-Kontingentberechtigungen.

Fehlerbehebung

Informationen zur Fehlerbehebung bei Kontingenten und Limits finden Sie unter Fehler in BigQuery-Kontingenten beheben.

Jobs

Kontingente und Beschränkungen gelten für Jobs, die BigQuery für Sie ausführt, unabhängig davon, ob sie mit der Google Cloud Console, dem bq-Befehlszeilentool oder programmatisch mit der REST API oder Clientbibliotheken ausgeführt werden.

Abfragejobs

Die folgenden Kontingente gelten für Abfragejobs, die durch die Ausführung von interaktiven Abfragen, geplanten Abfragen und Jobs, die mit den API-Methoden jobs.query und jobs.insert (Typ „query“) gesendet werden, automatisch erstellt werden:

Kontingent Standard Hinweise
Abfragenutzung pro Tag Unbegrenzt Die Anzahl der Byte, die von Abfragen in einem Projekt verarbeitet werden können, ist nicht begrenzt.
Kontingent in der Console ansehen
Abfragenutzung pro Tag und Nutzer Unbegrenzt Die Anzahl der Byte, die die Abfragen eines Nutzers pro Tag verarbeiten können, ist unbegrenzt.
Kontingent in der Console ansehen
Regionenübergreifende Byte pro Tag für föderierte Cloud SQL-Abfragen 1 TB Wenn sich der BigQuery-Standort zur Abfrageverarbeitung und der Cloud SQL-Instanzstandort unterscheiden, ist Ihre Abfrage regionenübergreifend. Ihr Projekt kann pro Tag bis zu 1 TB an regionenübergreifenden Abfragen ausführen. Siehe Föderierte Cloud SQL-Abfragen.
Kontingent in der Console ansehen

Die folgenden Limits gelten für Abfragejobs, die durch die Ausführung von interaktiven Abfragen, geplanten Abfragen und Jobs, die mit den API-Methoden jobs.query und jobs.insert (Typ „query“) gesendet werden, automatisch erstellt werden:

Limit Standard Hinweise
Maximale Anzahl gleichzeitiger interaktiver Abfragen 100 Abfragen Ihr Projekt kann bis zu 100 interaktive Abfragen gleichzeitig ausführen. Abfragen mit Ergebnissen, die vom Abfrage-Cache zurückgegeben werden, werden für die Dauer, die BigQuery zur Feststellung eines Cache-Treffers benötigt, auf dieses Limit angerechnet. Probelauf-Abfragen werden nicht auf dieses Limit angerechnet. Sie können eine Probelauf-Abfrage mit dem Flag --dry_run angeben. Informationen zu Strategien, um innerhalb dieses Limits zu bleiben, finden Sie unter Kontingentfehler beheben.
Maximale Anzahl gleichzeitiger interaktiver Abfragen externer Cloud Bigtable-Datenquellen 4 Abfragen Mit dem Projekt können bis zu vier Abfragen gleichzeitig in einer externen Bigtable-Datenquelle ausgeführt werden.
Maximale Anzahl gleichzeitiger Abfragen, die Remotefunktionen enthalten 10 Abfragen Sie können bis zu zehn Abfragen gleichzeitig mit Remotefunktionen pro Projekt ausführen.
Maximale Anzahl gleichzeitiger Abfragen mit mehreren Anweisungen 1.000 Abfragen mit mehreren Anweisungen Ihr Projekt kann bis zu 1.000 Abfragen mit mehreren Anweisungen gleichzeitig ausführen.
Maximale Anzahl gleichzeitiger Legacy-SQL-Abfragen, die UDFs enthalten 6 Abfragen Ihr Projekt kann bis zu sechs Legacy-SQL-Abfragen mit benutzerdefinierten Funktionen (UDFs) gleichzeitig ausführen. Dieses Limit umfasst sowohl interaktive als auch Batchabfragen. Interaktive Abfragen, die UDFs enthalten, werden auch auf das Limit für gleichzeitige interaktive Abfragen angerechnet. Dieses Limit gilt nicht für Standard-SQL-Abfragen.
Tageslimit für die Abfragegröße Unbegrenzt Standardmäßig gibt es kein Tageslimit für die Abfragegröße. Sie können jedoch die Menge der von Nutzern abgefragten Daten begrenzen, indem Sie benutzerdefinierte Kontingente erstellen.
Tageslimit für die Zieltabellenaktualisierung Siehe Maximale Anzahl von Tabellenvorgängen pro Tag. Aktualisierungen von Zieltabellen in einem Abfragejob werden auf das Limit für die maximale Anzahl von Tabellenvorgängen pro Tag für die Zieltabellen angerechnet. Zu den Aktualisierungen der Zieltabelle gehören Anhänge- und Überschreibungsvorgänge, die von Abfragen ausgeführt werden, die Sie mithilfe der Console, des bq-Befehlszeilentools oder des Aufrufs der API-Methoden jobs.query und jobs.insert (Typ "query") ausführen.
Limit für die Ausführungszeit von Abfragen/Mehrfachanweisungen 6 Stunden Eine Abfrage oder eine Abfrage mit mehreren Anweisungen kann bis zu sechs Stunden dauern und schlägt dann fehl. Manchmal werden Abfragen jedoch wiederholt. Eine Abfrage kann bis zu dreimal wiederholt werden und jeder Versuch kann bis zu sechs Stunden dauern. Daher kann eine Abfrage eine Gesamtlaufzeit von mehr als sechs Stunden haben.
Maximale Anzahl von Ressourcen, auf die pro Abfrage verwiesen wird 1.000 Ressourcen Eine Abfrage kann nach vollständiger Erweiterung auf bis zu 1.000 einzelne Tabellen, einzelne Ansichten, einzelne benutzerdefinierte Funktionen (UDFs) und einzelne Tabellenfunktionen (Vorschau) verweisen. Dieses Limit umfasst Folgendes:
  • Tabellen, Ansichten, UDFs und Tabellenfunktionen, auf die die Abfrage direkt verweist.
  • Tabellen, Ansichten, UDFs und Tabellenfunktionen, auf die von anderen Ansichten/UDFs/Tabellenfunktionen verwiesen wird, auf die die Abfrage verweist.
  • Tabellen, die sich aus der Erweiterung von Platzhaltertabellen ergeben, die in der Abfrage oder den anderen referenzierten Ansichten/UDFs/Tabellenfunktionen verwendet werden.
Maximale Länge ungelöster Legacy-SQL-Abfragen 256 KB Eine ungelöste Legacy-SQL-Abfrage kann bis zu 256 KB lang sein. Wenn Ihre Abfrage länger ist, wird der folgende Fehler angezeigt: The query is too large. Wenn Sie innerhalb dieses Limits bleiben möchten, sollten Sie eventuell große Arrays oder Listen durch Abfrageparameter ersetzen.
Maximale Länge ungelöster Standard-SQL-Abfragen 1 MB Eine ungelöste Standard-SQL-Abfrage kann bis zu 1 MB lang sein. Wenn Ihre Abfrage länger ist, wird der folgende Fehler angezeigt: The query is too large. Wenn Sie innerhalb dieses Limits bleiben möchten, sollten Sie eventuell große Arrays oder Listen durch Abfrageparameter ersetzen.
Maximale Länge gelöster Legacy- und Standard-SQL-Abfragen 12 MB Das Limit für die Länge der gelösten Abfragen umfasst die Länge aller Ansichten und Platzhaltertabellen, auf die sich die Abfrage bezieht.
Maximale Anzahl von Standard-SQL-Abfrageparametern 10.000 Parameter Eine Standard-SQL-Abfrage kann bis zu 10.000 Parameter haben.
Maximale Anfragegröße 10 MB Die Anfragegröße kann bis zu 10 MB betragen, einschließlich zusätzlicher Attribute wie Abfrageparameter.
Maximale Antwortgröße 10 GB komprimiert Die Größe ist je nach Komprimierungsverhältnis der Daten unterschiedlich. Die tatsächliche Größe der Antwort kann 10 GB deutlich überschreiten. Beim Schreiben umfangreicher Abfrageergebnisse in eine Zieltabelle ist die maximale Größe der Antwort unbegrenzt.
Maximale Zeilengröße 100 MB Die maximale Zeilengröße ist ein Näherungswert, da das Limit auf der internen Darstellung der Zeilendaten basiert. Es kommt in bestimmten Phasen der Ausführung eines Abfragejobs zur Anwendung.
Maximale Anzahl von Spalten in einer Tabelle, einem Abfrageergebnis oder einer Ansichtsdefinition 10.000 Spalten Eine Tabelle, ein Abfrageergebnis oder eine Ansichtsdefinition kann bis zu 10.000 Spalten enthalten.
Maximale Anzahl gleichzeitiger Slots für On-Demand-Preise 2.000 Slots Bei On-Demand-Preisen kann Ihr Projekt bis zu 2.000 Slots gleichzeitig ausführen. BigQuery-Slots werden auf alle Abfragen in einem Einzelprojekt aufgeteilt. BigQuery kann dieses Limit überschreiten, um Ihre Abfragen zu beschleunigen. Informationen darüber, wie viele Slots Sie nutzen, finden Sie unter Einführung in BigQuery-Monitoring.
Maximale CPU-Nutzung pro gescannten Daten zu On-Demand-Preisen 256 CPU-Sekunden pro gescannten MiB Bei On-Demand-Preisen kann Ihre Abfrage etwa bis zu 256 CPU-Sekunden pro MiB gescannter Daten nutzen. Wenn die Abfrage für die verarbeitete Datenmenge zu CPU-intensiv ist, schlägt die Abfrage mit dem Fehler billingTierLimitExceeded fehl. Weitere Informationen finden Sie unter billingTierLimitExceeded.

Obwohl geplante Abfragen Features von BigQuery Data Transfer Service verwenden, sind sie keine Übertragungen und unterliegen nicht den Limits für Ladejobs.

Exportjobs

Die folgenden Limits gelten für Jobs, die Daten aus BigQuery exportieren, indem das bq-Befehlszeilentool, die Console oder die API-Methode jobs.insert (Typ "export") verwendet wird.

Limit Standard Hinweise
Maximale Anzahl exportierter Byte pro Tag 50 TB Mit dem freigegebenen Slot-Pool kann Ihr Projekt bis zu 50 Terabyte pro Tag kostenlos exportieren. Wenn Sie mehr als 50 TB Daten pro Tag exportieren möchten, haben Sie folgende Möglichkeiten:
Maximale Anzahl von Exporten pro Tag 100.000 Exporte Ihr Projekt kann bis zu 100.000 Exporte pro Tag ausführen. So können Sie mehr als 100.000 Exporte pro Tag ausführen:
Platzhalter-URIs pro Export 500 URIs Ein Export kann bis zu 500 Platzhalter-URIs enthalten.

Ladejobs

Die folgenden Limits gelten, wenn Sie Daten in BigQuery laden, indem Sie die Console, das bq-Befehlszeilentool oder die API-Methode jobs.insert (Typ „load“) verwenden.

Limit Standard Hinweise
Ladejobs pro Tabelle und Tag Ladejobs, einschließlich fehlgeschlagener Ladejobs, werden auf das Limit für die Anzahl von Tabellenvorgängen pro Tag für die Zieltabelle angerechnet. Informationen zu Limits für die Anzahl von Tabellenvorgängen pro Tag für Standardtabellen und partitionierte Tabellen finden Sie unter Tabellen.
Ladejobs pro Tag 100.000 Jobs Ihr Projekt kann bis zu 100.000 Ladejobs pro Tag ausführen. Fehlgeschlagene Ladejobs werden auf dieses Limit angerechnet.
Maximale Anzahl von Spalten pro Tabelle 10.000 Spalten Eine Tabelle kann bis zu 10.000 Spalten enthalten.
Maximale Größe pro Ladejob 15 TB Die Gesamtgröße aller CSV-, JSON-, Avro-, Parquet- und ORC-Eingabedateien kann bis zu 15 TB betragen.
Maximale Anzahl von Quell-URIs in der Jobkonfiguration 10.000 URIs Eine Jobkonfiguration kann bis zu 10.000 Quell-URIs enthalten.
Maximale Anzahl von Dateien pro Ladejob 10.000.000 Dateien Ein Ladejob kann insgesamt bis zu 10 Millionen Dateien enthalten, einschließlich aller Dateien, die den Platzhalter-URIs entsprechen.
Ausführungszeitlimit für Ladejobs 6 Stunden Ein Ladejob schlägt fehl, wenn er länger als sechs Stunden ausgeführt wird.
Avro: Maximale Größe für Dateidatenblöcke 16 MB Die maximale Größe für Avro-Dateidatenblöcke beträgt 16 MB.
CSV: Maximale Zellengröße 100 MB CSV-Zellen können bis zu 100 MB groß sein.
CSV: Maximale Zeilengröße 100 MB CSV-Zeilen können bis zu 100 MB groß sein.
CSV: Maximale Dateigröße – komprimiert 4 GB Das Größenlimit für eine komprimierte CSV-Datei beträgt 4 GB.
CSV: Maximale Dateigröße – unkomprimiert 5 TB Das Größenlimit für eine unkomprimierte CSV-Datei beträgt 5 TB.
JSON: Maximale Zeilengröße 100 MB JSON-Zeilen können bis zu 100 MB groß sein.
JSON: Maximale Dateigröße – komprimiert 4 GB Das Größenlimit für eine komprimierte JSON-Datei beträgt 4 GB.
JSON: Maximale Dateigröße – unkomprimiert 5 TB Das Größenlimit für eine unkomprimierte JSON-Datei beträgt 5 TB.

Wenn Sie aufgrund häufiger Aktualisierungen die Limits für Ladejobs regelmäßig überschreiten, sollten Sie stattdessen in Betracht ziehen, Daten in BigQuery zu streamen.

Kopierjobs

Die folgenden Limits gelten für BigQuery-Jobs zum Kopieren von Tabellen, einschließlich Jobs, die eine Kopie, einen Klon oder einen Snapshot einer Standardtabelle, eines Tabellenklons oder eines Tabellen-Snapshots erstellen. Die Limits gelten für Jobs, die mit der Console, dem bq-Befehlszeilentool oder der API-Methode jobs.insert (Typ „copy“) erstellt wurden. Kopierjobs werden auf diese Limits angerechnet, unabhängig davon, ob sie erfolgreich sind.

Limit Standard Hinweise
Kopierjobs pro Zieltabelle und Tag Siehe Tabellenvorgänge pro Tag.
Kopierjobs pro Tag 100.000 Jobs Ihr Projekt kann bis zu 100.000 Kopierjobs pro Tag ausführen.
Regionenübergreifende Kopierjobs pro Zieltabelle und Tag 100 Jobs Ihr Projekt kann pro Tag bis zu 100 regionenübergreifende Kopierjobs für eine Zieltabelle ausführen.
Regionenübergreifende Kopierjobs pro Tag 2.000 Jobs Ihr Projekt kann bis zu 2.000 regionenübergreifende Kopierjobs pro Tag ausführen.

Für das Kopieren von Datasets gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl von Tabellen im Quell-Dataset 20.000 Tabellen Ein Quell-Dataset kann bis zu 20.000 Tabellen enthalten.
Maximale Anzahl von Tabellen, die pro Ausführung in ein Ziel-Dataset in derselben Region kopiert werden können 20.000 Tabellen Ihr Projekt kann 20.000 Tabellen pro Ausführung in ein Ziel-Dataset kopieren, das sich in derselben Region befindet.
Maximale Anzahl von Tabellen, die pro Ausführung in ein Ziel-Dataset in einer anderen Region kopiert werden können 1.000 Tabellen Ihr Projekt kann 1.000 Tabellen pro Ausführung in ein Ziel-Dataset kopieren, das sich in einer anderen Region befindet. Wenn Sie beispielsweise eine regionenübergreifende Kopie eines Datasets konfigurieren, das 8.000 Tabellen enthält, erstellt BigQuery Data Transfer Service automatisch acht sequenzielle Ausführungen. Bei der ersten Ausführung werden 1.000 Tabellen kopiert. 24 Stunden später kopiert die zweite Ausführung 1.000 Tabellen. Dieser Vorgang wird fortgesetzt, bis alle Tabellen im Dataset kopiert wurden, bis zum Maximum von 20.000 Tabellen pro Dataset.

Datenrichtlinienverwaltung

Für dynamische Datenmaskierung auf Spaltenebene (Vorschau) gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl von Datenrichtlinien pro Richtlinien-Tag. 1
Maximale Anzahl von dataPolicy.list-Aufrufen 400 Anfragen pro Minute pro Projekt

600 Anfragen pro Minute pro Organisation
Maximale Anzahl von dataPolicy.testIamPermissions-Aufrufen 400 Anfragen pro Minute pro Projekt

600 Anfragen pro Minute pro Organisation
Maximale Anzahl von Leseanfragen. 1.200 Anfragen pro Minute pro Projekt

1.800 Anfragen pro Minute pro Organisation
Dazu gehören Aufrufe von dataPolicy.get und dataPolicy.getIamPolicy.
Maximale Anzahl Schreibanfragen. 600 Anfragen pro Minute pro Projekt

900 Anfragen pro Minute pro Organisation

Hierzu zählen Aufrufe an:

Datasets

Für BigQuery-Datasets gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl von Datasets Unbegrenzt Ein Projekt kann beliebig viele Datasets haben.
Anzahl von Tabellen pro Dataset Unbegrenzt Wenn Sie einen API-Aufruf verwenden und ein Dataset rund 50.000 oder mehr Tabellen enthält, verlangsamt sich deren Aufzählung. In der Console können für jedes Dataset bis zu 50.000 Tabellen angezeigt werden.
Anzahl autorisierter Ressourcen in der Access Control List eines Datasets 2.500 Ressourcen Die Access Control List eines Datasets kann insgesamt bis zu 2.500 autorisierte Ressourcen enthalten, einschließlich autorisierter Ansichten, autorisierter Datasets und autorisierter Funktionen. Wenn Sie dieses Limit aufgrund einer großen Anzahl autorisierter Ansichten überschreiten, sollten Sie die Ansichten in autorisierten Datasets gruppieren.
Anzahl der Dataset-Aktualisierungsvorgänge pro Dataset pro 10 Sekunden 5 Vorgänge Ihr Projekt kann alle 10 Sekunden bis zu fünf Aktualisierungsvorgänge für Datasets durchführen. Das Dataset-Aktualisierungslimit umfasst alle Metadaten-Aktualisierungsvorgänge, die über Folgendes ausgeführt werden:
Maximale Länge einer Dataset-Beschreibung 16.384 Zeichen Für die Beschreibung eines Datasets dürfen Sie höchstens 16.384 Zeichen verwenden.

Tabellen

Alle Tabellen

Die folgenden Limits gelten für alle BigQuery-Tabellen.

Limit Standard Hinweise
Maximale Länge einer Spaltenbeschreibung 1.024 Zeichen Für die Beschreibung einer Spalte dürfen Sie höchstens 1.024 Zeichen verwenden.
Maximale Tiefe verschachtelter Datensätze 15 Ebenen Spalten vom Typ RECORD können verschachtelte RECORD-Typen enthalten, auch untergeordnete Datensätze genannt. Es sind maximal 15 Ebenen möglich. Dieses Limit gilt unabhängig davon, ob die Datensätze skalar oder arraybasiert (wiederholt) sind.

Externe Tabellen

Die folgenden Limits gelten für BigQuery-Tabellen, mit denen Daten in Cloud Storage im Format Parquet, ORC, Avro, CSV oder JSON gespeichert werden:

Limit Standard Hinweise
Maximale Anzahl von Quell-URIs pro externer Tabelle 10.000 URIs Jede externe Tabelle kann bis zu 10.000 Quell-URIs enthalten.
Maximale Anzahl von Dateien pro externer Tabelle 10.000.000 Dateien Eine externe Tabelle kann bis zu 10 Millionen Dateien enthalten, einschließlich aller Dateien, die den Platzhalter-URIs entsprechen.
Maximale Größe der gespeicherten Daten in Cloud Storage pro externer Tabelle 600 TB Eine externe Tabelle kann bis zu 600 Terabyte an Eingabedateien haben. Das Limit gilt für die Größe der in Cloud Storage gespeicherten Dateien. Diese Größe ist nicht identisch mit der Größe, die in der Preisformel für Abfragen verwendet wird. Bei extern partitionierten Tabellen tritt das Limit nach der Partitionsbereinigung in Kraft.

Partitionierte Tabellen

Für partitionierte BigQuery-Tabellen gelten die folgenden Limits.

Partitionslimits gelten für die Gesamtsumme allerLadejobs, Kopierjobs und Abfragejobs, die Daten an eine Zielpartition anfügen, eine Zielpartition überschreiben oder eine DELETE- ,INSERT-, MERGE-, TRUNCATE TABLE- oder UPDATE-DML-Anweisung verwenden, um Daten in einer Tabelle zu bearbeiten.

DML-Anweisungen werden auf die Partitionslimits angerechnet, aber nicht dadurch begrenzt. Weitere Informationen zu DML-Limits finden Sie unter Anweisungen der Datenbearbeitungssprache.

Ein einzelner Job kann sich auf mehrere Partitionen auswirken. Durch eine DML-Anweisung können z. B. Daten in mehreren Partitionen aktualisiert werden, sowohl in partitionierten Tabellen als auch in nach Aufnahmezeit partitionierten Tabellen. Auch Abfrage- und Ladejobs können in mehrere Partitionen schreiben, jedoch nur in partitionierte Tabellen.

BigQuery verwendet die Anzahl der Partitionen, die von einem Job betroffen sind, um zu ermitteln, wie viel vom Limit durch einen Job verbraucht wird. Streaming-Insert-Anweisungen werden dabei nicht berücksichtigt.

Informationen zu Strategien für das Einhalten der Limits für partitionierte Tabellen finden Sie unter Kontingentfehler beheben.

Limit Standard Hinweise
Anzahl der Partitionen pro partitionierter Tabelle 4.000 Partitionen Eine partitionierte Tabelle kann bis zu 4.000 Partitionen enthalten. Wenn Sie dieses Limit überschreiten, sollten Sie zusätzlich zur Partitionierung oder anstelle der Partitionierung Clustering verwenden.
Anzahl von Partitionen, die durch einen einzelnen Job geändert werden 4.000 Partitionen Jeder Jobvorgang (Abfrage oder Laden) kann bis zu 4.000 Partitionen betreffen. BigQuery lehnt alle Abfrage- oder Ladejobs ab, die versuchen, mehr als 4.000 Partitionen zu ändern.
Anzahl der Partitionsänderungen pro nach Aufnahmezeit partitionierter Tabelle pro Tag 5.000 Änderungen Ihr Projekt kann bis zu 5.000 Partitionsänderungen pro Tag in einer nach Aufnahmezeit partitionierten Tabelle vornehmen.
Anzahl der Partitionsänderungen pro nach Spalte partitionierter Tabelle pro Tag 30.000 Änderungen

In einem Projekt können bis zu 30.000 Partitionsänderungen pro Tag für eine nach Spalte partitionierte Tabelle vorgenommen werden.

Anzahl der Änderungen pro 10 Sekunden und Tabelle 50 Änderungen. Ihr Projekt kann alle 10 Sekunden bis zu 50 Änderungen pro partitionierter Tabelle ausführen.
Anzahl der möglichen Bereiche für die Bereichspartitionierung 10.000 Bereiche Eine nach Bereich partitionierte Tabelle kann bis zu 10.000 mögliche Bereiche haben. Dieses Limit gilt für die Partitionsspezifikation, wenn Sie die Tabelle erstellen. Nachdem Sie die Tabelle erstellt haben, gilt das Limit auch für die tatsächliche Anzahl von Partitionen.

Standardtabellen

Für BigQuery-Standardtabellen gelten die folgenden Limits:

Limit Standard Hinweise
Tabellenvorgänge pro Tag 1.500 Vorgänge

Ihr Projekt kann bis zu 1.500 Tabellenvorgänge pro Tabelle und Tag durchführen, unabhängig davon, ob durch den Vorgang Daten an die Tabelle angefügt werden oder die Tabelle gekürzt wird. Dieses Limit umfasst die Gesamtsumme aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen, eine Zieltabelle überschreiben oder eine DELETE-, INSERT-, MERGE-, TRUNCATE TABLE- oder UPDATE-DML-Anweisung verwenden, um Daten in eine Tabelle zu schreiben.

DML-Anweisungen werden auf die Partitionslimits angerechnet, aber nicht dadurch begrenzt. Weitere Informationen zu DML-Limits finden Sie unter Anweisungen der Datenbearbeitungssprache.

Maximale Aktualisierungsrate für Tabellenmetadaten pro Tabelle 5 Vorgänge pro 10 Sekunden Ihr Projekt kann bis zu fünf Tabellenaktualisierungsvorgänge pro 10 Sekunden pro Tabelle durchführen. Dieses Limit gilt für alle Aktualisierungsvorgänge für Tabellenmetadaten, die durch Folgendes ausgeführt werden: Dieses Limit umfasst auch die Gesamtzahl aller Lade-, Kopier- und Abfragejobs, die Daten an eine Zieltabelle anfügen oder ein Zieltabelle überschreiben. Dieses Limit gilt nicht für DML-Vorgänge.

Wenn Sie dieses Limit überschreiten, erhalten Sie eine Fehlermeldung wie Exceeded rate limits: too many table update operations for this table. Dieser Fehler ist nur vorübergehend. Sie können es mit einem exponentiellen Backoff noch einmal versuchen.

Um die Vorgänge zu ermitteln, die auf dieses Limit angerechnet werden, können Sie Ihre Logs prüfen.

Maximale Anzahl von Spalten pro Tabelle 10.000 Spalten Jede Tabelle, jedes Abfrageergebnis und jede Ansichtsdefinition kann bis zu 10.000 Spalten enthalten.

Tabellen-Snapshots

Für Tabellen-Snapshots von BigQuery gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl von gleichzeitigen Tabellen-Snapshot-Jobs 100 Jobs Sie können in Ihrem Projekt bis zu 100 Tabellen-Snapshot-Jobs gleichzeitig ausführen.
Maximale Anzahl von Tabellen-Snapshot-Jobs pro Tag 50.000 Jobs Ihr Projekt kann bis zu 50.000 Tabellen-Snapshot-Jobs pro Tag ausführen.
Maximale Anzahl von Jobs pro Tabellen-Snapshot und Tag 50 Jobs Ihr Projekt kann bis zu 50 Jobs pro Tag und Tabellen-Snapshot ausführen.
Maximale Anzahl von Metadatenaktualisierungen pro Tabellen-Snapshot pro 10 Sekunden 5 Aktualisierungen Die Metadaten eines Tabellen-Snapshots können bis zu fünfmal pro 10 Sekunden aktualisiert werden.

Aufrufe

Für BigQuery-Ansichten gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl verschachtelter Ansichtsebenen 16 Ebenen BigQuery unterstützt bis zu 16 Ebenen verschachtelter Ansichten. Bei mehr als 16 Ebenen wird der Fehler INVALID_INPUT zurückgegeben.
Maximale Länge einer Standard-SQL-Abfrage, die zur Definition einer Ansicht verwendet wird 256.000 Zeichen Der Text einer Standard-SQL-Abfrage, die eine Ansicht definiert, kann bis zu 256.000 Zeichen enthalten.
Maximale Anzahl von autorisierten Ansichten pro Dataset Siehe Datasets.

Sicherheit auf Zeilenebene

Die folgenden Limits gelten für BigQuery-Zugriffsrichtlinien auf Zeilenebene:

Limit Default Hinweise
Maximale Anzahl von Zeilenzugriffsrichtlinien pro Tabelle 100 Richtlinien Eine Tabelle kann bis zu 100 Zeilenzugriffsrichtlinien enthalten.
Maximale Anzahl der Zeilenzugriffsrichtlinien pro Abfrage 100 Richtlinien Eine Abfrage kann auf bis zu 100 Zeilenzugriffsrichtlinien zugreifen.
Maximale Anzahl von CREATE-/DROP-DDL-Anweisungen pro Richtlinie pro 10 Sekunden 5 Anweisungen Ihr Projekt kann alle 10 Sekunden bis zu fünf CREATE- oder DROP-Anweisungen pro Zeilenzugriffsrichtlinien-Ressource erstellen.
DROP ALL ROW ACCESS POLICIES-Anweisungen pro Tabelle pro 10 Sekunden 5 Anweisungen Im Projekt können bis zu fünf DROP ALL ROW ACCESS POLICIES-Anweisungen pro Tabelle alle 10 Sekunden erstellt werden.
Maximale Anzahl von rowAccessPolicies.list-Aufrufen Siehe Limits für alle BigQuery APIs.
Maximale Anzahl von rowAccessPolicies.getIamPolicy-Aufrufen Siehe IAM-API-Kontingente.

Anweisungen der Datenbearbeitungssprache

Für Anweisungen in der Datenbearbeitungssprache (Data Manipulation Language, DML) von BigQuery gelten die folgenden Limits:

Limit Standard Hinweise
DML-Anweisungen pro Tag Unbegrenzt DML-Anweisungen werden auf die Anzahl der Tabellenvorgänge pro Tag oder die Anzahl der Vorgänge pro Tag für partitionierte Tabellen angerechnet. Die Anzahl der DML-Anweisungen, die Ihr Projekt pro Tag ausführen kann, ist jedoch nicht begrenzt. Nachdem das Tageslimit für Tabellenvorgänge (oder Vorgänge für partitionierte Tabellen) aufgebraucht ist, werden Fehler für Nicht-DML-Tabellenvorgänge angezeigt. Sie können jedoch weiterhin DML-Anweisungen ausführen, ohne Fehler zu erhalten.

Angenommen, Sie haben eine nach Aufnahmezeit partitionierte Tabelle mit dem Namen mytable. Wenn Sie 3.000 Kopierjobs ausführen, die Daten an mytable$20210720 anhängen, und 2.000 Abfragejobs, die INSERT verwenden, um Daten an mytable$20210720anzuhängen, erreichen Sie das tägliche Limit für Partitionsänderungen. Sobald das Limit erreicht ist, schlagen alle weiteren Kopierjobs fehl. Abfragejobs, die auf DML basieren, werden jedoch weiterhin erfolgreich ausgeführt. Für DML-Anweisungen gelten jedoch eigene Einschränkungen.
Gleichzeitige mutierende DML-Anweisungen pro Tabelle 2 Anweisungen BigQuery führt für jede Tabelle bis zu zwei mutierende DML-Anweisungen (UPDATE, DELETE und MERGE) gleichzeitig aus. Zusätzliche mutierende DML-Anweisungen für eine Tabelle werden in die Warteschlange gestellt.
Mutierende DML-Anweisungen pro Tabelle in der Warteschlange 20 Anweisungen Eine Tabelle kann bis zu 20 mutierende DML-Anweisungen in der Warteschlange haben, die noch ausgeführt werden müssen. Wenn Sie zusätzliche mutierende DML-Anweisungen für die Tabelle senden, schlagen diese Anweisungen fehl.
Maximale Zeit für eine DML-Anweisung in der Warteschlange 6 Stunden Eine interaktive Prioritäts-DML-Anweisung kann bis zu sechs Stunden in der Warteschlange warten. Wenn die Anweisung nach sechs Stunden nicht ausgeführt wurde, schlägt sie fehl.

Weitere Informationen zu mutierenden DML-Anweisungen finden Sie unter INSERT-DML-Gleichzeitigkeit und UPDATE, DELETE, MERGE-DML-Gleichzeitigkeit.

Streaming-Insert-Anweisungen

Die folgenden Kontingente und Limits gelten beim Streamen von Daten in BigQuery mithilfe der Legacy-Streaming API. Informationen zu Strategien, um innerhalb dieser Limits zu bleiben, finden Sie unter Kontingentfehler beheben. Wenn Sie diese Kontingente überschreiten, erhalten Sie quotaExceeded-Fehler.

Limit Standard Hinweise
Maximale Byte pro Sekunde und Projekt in den Multiregionen us und eu 1 GB pro Sekunde

Ihr Projekt kann bis zu 1 GB pro Sekunde streamen. Dieses Kontingent ist innerhalb einer Multiregion kumulativ. Dies bedeutet, dass die Summe der Byte pro Sekunde, die in alle Tabellen für ein bestimmtes Projekt innerhalb einer Multiregion gestreamt werden, auf 1 GB begrenzt ist.

Das Überschreiten dieses Limits führt zu quotaExceeded-Fehlern.

Bei Bedarf können Sie eine Kontingenterhöhung über Cloud Customer Care anfordern. Fordern Sie eine Erhöhung so früh wie möglich an, mindestens zwei Wochen, bevor Sie sie benötigen. Kontingenterhöhungen benötigen Zeit, bis sie verfügbar sind, insbesondere im Fall einer erheblichen Erhöhung.

Maximale Byte pro Sekunde und Projekt an allen anderen Standorten 300 MB pro Sekunde

Ihr Projekt kann an allen Standorten mit Ausnahme der Multiregionen us und eu bis zu 300 MB pro Sekunde streamen. Dieses Kontingent ist innerhalb einer Multiregion kumulativ. Das bedeutet, dass die Summe der Byte pro Sekunde, die in alle Tabellen für ein bestimmtes Projekt innerhalb einer Region gestreamt werden, auf 300 MB begrenzt ist.

Das Überschreiten dieses Limits führt zu quotaExceeded-Fehlern.

Bei Bedarf können Sie eine Kontingenterhöhung über Cloud Customer Care anfordern. Fordern Sie eine Erhöhung so früh wie möglich an, mindestens zwei Wochen, bevor Sie sie benötigen. Kontingenterhöhungen benötigen Zeit, bis sie verfügbar sind, insbesondere im Fall einer erheblichen Erhöhung.

Maximale Zeilengröße 10 MB Das Überschreiten dieses Wertes verursacht invalid-Fehler.
Größenlimit für HTTP-Anfragen 10 MB

Das Überschreiten dieses Wertes verursacht invalid-Fehler.

Die Anfrage wird intern von HTTP-JSON in eine interne Datenstruktur übersetzt. Für diese gilt eine eigenes Größenlimit. Die Größe der resultierenden internen Datenstruktur lässt sich schwer vorhersagen. Wenn Sie jedoch Ihre HTTP-Anfragen bei maximal 10 MB halten, ist das Risiko gering, dass das interne Limit erreicht wird.

Maximale Anzahl von Zeilen pro Anfrage 50.000 Zeilen Es werden maximal 500 Zeilen empfohlen. Durch Batchverarbeitung können Leistung und Durchsatz bis zu einem gewissen Punkt gesteigert werden, allerdings auf Kosten der Latenz pro Anfrage. Bei zu wenigen Zeilen pro Anfrage kann der Verwaltungsaufwand für die jeweilige Anfrage die Datenaufnahme ineffizient machen. Bei zu vielen Zeilen pro Anfrage sinkt eventuell der Durchsatz. Experimentieren Sie mit repräsentativen Daten (Schema und Datengrößen), um die ideale Batchgröße für Ihre Daten zu ermitteln.
Feldlänge von insertId 128 Zeichen Das Überschreiten dieses Wertes verursacht invalid-Fehler.

Weitere Informationen zu Streamingkontingenten finden Sie unter Kontingenterhöhung anfordern.

Tabellenfunktionen

Die folgenden Limits gelten für Tabellenfunktionen von BigQuery:

Limit Standard Hinweise
Maximale Länge eines Tabellenfunktionsnamens 256 Zeichen Der Name einer Tabellenfunktion kann bis zu 256 Zeichen lang sein.
Maximale Länge eines Argumentnamens 128 Zeichen Der Name eines Tabellenfunktionsarguments kann bis zu 128 Zeichen lang sein.
Maximale Anzahl von Argumenten 256 Argumente Eine Tabellenfunktion kann bis zu 256 Argumente haben.
Maximale Tiefe der Verweiskette einer Tabellenfunktion 16 Verweise Die Verweiskette einer Tabellenfunktion kann bis zu 16 Verweise haben.
Maximale Tiefe eines Arguments oder einer Ausgabe vom Typ STRUCT 15 Ebenen Das Argument STRUCT für eine Tabellenfunktion kann bis zu 15 Ebenen tief sein. Ähnlich kann ein STRUCT-Datensatz in der Ausgabe einer Tabellenfunktion bis zu 15 Ebenen umfassen.
Maximale Anzahl von Feldern in einem Argument oder einer Rückgabetabelle vom Typ STRUCT pro Tabellenfunktion 1.024 Felder Ein STRUCT-Argument für eine Tabellenfunktion kann bis zu 1.024 Felder enthalten. Ähnlich kann ein STRUCT-Datensatz in der Ausgabe einer Tabellenfunktion bis zu 1.024 Felder enthalten.
Maximale Anzahl von Spalten in der Rückgabetabelle 1.024 Spalten Eine von einer Tabellenfunktion zurückgegebene Tabelle kann bis zu 1.024 Spalten enthalten.
Maximale Länge der Namen von Rückgabetabellenspalten 128 Zeichen Spaltennamen in zurückgegebenen Tabellen können bis zu 128 Zeichen lang sein.
Maximale Anzahl von Aktualisierungen pro Tabellenfunktion pro 10 Sekunden 5 Aktualisierungen Ihr Projekt kann eine Tabellenfunktion bis zu fünfmal alle 10 Sekunden aktualisieren.

UDFs

Die folgenden Limits gelten sowohl für temporäre als auch für persistente benutzerdefinierte Funktionen (User-Defined Functions, UDFs) in BigQuery-SQL-Abfragen.

Limit Standard Hinweise
Maximale Ausgabe pro Zeile 5 MB Die maximale Datenmenge, die von Ihrer JavaScript-UDF bei der Verarbeitung einer einzelnen Zeile ausgegeben werden kann, beträgt etwa 5 MB.
Maximale Anzahl gleichzeitiger Legacy-SQL-Abfragen mit JavaScript-UDFs 6 Abfragen Ihr Projekt kann bis zu sechs gleichzeitige Legacy-SQL-Abfragen enthalten, die UDFs in JavaScript enthalten. Dieses Limit umfasst sowohl interaktive als auch Batchabfragen. Interaktive Abfragen, die UDFs enthalten, werden auch auf die Ratenbegrenzung für gleichzeitige interaktive Abfragen angerechnet. Dieses Limit gilt nicht für Standard-SQL-Abfragen.
Maximale Anzahl von JavaScript-UDF-Ressourcen pro Abfrage 50 Ressourcen Ein Abfragejob kann bis zu 50 JavaScript-UDF-Ressourcen wie Inline-Code-Blobs oder externe Dateien enthalten.
Maximale Größe des Inline-Code-Blobs 32 KB Ein Inline-Code-Blob in einer UDF kann bis zu 32 KB groß sein.
Maximale Größe einzelner externer Coderessourcen 1 MB Die maximale Größe einer JavaScript-Coderessource beträgt 1 MB.

Für persistente UDFs gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Länge eines UDF-Namens 256 Zeichen Ein UDF-Name kann bis zu 256 Zeichen lang sein.
Maximale Anzahl von Argumenten 256 Argumente Eine UDF kann bis zu 256 Argumente enthalten.
Maximale Länge eines Argumentnamens 128 Zeichen Ein UDF-Argumentname kann bis zu 128 Zeichen lang sein.
Maximale Tiefe einer UDF-Verweiskette 16 Verweise Eine UDF-Verweiskette kann bis zu 16 Verweise haben.
Maximale Tiefe eines Arguments oder einer Ausgabe vom Typ STRUCT 15 Ebenen Ein UDF-Argument oder eine UDF-Ausgabe vom Typ STRUCT kann bis zu 15 Ebenen tief sein.
Maximale Anzahl von Feldern in Argumenten oder Ausgaben vom Typ STRUCT pro UDF 1.024 Felder UDFs können bis zu 1.024 Felder in Argumenten oder Ausgaben vom Typ STRUCT haben.
Maximale Anzahl von JavaScript-Bibliotheken in einer CREATE FUNCTION-Anweisung 50 Bibliotheken Eine CREATE FUNCTION-Anweisung kann bis zu 50 JavaScript-Bibliotheken enthalten.
Maximale Länge von enthaltenen JavaScript-Bibliothekspfaden 5.000 Zeichen Der Pfad für eine in einer UDF enthaltene JavaScript-Bibliothek kann bis zu 5.000 Zeichen lang sein.
Maximale Aktualisierungsrate pro UDF pro 10 Sekunden 5 Aktualisierungen Ihr Projekt kann eine UDF bis zu fünfmal pro 10 Sekunden aktualisieren.
Maximale Anzahl autorisierter UDFs pro Dataset Siehe Datasets.

Remote-Funktionen

Für Remote-Funktionen in BigQuery gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Anzahl gleichzeitiger Abfragen, die Remotefunktionen enthalten 10 Abfragen Sie können bis zu zehn Abfragen gleichzeitig mit Remotefunktionen pro Projekt ausführen.
Größenlimit für HTTP-Antworten (Cloud Functions, 1. Generation) 10 MB Der HTTP-Antworttextkörper von Ihrer Cloud Functions-Funktion der 1. Generation ist bis zu 10 MB groß. Das Überschreiten dieses Wertes führt zu Abfragefehlern.
Größenlimit für HTTP-Antworten (Cloud Functions der 2. Generation oder Cloud Run) 15 MB Der HTTP-Antworttext von Ihrer Cloud Functions-Funktion der 2. Generation oder Cloud Run hat eine Größe von bis zu 15 MB. Das Überschreiten dieses Wertes führt zu Abfragefehlern.
Maximales HTTP-Aufrufzeitlimit (Cloud Functions der 1. Generation) 9 Minuten Sie können für einen einzelnen HTTP-Aufruf ein eigenes Zeitlimit für Cloud Functions-Funktion der 1. Generation festlegen. Die maximale Zeit beträgt jedoch 9 Minuten. Das Überschreiten des für Ihre Cloud Functions-Funktion der 1. Generation festgelegten Zeitlimits kann nach einer begrenzten Anzahl von Wiederholungsversuchen zu HTTP-Aufruffehlern und Abfragefehlern führen.
Zeitlimit für HTTP-Aufruf (Cloud Functions der 2. Generation oder Cloud Run) 20 Minuten Das Zeitlimit für einen einzelnen HTTP-Aufruf an Ihre Cloud Functions-Funktion der 2. Generation oder Cloud Run. Das Überschreiten dieses Wertes kann nach einer begrenzten Anzahl von Wiederholungsversuchen zu HTTP-Aufruffehlern und Abfragefehlern führen.

Abfragen mit mehreren Anweisungen

Die folgenden Limits gelten für Abfragen mit mehreren Anweisungen in BigQuery.

Limit Standard Hinweise
Kumulatives Zeitlimit 24 Stunden Das kumulative Zeitlimit für eine Abfrage mit mehreren Anweisungen beträgt 24 Stunden.
Zeitlimit für Kontoauszüge 6 Stunden Das Zeitlimit für eine einzelne Anweisung innerhalb einer Abfrage mit mehreren Anweisungen beträgt 6 Stunden.

BigQuery API

In diesem Abschnitt werden die Kontingente und Limits für alle BigQuery API-Anfragen sowie die Kontingente und Limits für bestimmte Arten von API-Anfragen beschrieben.

Alle BigQuery APIs

Das folgende Kontingent gilt für alle BigQuery API-Anfragen:

Kontingent Standard Hinweise
Anfragen pro Tag Unbegrenzt Ihr Projekt kann eine unbegrenzte Anzahl von BigQuery API-Anfragen pro Tag stellen.
Kontingent in der Console ansehen

Die folgenden Limits gelten für alle BigQuery API-Anfragen:

Limit Standard Hinweise
Maximale Anzahl API-Anfragen pro Sekunde, Nutzer und Methode 100 Anfragen Ein Nutzer kann bis zu 100 API-Anfragen pro Sekunde an eine API-Methode senden. Wenn ein Nutzer mehr als 100 Anfragen pro Sekunde an eine Methode sendet, kann eine Drosselung auftreten. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.
Maximale Anzahl gleichzeitiger API-Anfragen pro Nutzer 300 Anfragen Wenn ein Nutzer mehr als 300 gleichzeitige Anfragen stellt, kann eine Drosselung auftreten. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.
Maximale Anfrageheader-Größe 16 KiB Eine BigQuery API-Anfrage kann bis zu 16 KiB umfassen, einschließlich der Anfrage-URL und aller Header. Dieses Limit gilt nicht für den Anfragetext, z. B. in einer POST-Anfrage.

jobs.get-Anfragen

Das folgende Limit gilt für jobs.get API-Anfragen:

Limit Standard Hinweise
Maximale Anzahl von jobs.get-Anfragen pro Sekunde 1.000 Anfragen Ihr Projekt kann bis zu 1.000 jobs.get-Anfragen pro Sekunde senden.

jobs.query-Anfragen

Das folgende Limit gilt für jobs.query API-Anfragen:

Limit Standard Hinweise
Maximale jobs.query-Antwortgröße 20 MB Standardmäßig ist keine Obergrenze für die Anzahl der von jobs.query zurückzugebenden Datenzeilen pro Ergebnisseite festgelegt. Es gilt jedoch das Limit von 20 MB für die Antwortgröße. Sie können die Anzahl der zurückzugebenden Zeilen mithilfe des Parameters maxResults ändern.

projects.list-Anfragen

Das folgende Limit gilt für projects.list API-Anfragen:

Limit Standard Hinweise
Maximale Anzahl von projects.list-Anfragen pro Sekunde 2 Anfragen Ihr Projekt kann bis zu zwei projects.list-Anfragen pro Sekunde senden.

tabledata.list-Anfragen

Das folgende Kontingent gilt für tabledata.list-Anfragen. Für andere APIs wie jobs.getQueryResults und für das Abrufen von Ergebnissen aus jobs.query und jobs.insert kann dieses Kontingent ebenfalls genutzt werden.

Kontingent Standard Hinweise
Byte pro Minute beim Auflisten von Tabellendaten 3,6 GB Ihr Projekt kann maximal 3,6 GB an Tabellenzeilendaten pro Minute zurückgeben. Dieses Kontingent gilt für das Projekt, das die gelesene Tabelle enthält.
Kontingent in der Console ansehen

Die folgenden Limits gelten für tabledata.list-Anfragen.

Limit Standard Hinweise
Maximale Anzahl von tabledata.list-Anfragen pro Sekunde 1.000 Anfragen Ihr Projekt kann bis zu 1.000 tabledata.list-Anfragen pro Sekunde senden.
Maximale Anzahl der von tabledata.list-Anfragen pro Sekunde zurückgegebenen Zeilen 150.000 Zeilen Ihr Projekt kann mithilfe von tabledata.list-Anfragen bis zu 150.000 Zeilen pro Sekunde zurückgeben. Dieses Limit gilt für das Projekt, das die gelesene Tabelle enthält.
Maximale Anzahl von Zeilen pro tabledata.list-Antwort 100.000 Zeilen Mit einem tabledata.list-Aufruf können bis zu 100.000 Tabellenzeilen zurückgegeben werden. Weitere Informationen finden Sie unter Mit der API in Ergebnissen suchen.

tables.insert-Anfragen

Mit der Methode tables.insert wird eine neue, leere Tabelle in einem Dataset erstellt. Das folgende Limit gilt für tables.insert-Anfragen. Dieses Limit umfasst SQL-Anweisungen, die Tabellen erstellen, z. B. CREATE TABLE, und Abfragen, bei denen Ergebnisse in Zieltabellen geschrieben werden.

Limit Standard Hinweise
Maximale Anzahl von tables.insert-Anfragen pro Sekunde 10 Anfragen Ihr Projekt kann bis zu 10 tables.insert-Anfragen pro Sekunde senden.

BigQuery Connection API

Die folgenden Kontingente gelten für BigQuery Connection API-Aufrufe:

Kontingent Standard Hinweise
Leseanfragen pro Minute 1.000 Anfragen Ihr Projekt kann bis zu 1.000 Anfragen pro Minute an BigQuery Connection API-Methoden senden, die Verbindungsdaten lesen.
Kontingent in der Console ansehen
Schreibanfragen pro Minute 100 Anfragen pro Minute Ihr Projekt kann bis zu 100 Anfragen pro Minute an BigQuery Connection API-Methoden senden, die Verbindungen erstellen oder aktualisieren.
Kontingent in der Console ansehen

BigQuery Migration API

Die folgenden Limits gelten für die BigQuery Migration API (Vorschau):

Limit Standard Hinweise
Individuelle Dateigröße für die Batch-SQL-Übersetzung 10 MB Jede einzelne Quell- und Metadatendatei kann bis zu 10 MB groß sein. Dieses Limit gilt nicht für die Metadaten-ZIP-Datei, die vom dwh-migration-dumper-Befehlszeilentool erstellt wurde.
Gesamtgröße der Quelldateien für Batch-SQL-Übersetzung 1 GB Die Gesamtgröße aller in Cloud Storage hochgeladenen Eingabedateien kann bis zu 1 GB betragen. Dazu gehören alle Quelldateien und alle Metadatendateien, wenn Sie diese hinzufügen möchten.
Größe des Eingabestrings für die interaktive SQL-Übersetzung < 1 MB Der String, den Sie für die interaktive SQL-Übersetzung eingeben, muss kleiner als 1 MB sein.

Die folgenden Kontingente gelten für die BigQuery Migration API (Vorschau):

Kontingent Standard Hinweise

EDWMigration Service-List-Anfragen pro Minute

EDWMigration Service-List-Anfragen pro Minute und Nutzer

25.000 Anfragen

5.000 Anfragen

Ihr Projekt kann bis zu 25.000 Migration API-List-Anfragen pro Minute senden.

Jeder Nutzer kann bis zu 5.000 Migration API-List-Anfragen pro Minute senden

Kontingente in der Console ansehen

EDWMigration Service-Get-Anfragen pro Minute

EDWMigration Service-Get-Anfragen pro Minute und Nutzer

50.000 Anfragen

5.000 Anfragen

Ihr Projekt kann bis zu 50.000 Get Migration API-Get-Anfragen pro Minute senden.

Jeder Nutzer kann bis zu 5.000 Migration API-Get-Anfragen pro Minute senden.

Kontingente in der Console ansehen

Weitere EDWMigration Service-Anfragen pro Minute

Weitere EDWMigration Service-Anfragen pro Minute und Nutzer

50 Anfragen

10 Anfragen

Ihr Projekt kann bis zu 50 weitere Migration API-Anfragen pro Minute senden.

Jeder Nutzer kann bis zu 10 weitere Migration API-Anfragen pro Minute senden.

Kontingente in der Console ansehen

Interaktive SQL-Übersetzungsanfragen pro Minute

Interaktive SQL-Übersetzungsanfragen pro Minute und Nutzer

500 Anfragen

100 Anfragen

Ihr Projekt kann bis zu 500 SQL-Übersetzungs-Dienstanfragen pro Minute senden.

Jeder Nutzer kann bis zu 100 weitere SQL-Übersetzungs-Dienstanfragen pro Minute senden.

Kontingente in der Console ansehen

BigQuery Reservation API

Die folgenden Kontingente gelten für die BigQuery Reservation API:

Kontingent Standard Hinweise
Anfragen pro Minuten und Region 100 Anfragen Ihr Projekt kann insgesamt bis zu 100 Aufrufe an die BigQuery Reservation API-Methoden pro Minute und Region senden.
Kontingente in der Console ansehen
Anzahl von SearchAllAssignments-Aufrufen pro Minute und Region 100 Anfragen Ihr Projekt kann bis zu 100 Aufrufe an die Methode SearchAllAssignments pro Minute und Region senden.
Kontingente in der Console ansehen
Anfragen für SearchAllAssignments pro Minute, Region und Nutzer 10 Anfragen Jeder Nutzer kann bis zu 10 Aufrufe an die Methode SearchAllAssignments pro Minute und Region senden.
Kontingente in der Console ansehen
Suchen Sie in den Suchergebnissen der Google Cloud Console nach pro Nutzer )
Gesamtzahl der Slots für die EU-Region 2.000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der EU-Multiregion mit der Google Cloud Console erwerben können.
Kontingente in der Console ansehen
Gesamtzahl der Slots für die US-Region 4.000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der US-Multiregion mit der Google Cloud Console erwerben können.
Kontingente in der Console ansehen
Gesamtzahl der Slots für die folgenden Regionen: asia-northeast1, asia-northeast3, australia-southeast1, europe-west2 und northamerica-northeast1 1000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in den einzelnen Regionen mit der Google Cloud Console erwerben können.
Kontingente in der Console ansehen
Gesamtzahl der Slots für Omni-Regionen (aws-us-east-1 und azure-eastus2) 100 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der Google Cloud Console in den Omni-Regionen erwerben können.
Kontingente in der Console ansehen
Gesamtzahl der Slots für alle anderen Regionen 500 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der anderen Region über die Google Cloud Console erwerben können.
Kontingente in der Console ansehen

IAM API

Die folgenden Kontingente gelten, wenn Sie die Funktion Identity and Access Management in BigQuery verwenden, um IAM-Richtlinien abzurufen und festzulegen sowie IAM-Berechtigungen zu testen.

Kontingent Standard Hinweise
IamPolicy-Anfragen pro Minute 3.000 Anfragen Ihr Projekt kann bis zu 3.000 IAM-Anfragen pro Sekunde senden.
Kontingent in der Console ansehen
IamPolicy-Anfragen pro Nutzer 1.500 Anfragen Jeder Nutzer kann bis zu 1.500 IAM-Anfragen pro Minute und Projekt stellen.
Kontingent in der Console ansehen

Storage Read API

Für BigQuery Storage Read API-Anfragen gelten die folgenden Kontingente:

Kontingent Standard Hinweise
Leseanfragen auf Datenebene pro Minute und Nutzer 25.000 Anfragen Jeder Nutzer kann bis zu 25.000 ReadRows-Aufrufe pro Minute und Projekt ausführen.
Kontingent in der Console ansehen
Leseanfragen auf Steuerungsebene pro Minute und Nutzer 5.000 Anfragen Jeder Nutzer kann bis zu 5.000 Storage Read API-Metadatenvorgangsaufrufe pro Minute pro Projekt ausführen. Die Metadatenaufrufe enthalten die Methoden CreateReadSession und SplitReadStream.
Kontingent in der Console ansehen

Für BigQuery Storage Read API-Anfragen gelten die folgenden Limits:

Limit Standard Hinweise
Maximale Zeilen-/Filterlänge 1 MB Wenn Sie den CreateReadSession-Aufruf der Storage Read API verwenden, gilt eine maximale Länge von 1 MB pro Zeile oder Filter.
Maximale Anzahl gleichzeitiger Verbindungen 2.000 in Multiregionen; 400 in Regionen Sie können maximal 2.000 gleichzeitige ReadRows-Verbindungen pro Projekt in den Mehrfachregionen us und eu und 400 gleichzeitige ReadRows-Verbindungen in anderen Regionen öffnen. In einigen Fällen ist die Anzahl der gleichzeitigen Verbindungen auf dieses Limit beschränkt.

Storage Write API

Die folgenden Kontingente gelten für Storage Write API-Anfragen:

Kontingent Standard Hinweise
Gleichzeitige Verbindungen 10.000 in Multiregionen; 1.000 in Regionen In Ihrem Projekt können 10.000 gleichzeitige Verbindungen in den Multiregionen us und eu sowie 1.000 Verbindungen in anderen Regionen vorhanden sein.
Kontingent in der Console ansehen
Ausstehende Stream-Byte 10 TB in Mehrfachregionen; 1 TB in Regionen Für jeden ausgelösten Commit können Sie in den Multiregionen us und eu für bis zu 10 TB und in anderen Regionen für 100 GB einen Commit durchführen.
Kontingent in der Console ansehen
Durchsatz 3 GB pro Sekunde Durchsatz in Multiregionen; 300 MB pro Sekunde in Regionen Sie können bis zu 3 GB/s in den Multiregionen us und eu und 300 Mbit/s in anderen Regionen pro Projekt streamen.
Kontingent in der Console ansehen
CreateWriteStream-Anfragen 30.000 Streams alle 4 Stunden pro Projekt Sie können CreateWriteStream bis zu 30.000-mal pro 4 Stunden pro Projekt aufrufen. Sie können den Standardstream verwenden, wenn Sie nicht genau eine Semantik benötigen.
Kontingent in der Console ansehen

Die folgenden Limits gelten für Storage Write API-Anfragen:

Limit Standard Hinweise
Batch-Commits 10.000 Streams pro Tabelle Sie können pro BatchCommitWriteStream-Aufruf bis zu 10.000 Streams ausführen.
Größe der Anfrage 10 MB Die maximale Größe der Anfrage beträgt 10 MB.

BigQuery BI Engine

Für BigQuery BI Engine gelten die folgenden Limits.

Limit Standard Hinweise
Maximale Reservierungsgröße pro Projekt und Standort (SQL-Schnittstelle) 250 GB Gilt für die Verwendung von BI Engine mit anderen BI-Tools (Business Intelligence) als Data Studio.

Sie können eine Erhöhung der maximalen Reservierungskapazität für Ihre Projekte anfordern.
Maximale Reservierungsgröße pro Projekt und Standort (Data Studio) 100 GB Gilt für die Verwendung von BI Engine mit Data Studio. Dieses Limit betrifft nicht die Größe der abgefragten Tabellen, da BI Engine nur die Spalten in den Arbeitsspeicher lädt, die in einer Abfrage verwendet werden, nicht jedoch die gesamte Tabelle.
Maximale Datenmodellgröße pro Tabelle (Data Studio) 10 GB Gilt für die Verwendung von BI Engine mit Data Studio. Wenn Sie eine 100 GB große Reservierung pro Projekt und Standort haben, beschränkt BI Engine die Reservierung pro Tabelle auf 10 GB. Der Rest der verfügbaren Reservierung wird für andere Tabellen im Projekt verwendet.
Maximale Partitionen pro Tabelle (Data Studio) 500 Partitionen BI Engine for Data Studio unterstützt maximal 500 Partitionen pro Tabelle.
Maximale Zeilen pro Abfrage (Data Studio) 150 Millionen BI Engine für Data Studio unterstützt je nach Komplexität der Abfrage bis zu 150 Millionen Zeilen abgefragter Daten.

Abfragelimits

Wenn Sie eine Abfrage ausführen, deren Ergebnisse Ihre BI Engine-Kapazität überschreiten, sorgt die automatische Anpassungsfunktion von BI Engine dafür, dass die Abfrage in BigQuery-Slots ausgeführt wird. In diesem Fall erfolgt die Abrechnung auf Basis der Preise für On-Demand-Abfragen, die für den Abfragejob gelten. Wenn die Abfrage in Slots ausgeführt wird, gelten alle Kontingente und Limits für Abfragejobs in BigQuery.

Größe der Reservierung erhöhen

Wenn Sie eine zusätzliche Speicherreservierung über die Standardgröße von 250 GB hinaus benötigen, können Sie eine Erhöhung anfordern. Reservierungserhöhungen werden von Fall zu Fall geprüft und sind nur in einigen Regionen verfügbar.

Analytics Hub

Die folgenden Limits gelten für Analytics Hub:

Limit Standard Hinweise
Maximale Anzahl an Datenpools pro Projekt 500 Sie können in einem Projekt bis zu 500 Datenaustausche erstellen.
Maximale Anzahl an Einträgen pro Datenaustausch 1.000 Sie können bis zu 1.000 Einträge in einer Datenaustauschplattform erstellen.
Maximale Anzahl verknüpfter Datasets pro freigegebenem Dataset 1.000 Alle kombinierten Analytics Hub-Abonnenten können maximal 1.000 verknüpfte Datasets pro freigegebenem Dataset haben.