Indice dei contenuti dell'articolo:
Quando si tratta di scegliere un database per far funzionare la propria applicazione, MySQL rimane una delle scelte più popolari. Come database open source più popolare nell’indice DB-Engines per più di un decennio, MySQL fornisce una piattaforma affidabile. Tuttavia, lo scorso 31 ottobre 2023, la versione 5.7 ha raggiunto lo stato di End of Life (EOL).
L’End of Life (EoL) di un DBMS MySQL si riferisce al termine del supporto ufficiale fornito dal produttore per una specifica versione del database. Questo significa che non verranno più rilasciati aggiornamenti di sicurezza, patch di bug o miglioramenti, rendendo il sistema più vulnerabile a rischi di sicurezza e meno compatibile con le nuove tecnologie. Per le aziende, l’EoL comporta la necessità di aggiornare a versioni più recenti di MySQL per garantire la sicurezza, l’efficienza e la compatibilità del loro database. La mancata migrazione può esporre i dati aziendali a rischi di sicurezza, perdita di dati, e problemi di performance. Inoltre, le nuove funzionalità e ottimizzazioni presenti nelle versioni aggiornate di MySQL possono essere cruciali per migliorare le performance complessive e l’efficienza dei sistemi che utilizzano il database.
Secondo i dati telemetrici dello strumento di gestione di database open source PMM, più della metà degli utenti di MySQL attualmente utilizza la versione 5.7. Questo significa che ci sono molte istanze che dovranno essere aggiornate o rischiare potenziali problemi.
Tuttavia, molti sviluppatori non sono propensi a modificare le loro installazioni di database una volta che funzionano bene. Mentre altri elementi dello stack applicativo ricevono aggiornamenti e modifiche regolari, i database richiedono competenze specifiche e una comprensione approfondita per sfruttarli al meglio in aree come query, indici e performance. Un aggiornamento completo come questo può ispirare sentimenti di trepidazione, ma pianificare i prossimi passi è essenziale prima della data di EOL.
Cosa comporta questo aggiornamento?
Prima di tutto, è importante guardare a cosa offre la migrazione per migliorare l’esecuzione della tua applicazione e aumentare la tua produttività. Per iniziare, MySQL 8.0 supporta una serie di aggiornamenti a SQL (Structured Query Language) che rendono più facile scrivere e supportare query. Le query efficienti sono al centro di come utilizzi i dati nella tua applicazione e nella tua attività, quindi qualsiasi cosa che possa migliorare questo aspetto dovrebbe avere un impatto diretto sul tuo lavoro.
Un buon esempio di ciò sono le subquery. Crearle può essere difficile se non si lavora quotidianamente con SQL, quindi sfruttare opzioni come join derivati laterali e Common Table Expressions (CTE) può aiutare. Le CTE aiutano a comporre e mantenere query complesse suddividendole in unità più piccole che puoi riutilizzare nel tempo. Mantenendo le cose semplici e leggibili, questo aiuta a costruire le query di cui hai bisogno nella tua applicazione. C’è anche una nuova clausola di intersezione per aiutare con i set, aiutandoti a trovare i punti dati comuni in due o più set di dati senza dover scrivere query molto complesse.
MySQL 8.0 include molti nuovi comandi che possono migliorare significativamente la tua produttività. Un esempio è EXPLAIN ANALYZE, che può aiutarti nel tuning delle query. EXPLAIN fornisce una stima di come dovrebbe comportarsi la tua query, basata sull’analisi del server. Tuttavia, si tratta solo di una stima e potrebbe essere errata. Utilizzare ANALYZE insieme a EXPLAIN fa eseguire la query, così puoi ottenere una visione più precisa di come quella query si comporta nella realtà. Questo rende molto più facile trovare miglioramenti potenziali in quella query, piuttosto che indovinare. Inoltre, INDEX INVISIBILE ti aiuta a testare l’efficienza di un indice senza rischiare una ricostruzione che può portare a seri problemi.
Oltre a questi cambiamenti di sintassi e comandi, MySQL 8.0 può ora supportare più caratteri internazionali poiché il set di caratteri predefinito è stato aggiornato a UTF8MB4, che fornisce supporto alla versione 9.0 di Unicode. Questo è particolarmente utile per le aziende con operazioni in tutto il mondo.
Abbandono della Query Cache di MySQL
La Query Cache di MySQL è stata un tempo un elemento chiave per massimizzare le prestazioni dei database. Progettata in un’epoca in cui i sistemi informatici si basavano su architetture a singolo core e singolo server, questa funzionalità era ottimizzata per tali ambienti, dove era in grado di fornire risultati rapidi e efficienti. La Query Cache operava memorizzando i risultati di query frequenti, permettendo al database di recuperare questi dati velocemente, senza la necessità di ricalcolare ogni volta la stessa query.
Tuttavia, l’evoluzione tecnologica ha portato cambiamenti significativi nell’architettura dei sistemi informatici. Con l’emergere e la popolarità di processori multicore e architetture multithread, il panorama tecnologico ha subito una trasformazione radicale. Questi cambiamenti hanno introdotto nuove sfide nella gestione della Query Cache di MySQL. La necessità di sincronizzare la cache su più core e di gestire l’accesso concorrente da diversi thread ha complicato notevolmente la sua implementazione. Questa crescente complessità ha portato a un incremento di problemi di sincronizzazione e gestione della cache, con il risultato di rallentare le operazioni del database piuttosto che velocizzarle.
Di fronte a questi ostacoli, gli sviluppatori di MySQL hanno preso la decisione di deprecare la Query Cache nella versione 5.7 e, successivamente, di eliminarla completamente nella versione 8. Questa scelta è stata influenzata anche dal raggiungimento della End Of Life di MySQL 5.7 nell’ottobre del 2023, il che significava che le versioni successive di MySQL non avrebbero più incluso questa caratteristica. Sebbene la Query Cache sia stata rimossa, il suo concetto rimane prezioso, soprattutto in scenari dove le richieste di lettura dominano sulle operazioni di scrittura. In tali contesti, la capacità di memorizzare e recuperare rapidamente i risultati delle query può ancora offrire significativi vantaggi in termini di efficienza e prestazioni.
L’eliminazione della Query Cache in MySQL 8 rappresenta un cambiamento sostanziale, con potenziali implicazioni critiche, specialmente per siti web con un alto volume di letture, come i blog WordPress o piattaforme simili. Questi siti spesso si affidano alla rapidità delle operazioni di lettura per fornire un’esperienza utente fluida e reattiva. La Query Cache, in questi contesti, svolgeva un ruolo vitale nel ridurre i tempi di risposta del database, memorizzando i risultati delle query più frequenti e riducendo così il carico sul database stesso.
La rimozione di questa funzionalità in MySQL 8 può quindi portare a significativi problemi di performance per tali siti. Senza la Query Cache, ogni richiesta richiederà il processamento completo della query sul database, potenzialmente aumentando i tempi di risposta e il carico sul server. Questo scenario pone una sfida importante per gli amministratori di sistemi e gli sviluppatori di siti web, che devono valutare attentamente i benefici e i rischi associati all’aggiornamento a MySQL 8.
In alcuni casi, potrebbe essere consigliabile rimanere con MySQL 5.7 per mantenere i vantaggi della Query Cache, nonostante il raggiungimento della End Of Life di questa versione. Tuttavia, questa scelta può comportare rischi di sicurezza e mancanza di supporto, rendendola una soluzione temporanea e non ideale a lungo termine.
Un’alternativa interessante è rappresentata dalla migrazione verso MariaDB. A differenza di MySQL e Percona Server, MariaDB ha scelto di mantenere la Query Cache, preservando quindi i suoi vantaggi (e i suoi svantaggi) nei contesti in cui questa funzionalità è particolarmente utile. Questa scelta fa di MariaDB un’opzione attraente per quei siti che dipendono fortemente dalle operazioni di lettura e che desiderano preservare le performance offerte dalla Query Cache.
Tuttavia, scegliere MariaDB per preservare i vantaggi della Query Cache comporta anche l’accettazione di un compromesso in termini di performance complessive del database management system (DBMS). È importante sottolineare che, stando alle valutazioni correnti, MySQL 8 presenta performance significativamente superiori rispetto a MariaDB, una differenza che non può essere trascurata nella scelta del DBMS.
Le stime indicano che le performance di MySQL 8 possono essere approssimativamente il doppio rispetto a quelle di MariaDB. Questa differenza è attribuibile a vari fattori, tra cui ottimizzazioni più avanzate in MySQL 8, miglioramenti nell’uso dell’hardware moderno, come i processori multicore, e l’implementazione di nuove funzionalità che aumentano l’efficienza generale del sistema.
Ad esempio, MySQL 8 ha introdotto miglioramenti nell’ottimizzazione delle query, nella gestione della memoria e nelle operazioni I/O, contribuendo così a un netto aumento delle prestazioni. Inoltre, MySQL 8 supporta funzionalità avanzate come l’atomic DDL (Data Definition Language), che migliora la gestione e la sicurezza delle operazioni di definizione dei dati.
Pianificare l’aggiornamento
Migrare da MySQL 5.7 a 8.0 è una mossa diretta, ma ci sono alcuni cambiamenti specifici e significativi che possono influenzare le tue applicazioni. Controllare la tua applicazione e il tuo database in anticipo segnalerà se questo processo sarà semplice o se dovrai effettuare alcune modifiche più complesse come parte del processo di migrazione.
L’utilità util.checkForServerUpgrade() di MySQL Shell può aiutare in questo. Esegue 21 diversi test per controllare potenziali problemi che potrebbero influenzare la tua migrazione. I controlli includono la ricerca di tabelle con nomi che entrano in conflitto con nuove parole chiave riservate e per qualsiasi variabile di sistema che sia stata rimossa o cambiata in nuovi valori predefiniti in MySQL 8.0. La lista completa delle variabili aggiunte, deprecate e rimosse è disponibile qui. Oltre a questi potenziali problemi, questa utilità cerca altri problemi come tabelle partizionate che utilizzano motori con partizionamento non nativo, riferimenti circolari nei percorsi dei file di dati dello spazio tabellare e qualsiasi utilizzo di funzioni che sono state rimosse in MySQL 8.0.
Una volta eseguita questa utilità e scoperto quanto lavoro è coinvolto nel passaggio, ora hai una scelta. Dovresti effettuare quella migrazione diretta dal 5.7 all’8.0, o dovresti esplorare altre opzioni? Se devi mettere un lavoro significativo per preparare la tua applicazione e il tuo database per l’aggiornamento, allora dovresti mettere quello sforzo nell’emigrare verso un’altra piattaforma o un database diverso invece? Allo stesso modo, potresti decidere di esaminare un diverso modo di gestire la tua infrastruttura in futuro – per esempio, potresti attualmente avere la tua applicazione ospitata on-premise, ma potresti spostare quei server nel cloud o in un servizio ospitato invece in modo da non doverti preoccupare di gestire l’infrastruttura in futuro?
Ognuna di queste opzioni avrà vantaggi e potenziali svantaggi, quindi è importante valutarle nel contesto. Ad esempio, i servizi basati su cloud possono rendere molto più facile far funzionare le cose, ma devi anche spendere di più per i costi di gestione di quei servizi. Inoltre, dovresti controllare il processo di inserimento e estrazione dei dati da qualsiasi servizio cloud che potresti utilizzare. Questo aiuta ad evitare grossi costi di uscita dei dati se mai dovessi cambiare il tuo approccio. Infine, dovresti anche esaminare se il servizio che potresti utilizzare è open source o meno. Mentre molti fornitori affermano di essere “compatibili” con opzioni di database open source come MySQL, potrebbero offrire add-on specifici per il loro servizio o versione.
