{"id":106286,"date":"2022-12-28T15:36:45","date_gmt":"2022-12-28T13:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11"},"modified":"2022-12-28T15:36:45","modified_gmt":"2022-12-28T13:36:45","slug":"predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"\u00c8 stata presentata una nuova e significativa versione del DBMS MariaDB 11","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Dopo 10 anni dalla creazione della serie 10.x \u00e8 stato rilasciato il DBMS MariaDB 11.0.0, che offre diversi miglioramenti e modifiche significative che rompono la compatibilit\u00e0. La serie \u00e8 attualmente in qualit\u00e0 alpha e diventer\u00e0 pronta per applicazioni di produzione dopo un processo di stabilizzazione. La formazione della prossima versione significativa MariaDB 12, contenente modifiche che rompono la compatibilit\u00e0, \u00e8 prevista non prima del 2032. <\/p>\n
Il progetto MariaDB sviluppa una diramazione da MySQL, mantenendo per quanto possibile la retrocompatibilit\u00e0 e differenziandosi attraverso l'integrazione di motori di archiviazione aggiuntivi e funzionalit\u00e0 avanzate. Lo sviluppo di MariaDB \u00e8 supervisionato dall'organizzazione indipendente MariaDB Foundation, seguendo un processo di sviluppo aperto e trasparente, privo di dipendenze da singoli fornitori. Il DBMS MariaDB \u00e8 fornito al posto di MySQL in molte distribuzioni Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) ed \u00e8 implementato in grandi progetti come Wikipedia, Google Cloud SQL e Nimbuzz. <\/p>\n
Il miglioramento principale nella versione di MariaDB 11 \u00e8 la transizione dell'ottimizzatore delle query a un nuovo modello di pesatura (cost model), che assicura una previsione pi\u00f9 precisa dei pesi di ogni piano di esecuzione della query. Anche se il nuovo modello consente di eliminare alcuni colli di bottiglia in termini di prestazioni, non \u00e8 escluso che non sia ottimale in tutti gli scenari e potrebbe causare un rallentamento di alcune query. Pertanto, si raccomanda agli utenti di partecipare ai test e di informare gli sviluppatori in caso di problemi. <\/p>\n
Il modello precedentemente utilizzato era adatto per trovare l'indice ottimale, ma aveva problemi con l'applicabilit\u00e0 delle operazioni di scansione della tabella, scansione dell'indice o selezione per intervallo. Nel nuovo modello, questo difetto \u00e8 stato risolto grazie alla modifica del peso di base delle operazioni con il motore di archiviazione. Nella valutazione delle performance delle operazioni che dipendono dalla velocit\u00e0 di accesso al disco, come la scansione sequenziale dei record, si presume ora che i dati siano memorizzati su unit\u00e0 SSD, garantendo una velocit\u00e0 di lettura di 400MB al secondo. Inoltre, sono stati ottimizzati anche altri parametri di peso dell'ottimizzatore, il che ha consentito, ad esempio, di implementare la possibilit\u00e0 di utilizzare indici per le operazioni \u00abORDER BY\/GROUP BY\u00bb nelle sottoquery e di accelerare l'elaborazione di tabelle molto piccole. <\/p>\n
Si osserva che il nuovo modello di peso consentir\u00e0 di scegliere un piano di esecuzione della query pi\u00f9 ottimale nelle seguenti situazioni: <\/p>\n
\n
Quando si utilizzano query che coinvolgono pi\u00f9 di 2 tabelle.\n
In presenza di indici contenenti un grande numero di valori identici.\n
Quando si utilizzano intervalli che coprono oltre il 10% della tabella.\n
Quando ci sono query complesse in cui non tutte le colonne utilizzate sono indicizzate.\n
Quando si utilizzano query che coinvolgono diversi motori di archiviazione (ad esempio, quando in una query ci sono riferimenti a tabelle nei motori InnoDB e Memory).\n
Quando si utilizza FORCE INDEX per migliorare il piano della query.\n
In caso di deterioramento del piano di query durante l'uso di \u00abANALYZE TABLE\u00bb.\n
Quando la query copre un gran numero di tabelle derivate (un gran numero di SELECT annidati).\n
Quando si utilizzano espressioni ORDER BY o GROUP BY che si applicano agli indici. <\/ul>\n
Principali incompatibilit\u00e0 nella versione MariaDB 11: <\/p>\n
\n
I diritti SUPER non consentono pi\u00f9 di eseguire azioni per cui sono disponibili privilegi separatamente impostati. Ad esempio, per modificare il formato dei log binari saranno necessari i diritti BINLOG ADMIN.\n
Rimossa l'implementazione del buffer delle modifiche in InnoDB.\n
Dichiarati obsoleti innodb_flush_method e innodb_file_per_table.\n
Dichiarato obsoleto il supporto per i nomi mysql*.\n
Dichiarata obsoleta l'impostazione del parametro explicit_defaults_for_timestamp a 0.\n
I collegamenti simbolici per la compatibilit\u00e0 con MySQL sono stati trasferiti in un pacchetto separato.\n
Il valore predefinito del parametro innodb_undo_tablespaces \u00e8 stato modificato in 3. <\/ul>\n<\/ul>\n