Kontingente und Limits

Auf dieser Seite sind die Kontingente und Limits für Cloud Bigtable aufgeführt.

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 oder eines Clusters (z. B. Instanzname oder Anzahl der Knoten 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 oder eines Clusters ändern (z. B. Instanzname oder Anzahl der Knoten in einem Cluster) 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änge1

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

  1. 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
us-west1 100 100
us-central1 200 200
us-east1 50 50
us-east4 50 50
europe-west1 200 200
asia-east1 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.

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 der Sicherungsvorgänge, die erstellt werden können: 50 pro Tabelle und Cluster
  • Minimale Gültigkeitsdauer einer Sicherung: 6 Stunden nach der ursprünglichen Erstellung
  • Maximale Gültigkeitsdauer einer Sicherung: 30 Tage nach der ursprünglichen Erstellung

Größe von Daten in Tabellen

Es hat sich bewährt, beim Entwerfen des Schemas unter diesen empfohlenen Limits zu bleiben:

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

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

  • 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 210 Byte und 1 MB entspricht 220 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.

Zeilenfilter

Ein Zeilenfilter darf nicht größer als 20 KB sein. Wenn Sie eine Fehlermeldung erhalten, sollten Sie den Filter neu gestalten oder verkü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 240 Byte. Diese Maßeinheit wird auch als Tebibyte (TiB) bezeichnet.

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

Nutzungsbedingungen

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