Questa pagina spiega come eseguire la migrazione di un database PostgreSQL open source (d'ora in poi chiamato semplicemente PostgreSQL) a un database in dialetto PostgreSQL di Spanner (d'ora in poi chiamato Spanner).
Per informazioni sulla migrazione a Spanner e sul dialetto GoogleSQL, consulta Eseguire la migrazione da PostgreSQL a Spanner (dialetto GoogleSQL).
Vincoli di migrazione
Spanner utilizza determinati concetti in modo diverso rispetto ad altri strumenti di gestione dei database aziendali, pertanto potrebbe essere necessario modificare l'architettura dell'applicazione per sfruttare appieno le sue funzionalità. Potresti anche dover integrare Spanner con altri servizi di Google Cloud per soddisfare le tue esigenze.
Stored procedure e trigger
Spanner non supporta l'esecuzione di codice utente a livello di database, pertanto, nell'ambito della migrazione, la logica di business implementata da trigger e procedure archiviate a livello di database deve essere spostata nell'applicazione.
Sequenze
Spanner consiglia di utilizzare la versione 4 di UUID come metodo predefinito per generare i valori della chiave primaria. La funzione GENERATE_UUID() (GoogleSQL,
PostgreSQL)
restituisce valori UUID versione 4 rappresentati come tipo STRING.
Se devi generare valori interi, Spanner supporta sequenze positive con inversione dei bit (GoogleSQL, PostgreSQL), che producono valori distribuiti in modo uniforme nello spazio numerico positivo a 64 bit. Puoi utilizzare questi numeri per evitare problemi di hotspotting.
Per ulteriori informazioni, consulta le strategie per i valori predefiniti delle chiavi principali.
Controlli di accesso
Spanner supporta il controllo dell'accesso granulare a livello di tabella e colonna. Il controllo granulare degli accessi per le visualizzazioni non è supportato. Per ulteriori informazioni, consulta Informazioni sul controllo dell'accesso granulare.
Processo di migrazione
La migrazione prevede le seguenti attività:
- Mappatura di uno schema PostgreSQL a Spanner.
- Traduzione delle query SQL.
- Creazione di un'istanza, un database e uno schema Spanner.
- Rifacimento dell'applicazione per il funzionamento con il database Spanner.
- Migrazione dei dati.
- Verifica del nuovo sistema e passaggio allo stato di produzione.
Passaggio 1: mappa lo schema PostgreSQL a Spanner
Il primo passaggio per spostare un database da PostgreSQL open source a Spanner consiste nel determinare le modifiche dello schema da apportare.
Chiavi primarie
In Spanner, ogni tabella che deve memorizzare più di una riga deve avere una chiave primaria composta da una o più colonne della tabella. La chiave primaria della tabella identifica in modo univoco ogni riga di una tabella e Spanner la utilizza per ordinare le righe della tabella. Poiché Spanner è molto distribuito, è importante scegliere una tecnica di generazione della chiave primaria che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali consigliate.
Tieni presente che, dopo aver designato la chiave primaria, non puoi aggiungere o rimuovere una colonna della chiave primaria né modificare un valore della chiave primaria in un secondo momento senza eliminare e ricreare la tabella. Per ulteriori informazioni su come designare la chiave primaria, consulta Schema e modello dei dati - chiavi principali.
Indici
Gli indici b-tree di PostgreSQL sono simili agli indici secondari in Spanner. In un database Spanner utilizzi gli indici secondari per indicizzare le colonne più comunemente cercate per migliorare le prestazioni e per sostituire eventuali vincoli UNIQUE specificati nelle tabelle. Ad esempio, se il tuo DDL PostgreSQL contiene questa dichiarazione:
CREATE TABLE customer (
id CHAR (5) PRIMARY KEY,
first_name VARCHAR (50),
last_name VARCHAR (50),
email VARCHAR (50) UNIQUE
);
Puoi utilizzare la seguente istruzione nel DDL di Spanner:
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);
Puoi trovare gli indici di qualsiasi tabella PostgreSQL eseguendo il metacomando \di in psql.
Dopo aver determinato gli indici necessari, aggiungi le istruzioni CREATE INDEX per crearli. Segui le indicazioni riportate in Indici secondari.
Spanner implementa gli indici come tabelle, pertanto l'indicizzazione delle colonne con incrementi monotonici (come quelle contenenti dati TIMESTAMP) può causare un hotspot.
Per ulteriori informazioni sui metodi per evitare gli hotspot, consulta
Informazioni per i DBA su Spanner, parte 1: chiavi e indici.
Spanner implementa gli indici secondari nello stesso modo delle tabelle, quindi i valori delle colonne da utilizzare come chiavi di indice avranno gli stessi vincoli delle chiavi principali delle tabelle. Ciò significa anche che gli indici hanno le stesse garanzie di coerenza delle tabelle Spanner.
Le ricerche dei valori che utilizzano gli indici secondari sono in pratica le stesse di una query con una join di tabelle. Puoi migliorare le prestazioni delle query che utilizzano gli indici memorizzando copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando la clausola INCLUDE, creando così un indice che copre.
L'ottimizzatore delle query di Spanner utilizza automaticamente un indice secondario solo quando l'indice stesso memorizza tutte le colonne su cui viene eseguita la query (una query coperta). Per forzare l'utilizzo di un indice quando esegui query sulle colonne della tabella originale, devi utilizzare un'istruzione FORCE INDEX nell'istruzione SQL, ad esempio:
SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;
Di seguito è riportato un esempio di istruzione DDL che crea un indice secondario per la tabella Albums:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Se crei altri indici dopo aver caricato i dati, l'inserimento dell'indice potrebbe richiedere del tempo. Ti consigliamo di limitarne la frequenza ad una media di tre al giorno. Per ulteriori indicazioni sulla creazione di indici secondari, consulta Indici secondari. Per ulteriori informazioni sulle limitazioni relative alla creazione di indici, consulta Aggiornamenti dello schema.
Visualizzazioni
Le visualizzazioni di Spanner sono di sola lettura. Non possono essere utilizzati per inserire, aggiornare o eliminare dati. Per ulteriori informazioni, consulta la sezione Visualizzazioni.
Colonne generate
Spanner supporta le colonne generate. Per le differenze e le limitazioni di sintassi, consulta Creare e gestire le colonne generate.
Interfoliazione delle tabelle
Spanner dispone di una funzionalità che consente di definire due tabelle come esistenti in una relazione 1-many padre-figlio. Questa funzionalità intercala le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, pre-unire efficacemente la tabella e migliorare l'efficienza del recupero dei dati quando vengono eseguite query su righe padre e figlie contemporaneamente.
La chiave primaria della tabella figlio deve iniziare con le colonne di chiave primaria della tabella padre. Dal punto di vista della riga figlio, la chiave primaria della riga padre è indicata come chiave esterna. Puoi definire fino a 6 livelli di relazioni tra elementi principali e secondari.
Puoi definire azioni ON DELETE per le tabelle secondarie per determinare cosa succede quando viene eliminata la riga principale: tutte le righe secondarie vengono eliminate o l'eliminazione della riga principale viene bloccata se esistono righe secondarie.
Ecco un esempio di creazione di una tabella Album interlacciata nella tabella principale Cantanti definita in precedenza:
CREATE TABLE Albums (
SingerID bigint,
AlbumID bigint,
AlbumTitle varchar,
PRIMARY KEY (SingerID, AlbumID)
)
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
Per ulteriori informazioni, vedi Creare tabelle con interleaving.
Tipi di dati
La tabella seguente elenca i tipi di dati PostgreSQL open source non supportati dall'interfaccia PostgreSQL per Spanner.
| Tipo di dati | Utilizza invece |
|---|---|
| bigserial,serial8 | bigint, int8 |
| bit [ (n) ] | - |
| bit variabile [ (n) ], varbit [ (n) ] | - |
| scatola | - |
| character [ (n) ], char [ (n) ] | carattere variabile |
| cidr | testo |
| cerchio | - |
| inet | testo |
| numero intero, int4 | bigint, int8 |
| intervallo [campi] [ (p) ] | bigint |
| json | jsonb |
| linea | - |
| lseg | - |
| macaddr | testo |
| denaro | numeric, decimal |
| percorso | - |
| pg_lsn | - |
| punto | - |
| poligono | - |
| realfloat4 | a precisione doppia, float8 |
| smallint, int2 | bigint, int8 |
| smallserial, serial2 | bigint, int8 |
| serial, serial4 | bigint, int8 |
| ora [ (p) ] [ senza fuso orario ] | testo, utilizzando la notazione HH:MM:SS.sss |
| ora [ (p) ] con fuso orariotimetz | di testo, utilizzando la notazione HH:MM:SS.sss+ZZZZ. In alternativa, utilizza due colonne. |
| timestamp [ (p) ] [ senza fuso orario ] | text o timestamptz |
| tsquery | - |
| tsvector | - |
| txid_snapshot | - |
| UUID | text o bytea |
| xml | testo |
Passaggio 2: traduci eventuali query SQL
Spanner offre molte delle funzioni PostgreSQL open source per contribuire a ridurre il carico di conversione.
È possibile eseguire il profiling delle query SQL utilizzando la pagina Spanner Studio nella console Google Cloud per eseguire la query. In generale, le query che eseguono scansioni complete della tabella su tabelle di grandi dimensioni sono molto costose e devono essere utilizzate con parsimonia. Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta la documentazione relativa alle best practice per SQL.
Passaggio 3: crea l'istanza, il database e lo schema Spanner
Crea l'istanza e un database nel dialetto PostgreSQL. Quindi, crea lo schema utilizzando il linguaggio di definizione dei dati (DDL) PostgreSQL.
Utilizza
pg_dump
per creare istruzioni DDL che definiscono gli oggetti nel
database PostgreSQL, quindi modifica le istruzioni come descritto nelle
sezioni precedenti. Dopo aver aggiornato le istruzioni DDL, utilizzale per creare il database nell'istanza Spanner.
Per ulteriori informazioni, vedi:
Passaggio 4: esegui il refactoring dell'applicazione
Aggiungi la logica di applicazione per tenere conto dello schema modificato e delle query SQL riviste e per sostituire la logica residente nel database, come procedure e trigger.
Passaggio 5: esegui la migrazione dei dati
Esistono due modi per eseguire la migrazione dei dati:
Utilizzando lo strumento di migrazione di Spanner.
Lo strumento di migrazione di Spanner supporta sia la migrazione dello schema sia quella dei dati. Puoi importare un file pg_dump o un file CSV oppure puoi importare i dati utilizzando una connessione diretta al database PostgreSQL open source.
Utilizzando il comando
COPY FROM STDIN.Per maggiori dettagli, vedi Comando COPY per l'importazione dei dati.