Schemaaktualisierungen vornehmen

Mit Spanner können Sie Schemaaktualisierungen ohne Ausfallzeiten vornehmen. Sie können das Schema einer vorhandenen Datenbank auf mehrere Arten:

Unterstützte Schemaaktualisierungen

Spanner unterstützt die folgenden Schemaaktualisierungen einer vorhandenen Datenbank:

  • Fügen Sie ein benanntes Schema hinzu oder löschen Sie es.
  • Erstellen einer neuen Tabelle 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.
  • Erstellen oder löschen Sie eine Tabelle mit einem Fremdschlüssel.
  • Hinzufügen oder entfernen eines Fremdschlüssels aus einer vorhandenen Tabelle.
  • Eine Nicht-Schlüsselspalte in eine Tabelle aufnehmen. Neue Nicht-Schlüsselspalten können nicht NOT NULL
  • Eine Nicht-Schlüsselspalte aus einer Tabelle löschen, sofern sie nicht von einem sekundären Index, einem Fremdschlüssel, einer gespeicherten generierten Spalte oder einer Diagnoseeinschränkung verwendet wird.
  • NOT NULL in eine Nicht-Schlüsselspalte aufnehmen und dabei ARRAY-Spalten ausschließen.
  • NOT NULL aus einer Nicht-Schlüsselspalte entfernen.
  • Eine Spalte des Typs STRING in eine Spalte des Typs BYTES ändern oder umgekehrt (BYTES in STRING).
  • Eine Spalte des Typs PROTO in eine Spalte des Typs BYTES ändern oder umgekehrt (BYTES in PROTO).
  • .proto-Nachrichtentyp einer Spalte vom Typ „PROTO“ ändern.
  • Einer ENUM-Definition neue Werte hinzufügen und vorhandene Werte umbenennen mit ALTER PROTO BUNDLE.
  • Sie können in einem PROTO BUNDLE definierte Nachrichten beliebig ändern, sofern dass geänderte Felder dieser Nachrichten in keiner Tabelle als Schlüssel verwendet werden. und dass die vorhandenen Daten die neuen Einschränkungen erfüllen.
  • 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.
  • Die Längenbeschränkung für ARRAY<STRING>, ARRAY<BYTES>, oder ARRAY<PROTO> auf das Maximum setzen.
  • Commit-Zeitstempel in Wert- und Primärschlüsselspalten aktivieren oder deaktivieren.
  • Einen sekundären Index hinzufügen oder entfernen
  • Diagnoseeinschränkung zu einer vorhandenen Tabelle hinzufügen oder daraus entfernen.
  • Gespeicherte generierte Spalte zu einer vorhandenen Tabelle hinzufügen oder daraus entfernen.
  • Erstellt ein neues Optimierungstool Statistics-Paket.
  • Datenansichten erstellen und verwalten
  • Sequenzen erstellen und verwalten.
  • Erstellen Sie Datenbankrollen und gewähren Sie Berechtigungen.
  • Sie können den Standardwert einer Spalte festlegen, ändern oder löschen.
  • Ändern Sie die Datenbankoptionen (z. B. default_leader oder version_retention_period).
  • Änderungsstreams erstellen und verwalten
  • ML-Modelle erstellen und verwalten

Nicht unterstützte Schemaaktualisierungen

Spanner unterstützt die folgenden Schemaaktualisierungen eines vorhandenen Datenbank:

  • Wenn ein PROTO-Feld des Typs ENUM vorhanden ist, auf das von einem Tabelle oder Indexschlüssel können Sie keine ENUM-Werte aus der Proto-Datei entfernen. enums. (Entfernung der ENUM-Werte aus den von ENUM<> verwendeten Enums Spalten unterstützt werden, auch wenn diese Spalten als Schlüssel verwendet werden.)

Leistung während der Schemaaktualisierung

Schemaaktualisierungen in Spanner erfordern keine Ausfallzeit. Wenn Sie eine in eine Spanner-Datenbank übertragen, können Sie mit dem Schreiben und ohne Unterbrechung aus der Datenbank lesen, während Spanner das Update als Vorgang mit langer Ausführungszeit.

Die Ausführungsdauer einer DDL-Anweisung hängt davon ab, ob die Aktualisierung eine Validierung von vorhandenen Daten oder einen Daten-Backfill voraussetzt. Beispiel: Wenn Sie die Annotation NOT NULL einer vorhandenen Spalte hinzufügen, muss Spanner lesen Sie alle Werte in der Spalte, um sicherzustellen, dass die Spalte keine beliebige NULL-Werte. Dieser Schritt kann lang dauern, wenn viele Daten validiert werden müssen. Ein weiteres Beispiel ist das Hinzufügen eines Index zu einer Datenbank: Spanner füllt den Index mit vorhandenen Daten auf. lange dauern, je nachdem, wie die Indexdefinition der entsprechenden Basistabelle. Wenn Sie jedoch eine neue Spalte in eine Tabelle einfügen, Keine vorhandenen Daten zur Validierung vorhanden, sodass Spanner das Update intensiver ausführen kann schnell ändern.

Zusammenfassend lässt sich sagen, dass Schemaaktualisierungen, bei denen die Validierung durch Spanner nicht erforderlich ist, vorhandene Daten innerhalb von Minuten erstellt werden. 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, die mit Ansichtsdefinitionen validiert werden

Wenn Sie eine Schemaaktualisierung vornehmen, wird von Spanner überprüft, ob die Aktualisierung die Abfragen, die zur Definition vorhandener Ansichten verwendet werden, nicht ungültig. Ist die Validierung erfolgreich, verläuft auch die Schemaaktualisierung erfolgreich. Wenn die Validierung nicht erfolgreich ist, schlägt die Schemaaktualisierung fehl. Weitere Informationen finden Sie unter Best Practices beim Erstellen von Ansichten.

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, Spanner lässt in Konflikt stehende Schemaaktualisierungen für das betroffene Schema nicht zu Entitäten 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.

Angenommen, Sie haben die folgende music.proto-Datei mit einem RecordLabel-Enum und Songwriter-Protokollnachricht:

  enum RecordLabel {
    COOL_MUSIC_INC = 0;
    PACIFIC_ENTERTAINMENT = 1;
    XYZ_RECORDS = 2;
  }

  message Songwriter {
    required string nationality   = 1;
    optional int64  year_of_birth = 2;
  }

So fügen Sie Ihrem Schema eine Songwriters-Tabelle hinzu:

GoogleSQL 

CREATE PROTO BUNDLE (
  googlesql.example.music.Songwriter,
  googlesql.example.music.RecordLabel,
);

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
  SongWriter googlesql.example.music.Songwriter
) PRIMARY KEY (Id);

CREATE TABLE Albums (
  SongwriterId     INT64 NOT NULL,
  AlbumId          INT64 NOT NULL,
  AlbumTitle       STRING(MAX),
  Label            INT32
) PRIMARY KEY (SongwriterId, AlbumId);

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);

  • INT64/INT32 in ENUM ändern. Beispiel:

    ALTER TABLE Albums ALTER COLUMN Label googlesql.example.music.RecordLabel;

  • Vorhandene Werte werden aus der Enum-Definition RecordLabel entfernt.

  • Commit-Zeitstempel für eine vorhandene TIMESTAMP-Spalte aktivieren. Beispiel:

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

  • Diagnoseeinschränkung zu einer vorhandenen Tabelle hinzufügen

  • Gespeicherte generierte Spalte zu einer vorhandenen Tabelle hinzufügen

  • Eine neue Tabelle mit einem Fremdschlüssel erstellen

  • Einer vorhandenen Tabelle einen Fremdschlüssel hinzufügen

Diese Schemaaktualisierungen schlagen fehl, wenn die zugrunde liegenden Daten den neuen Einschränkungen nicht entsprechen. Die ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL-Anweisung schlägt beispielsweise fehl, wenn ein Wert im Nickname Spalte NULL, da die vorhandenen Daten nicht den NOT NULL entsprechen -Beschränkung der neuen Definition.

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

  • Die Größe des Datasets
  • Rechenkapazität 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 zu einem Spalte beginnt Spanner fast sofort damit, Schreibvorgänge für neue Anfragen mit NULL für die Spalte. 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 die Google Cloud CLI, REST API oder RPC API verwenden, können Sie einen Batch ausgeben von mindestens einer CREATE-, ALTER- oder DROP-Anweisung

Spanner wendet Anweisungen aus demselben Batch der Reihe nach an und stoppt bei Fehler. 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.

Spanner kann Anweisungen aus verschiedenen Batches kombinieren und neu anordnen, Anweisungen aus verschiedenen Batches zu einer atomaren Änderung zu kombinieren, auf die Datenbank angewendet wird. Die Ausführung von Anweisungen aus verschiedenen Batches erfolgt in jeder atomaren Änderung in zufälliger Reihenfolge. Wenn z. B. ein Batch von Anweisungen enthält ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(50) und eine weitere ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(20) enthält, belässt Spanner diese Spalte in einem dieser beiden Zustände. aber nicht angegeben, welche.

Während der Schemaaktualisierung erstellte Schemaversionen

Spanner verwendet die Schemaversionsverwaltung, damit während einer Schemaaktualisierung für eine große Datenbank. Spanner behält das ältere Schema bei Version, um Lesevorgänge während der Verarbeitung der Schemaaktualisierung zu unterstützen. Spanner erstellt dann eine oder mehrere neue Versionen des Schemas, um das Schema zu verarbeiten. aktualisieren. Jede Version enthält das Ergebnis einer Sammlung von Anweisungen in einem Änderung einer einzelnen atomaren Änderung.

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 die Indexerstellung für vorhandene Basistabellen oder Anweisungen, die eine Datenvalidierung erfordern. In anderen Fällen können mehrere DDL-Anweisungen in einer einzigen Version zusammengefasst sein. Mit alten Schemaversionen beträchtliche Server- und Speicherressourcen verbrauchen und bis zum Sie laufen ab (werden nicht mehr benötigt, um Lesevorgänge früherer Datenversionen zu verarbeiten).

Die folgende Tabelle zeigt, wie lange Spanner zum Aktualisieren eines Schemas benötigt.

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
ANALYZE

Minuten bis Stunden, je nach Datenbankgröße.

Datentypänderungen und Änderungsstreams

Wenn Sie den Datentyp einer Spalte ändern, wird diese Änderung Stream ansehen, wird das Feld column_types eines relevanten nachfolgenden Änderungsstreams Einträge den neuen Typ widerspiegelt, ebenso wie die old_values-JSON-Daten innerhalb der Datensätze mods verwendet.

Der new_values des Felds mods eines Änderungsstream-Eintrags stimmt immer überein den aktuellen Typ einer Spalte. Das Ändern des Datentyps einer beobachteten Spalte sich auf alle Änderungsstream-Einträge vor dieser Änderung auswirken.

Bei einer BYTES-zu-STRING-Änderung Spanner validiert den alten Wert der Spalte Werte im Rahmen der Schemaaktualisierung hinzu. Infolgedessen hat Spanner die alten BYTES-Werte in Strings umwandeln, wenn alle nachfolgenden Änderungsstream-Datensätze.

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.
    • Wenn Sie die zulässige Länge einer STRING- oder BYTES-Spalte verkürzen, Überprüfen Sie, ob alle vorhandenen Werte in dieser Spalte die Länge Einschränkung.

  • 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 zu viele Schemaaktualisierungen innerhalb kurzer Zeit durchführen, Mai throttle Verarbeitung von Schemaaktualisierungen in der Warteschlange. Das liegt daran, dass Spanner Speicherplatz zum Speichern von Schemaversionen. Die Schemaaktualisierung wird möglicherweise gedrosselt Wenn innerhalb der Aufbewahrungsdauer zu viele alte Schemaversionen vorhanden sind. Die Die maximale Rate an Schemaänderungen hängt von vielen Faktoren ab Eine davon ist die Gesamtzahl der Spalten in der Datenbank. Beispiel: mit 2000 Spalten (ungefähr 2000 Zeilen in INFORMATION_SCHEMA.COLUMNS) maximal 1.500 Schemaänderungen ausführen kann (weniger, Änderung mehrerer Versionen) innerhalb der Aufbewahrungsdauer. Status abrufen fortlaufenden Schemaaktualisierungen ist, gcloud spanner operations list und filtern Sie nach Vorgängen des Typs DATABASE_UPDATE_DDL. So stornieren Sie eine fortlaufende Schemaaktualisierung ausführen, verwenden Sie gcloud spanner operations cancel und geben Sie die Vorgangs-ID an.

Wie Ihre DDL-Anweisungen in Batches gestapelt werden und ihre Reihenfolge innerhalb jedes Batches, sich auf die Anzahl der resultierenden Schemaversionen auswirken. Um die Anzahl der Schemaaktualisierungen, die innerhalb eines bestimmten Zeitraums durchgeführt werden können, sollten Sie die die Anzahl der Schemaversionen minimieren. Als Faustregel gilt: wie unter Große Updates beschrieben.

Wie unter Schemaversionen beschrieben, erstellen einige DDL-Anweisungen mehrere Schemaversionen. Diese spielen für Überlegungen zum Batching und der Reihenfolge in jedem Batch eine wichtige Rolle. Es gibt zwei Haupttypen von Anweisungen, die möglicherweise mehrere Schemaversionen erstellen:

  • Anweisungen, die möglicherweise einen Indexdaten-Backfill durchführen müssen, z. B. CREATE INDEX
  • Anweisungen, die möglicherweise vorhandene Daten validieren, müssen z. B. das Hinzufügen von NOT NULL

Diese Arten von Anweisungen erstellen nicht immer mehrere Schemaversionen, aber. Spanner versucht zu erkennen, wann diese Arten von Anweisungen optimiert, um die Verwendung mehrerer Schemaversionen zu vermeiden, die auf Batchverarbeitung angewiesen sind. Beispiel: Eine CREATE INDEX-Anweisung, die im selben Batch wie ein CREATE TABLE-Anweisung für die Basistabelle des Index ohne dazwischen für andere Tabellen verwenden, können Sie vermeiden, die Indexdaten auffüllen zu müssen, da Spanner garantieren kann, dass die Basistabelle zu diesem Zeitpunkt leer ist der Index erstellt wird. Im Abschnitt umfangreiche Updates wird beschrieben, wie Sie um mit dieser Eigenschaft viele Indexe effizient zu erstellen.

Wenn Sie die DDL-Anweisungen nicht im Batch verarbeiten können, um das Erstellen von vielen Schemaversionen zu vermeiden, sollten Sie die Anzahl der Schemaaktualisierungen innerhalb der Aufbewahrungsdauer für das Schema einer einzelnen Datenbank beschränken. Zeitfenster zum Erstellen des Schemas verlängern Aktualisierungen, damit Spanner frühere Versionen des Schemas vor neuen entfernen kann 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 Spanner.
  • Spanner ist so optimiert, dass Primärschlüssel zum Partitionieren von Daten für Lösungen für Mehrmandantenfähigkeit. Lösungen mit Mehrmandantenfähigkeit, bei denen für jeden Kunden separate Tabellen verwendet werden, können zu an einem großen Rückstand von Schemaaktualisierungsvorgängen, abgeschlossen ist.
  • Schemaaktualisierungen, die eine Validierung oder einen Index-Backfill erfordern, verwenden mehr Serverressourcen, da jede Anweisung intern mehrere Versionen des Schemas erstellt.

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, sodass nur eine Schemaversion erstellt wird. Es wird empfohlen, die Indexe unmittelbar nach der Tabelle in der Liste der DDL-Anweisungen zu erstellen. Sie können die Tabelle und ihre Indexe gleichzeitig mit der Datenbank oder als einzelnen großen Batch Anweisungen erstellen. Wenn Sie viele Tabellen mit jeweils vielen Indexen erstellen müssen, können Sie alle Anweisungen in einem einzigen Batch zusammenfassen. Sie können mehrere tausend Anweisungen in einem einzigen Batch zusammenfassen, wenn alle Anweisungen mithilfe einer einzigen Schemaversion gemeinsam ausgeführt werden können.

Wenn eine Anweisung einen Backfill für Indexdaten erfordert oder eine Datenvalidierung durchführt, kann sie nicht in einer einzelnen Schemaversion ausgeführt werden. Dies geschieht bei CREATE INDEX-Anweisungen, wenn die Basistabelle des Index bereits vorhanden ist, entweder weil sie in einem vorherigen Batch von DDL-Anweisungen erstellt wurde oder weil im Batch zwischen den Anweisungen CREATE TABLE und CREATE INDEX eine Anweisung vorhanden war, für die mehrere Schemaversionen erforderlich waren. Cloud Spanner verlangt, dass keine in einem Batch mehr als 10 dieser Anweisungen enthalten. Insbesondere die Indexerstellung, die Backfilling erfordert, verwendet mehrere Schemaversionen pro Index. Daher gilt als Faustregel, pro Tag nicht mehr als drei neue Indexe zu erstellen, die Backfilling erfordern. Dabei ist es unerheblich, wie das Batching erfolgt, es sei denn, Backfilling kann dadurch verhindert werden.

Dieser Batch Anweisungen verwendet beispielsweise eine einzige Schemaversion:

GoogleSQL 

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

Im Gegensatz dazu verwendet dieser Batch viele Schemaversionen, weil UnrelatedIndex Backfilling erfordert (da seine Basistabelle bereits vorhanden sein musste) und dadurch werden alle folgenden Indexe gezwungen, ebenfalls Backfilling zu erfordern (auch wenn sie sich im selben Batch wie ihre Basistabellen befinden):

GoogleSQL 

CREATE TABLE Singers (
SingerId   INT64 NOT NULL,
FirstName  STRING(1024),
LastName   STRING(1024),
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
SingerId   INT64 NOT NULL,
AlbumId    INT64 NOT NULL,
AlbumTitle STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId);

CREATE INDEX UnrelatedIndex ON UnrelatedTable(UnrelatedIndexKey);

CREATE INDEX SingersByFirstName ON Singers(FirstName);

CREATE INDEX SingersByLastName ON Singers(LastName);

CREATE INDEX AlbumsByTitle ON Albums(AlbumTitle);

Es ist besser, die Erstellung von UnrelatedIndex an das Ende des Batches oder in einen anderen Batch zu verschieben, um die Anzahl der Schemaversionen zu minimieren.

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.