Questa pagina spiega come eseguire la migrazione di un database PostgreSQL open source (d'ora in poi chiamato semplicemente PostgreSQL) a un database dialettico PostgreSQL di Spanner (d'ora in poi denominato Spanner).
Per informazioni sulla migrazione a Spanner e al dialetto GoogleSQL, consulta Migrazione da PostgreSQL a Spanner (dialetto GoogleSQL).
Vincoli di migrazione
Spanner utilizza alcuni concetti in modo diverso rispetto ad altri strumenti di gestione dei database aziendali, quindi potrebbe essere necessario regolare l'architettura della tua applicazione per sfruttarne appieno le 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 del codice utente a livello di database, quindi, nell'ambito della migrazione, la logica di business implementata da procedure e trigger archiviati a livello di database deve essere spostata nell'applicazione.
Sequenze
Spanner consiglia di utilizzare UUID versione 4 come metodo predefinito per generare coppie chiave primaria-valore. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce i valori UUID 4 della versione 4 rappresentati come tipo STRING.
Se devi generare valori interi, Spanner supporta sequenze positive invertite a bit (GoogleSQL, PostgreSQL), che producono valori che distribuiscono uniformemente nello spazio numerico positivo a 64 bit. Puoi usare questi numeri per evitare problemi di hotspot.
Per ulteriori informazioni, consulta le strategie per il valore predefinito della chiave principale.
Controlli di accesso
Spanner supporta un controllo dell'accesso granulare a livello di tabella e colonna. Il controllo granulare dell'accesso per le viste non è supportato. Per ulteriori informazioni, consulta Informazioni sul controllo dell'accesso granulare.
Processo di migrazione
La migrazione prevede le seguenti attività:
- Mappare uno schema PostgreSQL a Spanner.
- Traduzione di query SQL.
- 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.
Passaggio 1: mappa lo schema PostgreSQL a Spanner
Il primo passaggio per spostare un database da PostgreSQL open source a Spanner è determinare quali modifiche allo schema devi apportare.
Chiavi primarie
In Spanner, ogni tabella che deve archiviare 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 della tabella e Spanner utilizza la chiave primaria per ordinare le righe della tabella. Poiché Spanner è un'elevata distribuzione, è importante scegliere una tecnica di generazione di chiave primaria che si adatti bene alla crescita dei tuoi dati. Per ulteriori informazioni, consulta le strategie di migrazione della chiave principale consigliate.
Tieni presente che dopo aver designato la chiave primaria, non puoi aggiungere o rimuovere una colonna di chiave primaria o modificare il valore di una 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 primarie.
Indici
Gli indici b-tree PostgreSQL sono simili agli indici secondari di Spanner. In un database Spanner utilizzi indici secondari per indicizzare le colonne cercate più spesso al fine di migliorare le prestazioni e per sostituire eventuali vincoli UNIQUE specificati nelle tabelle. Ad esempio, se il DDL PostgreSQL
ha questa istruzione:
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 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 per qualsiasi tabella PostgreSQL eseguendo il meta-comando \di in psql.
Dopo aver determinato gli indici che ti servono, aggiungi istruzioni CREATE INDEX per crearli. Segui le indicazioni riportate in Indici secondari.
Spanner implementa gli indici come tabelle, pertanto l'indicizzazione delle colonne in aumento monotonico (come quelle contenenti dati TIMESTAMP) può causare un hotspot.
Consulta Cosa devono sapere i database su Spanner, parte 1: chiavi e indici per saperne di più sui metodi per evitare gli hotspot.
Spanner implementa gli indici secondari come le tabelle, quindi i valori delle colonne da utilizzare come chiavi di indice avranno gli stessi vincoli delle chiavi primarie delle tabelle. Ciò significa anche che gli indici hanno le stesse garanzie di coerenza delle tabelle Spanner.
Le ricerche di valori mediante indici secondari sono sostanzialmente identiche a quelle di una query con un join di tabella. Puoi migliorare le prestazioni delle query utilizzando gli indici archiviando copie dei valori delle colonne della tabella originale nell'indice secondario tramite la clausola INCLUDE, che diventa un indice di copertura.
Lo strumento di ottimizzazione delle query di Spanner utilizza automaticamente un indice secondario solo quando l'indice stesso archivia tutte le colonne sottoposte a query (una query coperta). Per forzare l'utilizzo di un indice quando si eseguono 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;
Ecco un esempio di istruzione DDL che crea un indice secondario per la tabella Album:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Se crei indici aggiuntivi dopo aver caricato i dati, il completamento dell'indice potrebbe richiedere del tempo. Ti consigliamo di limitare la frequenza con cui le aggiungi a una media di tre al giorno. Per ulteriori indicazioni sulla creazione di indici secondari, consulta Indici secondari. Per maggiori informazioni sui limiti relativi alla creazione degli indici, consulta Aggiornamenti dello schema.
Viste
Le viste Spanner sono di sola lettura. e non possono essere usati per inserire, aggiornare o eliminare dati. Per ulteriori informazioni, consulta la sezione Visualizzazioni.
Colonne generate
Spanner supporta le colonne generate. Consulta Creare e gestire le colonne generate per le differenze e le limitazioni di sintassi.
Interfoliazione delle tabelle
Spanner offre una funzionalità per cui puoi definire due tabelle con una relazione padre-figlio 1-molti. Questa funzionalità alterna le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, in modo efficace prima del join della tabella e migliorando l'efficienza del recupero dati quando vengono eseguite query insieme su elementi padre e figlio.
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 viene indicata come chiave esterna. Puoi definire fino a 6 livelli di rapporti genitore-figlio.
Puoi definire azioni ON DELETE per le tabelle figlio per determinare cosa succede quando viene eliminata la riga padre: vengono eliminate tutte le righe figlio o l'eliminazione delle righe padre viene bloccata mentre esistono righe figlio.
Ecco un esempio di creazione di una tabella Album con interleaving nella tabella Singers principale definita in precedenza:
CREATE TABLE Albums (
SingerID bigint,
AlbumID bigint,
AlbumTitle varchar,
PRIMARY KEY (SingerID, AlbumID)
)
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
Per saperne di più, vedi Creare tabelle con interleaving.
Tipi di dati
La seguente tabella elenca i tipi di dati PostgreSQL open source che l'interfaccia PostgreSQL per Spanner non supporta.
| Tipo di dati | Utilizza |
|---|---|
| bigserial,serial8 | bigint, int8 |
| bit [ (n) ] | - |
| bit variabile [ (n) ], varbit [ (n) ] | - |
| riquadro | - |
| carattere [ (n) ], carattere [ (n) ] | carattere con variazioni |
| cidr | testo |
| cerchio | - |
| Inet | testo |
| numero intero, int4 | bigint, int8 |
| intervallo [fields] [ (p) ] | Bigint |
| json | jsonb |
| linea | - |
| Lseg | - |
| Macaddr | testo |
| denaro | numerico, decimale |
| percorso | - |
| pg_lsn | - |
| punto | - |
| poligono | - |
| realfloat4 | precisione doppia, float8 |
| smallint, int2 | bigint, int8 |
| smallserial, serial2 | bigint, int8 |
| seriale, serial4 | bigint, int8 |
| ora [ (p) ] [ senza fuso orario ] | utilizzando la notazione HH:MM:SS.sss |
| orario [ (p) ] con fuso orariotimetz | utilizzando la notazione HH:MM:SS.sss+ZZZZ. Oppure utilizza due colonne. |
| timestamp [ (p) ] [ senza fuso orario ] | testo o timestamptz |
| tsquery | - |
| TsVector | - |
| txid_snapshot | - |
| uuid | testo o bytea |
| xml | testo |
Passaggio 2: traduci le query SQL
Spanner dispone di molte delle funzioni PostgreSQL open source disponibili per ridurre il carico della conversione.
Per eseguire la query, puoi profilare le query SQL utilizzando la pagina Spanner Studio della console Google Cloud. In generale, le query che eseguono scansioni complete delle tabelle su tabelle di grandi dimensioni sono molto costose e dovrebbero essere utilizzate con parsimonia. Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta la documentazione sulle best practice per SQL.
Passaggio 3: crea l'istanza, il database e lo schema Spanner
Crea l'istanza e crea un database nel dialetto PostgreSQL. Poi crea il tuo schema utilizzando il linguaggio DDL (Data Definition Language) PostgreSQL.
Utilizza pg_dump per creare istruzioni DDL che definiscono gli oggetti nel tuo 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, consulta:
Passaggio 4: esegui il refactoring dell'applicazione
Aggiungi la logica dell'applicazione per tenere conto dello schema modificato e delle query SQL riviste, nonché per sostituire la logica residente del database, come procedure e trigger.
Passaggio 5: esegui la migrazione dei dati
Esistono due modi per eseguire la migrazione dei dati:
Utilizzando Harbourbridge.
Harbourbridge supporta sia la migrazione di schemi che di dati. Puoi importare un file pg_dump o un file CSV oppure puoi eseguire l'importazione tramite una connessione diretta al database PostgreSQL open source.
Con il comando
COPY FROM STDIN.Per maggiori dettagli, vedi Comando COPY per importare i dati.