La 10 ani de la înființarea filialei 10.x, a fost lansat MariaDB 11.0.0, care a oferit câteva îmbunătățiri semnificative și modificări care au rupt compatibilitatea. Ramura este în prezent în calitate de lansare alfa și va fi gata pentru utilizare în producție după stabilizare. Următoarea ramură majoră a MariaDB 12, care conține modificări care întrerup compatibilitatea, este așteptată nu mai devreme de 10 ani de acum înainte (în 2032).
Proiectul MariaDB dezvoltă o furcă din MySQL, menținând compatibilitatea cu înapoi ori de câte ori este posibil și prezentând integrarea unor motoare de stocare suplimentare și capabilități avansate. Dezvoltarea MariaDB este supravegheată de Fundația MariaDB independentă, în urma unui proces de dezvoltare deschis și transparent, care este independent de furnizorii individuali. SGBD-ul MariaDB este furnizat în locul MySQL în multe distribuții Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) și a fost implementat în proiecte atât de mari precum Wikipedia, Google Cloud SQL și Nimbuzz.
O îmbunătățire cheie în ramura MariaDB 11 este tranziția optimizatorului de interogări la un nou model de pondere (model de cost), care oferă o predicție mai precisă a ponderilor fiecărui plan de interogare. Deși noul model poate atenua unele blocaje de performanță, este posibil să nu fie optim în toate scenariile și poate încetini anumite interogări, așa că utilizatorii sunt încurajați să participe la testare și să notifice dezvoltatorii dacă apar probleme.
Modelul anterior a fost bun la găsirea indexului optim, dar a avut probleme cu aplicabilitatea scanărilor de tabel, scanărilor de index sau operațiunilor de preluare a intervalului. În noul model, acest dezavantaj este eliminat prin modificarea greutății de bază a operațiunilor cu motorul de stocare. Când evaluăm performanța pentru operațiunile dependente de viteza discului, cum ar fi scanările de scriere secvențială, presupunem acum că datele sunt stocate pe un SSD care oferă viteze de citire de 400 MB pe secundă. În plus, au fost ajustați și alți parametri de greutate ai optimizatorului, ceea ce, de exemplu, a făcut posibilă implementarea capacității de a utiliza indici pentru operațiunile „ORDER BY/GROUP BY” în subinterogări și de a accelera lucrul cu tabele foarte mici.
Se observă că noul model de greutate vă va permite să alegeți un plan de execuție a interogării mai optim în următoarele situații:
- Când utilizați interogări care acoperă mai mult de 2 tabele.
- Când aveți indecși care conțin un număr mare de valori identice.
- Când utilizați intervale care acoperă mai mult de 10% din tabel.
- Când aveți interogări complexe în care nu toate coloanele utilizate sunt indexate.
- Când sunt utilizate interogări care implică diferite motoare de stocare (de exemplu, când o interogare accesează tabelele din motoarele InnoDB și Memory).
- Când utilizați FORCE INDEX pentru a îmbunătăți planul de interogare.
- Când planul de interogare se deteriorează atunci când utilizați „ANALIZAȚI TABEL”.
- Când interogarea se întinde pe un număr mare de tabele derivate (număr mare de SELECT imbricate).
- Când utilizați expresii ORDER BY sau GROUP BY care se încadrează în indecși.
Probleme majore de compatibilitate în ramura MariaDB 11:
- Drepturile SUPER nu vă mai permit să efectuați acțiuni pentru care sunt disponibile privilegii setate separat. De exemplu, pentru a schimba formatul jurnalelor binare, veți avea nevoie de drepturi BINLOG ADMIN.
- S-a eliminat implementarea tamponului de modificare în InnoDB.
- Innodb_flush_method și innodb_file_per_table au fost depreciate.
- Suportul pentru nume Mysql* a fost depreciat.
- Setarea explicit_defaults_for_timestamp la 0 a fost retrasă.
- Legăturile simbolice sunt incluse într-un pachet separat pentru compatibilitate cu MySQL.
- Valoarea implicită a parametrului innodb_undo_tablespaces a fost schimbată la 3.
Sursa: opennet.ru