Kontingente und Limits

Auf dieser Seite finden Sie die aktuell gültigen Ratenbegrenzungen und Kontingentlimits für BigQuery.

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.

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.

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 angeben, indem Sie das Flag --dry_run verwenden oder in einem Abfragejob das Attribut dryRun festlegen.

Dieses Limit gilt auf Projektebene. Wenn Sie das Limit erhöhen lassen möchten, wenden Sie sich an den Support oder an 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 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 Zieltabellenaktualisierungen gehören Anhänge- und Überschreibvorgänge, die von einer Abfrage über die Konsole, die klassische BigQuery-Web-UI, das bq-Befehlszeilentool oder durch Aufrufen der API-Methoden jobs.query und jobs.insert (Typ „query“) ausgeführt werden.

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

  • Maximale Größe der Antwort: 10 GB komprimiert1

1Die 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 MB2

2Das 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.

  • Maximale Anzahl gleichzeitiger Abfragen einer externen Cloud Bigtable-Datenquelle: 4

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 mit dem Befehlszeilentool, in der Cloud Console oder über die klassische BigQuery-Web-UI 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)
  • Das Limit von 1.500 Ladejobs pro Tabelle und Tag kann nicht erhöht werden.
  • 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 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.

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, der Cloud Console oder der klassischen BigQuery-Web-UI erstellt werden. Die Limits gelten auch für Kopierjobs, die programmatisch mit der API-Methode jobs.insert (Typ „copy“) gesendet werden.

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

Exportjobs

Für Jobs, bei denen Daten aus BigQuery exportiert werden, gelten die folgenden Limits. Sie beziehen sich auf Jobs, die automatisch durch Exportieren von Daten mit dem bq-Befehlszeilentool, der Cloud Console oder der klassischen BigQuery-Web-UI erstellt werden. Die Limits gelten auch für Exportjobs, die programmatisch mit der API-Methode jobs.insert (Typ „load“) 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)
  • Mit der BigQuery Storage API können Sie auch mehr als 50 TB Daten pro Tag exportieren.

  • Platzhalter-URIs: 500 Platzhalter-URIs pro Export

Limits für Datasets

Für Datasets gelten die folgenden Limits:

  • Anzahl von Datasets pro Projekt: unbeschränkt
    Die Anzahl der Datasets pro Projekt unterliegt keinem Kontingent. Ab mehreren Tausend Datasets in einem Projekt verschlechtert sich aber die Leistung der klassischen Web-UI und die Auflistung der Datasets wird langsamer.
  • Anzahl von Tabellen pro Dataset: unbeschränkt
    Wenn ein Dataset rund 50.000 oder mehr Tabellen enthält, verlangsamt sich deren Aufzählung. Dies gilt speziell bei API-Aufrufen oder in der klassischen BigQuery-Web-UI. Derzeit können mit der BigQuery-Web-UI in der Google Cloud Console nur 50.000 Tabellen pro Dataset angezeigt werden. Sie können die Leistung der klassischen BigQuery-Web-UI aber verbessern. Hierfür begrenzen Sie einfach mithilfe des Parameters ?minimal die Anzahl der angezeigten Tabellen pro Projekt auf 30.000. Den Parameter fügen Sie der URL für die klassische BigQuery-Web-UI im folgenden Format hinzu: https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal.
  • 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.
  • Maximale Aktualisierungsrate für Dataset-Metadaten: pro Dataset 5 Vorgänge alle 10 Sekunden
    Das Aktualisierungslimit für die Dataset-Metadaten umfasst alle Aktualisierungsvorgänge der Metadaten über die Konsole, die klassische BigQuery-Web-UI, das bq-Befehlszeilentool oder durch Aufrufen der API-Methoden datasets.insert, datasets.patch oder datasets.update.
  • 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.

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 für die Tabellenmetadaten umfasst alle Aktualisierungsvorgänge der Metadaten über die Cloud Console, die klassische BigQuery-Web-UI, das bq-Befehlszeilentool, die Clientbibliotheken, durch Aufrufen der API-Methoden tables.insert, tables.patch und tables.update oder durch Ausführen von ALTER TABLE-DDL-Anweisungen. Dieses Limit gilt auch für die Ausgabe von Jobs.

  • Maximale Anzahl von 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. 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 von Partitionsvorgängen: 50 Partitionsvorgänge alle 10 Sekunden

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.

Ansichten-Limits

  • 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.

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 (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.

Anweisungen der Datenbearbeitungssprache

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.

Darüber hinaus gilt für DML-Anweisungen die maximale Aktualisierungsrate für Tabellenmetadaten. Falls dieses Limit überschritten wird, wiederholen Sie den Vorgang mit einem exponentiellen Backoff zwischen den einzelnen Versuchen.

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.

  • 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, d. h., die Summe der pro Sekunde in alle Tabellen gestreamten Zeilen für ein bestimmtes Projekt innerhalb einer Mehrfachregion 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 Region kumulativ, d. h., die Summe der pro Sekunde in alle Tabellen gestreamten Zeilen für ein bestimmtes Projekt innerhalb einer Region 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: 5 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: 10.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.

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: 500/Sekunde
    Wenn Sie tabledata.list aufrufen, können Sie bis zu 500 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.

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 1.000 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.

  • Auf Google Cloud-Projektebene gilt ein Limit von 25 Anfragen pro Sekunde und Nutzer.

  • Auf Google Cloud-Projektebene gilt ein Limit von 50 Anfragen pro Sekunde.

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 API-Anfragen

Die folgenden Limits gelten für ReadRows-Aufrufe mit der BigQuery Storage API:

  • ReadRows-Aufrufe pro Minute: 5.000. Wenn Daten mit der BigQuery Storage API gelesen werden, ist die Anzahl der ReadRows-Aufrufe pro Minute, Nutzer und Projekt auf 5.000 beschränkt.

Die folgenden Limits gelten für alle anderen Methodenaufrufe mit der BigQuery Storage API:

  • API-Aufrufe pro Minute: 1.000. Die Anzahl der BigQuery Storage API-Aufrufe pro Minute, Nutzer und Projekt ist auf 1.000 beschränkt.

Wann werden die Kontingente wieder 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.