Kontingente und Limits

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

  • Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Kontingente werden von Google Cloud-Diensten wie BigQuery definiert.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.

Das Cloud-Kontingentsystem ermöglicht Folgendes:

  • Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
  • Ihren Verbrauch dieser Ressourcen einschränken
  • Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern

Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.

Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Für BigQuery-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

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 die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.

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

Anleitung

Kontingentnutzung einschränken

Informationen zum Einschränken der Nutzung einer bestimmten Ressource durch Erstellen einer Kontingentüberschreibung finden Sie unter Kontingentüberschreibung erstellen.

Erforderliche Berechtigungen

Zum Anzeigen und Aktualisieren Ihrer BigQuery-Kontingente in der Google Cloud Console 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 Notes
Abfragenutzung pro Tag Unbegrenzt Die Anzahl der Byte, die von Abfragen in einem Projekt verarbeitet werden können, ist nicht begrenzt.
Kontingent in der Google Cloud 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 Google Cloud 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 Google Cloud Console ansehen
Cloudübergreifend übertragene Byte/Tag 1 TB Sie können pro Tag bis zu 1 TB Daten von einem Amazon S3-Bucket oder von einem Azure Blob Storage übertragen. Weitere Informationen finden Sie unter Cloudübergreifende Übertragung von Amazon S3 und Azure.
Kontingent in der Google Cloud 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 Notes
Maximale Anzahl interaktiver Abfragen in der Warteschlange 1.000 Abfragen Ihr Projekt kann bis zu 1.000 interaktive Abfragen in die Warteschlange stellen. Bei zusätzlichen interaktiven Abfragen, die dieses Limit überschreiten, wird ein Kontingentfehler zurückgegeben.
Maximale Anzahl von Batchabfragen in der Warteschlange 20.000 Abfragen Ihr Projekt kann bis zu 20.000 Batchabfragen in die Warteschlange stellen. Bei zusätzlichen Batchabfragen, die dieses Limit überschreiten, wird ein Kontingentfehler zurückgegeben.
Maximale Anzahl gleichzeitiger interaktiver Abfragen externer Bigtable-Datenquellen 16 Abfragen Mit dem Projekt können bis zu 16 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. Weitere Kontingente und Limits für Abfragen mit mehreren Anweisungen finden Sie unter Abfragen mit mehreren Anweisungen.
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 GoogleSQL-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, um die Abfragenutzung pro Tag oder die Abfragenutzung pro Tag und Nutzer zu steuern.
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 Google Cloud 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.

Das Zeitlimit für den Job CREATE MODEL ist standardmäßig auf 24 Stunden festgelegt, mit Ausnahme von Zeitachsen, AutoML- und Hyperparameter-Abstimmungsjobs, die nach 72 Stunden abgelaufen sind.
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 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.
Maximale Länge von SQL-Abfragezeichen 1.024.000 Zeichen Eine SQL-Abfrage kann bis zu 1.024.000 Zeichen lang sein. Dieses Limit umfasst Kommentare und Leerzeichen. 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 und eine lange Abfrage in mehrere Abfragen in der Sitzung.
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 GoogleSQL-Abfragen 1 MB Eine ungelöste GoogleSQL-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 GoogleSQL-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 GoogleSQL-Abfrageparametern 10.000 Parameter Eine GoogleSQL-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. Dazu gehören auch verschachtelte und wiederkehrende Spalten.
Maximale Anzahl gleichzeitiger Slots für On-Demand-Preise 2.000 Slots pro Projekt

20.000 Slots pro Organisation 		Bei On-Demand-Preisen kann Ihr Projekt bis zu 2.000 Slots gleichzeitig ausführen. Außerdem ist die Anzahl der gleichzeitigen Slots auf Organisationsebene auf 20.000 begrenzt. BigQuery versucht, Slots innerhalb einer Organisation fair auf die Projekte aufzuteilen, wenn die Gesamtnachfrage mehr als 20.000 Slots beträgt. 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.
Mutationen einer Transaktionstabelle mit Mehrfachanweisungen 100 Tabellen Eine Transaktion kann Daten in maximal 100 Tabellen mutieren.
Änderungen der Transaktionspartition mit mehreren Anweisungen 100.000 Partitionsänderungen Eine Transaktion kann maximal 100.000 Partitionsänderungen ausführen.
Maximale Größe von Abfrageergebnissen in BigQuery Omni 20 GiB unkomprimiert Die maximale Ergebnisgröße beträgt 20 GiB logische Bytes, wenn Azure- oder AWS-Daten abgefragt werden. Wenn das Abfrageergebnis größer als 20 GiB ist, sollten Sie die Ergebnisse nach Amazon S3 oder Blob Storage exportieren. Weitere Informationen finden Sie unter BigQuery Omni-Limits.
Gesamtgröße der BigQuery Omni-Abfrageergebnisse pro Tag 1 TB Die Gesamtgröße der Abfrageergebnisse für ein Projekt beträgt 1 TB pro Tag. Weitere Informationen finden Sie unter BigQuery Omni-Limits.
Maximale Zeilengröße in BigQuery Omni 10 MiB Die maximale Zeilengröße beträgt 10 MiB, wenn Daten aus Azure oder AWS abgefragt werden. Weitere Informationen finden Sie unter BigQuery Omni-Limits.

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 Google Cloud Console oder die API-Methode jobs.insert (Typ „export“) verwendet wird.

Limit Standard Notes
Maximale Anzahl exportierter Byte pro Tag 50 TiB Mit dem freigegebenen Slot-Pool können Sie bis zu 50 TiB(Tebibyte) Daten pro Tag kostenlos aus einem Projekt exportieren. Sie können eine Cloud Monitoring-Benachrichtigungsrichtlinie einrichten, die Sie über die Anzahl der exportierten Bytes benachrichtigt. Führen Sie einen der folgenden Schritte aus, um mehr als 50 TiB Daten pro Tag zu exportieren:
Maximale Anzahl von Exportjobs pro Tag 100.000 Exporte Sie können bis zu 100.000 Exporte pro Tag in einem Projekt ausführen. Führen Sie einen der folgenden Schritte aus, um mehr als 100.000 Exporte pro Tag auszuführen:
Maximale Tabellengröße, die in eine einzelne Datei exportiert wird 1 GB Sie können in einer Datei bis zu 1 GB Tabellendaten exportieren. Wenn Sie mehr als 1 GB Daten exportieren möchten, verwenden Sie einen Platzhalter, um die Daten in mehrere Dateien zu exportieren. Wenn Sie Daten in mehrere Dateien exportieren, kann die Größe der Dateien variieren. In einigen Fällen beträgt die Größe der Ausgabedateien mehr als 1 GB.
Platzhalter-URIs pro Export 500 URIs Ein Export kann bis zu 500 Platzhalter-URIs enthalten.

Weitere Informationen zur Anzeige der aktuellen Nutzung von Exportjobs finden Sie unter Aktuelle Kontingentnutzung aufrufen.

Ladejobs

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

Limit Standard Notes
Ladejobs pro Tabelle und Tag 1.500 Jobs 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 wird alle 24 Stunden mit einem Kontingent von maximal 100.000 Ladejobs aufgefüllt. Fehlgeschlagene Ladejobs werden auf dieses Limit angerechnet. In einigen Fällen ist es möglich, mehr als 100.000 Ladejobs innerhalb von 24 Stunden auszuführen, wenn das Kontingent des Vortags nicht vollständig genutzt wurde.
Maximale Anzahl von Spalten pro Tabelle 10.000 Spalten Eine Tabelle kann bis zu 10.000 Spalten enthalten. Dazu gehören auch verschachtelte und wiederkehrende Spalten.
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.
Maximale Anzahl von Dateien im Cloud Storage-Quell-Bucket ca. 60.000.000 Dateien Ein Ladejob kann aus einem Cloud Storage-Bucket mit bis zu ca. 60.000.000 Dateien lesen.
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.
Durch Zeilenumbruch getrenntes JSON (ndJSON): Maximale Zeilengröße 100 MB ndJSON-Zeilen können bis zu 100 MB groß sein.
ndJSON: Maximale Dateigröße – komprimiert 4 GB Das Größenlimit für eine komprimierte ndJSON-Datei beträgt 4 GB.
ndJSON: Maximale Dateigröße – unkomprimiert 5 TB Das Größenlimit für eine unkomprimierte ndJSON-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.

Informationen zur Anzeige der aktuellen Nutzung von Ladejobs finden Sie unter Aktuelle Kontingentnutzung aufrufen.

Kontingente für BigQuery Data Transfer Service-Ladejobs

Durch BigQuery Data Transfer Service-Übertragungen erstellte Ladejobs werden auf die BigQuery-Kontingente für Ladejobs angerechnet. Planen Sie sorgfältig, wie viele Übertragungen Sie in jedem Projekt auswählen, um zu verhindern, dass Übertragungen und andere Ladejobs zum Fehler quotaExceeded führen.

Mit der folgenden Gleichung können Sie die für Ihre Übertragungen erforderliche Anzahl von Ladejobs schätzen.

Number of daily jobs = Number of transfers x Number of tables x Schedule frequency x Refresh window

Dabei gilt:

  • Number of transfers ist die Anzahl der Übertragungskonfigurationen, die Sie in Ihrem Projekt aktivieren.

  • Number of tables ist die Anzahl der Tabellen, die durch jede einzelne Übertragungsart erstellt werden. Die Anzahl der Tabellen variiert je nach Übertragungsart:

    • Bei Campaign Manager-Übertragungen werden etwa 25 Tabellen erstellt.
    • Bei Google Ads-Übertragungen werden etwa 60 Tabellen erstellt.
    • Bei Google Ad Manager-Übertragungen werden etwa 40 Tabellen erstellt.
    • Bei Google Play-Übertragungen werden etwa 25 Tabellen erstellt.
    • Bei Search Ads 360-Übertragungen werden etwa 50 Tabellen erstellt.
    • Bei YouTube-Übertragungen werden etwa 50 Tabellen erstellt.

  • Schedule frequency beschreibt, wie oft Übertragungen ausgeführt werden. Zu jeder Übertragungsart sind Übertragungszeitpläne verfügbar:

  • Refresh window ist die Anzahl der in die Datenübertragung einzubeziehenden Tage. Wenn Sie 1 eingeben, wird kein täglicher Backfill durchgeführt.

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 Google Cloud Console, dem bq-Befehlszeilentool oder der Methode jobs.insert erstellt wurden, die das copy-Feld in der Jobkonfiguration angibt. Kopierjobs werden auf diese Limits angerechnet, unabhängig davon, ob sie erfolgreich sind.

Limit Standard Notes
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.
Anzahl der zu kopierenden Quelltabellen 1.200 Quelltabellen Sie können bis zu 1.200 Quelltabellen pro Kopierjob kopieren.

Informationen zur aktuellen Nutzung von Kopierjobs finden Sie unter Kopierjobs – Aktuelle Kontingentnutzung aufrufen.

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

Limit Standard Notes
Maximale Anzahl von Tabellen im Quell-Dataset 25.000 Tabellen Ein Quell-Dataset kann bis zu 25.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 maximal 20.000 Tabellen pro Ausführung in ein Ziel-Dataset innerhalb derselben Region kopieren. Wenn ein Quelldatensatz mehr als 20.000 Tabellen enthält, plant der BigQuery Data Transfer Service sequenzielle Ausführungen, bei denen jeweils bis zu 20.000 Tabellen kopiert werden, bis alle Tabellen kopiert sind. Diese Ausführungen sind durch ein standardmäßiges Intervall von 24 Stunden voneinander getrennt, das Nutzer auf ein Minimum von 12 Stunden anpassen können.
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 maximal 1.000 Tabellen pro Ausführung in ein Ziel-Dataset in einer anderen Region kopieren. Wenn ein Quelldatensatz mehr als 1.000 Tabellen enthält, plant der BigQuery Data Transfer Service sequenzielle Ausführungen, bei denen jeweils bis zu 1.000 Tabellen kopiert werden, bis alle Tabellen kopiert sind. Diese Ausführungen sind durch ein standardmäßiges Intervall von 24 Stunden voneinander getrennt, das Nutzer auf ein Minimum von 12 Stunden anpassen können.

Reservierungen

Die folgenden Kontingente gelten für Reservierungen:

Kontingent Standard Notes
Gesamtzahl der Slots für die EU-Region 5.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 Google Cloud Console ansehen
Gesamtzahl der Slots für die US-Region 10.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 Google Cloud Console ansehen
Gesamtzahl der Slots für die us-east1-Region 4.000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der aufgelisteten Region über die Google Cloud Console erwerben können.
Kontingente in der Google Cloud Console ansehen
Gesamtzahl der Slots für die folgenden Regionen:
  • asia-south1
  • asia-southeast1
  • europe-west2
  • us-central1
  • us-west1
 2.000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in den einzelnen Regionen mit der Google Cloud Console erwerben können.
Kontingente in der Google Cloud Console ansehen
Gesamtzahl der Slots für die folgenden Regionen:
  • asia-east1
  • asia-northeast1
  • asia-northeast3
  • asia-southeast2
  • australia-southeast1
  • europe-north1
  • europe-west1
  • europe-west3
  • europe-west4
  • northamerica-northeast1
  • us-east4
  • southamerica-east1
 1.000 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in den einzelnen Regionen mit der Google Cloud Console erwerben können.
Kontingente in der Google Cloud Console ansehen
Gesamtzahl der Slots für BigQuery Omni-Regionen 100 Slots Die maximale Anzahl von BigQuery-Slots, die Sie in der Google Cloud Console in den BigQuery Omni-Regionen erwerben können.
Kontingente in der Google Cloud 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 Google Cloud Console ansehen

Für reservations gelten die folgenden Limits:

Limit Wert Notes
Anzahl der Administrationsprojekte für Slot-Reservierungen 5 Projekte pro Organisation Die maximale Anzahl von Projekten innerhalb einer Organisation, die eine Reservierung oder eine aktive Zusicherung für Slots für einen bestimmten Standort / eine Region enthalten kann.
Maximale Anzahl an Standardreservierungen 10 Reservierungen pro Projekt Die maximale Anzahl von Reservierungen der Standardversion pro Administrationsprojekt innerhalb einer Organisation für einen bestimmten Standort / eine bestimmte Region.
Maximale Anzahl an Reservierungen für Enterprise oder Enterprise Plus 200 Reservierungen pro Projekt Die maximale Anzahl von Reservierungen für Enterprise oder Enterprise Plus pro Administrationsprojekt innerhalb einer Organisation für einen bestimmten Standort / eine bestimmte Region.
Maximale Anzahl von Slots in einer Reservierung, die einer Reservierungszuweisung mit dem Jobtyp CONTINUOUS zugeordnet ist. 500 Slots Wenn Sie eine Reservierungszuweisung mit dem Jobtyp CONTINUOUS erstellen möchten, darf die zugehörige Reservierung nicht mehr als 500 Slots haben.

Datasets

Für BigQuery-Datasets gelten die folgenden Limits:

Limit Standard Notes
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 Google Cloud 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 Notes
Maximale Länge eines Spaltennamens 300 Zeichen Der Spaltenname darf maximal 300 Zeichen lang sein.
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.
Maximale Länge einer Tabellenbeschreibung 16.384 Zeichen Für die Beschreibung einer Tabelle dürfen Sie höchstens 16.384 Zeichen verwenden.

Standardtabellen

Die folgenden Limits gelten für Standard Tabellen (integrierte) von BigQuery:

Limit Standard Notes
Tabellenänderungen pro Tag 1,500 Änderungen

Ihr Projekt kann bis zu 1.500 Tabellenänderungen pro Tabelle und Tag vornehmen, unabhängig davon, ob durch die Änderung Tabellenmetadaten aktualisiert, Daten angefügt oder aktualisiert oder die Tabelle gekürzt werden. Dieses Limit kann nicht geändert werden und enthält die Gesamtzahl aller Ladejobs, Kopierjobs und Abfragejobs, die an eine Zieltabelle angefügt werden oder diese überschreiben.

DML-Anweisungen werden nicht auf die Anzahl der Tabellenänderungen pro Tag angerechnet.

Streamingdaten werden nicht auf die Anzahl der Tabellenänderungen pro Tag angerechnet.
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 die Gesamtsumme aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen, eine Zieltabelle überschreiben oder eine DML-Anweisung DELETE, INSERT, MERGE, TRUNCATE TABLE oder UPDATE verwenden, um Daten in eine Tabelle zu schreiben. Beachten Sie, dass DML-Anweisungen zwar auf dieses Limit angerechnet werden, sie jedoch nicht unterliegen, wenn sie erreicht werden. Für DML-Vorgänge gelten dedizierte Ratenbegrenzungen.

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. Informationen zum Diagnostizieren und Beheben dieses Fehlers finden Sie unter Kontingentfehler beheben.

Maximale Anzahl von Spalten pro Tabelle 10.000 Spalten Jede Tabelle, jedes Abfrageergebnis und jede Ansichtsdefinition kann bis zu 10.000 Spalten enthalten. Dazu gehören verschachtelte und wiederkehrende Spalten.

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 Notes
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.
Maximale Anzahl von Dateien im Cloud Storage-Quell-Bucket ca. 60.000.000 Dateien Eine externe Tabelle kann auf einen Cloud Storage-Bucket mit bis zu etwa 60.000.000 Dateien verweisen. Bei extern partitionierten Tabellen tritt dieses Limit vor der Partitionsbereinigung in Kraft.

Partitionierte Tabellen

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

Die Partitionslimits gelten für die Gesamtzahl aller Ladejobs, Kopierjobs und Abfragejobs die an eine Zielpartition angehängt werden oder diese überschrieben.

Ein einzelner Job kann sich auf mehrere Partitionen auswirken. So können beispielsweise Abfrage- und Ladejobs in mehrere Partitionen schreiben.

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 Notes
Anzahl der Partitionen pro partitionierter Tabelle 10.000 Partitionen Eine partitionierte Tabelle kann bis zu 10.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 während der Aufnahme pro partitionierter Tabelle pro Tag 11.000 Änderungen

Ihr Projekt kann bis zu 11.000 Partitionsänderungen pro Tag vornehmen, unabhängig davon, ob durch die Änderung Daten angefügt, Daten aktualisiert oder eine nach Aufnahmezeit partitionierte Tabelle gekürzt wird.

DML-Anweisungen werden nicht auf die Anzahl der Partitionsänderungen pro Tag angerechnet.

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.

DML-Anweisungen werden nicht auf die Anzahl der Partitionsänderungen pro Tag angerechnet.

Streamingdaten werden nicht auf die Anzahl der Partitionsänderungen pro Tag angerechnet.
Maximale Aktualisierungsrate für Tabellenmetadaten pro partitionierter Tabelle 50 Änderungen pro 10 Sekunden Ihr Projekt kann alle 10 Sekunden bis zu 50 Änderungen pro partitionierter Tabelle ausführen. Dieses Limit gilt für alle Aktualisierungsvorgänge für Tabellenmetadaten, die durch Folgendes ausgeführt werden: Dieses Limit umfasst die Gesamtsumme aller Ladejobs, Kopierjobs und Abfragejobs, die Daten an eine Zieltabelle anfügen, eine Zieltabelle überschreiben oder eine DML-Anweisung DELETE, INSERT, MERGE, TRUNCATE TABLE oder UPDATE verwenden, um Daten in eine Tabelle zu schreiben.

Wenn Sie dieses Limit überschreiten, erhalten Sie eine Fehlermeldung wie Exceeded rate limits: too many partitioned 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.

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.

Tabellenklone

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

Limit Standard Notes
Maximale Anzahl von Klonen und Snapshots in einer Kette 3 Tabellenklone oder Snapshots Klone und Snapshots in Kombination sind auf eine maximale Klontiefe von 3 begrenzt. Wenn Sie eine Basistabelle klonen oder davon einen Snapshot erstellen, können Sie das Ergebnis nur zweimal klonen bzw. einen Snapshot erstellen. Der Versuch, das Ergebnis zum dritten Mal zu klonen oder einen Snapshot zu erstellen, führt zu einem Fehler. Sie können beispielsweise Klon A der Basistabelle, Snapshot B von Klon A und Klon C von Snapshot B erstellen. Wenn Sie weitere Duplikate des Klons oder Snapshots der dritten Ebene erstellen möchten, verwenden Sie stattdessen einen Kopiervorgang.
Maximale Anzahl von Klonen und Snapshots für eine Basistabelle 1.000 Tabellenklone oder ‑Snapshots Sie können von einer bestimmten Basistabelle nicht mehr als 1.000 vorhandene Klone und Snapshots in Kombination haben. Wenn Sie beispielsweise 600 Snapshots und 400 Klone haben, wird das Limit erreicht.

Tabellen-Snapshots

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

Limit Standard Notes
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 Tabellen-Snapshot-Jobs pro Tabelle und Tag 50 Jobs Ihr Projekt kann bis zu 50 Tabellen-Snapshot-Jobs pro Tabelle und Tag 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.
Maximale Anzahl von Klonen und Snapshots in einer Kette 3 Tabellenklone oder Snapshots Klone und Snapshots in Kombination sind auf eine maximale Klontiefe von 3 begrenzt. Wenn Sie eine Basistabelle klonen oder davon einen Snapshot erstellen, können Sie das Ergebnis nur zweimal klonen bzw. einen Snapshot erstellen. Der Versuch, das Ergebnis zum dritten Mal zu klonen oder einen Snapshot zu erstellen, führt zu einem Fehler. Sie können beispielsweise Klon A der Basistabelle, Snapshot B von Klon A und Klon C von Snapshot B erstellen. Wenn Sie weitere Duplikate des Klons oder Snapshots der dritten Ebene erstellen möchten, verwenden Sie stattdessen einen Kopiervorgang.
Maximale Anzahl von Klonen und Snapshots für eine Basistabelle 1.000 Tabellenklone oder ‑Snapshots Sie können von einer bestimmten Basistabelle nicht mehr als 1.000 vorhandene Klone und Snapshots in Kombination haben. Wenn Sie beispielsweise 600 Snapshots und 400 Klone haben, wird das Limit erreicht.

Aufrufe

Die folgenden Kontingente und Limits gelten für Ansichten und materialisierte Ansichten.

Logische Ansichten

Für BigQuery-Standardtansichten gelten die folgenden Limits:

Limit Standard Notes
Maximale Anzahl verschachtelter Ansichtsebenen 16 Ebenen BigQuery unterstützt bis zu 16 Ebenen verschachtelter Ansichten. Es ist möglich, Ansichten bis zu diesem Limit zu erstellen. Die Abfrage ist jedoch auf 15 Ebenen beschränkt. Wenn das Limit überschritten wird, gibt BigQuery den Fehler INVALID_INPUT zurück.
Maximale Länge einer GoogleSQL-Abfrage, die zur Definition einer Ansicht verwendet wird 256.000 Zeichen Eine einzelne GoogleSQL-Abfrage, die eine Ansicht definiert, kann bis zu 256.000 Zeichen lang sein. Dieses Limit gilt für eine einzelne Abfrage und schließt die Länge der in der Abfrage referenzierten Ansichten nicht ein.
Maximale Anzahl von autorisierten Ansichten pro Dataset Siehe Datasets.
Maximale Länge einer Datenansichtsbeschreibung 16.384 Zeichen Für die Beschreibung einer Ansicht dürfen Sie höchstens 16.384 Zeichen verwenden.

Materialisierte Ansichten

Die folgenden Limits gelten für materialisierte Ansichten in BigQuery:

Limit Standard Notes
Basistabellenreferenzen (gleiches Dataset) 20 Materialisierte Ansichten Auf jede Basistabelle kann von bis zu 20 materialisierten Ansichten aus demselben Dataset verwiesen werden.
Basistabellenreferenzen (gleiches Projekt) 100 Materialisierte Ansichten Jede Basistabelle kann von bis zu 100 materialisierten Ansichten aus demselben Projekt referenziert werden.
Verweise auf Basistabellen (gesamte Organisation) 500 Materialisierte Ansichten Jede Basistabelle kann von bis zu 500 materialisierten Ansichten aus der gesamten Organisation referenziert werden.
Maximale Anzahl von autorisierten Ansichten pro Dataset Siehe Datasets.
Maximale Länge einer Beschreibung einer materialisierten Ansicht 16.384 Zeichen Für die Beschreibung einer materialisierten Ansicht dürfen Sie höchstens 16.384 Zeichen verwenden.

Suchindexe

Die folgenden Limits gelten für BigQuery-Suchindexe:

Limit Standard Notes
Anzahl der CREATE INDEX-DDL-Anweisungen pro Projekt, Region und Tag 500 Vorgänge Ihr Projekt kann bis zu 500 CREATE INDEX-DDL-Vorgänge pro Tag in einer Region ausführen.
Anzahl der Suchindex-DDL-Anweisungen pro Tabelle und Tag 20 Vorgänge Ihr Projekt kann bis zu 20 CREATE INDEX- oder DROP INDEX-DDL-Vorgänge pro Tabelle und Tag ausführen.
Maximale Gesamtgröße der Tabellendaten pro Organisation, die für die Suchindexerstellung zulässig sind und nicht in einer Reservierung ausgeführt werden 100 TB in Mehrfachregionen 20 TB in allen anderen Regionen Sie können einen Suchindex für eine Tabelle erstellen, wenn die Gesamtgröße der Tabellen mit Indexen in Ihrer Organisation unter dem Limit Ihrer Region liegt: 100 TB für die Mehrfachregionen US und EU und 20 TB für alle anderen Regionen. Wenn Ihre Indexverwaltungsjobs in Ihrer eigenen Reservierung ausgeführt werden, gilt dieses Limit nicht.

Vektorindexe

Für BigQuery-Vektorindexe gelten die folgenden Limits:

Limit Standard Notes
Mindestanzahl von Zeilen der Basistabelle 5.000 Zeilen Eine Tabelle muss mindestens 5.000 Zeilen enthalten,um einen Vektorindex zu erstellen.
Maximale Anzahl von Zeilen für die Basistabelle 10.000.000.000 Zeilen für den Indextyp IVF

200.000.000 Zeilen für den Indextyp TREE_AH		 Eine Tabelle kann maximal 10.000.000.000 Zeilen enthalten, um einen IVF-Vektorindex zu erstellen, und 200.000.000 Zeilen, um einen TREE_AH-Vektorindex zu erstellen.
Maximale Größe des Arrays in der indexierten Spalte 1.600 Elemente Die zu indexierende Spalte kann höchstens 1.600 Elemente im Array enthalten.
Minimale Tabellengröße für die Population des Vektorindex 10 MB Wenn Sie einen Vektorindex für eine Tabelle erstellen, die kleiner als 10 MB ist, wird der Index nicht ausgefüllt. Wenn Sie Daten aus einer vektorindexierten Tabelle löschen, sodass die Tabellengröße weniger als 10 MB beträgt, wird der Vektorindex ebenfalls vorübergehend deaktiviert. Dies geschieht unabhängig davon, ob Sie Ihre eigene Reservierung für Ihre Indexverwaltungsjobs verwenden. Sobald die Größe einer vektorindexierten Tabelle wieder 10 MB überschreitet, wird der Index automatisch ausgefüllt.
Anzahl der CREATE VECTOR INDEX-DDL-Anweisungen pro Projekt, Region und Tag 500 Vorgänge Für jedes Projekt können Sie bis zu 500 CREATE VECTOR INDEX-Vorgänge pro Tag für jede Region ausführen.
Anzahl der Vektorindex-DDL-Anweisungen pro Tabelle und Tag 10 Vorgänge Sie können bis zu 10 CREATE VECTOR INDEX- oder DROP VECTOR INDEX-Vorgänge pro Tabelle und Tag ausführen.
Maximale Gesamtgröße der Tabellendaten pro Organisation, die für die Vektorindexerstellung zulässig sind und nicht in einer Reservierung ausgeführt werden 6 TB Sie können einen Vektorindex für eine Tabelle erstellen, wenn die Gesamtgröße der Tabellen mit Indexen in Ihrer Organisation unter 6 TB liegt. Wenn Ihre Indexverwaltungsjobs in Ihrer eigenen Reservierung ausgeführt werden, gilt dieses Limit nicht.

Routinen

Die folgenden Kontingente und Limits gelten für Routinen.

Benutzerdefinierte Funktionen

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

Limit Standard Notes
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. Dieses Limit gilt nicht für GoogleSQL-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 Notes
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 Notes
Maximale Anzahl gleichzeitiger Abfragen, die Remotefunktionen enthalten 10 Abfragen Sie können bis zu zehn Abfragen gleichzeitig mit Remotefunktionen pro Projekt ausführen.
Maximale Eingabegröße 5 MB Die maximale Gesamtgröße aller Eingabeargumente aus einer einzelnen Zeile beträgt 5 MB.
Größenlimit für HTTP-Antworten (Cloud Run-Funktionen der 1. Generation) 10 MB Der HTTP-Antworttextkörper von Ihrer Cloud Run-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 Run-Funktionen der 2. Generation oder Cloud Run) 15 MB Der HTTP-Antworttext von Ihrer Cloud Run-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 Run-Funktionen der 1. Generation) 9 Minuten Sie können für einen einzelnen HTTP-Aufruf ein eigenes Zeitlimit für Cloud Run-Funktionen der 1. Generation festlegen. Die maximale Zeit beträgt jedoch 9 Minuten. Das Überschreiten des für Ihre Cloud Run-Funktion der 1. Generation festgelegten Zeitlimits kann zu HTTP-Aufruffehlern und Abfragefehlern führen.
Zeitlimit für HTTP-Aufruf (Cloud Run-Funktionen der 2. Generation oder Cloud Run) 20 Minuten Das Zeitlimit für einen einzelnen HTTP-Aufruf an Ihre Cloud Run-Funktion der 2. Generation oder Cloud Run. Das Überschreiten dieses Wertes kann zu HTTP-Aufruffehlern und Abfragefehlern führen.
Maximale Anzahl an Wiederholungsversuchen für HTTP-Aufrufe 20 Die maximale Anzahl von Wiederholungsversuchen für einen einzelnen HTTP-Aufruf an Ihre Cloud Run-Funktion der 1. Generation, 2. Generation oder Cloud Run. Das Überschreiten dieses Wertes kann zu HTTP-Aufruffehlern und Abfragefehlern führen.

Tabellenfunktionen

Die folgenden Limits gelten für Tabellenfunktionen von BigQuery:

Limit Standard Notes
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.

Gespeicherte Prozeduren für Apache Spark

Für gespeicherte BigQuery-Prozeduren für Apache Spark gelten die folgenden Limits:

Limit Default Hinweise
Maximale Anzahl gleichzeitiger gespeicherter Prozedurabfragen 50 Sie können für jedes Projekt bis zu 50 gleichzeitig gespeicherte Prozedurabfragen ausführen.
Maximale Anzahl verwendeter CPUs 12.000 Sie können für jedes Projekt bis zu 12.000 CPUs verwenden. Abfragen, die bereits verarbeitet wurden, nutzen dieses Limit nicht.

Sie können bis zu 2.400 CPUs für jeden Standort für jedes Projekt verwenden, mit Ausnahme der folgenden Standorte:

  • asia-south2
  • australia-southeast2
  • europe-central2
  • europe-west8
  • northamerica-northeast2
  • southamerica-west1

An diesen Standorten können Sie bis zu 500 CPUs für jeden Standort und jedes Projekt verwenden.

Wenn Sie gleichzeitige Abfragen an einem Standort mit mehreren Regionen und an einem einzelnen Standort mit derselben Region ausführen, verbrauchen Ihre Abfragen möglicherweise dasselbe CPU-Kontingent.
Maximale Gesamtgröße der verwendeten nichtflüchtigen Standardspeicher 204,8 TB

Sie können für jeden Standort und jedes Projekt bis zu 204,8 TB nichtflüchtige Standardspeicher verwenden. Abfragen, die bereits verarbeitet wurden, nutzen dieses Limit nicht.

Wenn Sie gleichzeitige Abfragen an einem Standort mit mehreren Regionen und an einem einzelnen Standort in derselben geografischen Region ausführen, verbrauchen Ihre Abfragen möglicherweise dasselbe Kontingent für nichtflüchtige Standardspeicher.

Notebooks

Alle Dataform-Kontingente und -Limits sowie Colab Enterprise-Kontingente und -Limits gelten für Notebooks in BigQuery. Darüber hinaus gelten die folgenden Limits:

Limit Default Notes
Maximale Notebookgröße 20 MB

Die Größe eines Notebooks setzt sich aus dem Inhalt, den Metadaten und dem Codierungsaufwand zusammen.

Sie können die Größe des Notebookinhalts anzeigen lassen. Maximieren Sie dazu den Notebookheader, klicken Sie auf Ansehen und dann auf Notebookinformationen.
Maximale Anzahl von Anfragen pro Sekunde an Dataform 100 Notebooks werden über Dataform erstellt und verwaltet. Jede Aktion, die ein Notebook erstellt oder ändert, wird auf dieses Kontingent angerechnet. Dieses Kontingent wird für gespeicherte Abfragen freigegeben. Wenn Sie beispielsweise 50 Änderungen an Notebooks und 50 Änderungen an gespeicherten Abfragen innerhalb einer Sekunde vornehmen, erreichen Sie das Kontingent.

Gespeicherte Abfragen

Alle Dataform-Kontingente und -Limits gelten für gespeicherte Abfragen. Darüber hinaus gelten die folgenden Limits:

Limit Default Notes
Maximale gespeicherte Abfragegröße 10 MB
Maximale Anzahl von Anfragen pro Sekunde an Dataform 100 Gespeicherte Abfragen werden über Dataform erstellt und verwaltet. Jede Aktion, die eine gespeicherte Abfrage erstellt oder ändert, wird auf dieses Kontingent angerechnet. Dieses Kontingent wird für Notebooks freigegeben. Wenn Sie beispielsweise 50 Änderungen an Notebooks und 50 Änderungen an gespeicherten Abfragen innerhalb einer Sekunde vornehmen, erreichen Sie das Kontingent.

Datenbearbeitungssprache

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

Limit Standard Notes
DML-Anweisungen pro Tag Unbegrenzt Die Anzahl der DML-Anweisungen, die Ihr Projekt pro Tag ausführen kann, ist unbegrenzt.

DML-Anweisungen werden nicht auf die Anzahl der Tabellenänderungen pro Tag oder die Anzahl der partitionierten Tabellenänderungen pro Tag für partitionierte Tabellen angerechnet.

Für DML-Anweisungen gelten die folgenden Beschränkungen.
Gleichzeitige INSERT-DML-Anweisungen pro Tabelle und Tag 1.500 Anweisungen Die ersten 1.500 INSERT-Anweisungen werden sofort nach ihrer Einreichung ausgeführt. Nachdem dieses Limit erreicht wurde, ist die Gleichzeitigkeit von INSERT-Anweisungen zum Schreiben in eine Tabelle auf 10 beschränkt. Zusätzliche INSERT-Anweisungen werden einer PENDING-Warteschlange hinzugefügt. Es können jeweils bis zu 100 INSERT-Anweisungen für eine Tabelle in die Warteschlange gestellt werden. Wenn eine INSERT-Anweisung abgeschlossen ist, wird die nächste INSERT-Anweisung aus der Warteschlange entfernt und ausgeführt.

Wenn Sie DML-INSERT-Anweisungen häufiger ausführen müssen, können Sie Daten mit der Storage Write API in Ihre Tabelle streamen.
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.
Maximale Rate von DML-Anweisungen pro Tabelle 25 Anweisungen alle 10 Sekunden Ihr Projekt kann alle 10 Sekunden bis zu 25 DML-Anweisungen pro Tabelle ausführen. Sowohl INSERT als auch sich ändernde DML-Anweisungen tragen zu diesem Limit bei.

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

Abfragen mit mehreren Anweisungen

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

Limit Standard Notes
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.
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.

Rekursive CTEs in Abfragen

Die folgenden Limits gelten für rekursive allgemeine Tabellenausdrücke (common table expressions, CTEs) in BigQuery.

Limit Standard Notes
Ausführungslimit 500 Iterationen Der rekursive CTE kann diese Anzahl von Iterationen ausführen. Wenn dieses Limit überschritten wird, wird ein Fehler erzeugt. Informationen zum Umgehen von Iterationslimits finden Sie unter Fehler bei Iterationslimits beheben.

Sicherheit auf Zeilenebene

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

Limit Default Anmerkungen
Maximale Anzahl von Zeilenzugriffsrichtlinien pro Tabelle 400 Richtlinien Eine Tabelle kann bis zu 400 Zeilenzugriffsrichtlinien enthalten.
Maximale Anzahl der Zeilenzugriffsrichtlinien pro Abfrage 6000 Richtlinien Eine Abfrage kann auf bis zu 6000 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.

Richtlinien für Daten

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

Limit Standard Notes
Maximale Anzahl von Datenrichtlinien pro Richtlinien-Tag. 8 Richtlinien pro Richtlinien-Tag Bis zu acht Datenrichtlinien pro Richtlinien-Tag. Eine dieser Richtlinien kann für die Zugriffssteuerung auf Spaltenebene verwendet werden. Doppelte Maskierungsausdrücke werden nicht unterstützt.

BigQuery ML

Für BigQuery ML gelten die folgenden Limits.

Abfragejobs

Alle Kontingente und Limits für Abfragejobs gelten für Google SQL-Abfragejobs, die BigQuery ML-Anweisungen und -Funktionen verwenden.

CREATE MODEL-Anweisungen

Die folgenden Limits gelten für CREATE MODEL-Jobs:

Limit Standard Notes
CREATE MODEL-Anweisungsabfragen pro 48 Stunden für jedes Projekt 20.000 Anweisungsabfragen Einige Modelle werden mit Vertex AI-Diensten trainiert, die eine eigene Ressourcen- und Kontingentverwaltung haben.
Ausführungszeitlimit 24 Stunden oder 72 Stunden Das Zeitlimit für den Job CREATE MODEL ist standardmäßig auf 24 Stunden festgelegt, mit Ausnahme von Zeitachsen, AutoML- und Hyperparameter-Abstimmungsjobs, die nach 72 Stunden abgelaufen sind.

Vertex AI- und Cloud AI-Dienstfunktionen

Für Funktionen, die Vertex AI Large Language Models (LLMs) und Cloud AI-Dienste verwenden, gelten die folgenden Limits:

Funktion Anfragen pro Minute Zeilen pro Job Anzahl gleichzeitig ausgeführter Jobs
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem gemini-1.5-pro-Modell 60 21.600 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem gemini-1.5-flash-Modell 200 72.000 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über dem Modell gemini-1.0-pro-vision in der Region us-central1 100 20.000 1
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells gegenüber dem Modell gemini-1.0-pro-vision in anderen Regionen als us-central1 10 3.600 1
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem gemini-1.0-pro-Modell in der Region us-central1 300 108.000 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem gemini-1.0-pro-Modell in anderen Regionen als us-central1 10 3.600 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem Anthropic Claude-Modell 30 10.800 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem text-bison-Modell 1.600 576.000 5
ML.GENERATE_TEXT bei Verwendung eines Remote-Modells über einem text-bison-32-Modell 300 108.000 5
ML.GENERATE_EMBEDDING bei Verwendung mit Remote-Modellen über Vertex AI multimodalembedding-Modelle in unterstützten europäischen Einzelregionen 120 14.000 5
ML.GENERATE_EMBEDDING bei Verwendung mit Remote-Modellen über Vertex AI multimodalembedding-Modelle in anderen Regionen als unterstützten europäischen Einzelregionen 600 25.000 5
ML.GENERATE_EMBEDDING bei Verwendung mit Remote-Modellen über Vertex AI-text-embedding- und text-multilingual-embedding-Modelle in der Region us-central1 1.500 2.700.000 1
ML.GENERATE_EMBEDDING bei Verwendung mit Remote-Modellen über Vertex AI-text-embedding- und text-multilingual-embedding-Modelle in anderen Regionen als der us-central1 100 324.000 1
ML.PROCESS_DOCUMENT mit durchschnittlich einer Seite pro Dokument 600 150.000 5
ML.PROCESS_DOCUMENT mit Dokumenten mit durchschnittlich zehn Seiten 600 100.000 5
ML.PROCESS_DOCUMENT mit Dokumenten mit durchschnittlich 50 Seiten 600 15.000 5
ML.TRANSCRIBE 200 10.000 5
ML.ANNOTATE_IMAGE 1.800 648.000 5
ML.TRANSLATE 6.000 2.160.000 5
ML.UNDERSTAND_TEXT 600 21.600 5

Weitere Informationen zum Kontingent für Vertex AI-LLMs und die Cloud AI-Dienst-APIs finden Sie in den folgenden Dokumenten:

Das Kontingent für Zeilen pro Job entspricht der höchsten theoretischen Anzahl von Zeilen, die das System innerhalb von sechs Stunden verarbeiten kann. Die tatsächliche Anzahl der verarbeiteten Zeilen hängt von vielen anderen Faktoren ab, z. B. von der Eingabegröße und der Netzwerkverbindung. ML.TRANSCRIBE kann beispielsweise mehr kurze Audios als lange Audios verarbeiten.

Wenn Sie ein höheres Kontingent für die BigQuery ML-Funktionen anfordern möchten, passen Sie zuerst das Kontingent für den zugehörigen Vertex AI LLM oder Cloud AI-Dienst an und senden Sie dann eine E-Mail an bqml-feedback@google.com und geben Sie Informationen zum angepassten LLM- oder Cloud AI-Dienstkontingent an. Weitere Informationen zum Anfordern eines höheren Kontingents für diese Dienste finden Sie unter Höheres Kontingent anfordern.

Kontingentdefinitionen

In der folgenden Liste sind die Kontingente für Vertex AI- und Cloud AI-Dienstfunktionen aufgeführt:

  • Für Funktionen, die ein Vertex AI-Basismodell aufrufen, wird ein Vertex AI-Kontingent in Form von Abfragen pro Minute (QPM) verwendet. In diesem Zusammenhang sind die Abfragen Anfragen von der Funktion an die API des Vertex AI-Modells. Das Kontingent für Abfragen pro Minute gilt für ein Basismodell und alle Versionen, Kennungen und abgestimmte Versionen dieses Modells. Weitere Informationen zu den Kontingenten für Vertex AI-Foundation-Modelle finden Sie unter Kontingente pro Region und Modell.
  • Für Funktionen, die einen Cloud AI-Dienst aufrufen, werden die Anfragequoten des Zieldienstes verwendet. Weitere Informationen finden Sie in der Kontingentreferenz des jeweiligen Cloud AI-Dienstes.

  • Für BigQuery ML gelten drei Kontingente:

    • Anfragen pro Minute. Dieses Kontingent ist die Obergrenze für die Anzahl der Anfrageaufrufe pro Minute, die Funktionen an die API des Vertex AI-Modells oder des Cloud AI-Dienstes senden können. Dieses Limit gilt für jedes Projekt.

      Bei Funktionen, die ein Vertex AI-Foundation-Modell aufrufen, hängt die Anzahl der Anfrageaufrufe pro Minute vom Vertex AI-Modellendpunkt, der Version und der Region ab. Dieses Kontingent entspricht konzeptionell dem von Vertex AI verwendeten QPM-Kontingent, kann aber einen niedrigeren Wert als das QPM-Kontingent für ein entsprechendes Modell haben.

    • Zeilen pro Job Dieses Kontingent ist die zulässige Anzahl von Zeilen für jeden Abfragejob.

    • Anzahl gleichzeitig ausgeführter Jobs Dieses Kontingent ist die Begrenzung pro Projekt für die Anzahl der SQL-Abfragen, die gleichzeitig für die jeweilige Funktion ausgeführt werden können.

Die folgenden Beispiele zeigen, wie Sie Kontingentbeschränkungen in typischen Situationen interpretieren:

  • Ich habe ein Kontingent von 1.000 Anfragen pro Minute in Vertex AI. Eine Abfrage mit 100.000 Zeilen sollte also etwa 100 Minuten dauern. Warum dauert die Ausführung des Jobs länger?

    Die Laufzeit von Jobs kann selbst bei denselben Eingabedaten variieren. In Vertex AI haben Remote-Prozeduraufrufe (RPCs) unterschiedliche Prioritäten, um einen übermäßigen Kontingentverbrauch zu vermeiden. Wenn das Kontingent nicht ausreicht, müssen RPCs mit niedrigerer Priorität warten und schlagen möglicherweise fehl, wenn die Verarbeitung zu lange dauert.

  • Wie sollte ich das Kontingent für Zeilen pro Job interpretieren?

    In BigQuery kann eine Abfrage bis zu sechs Stunden dauern. Die maximal unterstützte Anzahl von Zeilen hängt von diesem Zeitplan und Ihrem Vertex AI-QPM-Kontingent ab, damit die Abfrageverarbeitung in BigQuery innerhalb von sechs Stunden abgeschlossen werden kann. Da eine Abfrage in der Regel nicht das gesamte Kontingent nutzen kann, ist diese Zahl niedriger als das QPM-Kontingent multipliziert mit 360.

  • Was passiert, wenn ich einen Batch-Inferenzjob für eine Tabelle mit mehr Zeilen ausführe, als das Kontingent für Zeilen pro Job beträgt, z. B. 10.000.000 Zeilen?

    BigQuery verarbeitet nur die Anzahl der Zeilen, die durch das Kontingent „Zeilen pro Job“ angegeben ist. Ihnen werden nur die erfolgreichen API-Aufrufe für diese Anzahl von Zeilen in Rechnung gestellt, nicht die vollen 10.000.000 Zeilen in Ihrer Tabelle. Bei den übrigen Zeilen antwortet BigQuery mit einem A retryable error occurred: the maximum size quota per query has reached-Fehler, der in der Spalte status des Ergebnisses zurückgegeben wird. Sie können diese SQL-Skripts oder dieses Dataform-Paket verwenden, um Inferenzaufrufe zu iterieren, bis alle Zeilen erfolgreich verarbeitet wurden.

  • Ich muss viel mehr Zeilen verarbeiten, als das Kontingent für Zeilen pro Job beträgt. Hilft es, meine Zeilen auf mehrere Abfragen aufzuteilen und sie gleichzeitig auszuführen?

    Nein, da diese Abfragen dasselbe Kontingent für BigQuery-ML-Anfragen pro Minute und dasselbe QPM-Kontingent für Vertex AI nutzen. Wenn mehrere Abfragen das Kontingent für Zeilen pro Job und die Anzahl der gleichzeitig ausgeführten Jobs nicht überschreiten, wird durch die kumulative Verarbeitung das Kontingent für Anfragen pro Minute ausgeschöpft.

BI Engine

Für BigQuery BI Engine gelten die folgenden Limits.

Limit Standard Notes
Maximale Reservierungsgröße pro Projekt und Standort (SQL-Schnittstelle) 250 GiB Gilt für die Verwendung von BI Engine mit BigQuery. Gilt in allen Fällen außer Looker Studio ohne native Integration.

Sie können eine Erhöhung der maximalen Reservierungskapazität für Ihre Projekte anfordern. Reservierungserhöhungen sind in den meisten Regionen möglich und können zwischen 3 Tagen und einer Woche Bearbeitungszeit in Anspruch nehmen.
Maximale Anzahl von Zeilen pro Abfrage 7 Milliarden Maximale Anzahl von Zeilen pro Abfrage.

Analytics Hub

Die folgenden Limits gelten für Analytics Hub:

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

API-Kontingente und -Limits

Die Kontingente und Limits gelten für BigQuery API-Anfragen.

BigQuery API

Für BigQuery API-Anfragen (Kernanfragen) gelten die folgenden Kontingente:

Kontingent Standard Notes
Anfragen pro Tag Unbegrenzt Ihr Projekt kann eine unbegrenzte Anzahl von BigQuery API-Anfragen pro Tag stellen.
Kontingent in der Google Cloud Console ansehen
Höchstens tabledata.list Byte pro Minute 7,5 GB in Mehrfachregionen; 3,7 GB in allen anderen Regionen Ihr Projekt kann maximal 7,5 GB an Tabellenzeilendaten pro Minute über tabledata.list in den Mehrfachregionen us und eu und 3,7 GB an Tabellenzeilendaten pro Minute in allen anderen Regionen zurückgeben. Dieses Kontingent gilt für das Projekt, das die gelesene Tabelle enthält. 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 in der Google Cloud Console ansehen

Die BigQuery Storage Read API kann einen deutlich höheren Durchsatz als tabledata.list aufrechterhalten. Wenn Sie einen höheren Durchsatz als im Rahmen dieses Kontingents erlaubt benötigen, können Sie die BigQuery Storage Read API verwenden.

Die folgenden Limits gelten für BigQuery API-Anfragen (Kern):

Limit Standard Notes
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.
Maximale jobs.get-Anfragen pro Sekunde 1000 Anfragen Ihr Projekt kann bis zu 1000 jobs.get-Anfragen pro Sekunde senden.
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.
Maximale jobs.getQueryResults Zeilengröße 20 MB Die maximale Zeilengröße ist ein Näherungswert, da das Limit auf der internen Darstellung der Zeilendaten basiert. Das Limit wird während des Transcodierens erzwungen.
Maximale projects.list-Anfragen pro Sekunde 2 Anfragen Ihr Projekt kann bis zu zwei projects.list-Anfragen pro Sekunde senden.
Maximale Anzahl von tabledata.list-Anfragen pro Sekunde 1.000 Anfragen Ihr Projekt kann bis zu 1000 tabledata.list-Anfragen pro Sekunde senden.
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.
Maximale tabledata.list Zeilengröße 100 MB Die maximale Zeilengröße ist ein Näherungswert, da das Limit auf der internen Darstellung der Zeilendaten basiert. Das Limit wird während des Transcodierens erzwungen.
Maximale tables.insert-Anfragen pro Sekunde 10 Anfragen Ihr Projekt kann bis zu 10 tables.insert-Anfragen pro Sekunde senden. Mit der Methode tables.insert wird eine neue, leere Tabelle in einem Dataset erstellt. Dieses Limit umfasst SQL-Anweisungen, die Tabellen erstellen, z. B. CREATE TABLE, und Abfragen, bei denen Ergebnisse in Zieltabellen geschrieben werden.

BigQuery Connection API

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

Kontingent Standard Notes
Leseanfragen pro Minute 1000 Anfragen pro Minute Ihr Projekt kann bis zu 1.000 Anfragen pro Minute an BigQuery Connection API-Methoden senden, die Verbindungsdaten lesen.
Kontingent in der Google Cloud 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 Google Cloud Console ansehen
Erstellte BigQuery Omni-Verbindungen pro Minute 10 Verbindungen pro Minute erstellt Ihr Projekt kann insgesamt bis zu 10 BigQuery Omni-Verbindungen pro Minute für AWS und Azure erstellen.
BigQuery Omni-Verbindungsnutzung 100 Verbindungsnutzungen pro Minute Ihr Projekt kann eine BigQuery Omni-Verbindung bis zu 100-mal pro Minute verwenden. Dies gilt für Vorgänge, die Ihre Verbindung zu Ihrem AWS-Konto nutzen, um z. B. eine Tabelle abfragen.

BigQuery Migration API

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

Limit Standard Notes
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 zur Extraktion 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, darf 1 MB nicht überschreiten. Bei interaktiven Übersetzungen mit der Translation API gilt dieses Limit für die Gesamtgröße aller Stringeingaben.
Maximale Größe der Konfigurationsdatei für die interaktive SQL-Übersetzung 50 MB Einzelne Metadatendateien (komprimiert) und YAML-Konfigurationsdateien in Cloud Storage dürfen nicht größer als 50 MB sein. Wenn die Datei größer als 50 MB ist, überspringt der interaktive Übersetzer diese Konfigurationsdatei während der Übersetzung und erzeugt eine Fehlermeldung. Eine Möglichkeit, die Metadatendateigröße zu reduzieren, besteht darin, die Flags —database oder –schema zum filtern von Datenbanken zu verwenden, wenn Sie die Metadaten generieren .

Die folgenden Kontingente gelten für die BigQuery Migration API. In den meisten Fällen gelten die folgenden Standardwerte. Die Standardeinstellungen für Ihr Projekt können abweichen:

Kontingent Standard Notes

EDWMigration Service-List-Anfragen pro Minute

EDWMigration Service-List-Anfragen pro Minute und Nutzer

12.000 Anfragen

2.500 Anfragen

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

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

Kontingente in der Google Cloud Console ansehen

EDWMigration Service-Get-Anfragen pro Minute

EDWMigration Service-Get-Anfragen pro Minute und Nutzer

25.000 Anfragen

2.500 Anfragen

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

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

Kontingente in der Google Cloud Console ansehen

Weitere EDWMigration Service-Anfragen pro Minute

Weitere EDWMigration Service-Anfragen pro Minute und Nutzer

25 Anfragen

5 Anfragen

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

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

Kontingente in der Google Cloud Console ansehen

Interaktive SQL-Übersetzungsanfragen pro Minute

Interaktive SQL-Übersetzungsanfragen pro Minute und Nutzer

200 Anfragen

50 Anfragen

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

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

Kontingente in der Google Cloud Console ansehen

BigQuery Reservation API

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

Kontingent Standard Notes
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 Google Cloud 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 Google Cloud 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 Google Cloud Console ansehen
(Suchen Sie in den Suchergebnissen der Google Cloud Console nach pro Nutzer.)

BigQuery DataPolicy API

Die folgenden Limits gelten für die Data Policy API (Vorschau):

Limit Standard Notes
Maximale Anzahl von dataPolicies.list-Aufrufen 400 Anfragen pro Minute pro Projekt

600 Anfragen pro Minute pro Organisation
Maximale Anzahl von dataPolicies.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 dataPolicies.get und dataPolicies.getIamPolicy.
Maximale Anzahl Schreibanfragen. 600 Anfragen pro Minute pro Projekt

900 Anfragen pro Minute pro Organisation

Hierzu zählen Aufrufe an:

IAM API

Die folgenden Kontingente gelten, wenn Sie die Features Identity and Access Management in BigQuery verwenden, um IAM-Richtlinien abzurufen und festzulegen sowie IAM-Berechtigungen zu testen. Anweisungen der Datenkontrollsprache (DCL) werden auf das SetIAMPolicy-Kontingent angerechnet.

Kontingent Standard Notes
IamPolicy Anfragen pro Minute und Nutzer 1.500 Anfragen pro Minute und Nutzer Jeder Nutzer kann bis zu 1.500 Anfragen pro Minute und Projekt stellen.
Kontingent in der Google Cloud Console ansehen
IamPolicy Anfragen pro Minute und Projekt 3.000 Anfragen pro Minute und Projekt Ihr Projekt kann bis zu 3.000 Anfragen pro Minute senden.
Kontingent in der Google Cloud Console ansehen
Einzelne Region SetIAMPolicy Anfragen pro Minute und Projekt 1.000 Anfragen pro Minute und Projekt Ihr Projekt mit einer einzelnen Region kann bis zu 1.000 Anfragen pro Minute senden.
Kontingent in der Google Cloud Console ansehen
Multiregionale SetIAMPolicy Anfragen pro Minute und Projekt 2.000 Anfragen pro Minute und Projekt Ihr mehrregionales Projekt kann bis zu 2.000 Anfragen pro Minute senden.
Kontingent in der Google Cloud Console ansehen
Omni-region SetIAMPolicy Anfragen pro Minute und Projekt 200 Anfragen pro Minute und Projekt Ihr Omni-Region-Projekt kann bis zu 200 Anfragen pro Minute senden.
Kontingent in der Google Cloud Console ansehen

Storage Read API

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

Kontingent Standard Notes
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 Google Cloud 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 Google Cloud Console ansehen

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

Limit Standard Notes
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 serialisierte Datengröße 128 MB Wenn Sie den Storage Read API-ReadRows-Aufruf verwenden, darf die serialisierte Darstellung der Daten in einer einzelnen ReadRowsResponse-Nachricht nicht größer als 128 MB sein.
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.
Maximale Arbeitsspeichernutzung pro Stream 1,5 GB Der maximale Arbeitsspeicher pro Stream ist ein Näherungswert, da das Limit auf der internen Darstellung der Zeilendaten basiert. Streams, die mehr als 1,5 GB Arbeitsspeicher für eine einzelne Zeile verwenden, können fehlschlagen. Weitere Informationen finden Sie unter Fehlerbehebung bei Ressourcenüberschreitungen.

Storage Write API

Die folgenden Kontingente gelten für Storage Write API-Anfragen: Die folgenden Kontingente können auf Ordnerebene angewendet werden. Diese Kontingente werden dann zusammengefasst und für alle untergeordneten Projekte freigegeben. Wenden Sie sich an Cloud Customer Care, um diese Konfiguration zu aktivieren.

Wenn Sie ein höheres Kontingentlimit anfordern möchten, fügen Sie in Ihre Anfrage die Kontingentfehlermeldung ein, um die Verarbeitung zu beschleunigen.

Kontingent Standard Notes
Gleichzeitige Verbindungen 1.000 in einer Region; 10.000 in einer Mehrfachregion

Das Kontingent für gleichzeitige Verbindungen basiert auf dem Clientprojekt, das die Storage Write API-Anfrage initiiert, nicht auf dem Projekt, das die BigQuery-Dataset-Ressource enthält. Das initiierende Projekt ist das Projekt, das mit dem API-Schlüssel oder dem Dienstkonto verknüpft ist.

In Ihrem Projekt können 1.000 gleichzeitige Verbindungen in einer Region oder 10.000 gleichzeitige Verbindungen in den Mehrfachregionen US und EU ausgeführt werden.

Wenn Sie den Standardstream in Java oder Go verwenden, empfehlen wir, Storage Write API-Multiplexing zu verwenden, um in mehrere Zieltabellen mit freigegebenen Verbindungen zu schreiben. um die Anzahl der insgesamt erforderlichen Verbindungen zu reduzieren. Wenn Sie den Beam-Connector mit „Mindestens einmal“-Semantik verwenden, können Sie für UseStorageApiConnectionPool den Wert TRUE festlegen. um Multiplexing zu aktivieren.

Kontingent in der Google Cloud Console ansehen

In Cloud Monitoring können Sie Messwerte zu den Nutzungskontingenten und Limits für Ihre Projekte ansehen. Wählen Sie anhand Ihrer Region den Namen des Limits für gleichzeitige Verbindungen aus. Die Optionen sind ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU und ConcurrentWriteConnectionsPerProjectRegion für us, eu bzw. andere Regionen.

Es wird dringend empfohlen, Benachrichtigungen zur Überwachung Ihrer Kontingentnutzung und -limits einzurichten. Sollte es bei Ihren Trafficmustern zu Spitzen und/oder zu einem regulären organischen Wachstum kommen, kann es sinnvoll sein, Ihr Kontingent um 25 bis 50 % zu überschreiten, um die unerwartete Nachfrage zu bewältigen.
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 Google Cloud Console ansehen

In Cloud Monitoring können Sie Messwerte zu den Nutzungskontingenten und Limits für Ihre Projekte ansehen. Wählen Sie den Durchsatzlimit-Namen basierend auf Ihrer Region aus. Die Optionen sind AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU und AppendBytesThroughputPerProjectRegion für us, eu bzw. andere Regionen. Das Durchsatzkontingent für Schreibvorgänge wird anhand des Projekts berechnet, in dem sich das Ziel-Dataset befindet, und nicht auf Grundlage des Clientprojekts.

Es wird dringend empfohlen, Benachrichtigungen zur Überwachung Ihrer Kontingentnutzung und -limits einzurichten. Sollte es bei Ihren Trafficmustern zu Spitzen und/oder zu einem regulären organischen Wachstum kommen, kann es sinnvoll sein, Ihr Kontingent um 25 bis 50 % zu überschreiten, um die unerwartete Nachfrage zu bewältigen.
CreateWriteStream-Anfragen 10.000 Streams pro Stunde, Projekt und Region Sie können CreateWriteStream bis zu 10.000-mal pro Stunde,Projekt und Region aufrufen. Sie können den Standardstream verwenden, wenn Sie nicht genau eine Semantik benötigen. Dieses Kontingent gilt pro Stunde, der Messwert in der Google Cloud Console wird jedoch pro Minute angezeigt.
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 1 TB einen Commit durchführen. Für dieses Kontingent gibt es keine Kontingentberichte.

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

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

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

Bandbreite

Für die Replikationsbandbreite gelten die folgenden Kontingente:

Kontingent Standard Hinweise
Maximale anfängliche Backfill-Replikationsbandbreite für jede Region, für die regionenübergreifender Datenausgang vom primären Replikat an sekundäre Replikate erfolgt. 10 Gbit/s pro Region für die meisten Projekte
Maximale aktuelle Replikationsbandbreite für jede Region, für die regionenübergreifender Datenausgang vom primären Replikat an sekundäre Replikate erfolgt. 5 Gbit/s pro Region und Projekt
Maximale Turboreplikationsbandbreite für jede Region, für die regionenübergreifender Datenausgang vom primären Replikat an sekundäre Replikate erfolgt. 5 Gbit/s pro Standardkontingent für die meisten Projekte Das Kontingent für die Bandbreite der Turbo-Replikation gilt nicht für den anfänglichen Backfill-Vorgang.

Wenn die Replikationsbandbreite eines Projekts ein bestimmtes Kontingent überschreitet, wird die Replikation aus den betroffenen Projekten möglicherweise mit dem Fehler rateLimitExceeded beendet, der Details zum überschrittenen Kontingent enthält.