Migrazione da Oracle® Da sistema OLTP a Spanner

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

Spanner utilizza alcuni concetti in modo diverso rispetto ad altre strumenti di gestione dei database, quindi potresti dover regolare l'applicazione sfruttare appieno le sue capacità. Potresti anche dover integrare Spanner con altri servizi 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 dell'applicazione per adattarla al set di funzionalità di Spanner e l'integrazione con altri servizi Google Cloud.

Stored procedure e trigger

Spanner non supporta l'esecuzione di codice utente a livello di database, pertanto, nell'ambito della migrazione, devi spostare la logica di business implementata da trigger e procedure archiviate a livello di database nell'applicazione.

Sequenze

Ti consigliamo di utilizzare la versione 4 di UUID come metodo predefinito per generare i valori della chiave primaria. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce i valori UUID versione 4 come tipo STRING.

Se devi generare valori interi a 64 bit, Spanner supporta le sequenze con inversione dei bit positive (GoogleSQL, PostgreSQL), che producono valori distribuiti uniformemente nello spazio numerico 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 solo i controlli dell'accesso a livello di database utilizzando i ruoli e le autorizzazioni di accesso IAM. I ruoli predefiniti possono fornire accesso in lettura/scrittura o di sola lettura al database.

Se hai bisogno di autorizzazioni più granulari, devi implementarle a livello di applicazione. In uno scenario normale, solo l'applicazione autorizzati in lettura e scrittura al database.

Se devi esporre il database agli utenti per il reporting e vuoi usare autorizzazioni di sicurezza granulari (come autorizzazioni a livello di tabella e visualizzazione), devi esportare il database BigQuery.

Vincoli di convalida dei dati

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

Se hai bisogno di vincoli più complessi per i dati, implementali in il 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 le tabelle normali) Vedi Creare e gestire relazioni di chiave esterna.
Azioni ON DELETE/ON UPDATE della chiave esterna Possibile solo per tabelle interlacciate, altrimenti implementato nel livello di 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. La tabella seguente elenca i tipi di dati Oracle e il loro equivalente in Spanner. Per definizioni dettagliate di ogni tipo di dato Spanner, consulta Tipi di dati.

Potresti anche dover eseguire ulteriori trasformazioni sui dati descritto nella colonna Note per adattare i dati Oracle il 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 sempre stringhe Unicode.
Oracle supporta una lunghezza massima di 32.000 byte o caratteri (a seconda 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.
Valutare l'utilizzo di offerte Google Cloud alternative come Cloud Storage per archiviare oggetti più grandi.
CLOB, NCLOB, LONG STRING (contenente dati o URI a un 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 di dimensioni maggiori.
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. Per meccanismi alternativi, consulta Memorizzazione di dati numerici di precisione arbitraria.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La rappresentazione STRING predefinita del tipo DATE di Spanner è yyyy-mm-dd, che è diversa da quella di Oracle, quindi fai attenzione quando esegui la conversione automatica da e verso le rappresentazioni STRING delle date. Le funzioni SQL sono fornite per convertire le date in una stringa formattata.
DATETIME TIMESTAMP Spanner archivia l'ora indipendentemente dal fuso orario. Per se archivi un fuso orario, devi utilizzare una colonna STRING separata. Sono disponibili funzioni SQL per convertire i timestamp in una stringa formattata utilizzando i fusi orari.
XML STRING (contenente dati o URI a un oggetto esterno) Gli oggetti XML di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati STRING. Valutare l'utilizzo di offerte Google Cloud alternative ad esempio Cloud Storage, per archiviare oggetti più grandi.
URI, DBURI, XDBURI, HTTPURI STRING
ROWID PRIMARY KEY Spanner utilizza la chiave primaria della tabella per ordinare e fare riferimento alle righe internamente, quindi in Spanner è praticamente lo stesso del tipo di dato ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Spanner non supporta i tipi di dati geospaziali. Dovrai memorizzare questi dati utilizzando tipi di dati standard e implementare qualsiasi logica di ricerca e filtro nel livello di applicazione.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo, 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. Tradurre eventuali query SQL.
  3. Esegui la migrazione dell'applicazione per utilizzare Spanner, oltre a Oracle
  4. Esportare in blocco i dati da Oracle e importare i dati in Spanner usando Dataflow.
  5. Mantieni la coerenza tra i due 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 Spanner schema per archiviare i dati. Dovrebbe corrispondere allo schema Oracle esistente il più per semplificare le modifiche alle applicazioni. Tuttavia, a causa differenze nelle funzionalità, saranno necessarie alcune modifiche.

Utilizzo best practice per la progettazione dello schema può contribuire ad aumentare la velocità effettiva e a ridurre gli hotspot nel il 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 di una tabella e le righe della tabella sono ordinate in base alla chiave primaria. Poiché Spanner è altamente distribuito, è importante scegliere una tecnica di generazione della chiave primaria che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali consigliate.

Tieni presente che dopo aver scelto la chiave primaria, non puoi 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.

Interfoliare le tabelle

Spanner dispone di una funzionalità che consente di definire due tabelle come aventi una relazione padre-figlio uno a molti. In questo modo le righe di dati figlio con la 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 figlio, la chiave primaria della riga padre è indicata come chiave esterna. Puoi definire fino a 6 livelli di relazioni.

Puoi definire azioni al momento dell'eliminazione per le tabelle secondarie per determinare cosa succede quando viene eliminata la riga principale: o vengono eliminate tutte le righe secondarie oppure 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     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 nello stesso modo delle tabelle, pertanto 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 effettivamente identiche a quelle di una query con un join tabella. Puoi migliorare le prestazioni delle query che utilizzano gli indici memorizzando le copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando la clausola STORING, rendendolo un indice che copre.

L'ottimizzatore delle query di Spanner utilizzerà automaticamente gli indici secondari 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 si eseguono query sulle colonne dell'originale devi utilizzare 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 a Indice UNIQUE in quella colonna. L'indice impedirà l'aggiunta di valori duplicati.

Ecco un esempio di istruzione DDL che crea un indice secondario per gli album tabella:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Tieni presente che se crei indici aggiuntivi dopo aver caricato i dati, la compilazione l'indice potrebbe richiedere del tempo. Dovresti limitare la frequenza di aggiunta a una media di tre al giorno. Per ulteriori indicazioni sulla creazione di indici secondari, consulta Indici secondari. Per ulteriori informazioni sui limiti della 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 aiutarti a tradurre e aggregare i dati. Devi convertire le query SQL che utilizzano sintassi, funzioni e tipi specifici di Oracle in modo che siano compatibili con Spanner.

Sebbene Spanner non supporti i dati strutturati come colonna definizioni, i dati strutturati possono essere usati nelle query SQL utilizzando ARRAY e Tipi di STRUCT.

Ad esempio, è possibile scrivere una query per restituire tutti gli album di un artista utilizzando un ARRAY di STRUCTs in una singola query (sfruttando i dati precombinati). Per ulteriori informazioni, consulta la sezione Note sulle sottoquery della documentazione.

Le query SQL possono essere profilate utilizzando la pagina Spanner Studio in nella Google Cloud Console 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.

Consulta le Best practice per SQL documentazione per saperne di più sull'ottimizzazione delle query SQL.

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

Spanner fornisce un insieme di librerie client per vari linguaggi e la possibilità di leggere e scrivere dati utilizzando chiamate API specifiche di Spanner, nonché query SQL e istruzioni Data Manipulation Language (DML). L'utilizzo delle chiamate API potrebbe essere più veloce per alcune query, come le letture di righe dirette per chiave, perché 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 dispongono di integrazione nativa.

Nell'ambito del processo di migrazione, le funzionalità non sono disponibili Spanner deve essere implementato nella un'applicazione. Ad esempio, un attivatore per verificare i valori dei dati e aggiornare un deve essere implementata nell'applicazione utilizzando un sistema di lettura/scrittura transazione per leggere la riga esistente, verifica il vincolo, quindi scrivi ha aggiornato le righe in entrambe le tabelle.

Offerte Spanner transazioni di lettura/scrittura e di sola lettura, che garantiscono la coerenza esterna dei tuoi dati. Inoltre, alle transazioni di lettura possono essere applicati limiti di timestamp, se stai leggendo una versione coerente dei dati specificati in questi modi:

  • In un momento esatto nel passato (fino a 1 ora fa).
  • In futuro (in cui la lettura si bloccherà fino all'arrivo di quel momento).
  • Con un livello accettabile di inattualità limitata, che restituirà una visualizzazione coerente fino a un determinato momento nel passato senza dover verificare che i dati più recenti siano disponibili su un'altra replica. Questo può migliorare le 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, è necessario esporta il database Oracle in un formato file portatile, ad esempio CSV, quindi importare questi dati in Spanner usando Dataflow.

Il processo di estrazione, trasformazione e caricamento in Dataflow

Esportazione collettiva da Oracle

Oracle non fornisce utilità integrate per esportare o scaricare l'intero database in un formato file portatile.

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

Queste includono:

Ognuno di questi ha lo svantaggio di poter esportare una sola tabella alla volta, il che significa che devi mettere in pausa l'applicazione o mettere in stato di riposo il database in modo che rimanga in uno stato coerente per l'esportazione.

Sono disponibili anche gli strumenti di terze parti elencati nella Domande frequenti su Oracle pagina, alcune delle quali possono scaricare una visualizzazione coerente dell'intero per configurare un database.

Una volta scaricati, devi caricare questi file di dati in un Cloud Storage in modo che siano accessibili per l'importazione.

Importazione collettiva in Spanner

Poiché gli schemi di database probabilmente sono diversi tra Oracle e Spanner, potrebbe essere necessario eseguire alcune conversioni dei dati nell'ambito del processo di importazione.

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

Dataflow è il servizio distribuito Extract Transform and Load di Google Cloud (ETL). Fornisce una piattaforma per l'esecuzione di pipeline di dati scritte utilizzando l'SDK Apache Beam per 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 trasformare e scrivere i dati. Esistono connettori Beam per Cloud Storage e Spanner, quindi l'unico codice che deve essere scritto sono i dati e si trasformeranno automaticamente.

Guarda un esempio di una semplice pipeline che legge dai file CSV e scrive Spanner nella repository di codice di esempio che accompagna il presente articolo.

Se in Spanner vengono utilizzate tabelle con interfoliazione padre-figlio occorre prestare attenzione durante il processo di importazione, in modo che la riga padre venga creato prima della riga secondaria. La Codice pipeline di importazione di Spanner gestisce l'operazione importando prima tutti i dati per le tabelle di livello principale, poi tutti le tabelle figlio di livello 1, tutte le tabelle figlio di livello 2 e così via.

La pipeline di importazione di Spanner può essere utilizzata direttamente per importare collettivamente i dati, ma è necessario che i dati esistano in file Avro che utilizzano 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. Durante il trasferimento dei dati in Spanner, continua a modificare il database esistente. Devi duplicare gli aggiornamenti al database Spanner durante l'esecuzione dell'applicazione.

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

Change Data Capture (CDC)

Oracle GoldenGate può fornire uno stream di acquisizione dei dati modificati (CDC) per il tuo database Oracle. Oracle LogMiner o Oracle XStream Out sono interfacce alternative per il database Oracle per ottenere uno stream CDC che non coinvolge 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) ai tuoi il 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:
    • Ricevere i dati prodotti da uno degli stream CDC del database Oracle.
    • Interpretazione dei dati prodotti dal flusso CDC.
    • Conversione dei dati in istruzioni INSERT di Spanner.
    • Eseguire le istruzioni INSERT di Spanner.

La tecnologia di migrazione del database è una tecnologia middleware che ha implementato le funzionalità richieste nell'ambito della propria funzionalità. La piattaforma di migrazione dei database viene installato come componente separato nella posizione di origine o nella destinazione località, in conformità con i requisiti del cliente. La migrazione del database richiede solo la configurazione della connettività dei database coinvolti per specificare e avviare un trasferimento continuo di dati dall'origine database di destinazione.

Striim è una piattaforma di tecnologia di 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 ti consente di configurare connettività di database ed eventuali regole di trasformazione necessarie per trasferire i dati da Oracle a Spanner.

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

Aggiornamenti simultanei di entrambi i database dall'applicazione

Un metodo alternativo consiste nel modificare l'applicazione in modo da eseguire scritture in entrambi i database. Un database (inizialmente Oracle) verrebbe considerato l'origine e, dopo la scrittura di ogni database, l'intera riga viene letta, convertita e vengono scritte nel database Spanner.

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

Una volta accertato che tutti i dati sono stati trasferiti correttamente, puoi cambiare l'origine attendibile nel database Spanner.

Questo meccanismo fornisce un percorso di rollback se vengono rilevati problemi durante il passaggio Spanner.

Verifica la coerenza dei dati

Quando i dati vengono inseriti nel database Spanner, puoi eseguire periodicamente un confronto tra i dati di Spanner e quelli di Oracle per assicurarti che siano coerenti.

Puoi convalidare la coerenza eseguendo query su entrambe le origini dati e confrontando che consentono di analizzare i dati e visualizzare i risultati.

Puoi utilizzare Dataflow per eseguire un confronto dettagliato su set di dati di grandi dimensioni utilizzando la trasformazione Join. Questa trasformazione prende due set di dati con chiave e abbina i valori in base alla chiave. I valori corrispondenti possono quindi essere confrontati per verificare se sono uguali.

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

Quando hai la certezza che la migrazione dei dati sia andata a buon fine, puoi impostare la tua applicazione in modo che utilizzi 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 disattivare e rimuovere il codice di aggiornamento del database Oracle e arrestare il database Oracle.

Esportare e importare 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 conformità o emergenza ai criteri di conservazione dei dati e il ripristino di emergenza.
  • Importazione del file Avro in altre offerte Google Cloud come BigQuery.

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

Passaggi successivi