Questa pagina spiega come eseguire la migrazione di un database PostgreSQL open source (d'ora in poi solo PostgreSQL) a un Database Spanner con dialetto PostgreSQL (d'ora in poi denominato Spanner).
Per informazioni su 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 altre strumenti di gestione di database, quindi potrebbe essere necessario regolare un'architettura di Kubernetes per sfruttarne appieno le funzionalità. Potresti anche dover integrare Spanner con altri servizi Google Cloud per soddisfare le tue esigenze.
Stored procedure e trigger
Spanner non supporta l'esecuzione di codice utente a livello di database, Quindi, nell'ambito della migrazione, la logica di business è implementata da dati archiviati a livello di database e i trigger devono essere spostati 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 i valori UUID 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 utilizza 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 tabella e colonna livello. Il controllo granulare dell'accesso per le viste non è supportato. Per ulteriori informazioni consulta l'articolo 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 determina 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 tabella la chiave primaria identifica in modo univoco ogni riga di una tabella e Spanner utilizza la chiave primaria per ordinare le righe della tabella. Poiché Spanner è molto distribuito, è importante scegliere una generazione di chiave primaria tecnica che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta strategie di migrazione della chiave principale consigliati.
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.
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 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 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
Indici secondari.
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.
Spanner implementa gli indici secondari come le tabelle, perciò i valori delle colonne da usare come chiavi di indice avranno gli stessi vincoli come chiavi primarie delle tabelle. Ciò significa anche che gli indici hanno lo stesso di coerenza come le tabelle Spanner.
Le ricerche di valori mediante indici secondari sono effettivamente identiche a quelle di una query con un
join tabella. Puoi migliorare le prestazioni delle query utilizzando gli indici archiviando
copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando
INCLUDE, rendendola una
indice di copertura.
Lo strumento di ottimizzazione delle query di Spanner utilizza solo automaticamente un quando l'indice stesso archivia tutte le colonne sottoposte a query (una query). Per forzare l'utilizzo di un indice quando si eseguono query sulle colonne dell'originale devi utilizzare una classe Direttiva 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 gli album tabella:
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Se crei indici aggiuntivi dopo aver caricato i dati, la compilazione l'indice potrebbe richiedere del tempo. Ti consigliamo di limitare la frequenza con cui si aggiungono a una media di tre al giorno. Per ulteriori indicazioni sulla creazione indici secondari, consulta Indici secondari. Per ulteriori informazioni sui limiti della creazione degli indici, consulta Aggiornamenti dello schema.
Visualizzazioni
Le viste Spanner sono di sola lettura. Non possono essere utilizzate per inserire, aggiornare eliminare i dati. Per ulteriori informazioni, consulta la sezione Visualizzazioni.
Colonne generate
Spanner supporta le colonne generate. Consulta Crea e gestisci le colonne generate per la sintassi differenze e limitazioni.
Interfoliazione delle tabelle
Spanner ha una funzionalità in cui puoi definire due tabelle con un 1-molti, relazione genitore-figlio. Questa funzionalità alterna le righe di dati figlio accanto alla riga padre nello spazio di archiviazione, in modo efficace prima del join con la tabella e migliorare l'efficienza del recupero dati quando viene eseguita una query sull'elemento principale e su quelli secondari.
La chiave primaria della tabella figlio deve iniziare con le colonne di chiave primaria del nella tabella padre. Dal punto di vista della riga secondaria, la chiave primaria della riga padre è o chiave esterna. Puoi definire fino a 6 livelli di relazioni.
Puoi definire ON DELETE azioni
delle tabelle figlio per determinare cosa succede quando viene eliminata la riga padre:
vengono eliminate tutte le righe secondarie oppure l'eliminazione delle righe padre è bloccata
sono presenti righe secondarie.
Ecco un esempio di creazione di una tabella Album con interfoliazione nella sezione Cantanti principali 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 non supporta l'interfaccia PostgreSQL per Spanner.
| Tipo di dati | Utilizza |
|---|---|
| bigserial,serial8 | bigint, int8 |
| bit [ (n) ] | - |
| bit variabile [ (n) ], varbit [ (n) ] | - |
| riquadro | - |
| carattere [ (n) ], carattere [ (n) ] | carattere con variazioni |
| sidro | 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 offre molti dei database open source PostgreSQL funzioni disponibili per ridurre il carico delle conversioni.
Le query SQL possono essere profilate utilizzando la pagina Spanner Studio in nella console Google Cloud per eseguire la query. In generale, le query che eseguire scansioni complete delle tabelle su tabelle di grandi dimensioni sono molto costose e dovrebbero con parsimonia. Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta Best practice per SQL documentazione.
Passaggio 3: crea l'istanza, il database e lo schema Spanner
Crea l'istanza e crea un database in PostgreSQL dialetto. Poi crea lo schema utilizzando la definizione dei dati PostgreSQL lingua (DDL).
Utilizza le funzionalità di
pg_dump
per creare istruzioni DDL che definiscono gli oggetti
il tuo database PostgreSQL e quindi modificare le istruzioni come descritto in
sezioni precedenti. Dopo aver aggiornato le istruzioni DDL, utilizza le istruzioni DDL
per creare il database
nell'istanza Spanner.
Per ulteriori informazioni, vedi:
Passaggio 4: esegui il refactoring dell'applicazione
Aggiungi la logica dell'applicazione per tenere conto dello schema modificato e dell'SQL rivisto query e per sostituire la logica residente nel database, ad esempio 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 oppure CSV oppure puoi importarlo 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.