MariaDB 10.4 е текущ клон за разработка на MariaDB. Наскоро, на 21 май, беше пуснат третият Release Candidate (10.4.5), което ни доближи до официалното издание. Ето защо решихме, че може да е добра идея да разгледаме новите функции 10.4. Ще споделим и някои мисли за скорошна публикация в блога, публикувана от MariaDB Corporation. За информация относно самото издание можете да намерите всички подробности в регистъра на промените на MariaDB 10.4.0.
Промени в производителността
Наборите от символи в Unicode обикновено са по-бавни от наборите от знаци като latin1, най-вече поради техния размер. MySQL 8.0 донесе значителни подобрения в тази област, а MariaDB 10.4 също трябва да бъде значително по-бърз от 10.3 в това отношение. Това е доста важно подобрение - хората наистина обичат да използват емоджи, които изискват активиране на UTF8. Известна работа беше извършена в оптимизатора - MariaDB 10.4 би трябвало да работи по-добре за IN() подзаявки, тъй като вече е възможно да се избутват условия в материализирани подзаявки.
Стартирането и спирането на InnoDB може да отнеме известно време, в зависимост от количеството данни в регистрационните файлове за повторно изпълнение. MariaDB 10.4 ще подобри стартирането, изключването и прочистването. Такива подобрения са особено важни предвид популярността на инструменти за горещо архивиране като mariabackup и xtrabackup. Тези инструменти в крайна сметка преминават през процеса на стартиране на InnoDB от нечисто изключване, когато прилагат регистрационни файлове за повторно изпълнение, следователно всяко подобрение в тази област трябва да намали времето, необходимо за възстановяване на архиви.
Промени в InnoDB
MariaDB 10.4 получи незабавна операция DROP COLUMN. Вече е възможно също да пренаредите колоните в таблицата, без да е необходимо да я възстановявате. Не можем да подчертаем колко важно е това. Може да се чудите кои са най-често срещаните операции, които извършвате в производствената среда? Бихме казали, че това е добавяне или премахване на индекс. Друга най-често срещана операция би била операции с колоните - добавяне на нова колона и премахване на съществуваща колона. Досега най-често срещаният подход беше да се използват външни инструменти за извършване на работата:pt-online-schema-change или, по-скоро, gh-ost. И двете имат своите ограничения (gh-ost не работи за Galera Cluster, например), което може да направи невъзможно използването им във вашата система. Особено трудни са външните ключове. С незабавно DROP COLUMN (instant ADD COLUMN вече е налична), голяма част от промените в схемата могат да се извършват ad hoc, без подробно планиране и планиране, както трябва да се направи сега. Важно е да имате предвид, че мигновените промени са това, което искаме да имаме. Има промени в неблокиращи схеми, като създаване на индекс, но такива операции представляват сериозно предизвикателство, когато се използва репликацията, тъй като предизвикват забавяне на репликацията. По този начин, въпреки че операцията можеше да се изпълни в жива система, ние предпочитаме да използваме заобиколни решения като pt-online-schema-change, за да запазим по-добър контрол върху процеса.
Това не е единственото подобрение в начина, по който се изпълняват промените в схемата. MariaDB 10.4 ще се възползва от по-бързото разширяване на колоните VARCHAR, освен това наборът от знаци и промените в съпоставянето на неиндексирани колони ще бъдат незабавни.
Общи промени
Една от най-големите промени са промените в управлението на потребителите. Таблицата Mysql.host няма да бъде създадена, таблицата mysql.user е отхвърлена. Потребителските акаунти и глобалните привилегии ще се съхраняват в таблицата mysql.global_priv. Това е потенциално сериозна промяна за всички инструменти (включително ClusterControl), които имат опция за управление на потребители на MySQL и MariaDB – ще трябва да бъдат написани нови случаи, които да покриват управлението на потребителите в MariaDB 10.4 и по-нататък. Въпреки че признаваме, че са необходими промени, това определено не помага за поддържането на инструменти както за MariaDB, така и за MySQL, което прави пейзажа с инструменти още по-разделен, отколкото вече е. Говорейки за потребителите, MariaDB 10.4 идва с опция за изтичане на потребителска парола. Това определено е стъпка в добра посока – помага за налагането на добри практики по отношение на управлението на пароли.
Въпреки че ще го разгледаме в отделен блог по-подробно, тук трябва да споменем поддръжката за Galera 26.4 – MariaDB 10.4 ще се възползва от нова версия на Galera с функции като стрийминг репликация или подобрен SST благодарение на заключване на архивиране.
И накрая, в MariaDB 10.4 можете да зададете sql_mode=MSSQL. Това е първоначална реализация, но sql_mode=ORACLE също беше първоначална реализация в някакъв момент. Това показва фокуса на MariaDB върху корпоративните клиенти – ако клиентите на Oracle решат да мигрират, е много вероятно приемането на MariaDB сред Microsoft SQL Server също да нарасне, тъй като ще бъдат добавени повече функции и миграцията ще стане по-малко проблем.
MariaDB е вилица
Съвсем наскоро видяхме публикация в блог, обясняваща позицията на MariaDB относно промените и съвместимостта на InnoDB. Същността е, че MariaDB вече няма да обединява InnoDB функции от MySQL, фокусът ще бъде върху стабилността и подобрението на производителността, извършено от MariaDB. Това основно означава, че MariaDB ще стане несъвместима с MySQL. Дори и да сте могли да направите надграждането на двоичен файл в миналото, това няма да е възможно в бъдеще. Дори в момента може да бъде трудно да се изпълни. Това увеличава значението на инструменти като mydumper/myloader, тъй като логическото архивиране ще бъде единственият начин за миграция. Какво е добре, MariaDB ще може да притежава стабилността на своя форк на InnoDB - няма да им се налага да се справят с проблеми, въведени от разработчиците нагоре по веригата, така че можем да очакваме въвеждането на по-малко грешки.
По отношение на производителността трябва да изчакаме сравнителни показатели, но като се имат предвид историческите данни, можем да предположим, че MariaDB ще бъде по-бавна от MySQL. В предишните бенчмаркове това, което обикновено виждаме, е, че повишаването на производителността за MariaDB започва, когато е интегрирана по-нова версия на InnoDB. Това вече няма да е така, което ни кара да се чудим как ще се справи MariaDB в сравнението на производителността оттук нататък и дали подобренията, въведени от MariaDB, ще бъдат достатъчни, за да бъдем в крак с MySQL 8.0 и по-нататъшни версии.
За нас потребителите всичко това означава, че MariaDB 10.4 трябва да бъде по-стабилна от предишните версии. Това също така означава, че в крайна сметка ще трябва да научим вътрешните елементи на два различни механизма за съхранение - особено ако ни е грижа за производителността. Това далеч не е идеално, но това е така. Инструментите ще трябва да бъдат проектирани да работят с една или друга версия на InnoDB (или ще трябва да се добави допълнителна работа за поддръжка както на MySQL, така и на MariaDB). Ще следим как ще се развие това. Като се замислите, това не е толкова изненадващ ход - MariaDB винаги трябваше да отделя време, за да се интегрира с по-нова версия на InnoDB. С все повече и повече несъвместими функции, които се добавят към MariaDB и огромни промени, въведени в MySQL 8.0, има смисъл да се съсредоточи върху разработването на нова функционалност, а не върху пренасянето на несъвместим InnoDB от горния MySQL.
Надяваме се, че тази кратка публикация в блога ви даде представа за промените, които ще засегнат производствените системи, когато преминете към MariaDB 10.4.
