10 anni dopo la fondazione del ramo 10.x, è stata rilasciata MariaDB 11.0.0, che ha offerto numerosi miglioramenti e modifiche significativi che hanno interrotto la compatibilità. Il ramo è attualmente in qualità di rilascio alpha e sarà pronto per l'uso in produzione dopo la stabilizzazione. Il prossimo ramo principale di MariaDB 12, contenente modifiche che interrompono la compatibilità, è previsto non prima di 10 anni da oggi (nel 2032).
Il progetto MariaDB sta sviluppando un fork di MySQL, mantenendo la compatibilità con le versioni precedenti quando possibile e prevedendo l'integrazione di motori di archiviazione aggiuntivi e funzionalità avanzate. Lo sviluppo di MariaDB è supervisionato dalla MariaDB Foundation, indipendente, seguendo un processo di sviluppo aperto e trasparente, indipendente dai singoli fornitori. Il DBMS MariaDB viene fornito al posto di MySQL in molte distribuzioni Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) ed è stato implementato in progetti di grandi dimensioni come Wikipedia, Google Cloud SQL e Nimbuzz.
Un miglioramento chiave nel ramo MariaDB 11 è la transizione del Query Optimizer a un nuovo modello di peso (modello di costo), che fornisce una previsione più accurata dei pesi di ciascun piano di query. Sebbene il nuovo modello possa alleviare alcuni colli di bottiglia delle prestazioni, potrebbe non essere ottimale in tutti gli scenari e potrebbe rallentare alcune query, quindi gli utenti sono incoraggiati a partecipare ai test e ad avvisare gli sviluppatori in caso di problemi.
Il modello precedente era efficace nel trovare l'indice ottimale, ma presentava problemi con l'applicabilità delle scansioni di tabelle, scansioni di indici o operazioni di recupero dell'intervallo. Nel nuovo modello questo inconveniente viene eliminato modificando il peso base delle operazioni con lo storage engine. Quando si valutano le prestazioni per operazioni dipendenti dalla velocità del disco, come le scansioni di scrittura sequenziali, si presuppone ora che i dati siano archiviati su un SSD che fornisce velocità di lettura di 400 MB al secondo. Inoltre, sono stati ottimizzati altri parametri di peso dell'ottimizzatore che, ad esempio, hanno permesso di implementare la possibilità di utilizzare gli indici per le operazioni "ORDER BY/GROUP BY" nelle sottoquery e di accelerare il lavoro con tabelle molto piccole.
Si noti che il nuovo modello di peso consentirà di scegliere un piano di esecuzione delle query più ottimale nelle seguenti situazioni:
- Quando si utilizzano query che si estendono su più di 2 tabelle.
- Quando si hanno indici contenenti un numero elevato di valori identici.
- Quando si utilizzano intervalli che coprono più del 10% della tabella.
- Quando si hanno query complesse in cui non tutte le colonne utilizzate sono indicizzate.
- Quando vengono utilizzate query che coinvolgono diversi motori di archiviazione (ad esempio, quando una query accede alle tabelle nei motori InnoDB e Memoria).
- Quando si utilizza FORCE INDEX per migliorare il piano di query.
- Quando il piano di query si deteriora quando si utilizza "ANALYZE TABLE".
- Quando la query si estende su un numero elevato di tabelle derivate (numero elevato di SELECT annidate).
- Quando si utilizzano espressioni ORDER BY o GROUP BY che rientrano negli indici.
Principali problemi di compatibilità nel ramo MariaDB 11:
- I diritti SUPER non consentono più di eseguire azioni per le quali sono disponibili privilegi impostati separatamente. Ad esempio, per modificare il formato dei log binari, avrai bisogno dei diritti BINLOG ADMIN.
- Rimossa l'implementazione del buffer di modifica in InnoDB.
- Innodb_flush_method e innodb_file_per_table sono stati deprecati.
- Il supporto dei nomi Mysql* è stato deprecato.
- L'impostazione di esplicitamente_defaults_for_timestamp su 0 è stata deprecata.
- I collegamenti simbolici sono inclusi in un pacchetto separato per compatibilità con MySQL.
- Il valore predefinito del parametro innodb_undo_tablespaces è stato modificato in 3.
Fonte: opennet.ru