Mit Spanner können Sie Schemaaktualisierungen ohne Ausfallzeiten vornehmen. Sie können das Schema einer vorhandenen Datenbank auf mehrere Arten:
In der Google Cloud Console
Senden Sie den Befehl
ALTER TABLE
auf der Seite Spanner Studio.Klicken Sie auf Spanner Studio, um die Seite Spanner Studio auf der Seite „Datenbankübersicht“ oder „Tabellenübersicht“.
gcloud spanner
-Befehlszeilentool verwendenSenden Sie einen
ALTER TABLE
-Befehl mit demgcloud spanner databases ddl update
.projects.instances.databases.updateDdl
REST API verwendenUpdateDatabaseDdl
RPC API verwenden
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 dabeiARRAY
-Spalten ausschließen.NOT NULL
aus einer Nicht-Schlüsselspalte entfernen.- Eine Spalte des Typs
STRING
in eine Spalte des TypsBYTES
ändern oder umgekehrt (BYTES
inSTRING
). - Eine Spalte des Typs
PROTO
in eine Spalte des TypsBYTES
ändern oder umgekehrt (BYTES
inPROTO
). - .proto-Nachrichtentyp einer Spalte vom Typ „
PROTO
“ ändern. - Einer
ENUM
-Definition neue Werte hinzufügen und vorhandene Werte umbenennen mitALTER 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
- oderBYTES
-Typ erhöhen oder verringern (einschließlich aufMAX
), 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>
, oderARRAY<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
oderversion_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 TypsENUM
vorhanden ist, auf das von einem Tabelle oder Indexschlüssel verwenden, können Sie keineENUM
-Werte aus der Proto-Datei entfernen. enums. (Entfernung derENUM
-Werte aus den vonENUM<>
verwendeten Aufzählungen 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
inSTRING
ändern. Beispiel:ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX);
INT64/INT32
inENUM
ä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. 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
-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 eine 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. 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 auszuführen).
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 |
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
des 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 keineNULL
-Werte vorhanden sind. - Wenn Sie die zulässige Länge einer
STRING
- oderBYTES
-Spalte verkürzen, Überprüfen Sie, ob alle vorhandenen Werte in dieser Spalte die Länge Einschränkung.
- Achten Sie beim Hinzufügen der Annotation
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 Sie innerhalb eines bestimmten Zeitraums durchführen 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 setzt voraus, 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.