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

Von PostgreSQL zu Cloud Spanner migrieren

Auf dieser Seite finden Sie eine Anleitung zur Migration einer PostgreSQL-Datenbank zu Cloud Spanner. Folgende Aspekte einer Migration von PostgreSQL zu Cloud Spanner werden beschrieben:

  • PostgreSQL-Schema einem Cloud Spanner-Schema zuordnen
  • Cloud Spanner-Instanz, -Datenbank und -Schema erstellen
  • Anwendung für die Arbeit mit der Cloud Spanner-Datenbank umgestalten
  • Daten migrieren
  • Neues System überprüfen und in Produktionsstatus übergehen

Auf dieser Seite finden Sie außerdem einige Beispielschemas, die Tabellen aus der PostgreSQL-Datenbank MusicBrainz verwenden.

PostgreSQL-Schema zu Cloud Spanner zuordnen

Bestimmen Sie beim Verschieben einer Datenbank von PostgreSQL zu Cloud Spanner zuerst, welche Änderungen am Schema erforderlich sind. Erstellen Sie dafür mit pg_dump DDL-Anweisungen (Data Definition Language, Datendefinitionssprache), die Objekte in der PostgreSQL-Datenbank definieren. Verändern Sie dann die Anweisungen, wie in den folgenden Abschnitten beschrieben. Nachdem Sie die DLL-Anweisungen aktualisiert haben, erstellen Sie mit den DDL-Anweisungen eine Datenbank in einer Cloud Spanner-Instanz.

Datentypen

In der folgenden Tabelle wird beschrieben, wie PostgreSQL-Datentypen den Cloud Spanner-Datentypen zugeordnet werden. Aktualisieren Sie die Datentypen in den DDL-Anweisungen von PostgreSQL-Datentypen zu Cloud Spanner-Datentypen.

PostgreSQL Cloud Spanner
Bigint

int8

INT64
Bigserial

serial8

INT64
bit [ (n) ] ARRAY<BOOL>
bit varying [ (n) ]

varbit [ (n) ]

ARRAY<BOOL>
Boolean

bool

BOOL
box ARRAY<FLOAT64>
bytea BYTES
character [ (n) ]

char [ (n) ]

STRING
character varying [ (n) ]

varchar [ (n) ]

STRING
cidr STRING mit der standardmäßigen CIDR-Schreibweise
circle ARRAY<FLOAT64>
date DATE
double precision

float8

FLOAT64
inet STRING
Integer

int

int4

INT64
interval[ fields ] [ (p) ] INT64, wenn der Wert in Millisekunden gespeichert wird, oder STRING, wenn der Wert in einem anwendungsdefinierten Intervallformat gespeichert wird.
json STRING
jsonb BYTES
line ARRAY<FLOAT64>
lseg ARRAY<FLOAT64>
macaddr STRING mit der standardmäßigen Schreibweise der MAC-Adresse
money INT64 oder STRING für Zahlen mit beliebiger Genauigkeit
numeric [ (p, s) ]

decimal [ (p, s) ]

In PostgreSQL unterstützen die Datentypen NUMERIC und DECIMAL bis zu 217 Stellen der Genauigkeit und 214-1 Skalierung (wie in der Spalte definiert) Erklärung.

Der Datentyp NUMERIC in Spanner unterstützt bis zu 38 Stellen und 9 Dezimalstellen.

Wenn Sie eine höhere Genauigkeit benötigen, finden Sie unter Numerische Daten mit beliebiger Genauigkeit speichern weitere Informationen.
path ARRAY<FLOAT64>
pg_lsn Dies ist ein PostgreSQL-spezifischer Datentyp, daher gibt es kein Äquivalent in Cloud Spanner.
point ARRAY<FLOAT64>
polygon ARRAY<FLOAT64>
Real

float4

FLOAT64
Smallint

int2

INT64
Smallserial

serial2

INT64
Serial

serial4

INT64
text STRING
time [ (p) ] [ without time zone ] STRING, mit der Schreibweise HH:MM:SS.sss
time [ (p) ] with time zone

timetz

STRING, mit der Schreibweise HH:MM:SS.sss+ZZZZ Alternativ kann diese in zwei Spalten aufgeteilt werden. Dabei hat die eine den Typ TIMESTAMP und die andere enthält die Zeitzone.
timestamp [ (p) ] [ without time zone ] Kein Äquivalent. Kann nach Belieben als STRING oder TIMESTAMP gespeichert werden.
timestamp [ (p) ] with time zone

timestamptz

TIMESTAMP
tsquery Kein Äquivalent. Definieren Sie stattdessen einen Speichermechanismus in der Anwendung.
tsvector Kein Äquivalent. Definieren Sie stattdessen einen Speichermechanismus in der Anwendung.
txid_snapshot Kein Äquivalent. Definieren Sie stattdessen einen Speichermechanismus in der Anwendung.
uuid STRING oder BYTES
xml STRING

Primärschlüssel

Sie sollten in der Cloud Spanner-Datenbank für häufig anzufügende Tabellen keine kontinuierlich größer oder kleiner werdende Primärschlüssel verwenden, da dies bei Schreibvorgängen Hotspots verursacht. Ändern Sie stattdessen die DDL-Anweisungen CREATE TABLE so, dass sie unterstützte Primärschlüsselstrategien verwenden. Ein sorgfältiges Schemadesign ist wichtig, da Sie nach dem Erstellen einer Tabelle keine Primärschlüsselspalte hinzufügen oder entfernen können.

Während der Migration ist es möglicherweise erforderlich, dass Sie einige vorhandene kontinuierlich steigende Ganzzahlschlüssel beibehalten. Wenn eine Aufbewahrung dieser Schlüssel in einer Tabelle erforderlich ist, die häufig aktualisiert wird und viele Vorgänge für diese Schlüssel enthält, können Sie Hotspots vermeiden. Stellen Sie dazu dem vorhandenen Schlüssel eine Pseudogenerierung zufälliger Zahlen voran. Dadurch verteilt Cloud Spanner die Zeilen neu. Weitere Informationen zu diesem Ansatz finden Sie unter Das sollten Datenbankadministratoren über Cloud Spanner wissen, Teil 1: Schlüssel und Indexe.

Fremdschlüssel und referenzielle Integrität

Weitere Informationen zur Unterstützung von Fremdschlüsseln in Cloud Spanner

Indexe

PostgreSQL-B-Tree-Indexe ähneln den sekundären Indexen in Cloud Spanner. In einer Cloud Spanner-Datenbank können Sie mit sekundären Indexen häufig gesuchte Spalten indizieren, so die Leistung verbessern und eindeutige Einschränkungen in den Tabellen ersetzen. 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 Cloud Spanner-DDL verwenden:

CREATE TABLE customer (
   id STRING(5),
   first_name STRING(50),
   last_name STRING(50),
   email STRING(50)
   ) PRIMARY KEY (id);

CREATE UNIQUE INDEX customer_emails ON customer(email);

Wenn Sie die Indexe in PostgreSQL-Tabellen suchen, führen Sie den Meta-Befehl \di in psql aus.

Nachdem Sie die benötigten Indexe ermittelt haben, fügen Sie CREATE INDEX-Anweisungen hinzu, um sie zu erstellen. Folgen Sie der Anleitung unter Indexe erstellen.

Cloud Spanner implementiert Indexe als Tabellen, sodass das Indizieren von kontinuierlich steigenden Spalten (wie solchen, die TIMESTAMP-Daten enthalten) einen Hotspot verursachen kann. Weitere Informationen zu diesem Ansatz finden Sie unter Das sollten Datenbankadministratoren über Cloud Spanner wissen, Teil 1: Schlüssel und Indexe.

Einschränkungen prüfen

Weitere Informationen zur Unterstützung von CHECK-Einschränkung in Cloud Spanner.

Andere Datenbankobjekte

Es ist erforderlich, dass Sie die Funktionen der folgenden Objekte in der Anwendungslogik erstellen:

  • Ansichten
  • Trigger
  • Gespeicherte Prozeduren
  • Nutzerdefinierte Funktionen (UDFs)
  • Spalten mit serial-Datentypen als Sequenzgeneratoren

Beachten Sie bei der Migration dieser Funktionen in die Anwendungslogik die folgenden Hinweise:

Cloud Spanner-Instanz erstellen

Nachdem Sie die DDL-Anweisungen so aktualisiert haben, dass sie den Anforderungen des Cloud Spanner-Schemas entspricht, erstellen Sie die Datenbank in Cloud Spanner.

  1. Erstellen Sie eine Cloud Spanner-Instanz. Folgen Sie der Anleitung unter Instanzen, damit Sie die korrekte regionale Konfiguration und die Anzahl der Knoten ermitteln können, die Ihre Leistungsziele unterstützen.

  2. Erstellen Sie die Datenbank mithilfe der Google Cloud Console oder dem gcloud-Befehlszeilentool:

Console

  1. Zur Seite "Instanzen"
  2. Klicken Sie auf den Namen der Instanz, in der Sie die Beispieldatenbank erstellen möchten, um die Seite mit den Instanzdetails zu öffnen.
  3. Klicken Sie auf Datenbank erstellen.
  4. Geben Sie einen Namen für die Datenbank ein und klicken Sie auf Weiter.
  5. Schalten Sie im Abschnitt Datenbankschema definieren das Steuerelement Als Text bearbeiten ein.
  6. Kopieren Sie Ihre DDL-Anweisungen und fügen Sie sie in das Feld DDL-Anweisungen ein.
  7. Klicken Sie auf Erstellen.

gcloud

  1. Installieren Sie das gcloud-Tool.
  2. Erstellen Sie die Datenbank mit dem Befehl gcloud spanner databases create:
    gcloud spanner databases create DATABASE_NAME --instance=INSTANCE_NAME
    --ddl='DDL1' --ddl='DDL2'
    
  • DATABASE_NAME ist der Name der Datenbank.
  • INSTANCE_NAME ist die von Ihnen erstellte Cloud Spanner-Instanz.
  • DDLn sind Ihre geänderten DDL-Anweisungen.

Folgen Sie nach dem Erstellen der Datenbank der Anleitung unter IAM-Rollen anwenden, um Nutzerkonten zu erstellen und Berechtigungen für die Cloud Spanner-Instanz und -Datenbank zu erteilen.

Anwendungen und Datenzugriffsschichten bearbeiten

Zusätzlich zum Code, der zum Ersetzen der vorhergehenden Datenbankobjekte erforderlich ist, ist es notwendig, dass Sie Anwendungslogik zur Verarbeitung der folgenden Funktionen hinzufügen:

  • Hash-Primärschlüssel für Schreibvorgänge, für Tabellen mit hohen Schreibraten für sequenzielle Schlüssel.
  • Datenvalidierung, die nicht bereits durch CHECK-Einschränkungen abgedeckt ist.
  • Referenzielle, noch nicht durch Fremdschlüssel, Tabellenverschränkungen oder Anwendungslogik abgedeckte Integritätsprüfungen, einschließlich Funktionen, die von Triggern im PostgreSQL-Schema verarbeitet werden.

Wir empfehlen bei der Refaktorierung den folgenden Prozess:

  1. Suchen Sie nach dem gesamten auf die Datenbank zugreifenden Anwendungscode und wandeln Sie ihn in ein einzelnes Modul oder eine Bibliothek um. So wissen Sie genau, welcher Code auf die Datenbank zugreift und welcher Code geändert werden muss.
  2. Schreiben Sie Code, der Lese- und Schreibvorgänge in der Cloud Spanner-Instanz ausführt. So können Sie parallele Funktionen zum ursprünglichen Code bieten, der Lese- und Schreibvorgänge in PostgreSQL ausführt. Aktualisieren Sie während des Schreibvorgangs die gesamte Zeile und nicht nur die geänderten Spalten, damit die Daten in Cloud Spanner tatsächlich mit denen in PostgreSQL übereinstimmen.
  3. Schreiben Sie Code, der die Funktionalität der nicht in Cloud Spanner verfügbaren Datenbankobjekte und Funktionen ersetzt.

Daten migrieren

Nachdem Sie Ihre Cloud Spanner-Datenbank erstellt und den Anwendungscode umgestaltet haben, können Sie Ihre Daten zu Cloud Spanner migrieren.

  1. Sichern Sie mit dem PostgreSQL-Befehl COPY Daten in CSV-Dateien.
  2. Laden Sie die CSV-Dateien in Cloud Storage hoch.

    1. Erstellen Sie einen Cloud Storage-Bucket.
    2. Klicken Sie in der Cloud Storage-Konsole auf den Bucket-Namen, um den Bucket-Browser zu öffnen.
    3. Klicken Sie auf Dateien hochladen.
    4. Gehen Sie zum Verzeichnis mit den CSV-Dateien und wählen Sie die Dateien aus.
    5. Klicken Sie auf Öffnen.
  3. Erstellen Sie eine Anwendung für den Import von Daten in Cloud Spanner. Diese Anwendung kann Dataflow oder die Clientbibliotheken direkt verwenden. Folgen Sie der Anleitung unter Best Practices für das Laden im Bulk, um die beste Leistung zu erzielen.

Test

Testen Sie alle Anwendungsfunktionen mit der Cloud Spanner-Instanz, damit sie tatsächlich erwartungsgemäß funktionieren. Führen Sie Arbeitslasten auf Produktionsebene aus, damit die Leistung Ihren Anforderungen tatsächlich entspricht. Aktualisieren Sie die Anzahl der Knoten nach Bedarf, damit Sie Ihre Leistungsziele erreichen können.

Auf das neue System umsteigen

Nachdem Sie die ersten Anwendungstests abgeschlossen haben, aktivieren Sie das neue System mit einem der folgenden Prozesse. Die Offline-Migration ist die einfachste Methode für die Migration. Bei diesem Ansatz ist Ihre Anwendung jedoch für einen bestimmten Zeitraum nicht verfügbar und es wird kein Rollback-Pfad bereitgestellt, falls später Datenprobleme auftreten sollten. So führen Sie eine Offline-Migration durch:

  1. Löschen Sie alle Daten in der Cloud Spanner-Datenbank.
  2. Fahren Sie die Anwendung herunter, die die PostgreSQL-Datenbank als Ziel hat.
  3. Exportieren Sie alle Daten aus der PostgreSQL-Datenbank und importieren Sie sie in die Cloud Spanner-Datenbank, wie unter Daten migrieren beschrieben.
  4. Starten Sie die Anwendung, die die Cloud Spanner-Datenbank als Ziel hat.

    Datenfluss der Offline-Migration

Eine Live-Migration ist möglich und erfordert umfangreiche Änderungen an Ihrer Anwendung zur Unterstützung der Migration.

Beispiele für Schemamigration

Diese Beispiele zeigen Anweisungen CREATE TABLE für mehrere Tabellen in dem PostgreSQL-DatenbankschemaMusicBrainz. Jedes Beispiel enthält sowohl das PostgreSQL-Schema als auch das Cloud Spanner-Schema.

Tabelle "artist_credit"

PostgreSQL-Version:

CREATE TABLE artist_credit (
  id SERIAL,
  name VARCHAR NOT NULL,
  artist_count SMALLINT NOT NULL,
  ref_count INTEGER DEFAULT 0,
  created TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

Cloud Spanner-Version:

CREATE TABLE artist_credit (
  hashed_id STRING(4),
  id INT64,
  name STRING(MAX) NOT NULL,
  artist_count INT64 NOT NULL,
  ref_count INT64,
  created TIMESTAMP OPTIONS (
     allow_commit_timestamp = true
  ),
) PRIMARY KEY(hashed_id, id);

Tabelle "recording"

PostgreSQL-Version:

CREATE TABLE recording (
  id SERIAL,
  gid UUID NOT NULL,
  name VARCHAR NOT NULL,
  artist_credit INTEGER NOT NULL, -- references artist_credit.id
  length INTEGER CHECK (length IS NULL OR length > 0),
  comment VARCHAR(255) NOT NULL DEFAULT '',
  edits_pending INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >= 0),
  last_updated TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
  video BOOLEAN NOT NULL DEFAULT FALSE
);

Cloud Spanner-Version:

CREATE TABLE recording (
  hashed_id STRING(36),
  id INT64,
  gid STRING(36) NOT NULL,
  name STRING(MAX) NOT NULL,
  artist_credit_hid STRING(36) NOT NULL,
  artist_credit_id INT64 NOT NULL,
  length INT64,
  comment STRING(255) NOT NULL,
  edits_pending INT64 NOT NULL,
  last_updated TIMESTAMP OPTIONS (
     allow_commit_timestamp = true
  ),
  video BOOL NOT NULL,
) PRIMARY KEY(hashed_id, id);

Tabelle "recording-alias"

PostgreSQL-Version:

CREATE TABLE recording_alias (
  id SERIAL, --PK
  recording INTEGER NOT NULL, -- references recording.id
  name VARCHAR NOT NULL,
  locale TEXT,
  edits_pending INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >=0),
  last_updated TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
  type INTEGER, -- references recording_alias_type.id
  sort_name VARCHAR NOT NULL,
  begin_date_year SMALLINT,
  begin_date_month SMALLINT,
  begin_date_day SMALLINT,
  end_date_year SMALLINT,
  end_date_month SMALLINT,
  end_date_day SMALLINT,
  primary_for_locale BOOLEAN NOT NULL DEFAULT false,
  ended BOOLEAN NOT NULL DEFAULT FALSE
  -- CHECK constraint skipped for brevity
);

Cloud Spanner-Version:

CREATE TABLE recording_alias (
  hashed_id STRING(36)  NOT NULL,
  id INT64  NOT NULL,
  alias_id INT64,
  name STRING(MAX)  NOT NULL,
  locale STRING(MAX),
  edits_pending INT64  NOT NULL,
  last_updated TIMESTAMP NOT NULL OPTIONS (
     allow_commit_timestamp = true
  ),
  type INT64,
  sort_name STRING(MAX)  NOT NULL,
  begin_date_year INT64,
  begin_date_month INT64,
  begin_date_day INT64,
  end_date_year INT64,
  end_date_month INT64,
  end_date_day INT64,
  primary_for_locale BOOL NOT NULL,
  ended BOOL NOT NULL,
) PRIMARY KEY(hashed_id, id, alias_id),
 INTERLEAVE IN PARENT recording ON DELETE NO ACTION;