Kontingente und Limits

In diesem Dokument werden die quotas und quotas für Bigtable aufgeführt .

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:

• Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
• Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
• Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
• Möglichkeit, das Kontingent anzufordern oder zu ändern.

Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.

Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Für Bigtable-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.

Hinweis: Wenn Sie mehrere Vorgänge in einem einzelnen Batch senden, 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.

Im Allgemeinen können Sie keine Erhöhung der Kontingente für Administratorvorgänge anfordern, sofern nicht anders angegeben. 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 zunehmen, 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
Tabellen
Leseanfragen für Tabellen	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 Tabellen	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 zur 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 sind keine Garantie dafür, dass Sie einem Cluster immer Knoten hinzufügen 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.

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.

Sicherungen

• Maximale Anzahl von Sicherungen, die erstellt werden können: 150 pro Tabelle und Cluster
• Minimale Aufbewahrungsdauer einer Sicherung: 6 Stunden nach der anfänglichen Erstellung
• Maximale Aufbewahrungsdauer einer Sicherung: 90 Tage nach dem ursprünglichen Erstellungsdatum

Datenauffrischung

Ein Data Boost-Anwendungsprofil kann nicht mehr als 1.000 Leseanfragen pro Sekunde senden.

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

Harte 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

Ein Zeilenfilter darf nicht größer als 20 KB sein. Falls Sie eine Fehlermeldung erhalten, sollten Sie den Filter neu gestalten 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.