Questo articolo spiega come eseguire la migrazione dell'elaborazione transazionale online (OLTP) da MySQL a Spanner.
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 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 maggiori informazioni consulta l'articolo Informazioni sul controllo dell'accesso granulare.
Vincoli di convalida dei dati
Spanner supporta un insieme limitato di vincoli di convalida dei dati nel livello del database. Se hai bisogno di vincoli relativi ai dati più complessi, a livello di applicazione.
La tabella seguente illustra i tipi di vincoli comunemente presenti in MySQL e come implementarli con Spanner.
Vincolo | Implementazione con Spanner |
---|---|
Non null | Vincolo di colonna NOT NULL |
Univoco | Indice secondario con vincolo UNIQUE |
Foreign key (per tabelle normali) |
Vedi Creare e gestire relazioni di chiave esterna. |
Azioni chiave esterna ON DELETE/ON UPDATE |
Possibile solo per le tabelle con interleaving. o implementati in un'istanza livello di applicazione |
Controllo dei valori e convalida tramite vincoli CHECK |
Consulta la sezione Creazione e gestione dei vincoli di controllo. |
Controllo dei valori e convalida tramite trigger | Implementata nel livello dell'applicazione |
Colonne generate
Spanner supporta le colonne generate in cui il valore della colonna verrà sempre generato da una funzione fornita come parte della definizione della tabella. Come in MySQL, le colonne generate non possono essere impostate espressamente su un valore fornito in un'istruzione DML.
Le colonne generate sono definite come parte della definizione della colonna
nel corso di una definizione dei dati CREATE TABLE
o ALTER TABLE
dell'istruzione DDL. La parola chiave AS
è seguita da un numero
Funzione SQL e la parola chiave suffisso richiesta STORED
. La
La parola chiave STORED
fa parte della specifica ANSI SQL,
e indica che i risultati della funzione verranno archiviati insieme ad altre colonne
della tabella.
La funzione SQL, l'espressione di generazione, può includere qualsiasi espressione, funzione e operatore e può essere utilizzata in indici secondari o come chiave esterna.
Scopri di più su come gestire questo tipo di colonna, consulta Creazione e gestione delle colonne generate.
Tipi di dati supportati
MySQL e Spanner supportano diversi set di tipi di dati. La la seguente tabella elenca i tipi di dati MySQL e il loro equivalente Spanner. Per definizioni dettagliate di ogni Spanner tipo di dati, consulta Tipi di dati.
Potresti dover trasformare ulteriormente i dati come descritto nella colonna Note
per adattare i dati MySQL
al database Spanner. Ad esempio,
può archiviare un BLOB
di grandi dimensioni come oggetto in un bucket Cloud Storage anziché
nel database e quindi archivia il riferimento URI al Cloud Storage
nel database come STRING
.
Tipo di dati MySQL | Equivalente Spanner | Note |
---|---|---|
INTEGER , INT , MEDIUMINT BIGINT e SMALLINT |
INT64 |
|
TINYINT , BOOL , BOOLEAN |
BOOL , INT64 |
I valori TINYINT(1) vengono utilizzati per rappresentare i valori booleani di
'true' (diverso da zero) o "false" (0). |
FLOAT , DOUBLE |
FLOAT64 |
|
DECIMAL , NUMERIC |
NUMERIC , STRING
|
In MySQL,i tipi di dati NUMERIC e DECIMAL supportano
fino a un totale di 65 cifre di precisione e scala, come definito nella colonna
dichiarazione.
Il tipo di dati NUMERIC di Spanner
supporta fino a 38 cifre di precisione e 9 cifre decimali della scala.Se hai bisogno di una maggiore precisione, consulta Archiviazione di dati numerici di precisione arbitraria per meccanismi alternativi. |
BIT |
BYTES |
|
DATE |
DATE |
Sia Spanner che MySQL utilizzano "yyyy-mm-dd "
per le date, quindi non è necessaria alcuna trasformazione. Le funzioni SQL sono fornite
per convertire le date in una stringa formattata. |
DATETIME , TIMESTAMP |
TIMESTAMP |
Spanner archivia l'ora indipendentemente dal fuso orario. Per
per archiviare un fuso orario, devi utilizzare una colonna STRING separata.
Le funzioni SQL vengono fornite per convertire i timestamp in una stringa formattata utilizzando
fusi orari. |
CHAR , VARCHAR |
STRING |
Nota: Spanner utilizza stringhe Unicode ovunque. VARCHAR supporta una lunghezza massima di 65.535 byte, mentre Spanner supporta fino a 2.621.440 caratteri. |
BINARY , VARBINARY , BLOB , TINYBLOB |
BYTES |
Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati
BYTES . Valuta la possibilità di utilizzare offerte Google Cloud alternative come
come Cloud Storage, per archiviare oggetti più grandi |
TEXT , TINYTEXT , ENUM |
STRING
|
Valori di TEXT piccoli (meno di 10 MiB) possono essere memorizzati come
STRING . Valutare l'utilizzo di offerte Google Cloud alternative
come Cloud Storage per supportare TEXT di dimensioni
e i relativi valori. |
ENUM |
STRING |
La convalida dei valori ENUM deve essere eseguita nell'applicazione |
SET |
ARRAY<STRING> |
La convalida dei valori dell'elemento SET deve essere eseguita nell'applicazione |
LONGBLOB , MEDIUMBLOB |
BYTES o STRING contenente l'URI dell'oggetto.
|
Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati come BYTES .
Valuta l'utilizzo di offerte Google Cloud alternative come
per archiviare oggetti più grandi. |
LONGTEXT , MEDIUMTEXT |
STRING (contenente dati o URI dell'oggetto esterno)
|
Gli oggetti 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 |
JSON |
JSON
|
Le stringhe JSON di piccole dimensioni (meno di 2.621.440 caratteri) possono essere memorizzate come
JSON . Valutare l'utilizzo di offerte Google Cloud alternative
ad esempio Cloud Storage,
per archiviare oggetti più grandi. |
GEOMETRY , POINT , LINESTRING , POLYGON , MULTIPOINT , MULTIPOLYGON e GEOMETRYCOLLECTION |
Spanner non supporta i tipi di dati geospaziali. Devi memorizzare questi dati utilizzando tipi di dati standard e implementare eventuali funzionalità di ricerca/filtro a livello di applicazione. |
Processo di migrazione
Una tempistica generale del processo di migrazione sarebbe:
- Converti lo schema e il modello dei dati.
- Traduci le query SQL.
- Esegui la migrazione dell'applicazione per utilizzare Spanner, oltre a e MySQL.
- Esporta in blocco i dati da MySQL e importa i tuoi dati in Spanner usando Dataflow.
- Mantieni la coerenza tra entrambi i database durante la migrazione.
- Esegui la migrazione dell'applicazione da MySQL.
Passaggio 1: converti il database e lo schema
Converti lo schema esistente in Spanner schema per archiviare i dati. Per semplificare le modifiche alle applicazioni, che lo schema convertito corrisponda allo schema MySQL esistente il più possibile possibile. Tuttavia, a causa delle differenze nelle funzionalità, alcune modifiche potrebbero essere necessaria.
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 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, vedi Le strategie di migrazione della chiave principale che consigliamo.
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.
Interfoliare le 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 definisci le azioni all'eliminazione 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 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, pertanto i valori delle colonne da utilizzare come chiavi 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
STORING
, 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=@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 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.
Passaggio 2: traduci le query SQL
Spanner utilizza Dialetto ANSI 2011 di SQL con estensioni, e ha molti funzioni e operatori per tradurre e aggregare i dati. Qualsiasi query SQL che utilizza specifiche dialetto, funzioni e tipi dovranno essere convertiti per essere compatibili con Spanner.
Anche se Spanner non supporta i dati strutturati come colonna
definizioni, puoi usare i dati strutturati nelle query SQL utilizzando ARRAY<>
e
Tipi di STRUCT<>
. Ad esempio, potresti scrivere una query che restituisca tutti gli album
per un artista che utilizza ARRAY
di STRUCT
(sfruttando i vantaggi dei
dati). Per ulteriori informazioni, consulta
Sottoquery
della documentazione.
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: esegui la migrazione dell'applicazione per utilizzare Spanner
Spanner fornisce un insieme Librerie client per varie lingue e la possibilità di leggere e scrivere dati utilizzando per le chiamate API specifiche di Spanner, oltre all'uso Query SQL e DML (Data Modification Language) istruzioni. L'utilizzo delle chiamate API potrebbe essere più veloce per alcune query, ad esempio la riga diretta legge per chiave, perché l'istruzione SQL non deve essere tradotta.
Spanner fornisce Driver JDBC per applicazioni Java.
Nell'ambito del processo di migrazione, le funzionalità non sono disponibili Come indicato sopra, Spanner deve essere implementato un'applicazione. Ad esempio, un trigger per verificare i valori dei dati e aggiornare un attivatore 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, legge le transazioni possono avere Limiti di timestamp applicata, in cui leggi una versione coerente dei dati:
- a un'ora esatta nel passato (fino a un'ora fa).
- in futuro (in cui la lettura si bloccherà fino all'arrivo di quel momento).
- con una quantità accettabile di inattività limitata, che restituirà un costante fino a un certo periodo di tempo senza dover controllare in un secondo momento siano disponibili su un'altra replica. Questo può migliorare le prestazioni a scapito di dati potenzialmente inattivi.
Passaggio 4: trasferisci i dati da MySQL a Spanner
Per trasferire i tuoi dati da MySQL a Spanner, devi esporta il database MySQL in un formato file portatile, ad esempio un file XML, quindi importa i dati in Spanner utilizzando e Dataflow.
Esportazione collettiva da MySQL
Lo strumento mysqldump
incluso in MySQL è in grado di esportare l'intero database
in
file XML corretti.
In alternativa, puoi utilizzare
SELECT ... INTO OUTFILE
Istruzione SQL per creare file CSV per ogni tabella. Tuttavia, questo
presenta lo svantaggio che è possibile esportare una sola tabella alla volta,
il che significa che devi mettere in pausa l'applicazione o disattivare il database
in modo che il database rimanga in uno stato coerente per l'esportazione.
Dopo aver esportato questi file di dati, ti consigliamo di caricarli in una Cloud Storage in modo che siano accessibili per l'importazione.
Importazione collettiva in Spanner
Poiché è probabile che gli schemi del database siano diversi tra MySQL e Spanner, potresti dover includere alcune conversioni dei dati nel processo di importazione. La il modo più semplice per eseguire queste conversioni e importarli Spanner utilizza Dataflow. Dataflow è la piattaforma Google Cloud di estrazione, trasformazione, e il servizio di caricamento (ETL). Fornisce una piattaforma per eseguire pipeline di dati scritte utilizzando il SDK Apache Beam leggere ed elaborare grandi quantità di dati in parallelo su machine learning.
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 devi scrivere sono i dati e si trasformeranno automaticamente.
Esempio di una pipeline semplice che legge dai file CSV e scrive Spanner, consulta repository di codice di esempio.
Se usi tabelle con interleaving padre-figlio in Spanner di importazione, tieni presente che durante il processo di importazione la riga padre venga creata prima la riga secondaria. La Codice pipeline di importazione di Spanner gestisce questo aspetto importando prima tutti i dati per le tabelle a livello principale, poi tutti le tabelle figlio di livello 1, tutte le tabelle figlio di livello 2 e così via.
Puoi utilizzare la pipeline di importazione di Spanner direttamente eseguire l'importazione collettiva dei dati, ma questo approccio richiede che i dati siano presenti nei file Avro utilizzando il formato .
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. Di conseguenza, mentre trasferisci i dati in Spanner, continua a modificare il database esistente. Quindi è necessario per duplicare gli aggiornamenti al database Spanner mentre dell'applicazione è in esecuzione.
Esistono vari metodi per mantenere sincronizzati i due database, tra cui: Change Data Capture (CDC) e implementazione di aggiornamenti simultanei nell'applicazione.
Change Data Capture (CDC)
MySQL non dispone di un database Change Data Capture (CDC) (CDC). Tuttavia, esistono vari progetti open source che possono MySQL binlog e li converti in un flusso CDC. Ad esempio: Daemon di Maxwell può fornire un flusso CDC per il tuo database.
Puoi scrivere un'applicazione che si abbona a questo flusso e applica le stesse (dopo la conversione dei dati, ovviamente) in Spanner per configurare un database.
Aggiornamenti simultanei a entrambi i database dall'applicazione
Un metodo alternativo è modificare l'applicazione per eseguire scritture su entrambi o Microsoft SQL Server. Un database (inizialmente MySQL) 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.
Quando hai la certezza che tutti i tuoi dati siano stati trasferiti correttamente, può trasferire la fonte attendibile al database Spanner. Questo meccanismo di rollback fornisce un percorso di rollback se vengono rilevati problemi quando si passa Spanner.
Verifica la coerenza dei dati
Man mano che i flussi di dati vengono inseriti nel database Spanner, puoi eseguire periodicamente Eseguire un confronto tra i dati Spanner e MySQL per assicurarci che i dati siano coerenti. Per convalidare la coerenza eseguire query su entrambe le origini dati e confrontare i risultati.
Puoi usare Dataflow per eseguire un confronto dettagliato tra di dati utilizzando Unisci alla trasformazione. Questa trasformazione prende 2 set di dati con chiave e associa i valori in base alla chiave. La i valori corrispondenti possono quindi essere confrontati per trovare l'uguaglianza. Puoi eseguire regolarmente questo 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 di eseguire la migrazione dei dati, puoi cambiare l'applicazione all'utilizzo di Spanner come fonte attendibile. Se continui a scrivere le modifiche al database MySQL, questo mantiene il database MySQL aggiornato e fornisce un percorso di rollback in caso di problemi.
Infine, puoi disabilitare e rimuovere il codice di aggiornamento del database MySQL e arrestare il database MySQL, ora obsoleto.
Esporta e importa i database Spanner
Facoltativamente, puoi esportare le tabelle da Spanner in un nel bucket Cloud Storage utilizzando un modello Dataflow eseguire l'esportazione. La cartella risultante contiene un set di file Avro e JSON file manifest contenenti le tabelle esportate. Questi file possono essere utilizzati tra cui:
- Backup del database per conformità o emergenza al criterio di conservazione dei dati e il ripristino di emergenza.
- Importare il file Avro in altre offerte Google Cloud come in BigQuery.
Per ulteriori informazioni sul processo di esportazione e importazione, vedi Esportazione dei database e Importazione dei database.
Passaggi successivi
- Leggi come ottimizzare lo schema Spanner.
- Scopri come utilizzare Dataflow per situazioni più complesse.