Auf dieser Seite werden Produktionskontingente und -limits für Spanner beschrieben. Kontingente und Limits können in der Google Cloud Console synonym verwendet werden.
Die Werte für Kontingente und Limits können sich ändern.
Berechtigungen zum Prüfen und Bearbeiten von Kontingenten
Zum Ansehen Ihrer Kontingente benötigen Sie die Berechtigung serviceusage.quotas.get
Identity and Access Management (IAM).
Zum Ändern Ihrer Kontingente benötigen Sie die IAM-Berechtigung serviceusage.quotas.update
. Diese ist standardmäßig in den vordefinierten Rollen Inhaber, Bearbeiter und Kontingentadministrator enthalten.
Diese Berechtigungen sind standardmäßig in den einfachen IAM-Rollen „Inhaber“ und „Bearbeiter“ sowie in der vordefinierten Rolle Kontingentadministrator enthalten.
Kontingente prüfen
Die aktuell gültigen Kontingente für Ressourcen in Ihrem Projekt finden Sie in der Google Cloud Console:
Kontingente erhöhen
Bei einer intensiveren Nutzung von Spanner können Ihre Kontingente entsprechend erhöht werden. Wenn Sie eine deutlich stärkere Auslastung erwarten, sollten Sie einige Tage im Voraus eine Anfrage stellen, um dafür zu sorgen, dass Ihre Kontingente angemessen sind.
Möglicherweise müssen Sie auch die Überschreibung des Nutzerkontingents erhöhen. Weitere Informationen finden Sie unter Kontingentüberschreibung für Nutzer erstellen.
Sie können das Knotenlimit für die aktuelle Spanner-Instanzkonfiguration über die Google Cloud Console erhöhen.
Rufen Sie die Seite Kontingente auf.
Wählen Sie in der Drop-down-Liste Dienst die Option Spanner API aus.
Wenn Sie die Spanner API nicht sehen, wurde sie nicht aktiviert. Weitere Informationen finden Sie unter APIs aktivieren.
Wählen Sie die Kontingente aus, die Sie ändern möchten.
Klicken Sie auf Kontingente bearbeiten.
Geben Sie im angezeigten Bereich Kontingentänderungen das neue Kontingentlimit ein.
Klicken Sie auf Fertig und dann auf Anfrage senden.
Wenn Sie das Knotenlimit nicht manuell auf das gewünschte Limit erhöhen können, klicken Sie auf Höheres Kontingent beantragen. Füllen Sie das Formular aus, um eine Anfrage an das Spanner-Team zu senden. Sie erhalten innerhalb von 48 Stunden eine Antwort.
Kontingent für eine benutzerdefinierte Instanzkonfiguration erhöhen
Sie können das Knotenkontingent für Ihre benutzerdefinierte Instanzkonfiguration erhöhen.
Prüfen Sie das Knotenlimit einer benutzerdefinierten Instanzkonfiguration. Prüfen Sie dazu das Knotenlimit der Basisinstanzkonfiguration.
Verwenden Sie den Befehl showinstance configuration detail, wenn Sie die Basiskonfiguration der benutzerdefinierten Instanzkonfiguration nicht kennen oder erinnern.
Wenn das erforderliche Knotenlimit für Ihre benutzerdefinierte Instanzkonfiguration weniger als 85 beträgt, folgen Sie der Anleitung im vorherigen Abschnitt Kontingente erhöhen. Verwenden Sie die Google Cloud Console, um das Knotenlimit der Basisinstanzkonfiguration zu erhöhen, die Ihrer benutzerdefinierten Instanzkonfiguration zugeordnet ist.
Wenn das erforderliche Knotenlimit für Ihre benutzerdefinierte Instanzkonfiguration mehr als 85 beträgt, füllen Sie das Formular Kontingenterhöhung für Spanner-Knoten anfordern aus. Geben Sie im Formular die ID der benutzerdefinierten Instanzkonfiguration an.
Knotenlimits
Wert | Limit |
---|---|
Konfiguration von Knoten pro Instanz |
Die Standardlimits variieren je nach Projekt- und Instanzkonfiguration. Informationen zum Ändern der Projektkontingentlimits oder zum Anfordern einer Erhöhung des Limits finden Sie unter Kontingente erhöhen. |
Instanzlimits
Wert | Limit |
---|---|
Länge der Instanz-ID | 2 bis 64 Zeichen |
Limits für kostenlose Testinstanzen
Für eine kostenlose Spanner-Testinstanz gelten die folgenden zusätzlichen Limits. Wenn Sie diese Limits erhöhen oder entfernen möchten, führen Sie ein Upgrade Ihrer kostenlosen Testinstanz auf eine kostenpflichtige Instanz durch.
Wert | Limit |
---|---|
Speicherkapazität | 10 GB |
Datenbanklimit | Bis zu fünf Datenbanken erstellen |
Nicht unterstützte Funktionen | Sichern und Wiederherstellen |
SLA | Keine SLA-Garantien |
Testzeitraum | 90-tägiger kostenloser Testzeitraum |
Limits für die Instanzkonfiguration
Wert | Limit |
---|---|
Maximale Anzahl benutzerdefinierter Instanzkonfigurationen pro Projekt | 100 |
Länge der benutzerdefinierten Instanzkonfigurations-ID | 8 bis 64 Zeichen Eine benutzerdefinierte Instanzkonfigurations-ID muss mit |
Limits für die geografische Partitionierung
Wert | Limit |
---|---|
Maximale Anzahl von Partitionen pro Instanz | 10 |
Maximale Anzahl von Placement-Zeilen pro Knoten in der Partition9 | 20 Millionen |
Datenbanklimits
- Für Instanzen ab 1 Knoten (1.000 Verarbeitungseinheiten): 4 TB pro Knoten
- Für Instanzen mit weniger als 1 Knoten: 409,6 GB pro 100 Verarbeitungseinheiten
Eine erhöhte Speicherkapazität von 10 TB pro Knoten ist für ausgewählte regionale und multiregionale Spanner-Instanzkonfigurationen verfügbar. Weitere Informationen finden Sie unter Leistungs- und Speicherverbesserungen.
Sicherungen werden separat gespeichert und nicht auf dieses Limit angerechnet. Weitere Informationen finden Sie unter Messwerte zur Speicherauslastung.
Beachten Sie, dass Spanner den tatsächlich in einer Instanz genutzten Speicherplatz und nicht den insgesamt verfügbaren Speicher in Rechnung stellt.
Wert | Limit |
---|---|
Datenbanken pro Instanz |
|
Rollen pro Datenbank | 100 |
Länge der Datenbank-ID | 2 bis 30 Zeichen |
Speichergröße1 |
Limits für Sicherung und Wiederherstellung
Wert | Limit |
---|---|
Anzahl der laufenden Vorgänge zum Erstellen von Sicherungen pro Datenbank | 1 |
Anzahl der laufenden Vorgänge zum Wiederherstellen von Datenbanken pro Instanz (in der Instanz der wiederhergestellten Datenbank, nicht der Sicherung) | 10 |
Maximale Aufbewahrungsdauer für Sicherungen | 1 Jahr (einschließlich des zusätzlichen Tages in Schaltjahren) |
Schemalimits
DDL-Anweisungen
Wert | Limit |
---|---|
Größe der DDL-Anweisung für eine einzelne Schemaänderung | 10 MB |
Größe der DDL-Anweisung für das gesamte Schema einer Datenbank, wie von GetDatabaseDdl zurückgegeben |
10 MB |
Tabellen
Wert | Limit |
---|---|
Tabellen pro Datenbank | 5.000 |
Länge des Tabellennamens | 1 bis 128 Zeichen |
Spalten pro Tabelle | 1.024 |
Länge des Spaltennamens | 1 bis 128 Zeichen |
Größe der Daten pro Zelle | 10 MB |
Anzahl der Spalten in einem Tabellenschlüssel | 16 Schließt Schlüsselspalten ein, die für eine übergeordnete Tabelle freigegeben sind |
Tabellen-Verschachtelungstiefe | 7 Eine Tabelle der obersten Ebene mit untergeordneten Tabellen hat die Tiefe 1. Eine Tabelle der obersten Ebene mit um zwei Ebenen untergeordneten Tabellen hat die Tiefe 2 usw. |
Gesamtgröße einer Tabelle oder eines Indexschlüssels | 8 KB Beinhaltet die Größe aller Spalten, aus denen der Schlüssel besteht |
Gesamtgröße der Nicht-Schlüsselspalten | 1.600 MB Beinhaltet die Größe aller Nicht-Schlüsselspalten für eine Tabelle |
Indexe
Wert | Limit |
---|---|
Indexe pro Datenbank | 10.000 |
Indexe pro Tabelle | 128 |
Länge des Indexnamens | 1 bis 128 Zeichen |
Anzahl der Spalten in einem Indexschlüssel | 16 Die Anzahl der indexierten Spalten (außer für STORING-Spalten) plus der Anzahl der primären Schlüsselspalten in der Basistabelle |
Aufrufe
Wert | Limit |
---|---|
Ansichten pro Datenbank | 5.000 |
Länge des Namens anzeigen lassen | 1 bis 128 Zeichen |
Verschachtelungstiefe | 10 Eine Ansicht, die auf eine andere Ansicht verweist, hat eine Verschachtelungstiefe 1. Eine Ansicht, die auf eine andere Ansicht verweist, die auf eine andere Ansicht verweist, hat eine Verschachtelungstiefe 2 usw. |
Abfragelimits
Wert | Limit |
---|---|
Spalten in einer GROUP BY -Klausel |
1.000 |
Werte in einem IN -Operator |
10.000 |
Funktionsaufrufe | 1.000 |
Joins | 20 |
Verschachtelte Funktionsaufrufe | 75 |
Verschachtelte GROUP BY -Klauseln |
35 |
Verschachtelte Unterabfrageausdrücke | 25 |
Verschachtelte Subselect-Anweisungen | 60 |
Parameter | 950 |
Länge der Abfrageanweisung | 1 Million Zeichen |
STRUCT Felder |
1.000 |
Untergeordnete Unterabfrageausdrücke | 50 |
Unions in einer Abfrage | 200 |
Limits beim Erstellen, Lesen, Aktualisieren und Löschen von Daten
Wert | Limit |
---|---|
Commit-Größe (einschließlich Indexe und Änderungsstreams) | 100 MB |
Gleichzeitige Lesevorgänge pro Sitzung | 100 |
Mutationen pro Commit (einschließlich Indexe)2 | 80.000 |
Gleichzeitige partitionierte DML-Anweisungen pro Datenbank | 20.000 |
Administrative Limits
Wert | Limit |
---|---|
Anfragegröße bei administrativen Aktionen3 | 1 MB |
Limit für administrative Aktionen4 | 5 pro Sekunde, Projekt und Nutzer (gemittelt über 100 Sekunden) |
Anfragelimits
Wert | Limit |
---|---|
Anfragegröße außer Commits5 | 10 MB |
Streamlimits ändern
Wert | Limit |
---|---|
Änderungsstreams pro Datenbank | 10 |
Streams ändern, die eine beliebige Nicht-Schlüsselspalte beobachten6 | 3 |
Gleichzeitige Leser pro Änderungsstream-Datenpartition7 | 5 |
Data Boost-Limits
Wert | Limit |
---|---|
Gleichzeitige Data Boost-Anfragen8 | 200 |
Notes
1. Spanner definiert Speicherlimits basierend auf der Rechenkapazität der Instanz, um Hochverfügbarkeit und niedrige Latenz für den Zugriff auf eine Datenbank zu ermöglichen:
- Bei Instanzen mit weniger als einem Knoten (1.000 Verarbeitungseinheiten) weist Spanner 409,6 GB Daten pro 100 Verarbeitungseinheiten in der Datenbank zu.
- Bei Instanzen mit mindestens 1 Knoten weist Spanner jedem Knoten 4 TB Daten zu.
Wenn Sie beispielsweise eine Instanz für eine Datenbank mit 600 GB erstellen möchten, müssen Sie deren Rechenkapazität auf 200 Verarbeitungseinheiten festlegen. Durch diese Rechenkapazität bleibt die Instanz unter dem Limit, bis die Datenbank mehr als 819,2 GB anwächst. Wenn die Datenbank diese Größe erreicht hat, müssen Sie weitere 100 Verarbeitungseinheiten hinzufügen, damit die Datenbank wachsen kann. Andernfalls werden Schreibvorgänge in die Datenbank möglicherweise abgelehnt. Weitere Informationen finden Sie unter Empfehlungen für die Datenbankspeicherauslastung.
Für ein reibungsloses Wachstum sollten Sie Rechenkapazität hinzufügen, bevor das Limit für Ihre Datenbank erreicht ist.
2. Einfüge- und Aktualisierungsvorgänge werden nach der Vielzahl der Spalten gezählt, die sie beeinflussen. Primärschlüsselspalten sind immer betroffen. Das Einfügen eines neuen Eintrags kann als fünf Mutationen zählen, wenn Werte in fünf Spalten eingefügt werden. Das Aktualisieren von drei Spalten in einem Eintrag kann auch als fünf Mutationen zählen, wenn der Datensatz zwei Primärschlüsselspalten enthält. Lösch- und Bereichslöschvorgänge zählen als eine Mutation, unabhängig von der Anzahl der betroffenen Spalten.
Ebenso zählt das Löschen einer Zeile aus einer übergeordneten Tabelle mit der Anmerkung ON DELETE
CASCADE
als eine Mutation, unabhängig von der Anzahl der verschränkten untergeordneten Zeilen. Eine Ausnahme gibt es dann, wenn für zu löschende Zeilen Sekundärindexe definiert sind. Die Änderungen an den Sekundärindexen werden dann einzeln gezählt. Wenn eine Tabelle beispielsweise 2 sekundäre Indexe hat, zählt das Löschen eines Zeilenbereichs in der Tabelle als 1 Mutation für die Tabelle sowie als 2 Mutationen für jede gelöschte Zeile, da die Zeilen im sekundären Index möglicherweise über den Schlüsselbereich verteilt sind, sodass Spanner keinen einzigen Vorgang zum Löschen eines Bereichs für die sekundären Indexe aufrufen kann. Sekundärindexe beinhalten die Sicherungsindexe für Fremdschlüssel.
Informationen zum Ermitteln der Anzahl der Mutationen für eine Transaktion finden Sie unter Commit-Statistiken für eine Transaktion abrufen.
Änderungsstreams fügen keine Mutationen hinzu, die auf dieses Limit angerechnet werden.
3. Das Limit für Anfragen nach administrativen Aktionen betrifft keine Commits, in Anmerkung 5 aufgelisteten Anfragen oder Schemaänderungen.
4. Dieses Limit gilt für alle Aufrufe der Admin API, also auch solche zum Aufrufen von Vorgängen mit langer Ausführungszeit für eine Instanz, Datenbank oder Sicherung.
5. Dieses Limit umfasst folgende Anfragen: Erstellen einer Datenbank, Aktualisieren einer Datenbank, Lesen, Streamen von Lesevorgängen, Ausführen von SQL-Abfragen und Ausführen von Streaming-SQL-Abfragen.
6. Ein Änderungsstream, der eine ganze Tabelle oder Datenbank überwacht, überwacht implizit jede Spalte in dieser Tabelle oder Datenbank und wird daher auf dieses Limit angerechnet.
7. Dieses Limit gilt für gleichzeitige Leser derselben Änderungsstreampartition, unabhängig davon, ob es sich bei den Lesern um Dataflow-Pipelines oder direkte API-Abfragen handelt.
8. Die Standardlimits variieren je nach Projekt und Region. Weitere Informationen finden Sie unter Data Boost-Kontingentnutzung überwachen und verwalten.
9. Die meisten Partitionen haben ein Limit von 20 Millionen Zeilen pro Knoten. Für Partitionen, die die Konfigurationen us-west4
, nam10
und nam-eur-asia1
verwenden, gilt ein Limit von 10 Millionen Zeilen pro Knoten.