MySQL 8.0 membawa perubahan besar dan modifikasi yang didorong oleh Tim Oracle MySQL. File fisik telah diubah. Misalnya, *.frm, *.TRG, *.TRN, dan *.par tidak ada lagi. Banyak fitur baru telah ditambahkan seperti CTE (Common Table Expressions), Window Functions, Invisible Indexes, regexp (atau Regular Expression) -- yang terakhir telah diubah dan sekarang menyediakan dukungan Unicode penuh dan multibyte aman. Kamus data juga berubah. Sekarang digabungkan dengan kamus data transaksional yang menyimpan informasi tentang objek database. Tidak seperti versi sebelumnya, data kamus disimpan dalam file metadata dan tabel non-transaksional. Keamanan telah ditingkatkan dengan penambahan baru caching_sha2_password yang sekarang menjadi otentikasi default menggantikan mysql_native_password dan menawarkan lebih banyak fleksibilitas tetapi keamanan yang diperketat yang harus menggunakan koneksi aman atau koneksi tidak terenkripsi yang mendukung pertukaran kata sandi menggunakan pasangan kunci RSA.
Dengan semua fitur keren, peningkatan, peningkatan yang ditawarkan MySQL 8.0, tim kami tertarik untuk menentukan seberapa baik kinerja MySQL 8.0 versi saat ini, terutama mengingat dukungan kami untuk versi MySQL 8.0.x di ClusterControl sedang dalam proses (jadi pantau terus hal ini). Postingan blog ini tidak akan membahas fitur MySQL 8.0, tetapi bermaksud membandingkan kinerjanya dengan MySQL 5.7 dan melihat bagaimana peningkatannya.
Penyiapan dan Lingkungan Server
Untuk tolok ukur ini, saya bermaksud menggunakan pengaturan minimal untuk produksi menggunakan lingkungan AWS EC2 berikut:
Jenis instans:instans t2.xlarge
Penyimpanan:gp2 (Penyimpanan SSD dengan minimal 100 dan maksimal 16000 IOPS)
vCPUS:4
Memori:16GiB
Versi MySQL 5.7:Server Komunitas MySQL (GPL) 5.7.24
Versi MySQL 8.0:Server Komunitas MySQL - GPL 8.0.14
Ada beberapa variabel penting yang saya tetapkan untuk tolok ukur ini juga, yaitu:
- innodb_max_dirty_pages_pct =90 ## Ini adalah nilai default di MySQL 8.0. Lihat di sini untuk detailnya.
- innodb_max_dirty_pages_pct_lwm=10 ## Ini adalah nilai default di MySQL 8.0
- innodb_flush_neighbors=0
- innodb_buffer_pool_instances=8
- innodb_buffer_pool_size=8GiB
Variabel lainnya yang diatur di sini untuk kedua versi (MySQL 5.7 dan MySQL 8.0) sudah disetel oleh ClusterControl untuk template my.cnf-nya.
Juga, pengguna yang saya gunakan di sini tidak sesuai dengan otentikasi baru MySQL 8.0 yang menggunakan caching_sha2_password. Sebaliknya, kedua versi server menggunakan mysql_native_password ditambah variabel innodb_dedicated_server OFF (default), yang merupakan fitur baru MySQL 8.0.
Untuk membuat hidup lebih mudah, saya mengatur node MySQL 5.7 versi Komunitas dengan ClusterControl dari host terpisah kemudian menghapus node dalam sebuah cluster dan mematikan host ClusterControl untuk membuat node MySQL 5.7 tidak aktif (tidak ada lalu lintas pemantauan). Secara teknis, kedua node MySQL 5.7 dan MySQL 8.0 tidak aktif dan tidak ada koneksi aktif yang melalui node, jadi pada dasarnya ini adalah tes benchmark murni.
Perintah dan Skrip yang Digunakan
Untuk tugas ini, sysbench digunakan untuk pengujian dan simulasi beban untuk dua lingkungan. Berikut adalah perintah atau skrip berikut yang digunakan pada pengujian ini:
sb-prepare.sh
#!/bin/bash
host=$1
#host192.168.10.110
port=3306
user='sysbench'
password='[email protected]'
table_size=500000
rate=20
ps_mode='disable'
sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --threads=1 --max-requests=0 --time=3600 --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --tables=10 --report-interval=1 --skip-trx=on --table-size=$table_size --rate=$rate --db-ps-mode=$ps_mode preparesb-run.sh
#!/usr/bin/env bash
host=$1
port=3306
user="sysbench"
password="[email protected]"
table_size=100000
tables=10
rate=20
ps_mode='disable'
threads=1
events=0
time=5
trx=100
path=$PWD
counter=1
echo "thread,cpu" > ${host}-cpu.csv
for i in 16 32 64 128 256 512 1024 2048;
do
threads=$i
mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log
tmpfile=$path/${host}-tmp${threads}
touch $tmpfile
/bin/bash cpu-checker.sh $tmpfile $host $threads &
/usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --events=$events --threads=$threads --time=$time --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --report-interval=1 --skip-trx=on --tables=$tables --table-size=$table_size --rate=$rate --delete_inserts=$trx --order_ranges=$trx --range_selects=on --range-size=$trx --simple_ranges=$trx --db-ps-mode=$ps_mode --mysql-ignore-errors=all run | tee -a $host-sysbench.log
echo "${i},"`cat ${tmpfile} | sort -nr | head -1` >> ${host}-cpu.csv
unlink ${tmpfile}
mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log
done
python $path/innodb-ops-parser.py $host
mysql -h $host -e "SHOW GLOBAL VARIABLES" >> $host-global-vars.logJadi skrip hanya menyiapkan skema sbtest dan mengisi tabel dan catatan. Kemudian ia melakukan tes beban baca/tulis menggunakan skrip /usr/share/sysbench/oltp_read_write.lua. Skrip membuang status global dan variabel MySQL, mengumpulkan penggunaan CPU, dan mem-parsing operasi baris InnoDB yang ditangani oleh skrip innodb-ops-parser.py. Script kemudian menghasilkan file *.csv berdasarkan log yang dibuang yang dikumpulkan selama benchmark, kemudian saya menggunakan spreadsheet Excel di sini untuk menghasilkan grafik dari file *.csv. Silakan periksa kode di sini di repositori github ini.
Sekarang, mari kita lanjutkan dengan hasil grafiknya!
Operasi Baris InnoDB
Pada dasarnya di sini, saya hanya mengekstrak operasi baris InnoDB yang melakukan pemilihan (membaca), menghapus, menyisipkan, dan memperbarui. Ketika jumlah utas meningkat, MySQL 8.0 secara signifikan mengungguli MySQL 5.7! Kedua versi tidak memiliki perubahan konfigurasi khusus, tetapi hanya variabel penting yang telah saya tetapkan. Jadi kedua versi tersebut cukup banyak menggunakan nilai default.
Menariknya, sehubungan dengan klaim Tim Server MySQL tentang kinerja baca dan tulis di versi baru, grafik menunjukkan peningkatan kinerja yang signifikan, terutama di server dengan beban tinggi. Bayangkan perbedaan antara MySQL 5.7 versus MySQL 8.0 untuk semua operasi baris InnoDB-nya, ada perbedaan yang tinggi terutama ketika jumlah utas bertambah. MySQL 8.0 mengungkapkan bahwa ia dapat bekerja secara efisien terlepas dari beban kerjanya.
Transaksi Diproses
Seperti terlihat pada grafik di atas, kinerja MySQL 8.0 kembali menunjukkan perbedaan waktu yang sangat besar untuk memproses transaksi. Semakin rendah, semakin baik kinerjanya yang berarti lebih cepat dalam memproses transaksi. Transaksi yang diproses (grafik kedua) juga mengungkapkan bahwa kedua jumlah transaksi tidak berbeda satu sama lain. Artinya, kedua versi menjalankan jumlah transaksi yang hampir sama tetapi berbeda dalam seberapa cepat penyelesaiannya. Meskipun saya dapat mengatakan, MySQL 5.7 masih dapat menangani banyak hal pada beban yang lebih rendah, tetapi beban realistis terutama dalam produksi dapat diharapkan lebih tinggi - terutama periode tersibuk.
Grafik di atas masih menunjukkan transaksi yang dapat diproses tetapi memisahkan pembacaan dari penulisan. Namun, sebenarnya ada outlier dalam grafik yang tidak saya sertakan karena itu adalah informasi kecil dari hasil yang akan mencondongkan grafik.
MySQL 8.0 mengungkapkan peningkatan besar terutama untuk melakukan pembacaan. Ini menampilkan efisiensinya dalam menulis terutama untuk server dengan beban kerja tinggi. Beberapa dukungan tambahan hebat yang memengaruhi kinerja MySQL untuk pembacaan di versi 8.0 adalah kemampuan untuk membuat indeks dalam urutan menurun (atau pemindaian indeks maju). Versi sebelumnya hanya memiliki pemindaian indeks menaik atau mundur, dan MySQL harus melakukan pengurutan file jika memerlukan urutan menurun (jika pengurutan file diperlukan, Anda dapat mempertimbangkan untuk memeriksa nilai max_length_for_sort_data). Indeks menurun juga memungkinkan pengoptimal untuk menggunakan indeks multi-kolom ketika urutan pemindaian yang paling efisien menggabungkan urutan menaik untuk beberapa kolom dan urutan menurun untuk yang lain. Lihat di sini untuk detail lebih lanjut.
Sumber Daya CPU
Selama pembandingan ini, saya memutuskan untuk mengambil beberapa sumber daya perangkat keras, terutama penggunaan CPU.
Mari saya jelaskan dulu bagaimana saya mengambil sumber daya CPU di sini selama benchmarking. sysbench tidak menyertakan statistik kolektif untuk sumber daya perangkat keras yang digunakan atau digunakan selama proses saat Anda membuat tolok ukur database. Karena itu, yang saya lakukan adalah membuat flag dengan membuat file, menyambungkan ke host target melalui SSH, lalu memanen data dari perintah Linux "top" dan mengurainya sambil tidur sebentar sebelum mengumpulkan lagi. Setelah itu, ambil peningkatan penggunaan CPU yang paling luar biasa untuk proses mysqld dan kemudian hapus file flag. Anda dapat meninjau kode yang saya miliki di github.
Jadi mari kita bahas lagi tentang hasil grafik, sepertinya mengungkapkan bahwa MySQL 8.0 memakan banyak CPU. Lebih dari MySQL 5.7. Namun, mungkin harus berurusan dengan variabel baru yang ditambahkan di MySQL 8.0. Misalnya, variabel ini mungkin memengaruhi server MySQL 8.0 Anda:
- innodb_log_spin_cpu_abs_lwm =80
- innodb_log_spin_cpu_pct_hwm =50
- innodb_log_wait_for_flush_spin_hwm =400
- innodb_parallel_read_threads =4
Variabel dengan nilainya dibiarkan dengan nilai default untuk benchmark ini. Tiga variabel pertama menangani CPU untuk redo logging, yang di MySQL 8.0 telah menjadi peningkatan karena mendesain ulang cara InnoDB menulis ke log REDO. Variabel innodb_log_spin_cpu_pct_hwm memiliki afinitas CPU, yang berarti akan mengabaikan inti CPU lainnya jika mysqld disematkan hanya ke 4 inti, misalnya. Untuk utas baca paralel, di MySQL 8.0, ia menambahkan variabel baru yang dapat Anda atur berapa banyak utas yang akan digunakan.
Namun, saya tidak menggali lebih jauh ke dalam subjek. Ada beberapa cara agar kinerja dapat ditingkatkan dengan memanfaatkan fitur yang ditawarkan MySQL 8.0.
Kesimpulan
Ada banyak sekali peningkatan yang hadir di MySQL 8.0. Hasil benchmark menunjukkan bahwa ada peningkatan yang mengesankan, tidak hanya dalam mengelola beban kerja baca, tetapi juga pada beban kerja baca/tulis yang tinggi dibandingkan dengan MySQL 5.7.
Beralih ke fitur-fitur baru MySQL 8.0, tampaknya ia telah memanfaatkan teknologi paling mutakhir tidak hanya pada perangkat lunak (seperti peningkatan besar untuk Memcached, Manajemen Jarak Jauh untuk pekerjaan DevOps yang lebih baik, dll.) tetapi juga dalam perangkat keras. Sebagai contoh, penggantian latin1 dengan UTF8MB4 sebagai default character encoding. Ini berarti akan membutuhkan lebih banyak ruang disk karena UTF8 membutuhkan 2-byte pada karakter non-US-ASCII. Meskipun tolok ukur ini tidak memanfaatkan penggunaan metode autentikasi baru dengan caching_sha2_password, tolok ukur ini tidak akan memengaruhi kinerja apakah menggunakan enkripsi. Setelah diautentikasi, itu disimpan dalam cache yang berarti otentikasi hanya dilakukan sekali. Jadi jika Anda menggunakan satu pengguna untuk klien Anda, itu tidak akan menjadi masalah dan lebih aman daripada versi sebelumnya.
Karena MySQL memanfaatkan perangkat keras dan perangkat lunak paling mutakhir, ia mengubah variabel defaultnya. Anda dapat membaca di sini untuk lebih jelasnya.
Secara keseluruhan, MySQL 8.0 telah mendominasi MySQL 5.7 secara efisien.
