Đo điểm chuẩn hiệu suất của MySQL:MySQL 5.7 so với MySQL 8.0

MySQL 8.0 đã mang đến những thay đổi và sửa đổi to lớn do Nhóm Oracle MySQL thực hiện. Các tệp vật lý đã được thay đổi. Ví dụ:* .frm, * .TRG, * .TRN và * .par không còn tồn tại nữa. Hàng tấn tính năng mới đã được thêm vào như CTE (Biểu thức bảng chung), Chức năng cửa sổ, Chỉ mục vô hình, regexp (hoặc Biểu thức chính quy) - cái sau đã được thay đổi và hiện cung cấp hỗ trợ Unicode đầy đủ và an toàn nhiều byte. Từ điển dữ liệu cũng đã thay đổi. Giờ đây, nó được kết hợp với từ điển dữ liệu giao dịch để lưu trữ thông tin về các đối tượng cơ sở dữ liệu. Không giống như các phiên bản trước, dữ liệu từ điển được lưu trữ trong các tệp siêu dữ liệu và các bảng không giao dịch. Bảo mật đã được cải thiện với việc bổ sung mới caching_sha2_password, hiện là xác thực mặc định thay thế mysql_native_password và cung cấp tính linh hoạt hơn nhưng bảo mật được thắt chặt hơn, phải sử dụng kết nối an toàn hoặc kết nối không được mã hóa hỗ trợ trao đổi mật khẩu bằng cặp khóa RSA.

Với tất cả các tính năng, cải tiến, cải tiến thú vị này mà MySQL 8.0 cung cấp, nhóm của chúng tôi quan tâm đến việc xác định mức độ hoạt động của phiên bản hiện tại MySQL 8.0, đặc biệt là khi hỗ trợ của chúng tôi cho các phiên bản MySQL 8.0.x trong ClusterControl đang được triển khai (vì vậy hãy chú ý theo dõi về điều này). Bài đăng trên blog này sẽ không thảo luận về các tính năng của MySQL 8.0, nhưng dự định đánh giá hiệu suất của nó so với MySQL 5.7 và xem nó đã được cải thiện như thế nào sau đó.

Thiết lập và Môi trường Máy chủ

Đối với điểm chuẩn này, tôi dự định sử dụng thiết lập tối thiểu để sản xuất bằng cách sử dụng môi trường AWS EC2 sau:

Loại phiên bản:t2.xlarge instance
Bộ nhớ:gp2 (bộ nhớ SSD tối thiểu 100 và tối đa 16000 IOPS)
vCPUS:4
Bộ nhớ:16GiB
Phiên bản MySQL 5.7:MySQL Community Server (GPL) 5.7.24
Phiên bản MySQL 8.0:MySQL Community Server - GPL 8.0.14

Có một vài biến số đáng chú ý mà tôi cũng đã đặt cho điểm chuẩn này, đó là:

innodb_max_dirty_pages_pct =90 ## Đây là giá trị mặc định trong MySQL 8.0. Xem chi tiết tại đây.
innodb_max_dirty_pages_pct_lwm =10 ## Đây là giá trị mặc định trong MySQL 8.0
innodb_flush_neighbors =0
innodb_buffer_pool_instances =8
innodb_buffer_pool_size =8GiB

Phần còn lại của các biến đang được đặt ở đây cho cả hai phiên bản (MySQL 5.7 và MySQL 8.0) đã được ClusterControl tinh chỉnh cho mẫu my.cnf của nó.

Ngoài ra, người dùng tôi đã sử dụng ở đây không tuân theo xác thực mới của MySQL 8.0 sử dụng caching_sha2_password. Thay vào đó, cả hai phiên bản máy chủ đều sử dụng mysql_native_password cộng với biến innodb_dedicated_server là TẮT (mặc định), đây là một tính năng mới của MySQL 8.0.

Để làm cho cuộc sống dễ dàng hơn, tôi thiết lập nút phiên bản cộng đồng MySQL 5.7 với ClusterControl từ một máy chủ riêng biệt, sau đó xóa nút trong một cụm và tắt máy chủ ClusterControl để làm cho nút MySQL 5.7 không hoạt động (không có lưu lượng giám sát). Về mặt kỹ thuật, cả hai nút MySQL 5.7 và MySQL 8.0 đều không hoạt động và không có kết nối hoạt động nào đi qua các nút, vì vậy về cơ bản đây là một bài kiểm tra điểm chuẩn thuần túy.

Các lệnh và tập lệnh được sử dụng

Đối với nhiệm vụ này, sysbench được sử dụng để thử nghiệm và mô phỏng tải cho hai môi trường. Dưới đây là các lệnh hoặc tập lệnh sau đang được sử dụng trong bài kiểm tra này:

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 prepare

sb-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.log

Vì vậy, tập lệnh chỉ đơn giản là chuẩn bị lược đồ sbtest và điền các bảng và bản ghi. Sau đó, nó thực hiện kiểm tra tải đọc / ghi bằng tập lệnh /usr/share/sysbench/oltp_read_write.lua. Tập lệnh kết xuất trạng thái toàn cục và các biến MySQL, thu thập việc sử dụng CPU và phân tích cú pháp các hoạt động hàng InnoDB được xử lý bởi tập lệnh innodb-ops-parser.py. Sau đó, các tập lệnh tạo các tệp * .csv dựa trên các nhật ký đã kết xuất được thu thập trong quá trình chuẩn, sau đó tôi sử dụng bảng tính Excel tại đây để tạo biểu đồ từ các tệp * .csv. Vui lòng kiểm tra mã tại đây trong kho lưu trữ github này.

Bây giờ, hãy tiếp tục với kết quả biểu đồ!

Hoạt động hàng InnoDB

Về cơ bản ở đây, tôi chỉ trích xuất các hoạt động hàng InnoDB thực hiện chọn (đọc), xóa, chèn và cập nhật. Khi số luồng tăng lên, MySQL 8.0 vượt trội hơn đáng kể so với MySQL 5.7! Cả hai phiên bản không có bất kỳ thay đổi cấu hình cụ thể nào, mà chỉ có các biến đáng chú ý mà tôi đã đặt. Vì vậy, cả hai phiên bản đều sử dụng khá nhiều giá trị mặc định.

Thật thú vị, liên quan đến tuyên bố của Nhóm máy chủ MySQL về hiệu suất đọc và ghi trong phiên bản mới, các biểu đồ chỉ ra một sự cải thiện hiệu suất đáng kể, đặc biệt là trong một máy chủ tải cao. Hãy tưởng tượng sự khác biệt giữa MySQL 5.7 so với MySQL 8.0 cho tất cả các hoạt động hàng InnoDB của nó, có sự khác biệt cao, đặc biệt là khi số lượng luồng tăng lên. MySQL 8.0 tiết lộ rằng nó có thể hoạt động hiệu quả bất kể khối lượng công việc của nó là bao nhiêu.

Các giao dịch đã được xử lý

Như thể hiện trong biểu đồ trên, hiệu suất của MySQL 8.0 lại cho thấy một sự khác biệt lớn về thời gian xử lý các giao dịch. Càng thấp, nó càng hoạt động tốt hơn, đồng nghĩa với việc xử lý giao dịch nhanh hơn. Các giao dịch được xử lý (biểu đồ thứ hai) cũng tiết lộ rằng cả hai số lượng giao dịch không khác nhau. Có nghĩa là, cả hai phiên bản đều thực hiện số lượng giao dịch gần như giống nhau nhưng khác nhau về tốc độ hoàn thành. Mặc dù tôi có thể nói, MySQL 5.7 vẫn có thể xử lý rất nhiều ở mức tải thấp hơn, nhưng tải thực tế, đặc biệt là trong quá trình sản xuất có thể sẽ cao hơn - đặc biệt là giai đoạn bận rộn nhất.

Biểu đồ trên vẫn hiển thị các giao dịch mà nó có thể xử lý nhưng tách biệt việc đọc và ghi. Tuy nhiên, thực sự có những ngoại lệ trong biểu đồ mà tôi không đưa vào vì chúng là những mảnh nhỏ của kết quả sẽ làm sai lệch biểu đồ.

MySQL 8.0 cho thấy một cải tiến tuyệt vời, đặc biệt là cho việc đọc. Nó hiển thị hiệu quả của nó trong việc ghi, đặc biệt là đối với các máy chủ có khối lượng công việc cao. Một số hỗ trợ bổ sung tuyệt vời ảnh hưởng đến hiệu suất MySQL cho các lần đọc trong phiên bản 8.0 là khả năng tạo chỉ mục theo thứ tự giảm dần (hoặc quét chỉ mục chuyển tiếp). Các phiên bản trước chỉ có quét chỉ mục tăng dần hoặc ngược và MySQL phải thực hiện sắp xếp tệp nếu nó cần thứ tự giảm dần (nếu cần tệp phân loại, bạn có thể cân nhắc kiểm tra giá trị của max_length_for_sort_data). Các chỉ mục giảm dần cũng giúp trình tối ưu hóa có thể sử dụng các chỉ mục nhiều cột khi thứ tự quét hiệu quả nhất kết hợp thứ tự tăng dần cho một số cột và thứ tự giảm dần cho những cột khác. Xem tại đây để biết thêm chi tiết.

Tài nguyên CPU

Trong quá trình đo điểm chuẩn này, tôi quyết định sử dụng một số tài nguyên phần cứng, đáng chú ý nhất là việc sử dụng CPU.

Trước tiên, hãy để tôi giải thích cách tôi lấy tài nguyên CPU ở đây trong quá trình đo điểm chuẩn. sysbench không bao gồm thống kê tập thể cho các tài nguyên phần cứng được sử dụng hoặc được sử dụng trong quá trình bạn đang đo điểm chuẩn cho cơ sở dữ liệu. Do đó, những gì tôi đã làm là tạo cờ bằng cách tạo một tệp, kết nối với máy chủ đích thông qua SSH, sau đó thu thập dữ liệu từ lệnh Linux “top” và phân tích cú pháp nó trong khi ngủ trong một giây trước khi thu thập lại. Sau đó, lấy mức sử dụng CPU tăng đáng kể nhất cho quá trình mysqld và sau đó xóa tệp cờ. Bạn có thể xem lại mã mà tôi có trong github.

Vì vậy, chúng ta hãy thảo luận lại về kết quả biểu đồ, có vẻ như cho thấy rằng MySQL 8.0 tiêu thụ rất nhiều CPU. Nhiều hơn MySQL 5.7. Tuy nhiên, nó có thể phải xử lý các biến mới được thêm vào MySQL 8.0. Ví dụ:các biến này có thể ảnh hưởng đến máy chủ MySQL 8.0 của bạn:

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

Các biến có giá trị của nó được để lại bởi các giá trị mặc định của nó cho điểm chuẩn này. Ba biến đầu tiên xử lý CPU để làm lại quá trình ghi nhật ký, trong MySQL 8.0 là một cải tiến do thiết kế lại cách InnoDB ghi vào nhật ký REDO. Biến innodb_log_spin_cpu_pct_hwm có ái lực với CPU, có nghĩa là nó sẽ bỏ qua các lõi CPU khác nếu chẳng hạn như mysqld chỉ được ghim vào 4 lõi. Đối với các luồng đọc song song, trong MySQL 8.0, nó thêm một biến mới để bạn có thể điều chỉnh số lượng luồng được sử dụng.

Tuy nhiên, tôi đã không đào sâu hơn vào chủ đề này. Có thể có nhiều cách để cải thiện hiệu suất bằng cách tận dụng các tính năng mà MySQL 8.0 cung cấp.

Kết luận

Có rất nhiều cải tiến có trong MySQL 8.0. Kết quả điểm chuẩn cho thấy đã có một cải tiến ấn tượng, không chỉ về quản lý khối lượng công việc đọc mà còn về khối lượng công việc đọc / ghi cao so với MySQL 5.7.

Xem qua các tính năng mới của MySQL 8.0, có vẻ như nó đã tận dụng các công nghệ cập nhật nhất không chỉ trên phần mềm (như cải tiến tuyệt vời cho Memcached, Quản lý từ xa để DevOps hoạt động tốt hơn, v.v.) nhưng cũng trong phần cứng. Lấy ví dụ, thay thế latin1 bằng UTF8MB4 làm mã hóa ký tự mặc định. Điều này có nghĩa là nó sẽ yêu cầu nhiều dung lượng đĩa hơn vì UTF8 cần 2 byte trên các ký tự không phải US-ASCII. Mặc dù điểm chuẩn này không tận dụng được lợi thế của việc sử dụng phương pháp xác thực mới với caching_sha2_password, nhưng nó sẽ không ảnh hưởng đến hiệu suất cho dù nó có sử dụng mã hóa hay không. Sau khi được xác thực, nó sẽ được lưu trữ trong bộ nhớ cache, nghĩa là quá trình xác thực chỉ được thực hiện một lần. Vì vậy, nếu bạn đang sử dụng một người dùng cho khách hàng của mình, điều đó sẽ không thành vấn đề và an toàn hơn các phiên bản trước.

Vì MySQL tận dụng phần cứng và phần mềm cập nhật nhất, nên nó sẽ thay đổi các biến mặc định của nó. Bạn có thể đọc ở đây để biết thêm chi tiết.

Nhìn chung, MySQL 8.0 đã thống trị MySQL 5.7 một cách hiệu quả.