Questa pagina fornisce indicazioni sulla migrazione di un database PostgreSQL open source a Spanner.
La migrazione prevede le seguenti attività:
- Mappare uno schema PostgreSQL a uno schema Spanner.
- Creazione di un'istanza, un database e uno schema Spanner.
- Refactoring dell'applicazione in modo che funzioni con il database Spanner.
- Migrazione dei dati in corso.
- È in corso la verifica del nuovo sistema e lo stato di produzione.
Questa pagina fornisce anche alcuni schemi di esempio che utilizzano le tabelle MusicBrainz PostgreSQL standard.
Mappare lo schema PostgreSQL a Spanner
Il primo passaggio per spostare un database da PostgreSQL a Spanner è
determinare quali modifiche allo schema devi apportare. Utilizza le funzionalità di
pg_dump
per creare istruzioni DDL (Data Definition Language) che definiscono gli oggetti in
il tuo database PostgreSQL e quindi modificare le istruzioni come descritto in
le sezioni seguenti. Dopo aver aggiornato le istruzioni DDL, utilizzale
per creare il database
in un'istanza Spanner.
Tipi di dati
La tabella seguente descrive come Tipi di dati PostgreSQL ai tipi di dati di Spanner. Aggiornare i tipi di dati nelle istruzioni DDL dai tipi di dati PostgreSQL ai tipi di dati Spanner.
PostgreSQL | Spanner |
---|---|
Bigint
|
INT64 |
Bigserial
|
INT64 |
bit [ (n) ] |
ARRAY<BOOL> |
bit varying [ (n) ]
|
ARRAY<BOOL> |
Boolean
|
BOOL |
box |
ARRAY<FLOAT64> |
bytea |
BYTES |
character [ (n) ]
|
STRING |
character varying [ (n) ]
|
STRING |
cidr |
STRING , utilizzando la notazione CIDR standard. |
circle |
ARRAY<FLOAT64> |
date |
DATE |
double precision
|
FLOAT64 |
inet |
STRING |
Integer
|
INT64 |
interval[ fields ] [ (p) ] |
INT64 se memorizzi il valore in millisecondi o STRING se memorizzi il valore in un formato di intervallo definito dall'applicazione. |
json |
STRING |
jsonb |
JSON |
line |
ARRAY<FLOAT64> |
lseg |
ARRAY<FLOAT64> |
macaddr |
STRING , utilizzando la notazione indirizzo MAC standard. |
money |
INT64 o STRING per i numeri di precisione arbitraria. |
numeric [ (p, s) ]
|
In PostgreSQL, i tipi di dati NUMERIC e DECIMAL supportano fino a 217 cifre di precisione e 214-1 di scala, come definito nella dichiarazione della colonna.Il tipo di dati Spanner NUMERIC supporta fino a 38 cifre di precisione e 9 cifre decimali di scala.Se hai bisogno di una maggiore precisione, consulta l'articolo Archiviazione di dati numerici di precisione arbitraria per meccanismi alternativi. |
path |
ARRAY<FLOAT64> |
pg_lsn |
Questo tipo di dati è specifico per PostgreSQL, quindi non esiste un equivalente per Spanner. |
point |
ARRAY<FLOAT64> |
polygon |
ARRAY<FLOAT64> |
Real
|
FLOAT64 |
Smallint
|
INT64 |
Smallserial
|
INT64 |
Serial
|
INT64 |
text |
STRING |
time [ (p) ] [ without time zone ] |
STRING , utilizzando la notazione HH:MM:SS.sss . |
time [ (p) ] with time zone
|
STRING , utilizzando la notazione HH:MM:SS.sss+ZZZZ . In alternativa, può essere suddiviso in due colonne, una di tipo TIMESTAMP e un'altra con il fuso orario. |
timestamp [ (p) ] [ without time zone ] |
Nessun equivalente. Puoi archiviare come STRING o TIMESTAMP a tua discrezione. |
timestamp [ (p) ] with time zone
|
TIMESTAMP |
tsquery |
Nessun equivalente. Definisci un meccanismo di archiviazione nell'applicazione. |
tsvector |
Nessun equivalente. Definisci un meccanismo di archiviazione nell'applicazione. |
txid_snapshot |
Nessun equivalente. Definisci un meccanismo di archiviazione nell'applicazione. |
uuid |
STRING o BYTES |
xml |
STRING |
Chiavi primarie
Per le tabelle del database Spanner che aggiungi spesso, evita
utilizzando chiavi primarie che aumentano o diminuiscono in modo monotonico,
causa hotspot durante le scritture. Modifica invece le istruzioni DDL CREATE TABLE
.
in modo da usare
strategie di chiave primaria supportate. Se utilizzi
una funzionalità PostgreSQL come una funzione o un tipo di dati UUID
, dati SERIAL
colonna IDENTITY
o sequenza, puoi utilizzare
strategie di migrazione delle chiavi generate automaticamente che consigliamo.
Tieni presente che una volta designata la chiave primaria, non puoi più aggiungere o rimuovere una colonna di chiave primaria o modifica il valore di una chiave primaria in un secondo momento senza eliminare per ricreare la tabella. Per ulteriori informazioni su come designare la chiave primaria, consulta la sezione Schema e modello dei dati - principale chiave.
Durante la migrazione, potrebbe essere necessario mantenere alcune di numeri interi. Se hai bisogno di mantenere questi tipi di chiavi in un con molte operazioni su queste chiavi, potete evitare di creare hotspot far precedere la chiave esistente da un numero pseudo-casuale. Questa tecnica causa Spanner per ridistribuire le righe. Consulta Cosa devono sapere i DBA su Spanner, parte 1: chiavi e indici per ulteriori informazioni sull'uso di questo approccio.
Chiavi esterne e integrità referenziale
Scopri di più sul supporto delle chiavi esterne in Spanner.
Indici
PostgreSQL
Indici b-tree
sono simili agli indici secondari in
Spanner. In un database Spanner utilizzi indici secondari per
indicizzare le colonne cercate più spesso per migliorare il rendimento e sostituire eventuali
UNIQUE
vincoli specificati nelle tabelle. Ad esempio, se il tuo DDL PostgreSQL
include questa affermazione:
CREATE TABLE customer (
id CHAR (5) PRIMARY KEY,
first_name VARCHAR (50),
last_name VARCHAR (50),
email VARCHAR (50) UNIQUE
);
Dovresti utilizzare questa istruzione nel DDL di Spanner:
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);
Puoi trovare gli indici per qualsiasi tabella PostgreSQL eseguendo il comando
\di
meta-comando in psql
.
Dopo aver determinato gli indici che ti servono, aggiungi
Estratti conto CREATE INDEX
per crearle. Segui le indicazioni alla pagina
Creazione degli indici.
Spanner implementa gli indici come tabelle, pertanto l'indicizzazione in modo monotonico
L'aumento delle colonne (come quelle contenenti dati di TIMESTAMP
) può causare un hotspot.
Consulta
Cosa devono sapere i DBA su Spanner, parte 1: chiavi e indici
per ulteriori informazioni sui metodi per evitare gli hotspot.
Controlla i vincoli
Scopri di più sul supporto dei vincoli CHECK
in Spanner.
Altri oggetti di database
Devi creare la funzionalità degli oggetti seguenti nell'applicazione logica:
- Visualizzazioni
- Trigger
- Stored procedure
- Funzioni definite dall'utente
- Colonne che utilizzano i tipi di dati
serial
come generatori di sequenze
Quando esegui la migrazione di questa funzionalità in della logica dell'applicazione:
- Devi eseguire la migrazione delle istruzioni SQL che utilizzi dal dialetto SQL PostgreSQL nel dialetto GoogleSQL.
- Se utilizzi cursori, puoi rielaborare la query offset e limiti.
Crea la tua istanza Spanner
Dopo aver aggiornato le istruzioni DDL per renderle conformi allo schema Spanner utilizzalo per creare il tuo database in Spanner.
Crea un'istanza di Spanner. Segui le indicazioni in Istanze per determinare la configurazione regionale e la capacità di calcolo corrette per supportare obiettivi di rendimento.
Crea il database utilizzando la console Google Cloud oppure
gcloud
Strumento a riga di comando:
Console
- Vai alla pagina Istanze
- Fai clic sul nome dell'istanza in cui vuoi creare l'esempio per aprire la pagina Dettagli istanza.
- Fai clic su Crea database.
- Digita un nome per il database e fai clic su Continua.
- Nella sezione Definisci lo schema del database, attiva Modifica come testo.
- Copia e incolla le istruzioni DDL nel campo Istruzioni DDL.
- Fai clic su Crea.
gcloud
- Installa gcloud CLI.
- Usa il comando
gcloud spanner databases create
per crea il database:gcloud spanner databases create DATABASE_NAME --instance=INSTANCE_NAME --ddl='DDL1' --ddl='DDL2'
- DATABASE_NAME è il nome del tuo database.
- INSTANCE_NAME è l'istanza Spanner che hai creato.
- DDLn sono le tue istruzioni DDL modificate.
Dopo aver creato il database, segui le istruzioni in Applicare ruoli IAM per creare account utente e concedere le autorizzazioni all'istanza e al database Spanner.
Esegui il refactoring delle applicazioni e dei livelli di accesso ai dati
Oltre al codice necessario per sostituire il precedenti degli oggetti di database, devi aggiungere un'applicazione logica per gestire le seguenti funzionalità:
- Hashing delle chiavi primarie per le scritture, per le tabelle con velocità di scrittura elevate su sequenziali.
- Convalida dei dati, non ancora coperti dai vincoli
CHECK
. - Controlli di integrità referenziali non ancora coperti da chiavi esterne, tabella interleaving o logica dell'applicazione, incluse le funzionalità gestite nello schema PostgreSQL.
Ti consigliamo di utilizzare la seguente procedura per il refactoring:
- Individuare tutto il codice dell'applicazione che accede al database ed eseguirne il refactoring in un singolo modulo o in una singola libreria. In questo modo, sai esattamente quale codice accede al database e, di conseguenza, esattamente quale codice modificato.
- Scrivi il codice che esegue letture e scritture sull'istanza Spanner, fornendo funzionalità parallele al codice originale che legge e scrive in PostgreSQL. Durante le scritture, aggiorna l'intera riga, non solo le colonne che sono stati modificati, per garantire che i dati in Spanner identico a quello di PostgreSQL.
- Scrivi un codice che sostituisca la funzionalità degli oggetti di database e che non sono disponibili in Spanner.
Migrazione dei dati
Dopo aver creato il database Spanner ed eseguire il refactoring dell'applicazione esegui la migrazione dei dati in Spanner.
- Utilizza PostgreSQL
COPY
per eseguire il dump dei dati in file .csv. Carica i file .csv in Cloud Storage.
- Crea un bucket Cloud Storage.
- Nella console di Cloud Storage, fai clic sul nome del bucket per aprirlo nel browser del bucket.
- Fai clic su Carica file.
- Passa alla directory contenente i file .csv e selezionali.
- Fai clic su Apri.
Crea un'applicazione per importare i dati in Spanner. Questa applicazione potresti utilizzare Dataflow oppure potrebbe utilizzare le librerie client strato Add. Assicurati di seguire le indicazioni in Best practice per il caricamento collettivo dei dati per ottenere le migliori prestazioni possibili.
Test
Testa tutte le funzioni dell'applicazione sull'istanza Spanner per verificare che funzionino come previsto. Esegui carichi di lavoro a livello di produzione per garantire il rendimento sia più adatto alle tue esigenze. Aggiornare la capacità di calcolo in base alle necessità per raggiungere i tuoi obiettivi di rendimento.
Passa al nuovo sistema
Dopo aver completato il test iniziale dell'applicazione, attiva il nuovo sistema utilizzando uno dei seguenti processi. La migrazione offline è il modo più semplice eseguire la migrazione. Tuttavia, questo approccio rende la tua applicazione non disponibile per un determinato periodo e non fornisce un percorso di rollback se in seguito si riscontrano problemi con i dati. A eseguire una migrazione offline:
- Elimina tutti i dati nel database Spanner.
- Arresta l'applicazione che ha come target il database PostgreSQL.
- Esporta tutti i dati dal database PostgreSQL e importali nel Database Spanner come descritto in Migrazione dei dati.
Avvia l'applicazione che ha come target il database Spanner.
La migrazione live è possibile e richiede modifiche significative all'applicazione per per supportare la migrazione.
Esempi di migrazione degli schemi
Questi esempi mostrano le istruzioni CREATE TABLE
per diverse tabelle in
Database PostgreSQL di MusicBrainz
schema.
Ogni esempio include sia lo schema PostgreSQL sia lo schema Spanner.
tabella artist_credit
Versione PostgreSQL:
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()
);
Versione Spanner:
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);
tabella di registrazione
Versione PostgreSQL:
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
);
Versione Spanner:
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);
tabella alias registrazione
Versione PostgreSQL:
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
);
Versione Spanner:
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;