{"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\/en\/blog\/news\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"A new significant branch of the MariaDB database management system 11 has been introduced.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ten years after the launch of the 10.x branch, the release of the MariaDB 11.0.0 database management system has been introduced, featuring several significant improvements and compatibility-breaking changes. The branch is currently in alpha release quality and will be ready for production use after stabilization. The formation of the next major branch, MariaDB 12, which will include compatibility-breaking changes, is expected not earlier than ten years from now (in 2032). <\/p>\n

The MariaDB project is a fork of MySQL that aims to maintain backward compatibility while incorporating additional storage engines and enhanced features. Development of MariaDB is overseen by the independent MariaDB Foundation, following an open and transparent development process that is not reliant on specific vendors. The MariaDB database management system is supplied instead of MySQL in many Linux distributions (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) and is implemented in major projects such as Wikipedia, Google Cloud SQL, and Nimbuzz. <\/p>\n

A key improvement in the MariaDB 11 branch is the transition of the query optimizer to a new cost model, providing more accurate predictions of the weights for each query execution plan. Although the new model helps eliminate some performance bottlenecks, it may not be optimal in all scenarios, and some queries could slow down. Therefore, users are encouraged to participate in testing and inform developers if any issues arise. <\/p>\n

The previously used model was well-suited for finding the optimal index but had issues with the applicability of table scans, index scans, or range selections. In the new model, this drawback has been addressed by adjusting the base weights of the operations with the storage engine. When evaluating the performance of operations dependent on disk speed, such as sequential record scans, it is now assumed that the data is stored on an SSD with a reading speed of 400MB per second. Additionally, tuning of other optimizer weight parameters has been conducted, which, for example, has enabled the use of indexes for 'ORDER BY\/GROUP BY' operations in subqueries and improved the performance with very small tables. <\/p>\n

It is noted that the new weighting model will allow for the selection of a more optimal query execution plan in the following situations: <\/p>\n