Questa pagina spiega come eseguire la migrazione di un database PostgreSQL open source (d'ora in poi chiamato semplicemente 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 viene implementata per database archiviati a livello di 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 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 di 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 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 chiave primaria per tecnica che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali consigliate.
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 Schema e modello di dati - chiavi principali.
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 contiene questa dichiarazione:
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 di qualsiasi tabella PostgreSQL eseguendo il metacomando \di 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 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 lo stesso di coerenza come le 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 utilizzando gli indici archiviando
copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando
INCLUDE, rendendola una
indice di copertura.
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 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 di indici secondari, consulta Indici secondari. Per ulteriori informazioni sulle limitazioni relative alla creazione di indici, consulta Aggiornamenti dello schema.
Visualizzazioni
Le viste 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 della 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 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 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 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 tabella seguente elenca i tipi di dati PostgreSQL open source non supportati dall'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 |
| cidr | testo |
| cerchio | - |
| Inet | testo |
| numero intero, int4 | bigint, int8 |
| intervallo [fields] [ (p) ] | Bigint |
| json | jsonb |
| linea | - |
| lseg | - |
| macaddr | testo |
| denaro | numeric, decimal |
| 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 ] | 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 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 la documentazione relativa alle best practice per SQL.
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 o un file CSV oppure 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.