Schemaaktualisierungen vornehmen

Mit 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 Spanner folgende Arten von Aktualisierungen:

  • Ein benanntes Schema hinzufügen oder löschen.
  • 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 auf beliebige Weise ä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.
  • Ansichten erstellen und verwalten
  • Sequenzen erstellen und verwalten.
  • Erstellen Sie Datenbankrollen und gewähren Sie Berechtigungen.
  • Legen Sie den Standardwert einer Spalte fest, ändern Sie ihn oder löschen Sie ihn.
  • Ä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 Feld PROTO des Typs ENUM vorhanden ist, auf das von einem Tabelle oder Indexschlüssel verwenden, können Sie keine ENUM-Werte aus der Proto-Datei entfernen. enums. Das Entfernen von ENUM-Werten aus Enumerationen, die von ENUM<>-Spalten verwendet werden, wird unterstützt, auch wenn diese Spalten als Schlüssel verwendet werden.

Leistung während der Schemaaktualisierung

Schemaaktualisierungen in Spanner erfolgen ohne Ausfallzeiten. 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 anderes Beispiel ist die Erweiterung einer Datenbank um einen Index: 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, Keine vorhandenen Daten zur Validierung vorhanden, sodass Spanner das Update intensiver ausführen kann schnell ändern.

Zusammenfassend lässt sich sagen, dass Schemaaktualisierungen innerhalb von Minuten durchgeführt werden können, wenn 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, die mit Ansichtsdefinitionen validiert werden

Wenn Sie ein Schema aktualisieren, prüft Spanner, ob die Abfragen, die zum Definieren vorhandener Ansichten verwendet werden, durch das Update nicht ungültig werden. 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, lässt 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.

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 aus der Aufzählungsdefinition für RecordLabel entfernen

  • 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. Beispielsweise schlägt die Anweisung ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL fehl, wenn ein Wert im Feld Nickname Spalte NULL, da die vorhandenen Daten nicht den NOT NULL entsprechen 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
  • 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, die REST API oder die RPC API verwenden, können Sie einen Batch von einer oder mehreren CREATE-, ALTER- oder DROP-Anweisungen absetzen.

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 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 Spanner diese Spalte in einem dieser beiden Zustände, wobei nicht angegeben ist, in welchem.

Während der Schemaaktualisierung erstellte Schemaversionen

Da Spanner mit Schemaversionierung arbeitet, können Schemas von großen Datenbanken ohne Ausfallzeit aktualisiert werden. Spanner behält die ältere Schemaversion bei, sodass Lesevorgänge während der Verarbeitung der Schemaaktualisierung möglich sind. Anschließend erstellt Spanner eine oder mehrere neue Versionen des Schemas, um die Schemaaktualisierung zu verarbeiten. Jede Version enthält das Ergebnis einer Sammlung von Anweisungen in einem einzelne atomare Ä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. Alte Schemaversionen können erhebliche Server- und Speicherressourcen verbrauchen und werden aufbewahrt, bis sie abgelaufen bzw. nicht mehr erforderlich sind, um Lesevorgänge von älteren Datenversionen bereitzustellen.

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.

Änderungen am Datentyp 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 mit dem aktuellen Typ einer Spalte überein. Wenn Sie den Datentyp einer beobachteten Spalte ändern, hat das keine Auswirkungen auf die Datensatze des Änderungsstreams, die vor dieser Änderung erstellt wurden.

Im speziellen Fall einer Änderung von BYTES zu STRING prüft Spanner die alten Werte der Spalte im Rahmen der Schemaaktualisierung. Daher hat Spanner die alten Werte vom Typ BYTES bis zum Schreiben nachfolgender Änderungsstream-Einträge sicher in Strings decodiert.

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 innerhalb kurzer Zeit zu viele Schemaaktualisierungen ausführen, kann Spanner die Verarbeitung der anstehenden Schemaaktualisierungen throttle. Das liegt daran, dass Spanner den Speicherplatz für das Speichern von Schemaversionen begrenzt. Die Schemaaktualisierung wird möglicherweise gedrosselt, wenn sich innerhalb der Aufbewahrungsdauer zu viele alte Schemaversionen befinden. Die maximale Rate der Schemaänderungen hängt von vielen Faktoren ab, darunter die Gesamtzahl der Spalten in der Datenbank. Bei einer Datenbank mit 2.000 Spalten (ungefähr 2.000 Zeilen in INFORMATION_SCHEMA.COLUMNS) können innerhalb des Speicherzeitraums maximal 1.500 Schemaänderungen vorgenommen werden (weniger, wenn für die Schemaänderung mehrere Versionen erforderlich sind). Wenn Sie den Status laufender Schemaupdates sehen möchten, verwenden Sie den Befehl gcloud spanner operations list und filtern Sie nach Vorgängen vom Typ 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 Schemaupdates zu maximieren, die Sie in einem bestimmten Zeitraum ausführen können, sollten Sie Batch-Vorgänge verwenden, mit denen die Anzahl der Schemaversionen minimiert wird. 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 werden können, um die Verwendung mehrerer Schemaversionen zu vermeiden. Dies hängt vom Batching ab. 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 Große 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. Verlängern Sie das Zeitfenster für Schemaaktualisierungen, damit Spanner frühere 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 Spanner nicht empfohlen.
  • 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 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. In Spanner dürfen nicht mehr als zehn solche Anweisungen in einem einzelnen Batch vorhanden sein. 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.