Credito: Octopus Deploy
Questa settimana, l'organizzazione di sviluppo di Facebook ha annunciato il completamento del tipo di attività che le aziende temono: un importante aggiornamento al suo database principale. Larry Dignan ha delineato i punti salienti nella sua panoramica di ieri. E in quella panoramica, ha più che accennato alle prove e alle tribolazioni incontrate dalla migrazione.
Le migrazioni di database avvengono continuamente e non mancano i consigli su come condurle. Ma il post dettagliato del blog di Facebook ha fornito lezioni preziose, che approfondiremo qui. È stato un progetto enorme e pluriennale, soprattutto perché Facebook ha una vasta gamma di istanze MySQL.
Prima di tutto, di cosa si trattava? Non c'è dubbio che MySQL rappresenti un importante aggiornamento generazionale per questa piattaforma. L'aggiornamento è stato così significativo che Oracle, che possiede MySQL, è stato invitato a intraprendere un importante aggiornamento e aggiornamento del proprio servizio cloud MySQL.
C'è una lunga lista di modifiche nella versione 8.0, ma ne evidenzieremo alcune qui. Inizia con la gestibilità: MySQL 8.0 aggiunge il dizionario dei dati transazionali che è altrimenti standard per i database di livello aziendale. C'è una maggiore semplicità: tutte le attività coinvolte con il linguaggio di definizione dei dati (DDL) invocato per i comandi di routine sono ora combinate in un'unica istruzione. Pertanto, non è necessario scrivere istruzioni separate per gli aggiornamenti del dizionario dati, le operazioni del motore di archiviazione e le scritture di log binari. La crittografia delle tabelle è stata semplificata ed è stato migliorato il supporto per i tipi di dati estesi come BLOB, TEXT, GEOMETRY e JSON.
C'è la nuova fantastica funzionalità degli “indici invisibili” che consente di eseguire test sugli impatti della rimozione degli indici senza doverli rimuovere fisicamente. È analogo alle funzionalità di indicizzazione avanzate in Oracle Autonomous Database e Microsoft Azure SQL Database che consentono di testare schemi di indicizzazione alternativi per valutare se alcuni indici stanno sprecando spazio o se quelli nuovi o modificati potrebbero recuperare i dati con un minor sovraccarico di calcolo.
Ma come confermerà qualsiasi DBA esperto, c'è sempre un prezzo da pagare durante l'aggiornamento, come la destabilizzazione delle applicazioni, motivo per cui la maggior parte delle organizzazioni rimanda la migrazione fino a quando la necessità è troppo grande. Non a caso, la maggior parte dei provider di Database-as-a-Service (DBaaS) cloud mantiene la promessa di eliminare il dolore degli aggiornamenti perché eliminano quei grattacapi dalle spalle dei clienti.
Quindi, non sorprende che in cima alla lista delle lezioni apprese ci siano problemi di compatibilità. Iniziamo con le personalizzazioni, tipiche delle installazioni di dati aziendali radicate. Non sorprende che questo sia stato a lungo un problema anche nel mondo delle applicazioni aziendali, in cui gli strumenti di migrazione automatizzata in genere si fermano quando si tratta di personalizzazioni. In effetti, SAP ora incoraggia i clienti a mantenere invece le implementazioni principali alla base e ad astrarre le implementazioni tramite API che dovrebbero rimanere stabili. Facebook non ha avuto questo lusso con la migrazione di MySQL. Come ha notato Larry nel suo account, solo 1500 delle 2300 patch personalizzate sono state trasferite, mentre il resto è stato deprecato.
Un problema correlato è la compatibilità delle API, ed è qui che Facebook ha scoperto un “trucco” nascosto. Come notato, i clienti in genere rimandano le migrazioni di sistemi aziendali di grandi dimensioni a causa del tempo e dell'interruzione coinvolti e, in questo caso, ciò significava che Facebook ha saltato un ciclo. Invece di passare da MySQL 5.6 a 5.7, hanno saltato la versione provvisoria e sono passati direttamente a 8.0. Il risultato è stata la necessità di svolgere un lavoro investigativo sulle API supportate; come hanno appreso a proprie spese, nella versione 5.6 sono state modificate un certo numero di API che non erano incluse nella documentazione 8.0. Ciò ha aggiunto una penalità di tempo.
La migrazione in alcuni casi ha coinvolto anche il motore di archiviazione sottostante. MySQL è un database che supporta motori di archiviazione collegabili e dal 2016 Facebook ha spostato le sue implementazioni MySQL rivolte all'utente da InnoDB, il motore più comune utilizzato in MySQL, a MyRocks, un motore di archiviazione open source sviluppato da Facebook. Il vantaggio di MyRocks è la compressione e la scrittura più efficienti.
Il passaggio da InnoDB a MyRocks richiedeva un framework di test “ombra” che catturasse il traffico di produzione e lo riproducesse nelle istanze di test. Ma questo processo non era infallibile; ha mancato problemi come il modo in cui MyRocks avrebbe gestito i deadlock di scrittura delle transazioni. La morale della storia è che mentre puoi simulare alcuni scenari, in alcuni casi, i bug non verranno visualizzati fino a dopo il fatto e dovresti inserire correzioni a posteriori in qualsiasi piano di migrazione e test.
A causa di tutti i problemi di compatibilità previsti e imprevisti, Facebook ha giocato con molta cautela quando si trattava di spostare i dati. Invece del consueto processo di replica di tabelle o istruzioni SQL, Facebook è andato riga per riga, un processo molto scrupoloso. La necessità di un'azione così drastica era dettata dall'ampio portafoglio di app e dalla probabilità di incontrare interdipendenze: alcuni dati che potrebbero essere utilizzati dall'Applicazione A potrebbero essere stati derivati dall'elaborazione da parte dell'Applicazione B.
La lezione non sorprendente è che la migrazione dei database aziendali è raramente banale.
È uno dei motivi per cui Facebook ha intrapreso un percorso comune per le grandi aziende per rimandare fino a quando non è assolutamente necessario, e poiché ciò significava saltare un aggiornamento della versione intermedia, ha pagato un prezzo. Ha spinto Larry a porre la domanda nel suo pezzo se ne valesse la pena.
La domanda è se questi grattacapi potrebbero essere evitati o ridotti al minimo in futuro, quando, ad esempio, esiste un MySQL 9.0. Una risposta, se non sei Facebook, è passare al database Database-as-a-Service DBaaS nel cloud, dove i fornitori di cloud mantengono continuamente la versione aggiornata e presumibilmente isolano i clienti dai cambiamenti della piattaforma sottostante.
Ma se lo stai ancora provando a casa, Larry ha accennato alla risposta: inizia a pianificare ora per quell'eventualità. Più specificamente, fai gli aggiornamenti del rilascio del punto, ma forse a lungo termine, inizia ad astrarre le personalizzazioni usando le API, se possibile. Forse in futuro, l'apprendimento automatico potrebbe fornire un aiuto per prevedere dove potrebbero sorgere problemi di compatibilità, ma questo è certamente un caso in cui l'intuizione umana deve mantenere il controllo.
Big Data
Dov'è il launchpad del cloud ibrido di IBM? Sette modi per rendere reale la tecnologia in tempo reale per la tua organizzazione Machine learning all'avanguardia: TinyML sta diventando grande Quali sono le prospettive di Cloudera? McDonald's vuole “democratizzare” l'apprendimento automatico per tutti gli utenti nelle sue operazioniArgomenti correlati:
Gestione dei dati Trasformazione digitale Robotica Internet delle cose Innovazione Software aziendale 