Kontingente und Begrenzungen

BigQuery begrenzt die maximale Anzahl von eingehenden Abfragen und vergibt entsprechende Kontingente auf Projektbasis. Die einzelnen Richtlinien sind je nach Ressourcenverfügbarkeit, Nutzerprofil, Dienstnutzungsverlauf sowie weiteren Faktoren unterschiedlich und können ohne Ankündigung geändert werden.

Die folgenden Listen enthalten die aktuell gültigen Raten- und Kontingentlimits des Systems.

Abfragejobs

Für Abfragejobs, die automatisch durch die Ausführung interaktiver Abfragen erstellt werden, und für Jobs, die programmatisch durch Aufrufen der Methode jobs.query und des Abfragetyps der Methode jobs.insert gesendet werden, gelten die folgenden Begrenzungen:

Abfragen mit Ergebnissen, die aus dem Abfragecache geliefert werden, und Probeabfragen werden für diese Begrenzung nicht berücksichtigt. Mithilfe des Flags --dry_run oder durch Angabe der Property dryRun bei einem Abfragejob können Sie diesen als Probeabfrage definieren.

  • Ratenbegrenzung für gleichzeitige alte SQL-Abfragen, die benutzerdefinierte Funktionen (UDFs) enthalten: 6 gleichzeitige Abfragen

Die gleichzeitige Ratenbegrenzung für alte SQL-Abfragen, die UDFs enthalten, umfasst sowohl interaktive als auch Batch-Abfragen. Interaktive Abfragen, die UDFs enthalten, werden auch auf das Limit für gleichzeitige interaktive Abfragen angerechnet. Diese Begrenzung gilt nicht für Standard-SQL-Abfragen.

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

Sie können benutzerdefinierte Kontingente festlegen, um Limits für die Datenmenge vorzugeben, die Benutzer abfragen können.

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

Zieltabellen in einem Abfragejob unterliegen dem Limit von 1.000 Aktualisierungen pro Tabelle pro Tag. Zu den Aktualisierungen von Zieltabellen zählen unter anderem Anfügungs- und Überschreibungsvorgänge, die durch eine Abfrage mithilfe der Webbenutzeroberfläche von BigQuery, des Befehlszeilentools bq oder der API-Methode jobs.query und des Abfragetyps der API-Methode jobs.insert ausgeführt werden.

  • Zeitlimit für die Abfrageausführung: 6 Stunden

  • Maximale Anzahl von Tabellen, auf die pro Abfrage verwiesen wird: 1.000

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

  • Maximale Länge gelöster Abfragen: 12 MB

Das Limit für die Länge der gelösten Abfragen umfasst die Länge aller Ansichten und Platzhaltertabellen, auf die die Abfrage verweist.

  • Maximale Größe der Antwort: 128 MB komprimiert1

1Die Größe ist je nach Komprimierungsverhältnis für die Daten unterschiedlich. Die tatsächliche Größe der Antwort kann 128 MB deutlich überschreiten.

Die maximale Größe der Antwort ist beim Schreiben großer Abfrageergebnisse in eine Zieltabelle unbegrenzt.

  • Maximale Zeilengröße: 100 MB2

2Das maximale Limit für die Zeilengröße ist eine ungefähre Angabe, weil es von der internen Darstellung der Zeilendaten abhängt. Es kommt in bestimmten Phasen bei der Ausführung eines Abfragejobs zur Anwendung.

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

Die Standardanzahl von Slots für On-Demand-Abfragen gilt für alle Abfragen in einem einzelnen Projekt. Wenn Sie gleichzeitig Abfragen mit weniger als 100 GB ausführen, ist es normalerweise unwahrscheinlich, dass alle 2.000 Slots genutzt werden.

Informationen darüber, wie viele Slots Sie nutzen, finden Sie unter BigQuery mit Stackdriver überwachen. Wenn Sie mehr als 2.000 Slots benötigen, kontaktieren Sie Ihren Vertriebsmitarbeiter, um zu klären, ob es für Ihre Zwecke einen Pauschalpreis gibt.

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

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

Ladejobs

Für Jobs, die automatisch durch das Laden von Daten mithilfe des Befehlszeilentools oder der Webbenutzeroberfläche von BigQuery erstellt werden, gelten die folgenden Begrenzungen. Sie gelten auch für Ladejobs, die mithilfe des Ladetyps der API-Methode jobs.insert programmatisch gesendet werden.

Beim Laden von Daten in BigQuery gelten die folgenden Limits:

  • Ladejobs pro Tabelle pro Tag: 1.000 (einschließlich Fehler)
  • Ladejobs pro Projekt pro Tag: 50.000 (einschließlich Fehler)
  • Das Limit von 1.000 Ladejobs pro Tabelle pro Tag kann nicht erhöht werden.
  • Zeilen- und Zellengrößenlimit:
    Datenformat Max. Limit
    CSV 100 MB (Zeilen- und Zellengröße)
    JSON 100 MB (Zeilengröße)
    Avro 16 MB (Blockgröße)
  • Maximale Anzahl Spalten pro Tabelle: 10.000
  • Maximale Dateigröße:
    Dateityp Komprimiert Unkomprimiert
    CSV 4 GB 5 TB
    JSON 4 GB 5 TB
    Avro Komprimierte Avro-Dateien werden nicht unterstützt, komprimierte Datenblöcke dagegen schon. BigQuery unterstützt DEFLATE- und Snappy-Codecs. 5 TB (1 MB für Dateiheader)
  • Maximale Größe pro Ladejob: 15 TB für alle Eingabedateien im Format CSV, JSON und Avro
  • 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 der Standort des Datasets 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 gelten für Jobs, die automatisch durch das Kopieren von Daten mithilfe des Befehlszeilentools oder der Webbenutzeroberfläche von BigQuery erstellt werden. Die Begrenzungen gelten auch für Kopierjobs, die mithilfe des Kopiertyps der API-Methode jobs.insert programmatisch gesendet werden.

  • Kopierjobs pro Zieltabelle pro Tag: 1.000 (einschließlich Fehler)
  • Kopierjobs pro Projekt pro Tag: 10.000 (einschließlich Fehler)

Exportjobs

Für Jobs, bei denen Daten aus BigQuery exportiert werden, gelten die folgenden Limits. Sie gelten für Jobs, die automatisch durch das Exportieren von Daten mithilfe des Befehlszeilentools oder der Webbenutzeroberfläche von BigQuery erstellt werden. Die Begrenzungen gelten auch für Exportjobs, die mithilfe des Ladetyps der API-Methode jobs.insert programmatisch gesendet werden.

  • Exporte pro Tag: 50.000 Exporte pro Projekt und bis zu 10 TB pro Tag (das Datenlimit von 10 TB ist für alle Exporte kumulativ)
  • Platzhalter-URIs: 500 Platzhalter-URIs pro Export

Limits für Datasets

Für Datasets gelten die folgenden Limits:

  • Anzahl an Datasets pro Projekt: uneingeschränkt
    Die Anzahl der Datasets pro Projekt unterliegt keinem Kontingent. Ab mehreren tausend Datasets in einem Projekt verschlechtert sich jedoch die Leistung der Web-UI und die Auflistung der Datasets wird langsamer.
  • Anzahl an Tabellen pro Dataset: uneingeschränkt
    Die Anzahl an Tabellen pro Dataset ist ebenfalls nicht eingeschränkt, aber wenn annähernd 50.000 oder mehr Tabellen in einem Dataset vorhanden sind, verlangsamt sich deren Aufzählung. Die Leistung bei der Aufzählung nimmt unabhängig davon ab, ob Sie einen API-Aufruf, die Web-UI oder die Metatabelle __TABLES_SUMMARY__ verwenden. Zur Steigerung der UI-Leistung können Sie mit dem Parameter ?minimal die Anzahl der angezeigten Tabellen auf 30.000 pro Projekt begrenzen. Fügen Sie der URL der BigQuery-Weboberfläche den Parameter im folgenden Format hinzu: https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal.
  • Maximale Anzahl von autorisierten Ansichten in der Access Control List eines Datasets: 1.000
    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 1.000 autorisierte Ansichten hinzufügen.
  • Maximale Aktualisierungsrate für Dataset-Metadaten: ein Vorgang alle 2 Sekunden pro Dataset
    Die Aktualisierungsbegrenzung für Dataset-Metadaten umfasst alle Aktualisierungsvorgänge von Metadaten, die mithilfe der Webbenutzeroberfläche von BigQuery, des Befehlszeilentools bq oder durch Aufrufen der API-Methode datasets.insert, datasets.patch oder datasets.update ausgeführt werden.

Tabellenlimits

Für BigQuery-Tabellen gelten folgende Limits.

Standardtabellen

  • Maximale Anzahl an Tabellenvorgängen pro Tag: 1.000

Es stehen Ihnen maximal 1.000 Vorgänge pro Tabelle pro Tag unabhängig davon zur Verfügung, ob mit dem Vorgang Daten an eine Tabelle angefügt werden, eine Tabelle überschrieben oder die DML-Anweisung INSERT verwendet wird, um Daten in eine Tabelle zu schreiben.

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 die DML-Anweisung INSERT verwenden, um Daten in eine Tabelle zu schreiben.

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

  • Maximale Aktualisierungsrate für Tabellenmetadaten: ein Vorgang alle 2 Sekunden pro Tabelle

Die Aktualisierungsbegrenzung für Tabellenmetadaten umfasst alle Aktualisierungsvorgänge von Metadaten, die mithilfe der Webbenutzeroberfläche von BigQuery, des Befehlszeilentools bq oder durch Aufrufen der API-Methode tables.insert, tables.patch oder tables.update ausgeführt werden. Dieses Limit gilt auch für die Jobs-Ausgabe.

Partitionierte Tabellen

  • Maximale Anzahl von Partitionen pro partitionierter Tabelle: 4.000

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

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

  • Maximale Anzahl von Partitionsänderungen pro Tag pro Tabelle: 5.000

Pro partitionierter Tabelle gilt eine Beschränkung auf maximal 5.000 Partitionsänderungen pro Tag. 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 mehr als eine Partition betreffen. Durch eine DML-Anweisung können z. B. Daten in mehreren Partitionen aktualisiert werden (sowohl für Tabellen mit Aufnahmezeit als auch für partitionierte Tabellen). Auch Abfrage- und Ladejobs können in mehrere Partitionen schreiben, jedoch nur für partitionierte Tabellen. Google BigQuery verwendet die Anzahl der Partitionen, die von einem Job betroffen sind, um zu ermitteln, wie viel des Kontingents durch einen Job verbraucht wird. Streaming-Insert-Anweisungen werden dabei nicht berücksichtigt.

  • Maximale Anzahl an Partitionsvorgängen: 50 Partitionsvorgänge alle 10 Sekunden

UDF-Begrenzungen

Die folgenden Begrenzungen gelten für benutzerdefinierte Funktionen in SQL-Abfragen.

  • Die Datenmenge, die Ihre JavaScript-UDF beim Verarbeiten einer einzelnen Zeile ausgibt, beträgt ca. 5 MB oder weniger.
  • Ratenbegrenzung für gleichzeitige alte SQL-Abfragen, die benutzerdefinierte Funktionen enthalten: 6 gleichzeitige Abfragen
  • Die gleichzeitige Ratenbegrenzung für alte SQL-Abfragen, die UDFs enthalten, umfasst sowohl interaktive als auch Batch-Abfragen. Interaktive Abfragen, die UDFs enthalten, werden auch auf die Begrenzung für gleichzeitige interaktive Abfragen angerechnet. Diese Begrenzung gilt nicht für Standard-SQL-Abfragen.

  • Jedem Abfragejob können maximal 50 JavaScript-UDF-Ressourcen zugewiesen werden (Inline-Codeblobs oder externe Dateien).
  • Jedes Inline-Codeblob ist auf eine maximale Größe von 32 KB beschränkt.
  • Jede externe Coderessource ist auf eine maximale Größe von 1 MB begrenzt.

Anweisungen der Datenbearbeitungssprache

Für Anweisungen der Datenbearbeitungssprache (DML) gelten die folgenden Limits:

  • Maximale Gesamtzahl an UPDATE-, DELETE- und MERGE-Anweisungen pro Tag pro Tabelle: 200
  • Maximale Gesamtzahl an UPDATE-, DELETE- und MERGE-Anweisungen pro Tag pro Projekt: 10.000
  • Maximale Anzahl an INSERT-Anweisungen pro Tag pro Tabelle: 1.000

Eine MERGE-Anweisung gilt auch dann als einzelne DML-Anweisung, wenn sie mehrere INSERT-, UPDATE- oder DELETE-Befehle enthält.

DML-Anweisungen sind eingeschränkter als SELECT-Anweisungen (SQL), weil die Verarbeitung von DML-Anweisungen deutlich mehr Ressourcen erfordert.

Streaming-Insert-Anweisungen

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

  • Maximale Zeilengröße: 1 MB. Ein Überschreiten dieses Wertes führt zu einem invalid-Fehler.
  • Größenbeschränkung für HTTP-Requests: 10 MB. Ein Überschreiten dieses Wertes führt zu einem invalid-Fehler.
  • Maximale Zeilen pro Sekunde: 100.000 Zeilen pro Sekunde pro Projekt. Ein Überschreiten dieses Wertes führt zu quotaExceeded-Fehlern. Die maximale Anzahl von Zeilen pro Sekunde pro Tabelle liegt ebenfalls bei 100.000. Sie können das gesamte Kontingent für eine Tabelle verwenden oder es auf mehrere Tabellen in einem Projekt aufteilen.
  • Maximale Zeilen pro Request: 10.000 Zeilen pro Request. Es wird empfohlen, 500 Zeilen nicht zu überschreiten. Durch die Stapelverarbeitung können Leistung und Durchsatz bis zu einem gewissen Punkt gesteigert werden, allerdings auf Kosten der Latenz pro Request. Bei zu wenigen Zeilen pro Request kann der Aufwand jedes Requests die Datenaufnahme ineffizient machen. Bei zu vielen Zeilen pro Request sinkt möglicherweise der Durchsatz. Wir empfehlen ca. 500 Zeilen pro Request, aber durch Tests mit repräsentativen Daten (Schema und Datengrößen) können Sie die optimale Stapelgröße bestimmen.
  • Maximale Byte pro Sekunde: 100 MB pro Sekunde und Tabelle. Ein Überschreiten dieses Wertes erzeugt quotaExceeded-Fehler.

Wenn Sie für Ihr Projekt mehr Streaming-Datenkontingente benötigen, können Sie auf der Seite der Google Cloud Platform Console eine Anfrage senden. Sie können für das Streaming von Daten ein benutzerdefiniertes Kontingent in Schritten von 50.000 Zeilen festlegen. Normalerweise erhalten Sie innerhalb von zwei bis drei Arbeitstagen eine Antwort.

API-Requests

Alle API-Requests

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

  • API-Requests pro Sekunde und Nutzer: 100
    Bei mehr als 100 Requests pro Sekunde kann es zu einer Drosselung kommen. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.
  • Gleichzeitige API-Requests pro Nutzer: 300
    Bei mehr als 300 gleichzeitigen Requests pro Nutzer kann es zu einer Drosselung kommen. Dieses Limit gilt nicht für Streaming-Insert-Anweisungen.

tabledata.list-Requests

Mit der Methode tabledata.list werden Tabellendaten aus einem bestimmten Satz von Zeilen abgerufen. Für tabledata.list-Requests gelten die folgenden Limits:

  • Maximale Byte pro Sekunde und Projekt, die bei tabledata.list-Aufrufen 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 bei tabledata.list-Aufrufen zurückgegeben werden: 150.000/Sekunde
    Wenn Sie tabledata.list aufrufen, können maximal 150.000 Tabellenzeilen pro Sekunde und Projekt zurückgegeben werden. Das Limit gilt für das Projekt, das die gelesene Tabelle enthält.

tables.insert-Requests

Mit der Methode tables.insert wird eine neue, leere Tabelle in einem Dataset erstellt. Für tables.insert-Requests gelten die folgenden Limits:

projects.list-Requests

Mit der Methode projects.list werden alle Projekte aufgelistet, auf die Ihnen Zugriff gewährt wurde. Für projects.list-Requests gelten die folgenden Limits:

  • Maximale Requests pro Sekunde und Projekt: 2
    Wenn Sie projects.list aufrufen, können maximal zwei Requests pro Sekunde und Projekt erstellt werden.

jobs.get-Requests

Mit der Methode jobs.get werden Informationen zu einem bestimmten Job geliefert. Für jobs.get-Requests gelten die folgenden Limits:

  • Maximale Requests pro Sekunde und Projekt: 1.000
    Wenn Sie jobs.get aufrufen, können maximal 1.000 Requests pro Sekunde und Projekt erstellt werden.

Wann werden Kontingente aufgefüllt?

Tägliche Kontingente werden den ganzen Tag über in regelmäßigen Intervallen aufgefüllt, um das Verhalten von Ratenbegrenzungen zu steuern. Auch zwischenzeitlich aufgebrauchte Kontingente werden aufgefüllt, um längere Unterbrechungen zu vermeiden. Das Auffüllen des Kontingents erfolgt im Gegensatz zu einem täglichen Auffüllen meist innerhalb weniger Minuten.

Fehlercodes

Kontingent- und Limitfehler geben entweder den HTTP-Antwortcode 403 oder 400 zurück. Eine vollständige Liste mit Fehlercodes und Schritten zur Fehlerbehebung finden Sie unter "Fehlerbehebung".

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...