Kontingente und Limits

In diesem Dokument sind die Kontingente und Limits für Bigtable aufgeführt. Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Sie werden von Google Cloud-Diensten wie Bigtable definiert. Systemlimits sind feste Werte, die nicht geändert werden können.

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

Das Cloud-Kontingentsystem ermöglicht Folgendes:

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

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

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

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

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

Hinweis: Bei mehreren Vorgängen, die als ein Batch gesendet werden, wird jeder Vorgang im Batch auf das Kontingent oder Limit angerechnet.

Kontingente

In diesem Abschnitt werden die bei der Nutzung von Bigtable geltenden Standardkontingente erläutert.

Kontingente für administrative Vorgänge

Die folgenden Kontingente wirken sich auf die Anzahl der administrativen Bigtable-Vorgänge (Aufrufe der Admin API) aus, die Sie innerhalb eines bestimmten Zeitraums ausführen können.

Sofern unten nicht anders angegeben, können Sie in der Regel keine Erhöhung der Kontingente für administrative Vorgänge anfordern. Ausnahmen werden manchmal gewährt, wenn es einen sehr guten Grund dafür gibt. Die Anzahl der Aufrufe Ihrer Anwendung an die Admin API sollte jedoch nicht steigen, wenn die Nutzung zunimmt. Geschieht dies doch, ist das häufig ein Zeichen dafür, dass Ihr Anwendungscode unnötige Aufrufe an die Admin API ausführt. In diesem Fall sollten Sie Ihre Anwendung ändern, statt eine Erhöhung des Kontingents für administrative Vorgänge anzufordern.

Tageskontingente werden um Mitternacht (UTC -7/-8) zurückgesetzt.

Name	Beschreibung	Standardkontingent
Instanzen und Cluster
Leseanfragen für Instanzen und Cluster	Konfiguration einer Instanz bzw. eines Clusters (z. B. Instanzname oder Knotenanzahl in einem Cluster) oder eine Liste von Instanzen lesen	Pro Tag und Projekt: 864.000 Vorgänge (durchschnittlich 10 Vorgänge/Sekunde) Pro Minute und Nutzer: 1.000 Vorgänge
Schreibanfragen für Instanzen und Cluster	Konfiguration einer Instanz bzw. eines Clusters (z. B. Instanzname oder Knotenanzahl in einem Cluster) ändern oder eine neue Instanz erstellen	Pro Tag und Projekt: 500 Vorgänge Pro Minute und Nutzer: 100 Vorgänge
Anwendungsprofile
Leseanfragen für Anwendungsprofile	Konfiguration eines Anwendungsprofils lesen	Pro Tag und Projekt: 5.000 Vorgänge Pro Minute und Nutzer: 1.000 Vorgänge
Schreibanfragen für Anwendungsprofile	Konfiguration eines Anwendungsprofils ändern	Pro Minute und Projekt: 500 Vorgänge Pro Minute und Nutzer: 100 Vorgänge
Tables
Leseanfragen für Tabellenverwaltung	Konfiguration einer Tabelle (z. B. Einzelheiten zu den Spaltenfamilien) oder eine Liste von Tabellen lesen	Pro Tag und Projekt: 864.000 Vorgänge (durchschnittlich 10 Vorgänge/Sekunde) Pro Minute und Nutzer: 1.000 Vorgänge
Schreibanfragen für Tabellenadministratoren	Konfiguration einer Tabelle ändern (z. B. die Einstellungen für die Speicherbereinigung für eine Spaltenfamilie)	Pro Tag und Projekt: 5.000 Vorgänge Pro Minute und Nutzer: 100 Vorgänge
Methode DropRowRange	In einem einzelnen Vorgang mehrere Zeilen aus einer Tabelle löschen	Pro Tag und Projekt: 5.000 Vorgänge Pro Minute und Nutzer: 100 Vorgänge
Sicherungen
Sicherungsvorgänge	Sicherungen erstellen, hochladen und löschen	Pro Tag und Projekt: 1.000 Vorgänge Pro Minute und Nutzer: 10 Vorgänge^1
Sicherungs-Abrufanfragen	Sicherungen abrufen und auflisten	Pro Tag und Projekt: 864.000 Vorgänge
Methode RestoreTable	Sicherung in einer neuen Tabelle wiederherstellen	Pro Tag und Projekt: 5.000 Vorgänge Pro Minute und Nutzer: 100 Vorgänge
Identity and Access Management
Detaillierte Get-Anfragen für ACL	Informationen über die IAM-Richtlinie für eine Bigtable-Instanz lesen oder die IAM-Berechtigungen für eine Instanz testen	Pro Tag und Projekt: 864.000 Vorgänge (durchschnittlich 10 Vorgänge/Sekunde) Pro Minute und Nutzer: 1.000 Vorgänge
Detaillierte Set-Anfragen für ACL	IAM-Richtlinie für eine Bigtable-Instanz ändern	Pro Tag und Projekt: 864.000 Vorgänge (durchschnittlich 10 Vorgänge/Sekunde) Pro Minute und Nutzer: 1.000 Vorgänge
Erhöhung des Kontingentlimits möglich

Knotenkontingente

Ein Google Cloud-Projekt enthält Bigtable-Instanzen, die Container für Cluster sind. Ein Cluster stellt den eigentlichen Bigtable-Dienst dar, der in einer Zone ausgeführt wird. Cluster enthalten Knoten, bei denen es sich um Rechenressourcen handelt, mit denen Bigtable Ihre Daten verwaltet.

Die Standardanzahl der Knoten, die Sie pro Zone in jedem Projekt bereitstellen können, hängt von der Region ab. Sie können bis zur Standardanzahl von HDD-Knoten und bis zur Standardanzahl von SSD-Knoten pro Zone in einem Projekt bereitstellen.

Die standardmäßigen Knotenkontingente sind:

Region	SSD	HDD
asia-east1	100	100
europe-west1	200	200
us-central1	200	200
us-east1	50	50
us-east4	50	50
us-west1	100	100
Alle anderen Bigtable-Standorte	30	30

Wenn Sie das Autoscaling für einen Cluster aktivieren, wird die konfigurierte maximale Anzahl von Knoten auf dieses Limit angerechnet, auch wenn der Cluster nicht auf diese Anzahl von Knoten skaliert wird. Falls Sie mehr Knoten benötigen, als die Standardlimits zulassen, können Sie eine Erhöhung beantragen.

Kontingente und Knotenverfügbarkeit

Das Knotenkontingent ist die maximale Anzahl von Knoten, die Sie pro Zone in jedem Projekt bereitstellen können. Kontingente garantieren jedoch nicht, dass immer Knoten zu einem Cluster hinzugefügt werden können. Wenn eine Zone außerhalb der Knoten liegt, können Sie einem Cluster in dieser Zone möglicherweise keine Knoten hinzufügen, auch wenn in Ihrem Projekt noch ausreichendes Kontingent dafür vorhanden ist.

Wenn Sie beispielsweise versuchen, einem Cluster mit 20 Knoten 10 SSD-Knoten hinzuzufügen, die Knoten sich jedoch nicht in der Zone befinden, können Sie diese 10 Knoten nicht hinzufügen, auch wenn das Knotenkontingent für SSD-Knoten in dieser Region 30 ist.

In diesen Fällen versuchen wir, die Knotenressourcen einer Zone zu erhöhen und Ihre Anfragen zu bearbeiten, sobald diese Ressourcen verfügbar sind, wobei wir keine Garantie für den Zeitpunkt und die Fertigstellung geben können.

Die von Ihnen bereitgestellten Knoten sind immer verfügbar.

Data Boost-Kontingente

Die folgenden SPU-Kontingente gelten pro Projekt und pro Region.

Region	SPUs
asia-east1	100.000
europe-west1	200.000
us-central1	200.000
us-east1	100.000
us-east4	100.000
us-west1	100.000
Alle anderen Bigtable-Standorte	30.000

Weitere Informationen zu Data Boost finden Sie in der Data Boost-Übersicht.

Kontingentinformationen ansehen

Die Anzahl der verfügbaren SSD- und HDD-Knoten in jeder Zone Ihres Google Cloud-Projekts finden Sie in der Google Cloud Console. Bewegen Sie den Mauszeiger im linken Navigationsbereich auf IAM & Verwaltung, klicken Sie auf Kontingente und wählen Sie im Drop-down Dienst die Bigtable Admin API aus.

Die nun angezeigte Seite enthält Zeilen mit Kontingenten für alle Kombinationen aus Dienst, Knotentyp und Standort. Achten Sie auf die Zeilen mit der Bezeichnung SSD-Knoten pro Zone oder HDD-Knoten pro Zone. Die Spalte Limit enthält die maximal zulässige Zahl von Knoten für den jeweiligen Knotentyp und Standort. In der Spalte Aktuelle Nutzung finden Sie die Zahl der derzeit vorhandenen Knoten. Die Differenz zwischen diesen beiden Zahlen gibt an, wie viele Knoten Sie hinzufügen können, ohne ein höheres Kontingent anfordern zu müssen.

Erhöhung des Knotenkontingents anfordern

Um genügend Zeit für die Verarbeitung Ihrer Anfrage zu haben, sollten Sie immer vorausplanen und zusätzliche Ressourcen anfordern, bevor Sie sie benötigen. Anfragen für Erhöhungen von Knotenkontingenten werden nicht garantiert gewährt. Weitere Informationen finden Sie unter Mit Kontingenten arbeiten.

Sie benötigen mindestens Berechtigungen auf Bearbeiter-Ebene für das Projekt, das die Instanz enthält, für die Sie eine Erhöhung des Knotenkontingents beantragen.

Es fallen keine Gebühren für die Anforderung eines höheren Knotenkontingents an. Ihre Kosten erhöhen sich nur dann, wenn Sie mehr Ressourcen verwenden.

1. Rufen Sie die Seite Kontingente auf.

   Zur Seite „Kontingente“

2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
3. Klicken Sie oben auf der Seite auf die Schaltfläche Kontingente bearbeiten.
4. Geben Sie rechts Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie dann auf Weiter.
5. Geben Sie das neue Kontingentlimit ein, das Sie anfordern möchten, und klicken Sie auf Weiter.
6. Senden Sie die Anfrage.

Limits

In diesem Abschnitt werden die bei Ihrer Nutzung von Bigtable geltenden Limits erläutert. Limits sind in den Dienst eingebunden und können nicht geändert werden.

Anwendungsprofile pro Instanz

Jede Instanz kann maximal 2.000 Anwendungsprofile haben.

Autorisierte Ansichten

• Autorisierte Ansichten pro Bigtable-Instanz: bis zu 10.000
• Spaltenqualifizierungspräfixe pro autorisierter Ansicht: 10

Sicherungen

• Maximale Anzahl der Standardsicherungen, die erstellt werden können: 150 pro Tabelle und Cluster
• Maximale Anzahl der Hot-Sicherungen, die erstellt werden können: 10 pro Tabelle und Cluster
• Mindestaufbewahrungsdauer einer Sicherung: 6 Stunden nach der ursprünglichen Erstellung
• Maximale Aufbewahrungsdauer einer Sicherung: 90 Tage nach dem ursprünglichen Erstellungsdatum

Data Boost

Mit einem Data Boost-Anwendungsprofil können nicht mehr als 1.000 Leseanfragen pro Sekunde gesendet werden.

Größe von Daten in Tabellen

Empfohlene Limits

Entwerfen Sie Ihr Schema so, dass die Größe Ihrer Daten unter diesen empfohlenen Limits bleibt.

• Spaltenfamilien pro Tabelle: 100
• Einzelner Spaltenqualifizierer: 16 KB
• Einzelner Wert in einer Tabellenzelle: 10 MB
• Alle Werte in einer einzelnen Zeile: 100 MB

Starre Limits

Zusätzlich gelten die folgenden festen Limits, die eingehalten werden müssen:

• Einzelner Zeilenschlüssel: 4 KB
• Einzelner Wert in einer Tabellenzelle: 100 MB
• Alle Werte in einer einzelnen Zeile: 256 MB

Diese Limits werden in binären Kilobyte (KB) und in binären Megabyte (MB) gemessen. 1 KB entspricht dabei 2¹⁰ Byte und 1 MB entspricht 2²⁰ Byte. Diese Maßeinheiten werden auch als Kibibyte (KiB) und Mebibyte (MiB) bezeichnet.

Limits bei Vorgängen

Bei mehreren Mutationen, die als einzelner Batch an Bigtable gesendet werden, gelten die folgenden Limits:

• Ein Batch bedingter Mutationen, die CheckAndMutate aufrufen, kann bis zu 100.000 wahre Mutationen und bis zu 100.000 falsche Mutationen enthalten.

• In Batches aller anderen Mutationenstypen können nicht mehr als 100.000 Mutationen in den Batch aufgenommen werden.

Regionen pro Instanz

Eine Bigtable-Instanz kann Cluster in bis zu acht Regionen haben, in denen Bigtable verfügbar ist. Sie können in jeder Zone in einer Region einen Cluster erstellen. Eine Liste der verfügbaren Zonen finden Sie unter Bigtable-Standorte.

Zeilenfilter

Zeilenfilter dürfen nicht mehr als 20 KB haben. Wenn Ihnen eine Fehlermeldung angezeigt wird, sollten Sie Ihren Filter ändern oder kürzen.

Speicherplatz pro Knoten

Wenn die Knoten im Cluster für die aktuelle Arbeitslast und die gespeicherte Datenmenge nicht ausreichen, hat Bigtable nicht genügend CPU-Ressourcen, um alle mit dem Cluster verknüpften Tabellen zu verwalten. Außerdem ist Bigtable dann nicht in der Lage, wichtige Wartungsaufgaben im Hintergrund auszuführen. Daher kann der Cluster eingehende Requests eventuell nicht verarbeiten und die Latenz kann zunehmen. Weitere Informationen finden Sie unter Kompromisse zwischen Speichernutzung und Leistung.

Zur Vermeidung dieser Probleme sollten Sie die Speicherauslastung für Ihre Cluster überwachen. So können Sie sicherstellen, dass für die Datenmenge im Cluster genug Knoten vorhanden sind. Hierbei gelten die folgenden Limits:

• SSD-Cluster: 5 TB pro Knoten
• HDD-Cluster: 16 TB pro Knoten

Diese Werte werden in binären Terabyte (TB) gemessen. 1 TB entspricht dabei 2⁴⁰ Byte. Diese Maßeinheit wird auch als Tebibyte (TiB) bezeichnet.

Wichtig: Wenn ein Cluster einer Instanz dieses Limit überschreitet, schlagen Schreibvorgänge auf allen Clustern dieser Instanz fehl, bis Sie jedem über dem Limit liegenden Cluster Knoten hinzufügen. Außerdem lehnt Bigtable jeden Versuch zum Entfernen von Knoten aus dem Cluster ab, wenn die reduzierte Anzahl von Knoten dazu führen würde, dass der Cluster das Speicherlimit überschreitet.

Fügen Sie Ihrem Cluster am besten immer ausreichend Knoten hinzu, sodass Sie diese Limits nur zu 70 % ausschöpfen und plötzliche Spitzen in der Speichernutzung abfangen können. Wenn beispielsweise 50 TB Daten in einem Cluster mit SSD-Speicher gespeichert sind, sollten Sie mindestens 15 Knoten bereitstellen, die bis zu 75 TB Daten verarbeiten können. Wenn dem Cluster voraussichtlich keine erhebliche Datenmenge hinzugefügt wird, können Sie diese Empfehlung überschreiten und bis zu 100 % des Limits belegen.

Tabellen pro Instanz

Bigtable unterstützt in jeder Instanz maximal 1.000 Tabellen.

Limits für ID-Längen

Nachfolgend sind die von Bigtable unterstützten minimalen und maximalen ID-Längen (Anzahl der Zeichen) aufgeführt.

• App-Profil: 1-50
• Back-up: 1-50
• Cluster: 6-30
• Spaltenfamilie: 1-64
• Instanz: 6-33
• Tabelle: 1-50
• autorisierte Ansicht: 1–50

Nutzungsbedingungen

Die Nutzung dieses Dienstes muss den Nutzungsbedingungen sowie der Datenschutzerklärung von Google entsprechen.