L'incubo definitivo per i database legacy MySQL

Question

Tabella 1:Tutto compreso il lavello della cucina.Date nel formato sbagliato (anno scorso quindi non è possibile ordinare in quella colonna), Numeri memorizzati come VARCHAR, indirizzi completi nella colonna "via", nome e cognome nella colonna nome, città nella colonna cognome, indirizzi incompleti, righe che aggiornare le righe precedenti spostando i dati da un campo all'altro in base a una serie di regole che sono cambiate nel corso degli anni, record duplicati, record incompleti, record spazzatura...lo chiami tu...oh e ovviamente non c'è una colonna TIMESTAMP o PRIMARY KEY in vista.

Tavolo 2:Ogni speranza di normalizzazione è andata in fumo dopo aver aperto questo bambino.Abbiamo una riga per ogni voce E aggiornamento delle righe nella tabella uno.Quindi duplicati come se non ci fosse un domani (valore 800 MB) e colonne come Phone1 Phone2 Phone3 Phone4 ...Phone15 (non si chiamano phone.Lo uso per l'illustrazione) La chiave straniera è...beh, indovina.Ci sono tre candidati a seconda del tipo di dati presenti nella riga della tabella 1

Tabella3:Può andare peggio?Oh si.La "chiave esterna è una combinazione di colonne VARCHAR di trattini, punti, numeri e lettere!se ciò non fornisce la corrispondenza (cosa che spesso non avviene), dovrebbe essere necessaria una seconda colonna di codice prodotto simile.Colonne che hanno nomi che NON hanno alcuna correlazione con i dati al loro interno e l'obbligatorio Telefono1 Telefono2 Telefono3 Telefono4...Telefono15.Sono presenti colonne duplicate dalla Tabella 1 e non una colonna TIMESTAMP o PRIMARY KEY in vista.

Tabella 4:è stato descritto come un lavoro in progress e soggetto a modifiche in qualsiasi momento.E' sostanzialmente simile agli altri.

A quasi 1 milione di file questo è un GRANDE pasticcio.Fortunatamente non è il mio grande pasticcio.Purtroppo devo tirarne fuori un composito per ogni "cliente".

Inizialmente ho ideato una traduzione in quattro passaggi della Tabella1 aggiungendo una CHIAVE PRIMARIA e convertendo tutte le date in un formato ordinabile.Quindi un altro paio di passaggi di query che hanno restituito dati filtrati fino a quando non ho avuto Table1 dove potevo usarla per estrarre dalle altre tabelle per formare il composito.Dopo settimane di lavoro sono riuscito a ridurre il problema a un solo passaggio utilizzando alcuni trucchi.Quindi ora posso puntare la mia app verso il caos ed estrarre una bella tabella pulita di dati compositi.Fortunatamente mi serve solo uno dei numeri di telefono per i miei scopi, quindi normalizzare la mia tabella non è un problema.

Tuttavia è qui che inizia il vero compito, perché ogni giorno centinaia di dipendenti aggiungono/aggiornano/eliminano questo database in modi che non vorresti immaginare e ogni notte devo recuperare le nuove righe.

Poiché le righe esistenti in qualsiasi tabella possono essere modificate e poiché non sono presenti colonne TIMESTAMP ON UPDATE, dovrò ricorrere ai log per sapere cosa è successo.Ovviamente questo presuppone che esista un log binario, cosa che non esiste!

L'introduzione del concetto è andata giù come un pallone di piombo.Avrei anche potuto dire loro che i loro figli dovranno essere sottoposti a un intervento chirurgico sperimentale.Non sono esattamente hi-tech...nel caso non ti fossi accorto...

La situazione è un po' delicata perché hanno alcune informazioni preziose che la mia azienda desidera disperatamente.Sono stato mandato dal senior management di una grande azienda (sapete come sono fatti) per "realizzarlo".

Non riesco a pensare a nessun altro modo per gestire gli aggiornamenti notturni, se non analizzare il file di registro del contenitore con un'altra applicazione ancora, per capire cosa hanno fatto a quel database durante il giorno e quindi comporre la mia tabella di conseguenza.In realtà mi basta solo guardare il loro tavolo1 per capire cosa fare con il mio tavolo.Le altre tabelle forniscono solo campi per svuotare il record.(L'uso di MASTER SLAVE non aiuterà perché avrò un duplicato del pasticcio.)

L'alternativa è creare un hash univoco per ogni riga della tabella1 e creare una tabella hash.Quindi esaminerei TUTTO il database ogni notte controllando se gli hash corrispondono.In caso contrario, leggerei quel record e controllerei se esiste nel mio database, in caso affermativo lo aggiornerei nel mio database, in caso contrario è un nuovo record e lo INSERIREI.Questo è brutto e non veloce, ma neanche l'analisi di un file di registro binario è carina.

Ho scritto questo per aiutare a chiarire il problema.spesso raccontarlo a qualcun altro aiuta a chiarire il problema rendendo più ovvia una soluzione.In questo caso ho solo un mal di testa più grande!

I tuoi pensieri sarebbero molto apprezzati.

Answer 1

Anche i file di registro (log binari) sono stati il ​​mio primo pensiero.Se sapessi come fanno le cose rabbrividiresti.Per ogni riga ci sono molte voci nel registro man mano che i pezzi vengono aggiunti e modificati.È semplicemente ENORME!Per ora ho optato per l'approccio Hash.Con un po' di paginazione intelligente della memoria dei file, questo è abbastanza veloce.

Answer 2

Non sono una persona MySQL, quindi questo esce dal campo sinistro.

Ma penso che i file di registro potrebbero essere la risposta.

Per fortuna, hai davvero bisogno di sapere solo 2 cose dal registro.

Hai bisogno del record/riga e dell'operazione.

Nella maggior parte dei DB, e presumo MySQL, c'è una colonna implicita su ogni riga, come un rowid o un recordid o qualsiasi altra cosa.È il numero di riga interno utilizzato dal database.Questa è la tua chiave primaria "gratuita".

Successivamente, è necessaria l'operazione.In particolare se si tratta di un'operazione di inserimento, aggiornamento o eliminazione sulla riga.

Consolidi tutte queste informazioni, in ordine temporale, e poi le esamini.

Per ogni inserimento/aggiornamento, selezioni la riga dal DB originale e inserisci/aggiorna quella riga nel DB di destinazione.Se si tratta di un'eliminazione, elimini la riga.

Non ti interessano i valori dei campi, semplicemente non sono importanti.Fai l'intera riga.

Si spera che non sia necessario "analizzare" i file di log binari, MySQL deve già avere delle routine per farlo, devi solo trovare e capire come usarli (potrebbe anche esserci qualche pratica utilità di "dump log" che potresti usare ).

Ciò ti consente di mantenere il sistema piuttosto semplice e dovrebbe dipendere solo dalla tua attività effettiva durante il giorno, piuttosto che dalla dimensione totale del DB.Infine, potresti successivamente ottimizzarlo rendendolo "più intelligente".Ad esempio, potrebbero inserire una riga, quindi aggiornarla e quindi eliminarla.Sapresti che puoi semplicemente ignorare completamente quella riga nel tuo replay.

Ovviamente questo richiede un po' di conoscenza arcana per leggere effettivamente i file di registro, ma il resto dovrebbe essere semplice.Mi piacerebbe pensare che anche i file di registro abbiano un timestamp, quindi puoi sapere come lavorare sulle righe "da oggi" o qualunque intervallo di date desideri.

Answer 3

Non puoi utilizzare il codice esistente che accede a questo database e adattarlo alle tue esigenze?Naturalmente, il codice deve essere orribile, ma it Potrebbe gestire la struttura del database per te, no?Si spera che allora potresti concentrarti sul portare a termine il tuo lavoro invece di giocare a fare l'archeologo.

Answer 4

potresti essere in grado di utilizzare lo strumento mk-table-sync di maatkit per sincronizzare un database di staging (dopotutto il tuo database è solo molto piccolo).Questo "duplicherà il pasticcio"

Potresti quindi scrivere qualcosa che, dopo la sincronizzazione, esegua varie query per generare una serie di tabelle più sensate che puoi quindi segnalare.

Immagino che ciò possa essere fatto quotidianamente senza problemi di prestazioni.

Fare tutto da un server diverso eviterà di influenzare il database originale.

L'unico problema che posso vedere è se alcune tabelle non hanno chiavi primarie.