Seit dem 20. April 2026 heißt BigLake jetzt „Lakehouse for Apache Iceberg“. BigLake Metastore heißt jetzt Lakehouse-Laufzeitkatalog. Lakehouse-APIs, Clientbibliotheken, CLI-Befehle und IAM-Namen bleiben unverändert und verweisen weiterhin auf BigLake.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Kontingente und Systemlimits für das grenzenlose Lakehouse

In diesem Dokument sind die für Lakehouse geltenden Kontingente und Systemlimits 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 dem Cloud-Kontingente – Übersicht.

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

Messwertnamen für Kontingente und Systemlimits abrufen

Kontingente und Systemlimits haben zwei Arten von Namen: Anzeigenamen und Messwertnamen. Anzeigenamen enthalten Leerzeichen und Großbuchstaben, damit sie für Menschen leichter zu lesen sind. Messwertnamen sind in der Regel kleingeschrieben und werden durch Unterstriche anstelle von Leerzeichen getrennt. Das genaue Format hängt vom Dienst ab.

In der folgenden Anleitung wird beschrieben, wie Sie Messwertnamen für Kontingente und System limits entweder über die Google Cloud Console oder die Google Cloud CLI abrufen.

Console

Gehen Sie in der Google Cloud Console zu der IAM und Verwaltung > Kontingente und Systemlimits Seite:

Zur Seite „Kontingente und Systemlimits“

In der Tabelle auf dieser Seite werden Kontingente und Systemlimits mit Nutzung oder angepassten Werten sowie ein Referenzeintrag für andere Kontingente angezeigt. Der Referenzeintrag enthält in der Spalte Name am Ende der Auflistung in Klammern das Wort „standard“. `SetIAM Policy requests per minute per region (default)` ist beispielsweise der Referenzeintrag für das Kontingent` SetIamPolicyRequestsPerMinutePerProject`.
Wenn die Spalte Messwert nicht angezeigt wird, gehen Sie so vor:
1. Klicken Sie auf Spaltenanzeigeoptionen.
2. Wählen Sie Messwert aus.
3. Klicken Sie auf OK. Die Spalte Messwert wird in der Tabelle angezeigt.
In der Spalte Messwert werden die Messwertnamen angezeigt. Wenn Sie die Ergebnisse filtern möchten, geben Sie einen Attributnamen oder -wert in das Feld neben Filter ein.

gcloud

Führen Sie den Befehl quotas info list aus, um die Messwertnamen für einen Dienst mit der gcloud CLI abzurufen. Wenn Sie Zeilen überspringen möchten, in denen keine Messwertnamen aufgeführt sind, leiten Sie die Ausgabe an einen Befehl wie grep mit metric: als Suchbegriff weiter oder verwenden Sie das Flag der gcloud CLI --format:

gcloud quotas info list --project=PROJECT_ID_OR_NUMBER \
    --service=SERVICE_NAME --format="value(metric)"

Ersetzen Sie Folgendes:

PROJECT_ID_OR_NUMBER: die Projekt-ID oder Projektnummer.
SERVICE_NAME: der Name des Dienstes, dessen Kontingentmesswerte Sie sehen möchten. Der Dienstname für Compute Engine ist beispielsweise compute.googleapis.com. Geben Sie den Teil googleapis.com des Dienstnamens an.

Kontingenterhöhung anfordern

Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.

Kontingente

Die folgenden Kontingente gelten für Lakehouse:

Lakehouse-Laufzeitkatalog

Für den Lakehouse-Laufzeitkatalog gelten die folgenden Limits:

Limit Standard Notes

Tabellenänderungen pro Tag

1.500 Änderungen

Limit	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 bei dem Tabellendaten angefügt oder überschrieben werden, zählt als eine Änderung an der Tabelle. Dieses Limit kann nicht erhöht werden. 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. Dazu gehören auch verschachtelte und wiederholte Spalten.

Ihr Projekt kann bis zu 1.500 Tabellenänderungen pro Tabelle und Tag vornehmen. Ein Ladejob, Kopierjob, oder Abfragejob bei dem Tabellendaten angefügt oder überschrieben werden, zählt als eine Änderung an der Tabelle. Dieses Limit kann nicht erhöht werden.

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:
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. Dazu gehören auch verschachtelte und wiederholte Spalten.

Cloudübergreifender Datenzugriff

Quota	Wert
Maximale Gesamtzahl von Namespaces in einem föderierten Katalog	100 Namespaces
Maximale Anzahl von Tabellen pro Namespace in einem föderierten Katalog	300 Tabellen pro Namespace
Maximale Gesamtzahl von Tabellen in einem föderierten Katalog	10.000 Tabellen
Maximale Anzahl von Namespace-Filtern in einem föderierten Katalog	16 Namespace-Filter

System limits

In der folgenden Tabelle sind die Systemlimits für Lakehouse und die Werte für die einzelnen Systemlimits aufgeführt:

System limit	Wert
Maximale Anzahl von Apache Iceberg-Tabellen, die von Lakehouse pro Cloud Storage-Bucket verwaltet werden, das von einem Discovery-Scan unterstützt wird	1.000 Tabellen pro Bucket