I set di caratteri Unicode sono in genere più lenti dei set di caratteri come latin1, principalmente a causa delle loro dimensioni. MySQL 8.0 ha apportato miglioramenti significativi a questa problematica e quindi anche MariaDB 10.4 dovrebbe essere in questo senso notevolmente più veloce della 10.3. Inoltre MariaDB 10.4 dovrebbe funzionare meglio per le sottoquery IN () in quanto è ora possibile trasferire le condizioni in sottoquery materializzate.
L'avvio e l'arresto di InnoDB può richiedere del tempo, a seconda della quantità di dati nei registri di ripetizione. MariaDB 10.4 ha migliorato l'avvio, l'arresto e l'eliminazione. Tali miglioramenti sono particolarmente importanti data la popolarità di strumenti di backup a caldo come mariabackup e xtrabackup. Questi strumenti, alla fine, passano attraverso il processo di avvio di InnoDB da un arresto improvviso, quindi ogni miglioramento dovrebbe ridurre il tempo necessario per ripristinare i backup.
In MariaDB 10.4 è stato inserita l'operazione DROP COLUMN istantanea, ed è anche possibile riordinare le colonne nella tabella senza la necessità di ricostruirla. Potremmo chiederci quali sono le operazioni più comuni che eseguiamo nell'ambiente di produzione? diremo aggiungere o rimuovere un indice. Un'altra operazione più comune sarebbero le operazioni sulle colonne com aggiungere una nuova colonna e rimuovere la colonna esistente. Finora l'approccio più comune era usare strumenti esterni per fare questo lavoro: pt-online-schema-change o, più recentemente, gh-ost. Entrambi hanno i loro limiti (gh-ost non funziona per Galera Cluster, per esempio) che potrebbe essere impossibile usarlo sul tuo sistema. Con la COLONNA DROP istantanea (la COLONNA istantanea ADD invece già disponibile), gran parte delle modifiche allo schema possono essere eseguite ad hoc, senza pianificazione, al contrario delle versioni precedenti. Esistono modifiche dello schema non bloccanti, come la creazione di un indice, ma tali operazioni rappresentano una seria sfida quando viene utilizzata la replica poiché inducono un ritardo nella replica. Pertanto, anche se l'operazione avrebbe potuto essere eseguita su un sistema in live, è consigliato usare soluzioni alternative, come pt-online-change-change, per mantenere un migliore controllo del processo. Questo non è l'unico miglioramento ma MariaDB 10.4 beneficerà di un'estensione più rapida delle colonne VARCHAR, inoltre le modifiche al set di caratteri e alle regole di confronto su colonne non indicizzate saranno istantanee.
Uno dei maggiori cambiamenti sono i cambiamenti nella gestione degli utenti. La tabella Mysql.host non verrà creata e la tabella mysql.user è obsoleta. Gli account utente e i privilegi globali verranno mantenuti nella tabella mysql.global_priv. Questo è potenzialmente un grave cambiamento per tutti gli strumenti (incluso ClusterControl), che hanno un'opzione per gestire gli utenti MySQL e MariaDB: le nuove funzione dovranno essere allineate per coprire la gestione degli utenti in MariaDB 10.4 e versioni successive. Quindi riconosciamo benissimo, vista la necessità di modifiche ad alcunu siftware di gestione, sicuramente non aiuta a mantenere strumenti sia per MariaDB che per MySQL rendendo il panorama degli strumenti ancora più diviso di quanto non sia già. Parlando di utenti, inoltre, MariaDB 10.4 viene fornito con un'opzione per la scadenza della password utente. Questo è sicuramente aiuta a far rispettare le buone pratiche relative alla gestione delle password.
Infine, in MariaDB 10.4 è possibile impostare sql_mode = MSSQL. Ciò dimostra l'attenzione di MariaDB sui clienti aziendali: se i clienti Oracle decidono di migrare, è molto probabile che anche l'adozione di MariaDB tra Microsoft SQL Server aumenterà man mano che verranno aggiunte più funzionalità e la migrazione diventerà sempre meno un problema.
L'essenza è che MariaDB non unirà più le funzionalità InnoDB di MySQL, ma l'attenzione sarà rivolta alla stabilità e al miglioramento delle prestazioni di MariaDB. Ciò significa sostanzialmente che MariaDB diventerà incompatibile con MySQL.
Per quanto riguarda le prestazioni, dobbiamo attendere i benchmark ma, dati i dati storici, possiamo supporre che MariaDB sia più lenta di MySQL. Nei benchmark precedenti ciò che vediamo in genere è che l'aumento delle prestazioni di MariaDB prende avvio quando è stata integrata la versione più recente di InnoDB.
Tutto ciò significa che MariaDB 10.4 dovrebbe essere più stabile rispetto alle versioni precedenti. Significa anche che alla fine dovremo imparare gli interni di due diversi motori di archiviazione, soprattutto se ci preoccupiamo delle prestazioni. Questo è tutt'altro che ideale, ma è così. Gli strumenti dovranno essere progettati per funzionare con l'una o l'altra versione di InnoDB (o dovranno esserci funzioni aggiuntivi per supportare sia MySQL che MariaDB).
Programmatore informatico italiano, mi occupo di sviluppo sia Front-end che Back-end presso una grande azienda. La programmazione è stata la mia passione, insieme allo sport e al teatro che pratico tutt'ora. Ho deciso di aprire questo blog per dare consigli e condividerli con chi, come me, porta con sé questa passione. [..]
