Migrazione dal sistema Oracle OLTP a Spanner

Questo articolo spiega come eseguire la migrazione del database dai sistemi Oracle® Online Transaction Processing (OLTP) a Spanner.

Spanner utilizza alcuni concetti in modo diverso rispetto ad altri strumenti di gestione dei database aziendali, quindi potrebbe essere necessario modificare l'applicazione per sfruttarne appieno le funzionalità. Potresti anche dover integrare Spanner con altri servizi di Google Cloud per soddisfare le tue esigenze.

Vincoli di migrazione

Quando esegui la migrazione dell'applicazione a Spanner, devi tenere conto delle diverse funzionalità disponibili. Probabilmente avrai bisogno di riprogettare l'architettura della tua applicazione per adattarla al set di funzionalità di Spanner e per integrarla con i servizi aggiuntivi di Google Cloud.

Stored procedure e trigger

Spanner non supporta l'esecuzione di codice utente a livello di database, quindi, durante la migrazione, devi spostare nell'applicazione la logica di business implementata da procedure e trigger archiviati a livello di database.

Sequenze

Ti consigliamo di utilizzare l'UUID versione 4 come metodo predefinito per generare coppie chiave-valore primarie. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce i valori dell'UUID 4 della versione 4 come tipo STRING.

Se devi generare valori interi a 64 bit, Spanner supporta sequenze invertite di bit positive (GoogleSQL, PostgreSQL), che producono valori che vengono distribuiti in modo uniforme nello spazio dei numeri positivo a 64 bit. Puoi utilizzare 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 i controlli dell'accesso a livello di database che usano ruoli e autorizzazioni di accesso IAM. I ruoli predefiniti possono concedere accesso in lettura/scrittura o sola lettura al database.

Se hai bisogno di autorizzazioni più granulari, devi implementarle a livello di applicazione. In uno scenario normale, solo all'applicazione dovrebbe essere consentita la lettura e la scrittura sul database.

Se devi esporre il database agli utenti per la generazione di report e vuoi utilizzare autorizzazioni di sicurezza granulari (ad esempio autorizzazioni a livello di tabella e vista), devi esportare il database in BigQuery.

Vincoli di convalida dei dati

Spanner può supportare un set limitato di vincoli di convalida dei dati nel livello di database.

Se hai bisogno di vincoli per i dati più complessi, implementali nel livello dell'applicazione.

La tabella seguente illustra i tipi di vincoli comunemente presenti nei database Oracle® e come implementarli con Spanner.

Vincolo Implementazione con Spanner
Non null NOT NULLvincolo di colonna
Univoco Indice secondario con vincolo UNIQUE
Chiave esterna (per tabelle normali) Vedi Creare e gestire relazioni di chiave esterna.
Azioni chiave esterna ON DELETE/ON UPDATE Possibile solo per tabelle con interleaving, altrimenti implementate nel livello dell'applicazione
Controlli e convalida dei valori tramite vincoli o attivatori CHECK Implementata nel livello dell'applicazione

Tipi di dati supportati

I database Oracle® e Spanner supportano diversi set di tipi di dati. Nella tabella seguente sono elencati i tipi di dati Oracle e il relativo equivalente in Spanner. Per definizioni dettagliate di ogni tipo di dati di Spanner, consulta Tipi di dati.

Potrebbe inoltre essere necessario eseguire trasformazioni aggiuntive sui dati come descritto nella colonna Note per adattare i dati Oracle al tuo database Spanner.

Ad esempio, puoi archiviare un BLOB di grandi dimensioni come oggetto in un bucket Cloud Storage anziché nel database, quindi archiviare il riferimento URI all'oggetto Cloud Storage nel database come STRING.

Tipo di dati Oracle Equivalente Spanner Note
Tipi di caratteri (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Nota: Spanner utilizza stringhe Unicode ovunque.
Oracle supporta una lunghezza massima di 32.000 byte o caratteri (a seconda del tipo), mentre Spanner supporta fino a 2.621.440 caratteri.
BLOB, LONG RAW, BFILE BYTES o STRING contenente l'URI dell'oggetto. Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati come BYTES.
Valuta la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per archiviare oggetti più grandi.
CLOB, NCLOB, LONG STRING (contenente dati o URI dell'oggetto esterno) Gli oggetti di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati come STRING. Valuta la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per archiviare oggetti più grandi.
NUMBER, NUMERIC, DECIMAL STRING, FLOAT64, INT64 Il tipo di dati Oracle NUMBER supporta fino a 38 cifre di precisione, mentre il tipo di dati Spanner FLOAT64 supporta fino a 16 cifre di precisione. Consulta Archiviazione di dati numerici di precisione arbitraria per meccanismi alternativi.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La rappresentazione predefinita STRING del tipo Spanner DATE è yyyy-mm-dd, che è diversa da Oracle, quindi presta attenzione quando effettui automaticamente la conversione da e verso rappresentazioni STRING di date. Le funzioni SQL sono fornite per convertire le date in una stringa formattata.
DATETIME TIMESTAMP Spanner archivia l'ora indipendentemente dal fuso orario. Se devi archiviare un fuso orario, devi utilizzare una colonna STRING separata. Le funzioni SQL sono fornite per convertire i timestamp in una stringa formattata utilizzando i fusi orari.
XML STRING (contenente dati o URI dell'oggetto esterno) Gli oggetti XML di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati come STRING. Valuta l'uso di offerte alternative di Google Cloud, come Cloud Storage, per archiviare oggetti più grandi.
URI, DBURI, XDBURI e HTTPURI STRING
ROWID PRIMARY KEY Spanner utilizza la chiave primaria della tabella per ordinare e fare riferimento alle righe internamente, quindi in Spanner è di fatto uguale al tipo di dati ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Spanner non supporta i tipi di dati geospaziali. Dovrai archiviare questi dati utilizzando tipi di dati standard e implementare qualsiasi logica di ricerca e filtro nel livello dell'applicazione.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo e ORDImageSignature Spanner non supporta i tipi di dati multimediali. Valuta la possibilità di utilizzare Cloud Storage per archiviare i dati multimediali.

Processo di migrazione

Una tempistica generale del processo di migrazione sarebbe:

  1. Converti lo schema e il modello dei dati.
  2. Traduci le query SQL.
  3. Esegui la migrazione della tua applicazione per utilizzare Spanner oltre a Oracle.
  4. Esporta in blocco i dati da Oracle e importa i dati in Spanner utilizzando Dataflow.
  5. Mantieni la coerenza tra entrambi i database durante la migrazione.
  6. Esegui la migrazione dell'applicazione da Oracle.

Passaggio 1: converti il database e lo schema

Converti lo schema esistente in uno schema Spanner per archiviare i tuoi dati. Questo dovrebbe corrispondere il più fedelmente possibile allo schema Oracle esistente per semplificare le modifiche alle applicazioni. Tuttavia, a causa delle differenze nelle funzionalità, sarà necessario apportare alcune modifiche.

L'utilizzo delle best practice per la progettazione dello schema può aiutarti ad aumentare la velocità effettiva e a ridurre gli hotspot nel tuo database Spanner.

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 le righe della tabella sono ordinate per chiave primaria. Poiché Spanner è altamente distribuito, è 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 né 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.

Interfoliare le tabelle

Spanner offre una funzionalità per cui puoi definire due tabelle come se abbiano una relazione padre-figlio uno a molti. In questo modo le righe di dati figlio vengono interlacciate con la riga padre nello spazio di archiviazione, in modo efficace prima del join della tabella e migliorando l'efficienza del recupero 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 viene indicata come chiave esterna. Puoi definire fino a 6 livelli di rapporti genitore-figlio.

Puoi definire le azioni all'eliminazione 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 è 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     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Crea indici secondari

Puoi anche creare indici secondari per indicizzare i dati all'interno della tabella al di fuori della chiave primaria.

Spanner implementa gli indici secondari come le tabelle, quindi i valori delle colonne da utilizzare come chiavi di indice hanno 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 i valori delle colonne della tabella originale nell'indice secondario tramite la clausola STORING, che diventa un indice di copertura.

Lo strumento di ottimizzazione delle query di Spanner utilizzerà automaticamente gli indici secondari 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=@value

Gli indici possono essere utilizzati per applicare valori univoci all'interno di una colonna della tabella, definendo un indice UNIQUE in quella colonna. L'indice non impedirà l'aggiunta di valori duplicati.

Ecco un esempio di istruzione DDL che crea un indice secondario per la tabella Album:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Tieni presente che se crei indici aggiuntivi dopo aver caricato i dati, il completamento dell'indice potrebbe richiedere del tempo. Dovresti 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 maggiori informazioni sui limiti relativi alla creazione degli indici, consulta Aggiornamenti dello schema.

Passaggio 2: traduci le query SQL

Spanner utilizza il dialetto ANSI 2011 di SQL con estensioni e dispone di molti funzioni e operatori per tradurre e aggregare i dati. Devi convertire tutte le query SQL che utilizzano sintassi, funzioni e tipi specifici di Oracle per renderli compatibili con Spanner.

Sebbene Spanner non supporti i dati strutturati come definizioni di colonne, i dati strutturati possono essere utilizzati nelle query SQL con i tipi ARRAY e STRUCT.

Ad esempio, potrebbe essere scritta una query per restituire tutti gli album di un artista utilizzando un ARRAY di STRUCTs in una singola query (sfruttando i dati pre-uniti). Per ulteriori informazioni, consulta la sezione Note sulle sottoquery della documentazione.

Per eseguire la query SQL, puoi profilare le query SQL utilizzando la pagina Spanner Studio di Google Cloud Console. In generale, le query che eseguono scansioni complete delle tabelle su tabelle di grandi dimensioni sono molto costose e dovrebbero essere usate con parsimonia.

Per ulteriori informazioni sull'ottimizzazione delle query SQL, consulta la documentazione sulle best practice SQL.

Passaggio 3: esegui la migrazione dell'applicazione per utilizzare Spanner

Spanner offre un set di librerie client per vari linguaggi e la possibilità di leggere e scrivere dati utilizzando chiamate API specifiche di Spanner, nonché utilizzando query SQL e istruzioni DML (Data Modifica Language). L'utilizzo delle chiamate API può essere più veloce per alcune query, ad esempio le letture di righe dirette per chiave, poiché l'istruzione SQL non deve essere tradotta.

Puoi anche utilizzare il driver Java Database Connectivity (JDBC) per connetterti a Spanner, sfruttando gli strumenti e l'infrastruttura esistenti che non hanno integrazione nativa.

Nell'ambito del processo di migrazione, le funzionalità non disponibili in Spanner devono essere implementate nell'applicazione. Ad esempio, un trigger per verificare i valori dei dati e aggiornare una tabella correlata deve essere implementato nell'applicazione utilizzando una transazione di lettura/scrittura per leggere la riga esistente, verificare il vincolo, quindi scrivere le righe aggiornate in entrambe le tabelle.

Spanner offre transazioni di lettura/scrittura e di sola lettura, che garantiscono la coerenza esterna dei dati. Inoltre, alle transazioni di lettura possono essere applicati limiti di timestamp, che consentono di leggere una versione coerente dei dati specificati nei seguenti modi:

  • A un'ora esatta nel passato (fino a un'ora fa).
  • In futuro (dove la lettura si bloccherà fino all'arrivo di quel momento).
  • Con una quantità accettabile di inattività limitata, che restituisce una visualizzazione coerente fino a un certo periodo di tempo nel passato senza dover verificare la disponibilità di dati in un secondo momento su un'altra replica. Ciò può portare vantaggi in termini di prestazioni a scapito di dati potenzialmente inattivi.

Passaggio 4: trasferisci i dati da Oracle a Spanner

Per trasferire i tuoi dati da Oracle a Spanner, dovrai esportare il database Oracle in un formato file portatile, ad esempio CSV, quindi importare i dati in Spanner utilizzando Dataflow.

Il processo di estrazione, trasformazione e caricamento in Dataflow

Esportazione collettiva da Oracle

Oracle non fornisce utilità integrate per l'esportazione o l'unload dell'intero database in un formato file portatile.

Alcune opzioni per eseguire un'esportazione sono elencate nelle Domande frequenti su Oracle.

Questi includono:

Ognuna di queste presenta lo svantaggio che è possibile esportare una sola tabella alla volta, il che significa che è necessario mettere in pausa l'applicazione o disattivare il database in modo che rimanga in uno stato coerente per l'esportazione.

Tra le altre opzioni sono inclusi gli strumenti di terze parti elencati nella pagina delle domande frequenti su Oracle, alcuni dei quali possono scaricare una visualizzazione coerente dell'intero database.

Dopo l'unload, devi caricare questi file di dati in un bucket di Cloud Storage in modo che siano accessibili per l'importazione.

Importazione collettiva in Spanner

Poiché gli schemi del database probabilmente differiscono tra Oracle e Spanner, potrebbe essere necessario eseguire alcune conversioni dei dati come parte del processo di importazione.

Il modo più semplice per eseguire queste conversioni e importare i dati in Spanner è utilizzare Dataflow.

Dataflow è il servizio distribuito Extract Transform and Load (ETL) di Google Cloud. Fornisce una piattaforma per eseguire pipeline di dati scritte utilizzando l'SDK Apache Beam al fine di leggere ed elaborare grandi quantità di dati in parallelo su più macchine.

L'SDK Apache Beam richiede la scrittura di un semplice programma Java per impostare le operazioni di lettura, trasformazione e scrittura dei dati. I connettori Beam esistono per Cloud Storage e Spanner, quindi l'unico codice che deve essere scritto è la trasformazione dei dati.

Guarda un esempio di una pipeline semplice che legge dai file CSV e scrive in Spanner nel repository di codice di esempio che accompagna questo articolo.

Se nello schema Spanner vengono utilizzate tabelle con interfoliazione padre-figlio, devi prestare attenzione durante il processo di importazione in modo che la riga padre venga creata prima della riga secondaria. Il codice pipeline di importazione di Spanner gestisce questo processo importando prima tutti i dati per le tabelle di livello principale, poi tutte le tabelle figlio di livello 1, poi tutte le tabelle figlio di livello 2 e così via.

La pipeline di importazione di Spanner può essere utilizzata direttamente per importare i dati in blocco,ma per farlo è necessario che i dati esistano in file Avro utilizzando lo schema corretto.

Passaggio 5: mantieni la coerenza tra i due database

Molte applicazioni hanno requisiti di disponibilità che rendono impossibile mantenere l'applicazione offline per il tempo necessario a esportare e importare i dati. Mentre trasferisci i dati in Spanner, la tua applicazione continua a modificare il database esistente. Devi duplicare gli aggiornamenti al database Spanner mentre l'applicazione è in esecuzione.

Esistono vari metodi per mantenere sincronizzati i due database, tra cui Change Data Capture e l'implementazione di aggiornamenti simultanei nell'applicazione.

Change Data Capture (CDC)

Oracle GoldenGate può fornire un flusso di Change Data Capture (CDC) per il tuo database Oracle. Oracle LogMiner o Oracle XStream Out sono interfacce alternative per il database Oracle per ottenere un flusso CDC che non prevede Oracle GoldenGate.

Puoi scrivere un'applicazione che si abbona a uno di questi flussi e che applica le stesse modifiche (ovviamente dopo la conversione dei dati) al tuo database Spanner. Un'applicazione di elaborazione dei flussi deve implementare diverse funzionalità:

  • Connessione al database Oracle (database di origine).
  • Connessione a Spanner (database di destinazione).
  • Eseguire ripetutamente le seguenti operazioni:
    • Ricezione dei dati prodotti da uno dei flussi CDC del database Oracle.
    • Interpretazione dei dati prodotti dal flusso CDC.
    • Conversione dei dati in istruzioni INSERT di Spanner.
    • Esecuzione delle istruzioni INSERT di Spanner.

La tecnologia di migrazione dei database è una tecnologia middleware che ha implementato le caratteristiche richieste come parte della sua funzionalità. La piattaforma di migrazione del database viene installata come componente separato nella località di origine o in quella di destinazione, in base ai requisiti del cliente. La piattaforma di migrazione dei database richiede solo la configurazione della connettività dei database coinvolti per specificare e avviare il trasferimento continuo di dati dall'origine al database di destinazione.

Striim è una piattaforma tecnologica per la migrazione dei database disponibile su Google Cloud. Fornisce connettività ai flussi CDC da Oracle GoldenGate nonché da Oracle LogMiner e Oracle XStream Out. Striim fornisce uno strumento grafico che consente di configurare la connettività del database e le regole di trasformazione necessarie per trasferire i dati da Oracle a Spanner.

Puoi installare Striim da Google Cloud Marketplace, connetterti ai database di origine e di destinazione, implementare eventuali regole di trasformazione e iniziare a trasferire i dati senza dover creare personalmente un'applicazione per l'elaborazione dei flussi.

Aggiornamenti simultanei a entrambi i database dall'applicazione

Un metodo alternativo è modificare l'applicazione per eseguire scritture in entrambi i database. Un database (inizialmente Oracle) verrebbe considerato l'origine dati attendibile e, dopo la scrittura di ogni database, l'intera riga viene letta, convertita e scritta nel database Spanner.

In questo modo, l'applicazione sovrascrive costantemente le righe Spanner con i dati più recenti.

Dopo aver verificato che tutti i dati siano stati trasferiti correttamente, puoi trasferire l'origine attendibile al database Spanner.

Questo meccanismo fornisce un percorso di rollback in caso di problemi durante il passaggio a Spanner.

Verifica la coerenza dei dati

Man mano che vengono trasmessi i flussi di dati nel database Spanner, puoi eseguire periodicamente un confronto tra i dati di Spanner e quelli di Oracle per assicurarti che i dati siano coerenti.

Per convalidare la coerenza, esegui query su entrambe le origini dati e confronta i risultati.

Puoi utilizzare Dataflow per eseguire un confronto dettagliato tra set di dati di grandi dimensioni utilizzando la trasformazione Join. Questa trasformazione prende 2 set di dati con chiave e associa i valori in base alla chiave. I valori corrispondenti possono quindi essere confrontati per trovare l'uguaglianza.

Puoi eseguire regolarmente questa verifica finché il livello di coerenza non soddisfa i requisiti della tua attività.

Passaggio 6: passa a Spanner come fonte attendibile dell'applicazione

Una volta acquisita fiducia nella migrazione dei dati, puoi passare l'applicazione all'utilizzo di Spanner come origine attendibile. Continua a scrivere le modifiche al database Oracle per mantenere aggiornato il database Oracle, fornendoti un percorso di rollback in caso di problemi.

Infine, puoi disabilitare e rimuovere il codice di aggiornamento del database Oracle e arrestare il database Oracle.

Esporta e importa i database Spanner

Facoltativamente, puoi esportare le tabelle da Spanner in un bucket Cloud Storage utilizzando un modello Dataflow per eseguire l'esportazione. La cartella risultante contiene un insieme di file Avro e file manifest JSON contenenti le tabelle esportate. Questi file possono servire a vari scopi, tra cui:

  • Backup del database per la conformità ai criteri di conservazione dei dati o il ripristino di emergenza.
  • Importare il file Avro in altre offerte Google Cloud come BigQuery.

Per ulteriori informazioni sul processo di esportazione e importazione, consulta Esportazione di database e Importazione dei database.

Passaggi successivi