Auf dieser Seite wird erläutert, wie Sie eine Open-Source-PostgreSQL-Datenbank (im Folgenden nur PostgreSQL) zu einer Datenbank mit dem Spanner-PostgreSQL-Dialekt (im Folgenden nur Spanner) migrieren.
Informationen zur Migration zu Spanner und zum GoogleSQL-Dialekt finden Sie unter Von PostgreSQL zu Spanner (GoogleSQL-Dialekt) migrieren.
Migrationseinschränkungen
Bei Spanner werden bestimmte Konzepte anders als bei anderen Verwaltungstools für Unternehmensdatenbanken verwendet. Daher müssen Sie möglicherweise die Architektur Ihrer Anwendung anpassen, um alle Funktionen nutzen zu können. Eventuell müssen Sie Spanner durch andere Dienste von Google Cloud ergänzen, um Ihre Anforderungen zu erfüllen.
Gespeicherte Prozeduren und Trigger
Spanner unterstützt nicht die Ausführung von Nutzercode auf Datenbankebene. Daher muss im Rahmen der Migration die Geschäftslogik, die durch auf Datenbankebene gespeicherte Prozeduren und Trigger implementiert wird, in die Anwendung verschoben werden.
Sequenzen
Spanner empfiehlt die Verwendung von UUID Version 4 als Standardmethode zum Generieren
Primärschlüsselwerte. Die Funktion GENERATE_UUID() (GoogleSQL, PostgreSQL) gibt UUID-Version-4-Werte zurück, die als STRING-Typ dargestellt werden.
Wenn Sie Ganzzahlwerte generieren müssen, unterstützt Spanner bitweise umgekehrte positive Sequenzen (GoogleSQL, PostgreSQL), die Werte erzeugen, die sich gleichmäßig über den positiven 64‑Bit-Zahlenbereich verteilen. Mit diesen Zahlen können Sie Probleme mit Hotspots vermeiden.
Weitere Informationen finden Sie unter Strategien für Standardwerte für Primärschlüssel.
Zugriffssteuerung
Spanner unterstützt eine detaillierte Zugriffssteuerung auf Tabellen- und Spaltenebene. Die detaillierte Zugriffssteuerung für Ansichten wird nicht unterstützt. Weitere Informationen finden Sie unter Detaillierte Zugriffssteuerung.
Migrationsprozess
Die Migration umfasst die folgenden Aufgaben:
- PostgreSQL-Schema zu Spanner zuordnen
- SQL-Abfragen übersetzen
- Spanner-Instanz, Datenbank und Schema erstellen
- Anwendung so refaktorieren, dass sie mit der Spanner-Datenbank funktioniert
- Daten migrieren
- Neues System überprüfen und in Produktionsstatus übergehen
Schritt 1: PostgreSQL-Schema Spanner zuordnen
Der erste Schritt beim Verschieben einer Datenbank von Open-Source-PostgreSQL zu Spanner bestimmt, welche Schemaänderungen Sie vornehmen müssen.
Primärschlüssel
In Spanner muss jede Tabelle, die mehr als eine Zeile speichern muss, einen Primärschlüssel haben, der aus einer oder mehreren Spalten der Tabelle besteht. Die Primärschlüssel identifiziert jede Zeile in einer Tabelle eindeutig und Spanner verwendet den Primärschlüssel zum Sortieren der Tabellenzeilen. Da Spanner stark verteilt ist, ist es wichtig, dass Sie eine Primärschlüsselgenerierung die mit dem Datenwachstum gut skaliert wird. Weitere Informationen finden Sie in der Primärschlüssel-Migrationsstrategien, die wir empfehlen.
Nachdem Sie Ihren Primärschlüssel festgelegt haben, können Sie keine Primärschlüsselspalte oder später einen Primärschlüsselwert ändern, ohne und wenn Sie die Tabelle neu erstellen. Weitere Informationen zur Festlegung des Primärschlüssels Siehe Schema und Datenmodell – primär Schlüssel.
Indexe
PostgreSQL
B-Tree-Indexe
ähneln sekundären Indexen in
Spanner. In einer Spanner-Datenbank
verwenden Sie sekundäre Indexe,
häufig gesuchte Spalten indexieren, um die Leistung zu verbessern
UNIQUE Einschränkungen in Ihren Tabellen angegeben. Wenn die PostgreSQL-DDL beispielsweise folgende Anweisung enthält:
CREATE TABLE customer (
id CHAR (5) PRIMARY KEY,
first_name VARCHAR (50),
last_name VARCHAR (50),
email VARCHAR (50) UNIQUE
);
Dann würden Sie diese Anweisung in der Spanner-DDL verwenden:
CREATE TABLE customer (
id VARCHAR(5) PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50),
email VARCHAR(50)
);
CREATE UNIQUE INDEX customer_emails ON customer(email);
Sie können die Indexe für jede Ihrer PostgreSQL-Tabellen ermitteln, indem Sie den
\di
Meta-Befehl in psql.
Nachdem Sie die benötigten Indexe ermittelt haben, fügen Sie CREATE INDEX-Anweisungen hinzu, um sie zu erstellen. Folgen Sie der Anleitung unter
Sekundäre Indexe
Spanner implementiert Indexe als Tabellen, sodass eine monotone Indexierung
Durch zunehmende Spalten (z. B. Spalten mit TIMESTAMP-Daten) kann es zu einem Hotspot kommen.
Weitere Informationen finden Sie unter
Was Datenbankadministratoren über Spanner wissen müssen, Teil 1: Schlüssel und Indexe
finden Sie weitere Informationen zu Methoden zur Vermeidung von Hotspots.
Spanner implementiert sekundäre Indexe auf dieselbe Weise wie Tabellen. Daher gelten für die als Indexschlüssel zu verwendenden Spaltenwerte dieselben Einschränkungen wie für die Primärschlüssel von Tabellen. Dies bedeutet auch, dass Indexe die gleichen Konsistenzgarantien wie Spanner-Tabellen haben.
Werte-Zuordnungen mit sekundären Indexen entsprechen praktisch einer Abfrage mit Tabellenverknüpfung. Sie können die Leistung von Abfragen mithilfe von Indexen verbessern, indem Sie
Kopien der Spaltenwerte aus der Originaltabelle im sekundären Index unter Verwendung des
INCLUDE-Klausel, was sie zu einer
Abdeckungsindex.
Die Abfrageoptimierung von Spanner verwendet nur dann automatisch einen sekundären Index, wenn der Index selbst alle abgefragten Spalten speichert (abgedeckte Abfrage). Wenn Sie erzwingen möchten, dass beim Abfragen von Spalten in der ursprünglichen Tabelle ein Index verwendet wird, müssen Sie in der SQL-Anweisung eine FORCE INDEX-Anweisung verwenden. Beispiel:
SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;
Hier ist ein Beispiel für eine DDL-Anweisung, die einen sekundären Index für die Album-Tabelle erstellt:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Wenn Sie nach dem Laden Ihrer Daten zusätzliche Indexe erstellen, kann das Auffüllen des Index einige Zeit in Anspruch nehmen. Daher wird empfohlen, maximal drei Indexe pro Tag hinzuzufügen. Eine ausführliche Anleitung zum Erstellen von sekundären Indexen finden Sie unter Sekundäre Indexe. Weitere Informationen zu den Einschränkungen bei der Indexerstellung finden Sie unter Schemaaktualisierungen.
Aufrufe
Spanner-Ansichten sind schreibgeschützt. Sie können nicht zum Einfügen, Aktualisieren oder Daten löschen. Weitere Informationen finden Sie unter Aufrufe.
Generierte Spalten
Spanner unterstützt generierte Spalten. Informationen zu Syntaxunterschieden und Einschränkungen finden Sie unter Generierte Spalten erstellen und verwalten.
Tabellenverschachtelung
Spanner hat ein Feature, mit dem Sie zwei Tabellen mit einer 1:n-Beziehung mit hierarchischer Struktur definieren können. Mit dieser Funktion werden die untergeordneten Datenzeilen mit der jeweils übergeordneten Zeile im Speicher verschränkt. Die Tabelle wird hierdurch vorab verknüpft und der Datenabruf erfolgt effizienter, wenn beide Tabellen (untergeordnet und übergeordnet) gemeinsam abgefragt werden.
Der Primärschlüssel der untergeordneten Tabelle muss mit der bzw. den Primärschlüsselspalten der übergeordneten Tabelle beginnen. Aus der Perspektive der untergeordneten Zeile wird der Primärschlüssel der übergeordneten Zeile als Fremdschlüssel bezeichnet. Sie können bis zu 6 Ebenen an hierarchischen Beziehungen definieren.
Sie können ON DELETE-Aktionen definieren
für untergeordnete Tabellen, um zu bestimmen, was passiert, wenn die übergeordnete Zeile gelöscht wird:
werden entweder alle untergeordneten Zeilen gelöscht oder das Löschen der übergeordneten Zeile wird blockiert, während
untergeordnete Zeilen vorhanden sind.
Hier sehen Sie anhand eines Beispiels, wie eine Album-Tabelle erstellt wird, die in der zuvor definierten übergeordneten Tabelle mit den Interpreten verschränkt ist:
CREATE TABLE Albums (
SingerID bigint,
AlbumID bigint,
AlbumTitle varchar,
PRIMARY KEY (SingerID, AlbumID)
)
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
Weitere Informationen finden Sie unter Verschränkte Tabellen erstellen.
Datentypen
In der folgenden Tabelle sind die Open-Source-PostgreSQL-Datentypen aufgeführt, die von der PostgreSQL-Oberfläche für Spanner nicht unterstützt werden.
| Datentyp | Stattdessen verwenden |
|---|---|
| bigserial,serial8 | bigint, int8 |
| bit [ (n) ] | - |
| Bit variieren [ (n) ], varbit [ (n) ] | - |
| box | - |
| Zeichen [ (n) ], Zeichen [ (n) ] | Zeichen variieren |
| cidr | Text |
| Kreis | - |
| inet | Text |
| Ganzzahl, int4 | Bigint, int8 |
| interval [Felder] [ (p) ] | bigint |
| json | jsonb |
| Linie | - |
| lseg | - |
| macaddr | Text |
| money | numeric, decimal |
| Pfad | - |
| pg_lsn | - |
| point | - |
| polygon | - |
| realfloat4 | double precision, float8 |
| Smallint, int2 | bigint, int8 |
| smallserial, serial2 | Bigint, int8 |
| seriell, seriell4 | bigint, int8 |
| time [ (p) ] [ ohne Zeitzone ] | Text im Format HH:MM:SS.sss |
| time [ (p) ] mit Zeitzonetimetz | Text unter Verwendung der Schreibweise HH:MM:SS.sss+ZZZZ. Oder verwenden Sie zwei Spalten. |
| timestamp [ (p) ] [ ohne Zeitzone ] | Text oder Zeitstempel |
| tsquery | - |
| tsvector | - |
| txid_snapshot | - |
| uuid | text oder bytea |
| xml | Text |
Schritt 2: SQL-Abfragen übersetzen
Spanner verfügt über viele der Open-Source- Funktionen um den Conversion-Aufwand zu verringern.
SQL-Abfragen können über die Spanner Studio-Seite in der Google Cloud Console erstellt werden, um die Abfrage auszuführen. Im Allgemeinen sollten Abfragen, die vollständige Tabellenscans für große Tabellen ausführen, sparsam verwendet werden, da sie sehr teuer sind. Weitere Informationen zum Optimieren von SQL-Abfragen finden Sie in der Best Practices für SQL Dokumentation.
Schritt 3: Spanner-Instanz, Datenbank und Schema erstellen
Erstellen Sie die Instanz und eine Datenbank im PostgreSQL-Dialekt. Erstellen Sie dann Ihr Schema mit der PostgreSQL-Datendefinition Language (DDL) enthält.
Erstellen Sie mit pg_dump DDL-Anweisungen, die Objekte in der PostgreSQL-Datenbank definieren. Verändern Sie dann die Anweisungen, wie in den vorherigen Abschnitten beschrieben. Nachdem Sie die DDL-Anweisungen aktualisiert haben, verwenden Sie die DDL-Anweisungen.
um die Datenbank in der Spanner-Instanz zu erstellen.
Weitere Informationen finden Sie unter:
Schritt 4: Anwendung refaktorieren
Fügen Sie Anwendungslogik hinzu, um das geänderte Schema und die überarbeiteten SQL-Abfragen zu berücksichtigen und datenbankinterne Logik wie Prozeduren und Trigger zu ersetzen.
Schritt 5: Daten migrieren
Es gibt zwei Möglichkeiten, Ihre Daten zu migrieren:
Mit Harbourbridge
Harbourbridge unterstützt sowohl Schema- als auch Datenmigrationen. Sie können eine pg_dump-Datei oder eine CSV-Datei importieren oder über eine direkte Verbindung zur Open-Source-PostgreSQL-Datenbank importieren.
Mit dem Befehl
COPY FROM STDIN.Weitere Informationen finden Sie unter COPY-Befehl zum Importieren von Daten.