Kontingente und Limits

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

• Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
• Systemlimits sind feste Werte, die nicht geändert werden können.

Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud Ressource Ihr Google Cloud Projekt nutzen kann. 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 nebenläufig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.

Das Cloud-Kontingentsystem tut Folgendes:

• Es überwacht Ihren Verbrauch von Google Cloud Produkten und Diensten.
• Es schränkt Ihren Verbrauch dieser Ressourcen ein.
• Es bietet eine Möglichkeit, Änderungen am Kontingentwert zu beantragen und Kontingentanpassungen zu automatisieren.

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 auszuführen versuchen, schlägt dann fehl.

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

Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.

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

In einigen Fehlermeldungen werden Kontingente oder Limits angegeben, die Sie erhöhen können, während in anderen Fehlermeldungen Kontingente oder Limits angegeben werden, die Sie nicht erhöhen können. Wenn Sie ein festes Limit erreichen, müssen Sie temporäre oder dauerhafte Problemumgehungen oder Best Practices für Ihre Arbeitslast implementieren. Dies ist eine Best Practice, auch für Kontingente oder Limits, die erhöht werden können. Weitere Informationen zu beiden Fehlertypen finden Sie unter Fehler bei Kontingenten und Limits beheben.

Berechnung der Slot-Kontingentnutzung

Bei Projekten, die das kapazitätsbasierte Preismodell verwenden, einschließlich BigQuery-Editionen, spiegelt die Spalte Verwendet für das Kontingent Gesamtzahl der Slots Ihre gesamte zugewiesene Kapazität in einer bestimmten Region wider. Dieser Wert umfasst alle in Ihren Reservierungen definierten Baseline-Slots sowie alle aktiven Kapazitätszusicherungen. Da Baseline-Slots dedizierte verfügbare Ressourcen sind, werden sie vom Kontingentsystem auch dann als „verwendet“ angezeigt, wenn sie inaktiv sind. Weitere Informationen dazu, wie sich dies vom Ressourcenmonitoring unterscheidet, finden Sie unter Slot-Messwerte.

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 genauen Richtlinien variieren je nach Ressourcenverfügbarkeit, Nutzerprofil, Service Usage-Verlauf und anderen Faktoren und können sich ohne Vorankündigung ändern.

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

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

Messwertnamen für Kontingente und Systemlimits abrufen

Sie können die Google Cloud Console oder die Google Cloud CLI verwenden, um die Messwertnamen und Kontingent-IDs (auch als Limitnamen bezeichnet) für Ihre BigQuery-Kontingente und -Systemlimits zu finden:

Console

1. Rufen Sie in der Google Cloud Console die Seite Kontingente und Systemlimits auf.

   Zur Seite „Kontingente und Systemlimits“

2. Klicken Sie auf Filter, wählen Sie Dienst und dann den BigQuery-Dienst aus, den Sie prüfen möchten (z. B. BigQuery API, BigQuery Reservation API oder BigQuery Storage API).

3. Klicken Sie in der Tabellenüberschrift auf Spaltenanzeigeoptionen, wählen Sie Messwert und Limitname aus und klicken Sie dann auf OK.

gcloud

Führen Sie den Befehl gcloud beta quotas info list aus:

gcloud beta quotas info list --project=PROJECT_ID_OR_NUMBER \
    --service=SERVICE_NAME \
    --format="table(metric, name, quota_id, dimensions)"

Ersetzen Sie Folgendes:

• PROJECT_ID_OR_NUMBER: Ihre Projekt-ID oder Projektnummer von Google Cloud
• SERVICE_NAME: der Name des BigQuery-Dienstes, den Sie prüfen möchten:
• Core BigQuery API: bigquery.googleapis.com
• Storage Read API und Storage Write API (gRPC): bigquerystorage.googleapis.com
• BigQuery Reservation API: bigqueryreservation.googleapis.com
• BigQuery Migration API: bigquerymigration.googleapis.com
• BigQuery Data Transfer Service API: bigquerydatatransfer.googleapis.com
• BigQuery Connection API: bigqueryconnection.googleapis.com
• BigLake API: biglake.googleapis.com
• BigQuery Sharing API (früher Analytics Hub API): analyticshub.googleapis.com
• BigQuery Data Policy API: bigquerydatapolicy.googleapis.com

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.

Ausstehende Jobs

Für ausstehende Jobs in BigQuery gilt das folgende Limit:

Systemlimit	Standard	Hinweise
Maximale Anzahl ausstehender Jobs	50.000 Jobs pro Projekt und Region	Die Anzahl der Jobs, die gleichzeitig den Status „Ausstehend“ haben können. Dieses Limit kann nicht erhöht werden. Weitere Informationen finden Sie unter BigQuery-Kontingentfehler beheben.

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.

Informationen zur Fehlerbehebung finden Sie auf der Seite zur Fehlerbehebung für BigQuery.

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
Abfragenutzung pro Tag	Messwert: bigquery.googleapis.com/quota/query/usage Kontingent-ID: QueryUsagePerDay	200 Tebibyte (TiB)	Dieses Kontingent gilt nur für das On-Demand-Preismodell für Abfragen. Ihr Projekt kann bis zu 200 TiB in Abfragen pro Tag ausführen. Sie können dieses Limit jederzeit ändern. Weitere Informationen zur Kostenkontrolle finden Sie unter Benutzerdefinierte Abfragekontingente erstellen.
Abfragenutzung pro Tag und Nutzer	Messwert: bigquery.googleapis.com/quota/query/usage Kontingent-ID: QueryUsagePerUserPerDay	Unbegrenzt	Dieses Kontingent gilt nur für das On-Demand-Abfragepreismodell. Es gibt kein Standardlimit für die Anzahl der TiB in Abfragen, die ein Nutzer pro Tag ausführen kann. Sie können das Limit jederzeit festlegen. Unabhängig vom Limit pro Nutzer darf die Gesamtnutzung aller Nutzer im Projekt das Limit für die Abfragenutzung pro Tag nicht überschreiten. Weitere Informationen zur Kostenkontrolle finden Sie unter Benutzerdefinierte Abfragekontingente erstellen.
Regionenübergreifende Byte pro Tag für föderierte GoogleSQL-Abfragen	Messwert: bigquery.googleapis.com/quota/query/cloud_sql_federated_query_cross_region_bytes Kontingent-ID: CloudSqlFederatedQueryCrossRegionBytesPerDay	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.
BigQuery Omni – Übertragene Byte pro Tag	Messwert: bigquery.googleapis.com/quota/query/cross_cloud_transfer_bytes Kontingent-ID: CrossCloudTransferBytesPerDay	1 TB	Sie können pro Tag bis zu 1 TB Daten von einem Amazon S3-Bucket oder von einem Azure Blob Storage übertragen.
BigQuery Omni – Gesamtgröße der Abfrageergebnisse pro Tag	Messwert: bigquery.googleapis.com/quota/query/omni_query_bytes Kontingent-ID: OmniQueriesBytesPerDay	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.

Die folgenden Systemlimits 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:

Systemlimit	Wert	Hinweise
Übertragene Byte pro Job in BigQuery Omni	60 GB	Die maximale Übertragungsgröße pro Job beträgt 60 GB, wenn Sie CREATE TABLE AS SELECT- (CTAS) oder INSERT INTO SELECT-Anweisungen in BigQuery Omni-Regionen ausführen, um Daten während einer cloudübergreifenden Übertragung zu filtern. Dieses Limit gilt auch für BigQuery Omni-Joins, bei denen im Hintergrund eine Omni-CTAS-Abfrage ausgeführt wird, um Daten in eine temporäre Tabelle in Ihrer BigQuery-Region zu übertragen. Wenn Sie eine Erhöhung beantragen möchten, wenden Sie sich an den Support. Weitere Informationen finden Sie unter BigQuery Omni-Join-Kosten.
Von globalen Abfragen übertragene Byte pro Tag und Regionspaar	180 TB	Sie können mit globalen Abfragen bis zu 180 TB Daten pro Tag zwischen jedem Regionspaar übertragen. Wenden Sie sich an den Support, um eine Kontingenterhöhung anzufordern.
Kopierjobs für globale Abfragen pro Projekt	10.000	Sie können bis zu 10.000 Kopierjobs pro Projekt ausführen, wenn Sie globale Abfragen ausführen, die Daten zwischen Regionen kopieren. Eine globale Abfrage kann mehrere Kopierjobs auslösen. Wenden Sie sich an den Support, um eine Kontingenterhöhung anzufordern.
Von einem einzelnen Kopierjob in einer globalen Abfrage übertragene Byte	100 GB	Standardmäßig kann ein einzelner Kopierjob, der Teil einer globalen Abfrage ist, maximal 100 GB übertragen. Wenn Sie eine Erhöhung des Limits beantragen möchten, wenden Sie sich an den Support.
Globale Aktualisierungen der Optionen auf Projektebene	5	Wenn Sie eine DDL-Anweisung ausführen, die globale Konfigurationsoptionen ändert, können Sie alle 10 Sekunden bis zu fünf Anweisungen ausführen. Dieses Limit gilt für die folgenden DDL-Anweisungen: ALTER PROJECT SET OPTIONS ALTER ORGANIZATION SET OPTIONS
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. Informationen zur Fehlerbehebung finden Sie unter Limits für interaktive Abfragen mit hohem Volumen vermeiden.
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 Remote-Funktionen 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 im Zusammenhang mit 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. BigQuery kann jedoch einen Abfragejob aufgrund vorübergehender Probleme wie Serverneustarts intern wiederholen. BigQuery kann eine Abfrage bis zu dreimal wiederholen und jeder Versuch kann bis zu sechs Stunden dauern. Daher kann eine Abfrage eine Gesamtlaufzeit von mehr als sechs Stunden (bis zu 18 Stunden) haben. Anhand der folgenden Signale können Sie prüfen, ob ein Job wiederholt wurde: Google Cloud -Console: Vergleichen Sie im Job-Explorer zwei Jobs. Prüfen Sie im Abschnitt Analyse auf Abfrageebene auf dem Tab Messwerte das Feld Wiederholen. INFORMATION_SCHEMA: Prüfen Sie in den INFORMATION_SCHEMA.JOBS-Ansichten die Spalte final_execution_duration_ms. Wenn der Unterschied zwischen start_time und end_time deutlich größer als final_execution_duration_ms ist, wurde die Abfrage wiederholt. BigQuery API: Prüfen Sie im Objekt JobStatistics das Feld finalExecutionDurationMs. Wenn der Unterschied zwischen startTime und endTime deutlich größer als finalExecutionDurationMs ist, wurde die Abfrage wiederholt. Weitere Informationen finden Sie in der Dokumentation zur Fehlerbehebung bei Abfragen unter Ausführungsdauer. 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 48 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. Dies schließt verschachtelte und wiederkehrende Spalten ein. Gelöschte Spalten können weiterhin zur Gesamtzahl der Spalten zählen. Wenn Sie Spalten gelöscht haben, erhalten Sie möglicherweise Kontingentfehler, bis die Gesamtzahl zurückgesetzt wird.
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. Auf Organisationsebene gilt außerdem ein Limit von 20.000 gleichzeitigen Slots. BigQuery versucht, Slots fair auf Projekte innerhalb einer Organisation zu verteilen, wenn der Gesamtbedarf höher als 20.000 Slots ist. BigQuery-Slots werden auf alle Abfragen in einem Einzelprojekt aufgeteilt. BigQuery kann dieses Limit überschreiten, um Ihre Abfragen zu beschleunigen. Die Kapazität ist abhängig von der Verfügbarkeit. Informationen zur Anzahl der von Ihnen genutzten Slots finden Sie unter BigQuery mit Cloud Monitoring überwachen.
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 Fehlermeldungen.
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 Byte, wenn Sie Microsoft Azure- oder AWS-Daten abfragen. 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.
Maximale Zeilengröße in BigQuery Omni	10 MiB	Die maximale Zeilengröße beträgt 10 MiB, wenn Sie Microsoft Azure- oder AWS-Daten abfragen. Weitere Informationen finden Sie unter BigQuery Omni-Limits.
Übertragung globaler Abfragen	2 GiB/s	Die Bandbreite der Übertragung, die von globalen Abfragen verwendet wird, pro Projekt und Regionspaar

Obwohl geplante Abfragen Features von BigQuery Data Transfer Service verwenden, sind sie keine Übertragungen und unterliegen nicht den Limits für Ladejobs.

Extrahierungsjobs

Die folgenden Kontingente gelten für Jobs, die Daten aus BigQuery extrahieren, indem das bq-Befehlszeilentool, die Google Cloud Console oder die API-Methode jobs.insert (Typ „extract“) verwendet wird:

Kontingent	Messwert- und Kontingent-ID	Standard	Hinweise
Maximale Anzahl extrahierter Byte pro Tag	Messwert: bigquery.googleapis.com/quota/extract/bytes Kontingent-ID: ExtractBytesPerDay	50 TiB	Das Limit von 50 TiB pro Tag (ExtractBytesPerDay) ist ein Limit zur Missbrauchsverhinderung, das nur für Extraktionsjobs gilt, die den kostenlosen freigegebenen Slot-Pool verwenden. Mit dem freigegebenen Slot-Pool können Sie bis zu 50 TiB Daten pro Tag kostenlos aus einem Projekt extrahieren. Sie können eine Cloud Monitoring-Benachrichtigungsrichtlinie einrichten, die Benachrichtigungen zur Anzahl der extrahierten Byte enthält. Extraktionsjobs sind vom Tageslimit von 50 TiB ausgenommen und können dieses überschreiten, wenn Sie einen der folgenden Schritte ausführen: Erstellen Sie eine Slot-Reservierung oder verwenden Sie eine vorhandene Reservierung und weisen Sie dann Ihr Projekt der Reservierung mit dem Jobtyp PIPELINE zu. Da für Extraktionsjobs dedizierte oder automatisch skalierte Slot-Kapazität anstelle des freigegebenen Pools verwendet wird, wird das tägliche Kontingent von 50 TiB umgangen. Die Abrechnung erfolgt nach dem kapazitätsbasierten Preis. EXPORT DATA-Anweisungen werden für PIPELINE-Reservierungen nicht unterstützt. Verwenden Sie die SQL-Anweisung EXPORT DATA. Da die Anweisung als Abfragejob mit Abfragekapazität und nicht mit dem freigegebenen Extraktionspool ausgeführt wird, ist sie vom Kontingent für extrahierte Byte ausgenommen. Je nach Konfiguration Ihres Projekts werden Sie entweder mit On-Demand- oder kapazitätsbasierten Preisen abgerechnet. Verwenden Sie die Storage Read API. Da Streaming-Lesevorgänge direkt aus dem BigQuery-Speicher lesen, werden Kontingente für Extraktionsjobs umgangen. Die Abrechnung erfolgt nach dem Preis für Streaming-Lesevorgänge. Die Ablaufzeit beträgt garantiert mindestens 6 Stunden ab dem Zeitpunkt der Sitzungserstellung.
Maximale Anzahl von Extraktionsjobs pro Tag	Messwert: bigquery.googleapis.com/quota/extract/count Kontingent-ID: ExtractJobsPerDay	100.000 Extraktionsjobs	Das Limit von 100.000 Extraktionsjobs pro Tag ist ein Limit zur Missbrauchsprävention, das nur für Extraktionsjobs gilt, die den kostenlosen freigegebenen Slot-Pool verwenden. Mit dem freigegebenen Slot-Pool können Sie bis zu 100.000 Extraktionsjobs pro Tag in einem Projekt kostenlos ausführen. Extraktionsjobs sind vom Limit von 100.000 Jobs pro Tag ausgenommen und können dieses Limit überschreiten,wenn Sie einen der folgenden Schritte ausführen: Erstellen Sie eine Slot-Reservierung oder verwenden Sie eine vorhandene Reservierung und weisen Sie dann Ihr Projekt der Reservierung mit dem Jobtyp PIPELINE zu. Da für Extraktionsjobs dedizierte oder automatisch skalierte Kapazität anstelle des gemeinsam genutzten Pools verwendet wird, wird das tägliche Limit für Extraktionsjobs vollständig umgangen. Die Abrechnung erfolgt nach dem kapazitätsbasierten Preis. Verwenden Sie die SQL-Anweisung EXPORT DATA. Da die Anweisung als Abfragejob ausgeführt wird, ist sie von den täglichen Limits für Extraktionsjobs ausgenommen. Je nach Konfiguration Ihres Projekts werden Sie entweder mit On-Demand- oder kapazitätsbasierten Preisen abgerechnet. Verwenden Sie die Storage Read API. Da Streaming-Lesevorgänge direkt aus dem BigQuery-Speicher lesen, werden Kontingente für Extraktionsjobs umgangen. Die Abrechnung erfolgt nach dem Preis für Streaming-Lesevorgänge. Die Ablaufzeit beträgt garantiert mindestens 6 Stunden ab dem Zeitpunkt der Sitzungserstellung.

Für Extraktionsjobs gelten die folgenden Systemlimits:

Systemlimit	Wert	Hinweise
Maximale Tabellengröße, die in eine einzelne Datei extrahiert wird	1 GB	Sie können in einer Datei bis zu 1 GB Tabellendaten extrahieren. Wenn Sie mehr als 1 GB Daten extrahieren möchten, verwenden Sie einen Platzhalter, um die Daten in mehrere Dateien zu extrahieren. Wenn Sie Daten in mehrere Dateien extrahieren, 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 Extraktionsjob	500 URIs	Ein Extraktionsjob kann bis zu 500 Platzhalter-URIs enthalten.

Weitere Informationen zur Anzeige der aktuellen Nutzung von Extraktionsjobs finden Sie unter Aktuelle Kontingentnutzung aufrufen. Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung beim Export.

Ladejobs

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

Systemlimit	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. Dies schließt verschachtelte und wiederkehrende Spalten ein.
Maximale Größe pro Ladejob	15 TB	Die Gesamtgröße aller CSV-, JSON-, Avro-, Parquet- und ORC-Eingabedateien kann bis zu 15 TB betragen. Dieses Limit gilt nicht für Jobs mit einer Reservierung.
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 Transferkonfigurationen, 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:

  • Campaign Manager
  • Google Ads
  • Google Ad Manager
  • Google Merchant Center (Beta)
  • Google Play
  • Search Ads 360 (Beta)
  • YouTube-Kanal
  • YouTube-Rechteinhaber

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

Systemlimit	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. Informationen zur Fehlerbehebung bei Kopierjobs finden Sie unter Maximale Anzahl von Kopierjobs pro Tag und Projektkontingentfehler.

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

Systemlimit	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 in derselben Region kopieren. Wenn ein Quell-Dataset mehr als 20.000 Tabellen enthält, plant 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 Standardintervall von 24 Stunden getrennt, das Nutzer auf mindestens 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 Quell-Dataset mehr als 1.000 Tabellen enthält, plant 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 Standardintervall von 24 Stunden getrennt, das Nutzer auf mindestens 12 Stunden anpassen können.

Reservierungen

Die folgenden Kontingente gelten für Reservierungen:

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
Gesamtzahl der Slots für die EU-Region	Messwert: bigqueryreservation.googleapis.com/total_slots_eu Kontingent-ID: TotalSlotsPerProjectEU	5.000 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in der EU-Multiregion mit der Google Cloud Console erwerben können.
Gesamtzahl der Slots für die US-Region	Messwert: bigqueryreservation.googleapis.com/total_slots_us Kontingent-ID: TotalSlotsPerProjectUS	10.000 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in der US-Multiregion mit der Google Cloud Console erwerben können.
Gesamtzahl der Slots für die us-east1-Region	Messwert: bigqueryreservation.googleapis.com/total_slots Kontingent-ID: TotalSlotsPerProject	4.000 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in der aufgelisteten Region über die Google Cloud Console erwerben können.
Gesamtzahl der Slots für die folgenden Regionen: asia-south1, asia-southeast1, europe-west2, us-central1, us-west1	Messwert: bigqueryreservation.googleapis.com/total_slots Kontingent-ID: TotalSlotsPerProject	2.000 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in den einzelnen Regionen mit der Google Cloud Console erwerben können.
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	Messwert: bigqueryreservation.googleapis.com/total_slots Kontingent-ID: TotalSlotsPerProject	1.000 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in den einzelnen Regionen mit der Google Cloud Console erwerben können.
Gesamtzahl der Slots für BigQuery Omni-Regionen	Messwert: bigqueryreservation.googleapis.com/totalslotsOMNI_REGION (z. B. bigqueryreservation.googleapis.com/total_slots_aws-us-east-1) Kontingent-ID: TotalSlotsPerProjectOMNI_REGION (z. B. TotalSlotsPerProjectAwsUSEast1)	100 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in der Google Cloud Console in den BigQuery Omni-Regionen erwerben können.
Gesamtzahl der Slots für alle anderen Regionen	Messwert: bigqueryreservation.googleapis.com/total_slots Kontingent-ID: TotalSlotsPerProject	500 Slots	Die maximale Anzahl von BigQuery-Slots, die Sie in der anderen Region über die Google Cloud Console erwerben können.
Anzahl der Administrationsprojekte für Slot-Reservierungen	Messwert: bigqueryreservation.googleapis.com/total_admin_projects Kontingent-ID: TotalAdminProjectsPerOrganization	10 Projekte pro Organisation	Die maximale Anzahl von Administrationsprojekten innerhalb einer Organisation, die eine Reservierung oder eine aktive Zusicherung für Slots für einen bestimmten Standort / eine bestimmte Region enthalten kann.

Die folgenden Systemlimits gelten für Reservierungen:

Systemlimit	Wert	Hinweise
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:

Systemlimit	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, darunter autorisierte Ansichten, autorisierte Datasets und autorisierte Funktionen. Wenn Sie dieses Limit aufgrund einer großen Anzahl autorisierter Ansichten überschreiten, sollten Sie die Ansichten in autorisierten Datasets gruppieren. Als Best Practice sollten Sie zusammengehörige Ansichten in autorisierten Datasets gruppieren, wenn Sie neue BigQuery-Architekturen entwerfen, insbesondere mandantenfähige Architekturen.
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: Google Cloud Console bq-Befehlszeilentool BigQuery-Clientbibliotheken Die folgenden API-Methoden: datasets.insert datasets.patch datasets.update datasets.delete datasets.undelete Die folgenden DDL-Anweisungen: CREATE SCHEMA ALTER SCHEMA DROP SCHEMA UNDROP SCHEMA
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.

Hinweis: Kontingente und Limits sind mit Tabellennamen verknüpft. Wenn Sie die Tabelle also kürzen oder löschen und dann neu erstellen, wird das Kontingent oder Limit nicht zurückgesetzt, da sich der Tabellenname nicht geändert hat.

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

Informationen zur Fehlerbehebung im Zusammenhang mit Tabellenkontingenten oder -limits finden Sie auf der Seite zur Fehlerbehebung in BigQuery.

Standardtabellen

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

Systemlimit	Standard	Notes
Tabellenänderungen pro Tag	1,500 Änderungen	Ihr Projekt kann bis zu 1.500 Tabellenänderungen pro Tabelle und Tag vornehmen. Ein Ladejob, Kopierjob oder Abfragejob, der Tabellendaten anhängt oder überschreibt, zählt als eine Änderung an der Tabelle. Dieses Limit kann nicht erhöht werden. Dieses Limit wird den ganzen Tag über als Ratenbegrenzung durchgesetzt, nicht als einzelnes Kontingent, das auf einmal zugewiesen wird. BigQuery füllt das verfügbare Kontingent regelmäßig auf. Häufige Vorgänge können das verfügbare Kontingent erschöpfen, was zu quotaExceeded-Fehlern führt,selbst wenn Ihr tägliches Gesamtvolumen weit unter dem Tageslimit von 1.500 Änderungen liegt. Wenn Sie die Aufnahme mit hoher Frequenz optimieren möchten, sollten Sie Vorgänge im Batchmodus ausführen, Jobs gleichmäßig über die Zeit verteilen oder zur BigQuery Storage Write API (gRPC) migrieren. DML-Anweisungen sind ausgeschlossen und werden nicht auf die Anzahl der Tabellenänderungen pro Tag angerechnet. Streamingdaten sind ausgeschlossen und 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: Google Cloud Console bq-Befehlszeilentool BigQuery-Clientbibliotheken Die folgenden API-Methoden: tables.insert tables.patch tables.update DDL-Anweisungen für Tabellen 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. Dies schließt verschachtelte und wiederkehrende Spalten ein.

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:

Systemlimit	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. 300.000.000 Dateien	Eine externe Tabelle kann auf einen Cloud Storage-Bucket mit bis zu etwa 300.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.

Hinweis: Diese Limits gelten nicht für von Hive partitionierte Tabellen.

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. Abfrage- und Ladejobs können beispielsweise 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 wirken sich nicht auf dieses Limit aus.

Informationen zu Strategien für das Einhalten der Limits für partitionierte Tabellen finden Sie unter Kontingentfehler beheben.

Systemlimit	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 Aufnahmezeit pro partitionierter Tabelle pro Tag	11.000 Änderungen	In einem Projekt können bis zu 11.000 Partitionsänderungen pro Tag vorgenommen werden. Eine Partitionsänderung liegt vor, wenn Sie Daten in einer partitionierten Tabelle anhängen, aktualisieren, löschen oder kürzen. Für jede Art von Datenänderung, die Sie vornehmen, wird eine Partitionsänderung gezählt. Das Löschen einer Zeile zählt beispielsweise als eine Partitionsänderung, ebenso wie das Löschen einer gesamten Partition als eine Änderung zählt. Wenn Sie eine Zeile aus einer Partition löschen und dann in eine andere Partition einfügen, zählt dies als zwei Partitionsänderungen. Änderungen, die mit DML-Anweisungen oder der Streaming API vorgenommen werden, 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 Metadaten partitionierter Tabellen, die durch Folgendes ausgeführt werden: Google Cloud Console bq-Befehlszeilentool BigQuery-Clientbibliotheken Die folgenden API-Methoden: tables.insert tables.patch tables.update DDL-Anweisungen für Tabellen 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:

Systemlimit	Standard	Notes
Maximale Anzahl von Klonen und Snapshots in einer Kette	3 Tabellenklone oder ‑Snapshots	Klone und Snapshots sind in Kombination auf eine maximale Tiefe 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 den Klon A der Basistabelle, den Snapshot B von Klon A und den 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, erreichen Sie das Limit.

Tabellen-Snapshots

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

Systemlimit	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 sind in Kombination auf eine maximale Tiefe 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, erreichen Sie das Limit.

Aufrufe

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

Logische Ansichten

Für BigQuery-Standardtansichten gelten die folgenden Limits:

Systemlimit	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 umfasst nicht die Länge der in der Abfrage referenzierten Ansichten.
Maximale Anzahl von autorisierten Ansichten pro Dataset		Siehe Datasets.
Maximale Länge einer Ansichtsbeschreibung	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:

Systemlimit	Standard	Hinweise
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 der Beschreibung einer materialisierten Ansicht	16.384 Zeichen	Für die Beschreibung einer materialisierten Ansicht dürfen Sie höchstens 16.384 Zeichen verwenden.
Ausführungszeitlimit für Aktualisierungsjobs für materialisierte Ansichten	12 Stunden	Ein Aktualisierungsjob für eine materialisierte Ansicht kann bis zu 12 Stunden lang ausgeführt werden, bevor er fehlschlägt.

Suchindexe

Die folgenden Limits gelten für BigQuery-Suchindexe:

Systemlimit	Standard	Hinweise
Anzahl der CREATE INDEX- oder ALTER INDEX-DDL-Anweisungen pro Projekt, Region und Tag	500 Vorgänge	Ihr Projekt kann bis zu 500 CREATE INDEX- oder ALTER 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-, ALTER 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 Multiregionen; 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 Multiregionen 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.
Anzahl der Spalten, die mit Spaltengranularität pro Tabelle indexiert sind	63 Spalten pro Tabelle	Eine Tabelle kann bis zu 63 Spalten enthalten, bei denen index_granularity auf COLUMN gesetzt ist. Spalten, die mit der Granularität COLUMN durch Festlegen der Option default_index_column_granularity indexiert wurden, werden auf dieses Limit angerechnet. Die Anzahl der Spalten, die mit der Granularität GLOBAL indexiert werden, ist unbegrenzt. Weitere Informationen finden Sie unter Index mit Spaltengranularität.

Vektorindexe

Für BigQuery-Vektorindexe gelten die folgenden Limits:

Systemlimit	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 für den Indextyp IVF	10.000.000.000 Zeilen	Eine Tabelle kann maximal 10.000.000.000 Zeilen enthalten, um einen IVF-Vektorindex zu erstellen.
Maximale Anzahl von Zeilen für die Basistabelle für den Indextyp TREE_AH	200.000.000 Zeilen	Eine Tabelle kann maximal 200.000.000 Zeilen enthalten, um einen TREE_AH-Vektorindex zu erstellen.
Maximale Anzahl von Zeilen der Basistabelle für den partitionierten Indextyp TREE_AH	Insgesamt 10.000.000.000 Zeilen 200.000.000 Zeilen pro Partition	Eine Tabelle kann maximal 10.000.000.000 Zeilen enthalten und jede Partition kann maximal 200.000.000 Zeilen enthalten, um einen partitionierten TREE_AH-Vektorindex zu erstellen.
Maximale Größe des Arrays in der indexierten Spalte	4.096 Elemente	Die zu indexierende Spalte kann höchstens 4.096 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.

Hinweis: UDFs und die Tabellen, auf die sie verweisen, werden auf das Limit für die Anzahl von Ressourcen, auf die in einer Abfrage verwiesen wird, angerechnet.

Systemlimit	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:

Systemlimit	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.
Python-UDFs: Bildspeicherbyte pro Projekt und Region	10 GiB	Die Gesamtgröße in Byte aller Container-Images, die von Python-UDFs in einem bestimmten Projekt und einer bestimmten Region verwendet werden.
Python-UDFs: Mutationslimit	30 pro Minute	Sie können Python-UDFs bis zu 30-mal pro Minute, Region und Projekt erstellen oder aktualisieren.
Python-UDFs: Maximale Anzahl gleichzeitiger Python-UDFs	10	Sie können pro Projekt bis zu 10 gleichzeitige Abfragen ausführen, die auf Python-UDFs verweisen.

Remote-Funktionen

Für Remote-Funktionen in BigQuery gelten die folgenden Limits:

Informationen zur Fehlerbehebung finden Sie unter Maximale Anzahl gleichzeitiger Abfragen, die Remote-Funktionen enthalten.

Systemlimit	Standard	Notes
Maximale Anzahl gleichzeitiger Abfragen, die Remotefunktionen enthalten	10 Abfragen	Sie können bis zu zehn Abfragen gleichzeitig mit Remote-Funktionen 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 Functions, 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 Functions 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 Functions 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:

Systemlimit	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:

System 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 Multiregion-Standort und an einem einzelnen Standort in derselben geografischen Region ausführen, verbrauchen Ihre Abfragen möglicherweise dasselbe gleichzeitige 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 Multiregion-Standort 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:

System 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:

System 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:

Systemlimit	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 (gRPC) 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	7 Stunden	Eine interaktive Prioritäts-DML-Anweisung kann bis zu sieben Stunden in der Warteschlange warten. Wenn die Anweisung nach sieben 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 mutierende DML-Anweisungen werden auf dieses Limit angerechnet.

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.

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

Systemlimit	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:

System 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:

Systemlimit	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:

Systemlimit	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 48 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 48 Stunden abgelaufen sind.

Generative AI-Funktionen

Die folgenden Limits gelten für Funktionen, die Large Language Models (LLMs) der Agent Platform verwenden. Weitere Informationen finden Sie unter Kontingentdefinitionen für Funktionen.

Limits für Anfragen pro Minute

Die folgenden Limits gelten für Agent Platform-Modelle, die ein Limit für Anfragen pro Minute verwenden.

Funktion	Modell	Region	Anfragen pro Minute	Zeilen pro Job
AI.GENERATE_TEXT ML.GENERATE_TEXT AI.GENERATE_TABLE AI.GENERATE AI.GENERATE_BOOL AI.GENERATE_DOUBLE AI.GENERATE_INT	gemini-2.0-flash-lite-001	Multiregionen US und EU Einzelne Regionen, wie für gemini-2.0-flash-lite-001 in Standorte von Google-Modellendpunkten dokumentiert	Kein festgelegtes Kontingent. Kontingent bestimmt durch dynamisches gemeinsam genutztes Kontingent (DSQ)^1 und bereitgestellten Durchsatz^2	– für bereitgestellten Durchsatz 10.500.000 für DSQ, für einen Aufruf mit durchschnittlich 500 Eingabetokens und 50 Ausgabetokens
	gemini-2.0-flash-001	Multiregionen US und EU Einzelne Regionen, wie für gemini-2.0-flash-001 in Google-Modellendpunktstandorte dokumentiert		– für bereitgestellten Durchsatz 10.200.000 für DSQ, für einen Aufruf mit durchschnittlich 500 Eingabetokens und 50 Ausgabetokens
	gemini-2.5-flash	Multiregionen US und EU Einzelne Regionen, wie für gemini-2.5-flash in Standorte von Google-Modellendpunkten dokumentiert		– für bereitgestellten Durchsatz 9.300.000 für DSQ, für einen Aufruf mit durchschnittlich 500 Eingabetokens und 50 Ausgabetokens
	gemini-2.5-pro	Multiregionen US und EU Einzelne Regionen, wie für gemini-2.5-pro in Google-Modellendpunktstandorte dokumentiert		– für bereitgestellten Durchsatz 7.600.000 für DSQ, für einen Aufruf mit durchschnittlich 500 Eingabetokens und 50 Ausgabetokens
AI.IF AI.SCORE AI.CLASSIFY	Verschiedene gemini-2.5-*-Modelle	Multiregionen US und EU Jede einzelne Region, die für eine der gemini-2.5-* models in Google-Modellendpunktstandorten unterstützt wird	Kein festgelegtes Kontingent. Kontingent wird durch das dynamische freigegebene Kontingent (DSQ)^1 bestimmt	10.000.000 für einen Aufruf mit durchschnittlich 500 Tokens in jeder Eingabezeile und 50 Ausgabetokens.
AI.AGG	Verschiedene Gemini-Modelle	Weitere Informationen finden Sie unter Standorte.	Kein festgelegtes Kontingent. Das Kontingent wird durch das dynamische freigegebene Kontingent (DSQ)^1 bestimmt.	20.000.000
AI.GENERATE_TEXT ML.GENERATE_TEXT	Anthropic Claude	Siehe Kontingente nach Modell und Region.	Siehe Kontingente nach Modell und Region.	Wert für Anfragen pro Minute * 60 * 6
	Llama 3	Verfügbarkeit und Kontingente der Llama-Modellregion	Verfügbarkeit und Kontingente der Llama-Modellregion
	Mistral AI	Verfügbarkeit und Kontingente der Mistral KI-Modellregion	Verfügbarkeit und Kontingente der Mistral KI-Modellregion
AI.GENERATE_EMBEDDING^5 AI.EMBED AI.SIMILARITY AI.SEARCH VECTOR_SEARCH ML.GENERATE_EMBEDDING^5	text-embedding text-multilingual-embedding	Alle Regionen, die Remote-Modelle unterstützen	1.500^3,4	80.000.000 für einen Aufruf mit durchschnittlich 50 Tokens in jeder Eingabezeile 14.000.000 für einen Aufruf mit durchschnittlich 600 Tokens in jeder Eingabezeile
	multimodalembedding	Unterstützte europäische Einzelregionen	120^3	43.200
		Andere Regionen als die unterstützten europäischen Einzelregionen	600^3	216.000
	gemini-embedding-2	US, EU und global	Kein festgelegtes Kontingent. Das Kontingent wird durch das dynamische freigegebene Kontingent (DSQ)^1 bestimmt.	–

¹ Wenn Sie DSQ verwenden, gibt es keine vordefinierten Kontingentlimits für Ihre Nutzung. Stattdessen bietet DSQ Zugriff auf einen großen gemeinsam genutzten Ressourcenpool, der dynamisch basierend auf der Echtzeitverfügbarkeit von Ressourcen und der Kundennachfrage nach dem jeweiligen Modell zugewiesen wird. Wenn mehr Kunden aktiv sind, erhält jeder Kunde weniger Durchsatz. Wenn weniger Kunden aktiv sind, kann jeder Kunde einen höheren Durchsatz erzielen.

² Der bereitgestellte Durchsatz ist ein Abo mit festen Kosten und fester Laufzeit, das in verschiedenen Laufzeiten verfügbar ist. Mit dem bereitgestellten Durchsatz können Sie Durchsatz für unterstützte generative KI-Modelle auf der Agent Platform reservieren.

³ Wenn Sie das Kontingent erhöhen möchten, fordern Sie in der Agent Platform eine Anpassung des QPM-Kontingents an. Es kann bis zu 30 Minuten dauern, bis der erhöhte Kontingentwert wirksam wird.

⁴ Sie können das Kontingent für die Agent Platform-Modelle text-embedding und text-multilingual-embedding ohne manuelle Genehmigung auf 10.000 Anfragen pro Minute erhöhen. Dies führt zu einem höheren Durchsatz von 500.000.000 Zeilen pro Job oder mehr, basierend auf einem Aufruf mit durchschnittlich 50 Tokens in jeder Eingabezeile.

⁵ Diese Funktion ist auf maximal 5 gleichzeitig ausgeführte Jobs pro Projekt beschränkt.

Weitere Informationen zu Kontingenten für LLMs der Agent Platform finden Sie unter Kontingentlimits für generative KI auf der Agent Platform.

Limits für Tokens pro Minute

Die folgenden Limits gelten für Agent Platform-Modelle, die ein Limit für Tokens pro Minute verwenden:

Funktion	Tokens pro Minute	Zeilen pro Job	Anzahl gleichzeitig ausgeführter Jobs
AI.GENERATE_EMBEDDING oder ML.GENERATE_EMBEDDING bei Verwendung eines Remote-Modells über einem gemini-embedding-001-Modell	10.000.000	12.000.000 für einen Aufruf mit durchschnittlich 300 Tokens pro Zeile	5
AI.GENERATE_EMBEDDING oder ML.GENERATE_EMBEDDING bei Verwendung eines Remote-Modells über einem gemini-embedding-2-Modell	5.000.000	1.440.000	5

Limits für Tokens pro Tag

Die folgenden Tageslimits gelten für die Tokennutzung für Large Language Models, auf die über generative KI-Funktionen von BigQuery zugegriffen wird. Diese Limits gelten global für alle Regionen. Sie können eine Anpassung anfordern. Weitere Informationen finden Sie unter Kosten mit Tokenkontingenten kontrollieren.

Kontingent	Messwert- und Kontingent-ID	Standard	Hinweise
KI-Eingabetokens pro Tag	Messwert: bigquery.googleapis.com/quota/query/ai_input_tokens Kontingent-ID: GenAiInputTokensPerDay	200.000.000.000	Vom LLM verwendete Eingabe-Tokens. Gilt pro Tag und Projekt.
KI-Eingabetokens pro Tag und Nutzer	Messwert: bigquery.googleapis.com/quota/query/ai_input_tokens Kontingent-ID: GenAiInputTokensPerUserPerDay	150.000.000.000	Vom LLM verwendete Eingabe-Tokens. Gilt pro Tag, Projekt und Nutzer.
KI-Ausgabetokens pro Tag	Messwert: bigquery.googleapis.com/quota/query/ai_output_tokens Kontingent-ID: GenAiOutputTokensPerDay	20.000.000.000	Vom LLM verwendete Ausgabe- und Thought-Tokens. Gilt pro Tag und Projekt.
KI-Ausgabetokens pro Tag und Nutzer	Messwert: bigquery.googleapis.com/quota/query/ai_output_tokens Kontingent-ID: GenAiOutputTokensPerUserPerDay	15.000.000.000	Vom LLM verwendete Ausgabe- und Thought-Tokens. Gilt pro Tag, Projekt und Nutzer.

Cloud AI-Dienstfunktionen

Für Funktionen, die Cloud AI-Dienste verwenden, gelten die folgenden Limits:

Funktion	Anfragen pro Minute	Zeilen pro Job	Anzahl gleichzeitig ausgeführter Jobs
ML.PROCESS_DOCUMENT mit Dokumenten mit durchschnittlich 50 Seiten	600	100.000 (basierend auf durchschnittlich 50 Seiten pro Eingabedokument)	5
ML.TRANSCRIBE	200	10.000 (basierend auf einer durchschnittlichen Länge von 1 Minute pro Audiodatei)	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 zu Kontingenten für Cloud AI-Dienst-APIs finden Sie in den folgenden Dokumenten:

• Kontingente und Limits für die Cloud Translation API
• Vision API-Kontingente und -Limits
• Kontingente und Limits der Natural Language API
• Document AI-Kontingente und -Limits
• Speech-to-Text-Kontingente und -Limits

Definitionen von Funktionskontingenten

In der folgenden Liste werden die Kontingente für generative KI und Cloud AI-Dienstfunktionen beschrieben:

• Für Funktionen, die ein Agent Platform-Modell aufrufen, wird ein Agent Platform-Kontingent verwendet, das in Abfragen pro Minute (QPM) angegeben wird. In diesem Kontext sind die Abfragen Anfrageaufrufe von der Funktion an die API des Agent Platform-Modells. Das QPM-Kontingent gilt für ein Basismodell und alle Versionen, Kennungen und abgestimmten Versionen dieses Modells. Weitere Informationen zu den Modellkontingenten der Agent Platform finden Sie unter Kontingentlimits für generative KI auf der Agent Platform.
• Funktionen, die einen Cloud AI-Dienst aufrufen, verwenden die Anfragekontingente des Zieldienstes. Weitere Informationen finden Sie in der Kontingentreferenz des jeweiligen Cloud AI-Dienstes.

• BigQuery ML verwendet die folgenden Kontingente:

  • Anfragen pro Minute. Dieses Kontingent ist das Limit für die Anzahl der Anfrageaufrufe pro Minute, die Funktionen an die API des Agent Platform-Modells oder des Cloud AI-Dienstes senden können. Dieses Limit gilt für jedes Projekt und wird von allen Jobs gemeinsam genutzt, die denselben Modellendpunkt verwenden.

    Für Aufrufe von Gemini-Modellen in der Agent Platform gibt es keine vordefinierten Kontingentlimits, da Gemini-Modelle ein dynamisches gemeinsam genutztes Kontingent (DSQ) verwenden. DSQ bietet Zugriff auf einen großen gemeinsamen Ressourcenpool, der dynamisch basierend auf der Echtzeitverfügbarkeit von Ressourcen und der Kundennachfrage nach dem jeweiligen Modell zugewiesen wird.

  • Tokens pro Minute. Dieses Kontingent ist das Limit für die Anzahl der Tokens pro Minute, die Funktionen an die API des Agent Platform-Modells senden können. Dieses Limit gilt für jedes Projekt.

    Bei Funktionen, die ein Foundation Model der Agent Platform aufrufen, variiert die Anzahl der Tokens pro Minute je nach Modellendpunkt, Version und Region der Agent Platform sowie der Bewertung Ihres Projekts. Dieses Kontingent entspricht konzeptionell dem QPM-Kontingent, das von der Agent Platform verwendet wird.

  • Zeilen pro Job Der Wert Rows per job dient als Leistungsbenchmark und gibt die ungefähre Verarbeitungskapazität an, wenn ein einzelner Job die Ressourcen des Modellendpunkts des Projekts exklusiv nutzt. Die tatsächliche Anzahl der verarbeiteten Zeilen hängt von vielen Faktoren ab, darunter die Größe der Eingabeanfrage an das Modell, die Größe der Ausgabeantworten des Modells und die Verfügbarkeit des dynamischen freigegebenen Kontingents. Die folgenden Beispiele zeigen einige gängige Szenarien:

    • Beim Endpunkt gemini-2.0-flash-lite-001 hängt die Anzahl der Zeilen, die von der Funktion AI.GENERATE_TEXT oder ML.GENERATE_TEXT verarbeitet werden können, von der Anzahl der Eingabe- und Ausgabetokens ab. Der Dienst kann etwa 7,6 Millionen Zeilen für Aufrufe mit einer durchschnittlichen Eingabe-Tokenanzahl von 2.000 und einer maximalen Ausgabe-Tokenanzahl von 50 verarbeiten. Diese Zahl sinkt auf etwa 1 Million Zeilen, wenn die durchschnittliche Anzahl der Eingabetokens 10.000 und die maximale Anzahl der Ausgabetokens 3.000 beträgt.

      Ähnlich kann der Endpunkt gemini-2.0-flash-001 4,4 Millionen Zeilen für Aufrufe mit einer durchschnittlichen Anzahl von 2.000 Eingabetokens und einer maximalen Anzahl von 50 Ausgabetokens verarbeiten, aber nur etwa 1 Million Zeilen für Aufrufe mit 10.000 Eingabe- und 3.000 Ausgabetokens.

    • Die Funktion ML.PROCESS_DOCUMENT kann bei kurzen Dokumenten mehr Zeilen pro Job verarbeiten als bei langen Dokumenten.

    • Die Funktion ML.TRANSCRIBE kann bei kurzen Audioclips mehr Zeilen pro Job verarbeiten als bei langen Audioclips.

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

Die folgenden Beispiele zeigen, wie Kontingentbeschränkungen in typischen Situationen interpretiert werden:

• Ich habe ein Kontingent von 1.000 QPM in der Agent Platform. Eine Abfrage mit 100.000 Zeilen sollte also etwa 100 Minuten dauern. Warum dauert die Ausführung des Jobs länger?

  Die Joblaufzeiten können selbst bei denselben Eingabedaten variieren. In der Agent Platform haben Remote-Prozeduraufrufe (RPCs) unterschiedliche Prioritäten, um einen übermäßigen Kontingentverbrauch zu vermeiden. Wenn nicht genügend Kontingent vorhanden ist, warten RPCs mit niedrigerer Priorität und schlagen möglicherweise fehl, wenn die Verarbeitung zu lange dauert.

• Wie ist das Kontingent für Zeilen pro Job zu interpretieren?

  In BigQuery kann eine Abfrage bis zu sechs Stunden lang ausgeführt werden. Die maximal unterstützte Anzahl von Zeilen hängt von diesem Zeitrahmen und Ihrem QPM-Kontingent für die Agent-Plattform ab, damit BigQuery die Abfrageverarbeitung innerhalb von sechs Stunden abschließen kann. Da eine Abfrage in der Regel nicht das gesamte Kontingent nutzen kann, ist diese Zahl niedriger als Ihr 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 für Zeilen pro Job angegeben ist. Ihnen werden nur die erfolgreichen API-Aufrufe für diese Anzahl von Zeilen in Rechnung gestellt, nicht die gesamten 10.000.000 Zeilen in Ihrer Tabelle. Für die restlichen Zeilen antwortet BigQuery auf die Anfrage 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 habe viel mehr Zeilen zu verarbeiten, als das Kontingent für Zeilen pro Job beträgt. Hilft es, wenn ich meine Zeilen auf mehrere Abfragen aufteile und sie gleichzeitig ausführe?

  Nein, da diese Abfragen dasselbe Kontingent für BigQuery ML-Anfragen pro Minute und das QPM-Kontingent für die Agent Platform verbrauchen. Wenn mehrere Abfragen vorhanden sind, die alle innerhalb des Kontingents für Zeilen pro Job und des Kontingents für die Anzahl gleichzeitig ausgeführter Jobs liegen, wird das Kontingent für Anfragen pro Minute durch die kumulative Verarbeitung ausgeschöpft.

BigQuery-Graph

Für BigQuery Graph gelten die folgenden Limits:

Systemlimit	Standard	Hinweise
Maximale Anzahl von Tabellen, auf die ein Graph verweist	1.000 Tabellen	Ein Graph kann in seinen Knoten- und Kantendefinitionen auf insgesamt bis zu 1.000 Knoten- und Kantentabellen verweisen.
Maximale Anzahl von Schlüsselspalten pro Knoten- oder Kantentabelle	16 Spalten	Sie können einen Schlüssel definieren, der bis zu 16 Spalten in einer Knoten- oder Edge-Tabelle eines Graphen verwendet.
Maximale Anzahl von Spalten pro Knotenreferenz	16 Spalten	Ein Quell- oder Zielschlüssel kann auf bis zu 16 Spalten aus einer Knotentabelle in einem Diagramm verweisen.
Maximale Anzahl von Spalten pro Kantenreferenz	16 Spalten	Der Quell- oder Zielschlüssel einer Kante kann auf bis zu 16 Spalten aus der Kantentabelle verweisen.
Maximale Anzahl von Labels in einem Diagramm	1.000 Labels	Sie können in einem Diagramm insgesamt bis zu 1.000 Knoten- und Kantenlabels definieren.
Maximale Anzahl von Labels, die pro Knoten oder Edge definiert sind	20 Labels	Sie können bis zu 20 Labels für einen Knoten oder eine Kante in einem Graphen definieren.
Maximale Anzahl von Attributen, die in einem Diagramm definiert sind	5.000 Properties	Sie können bis zu 5.000 Attribute für einen Graphen definieren.
Maximale Anzahl von Attributen, die pro Label definiert werden können	1.000 Properties	Sie können bis zu 1.000 Attribute pro Label in einem Diagramm definieren.

BI Engine

Für BigQuery BI Engine gelten die folgenden Limits.

Systemlimit	Standard	Hinweise
Maximale Reservierungsgröße pro Projekt und Standort (BigQuery BI Engine)	250 GiB	250 GiB ist die standardmäßige maximale Reservierungsgröße pro Projekt und Standort. 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 je nach Umfang der angeforderten Erhöhung 3 oder mehr Arbeitstage in Anspruch nehmen. Wenden Sie sich bei dringenden Anfragen an Ihren Google Cloud-Ansprechpartner oder an Cloud Customer Care.
Maximale Anzahl von Zeilen pro Abfrage	7 Milliarden	Maximale Anzahl von Zeilen pro Abfrage.

BigQuery Sharing (früher Analytics Hub)

Die folgenden Limits gelten für BigQuery Sharing (früher Analytics Hub):

Systemlimit	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 BigQuery-Sharing-Abonnenten können zusammen maximal 1.000 verknüpfte Datasets pro freigegebenem Dataset haben.

Automatische Erkennung im Knowledge Catalog

Für die automatische Erkennung von Knowledge Catalog gelten die folgenden Limits:

Systemlimit	Standard	Hinweise
Maximale Anzahl von BigQuery-, BigLake- oder externen Tabellen pro Cloud Storage-Bucket, die ein Discovery-Scan unterstützt	1.000 BigQuery-Tabellen pro Bucket	Sie können bis zu 1.000 BigQuery-Tabellen pro Cloud Storage-Bucket erstellen.

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	Messwert- und Kontingent-ID	Standard	Notes
Anfragen pro Tag	Messwert: bigquery.googleapis.com/unlimited_requests Kontingent-ID: UnlimitedRequestsPerDayPerProject	Unbegrenzt	Ihr Projekt kann eine unbegrenzte Anzahl von BigQuery API-Anfragen pro Tag stellen.
Maximal tabledata.list Byte pro Minute	Messwerte: bigquery.googleapis.com/quota/tabledata/list_bytes_us, bigquery.googleapis.com/quota/tabledata/list_bytes_eu, bigquery.googleapis.com/quota/tabledata/list_bytes_regional Kontingent-IDs: ListBytesPerSecondUs, ListBytesPerSecondEu, ListBytesPerSecondRegional	7,5 GB in Multiregionen; 3,7 GB in allen anderen Regionen	Ihr Projekt kann maximal 7,5 GB an Tabellenzeilendaten pro Minute über tabledata.list in den Multiregionen 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. Informationen zur Fehlerbehebung finden Sie auf der Seite zur Fehlerbehebung. Die BigQuery Storage Read API kann einen deutlich höheren Durchsatz als tabledata.list erreichen. 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 Systemlimits gelten für BigQuery API-Anfragen (Kern):

Hinweis: Die meisten BigQuery API-Kernmethoden haben ein Limit von maximal 100 API-Anfragen pro Nutzer und Methode. Einige Kernmethoden können jedoch andere Ratenlimits haben.

Systemlimit	Wert	Hinweise
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. Informationen zur Fehlerbehebung finden Sie auf der Seite zur Fehlerbehebung.
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 der Transcodierung erzwungen.
Maximale projects.list-Anfragen pro Sekunde	10 Anfragen	Ein Nutzer kann bis zu 10 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 Referenz: API-Limits und -Kriterien.
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 der Transcodierung erzwungen.
Maximale tables.insert-Anfragen pro Sekunde	10 Anfragen	Ein Nutzer kann bis zu 10 tables.insert-Anfragen pro Sekunde senden. Mit der Methode tables.insert wird eine neue, leere Tabelle in einem Dataset erstellt.

BigQuery Connection API

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

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
Leseanfragen pro Minute	Messwert: bigqueryconnection.googleapis.com/read_requests Kontingent-ID: ReadRequestsPerMinutePerProject	1000 Anfragen pro Minute	Ihr Projekt kann bis zu 1.000 Anfragen pro Minute an BigQuery Connection API-Methoden senden, die Verbindungsdaten lesen.
Schreibanfragen pro Minute	Messwert: bigqueryconnection.googleapis.com/write_requests Kontingent-ID: WriteRequestsPerMinutePerProject	100 Anfragen pro Minute	Ihr Projekt kann bis zu 100 Anfragen pro Minute an BigQuery Connection API-Methoden senden, die Verbindungen erstellen oder aktualisieren.
Erstellte BigQuery Omni-Verbindungen pro Minute	Messwert: bigqueryconnection.googleapis.com/bq_omni_connection_creations Kontingent-ID: BQOmniConnectionsCreatedPerMinute	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	Messwert: bigqueryconnection.googleapis.com/bq_omni_connection_uses Kontingent-ID: BQOmniConnectionUsesPerMinute	500 Verbindungsnutzungen pro Minute	Ihr Projekt kann eine BigQuery Omni-Verbindung bis zu 500-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 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	Messwert- und Kontingent-ID	Standard	Notes
EDWMigration Service-List-Anfragen pro Minute	Messwert: bigquerymigration.googleapis.com/edwmigration_service_list_requests Kontingent-ID: ListRequestsPerMinutePerProject	12.000 Anfragen	Ihr Projekt kann bis zu 12.000 Migration API-List-Anfragen pro Minute senden.
EDWMigration Service-List-Anfragen pro Minute und Nutzer	Messwert: bigquerymigration.googleapis.com/edwmigration_service_list_requests Kontingent-ID: ListRequestsPerMinutePerProjectPerUser	2.500 Anfragen	Jeder Nutzer kann bis zu 2.500 Migration API-List-Anfragen pro Minute senden
EDWMigration Service-Get-Anfragen pro Minute	Messwert: bigquerymigration.googleapis.com/edwmigration_service_get_requests Kontingent-ID: GetRequestsPerMinutePerProject	25.000 Anfragen	Ihr Projekt kann bis zu 25.000 Migration API-Get-Anfragen pro Minute senden.
EDWMigration Service-Get-Anfragen pro Minute und Nutzer	Messwert: bigquerymigration.googleapis.com/edwmigration_service_get_requests Kontingent-ID: GetRequestsPerMinutePerProjectPerUser	2.500 Anfragen	Jeder Nutzer kann bis zu 2.500 Migration API-Get-Anfragen pro Minute senden.
Weitere EDWMigration Service-Anfragen pro Minute	Messwert: bigquerymigration.googleapis.com/edwmigration_service_other_requests Kontingent-ID: OtherRequestsPerMinutePerProject	25 Anfragen	Ihr Projekt kann bis zu 25 weitere Migration API-Anfragen pro Minute senden.
Weitere EDWMigration Service-Anfragen pro Minute und Nutzer	Messwert: bigquerymigration.googleapis.com/edwmigration_service_other_requests Kontingent-ID: OtherRequestsPerMinutePerProjectPerUser	5 Anfragen	Jeder Nutzer kann bis zu 5 weitere Migration API-Anfragen pro Minute senden.
Interaktive SQL-Übersetzungsanfragen pro Minute	Messwert: bigquerymigration.googleapis.com/sql_translation_translate_requests Kontingent-ID: TranslationRequestsPerMinutePerProject	200 Anfragen	Ihr Projekt kann bis zu 200 SQL-Übersetzungs-Dienstanfragen pro Minute senden.
Interaktive SQL-Übersetzungsanfragen pro Minute und Nutzer	Messwert: bigquerymigration.googleapis.com/sql_translation_translate_requests Kontingent-ID: TranslationRequestsPerMinutePerProjectPerUser	50 Anfragen	Jeder Nutzer kann bis zu 50 SQL-Übersetzungs-Dienstanfragen pro Minute senden.

Die folgenden Systemlimits gelten für die BigQuery Migration API:

Systemlimit	Wert	Hinweise
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. Wenn Sie interaktive Übersetzungen mit der Translation API ausführen, 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 .
Maximale Anzahl von Gemini-Vorschlägen pro Stunde	1.000 (kann auf bis zu 10.000 erhöht werden, wenn nicht verwendet)	Bei Bedarf können Sie eine Kontingenterhöhung über Cloud Customer Care anfordern.

BigQuery Reservation API

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

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
Anfragen pro Minute und Region	Messwert: bigqueryreservation.googleapis.com/requests Kontingent-ID: RequestsPerMinutePerProjectPerRegion	100 Anfragen	Ihr Projekt kann insgesamt bis zu 100 Aufrufe an die BigQuery Reservation API-Methoden pro Minute und Region senden.
Anzahl von SearchAllAssignments-Aufrufen pro Minute und Region	Messwert: bigqueryreservation.googleapis.com/search_all_assignments_requests Kontingent-ID: SearchAllAssignmentsRequestsPerMinutePerProjectPerRegion	100 Anfragen	Ihr Projekt kann bis zu 100 Aufrufe an die Methode SearchAllAssignments pro Minute und Region senden.
Anfragen für SearchAllAssignments pro Minute, Region und Nutzer	Messwert: bigqueryreservation.googleapis.com/search_all_assignments_requests Kontingent-ID: SearchAllAssignmentsRequestsPerMinutePerProjectPerUserPerRegion	10 Anfragen	Jeder Nutzer kann bis zu 10 Aufrufe an die Methode SearchAllAssignments pro Minute und Region senden.

BigQuery DataPolicy API

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

Systemlimit	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: dataPolicies.create dataPolicies.delete dataPolicies.setIamPolicy dataPolicies.patch

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.

Hinweis: Wenn es IAM-Anfragebeschränkungen gibt, sollten Sie prüfen, ob Ihr Projekt die IAM-Berechtigungsübernahme verwenden kann, um die Einschränkung zu verringern.

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
IamPolicy Anfragen pro Minute und Nutzer	Messwert: bigquery.googleapis.com/iam_policy_requests Kontingent-ID: IamPolicyRequestsPerMinutePerUser	1.500 Anfragen pro Minute und Nutzer	Jeder Nutzer kann bis zu 1.500 Anfragen pro Minute und Projekt stellen.
IamPolicy-Anfragen pro Minute und Projekt	Messwert: bigquery.googleapis.com/iam_policy_requests Kontingent-ID: IamPolicyRequestsPerMinutePerProject	3.000 Anfragen pro Minute und Projekt	Ihr Projekt kann bis zu 3.000 Anfragen pro Minute senden.
Einzelne Region: SetIAMPolicy Anfragen pro Minute und Projekt	Messwert: bigquery.googleapis.com/set_iam_policy_requests Kontingent-ID: SetIamPolicyRequestsPerMinutePerProject	1.000 Anfragen pro Minute und Projekt	Ihr Projekt in einer einzelnen Region kann bis zu 1.000 Anfragen pro Minute senden.
Multiregional: SetIAMPolicy Anfragen pro Minute und Projekt	Messwert: bigquery.googleapis.com/set_iam_policy_requests_global Kontingent-ID: SetIamPolicyRequestsPerMinutePerProjectGlobal	2.000 Anfragen pro Minute und Projekt	Ihr multiregionales Projekt kann bis zu 2.000 Anfragen pro Minute senden.
Omni-Region SetIAMPolicy Anfragen pro Minute und Projekt	Messwert: bigquery.googleapis.com/set_iam_policy_requests_OMNI_REGION (z. B. bigquery.googleapis.com/set_iam_policy_requests_aws-us-east-1) Kontingent-ID: SetIamPolicyRequestsPerMinutePerProjectOMNI_REGION (z. B. SetIamPolicyRequestsPerMinutePerProjectAwsUsEast1)	200 Anfragen pro Minute und Projekt	Ihr Omni-Region-Projekt kann bis zu 200 Anfragen pro Minute senden.

Storage Read API

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

Kontingent	Messwert- und Kontingent-ID	Standard	Notes
Leseanfragen auf Datenebene pro Minute und Nutzer	Messwert: bigquerystorage.googleapis.com/data_plane_requests Kontingent-ID: DataPlaneRequestsPerMinutePerProjectPerUser	25.000 Anfragen	Jeder Nutzer kann bis zu 25.000 ReadRows-Aufrufe pro Minute und Projekt ausführen.
Maximale Anzahl gleichzeitiger Leseverbindungen	Messwerte: bigquerystorage.googleapis.com/read/max_concurrent_connections_us, bigquerystorage.googleapis.com/read/max_concurrent_connections_eu, bigquerystorage.googleapis.com/read/max_concurrent_connections_region Kontingent-IDs: MaxConcurrentReadConnectionsPerProjectUS, MaxConcurrentReadConnectionsPerProjectEU, MaxConcurrentReadConnectionsPerProjectRegion	2.000 in Multiregionen; 400 in Regionen	Maximale Anzahl gleichzeitiger ReadRows-Verbindungen pro Projekt. Der Standardwert ist 2.000 Verbindungen in den Multiregionen us und eu und 400 Verbindungen in anderen Regionen. Die tatsächliche Verfügbarkeit von Verbindungen kann je nach Dienstlast und Nachfrage in der gesamten Region schwanken. Diese dynamische Anpassung sorgt für eine faire Ressourcenverteilung und die Stabilität des Dienstes für alle Nutzer. Wenn ein Stream aus Fairnessgründen geschlossen wird oder Sie das Verbindungslimit erreichen, erhalten Sie den Fehler RESOURCE_EXHAUSTED (HTTP 429). Anfragen zur Kontingenterhöhung werden anhand der bisherigen Nutzungsmuster des Projekts und der allgemeinen Verfügbarkeit von Ressourcen in der Region geprüft.
Leseanfragen auf Steuerungsebene pro Minute und Nutzer	Messwert: bigquerystorage.googleapis.com/control_plane_requests Kontingent-ID: ControlPlaneRequestsPerMinutePerProjectPerUser	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.

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

Systemlimit	Wert	Hinweise
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 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 (gRPC)

Die folgenden Kontingente gelten für Storage Write API (gRPC)-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.

Hinweis: Projekte, für die die Kontingenterzwingung auf Ordnerebene aktiviert ist, können nur die Kontingentnutzung und das Limit auf Ordnerebene auf der Seite „Kontingente“ der Google Cloud Console prüfen. Kontingentnutzung und -limit auf Projektebene werden nicht angezeigt. In diesem Fall sind die Monitoringmesswerte auf Projektebene weiterhin eine gute Quelle für die Nutzung auf Projektebene.

Hinweis: Aufgrund der Leistungsoptimierung meldet BigQuery möglicherweise eine höhere Kontingentnutzung für gleichzeitige Verbindungen als die tatsächliche Kontingentnutzung. Die Abweichung kann bis zu 1 % des Gesamtkontingents oder 100 Verbindungen betragen, je nachdem, welcher Wert kleiner ist, multipliziert mit einem Faktor von 1–4. Das bedeutet, dass die gemeldete Nutzung in Multiregionen mit einem Standardkontingent von 10.000 um maximal 400 Verbindungen und in kleinen Regionen mit einem Standardkontingent von 1.000 um maximal 40 Verbindungen abweichen kann. Die Kontingentdurchsetzung basiert immer auf der tatsächlichen Nutzung, nicht auf dem gemeldeten Wert.

Wenn Sie eine Kontingentanpassung anfordern möchten, fügen Sie in Ihre Anfrage die Kontingentfehlermeldung ein, um die Verarbeitung zu beschleunigen. BigQuery kann Ihr bereitgestelltes Kontingent reduzieren, wenn es länger als ein Jahr deutlich unterausgelastet ist.

Kontingent	Messwert- und Kontingent-ID	Standard	Hinweise
Gleichzeitige Schreibverbindungen	Messwerte: bigquerystorage.googleapis.com/write/max_active_streams, bigquerystorage.googleapis.com/write/max_active_streams_eu, bigquerystorage.googleapis.com/write/max_active_streams_region Kontingent-IDs: ConcurrentWriteConnectionsPerProject, ConcurrentWriteConnectionsPerProjectEU, ConcurrentWriteConnectionsPerProjectRegion	5.000 in einer Region; 20.000 in einer Multiregion	Das Kontingent für gleichzeitige Verbindungen basiert auf dem Clientprojekt, das die Storage Write API-Anfrage (gRPC) 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 5.000 gleichzeitige Verbindungen in einer Region oder 20.000 gleichzeitige Verbindungen in den Multiregionen US und EU ausgeführt werden. Eine Verbindung sollte langlebig sein und zum Senden möglichst vieler Anfragen verwendet werden. Die Verwendung kurzlebiger Verbindungen wird nicht empfohlen und kann zu einer übermäßigen Nutzung des Kontingents für gleichzeitige Verbindungen führen. Für die Kontingentabrechnung empfehlen wir eine Verbindungsdauer von mindestens mehreren Minuten. Wenn Sie den Standardstream in Java oder Go verwenden, empfehlen wir, Storage Write API (gRPC)-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. 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	Messwerte: bigquerystorage.googleapis.com/write/append_bytes, bigquerystorage.googleapis.com/write/append_bytes_eu, bigquerystorage.googleapis.com/write/append_bytes_region Kontingent-IDs: AppendBytesThroughputPerProject, AppendBytesThroughputPerProjectEU, AppendBytesThroughputPerProjectRegion	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. 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	Messwerte: bigquerystorage.googleapis.com/write/create_stream_requests, bigquerystorage.googleapis.com/write/create_stream_requests_eu, bigquerystorage.googleapis.com/write/create_stream_requests_region Kontingent-IDs: CreateWriteStreamRequestsPerMinutePerProject, CreateWriteStreamRequestsPerMinutePerProjectEU, CreateWriteStreamRequestsPerMinutePerProjectRegion	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, aber der in der Google Cloud Console angezeigte Messwert gilt pro Minute.
Ausstehende Stream-Byte	Messwerte: bigquerystorage.googleapis.com/write/pending_stream_bytes, bigquerystorage.googleapis.com/write/pending_stream_bytes_eu, bigquerystorage.googleapis.com/write/pending_stream_bytes_region Kontingent-IDs: PendingWriteStreamBytesPerProject, PendingWriteStreamBytesPerProjectEU, PendingWriteStreamBytesPerProjectRegion	10 TB in Multiregionen; 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 Systemlimits gelten für Storage Write API (gRPC)-Anfragen:

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

Streaming-Insert-Anweisungen

Die folgenden Kontingente und Limits gelten beim Streamen von Daten in BigQuery mithilfe der BigQuery Storage Write API (REST). Informationen zu Strategien, um innerhalb dieser Limits zu bleiben, finden Sie unter Kontingentfehler beheben. Wenn Sie diese Kontingente überschreiten, gibt BigQuery den Fehler quotaExceeded zurück. BigQuery kann Ihr bereitgestelltes Kontingent reduzieren, wenn es länger als ein Jahr deutlich unterausgelastet ist.

Kontingent	Messwert- und Kontingent-ID	Standard	Hinweise
Maximale Byte pro Sekunde und Projekt in den Multiregionen us und eu	Messwerte: bigquery.googleapis.com/quota/streaming/insert_bytes_us, bigquery.googleapis.com/quota/streaming/insert_bytes_eu Kontingent-IDs: StreamingInsertBytesPerSecondUs, StreamingInsertBytesPerSecondEu	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	Messwert: bigquery.googleapis.com/quota/streaming/insert_bytes Kontingent-ID: StreamingInsertBytesPerSecond	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.

Die folgenden Systemlimits gelten beim Streamen von Daten in BigQuery mithilfe der BigQuery Storage Write API (REST):

Systemlimit	Wert	Hinweise
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. Intern wird die Anfrage von HTTP-JSON in eine interne Datenstruktur übersetzt. Für diese gilt eine eigene feste Größenbeschränkung. Die Größe der resultierenden internen Datenstruktur lässt sich nur schwer vorhersagen. Wenn Sie Ihre HTTP-Anfragen jedoch auf 10 MB oder weniger beschränken, ist die Wahrscheinlichkeit, dass das interne Limit erreicht wird, gering.
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

Die folgenden Kontingente gelten für die Bandbreite der regionenübergreifenden Dataset-Replikation:

Kontingent	Standard	Hinweise
Maximale Bandbreite für die regionenübergreifende Dataset-Replikation beim ersten Backfill für jede Region, die regionenübergreifenden ausgehenden Datentraffic vom primären Replikat zu sekundären Replikaten hat.	10 physische GiB/s pro Region und Organisation
Maximale laufende Bandbreite für die regionenübergreifende Dataset-Replikation für jede Region mit regionenübergreifendem ausgehendem Datentraffic vom primären Replikat zu sekundären Replikaten.	5 physische GiB/s pro Region und Organisation
Maximale Bandbreite für die regionenübergreifende Dataset-Replikation mit Turbo-Replikation für jede Region mit regionenübergreifendem ausgehendem Datentraffic vom primären Replikat zu sekundären Replikaten.	5 physische GiB/s pro Region und Organisation	Das Bandbreitenkontingent für die schnelle regionenübergreifende Dataset-Replikation gilt nicht für den ersten Backfill-Vorgang.

Wenn die Bandbreite für die regionenübergreifende Dataset-Replikation eines Projekts ein bestimmtes Kontingent überschreitet, wird die regionenübergreifende Dataset-Replikation von betroffenen Projekten möglicherweise mit dem Fehler rateLimitExceeded beendet, der Details zum überschrittenen Kontingent enthält.

Die folgenden Kontingente gelten für die Bandbreite beim Kopieren von Tabellen zwischen Regionen:

Kontingent	Standard	Hinweise
Maximale Kopierbandbreite für jede Region mit regionsübergreifendem ausgehendem Datentraffic von der Quelltabelle zur Zieltabelle.	2 physische GiB/s pro Regionspaar und Organisation.