Kembali pada hari-hari ketika seseorang mengatakan MySQL, hanya ada MySQL. Anda dapat memilih versi yang berbeda (4.0, 4.1) tetapi vendornya sama. Ini berubah di sekitar MySQL 5.0/5.1 ketika Percona memutuskan untuk merilis rasa MySQL mereka sendiri - Server Percona. Beberapa saat kemudian, MariaDB bergabung dengan MariaDB 5.1 dan kesenangan (atau kebingungan) meningkat. Versi apa yang harus saya gunakan? Apa perbedaan antara MySQL 5.1, Percona Server 5.1 dan MariaDB 5.1? Mana yang lebih cepat? Mana yang lebih stabil? Manakah yang memiliki fungsionalitas superior? Seiring waktu, ini menjadi lebih buruk karena semakin banyak perubahan yang diperkenalkan di setiap rasa. Posting blog ini akan menjadi upaya kami untuk merangkum fitur-fitur utama yang membedakannya. Kami juga akan mencoba memberi Anda beberapa saran tentang rasa mana yang terbaik untuk jenis proyek tertentu. Mari kita mulai.
Oracle MySQL
Dulu MySQL, sekarang upstream. Sebagian besar pengembangan dimulai di sini, setiap versi mulai dari 5.6 menyelesaikan beberapa perselisihan internal dan menghadirkan kinerja yang lebih baik. Fitur-fitur baru juga ditambahkan secara teratur. MySQL 5.6 membawa kami (antara lain) GTID dan implementasi awal replikasi paralel. Ini juga memberi kami kemampuan untuk mengeksekusi sebagian besar ALTER secara online. Mari kita lihat fitur-fitur MySQL versi terbaru - MySQL 5.7
Fitur MySQL 5.7
Salah satu perubahan besar adalah perubahan dalam proses penerapan - alih-alih skrip yang berbeda, Anda cukup menjalankan mysqld --initialize untuk mengatur MySQL dari awal. Perubahan lain yang sangat penting - replikasi paralel berdasarkan jam logis. Terakhir, kita dapat menggunakan replikasi paralel dalam semua kasus - tidak peduli apakah Anda menggunakan banyak skema atau tidak. Peningkatan replikasi lainnya adalah replikasi multi-sumber - slave 5.7 dapat memiliki banyak master - ini adalah fitur hebat jika Anda ingin membuat slave agregasi dan, katakanlah, menggabungkan data dari beberapa cluster terpisah.
InnoDB mulai mendukung tipe spasial, kumpulan buffer InnoDB akhirnya dapat diubah ukurannya saat runtime, ALTER online telah ditingkatkan untuk mendukung lebih banyak kasus seperti partisi dan ALTER tanpa operasi.
MySQL mulai mendukung tipe data JSON secara native bersama dengan beberapa fungsi baru yang difokuskan pada penambahan fungsionalitas di sekitar JSON. Keamanan data Anda sangat penting akhir-akhir ini, MySQL 5.7 mendukung enkripsi data-at-rest untuk tablespace file-per-tabel. Beberapa peningkatan juga telah ditambahkan ke dukungan SSL (SSL akan dikonfigurasi jika kunci ada, skrip disertakan yang dapat digunakan untuk membuat sertifikat). Dari perspektif manajemen pengguna, penyiapan masa pakai sandi telah ditambahkan, yang seharusnya membuat desain kebijakan kedaluwarsa sandi sedikit lebih mudah.
Fitur lain yang dimaksudkan untuk membantu DBA adalah skema 'sys', serangkaian tampilan yang dirancang untuk memudahkan penggunaan Skema Kinerja. Sudah disertakan secara default di MySQL 5.7.
Akhirnya, MySQL Group Replication (dan akhirnya MySQL InnoDB Cluster) telah ditambahkan ke MySQL 5.7. Ini berfungsi sebagai plugin dan disertakan dalam versi terbaru dari cabang 5.7, tetapi itu adalah topik tersendiri. Singkatnya, Group Replication memungkinkan Anda membangun cluster sinkron “hampir”.
Ini jelas bukan daftar fitur yang lengkap - jika Anda tertarik dengan semuanya, Anda mungkin ingin melihat dokumentasi MySQL 5.7.
Server Percona
Pada awalnya, ada satu set tambalan untuk diterapkan ke kode sumber MySQL yang menambahkan beberapa peningkatan kinerja dan fungsionalitas. Pada titik tertentu, Percona memutuskan untuk merilis build MySQL mereka sendiri yang menyertakan tambalan ini. Seiring waktu, semakin banyak sumber daya pengembangan yang tersedia, sehingga semakin banyak fitur yang ditambahkan.
Secara umum, Anda dapat melihat Server Percona sebagai versi MySQL terbaru dengan beberapa tambalan/perbaikan. Seiring waktu, beberapa peningkatan fitur Server Percona digantikan oleh fitur dari hulu - setiap kali Oracle mengembangkan fitur yang menggantikan salah satu fungsi yang ditambahkan di Server Percona. Selama implementasinya setara, Percona menghapus kode mereka sendiri demi kode dari hulu. Ini menjadikan Percona Server pada dasarnya pengganti drop-in untuk Oracle's MySQL. Salah satu area di mana peningkatan kinerja utama telah dilakukan adalah InnoDB. Ini telah dimodifikasi cukup signifikan untuk mencapnya sebagai XtraDB. Saat ini sepenuhnya kompatibel dengan InnoDB tetapi tidak selalu seperti itu. Misalnya, beberapa fitur di Percona Server 5.5 tidak kompatibel dengan MySQL 5.5. Hal ini juga berlaku untuk versi Server Percona yang lebih baru. Yang penting adalah, secara default, Server Percona hadir dengan semua fitur yang tidak kompatibel dinonaktifkan - ini memudahkan untuk mengujinya dan memutar kembali ke MySQL Oracle jika diperlukan. Dengan mempertimbangkan semua hal di atas, Anda tetap harus berhati-hati saat berencana bermigrasi dari Server Percona ke MySQL - seseorang mungkin telah mengaktifkan salah satu fitur yang tidak kompatibel.
Apa yang patut disoroti adalah bahwa Percona berusaha untuk mengimplementasikan kembali fitur-fitur perusahaan di hulu. Dalam kasus MySQL, contohnya adalah implementasi dari kumpulan utas atau plugin otentikasi PAM. Mari kita lihat sekilas beberapa fitur Server Percona.
Fitur Percona Server 5.7
Salah satu fitur utama XtraDB adalah peningkatan skalabilitas kumpulan buffer - meskipun perselisihan semakin berkurang karena pekerjaan yang dilakukan Oracle pada setiap versi MySQL, tim teknik Percona berusaha untuk mendorong kinerja lebih jauh dan menghapus mutex tambahan yang dapat membatasi kinerja. Selain itu, lebih banyak data ditulis ke dalam monitor InnoDB (dapat diakses melalui SHOW ENGINE INNODB STATUS) mengenai pertentangan dalam InnoDB - misalnya, bagian tentang semaphore telah ditambahkan.
Satu set perbaikan telah dibuat di bidang I/O. Di InnoDB, Anda dapat mengatur metode flush hanya untuk tablespace InnoDB dan ini menyebabkan buffering ganda untuk log redo InnoDB. XtraDB memungkinkan untuk menggunakan O_DIRECT juga untuk file-file itu. Itu juga menambahkan lebih banyak data mengenai pos pemeriksaan ke output SHOW ENGINE INNODB STATUS. Selain itu, buffer doublewrite paralel dan flusher LRU multi-utas telah diterapkan untuk mengurangi pertentangan dalam operasi I/O dalam InnoDB.
Thread pool adalah fitur lain yang disediakan oleh Percona Server. Di Oracle MySQL, ini hanya tersedia dalam edisi Enterprise. Di sini Anda dapat menggunakan implementasi Percona secara gratis. Secara umum, kumpulan utas mengurangi pertengkaran sambil melayani koneksi dalam jumlah besar dari aplikasi dengan menggunakan kembali koneksi yang ada ke database.
Dua fitur lainnya adalah penggantian langsung fitur dari MySQL versi Enterprise. Salah satunya adalah plugin otentikasi PAM yang telah dikembangkan oleh Percona dan dirancang untuk memungkinkan penggunaan banyak pilihan otentikasi yang berbeda seperti LDAP, RSA SecurID atau metode lain yang didukung oleh PAM. Fitur kedua juga terkait dengan keamanan - plugin log audit. Ini akan membuat file dengan catatan tindakan yang diambil pada server database.
Dari waktu ke waktu, Percona memperkenalkan peningkatan signifikan pada mesin penyimpanan lain seperti perubahan yang mereka buat pada mesin MEMORY yang memungkinkan jenis data VARCHAR atau BLOB digunakan.
Pengenalan kunci cadangan juga merupakan peningkatan yang cukup signifikan. Di Oracle dan MariaDB, satu-satunya metode mengunci tabel untuk mendapatkan cadangan yang konsisten adalah dengan menggunakan FLUSH TABLES WITH READ LOCK (FTWRL). Ini agak berat dan memaksa MySQL untuk menutup semua tabel yang dibuka. Kunci cadangan, di sisi lain, menggunakan pendekatan kunci metadata yang lebih ringan. Dalam banyak kasus, server dengan beban berat menjalankan FTWRL membutuhkan waktu terlalu lama (dan mengunci server terlalu lama) untuk dianggap layak sementara kunci cadangan memungkinkan untuk mengambil cadangan menggunakan mysqldump atau xtrabackup.
Percona juga terbuka pada fitur porting dari vendor lain. Salah satu contohnya adalah port dari MariaDB's MULAI TRANSAKSI DENGAN SNAPSHOTS KONSISTEN. Fitur ini juga terkait dengan pencadangan - dengan bantuannya, Anda dapat membuat pencadangan logis yang konsisten (menggunakan mysqldump) tanpa menjalankan FLUSH TABLE WITH READ LOCK.
Terakhir, tiga fitur yang meningkatkan observabilitas - pertama:statistik pengguna. Ini adalah fitur yang cukup ringan yang mengumpulkan data tentang pengguna, indeks, tabel, dan utas. Ini memungkinkan Anda untuk menemukan indeks yang tidak digunakan atau menentukan pengguna mana yang bertanggung jawab atas beban di server. Saat ini sebagian berlebihan untuk skema_kinerja tetapi sedikit lebih ringan dan dibuat pada masa MySQL 5.0 - 5.1, di mana tidak ada yang memimpikan skema_kinerja.
Kedua - log kueri lambat yang ditingkatkan. Sekali lagi, itu ditambahkan saat granularitas tertinggi long_query_time adalah 1 detik. Dengan tambahan ini, Anda memiliki perincian mikrodetik dan banyak data tambahan tentang statistik InnoDB per kueri atau karakteristik kinerjanya secara keseluruhan. Apakah itu membuat tabel sementara? Apakah itu menggunakan indeks? Apakah sudah di-cache di cache query MySQL?
Fitur ketiga yang kami sebutkan beberapa kali di atas - Server Percona memperlihatkan lebih banyak data secara signifikan di SHOW ENGINE INNODB STATUS daripada upstream. Sangat membantu untuk lebih memahami beban kerja dan menangkap lebih banyak masalah sebelum terungkap.
Tentu saja, ini bukan daftar lengkap - jika Anda tertarik dengan detail lebih lanjut, Anda mungkin ingin memeriksa dokumentasi Server Percona.
MariaDB
MariaDB dimulai sebagai cabang dari MySQL tetapi, dengan bagian dari tim pengembangan MySQL asli bergabung dengan MariaDB, dengan cepat berfokus pada penambahan fitur. Di MariaDB 5.3, banyak fitur telah ditambahkan ke pengoptimal:Batch Key Access, MultiRange Read, Index Condition Pushdown untuk beberapa nama. Ini memungkinkan MariaDB untuk unggul dalam beberapa beban kerja di mana MySQL atau Server Percona akan kesulitan. Sampai saat ini, beberapa fitur tersebut telah ditambahkan ke MySQL (kebanyakan di MySQL 5.6) tetapi beberapa masih unik untuk MariaDB.
Fitur penting lainnya yang diperkenalkan oleh MariaDB adalah Global Transaction ID. Tidak lama kemudian Oracle merilis implementasinya sendiri tetapi MariaDB adalah yang pertama memilikinya. Kisah serupa dengan fitur replikasi lain - replikasi multisumber:MariaDB memilikinya sebelum Oracle. Sekarang, MariaDB 10.2 yang baru-baru ini dirilis juga berisi fitur-fitur yang akan tersedia di MySQL 8.0, yang masih dalam pengembangan. Kita berbicara tentang, misalnya, ekspresi tabel umum rekursif atau fungsi jendela.
Fitur MariaDB 10.2
Seperti yang kami sebutkan, MariaDB 10.2 memperkenalkan fungsi jendela dan ekspresi tabel umum rekursif - peningkatan dalam SQL yang akan membantu pengembang untuk menulis kueri SQL yang lebih efisien.
Perubahan yang sangat penting adalah bahwa MariaDB 10.2 menggunakan InnoDB. Hingga 10.1, XtraDB telah digunakan sebagai penyimpanan default. Sayangnya, ini membuat fitur yang ditambahkan di XtraDB terbaru tidak tersedia untuk pengguna MariaDB 10.2.
Perbaikan telah dilakukan di kolom virtual - lebih banyak batasan telah dihilangkan di 10.2.
Terakhir, dukungan untuk beberapa pemicu untuk peristiwa yang sama telah ditambahkan - sekarang Anda dapat membuat beberapa, misalnya, pemicu ON UPDATE pada tabel yang sama.
Pengembang harus mendapat manfaat dari dukungan JSON, bersama dengan beberapa fungsi yang terkait dengannya. Mereka juga harus menyukai fungsi baru yang memungkinkan mereka mengekspor data spasial ke dalam format GeoJSON. Berbicara tentang JSON, peningkatan telah dilakukan di EXPLAIN FORMAT=JSON output - lebih banyak data ditampilkan.
Di bidang keamanan, dukungan untuk OpenSSL 1.1 dan LibreSSL telah ditambahkan.
Tentu saja, daftar ini tidak lengkap dan jika Anda tertarik dengan apa yang telah ditambahkan ke MySQL 10.2, Anda mungkin ingin melihat dokumentasi.
Selain fitur baru, MariaDB 10.2 mendapat manfaat dari fitur yang diterapkan di versi sebelumnya. Kami akan membahas yang paling penting.
Fitur Paling Penting dari MariaDB 10.1
Pertama-tama, MariaDB sejak 10.1 dibundel dengan cluster Galera - tidak perlu menginstal pustaka tambahan, semuanya siap digunakan.
MariaDB 10.1 membawa implementasi enkripsi data-at-rest. Dibandingkan dengan fitur yang diimplementasikan di Oracle MySQL, MariaDB memilikinya lebih luas. Tidak hanya mengenkripsi tablespace tetapi juga mengenkripsi redo log, file sementara dan log biner. Ini disertai dengan beberapa masalah - Alat CLI seperti mysqldump atau xtrabackup tidak dapat mengakses log biner dan mungkin mengalami masalah saat mencadangkan instance terenkripsi (ini terutama berlaku untuk xtrabackup - baru-baru ini MariaDB membuat garpu xtrabackup bernama MariaDB Backup yang mendukung data saat istirahat enkripsi).
Ok, Jadi Rasa Mana Yang Harus Saya Gunakan?
Seperti biasanya, jawaban yang benar adalah:“Tergantung” :-) . Kami akan membagikan beberapa pengamatan kami yang mungkin atau mungkin tidak membantu Anda memutuskan, tetapi, pada akhirnya, terserah Anda untuk menjalankan tolok ukur dan menemukan opsi apa pun yang paling sesuai untuk lingkungan dan aplikasi Anda.
Pertama-tama, mari kita bicara tentang alirannya. Oracle merilis versi baru - katakanlah MySQL 5.7. Dari segi kinerja, pada saat itu, ini adalah rasa MySQL tercepat di pasar. Ini karena hanya Oracle yang memiliki sumber daya yang cukup untuk meningkatkan InnoDB sejauh itu. Dalam beberapa bulan (dalam kasus 5.7, itu adalah 4 bulan) Percona merilis Percona Server 5.7 dengan serangkaian peningkatan mereka - tergantung pada jenis beban kerja, itu mungkin memberikan kinerja yang lebih baik daripada hulu. Terakhir, MariaDB mengadopsi versi upstream baru dan membangun versi baru di atasnya.
Beginilah tampilannya di kalender (kita masih berbicara tentang MySQL 5.7).
MySQL 5.7 GA:21 Oktober 2015
Percona Server 5.7 GA:23 Februari 2016
MariaDB 10.2 GA:23 Mei 2017
Harap perhatikan berapa lama MariaDB merilis versi berdasarkan MySQL 5.7 - semua versi sebelumnya didasarkan pada MySQL 5.6 dan, tentu saja, memberikan kinerja yang lebih rendah daripada MySQL 5.7. Di sisi lain, MariaDB 10.2 telah dirilis dengan InnoDB menggantikan XtraDB. Meskipun benar bahwa Oracle sebagian besar menutup kesenjangan kinerja antara MySQL dan Server Percona, itu masih "kebanyakan". Akibatnya, MariaDB 10.2 dapat memberikan kinerja yang lebih rendah daripada Server Percona dalam beberapa kasus (dan lebih baik dalam beberapa kasus lain - karena pekerjaan pengoptimal dilakukan di MariaDB 5.3, beberapa di antaranya belum dibuat ulang di MySQL).
Dari segi fitur, ini lebih kompleks. MariaDB telah menambahkan banyak fitur, jadi jika Anda tertarik dengan beberapa di antaranya, Anda pasti dapat mempertimbangkan untuk menggunakan MariaDB. Ada sisi negatifnya juga. Server Percona memiliki banyak fitur yang membedakannya dari MySQL hulu tetapi ketika Oracle mulai mengimplementasikannya di MySQL, Percona memutuskan untuk mendepresiasi implementasi mereka demi menggunakan implementasi dari hulu. Hal ini mengurangi jumlah kode yang berbeda antara MySQL dan Server Percona, memudahkan pemeliharaan kode Server Percona dan, yang paling penting, membuat Server Percona 100% kompatibel dengan MySQL.
Sayangnya, ini tidak berlaku untuk MariaDB. MariaDB memperkenalkan GTID terlebih dahulu, itu benar, tetapi setelah Oracle mengembangkan versi GTID mereka, MariaDB memutuskan untuk tetap pada implementasi mereka sendiri. Blog ini bukan tempat untuk memutuskan implementasi mana yang lebih baik, tetapi sebagai hasilnya kami harus mengelola dua sistem GTID yang berbeda dan tidak kompatibel - blog ini menambah beban pada alat apa pun yang mengelola replikasi dan mengurangi interoperabilitas. Berpegang teguh pada replikasi - komit grup dan replikasi paralel:Oracle dan MariaDB memiliki implementasinya sendiri dan jika Anda bekerja dengan keduanya, Anda perlu mempelajari keduanya untuk menerapkan penyetelan yang diperlukan - kenopnya berbeda dan bekerja dengan cara yang berbeda. Kasus serupa adalah dengan dukungan kolom virtual - dua implementasi yang berbeda, tidak 100% kompatibel yang, akibatnya, tidak memungkinkan untuk dengan mudah membuang data dari MariaDB dan memuat ke MySQL Oracle (dan sebaliknya) karena sintaksnya sedikit berbeda. Jadi, jika Anda memutuskan untuk menggunakan versi MariaDB untuk beberapa fitur baru, Anda mungkin akan terjebak dengannya bahkan jika Anda ingin bermigrasi kembali ke MySQL untuk menggunakan implementasi Oracle. Paling-paling, migrasi akan membutuhkan lebih banyak upaya untuk dieksekusi. Tentu saja, jika Anda tetap berada di satu lingkungan sepanjang waktu, itu mungkin tidak terlalu memengaruhi Anda. Namun meskipun demikian, kurangnya kompatibilitas akan terlihat bagi Anda, jika hanya saat Anda membaca blog di internet dan menemukan solusi yang tidak benar-benar sesuai dengan cita rasa MySQL Anda.
Jadi, kesimpulannya - jika Anda tertarik untuk menjaga kompatibilitas dengan MySQL, Percona Server (atau MySQL itu sendiri, tentu saja) mungkin adalah cara yang tepat. Jika Anda tertarik dengan kinerja, selama ada Server Percona yang dibangun di atas MySQL terbaru, ini mungkin cara yang tepat. Tentu saja, Anda mungkin ingin membandingkan MariaDB dan melihat apakah beban kerja Anda tidak dapat memanfaatkan beberapa pengoptimalan yang masih unik untuk MariaDB. Dari segi operasional, mungkin baik untuk tetap menggunakan salah satu lingkungan (Oracle/Percona atau MariaDB), mana yang lebih cocok untuk Anda. MySQL atau Server Percona memiliki keunggulan karena lebih umum digunakan dan sedikit lebih mudah untuk mengintegrasikannya dengan alat eksternal (karena tidak semua alat mendukung semua fitur MariaDB). Jika Anda akan mendapat manfaat dari fitur baru dan mengkilap yang baru saja diterapkan di MariaDB, Anda harus mempertimbangkannya, dengan mengingat potensi masalah kompatibilitas dan kemungkinan kinerja yang lebih rendah.
Kami berharap posting blog ini memberi Anda beberapa ide tentang pilihan berbeda yang kami miliki di dunia MySQL dan sudut pandang berbeda dari mana Anda dapat membandingkannya. Pada akhirnya, itu akan menjadi tugas Anda untuk memutuskan apa yang terbaik untuk pengaturan Anda. Ini mungkin tidak mudah, tetapi kita tetap harus bersyukur bahwa kita memiliki pilihan dan kita dapat memilih yang terbaik untuk kita.
