Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Schemaaktualisierungen

Mit Cloud Spanner lassen sich Schemas ohne Ausfallzeit aktualisieren. Das Schema einer vorhandenen Datenbank kann mit verschiedenen Methoden aktualisiert werden:

Unterstützte Schemaaktualisierungen

Für das Schema einer vorhandenen Datenbank unterstützt Cloud Spanner folgende Arten von Aktualisierungen:

  • Neue Tabellen erstellen. Spalten in neuen Tabellen können NOT NULL sein.
  • Eine Tabelle löschen, sofern keine anderen Tabellen damit verschränkt sind und die zu löschende Tabelle keine sekundären Indexe hat.
  • Eine Nicht-Schlüsselspalte in eine Tabelle aufnehmen. Neue Nicht-Schlüsselspalten dürfen nicht NOT NULL sein.
  • NOT NULL in eine Nicht-Schlüsselspalte aufnehmen und dabei ARRAY-Spalten ausschließen.
  • NOT NULL aus einer Nicht-Schlüsselspalte entfernen.
  • Eine Nicht-Schlüsselspalte aus einer Tabelle löschen, sofern sie nicht von einem sekundären Index verwendet wird.
  • Eine Spalte des Typs STRING in eine Spalte des Typs BYTES ändern oder umgekehrt (BYTES in STRING).
  • Die Längenbeschränkung für einen STRING- oder BYTES-Typ erhöhen oder verringern (einschließlich auf MAX), es sei denn, es ist eine Primärschlüsselspalte, die von einer oder mehreren untergeordneten Tabellen übernommen werden.
  • Commit-Zeitstempel in Wert- und Primärschlüsselspalten aktivieren oder deaktivieren.
  • Einen beliebigen sekundären Index hinzufügen oder entfernen.

Leistung während der Schemaaktualisierung

Schemaaktualisierungen in Cloud Spanner erfolgen ohne Ausfallzeiten. Wenn Sie einen Batch von DDL-Anweisungen an eine Cloud Spanner-Datenbank absetzen, können Sie ohne Unterbrechung weiter Daten in die Datenbank schreiben und aus ihr lesen, während Cloud Spanner die Aktualisierung als lang laufenden Vorgang durchführt.

Die Ausführungsdauer einer DDL-Anweisung hängt davon ab, ob die Aktualisierung eine Validierung von vorhandenen Daten oder einen Daten-Backfill voraussetzt. Wenn Sie beispielsweise die Annotation NOT NULL in eine vorhandene Spalte aufnehmen, muss Cloud Spanner alle Werte in der Spalte lesen und so gewährleisten, dass die Spalte keine NULL-Werte enthält. Dieser Schritt kann lang dauern, wenn viele Daten validiert werden müssen. Ein anderes Beispiel ist die Erweiterung einer Datenbank um einen Index: Cloud Spanner verwendet dann vorhandene Daten, um einen Backfill für den Index durchzuführen. In Abhängigkeit von der Definition des Index und der Größe der entsprechenden Basistabelle kann dieser Prozess viel Zeit in Anspruch nehmen. Wenn Sie jedoch eine neue Spalte in eine Tabelle einfügen, müssen keine vorhandenen Daten validiert werden, sodass Cloud Spanner die Aktualisierung schneller abwickeln kann.

Zusammenfassend lässt sich sagen, dass Schemaaktualisierungen innerhalb von Minuten durchgeführt werden können, wenn Cloud Spanner keine vorhandenen Daten validieren muss. Schemaaktualisierungen mit Validierung können je nach Menge der zu validierenden vorhandenen Daten länger dauern. Allerdings erfolgt die Datenvalidierung im Hintergrund mit niedrigerer Priorität als Produktionstraffic. Schemaaktualisierungen, die eine Datenvalidierung voraussetzen, werden im nächsten Abschnitt ausführlicher erläutert.

Schemaaktualisierungen mit erforderlicher Datenvalidierung

Sie können Schemaaktualisierungen vornehmen, bei denen überprüft werden muss, ob die vorhandenen Daten den neuen Einschränkungen entsprechen. Wenn für eine Schemaaktualisierung eine Datenvalidierung erforderlich ist, lässt Cloud Spanner keine in Konflikt stehenden Schemaaktualisierungen der betroffenen Schemaentitäten zu und validiert die Daten im Hintergrund. Ist die Validierung erfolgreich, verläuft auch die Schemaaktualisierung erfolgreich. Wenn die Validierung nicht erfolgreich ist, gilt das auch für die Schemaaktualisierung. Validierungsvorgänge sind lang laufende Vorgänge. Anhand des Status dieser Vorgänge können Sie feststellen, ob sie erfolgreich beendet wurden oder fehlgeschlagen sind.

Beispiel: Sie haben in Ihrem Schema die Tabelle Songwriters definiert:

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
) PRIMARY KEY (Id);

In diesem Fall sind folgende Schemaaktualisierungen zulässig, die jedoch validiert werden müssen und je nach Menge der vorhandenen Daten länger dauern können:

  • Die Annotation NOT NULL in eine Nicht-Schlüsselspalte aufnehmen. Beispiel:

    ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL;
    
  • Die Länge einer Spalte verringern. Beispiel:

    ALTER TABLE Songwriters ALTER COLUMN FirstName STRING(10);
    
  • BYTES in STRING ändern. Beispiel:

    ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX);
    
  • Commit-Zeitstempel für eine vorhandene TIMESTAMP-Spalte aktivieren. Beispiel:

    ALTER TABLE Albums ALTER COLUMN LastUpdateTime SET OPTIONS (allow_commit_timestamp = true);
    

Diese Schemaaktualisierungen schlagen fehl, wenn die zugrunde liegenden Daten den neuen Einschränkungen nicht entsprechen. Beispielsweise schlägt die obige Anweisung ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL fehl, wenn in der Spalte Nickname ein Wert NULL ist. In diesem Fall entsprechen die vorhandenen Daten nicht der Einschränkung NOT NULL der neuen Definition.

Die Datenvalidierung kann mehrere Minuten bis viele Stunden andauern. Die Dauer der Datenvalidierung hängt von folgenden Faktoren ab:

  • Größe des Datasets
  • Anzahl der Knoten in der Instanz
  • Auslastung der Instanz

Einige Schemaaktualisierungen können das Verhalten von Anfragen an die Datenbank während der Schemaaktualisierung ändern. Wenn Sie beispielsweise NOT NULL in eine Spalte aufnehmen, beginnt Cloud Spanner nahezu sofort damit, Schreibvorgänge für neue Anfragen abzulehnen, in denen NULL für diese Spalte angegeben ist. Sollte die neue Schemaaktualisierung aufgrund der Datenvalidierung letztendlich fehlschlagen, wurden Schreibvorgänge in einem gewissen Zeitraum blockiert, auch wenn sie vom alten Schema akzeptiert worden wären.

Sie können einen lang andauernden Datenvalidierungsprozess mit der Methode projects.instances.databases.operations.cancel oder mit gcloud spanner operations abbrechen.

Ausführungsreihenfolge von Anweisungen in Batches

Wenn Sie das gcloud-Tool, die REST API oder die RPC API verwenden, können Sie einen Batch von einer oder mehreren CREATE-, ALTER- oder DROP-Anweisungen absetzen.

Cloud Spanner wendet Anweisungen aus demselben Batch entsprechend der Reihenfolge an und hält beim ersten Fehler an. Wenn die Anwendung einer Anweisung zu einem Fehler führt, wird diese Anweisung zurückgesetzt. Die Ergebnisse von vorher angewendeten Anweisungen im Batch bleiben jedoch erhalten.

Unter Umständen kombiniert Cloud Spanner Anweisungen aus verschiedenen Batches und ordnet sie neu an. Dies kann dazu führen, dass Anweisungen aus verschiedenen Batches zu einer atomaren Änderung zusammengefasst werden und diese Änderung dann auf die Datenbank angewendet wird. Die Ausführung von Anweisungen aus verschiedenen Batches erfolgt in jeder atomaren Änderung in zufälliger Reihenfolge. Wenn beispielsweise ein Batch von Anweisungen ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(50) enthält und ein anderer ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(20), belässt Cloud Spanner diese Spalte in einem dieser beiden Zustände, wobei nicht angegeben ist, in welchem.

Während der Schemaaktualisierung erstellte Schemaversionen

Da Cloud Spanner mit Schemaversionierung arbeitet, können Schemas von großen Datenbanken ohne Ausfallzeit aktualisiert werden. Cloud Spanner behält die ältere Schemaversion bei, sodass Lesevorgänge während der Verarbeitung der Schemaaktualisierung möglich sind. Anschließend erstellt Cloud Spanner eine oder mehrere neue Versionen des Schemas, um die Schemaaktualisierung zu verarbeiten. Jede Version enthält das Ergebnis einer Gruppe von Anweisungen in einer einzelnen atomaren Änderung, wie oben beschrieben.

Die Schemaversionen stimmen nicht zwangsläufig eins zu eins mit Batches von DDL-Anweisungen oder einzelnen DDL-Anweisungen überein. Manche einzelne DDL-Anweisungen führen zu mehreren Schemaversionen, beispielsweise solche, die nicht verschränkte Indexe erstellen oder eine Datenvalidierung erfordern. In anderen Fällen können mehrere DDL-Anweisungen in einer einzigen Version zusammengefasst sein. Alte Schemaversionen können erhebliche Server- und Speicherressourcen verbrauchen und bleiben bis zum Ablaufen erhalten. Eine Verwendung von älteren Versionen von Daten ist dann nicht mehr erforderlich.

Die folgende Tabelle zeigt, wie lange Cloud Spanner benötigt, um ein Schema zu aktualisieren.

Schemavorgang Geschätzte Dauer
CREATE TABLE Minuten
CREATE INDEX

Minuten bis Stunden, wenn die Basistabelle vor dem Index erstellt wird.

Minuten, wenn die Anweisung gleichzeitig mit der Anweisung CREATE TABLE für die Basistabelle ausgeführt wird.

DROP TABLE Minuten
DROP INDEX Minuten
ALTER TABLE ... ADD COLUMN Minuten
ALTER TABLE ... ALTER COLUMN

Minuten bis Stunden, wenn eine Validierung im Hintergrund erforderlich ist.

Minuten, wenn keine Validierung im Hintergrund erforderlich ist.

ALTER TABLE ... DROP COLUMN Minuten

Best Practices für Schemaaktualisierungen

In den folgenden Abschnitten werden Best Practices für das Aktualisieren von Schemas beschrieben.

Vor der Schemaaktualisierung auszuführende Schritte

Führen Sie vor dem Aktualisieren eines Schemas folgende Schritte aus:

  • Überprüfen Sie, ob alle vorhandenen Daten in der zu ändernden Datenbank den Einschränkungen entsprechen, die die Schemaaktualisierung auferlegt. Da die erfolgreiche Ausführung von manchen Arten von Schemaaktualisierungen von den Daten in der Datenbank und nicht nur vom aktuellen Schema abhängt, garantiert eine erfolgreiche Schemaaktualisierung einer Testdatenbank nicht zwangsläufig, dass auch das Schema einer Produktionsdatenbank erfolgreich aktualisiert wird. Hier ein paar gängige Beispiele:

    • Achten Sie beim Hinzufügen der Annotation NOT NULL zu einer vorhandenen Spalte darauf, dass in der Spalte keine NULL-Werte vorhanden sind.
    • Achten Sie beim Verringern der zulässigen Länge einer STRING- oder BYTES-Spalte darauf, dass alle vorhandenen Werte in dieser Spalte der gewünschten Längenbeschränkung entsprechen.
  • Wenn Sie in Spalten, Tabellen oder Indexe schreiben, die gerade einer Schemaaktualisierung unterzogen werden, sollten Sie prüfen, ob die von Ihnen geschriebenen Werte den neuen Einschränkungen entsprechen.

  • Achten Sie beim Löschen von Spalten, Tabellen oder Indexen darauf, dass Sie dafür keine Schreib- oder Lesevorgänge mehr ausführen.

Häufigkeit von Schemaaktualisierungen begrenzen

Wenn Sie innerhalb kurzer Zeit zu viele Schemaaktualisierungen durchführen, kann Cloud Spanner die Verarbeitung von Schemaaktualisierungen in der Warteschlange throttle verarbeiten. Das liegt daran, dass Cloud Spanner den Speicherplatz für das Speichern von Schemaversionen begrenzt. Die Schemaaktualisierung kann gedrosselt werden, wenn innerhalb der Aufbewahrungsdauer zu viele alte Schemaversionen vorhanden sind. Die maximale Rate von Schemaänderungen hängt von vielen Faktoren ab, von denen einer die Gesamtzahl der Spalten in der Datenbank ist. Beispiel: Eine Datenbank mit 2.000 Spalten (ungefähr 2.000 Zeilen inINFORMATION_SCHEMA.COLUMNS ) mit maximal 1.500 einfachen Schemaänderungen innerhalb der Aufbewahrungsdauer ausgeführt werden, wenn die Schemaänderung mehrere Versionen erfordert. Um den Status laufender Schemaaktualisierungen zu sehen, verwenden Sie den Befehl gcloud spanner operations list und filtern Sie nach Vorgängen vom Typ DATABASE_UPDATE_DDL. Verwenden Sie den Befehl gcloud spanner operations cancel, um eine laufende Schemaaktualisierung abzubrechen, und geben Sie die Vorgangs-ID an.

Wenn Sie die DDL-Anweisungen nicht im Batch verarbeiten können, sollten Sie während der Aufbewahrungsdauer nicht jede Aktualisierungen des Schemas einer einzelnen Datenbank vornehmen. Verlängern Sie das Zeitfenster für Schemaaktualisierungen, damit Cloud Spanner alte Versionen des Schemas entfernen kann, bevor neue Versionen erstellt werden.

  • Für einige relationale Datenbankverwaltungssysteme gibt es Softwarepakete, die bei jeder Produktionsbereitstellung eine lange Reihe von Upgrade- und Downgrade-Schemaaktualisierungen auf die Datenbank anwenden. Diese Arten von Prozessen werden für Cloud Spanner nicht empfohlen.
  • Cloud Spanner ist für die Verwendung von Primärschlüsseln zum Partitionieren von Daten für Lösungen mit Mehrinstanzfähigkeit optimiert. Lösungen mit Mehrinstanzfähigkeit, die eigene Tabellen für jeden Kunden verwenden, können dazu führen, dass ein großer Rückstand an Schemaaktualisierungsvorgängen entsteht, der nur langsam abgearbeitet wird.
  • Schemaaktualisierungen, die eine Validierung oder einen Index-Backfill erfordern, verwenden mehr Serverressourcen, da durch jede Anweisung mehrere Versionen des Schemas intern erstellt werden.

Optionen für umfangreiche Schemaaktualisierungen

Die beste Methode zum Erstellen einer Tabelle und einer großen Anzahl von Indexen für diese Tabelle besteht darin, alles zur selben Zeit zu erstellen. Sie können die Tabelle und ihre Indexe gleichzeitig mit der Datenbank oder als einzelnen großen Batch von DDL-Anweisungen erstellen. Sie können mehrere tausend DDL-Anweisungen als Batch in einer einzigen Anfrage verarbeiten, solange nicht mehr als zehn dieser Anweisungen eine Validierung oder einen Backfill erfordern.

Wenn Sie die Tabelle und ihre Indexe nicht als einen einzelnen großen Batch von DDL-Anweisungen erstellen können, versuchen Sie, pro Tag nicht mehr als drei neue Indexe hinzuzufügen.

Auf Abschluss von API-Anfragen warten

Verwenden Sie beim Senden der Anfragen projects.instances.databases.updateDdl (REST API) oder UpdateDatabaseDdl (RPC API) jeweils projects.instances.databases.operations.get (REST API) oder GetOperation (RPC API), um auf den Abschluss der einzelnen Anfragen zu warten, bevor eine neue Anfrage gestartet wird. Ihre Anwendung kann dann den Fortschritt der Schemaaktualisierungen verfolgen. Außerdem bleibt der Rückstand von ausstehenden Schemaaktualisierungen in diesem Fall überschaubar.

Im Bulk laden

Wenn Sie nach dem Erstellen von Tabellen Daten im Bulk in die Tabellen laden, ist es in der Regel effizienter, Indexe nach dem Laden der Daten zu erstellen. Beim Hinzufügen mehrerer Indexe kann es sich als effizienter erweisen, die Datenbank mit allen Tabellen und Indexen im Anfangsschema zu erstellen, wie unter Optionen für umfangreiche Aktualisierungen beschrieben.