Kontingente und Limits

In den folgenden Listen sind die Ratenbegrenzungen und Kontingentlimits von BigQuery aufgeführt.

BigQuery begrenzt die maximale Anzahl eingehender Anfragen und erzwingt entsprechende Kontingente auf Projektbasis. Die einzelnen Richtlinien variieren je nach Ressourcenverfügbarkeit, Nutzerprofil, Dienstnutzungsverlauf sowie weiteren Faktoren und können ohne Vorankündigung geändert werden.

Kontingenterhöhung anfordern

  • Einige BigQuery-Kontingente werden in der Google Cloud Console angezeigt. Für diese Kontingente können Sie über die Cloud Console eine Kontingenterhöhung anfragen. Für eine detailierte Anleitung durch diesen Prozess öffnen Sie in der Google Cloud Console das Tutorial Informationen zur Anforderung einer Kontingenterhöhung:

    Anleitung

  • Wenn Sie eine Erhöhung von Kontingenten beantragen möchten, die nicht in der Google Cloud Console angezeigt werden, wenden Sie sich an Cloud Customer Care.

  • Einige Kontingente und Limits können nicht erhöht werden. Zum Beispiel Kontingente und Limits, die Systemsicherheiten bieten.

Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Abfragejobs

Die folgenden Limits gelten für Abfragejobs, die durch die Ausführung interaktiver Abfragen automatisch erstellt werden, und für Jobs, die programmatisch durch Aufruf der Methoden jobs.query und jobs.insert (Typ „query“) gesendet werden.

  • Gleichzeitige Ratenbegrenzung für interaktive Abfragen: 100 gleichzeitige Abfragen pro Projekt

    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. Probeabfragen werden nicht auf dieses Limit angerechnet. Sie können eine Probeabfrage mit dem Flag --dry_run angeben.

    Informationen zu Strategien, um innerhalb dieses Limits zu bleiben, finden Sie unter Fehlerbehebung bei Quotenfehlern. Wenn Sie das Limit erhöhen möchten, wenden Sie sich an Customer Care oder den Vertrieb.

  • Ratenbegrenzung für gleichzeitige interaktive Abfragen von externen Datenquellen in Cloud Bigtable: 4 gleichzeitige Abfragen

    Sie können maximal vier Abfragen gleichzeitig für eine externe Bigtable-Datenquelle senden.

  • Ratenlimit für gleichzeitige Legacy-SQL-Abfragen, die benutzerdefinierte Funktionen (User-Defined Functions, UDFs) enthalten: 6 gleichzeitige Abfragen

    Das Ratenlimit für gleichzeitige Legacy-SQL-Abfragen, die UDFs enthalten, umfasst sowohl interaktive Abfragen 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.

  • Regionenübergreifende föderierte Abfragen: 1 TB pro Projekt und Tag

    Wenn sich der BigQuery-Standort zur Abfrageverarbeitung und der Cloud SQL-Instanzstandort unterscheiden, ist dies eine regionenübergreifende Abfrage. Sie können pro Projekt und Tag regionenübergreifende Abfragen in einem Umfang von bis zu 1 TB ausführen. Siehe Föderierte Cloud SQL-Abfragen.

  • Tageslimit für die Abfragegröße: standardmäßig unbegrenzt

    Sie können benutzerdefinierte Kontingente festlegen, um die Datenmenge zu begrenzen, die einzelne Nutzer abfragen können.

  • Tageslimit für die Zieltabellenaktualisierung: 1.500 Aktualisierungen pro Tabelle und Tag

    Für Zieltabellen in Abfragejobs gilt ein Limit von 1.500 Aktualisierungen pro Tabelle und Tag. Zu den Aktualisierungen der Zieltabelle gehören Anhänge- und Überschreibungsvorgänge, die von Abfragen ausgeführt werden, die Sie mithilfe der Cloud Console, des bq-Befehlszeilentools oder des Aufrufs der API-Methoden jobs.query und jobs.insert (Typ "query") ausführen.

  • Zeitlimit für die Ausführung einer Abfrage/eines Skripts: 6 Stunden

    Dieses Limit kann nicht erhöht werden. In manchen Fällen können Abfragen wiederholt werden. Eine wiederholte Abfrage kann bis zu sechs Stunden zusätzlich laufen. Die Wiederholung ist maximal dreimal möglich. Dies kann zu einer Gesamtlaufzeit von mehr als sechs Stunden führen.

  • Maximale Anzahl von Tabellen, auf die sich eine Abfrage bezieht: 1.000

  • Maximale Länge ungelöster Legacy-SQL-Abfragen: 256 KB

  • Maximale Länge ungelöster Standard-SQL-Abfragen: 1 MB

  • 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 an Standard-SQL-Abfrageparametern: 10.000

  • Maximale Größe der Antwort: 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

    Das Limit für die maximale Zeilengröße ist eine ungefähre Angabe, weil es von der internen Darstellung der Zeilendaten abhängt. 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

  • Maximale Anzahl von Slots für gleichzeitige Abfragen pro Projekt zu On-Demand-Preisen: 2.000

    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 BigQuery-Monitoring mit Cloud Monitoring.

    Informationen zu Limits, die für benutzerdefinierte Funktionen in SQL-Abfragen gelten, finden Sie unter UDF-Limits.

  • Geplante Abfragen

    Obwohl geplante Abfragen Funktionen von BigQuery Data Transfer Service verwenden, sind sie keine Übertragungen und unterliegen nicht dem Kontingent für Ladejobs. Geplante Abfragen unterliegen denselben Kontingenten und Limits für BigQuery wie manuelle Abfragen.

Ladejobs

Die Limits gelten für Jobs, die automatisch durch das Laden von Daten mithilfe der Cloud Console oder des bq-Befehlszeilentools erstellt werden. Die Limits gelten auch für Ladejobs, die programmatisch mit der API-Methode jobs.insert (Typ „load“) übertragen werden.

Beim Laden von Daten in BigQuery gelten die folgenden Limits:

  • Ladejobs pro Tabelle und Tag: 1.500 (einschließlich Fehlern)
  • Ladejobs pro Projekt und Tag: 100.000 (einschließlich Fehlern)
  • Zeilen- und Zellengrößenlimit:
    Datenformat Limit
    CSV 100 MB (Zeilen- und Zellengröße)
    JSON 100 MB (Zeilengröße)
  • Maximale Anzahl von Spalten pro Tabelle: 10.000
  • Maximale Dateigröße:
    Dateityp Komprimiert Unkomprimiert
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
  • Maximale Größe pro Ladejob: 15 TB für alle Eingabedateien in den Formaten CSV, JSON, Avro, Parquet und ORC
  • Maximale Größe für Avro-Dateidatenblöcke: 16 MB
  • Maximale Anzahl von Quell-URIs in der Jobkonfiguration: 10.000 URIs
  • Maximale Anzahl von Dateien pro Ladejob: insgesamt 10 Millionen Dateien einschließlich aller Dateien, die einem Platzhalter-URI entsprechen
  • Zeitlimit für die Ausführung von Ladejobs: 6 Stunden

Mit Ausnahme von Datasets in den USA müssen Sie Daten aus einem Cloud Storage-Bucket in der gleichen Region laden, in der sich das Dataset befindet. Der Bucket kann entweder ein multiregionaler Bucket oder ein regionaler Bucket in der gleichen Region wie das Dataset sein. In ein Dataset in den USA können Sie Daten aus jeder Region laden.

Wenn Sie aufgrund häufiger Aktualisierungen das Ladejobkontingent regelmäßig überschreiten, sollten Sie stattdessen Daten in BigQuery streamen.

Weitere Informationen finden Sie unter Einführung in das Laden von Daten in BigQuery.

Kopierjobs

Für das Kopieren von Tabellen in BigQuery gelten die folgenden Limits. Sie beziehen sich auf Jobs, die automatisch durch Kopieren von Daten mit dem bq-Befehlszeilentool oder der Cloud Console erstellt werden. Die Limits gelten auch für Kopierjobs, die programmatisch mit der API-Methode (Typ "copy") jobs.insert gesendet werden.

  • Kopierjobs pro Zieltabelle und Tag: 1.000 (einschließlich Fehlern)

  • Kopierjobs pro Projekt und Tag: 100.000 (einschließlich Fehlern)

  • Regionenübergreifende Kopierjobs pro Zieltabelle und Tag: 100 (einschließlich Fehlern)

  • Regionenübergreifende Kopierjobs pro Projekt und Tag: 2.000 (einschließlich Fehler)

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

  • Maximale Anzahl von Tabellen im Quell-Dataset: 20.000 Tabellen

  • Maximale Anzahl von Tabellen, die pro Ausführung in ein Ziel-Dataset in derselben Region kopiert werden können: 20.000 Tabellen pro Ausführung

  • Maximale Anzahl von Tabellen, die pro Ausführung in ein Ziel-Dataset in einer anderen Region kopiert werden können: 1.000 Tabellen pro Ausführung

    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 eine weitere Ausführung 1.000 Tabellen usw., bis alle Tabellen im Dataset kopiert wurden, bis zu maximal 20.000 Tabellen pro Dataset.

Exportjobs

Für Jobs, bei denen Daten aus BigQuery exportiert werden, gelten die folgenden Limits. Die folgenden Limits beziehen sich auf Jobs, die automatisch durch Exportieren von Daten mit dem bq-Befehlszeilentool oder der Cloud Console erstellt werden. Die Limits gelten auch für Exportjobs, die programmatisch mit der API-Methode jobs.insert (Typ "export") gesendet werden.
  • Exporte pro Tag: 100.000 Exporte pro Projekt und bis zu 50 TB pro Tag (das Datenlimit von 50 TB ist für alle Exporte kumulativ)
  • Wenn Sie mehr als 50 TB Daten pro Tag exportieren möchten, verwenden Sie die Anweisung Storage Read API oder die Anweisung EXPORT DATA.

  • Platzhalter-URIs: 500 Platzhalter-URIs pro Export

Limits für Datasets

Für Datasets gelten die folgenden Limits:

  • Anzahl Datasets pro Projekt: unbeschränkt

  • Anzahl Tabellen pro Dataset: unbeschränkt

    Wenn Sie einen API-Aufruf verwenden und ein Dataset rund 50.000 oder mehr Tabellen enthält, verlangsamt sich deren Aufzählung. In der Cloud Console können für jedes Dataset bis zu 50.000 Tabellen angezeigt werden.

  • Maximale Anzahl autorisierter Ansichten in der Access Control List eines Datasets: 2.500

    Sie können eine autorisierte Ansicht erstellen, um den Zugriff auf Ihre Quelldaten einzuschränken. Eine autorisierte Ansicht wird mit einer SQL-Abfrage erstellt, die die Spalten ausschließt, die Nutzer bei der Abfrage der Ansicht nicht sehen sollen. Sie können bis zu 2.500 autorisierte Ansichten zur Access Control List eines Datasets hinzufügen.

  • Maximale Aktualisierungsrate für Dataset-Metadaten: pro Dataset 5 Vorgänge alle 10 Sekunden

    Das Limit für die Aktualisierung von Dataset-Metadaten umfasst alle Metadaten-Aktualisierungsvorgänge, die mithilfe der Cloud Console, des bq-Befehlszeilentools, der Clientbibliotheken, durch Aufrufen der API-Methoden datasets.insert, datasets.patch oder datasets.update oder durch Ausführen der DDL-Anweisungen CREATE SCHEMA oder ALTER SCHEMA durchgefü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.

Tabellenlimits

Für BigQuery-Tabellen gelten die folgenden Limits:

Alle Tabellen

  • 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

    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.

Standardtabellen

  • Maximale Anzahl von Tabellenvorgängen pro Tag: 1.500

    Es stehen maximal 1.500 Vorgänge pro Tabelle und Tag zur Verfügung. Dabei spielt es keine Rolle, ob mit dem Vorgang Daten an eine Tabelle angefügt werden oder die Tabelle gekürzt wird.

    Die maximale Anzahl von Tabellenvorgängen umfasst die Gesamtsumme aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen, eine Zieltabelle überschreiben oder mithilfe der DML-Anweisung INSERT, UPDATE, DELETE oder MERGE Daten in eine Tabelle schreiben. DML-Anweisungen werden auf dieses Kontingent angerechnet, aber nicht dadurch limitiert. Mit anderen Worten: Die Anzahl der Vorgänge pro Tag, die unter dieses Kontingent fällt, beinhaltet DML-Anweisungen, aber dieses Limit führt nicht dazu, dass DML-Anweisungen fehlschlagen.

    Sie nutzen beispielsweise das komplette Kontingent, wenn Sie 500 Kopierjobs ausführen, mit denen Daten an mytable angefügt werden, und 1.000 Abfragejobs, mit denen Daten an mytable angefügt werden.

  • Maximale Aktualisierungsrate für Tabellenmetadaten: pro Tabelle 5 Vorgänge alle 10 Sekunden

    Das Aktualisierungslimit von Tabellenmetadaten umfasst alle Aktualisierungsvorgänge der Metadaten über die Cloud Console, das bq-Befehlszeilentool oder die Clientbibliotheken oder durch Aufrufen der API-Methoden tables.insert, tables.patch und tables.update oder durch Ausführen von ALTER TABLE-DDL-Anweisungen. Dieses Limit umfasst auch die Gesamtzahl aller Ladejobs, Kopier- und Abfragejobs, die an eine Zieltabelle angefügt werden oder diese überschreiben. Dieser Fehler ist in der Regel vorübergehend und wird mit einem exponentiellen Backoff wiederholt. Dieses Limit gilt nicht für DML-Vorgänge.

  • Maximale Anzahl an Spalten in einer Tabelle, einem Abfrageergebnis oder einer Ansichtsdefinition: 10.000

Partitionierte Tabellen

  • Maximale Anzahl von Partitionen pro partitionierter Tabelle: 4.000

  • Maximale Anzahl von Partitionen, die durch einen einzelnen Job geändert werden: 4.000

    Jeder Jobvorgang (Abfrage oder Laden) kann maximal 4.000 Partitionen betreffen. Abfrage- oder Ladejobs, die mehr als 4.000 Partitionen betreffen, werden von BigQuery abgelehnt.

  • Maximale Anzahl von Partitionsänderungen pro nach Aufnahmezeit partitionierter Tabelle: 5.000

  • Maximale Anzahl von Partitionsänderungen pro nach Spalte partitionierter Tabelle: 30.000

    Sie können maximal 5.000 Partitionsänderungen pro Tag für eine nach Aufnahmezeit partitionierte Tabelle und 30.000 Partitionsänderungen für eine nach Spalten partitionierte Tabelle vornehmen. Informationen zu Strategien, um innerhalb dieser Limits zu bleiben, finden Sie unter Fehlerbehebung bei Quotenfehlern.

    Eine Partition kann mithilfe eines Vorgangs geändert werden, bei dem Daten an eine Partition angefügt oder darin überschrieben werden. Vorgänge zur Änderung von Partitionen sind Ladejobs, Abfragen, die Ergebnisse in eine Partition schreiben, oder DML-Anweisungen (INSERT, DELETE, UPDATE oder MERGE), die Daten in einer Partition ändern.

    Ein Job kann mehrere Partitionen betreffen. 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. DML-Anweisungen werden auf dieses Kontingent angerechnet, aber nicht dadurch limitiert. Mit anderen Worten: Die Anzahl der Vorgänge pro Tag, die unter dieses Kontingent fällt, beinhaltet DML-Anweisungen, aber dieses Limit führt nicht dazu, dass DML-Anweisungen fehlschlagen.

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

  • Maximale Anzahl der Partitionsvorgänge: 50 Partitionsvorgänge alle 10 Sekunden pro Tabelle

  • Maximale Anzahl möglicher Bereiche für die Bereichspartitionierung: 10.000

    Dieses Limit gilt beim Erstellen der Tabelle für die Partitionsspezifikation. Nachdem Sie die Tabelle erstellt haben, gilt auch das Limit für die Anzahl der tatsächlichen Partitionen.

Tabellen-Snapshots

  • Maximale Anzahl von gleichzeitigen Tabellen-Snapshot-Jobs: 100

    Sie können bis zu 100 gleichzeitige Tabellen-Snapshot-Jobs pro Projekt und Region ausführen.

  • Maximale Anzahl von Tabellen-Snapshot-Jobs pro Tag: 50.000

    Sie können bis zu 50.000 Tabellen-Snapshot-Jobs pro Tag, Projekt und Region ausführen.

  • Maximale Anzahl von Jobs pro Tabellen-Snapshot und Tag: 50

    Sie können bis zu 50 Jobs pro Tag für einen Tabellen-Snapshot ausführen. Wenn Sie das Limit erhöhen lassen möchten, wenden Sie sich an den Support oder an den Vertrieb.

  • Maximale Anzahl von Metadatenaktualisierungen pro Tabellen-Snapshot pro 10 Sekunden – 5

    Sie können die Metadaten eines Tabellen-Snapshots bis zu fünfmal alle 10 Sekunden aktualisieren.

Externe Tabellen

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

  • Maximale Anzahl von Quell-URIs pro externe Tabelle: 10.000 URIs

  • Maximale Anzahl von Dateien pro externe Tabelle: insgesamt 10 Millionen Dateien einschließlich aller Dateien, die einem Platzhalter-URI entsprechen

  • Maximale Anzahl von gespeicherten Daten in Cloud Storage pro externe Tabelle für alle Eingabedateien: 600 TB

    Das Limit gilt für die Größe der in Cloud Storage gespeicherten Dateien. Die jeweilige Größe weicht von der Preisformel für Abfragen ab. Bei extern partitionierten Tabellen tritt das Limit nach der Partitionsbereinigung in Kraft.

Limits für Tabellenfunktionen

Die folgenden Limits gelten für Tabellenfunktionen.

  • Maximale Länge eines Funktionsnamens: 256 Zeichen
  • Maximale Anzahl der Argumente: 256
  • Maximale Länge eines Argumentnamens: 128 Zeichen
  • Maximale Tiefe der Referenzkette einer Tabellenfunktion: 16
  • Maximale Tiefe eines Arguments oder einer Ausgabe vom Typ STRUCT: 15
  • Maximale Anzahl der Felder in einer Argument- oder Rückgabetabelle vom Typ STRUCT pro Tabellenfunktion: 1.024
  • Maximale Anzahl von Spalten in der Rückgabetabelle: 1.024
  • Maximale Länge der Namen von Rückgabetabellenspalten: 128
  • Maximale Aktualisierungsrate pro Tabellenfunktion: 5 pro 10 Sekunden Nachdem Sie eine Tabellenfunktion erstellt haben, können Sie jede Funktion bis zu fünfmal pro 10 Sekunden aktualisieren.

Anweisungen der Datenbearbeitungssprache (Data Manipulation Language, DML)

Für BigQuery DML-Anweisungen gelten keine Kontingentlimits.

DML-Anweisungen werden jedoch bei der maximalen Anzahl von Tabellenvorgängen pro Tag und Partitionsänderungen pro Tag berücksichtigt. Diese Limits führen jedoch nicht dazu, dass DML-Anweisungen fehlschlagen.

Sicherheit auf Zeilenebene

Description Kontingent
Maximale Anzahl der Zeilenzugriffsrichtlinien pro Tabelle 100
Gesamtzahl der Zeilenzugriffsrichtlinien, auf die eine Abfrage von Tabellen mit Zeilenzugriffsrichtlinien verweisen kann 100
CREATE / DROP DDL-Anweisungen 5 pro 10 Sekunden und Zugriffsrichtlinie für Zeilen in einer Tabelle
DROP ALL ROW ACCESS POLICIES-Anweisungen 5 pro 10 Sekunden und Tabellenressource
Zeilenzugriffsrichtlinien mithilfe der REST API „rowAccessPolicies.list“ auflisten API-Standardkontingent
IAM-Richtlinien für Zeilenzugriffsrichtlinien abrufen (mithilfe der API „rowAccessPolicies.getIamPolicy“) IAM API-Standardkontingent

Streaming-Insert-Anweisungen

Die folgenden Limits gelten für das Streamen von Daten in BigQuery.

Wenn Sie das Feld insertId beim Einfügen von Zeilen nicht füllen, gilt das folgende Kontingent. Weitere Informationen finden Sie unter Best-Effort-Deduplizierung deaktivieren. Diese Verwendung von BigQuery wird empfohlen, um höhere Kontingentlimits für die Streamingaufnahme zu erhalten. Informationen zu Strategien, um innerhalb dieser Limits zu bleiben, finden Sie unter Fehlerbehebung bei Quotenfehlern.

  • Maximale Byte pro Sekunde: 1 GB

    Wenn Sie das Feld insertId nicht für jede eingefügte Zeile füllen, gilt ein Limit von 1 GB pro Sekunde und Projekt. Dieses Limit gilt auf Projektebene. Es gilt nicht für einzelne Tabellen.

    Ein Überschreiten dieses Wertes verursacht quotaExceeded-Fehler.

Wenn Sie das Feld insertId für jede eingefügte Zeile füllen, gelten die folgenden Kontingente.

  • Maximale Zeilen pro Sekunde und Projekt in den Mehrfachregionen us und eu: 500.000

    Wenn Sie das Feld insertId für jede eingefügte Zeile füllen, gilt in den Mehrfachregionen us und eu ein Limit von 500.000 Zeilen pro Sekunde und Projekt. Dieses Kontingent ist innerhalb einer Mehrfachregion kumulativ. Das heißt, die Summe der Zeilen pro Sekunde, die in alle Tabellen für ein bestimmtes Projekt innerhalb einer Mehrfachregion gestreamt werden können, ist auf 500.000 begrenzt. Jede Tabelle ist außerdem auf 100.000 Zeilen pro Sekunde beschränkt.

    Ein Überschreiten des Projekt- oder Tabellenlimits verursacht quotaExceeded-Fehler.

  • Maximale Zeilen pro Sekunde und Projekt an allen anderen Standorten: 100.000

    Wenn Sie das Feld insertId für jede eingefügte Zeile füllen, gilt an allen Standorten mit Ausnahme der Mehrfachregionen us und eu ein Limit von 100.000 Zeilen pro Sekunde und Projekt bzw. Tabelle. Dieses Kontingent ist innerhalb einer bestimmten Region kumulativ. Das heißt, die Summe der Zeilen pro Sekunde, die in alle Tabellen für ein bestimmtes Projekt innerhalb einer Region übertragen werden können, ist auf 100.000 begrenzt.

    Ein Überschreiten dieses Wertes verursacht quotaExceeded-Fehler.

  • Maximale Zeilen pro Sekunde und Tabelle: 100.000

    Wenn Sie das Feld insertId für jede eingefügte Zeile füllen, gilt ein Limit von 100.000 Zeilen pro Sekunde und Tabelle.

    Ein Überschreiten dieses Wertes verursacht quotaExceeded-Fehler.

  • Maximale Byte pro Sekunde: 100 MB

    Wenn Sie das Feld insertId für jede eingefügte Zeile füllen, gilt ein Limit von 100 MB pro Sekunde und Tabelle.

    Ein Überschreiten dieses Wertes verursacht quotaExceeded-Fehler.

Die folgenden zusätzlichen Streaming-Kontingente gelten unabhängig davon, ob Sie das Feld insertId füllen oder nicht:

  • Maximale Zeilengröße: 10 MB

    Das Überschreiten dieses Wertes verursacht invalid-Fehler.

  • Größenlimit für HTTP-Anfragen: 10 MB (siehe Hinweis)

    Das Überschreiten dieses Wertes verursacht invalid-Fehler.

  • Maximale Zeilen pro Anfrage: 50.000 Zeilen pro Anfrage

    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.

    Es werden maximal 500 Zeilen pro Anfrage empfohlen. Durch Tests mit repräsentativen Daten (Schema und Datengrößen) können Sie die optimale Batchgröße bestimmen.

  • Feldlänge von insertId: 128

    Das Überschreiten dieses Wertes verursacht invalid-Fehler.

Wenn Sie ein größeres Streamingkontingent für Ihr Projekt benötigen, können Sie die Best-Effort-Deduplizierung deaktivieren. Für darüber hinausgehende Kontingenterhöhungen müssen Sie in der Google Cloud Console eine Anfrage stellen. Innerhalb von zwei bis drei Arbeitstagen erhalten Sie dann eine Antwort.

UDF-Limits

Die folgenden Limits gelten für temporäre und persistente benutzerdefinierte Funktionen (User-Defined Functions, UDF) in SQL-Abfragen:

  • Der Umfang an Daten, den Ihre JavaScript-UDF bei der Verarbeitung einer einzelnen Zeile ausgibt, ist auf ca. 5 MB oder weniger beschränkt.
  • Die Rate für gleichzeitige Legacy-SQL-Abfragen, die benutzerdefinierte Funktionen (User-defined Functions, UDFs) enthalten, ist auf 6 gleichzeitige Abfragen beschränkt.
  • Das Ratenlimit für gleichzeitige Legacy-SQL-Abfragen, die UDFs enthalten, 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.

  • Maximale Anzahl von JavaScript-UDF-Ressourcen wie Inline-Code-Blobs oder externe Dateien in einem Abfragejob: 50.
  • Maximale Größe eines Inline-Code-Blobs: 32 KB
  • Maximale Größe einer externen Coderessource: 1 MB
Für persistente benutzerdefinierte Funktionen gelten die folgenden Limits
  • Maximale Länge eines Funktionsnamens: 256 Zeichen
  • Maximale Anzahl der Argumente: 256
  • Maximale Länge eines Argumentnamens: 128 Zeichen
  • Maximale Tiefe der Referenzkette einer benutzerdefinierten Funktion: 16
  • Maximale Tiefe eines Arguments oder einer Ausgabe vom Typ STRUCT: 15
  • Maximale Anzahl der Felder in einem Argument oder einer Ausgabe vom Typ STRUCT pro UDF: 1.024
  • Maximale Anzahl der Verweise auf einzelne UDFs und Tabellen pro Abfrage: 1.000.

    Nach vollständiger Erweiterung kann eine UDF auf bis zu 1.000 Kombinationen aus einzelnen Tabellen und UDFs verweisen.

  • Maximale Anzahl der JavaScript-Bibliotheken in einer CREATE-FUNCTION-Anweisung: 50
  • Maximale Länge der enthaltenen JavaScript-Bibliothekspfade: 5.000 Zeichen
  • Maximale Aktualisierungsrate pro UDF: 5 pro 10 Sekunden

    Nach der Funktionserstellung können Sie jede Funktion bis zu fünfmal pro 10 Sekunden aktualisieren.

  • Jedes Inline-Codeblob ist auf eine maximale Größe von 32 KB begrenzt.
  • Jede JavaScript-Coderessource ist auf eine maximale Größe von 1 MB begrenzt.

Limits ansehen

  • Maximale Anzahl verschachtelter Ansichtsebenen: 16

    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 zur Definition einer Ansicht verwendeten SQL-Abfrage: 256.000 Zeichen

    Wenn Sie eine Ansicht erstellen, darf der Text der Standard-SQL-Abfrage höchstens 256.000 Zeichen betragen.

  • Maximale Anzahl autorisierter Ansichten in der Access Control List eines Datasets: 2.500

    Sie können eine autorisierte Ansicht erstellen, um den Zugriff auf Ihre Quelldaten einzuschränken. Eine autorisierte Ansicht wird mit einer SQL-Abfrage erstellt, die die Spalten ausschließt, die Nutzer bei der Abfrage der Ansicht nicht sehen sollen. Sie können der Access Control List eines Datasets bis zu 2.500 autorisierte Ansichten hinzufügen.

API-Anfragen

Alle API-Anfragen

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

  • API-Anfragen pro Sekunde und Nutzer: 100

    Bei mehr als 100 Anfragen pro Sekunde kann es zu einer Drosselung kommen. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.

  • Gleichzeitige API-Anfragen pro Nutzer: 300

    Bei mehr als 300 gleichzeitigen Anfragen pro Nutzer kann es zu einer Drosselung kommen. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.

tabledata.list-Anfragen

Mit der Methode tabledata.list werden Tabellendaten aus einem bestimmten Satz von Zeilen abgerufen. Das Kontingent dieser API kann auch für andere APIs wie jobs.getQueryResults und das Abrufen von Ergebnissen von jobs.query und jobs.insert genutzt werden. Die folgenden Limits betreffen tabledata.list-Anfragen:

  • Maximale Anzahl von tabledata.list-Anfragen pro Projekt: 1000/Sekunde

    Wenn Sie tabledata.list aufrufen, können Sie bis zu 1000 Anfragen pro Sekunde und Projekt erstellen.

  • Maximale Byte pro Sekunde und Projekt, die durch Aufrufe an tabledata.list zurückgegeben werden: 60 MB/Sekunde

    Wenn Sie tabledata.list aufrufen, können maximal 60 MB an Tabellenzeilendaten pro Sekunde und Projekt zurückgegeben werden. Das Limit gilt für das Projekt, das die gelesene Tabelle enthält.

  • Maximale Zeilen pro Sekunde und Projekt, die durch tabledata.list-Aufrufe zurückgegeben werden: 150.000/Sekunde

    Wenn Sie tabledata.list aufrufen, können maximal 150.000 Tabellenzeilen pro Sekunde und Objekt zurückgegeben werden. Das Limit gilt für das Projekt, das die gelesene Tabelle enthält.

  • Maximale Anzahl von Zeilen, die durch einen tabledata.list-Aufruf zurückgegeben werden: 100.000 Zeilen

    Wenn Sie tabledata.list aufrufen, kann die Antwort maximal 100.000 Tabellenzeilen enthalten. Weitere Informationen finden Sie unter Ergebnisse mithilfe der API ansehen.

tables.insert-Anfragen

Mit der Methode tables.insert wird eine neue, leere Tabelle in einem Dataset erstellt. Die folgenden Limits betreffen tables.insert-Anfragen:

projects.list-Anfragen

Mit der Methode projects.list werden alle Projekte aufgelistet, auf die Sie Zugriff erhalten haben. Die folgenden Limits betreffen projects.list-Anfragen:

  • Maximale Anfragen pro Sekunde und Projekt: 2

    Wenn Sie projects.list aufrufen, können maximal zwei Anfragen pro Sekunde und Projekt erstellt werden.

jobs.get-Anfragen

Bei der Methode jobs.get werden Informationen zu einem konkreten Auftrag zurückgegeben. Die folgenden Limits betreffen jobs.get-Anfragen:

  • Maximale Anfragen pro Sekunde und Projekt: 1.000

    Wenn Sie jobs.get aufrufen, können maximal 1000 Anfragen pro Sekunde und Projekt erstellt werden.

jobs.query-Anfragen

Mit der Methode jobs.query wird eine SQL-Abfrage synchron ausgeführt und es werden Ergebnisse zurückgegeben, wenn die Abfrage innerhalb eines bestimmten Zeitlimits abgeschlossen wird.

  • Maximale Antwortgröße: 10 MB

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

IAM API-Anfragen

Die folgenden Limits gelten, wenn Funktionen der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) in BigQuery eingesetzt werden, um IAM-Richtlinien abzurufen und festzulegen sowie IAM-Berechtigungen zu testen.

  • Maximale Anfragen pro Nutzer: 25

    Es sind maximal 25 IAM-Anfragen pro Sekunde, Nutzer und Projekt zulässig.

  • Maximale Anfragen pro Projekt: 50

    Es sind maximal 50 IAM-Anfragen pro Sekunde und Projekt zulässig.

Wenn Sie ein größeres IAM-Kontingent für Ihr Projekt benötigen, können Sie in der Google Cloud Console eine Anfrage stellen. Innerhalb von zwei bis drei Arbeitstagen erhalten Sie dann eine Antwort.

BigQuery Storage Read API-Anfragen

Für die Storage Read API gelten die folgenden Kontingente und Limits.

  • Maximale Zeilenbeschränkung/Filterlänge: 1 MB

    Wenn Sie den CreateReadSession-Aufruf der Storage Read API verwenden, gilt eine maximale Zeilenbeschränkung/Filterlänge von 1 MB.

  • Leseanfragen auf Datenebene: 5.000 Aufrufe pro Minute, Nutzer und Projekt

    Sie sind auf 5.000 ReadRows-Aufrufe pro Minute, Nutzer und Projekt beschränkt.

  • Anfragen auf Steuerungsebene: 5.000 Aufrufe pro Minute, Nutzer und Projekt

    Sie können maximal 5.000 API-Metadatenaufrufe für die Storage Read API (CreateReadSession und SplitReadStream) pro Minute, Nutzer und Projekt vornehmen.

BigQuery Storage Write API-Anfragen

Für die Storage Write API gelten die folgenden Kontingente und Limits.

  • Ratenlimit für das Erstellen von Schreibstreams: 100 pro Minute und Projekt

    CreateWriteStream-Aufrufe sind begrenzt. Wenn Sie dieses Limit erreichen, wiederholen Sie den Vorgang mit exponentiellem Backoff. Versuchen Sie außerdem, Aufrufe an CreateWriteStream zu verteilen. Der Standard-Stream unterliegt diesem Kontingent nicht. Wenn Sie die Datenduplizierung mit dem Commit-Modus nicht benötigen, sollten Sie den Standard-Stream verwenden.

  • Ausstehende Byte: 100 GB pro Projekt.

    Dieses Limit gibt die maximale Anzahl von Byte an, die Sie im ausstehenden Modus schreiben können, bevor Sie die Streams übergeben.

  • Gleichzeitige Verbindungen: 1.000 pro Projekt.

  • Maximale Anzahl an Streams, die an BatchCommitWriteStreams übergeben werden: 100

    Im ausstehenden Modus nimmt die Methode BatchCommitWriteStreams eine Liste von Streams an, für die ein Commit durchgeführt werden soll. Wird dieses Limit überschritten, gibt die Methode einen Fehler zurück. Zur Vereinfachung können Sie BatchCommitWriteStreams mehrmals aufrufen.

Wann werden Kontingente aufgefüllt?

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.

Fehlerbehebung

Informationen zum Beheben von Fehlern bei Kontingentlimits finden Sie unter Fehler in BigQuery-Kontingenten beheben.

Kontingentnutzung einschränken

Informationen zum Einschränken der Nutzung einer bestimmten Ressource bis zum von Google festgelegten Limit finden Sie unter Nutzung einschränken.