Kontingente und Beschränkungen

BigQuery begrenzt die maximale Anzahl von eingehenden Abfragen und vergibt entsprechende Kontingente auf Projektbasis. Bestimmte Richtlinien variieren je nach Ressourcenverfügbarkeit, Nutzerprofil, Dienstnutzungsverlauf und weiteren Faktoren und können ohne Vorankündigung geändert werden.

In der folgenden Liste werden die aktuell gültigen Raten- und Kontingentlimits des Systems zusammengefasst.

Abfragen

Die folgenden Limits gelten für den Funktionsaufruf jobs.query und den Abfragetyp-Funktionsaufruf jobs.insert.

  • Limit für gleichzeitige interaktive Abfragen zu On-Demand-Preisen: 50 gleichzeitige Abfragen. Abfragen, die im Cache gespeicherte Ergebnisse zurückgeben, oder Abfragen, die mithilfe der Property dryRun konfiguriert wurden, werden nicht auf dieses Limit angerechnet.
  • Limit für gleichzeitige Abfragen, die benutzerdefinierte Funktionen (UDFs) enthalten: sechs gleichzeitige Abfragen, einschließlich interaktive Abfragen und Stapelabfragen. Interaktive Abfragen, die UDFs enthalten, werden auf das Limit für gleichzeitige interaktive Abfragen angerechnet.
  • Tageslimit für Abfragegröße: Standardmäßig unbegrenzt, aber es können Limits über benutzerdefinierte Kontingente festgelegt werden.
  • Tägliches Aktualisierungslimit: 1.000 Aktualisierungen pro Tabelle pro Tag. Gilt nur für die Zieltabelle in einer Abfrage.
  • Zeitlimit für Abfrageausführung: 6 Stunden
  • Maximale Slots für gleichzeitige Abfragen pro BigQuery-Projekt zu On-Demand-Preisen: 2.000
  • Maximale Anzahl von Tabellen, auf die pro Abfrage verwiesen wird: 1.000
  • Maximale Anzahl von autorisierten Ansichten pro Dataset: 1.000
  • Maximale ungelöste Abfragelänge: 256 KB
  • Maximale gelöste Abfragelänge: 12 MB einschließlich der Länge aller referenzierten Ansichten und Platzhaltertabellen
  • Maximale Antwortgröße: 128 MB komprimiert1 (unbegrenzt, wenn große Abfrageergebnismengen zurückgegeben werden)
    1 Die Größe variiert je nach Komprimierungsverhältnis der Daten. Die tatsächliche Antwortgröße ist möglicherweise deutlich größer als 128 MB.

Die Standardanzahl von Slots für On-Demand-Abfragen wird von allen Abfragen in einem Projekt geteilt. Als Faustregel gilt, dass es beim gleichzeitigen Ausführen von weniger als 100 GB Abfragen sehr unwahrscheinlich ist, 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 Pauschalpreise Ihrem Bedarf gerecht werden.

Dataset- und Tabellenaktualisierungsvorgänge

Die folgenden Limits gelten für Dataset- und Tabellenaktualisierungsvorgänge:

Anweisungen der Datenbearbeitungssprache

Die folgenden Limits gelten für die Datenbearbeitungssprache (DML).

  • Maximale UPDATE-/DELETE-Anweisungen pro Tag und Tabelle: 96
  • Maximale UPDATE-/DELETE-Anweisungen pro Tag und Projekt: 1.000
  • Maximale INSERT-Anweisungen pro Tag und Tabelle: 1.000
  • Maximale INSERT-Anweisungen pro Tag und Projekt: 1.000

Die Verarbeitung von DML-Anweisungen ist wesentlich teurer als die Verarbeitung von SELECT-Anweisungen.

Ladejobs

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

  • Tageslimit: 1.000 Ladejobs pro Tabelle pro Tag (einschließlich Fehler), 50.000 Ladejobs pro Projekt pro Tag (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 10 MB (Zeilen- und Zellengröße)
    JSON 10 MB (Zeilengröße)
    Avro 16 MB (Blockgröße)
  • Maximale Spalten pro Tabelle: 10.000
  • Maximale Dateigröße:
    Dateityp Komprimiert Unkomprimiert
    CSV 4 GB
    • Mit Zeilenvorschüben in Anführungszeichen in Werten: 4 GB
    • Ohne Zeilenvorschübe in Werten: 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: 10 Millionen Dateien gesamt entsprechend sämtlichen Platzhaltern
  • Zeitlimit für die Ausführung von Ladejobs: 6 Stunden

Weitere Informationen zu den von BigQuery unterstützten Datenformaten finden Sie unter Daten für BigQuery vorbereiten.

Kopierjobs

Die folgenden Limits gelten für das Kopieren von Tabellen in BigQuery.

  • Tageslimit: 1.000 Kopierjobs pro Tabelle (Kopierzieltabelle) pro Tag (einschließlich Fehler), 10.000 Kopierjobs pro Projekt (unter dem der Kopierjob ausgeführt wird) pro Tag (einschließlich Fehler).

Exportanforderungen

Die folgenden Limits gelten für das Exportieren von Daten aus BigQuery.

  • Tageslimit: 1.000 Exporte pro Tag bei einem kumulativen Limit von 10 TB pro Tag
  • Limit für mehrere Platzhalter-URIs: 500 URIs pro Export

Aktualisierungen partitionierter Tabellen

Die folgenden Limits gelten für partitionierte Tabellen.

  • Tageslimit: 2.000 Partitionsaktualisierungen pro Tabelle und Tag
  • Ratenlimit: 50 Partitionsaktualisierungen alle 10 Sekunden

Schreibvorgänge in eine Tabellenpartition aus Abfragejobs (einschließlich DML), Ladejobs und Kopierjobs werden auf die Limits für Partitionsaktualisierungen angerechnet.

Streaming von 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 invalid-Fehlern.
  • Größenlimit für HTTP-Anfragen: 10 MB. Ein Überschreiten dieses Wertes führt zu invalid-Fehlern.
  • Maximale Zeilen pro Sekunde: 100.000 Zeilen pro Sekunde und Projekt. Ein Überschreiten dieses Wertes erzeugt quotaExceeded-Fehler. Die maximale Anzahl von Zeilen pro Sekunde und Tabelle liegt ebenfalls bei 100.000. Sie können das gesamte Kontingent für eine Tabelle aufbrauchen oder es auf mehrere Tabellen in einem Projekt aufteilen.
  • Maximale Zeilen pro Anfrage: 10.000 Zeilen pro Anfrage. 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 Anfrage. Bei zu wenigen Zeilen pro Anfrage kann der Aufwand jeder Anfrage die Datenaufnahme ineffizient machen. Bei zu vielen Zeilen pro Anfrage sinkt möglicherweise der Durchsatz. Wir empfehlen ca. 500 Zeilen pro Anfrage, 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 mehr Streaming-Datenkontingente benötigen, verwenden Sie das Formular BigQuery – Benutzerdefinierte Kontingentanfrage. Im Allgemeinen erhalten Sie innerhalb von zwei bis drei Arbeitstagen eine Antwort.

API-Anfragen

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

Wann werden Kontingente aufgefüllt?

Tägliche Kontingente werden den 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.

Feedback geben zu...