Questa pagina spiega come eseguire la migrazione di un database PostgreSQL open source (da ora in poi solo PostgreSQL) a un database dialetto PostgreSQL di Spanner (da 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 determinati concetti in modo diverso da altri strumenti di gestione dei database aziendali, per cui potrebbe essere necessario modificare l'architettura dell'applicazione per sfruttarne al meglio 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; di conseguenza, 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 UUID versione 4 come metodo predefinito per generare coppie chiave-valore primarie. 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 invertire i bit (GoogleSQL, PostgreSQL), che producono valori che si distribuiscono in modo uniforme nello spazio dei numeri positivi a 64 bit. Puoi usare questi numeri per evitare problemi di hotspot.
Per saperne di più, consulta le strategie per i valori predefiniti della chiave principale.
Controlli di accesso
Spanner supporta un controllo dell'accesso granulare a livello di tabella e colonna. Non è supportato un controllo dell'accesso granulare per le visualizzazioni. Per ulteriori informazioni, consulta Informazioni sul controllo dell'accesso granulare.
Processo di migrazione
La migrazione prevede le seguenti attività:
- Mappatura di uno schema PostgreSQL su 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.
- 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 è 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 al suo interno e Spanner utilizza la chiave primaria per ordinare le righe della tabella. Poiché Spanner è altamente distribuito, è importante scegliere una tecnica di generazione chiave primaria che si adatti in modo adeguato alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali che consigliamo.
Tieni presente che, dopo aver designato la chiave primaria, non puoi aggiungere o rimuovere una colonna di chiave primaria né modificare un valore di 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 di PostgreSQL sono simili agli indici secondari in Spanner. In un database Spanner, utilizzi gli indici secondari per indicizzare le colonne cercate più di frequente al fine di migliorare le prestazioni e per sostituire eventuali vincoli UNIQUE specificati nelle tabelle. Ad esempio, se il tuo 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 metacomando \di in psql.
Dopo aver determinato gli indici necessari, aggiungi le istruzioni CREATE INDEX per crearle. Segui le istruzioni 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.
Per saperne di più sui metodi per evitare hotspot, consulta Cosa devono sapere gli DBA su Spanner, parte 1: chiavi e indici.
Spanner implementa gli indici secondari allo stesso modo delle tabelle, pertanto 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 che utilizzano indici secondari sono di fatto le stesse di una query con un join di tabella. Puoi migliorare le prestazioni delle query utilizzando gli indici archiviando le copie dei valori della colonna della tabella originale nell'indice secondario tramite la clausola INCLUDE, rendendolo 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 su cui viene eseguita la query (una query coperta). Per forzare l'utilizzo di un indice durante l'esecuzione di query sulle colonne nella tabella originale, devi utilizzare un'istruzione FORCE INDEX nell'istruzione SQL, ad esempio:
SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;
Ecco un'istruzione DDL di esempio 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 aggiungili a 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 degli indici, consulta Aggiornamenti dello schema.
Viste
Le viste Spanner sono di sola lettura. Non possono essere utilizzate 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 conoscere le differenze e le limitazioni di sintassi.
Interleaving delle tabelle
Spanner include una funzionalità in cui puoi definire due tabelle con una relazione padre-figlio, Questa funzionalità interlaccia le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, unendo efficacemente la tabella prima della tabella e migliorando l'efficienza di recupero dei dati quando le query padre e figlio vengono eseguite insieme.
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 è definita come chiave esterna. Puoi definire fino a 6 livelli di relazioni padre-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 oppure l'eliminazione della riga padre viene bloccata quando esistono le 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 ulteriori informazioni, vedi Creare tabelle con interleaving.
Tipi di dati
La seguente tabella elenca i tipi di dati PostgreSQL open source non supportati dall'interfaccia PostgreSQL per Spanner.
| Tipo di dati | Utilizza invece |
|---|---|
| bigserial,serie8 | bigint, int8 |
| bit [ (n) ] | - |
| bit variabile [ (n) ], varbit [ (n) ] | - |
| postale | - |
| carattere [ (n) ], carattere [ (n) ] | carattere variabile |
| cidr | testo |
| cerchio | - |
| Inet | testo |
| numero intero, int4 | bigint, int8 |
| intervallo [fields] [ (p) ] | Bigint |
| json | JSON |
| linea | - |
| Lseg | - |
| Macadr | testo |
| denaro | numerico, decimale |
| percorso | - |
| pg_lsn | - |
| punto | - |
| poligono | - |
| realfloat4 | precisione doppia, float8 |
| smallint, int2 | bigint, int8 |
| smallserial, serial2 | bigint, int8 |
| seriale, seriale4 | bigint, int8 |
| ora [ (p) ] [ senza fuso orario ] | utilizzando la notazione HH:MM:SS.sss |
| ora [ (p) ] con fuso orario | utilizzando la notazione HH:MM:SS.sss+ZZZZ. In alternativa, utilizza due colonne. |
| timestamp [ (p) ] [ senza fuso orario ] | testo o timestamptz |
| tsquery | - |
| tsvector | - |
| txid_snapshot | - |
| uuid | text o bytea |
| xml | testo |
Passaggio 2: traduci eventuali query SQL
Spanner offre molte delle funzioni open source PostgreSQL disponibili per ridurre il carico delle conversioni.
Le query SQL possono essere profilate utilizzando la pagina di Spanner Studio nella console Google Cloud per eseguire la query. In generale, le query che eseguono scansioni complete delle tabelle 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 sulle best practice SQL.
Passaggio 3: crea l'istanza, il database e lo schema Spanner
Creare l'istanza e creare un database nel dialetto PostgreSQL. Poi crea lo schema utilizzando il Data Definition Language (DDL) di 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: refactoring dell'applicazione
Aggiungere la logica dell'applicazione per tenere conto dello schema modificato e delle query SQL riviste e 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 la migrazione sia dello schema sia dei dati. Puoi importare un file pg_dump o un file CSV oppure eseguire l'importazione tramite 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.