MariaDB 10.4 to aktualna gałąź rozwojowa MariaDB. Niedawno, 21 maja, ukazał się trzeci Release Candidate (10.4.5), przybliżający nas do oficjalnego wydania. Dlatego pomyśleliśmy, że dobrym pomysłem może być przyjrzenie się nowym funkcjom 10.4. Podzielimy się również kilkoma przemyśleniami w ostatnim poście na blogu opublikowanym przez MariaDB Corporation. Aby uzyskać informacje na temat samego wydania, wszystkie szczegóły można znaleźć w dzienniku zmian MariaDB 10.4.0.
Zmiany wydajności
Zestawy znaków Unicode są zazwyczaj wolniejsze niż zestawy znaków, takie jak latin1, głównie ze względu na ich rozmiar. MySQL 8.0 przyniósł znaczną poprawę w tym obszarze, a MariaDB 10.4 powinna być również zauważalnie szybsza niż 10.3 pod tym względem. To dość ważne ulepszenie - ludzie naprawdę uwielbiają używać emotikonów, które wymagają włączenia UTF8. Wykonano trochę pracy w optymalizatorze — MariaDB 10.4 powinna działać lepiej z podzapytaniami IN(), ponieważ teraz możliwe jest wypchnięcie warunków do zmaterializowanych podzapytań.
Uruchamianie i zatrzymywanie InnoDB może chwilę potrwać, w zależności od ilości danych w logach przeróbek. MariaDB 10.4 usprawni uruchamianie, zamykanie i czyszczenie. Takie ulepszenia są szczególnie ważne, biorąc pod uwagę popularność narzędzi do tworzenia kopii zapasowych na gorąco, takich jak mariabackup i xtrabackup. Narzędzia te w końcu przechodzą przez proces uruchamiania InnoDB od nieczystego zamknięcia, gdy stosują logi ponawiania, dlatego każda poprawa w tym obszarze powinna skrócić czas potrzebny na przywrócenie kopii zapasowych.
Zmiany InnoDB
MariaDB 10.4 otrzymała natychmiastową operację DROP COLUMN. Teraz można również zmienić kolejność kolumn w tabeli bez konieczności jej przebudowy. Nie możemy podkreślić, jak ważne jest to. Możesz się zastanawiać, jakie są najczęstsze operacje, które wykonujesz w środowisku produkcyjnym? Powiedzielibyśmy, że to dodanie lub usunięcie indeksu. Inną najczęstszą operacją byłyby operacje na kolumnach - dodaj nową kolumnę i usuń istniejącą. Do tej pory najczęstszym podejściem było korzystanie z zewnętrznych narzędzi do wykonania zadania:zmiana schematu pt-online lub, ostatnio, gh-ost. Oba mają swoje ograniczenia (na przykład gh-ost nie działa w Galera Cluster), które mogą uniemożliwić korzystanie z nich w twoim systemie. Szczególnie trudne są klucze obce. Dzięki natychmiastowemu DROP COLUMN (natychmiastowe ADD COLUMN jest już dostępne), dużą część zmian schematu można wykonać ad hoc, bez szczegółowego planowania i planowania, ponieważ należy to zrobić teraz. Należy pamiętać, że natychmiastowe zmiany są tym, czego chcemy. Istnieją nieblokujące zmiany schematu, takie jak tworzenie indeksu, ale takie operacje stanowią poważne wyzwanie, gdy używana jest replikacja, ponieważ powodują opóźnienie replikacji. Dlatego nawet jeśli operacja mogła zostać wykonana w systemie live, wolimy używać obejść, takich jak pt-online-schema-change, aby zachować lepszą kontrolę nad procesem.
To nie jedyne usprawnienie w sposobie realizacji zmian w schemacie. MariaDB 10.4 skorzysta z szybszego rozszerzenia kolumn VARCHAR, dodatkowo zmiany zestawu znaków i sortowania w kolumnach nieindeksowanych będą natychmiastowe.
Zmiany ogólne
Jedną z największych zmian są zmiany w zarządzaniu użytkownikami. Tabela mysql.host nie zostanie utworzona, tabela mysql.user jest przestarzała. Konta użytkowników i uprawnienia globalne będą przechowywane w tabeli mysql.global_priv. Jest to potencjalnie poważna zmiana dla wszystkich narzędzi (w tym ClusterControl), które mają opcję zarządzania użytkownikami MySQL i MariaDB - trzeba będzie napisać nowe przypadki, aby objąć zarządzanie użytkownikami w MariaDB 10.4 i nowszych. Chociaż zdajemy sobie sprawę, że potrzebne są zmiany, zdecydowanie nie pomaga to w utrzymaniu narzędzi zarówno dla MariaDB, jak i MySQL, sprawiając, że krajobraz narzędziowy jest jeszcze bardziej podzielony niż jest. Mówiąc o użytkownikach, MariaDB 10.4 zawiera opcję wygaśnięcia hasła użytkownika. Jest to zdecydowanie krok w dobrym kierunku - pomaga egzekwować dobre praktyki dotyczące zarządzania hasłami.
Chociaż omówimy to bardziej szczegółowo w osobnym blogu, musimy wspomnieć tutaj o obsłudze Galera 26.4 - MariaDB 10.4 skorzysta z nowej wersji Galera z funkcjami takimi jak replikacja strumieniowa lub ulepszone SST dzięki blokadom kopii zapasowych.
Wreszcie w MariaDB 10.4 możesz ustawić sql_mode=MSSQL. Jest to początkowa implementacja, ale sql_mode=ORACLE również była początkową implementacją w pewnym momencie. Pokazuje to, że MariaDB koncentruje się na klientach korporacyjnych — jeśli klienci Oracle zdecydują się na migrację, jest całkiem prawdopodobne, że adopcja MariaDB wśród Microsoft SQL Server również będzie rosła, ponieważ zostanie dodanych więcej funkcji, a migracja stanie się mniejszym problemem.
MariaDB jako widelec
Całkiem niedawno widzieliśmy wpis na blogu wyjaśniający stanowisko MariaDB w sprawie zmian i kompatybilności InnoDB. Istotą jest to, że MariaDB nie będzie już łączyć funkcji InnoDB z MySQL, skupimy się na poprawie stabilności i wydajności wykonanej przez MariaDB. Zasadniczo oznacza to, że MariaDB stanie się niekompatybilna z MySQL. Nawet jeśli mogłeś dokonać aktualizacji binarnej w przeszłości, nie będzie to możliwe w przyszłości. Nawet teraz może to być trudne do wykonania. Zwiększa to znaczenie narzędzi takich jak mydumper/myloader, ponieważ logiczna kopia zapasowa będzie jedynym sposobem migracji. Co jest dobre, MariaDB będzie w stanie zachować stabilność swojego forka InnoDB - nie będzie musiała zajmować się problemami wprowadzanymi przez zewnętrznych programistów, dlatego możemy spodziewać się mniejszej liczby wprowadzanych błędów.
Pod względem wydajności musimy poczekać na testy porównawcze, ale biorąc pod uwagę dane historyczne, możemy założyć, że MariaDB będzie wolniejsza niż MySQL. W poprzednich testach porównawczych zwykle widzimy, że wzrost wydajności MariaDB zaczyna się, gdy integrowana jest nowsza wersja InnoDB. Tak już nie będzie, co sprawia, że zastanawiamy się, jak MariaDB będzie od teraz radzić sobie w porównaniu wydajności i czy ulepszenia wprowadzone przez MariaDB wystarczą, aby nadążyć za MySQL 8.0 i kolejnymi wersjami.
Dla nas użytkowników to wszystko oznacza, że MariaDB 10.4 powinna być bardziej stabilna niż poprzednie wydania. Oznacza to również, że w końcu będziemy musieli nauczyć się elementów wewnętrznych dwóch różnych silników pamięci masowej – zwłaszcza jeśli zależy nam na wydajności. To dalekie od ideału, ale tak właśnie jest. Narzędzia będą musiały być zaprojektowane do pracy z jedną lub drugą wersją InnoDB (lub trzeba będzie dodać dodatkową pracę, aby obsługiwać zarówno MySQL, jak i MariaDB). Będziemy obserwować, jak się to potoczy. Kiedy się nad tym zastanowić, nie jest to aż tak zaskakujące posunięcie – MariaDB zawsze musiała poświęcić trochę czasu na integrację z nowszą wersją InnoDB. Wraz z dodawaniem coraz większej liczby niekompatybilnych funkcji do MariaDB i ogromnymi zmianami wprowadzonymi w MySQL 8.0, sensowne jest skupienie się na rozwijaniu nowych funkcji, a nie na przenoszeniu niekompatybilnego InnoDB z wcześniejszego MySQL.
Mamy nadzieję, że ten krótki wpis na blogu dał wgląd w zmiany, które dotkną systemy produkcyjne po przejściu do MariaDB 10.4.
