MariaDB 10.4 adalah cabang pengembangan MariaDB saat ini. Baru-baru ini, pada 21 Mei, Kandidat Rilis ketiga (10.4.5) dirilis, membawa kita lebih dekat ke rilis resmi. Itu sebabnya kami pikir mungkin ide yang bagus untuk melihat fitur 10.4 yang baru. Kami juga akan membagikan beberapa pemikiran tentang posting blog terbaru yang diterbitkan oleh MariaDB Corporation. Untuk informasi tentang rilis itu sendiri, Anda dapat menemukan semua detailnya di log perubahan MariaDB 10.4.0.
Perubahan Kinerja
Kumpulan karakter Unicode biasanya lebih lambat daripada rangkaian karakter seperti latin1, sebagian besar karena ukurannya. MySQL 8.0 membawa peningkatan yang signifikan di bidang ini, dan MariaDB 10.4 juga harus terasa lebih cepat dari 10.3 dalam hal ini. Ini adalah peningkatan yang cukup penting - orang-orang sangat suka menggunakan emoji, yang mengharuskan UTF8 diaktifkan. Beberapa pekerjaan telah dilakukan di pengoptimal - MariaDB 10.4 seharusnya bekerja lebih baik untuk subkueri IN() karena sekarang memungkinkan untuk mendorong kondisi ke dalam subkueri yang terwujud.
Memulai dan menghentikan InnoDB dapat memakan waktu cukup lama, tergantung pada jumlah data dalam redo log. MariaDB 10.4 akan meningkatkan startup, shutdown, dan purging. Peningkatan tersebut sangat penting mengingat popularitas alat pencadangan panas seperti mariabackup dan xtrabackup. Alat-alat tersebut, pada akhirnya, melalui proses startup InnoDB dari shutdown yang tidak bersih ketika mereka menerapkan redo log, oleh karena itu setiap peningkatan di area tersebut akan mengurangi waktu yang diperlukan untuk memulihkan cadangan.
Perubahan InnoDB
MariaDB 10.4 telah menerima operasi DROP COLUMN instan. Sekarang juga dimungkinkan untuk menyusun ulang kolom dalam tabel tanpa perlu membangunnya kembali. Kami tidak dapat menekankan betapa pentingnya hal ini. Anda mungkin bertanya-tanya apa operasi paling umum yang Anda lakukan di lingkungan produksi? Kami akan mengatakan itu menambah atau menghapus file index. Operasi lain yang paling umum adalah operasi pada kolom - tambahkan kolom baru dan hapus kolom yang ada. Sejauh ini pendekatan yang paling umum adalah menggunakan alat eksternal untuk melakukan pekerjaan:pt-online-schema-change atau, baru-baru ini, gh-ost. Keduanya memiliki keterbatasan (gh-ost tidak berfungsi untuk Galera Cluster, misalnya) yang mungkin tidak memungkinkan untuk digunakan di sistem Anda. Terutama rumit adalah kunci asing. Dengan instant DROP COLUMN (instant ADD COLUMN sudah tersedia), sebagian besar perubahan skema dapat dilakukan secara ad hoc, tanpa penjadwalan dan perencanaan yang mendetail, seperti yang harus dilakukan sekarang. Penting untuk diingat bahwa perubahan instan adalah apa yang kita inginkan. Ada perubahan skema non-pemblokiran, seperti membuat indeks, tetapi operasi semacam itu menimbulkan tantangan serius ketika replikasi digunakan karena menyebabkan jeda replikasi. Jadi, meskipun operasi dapat dijalankan pada sistem langsung, kami lebih suka menggunakan solusi seperti pt-online-schema-change untuk menjaga kontrol yang lebih baik atas proses.
Ini bukan satu-satunya perbaikan dalam bagaimana perubahan skema dijalankan. MariaDB 10.4 akan mendapat manfaat dari ekstensi kolom VARCHAR yang lebih cepat, tambahan set karakter dan perubahan susunan pada kolom yang tidak diindeks akan instan.
Perubahan Umum
Salah satu perubahan terbesar adalah perubahan dalam manajemen pengguna. Tabel mysql.host tidak akan dibuat, tabel mysql.user tidak digunakan lagi. Akun pengguna dan hak global akan disimpan di tabel mysql.global_priv. Ini berpotensi menjadi perubahan serius untuk semua alat (termasuk ClusterControl), yang memiliki opsi untuk mengelola pengguna MySQL dan MariaDB - kasus baru harus ditulis untuk mencakup manajemen pengguna di MariaDB 10.4 dan seterusnya. Meskipun kami mengakui bahwa perubahan diperlukan, ini jelas tidak membantu memelihara alat untuk MariaDB dan MySQL, membuat lanskap alat menjadi lebih terbagi daripada yang sudah ada. Berbicara tentang pengguna, MariaDB 10.4 hadir dengan opsi untuk kata sandi pengguna yang kedaluwarsa. Ini jelas merupakan langkah ke arah yang baik - ini membantu menegakkan praktik yang baik terkait pengelolaan sandi.
Meskipun kami akan membahasnya di blog terpisah secara lebih rinci, kami harus menyebutkan di sini dukungan untuk Galera 26.4 - MariaDB 10.4 akan mendapat manfaat dari versi Galera baru dengan fitur seperti replikasi streaming atau peningkatan SST berkat kunci cadangan.
Terakhir, di MariaDB 10.4 Anda dapat mengatur sql_mode=MSSQL. Ini adalah implementasi awal tetapi sql_mode=ORACLE juga merupakan implementasi awal di beberapa titik. Hal ini menunjukkan fokus MariaDB pada pelanggan perusahaan - jika pelanggan Oracle memutuskan untuk bermigrasi, kemungkinan besar adopsi MariaDB di antara Microsoft SQL Server juga akan tumbuh karena lebih banyak fitur akan ditambahkan dan migrasi akan menjadi lebih sedikit masalah.
MariaDB Menjadi Garpu
Baru-baru ini kami melihat posting blog yang menjelaskan pendirian MariaDB tentang perubahan dan kompatibilitas InnoDB. Intinya adalah MariaDB tidak akan lagi menggabungkan fitur InnoDB dari MySQL, fokusnya adalah pada stabilitas dan peningkatan kinerja yang dilakukan oleh MariaDB. Ini pada dasarnya berarti bahwa MariaDB akan menjadi tidak kompatibel dengan MySQL. Bahkan jika Anda bisa melakukan upgrade biner di masa lalu, ini tidak akan mungkin di masa depan. Bahkan saat ini bisa jadi sulit untuk dieksekusi. Ini meningkatkan pentingnya alat seperti mydumper/myloader karena pencadangan logis akan menjadi satu-satunya cara untuk migrasi. Apa yang baik, MariaDB akan dapat memiliki stabilitas garpu InnoDB mereka - mereka tidak perlu berurusan dengan masalah yang diperkenalkan oleh pengembang hulu sehingga kita dapat mengharapkan lebih sedikit bug yang diperkenalkan.
Dari segi kinerja, kita harus menunggu tolok ukur tetapi mengingat data historis, kita dapat mengasumsikan MariaDB akan lebih lambat dari MySQL. Di masa lalu, apa yang biasanya kita lihat adalah bahwa peningkatan kinerja untuk MariaDB dimulai ketika versi InnoDB yang lebih baru telah terintegrasi. Ini tidak lagi menjadi kasus yang membuat kita bertanya-tanya bagaimana MariaDB akan berjalan dalam perbandingan kinerja mulai sekarang dan apakah peningkatan yang diperkenalkan oleh MariaDB akan cukup untuk mengikuti MySQL 8.0 dan versi lebih lanjut.
Bagi kami pengguna, semua ini berarti MariaDB 10.4 harus lebih stabil dari rilis sebelumnya. Ini juga berarti bahwa pada akhirnya kita harus mempelajari internal dari dua mesin penyimpanan yang berbeda - terutama jika kita peduli dengan kinerjanya. Ini jauh dari ideal tapi begitulah adanya. Alat harus dirancang untuk bekerja dengan satu atau versi lain dari InnoDB (atau pekerjaan tambahan harus ditambahkan untuk mendukung MySQL dan MariaDB). Kami akan mengawasi bagaimana ini akan berkembang. Ketika Anda memikirkannya, itu bukan langkah yang mengejutkan - MariaDB selalu harus meluangkan waktu untuk berintegrasi dengan versi InnoDB yang lebih baru. Dengan semakin banyak fitur yang tidak kompatibel ditambahkan ke MariaDB dan perubahan besar yang diperkenalkan di MySQL 8.0, masuk akal untuk fokus pada pengembangan fungsionalitas baru daripada porting InnoDB yang tidak kompatibel dari MySQL hulu.
Kami berharap posting blog singkat ini memberi Anda wawasan tentang perubahan yang akan terjadi pada sistem produksi saat membuka MariaDB 10.4.
