MySQL प्रदर्शन बेंचमार्किंग:MySQL 5.7 बनाम MySQL 8.0

MySQL 8.0 भारी परिवर्तन और संशोधन लाया जो Oracle MySQL टीम द्वारा आगे बढ़ाया गया था। भौतिक फ़ाइलें बदल दी गई हैं। उदाहरण के लिए, *.frm, *.TRG, *.TRN, और *.par अब मौजूद नहीं हैं। सीटीई (कॉमन टेबल एक्सप्रेशंस), विंडो फंक्शंस, इनविजिबल इंडेक्स, रेगेक्सपी (या रेगुलर एक्सप्रेशन) जैसी कई नई सुविधाओं को जोड़ा गया है - बाद वाले को बदल दिया गया है और अब पूर्ण यूनिकोड समर्थन प्रदान करता है और मल्टीबाइट सुरक्षित है। डेटा डिक्शनरी भी बदल गई है। इसे अब एक ट्रांजेक्शनल डेटा डिक्शनरी के साथ शामिल किया गया है जो डेटाबेस ऑब्जेक्ट्स के बारे में जानकारी संग्रहीत करता है। पिछले संस्करणों के विपरीत, शब्दकोश डेटा मेटाडेटा फ़ाइलों और गैर-लेनदेन तालिकाओं में संग्रहीत किया गया था। caching_sha2_password के नए जोड़े के साथ सुरक्षा में सुधार किया गया है जो अब mysql_native_password की जगह डिफ़ॉल्ट प्रमाणीकरण है और अधिक लचीलापन लेकिन कड़ी सुरक्षा प्रदान करता है जिसे एक सुरक्षित कनेक्शन या एक अनएन्क्रिप्टेड कनेक्शन का उपयोग करना चाहिए जो RSA कुंजी जोड़ी का उपयोग करके पासवर्ड एक्सचेंज का समर्थन करता है।

इन सभी शानदार सुविधाओं, एन्हांसमेंट्स, सुधारों के साथ, जो MySQL 8.0 प्रदान करता है, हमारी टीम यह निर्धारित करने में रुचि रखती थी कि वर्तमान संस्करण MySQL 8.0 कितना अच्छा प्रदर्शन करता है, विशेष रूप से यह देखते हुए कि ClusterControl में MySQL 8.0.x संस्करणों के लिए हमारा समर्थन जारी है (इसलिए बने रहें) इस पर)। यह ब्लॉग पोस्ट MySQL 8.0 की विशेषताओं पर चर्चा नहीं करेगा, लेकिन MySQL 5.7 के खिलाफ इसके प्रदर्शन को बेंचमार्क करने का इरादा रखता है और देखें कि यह कैसे सुधार हुआ है।

सर्वर सेटअप और पर्यावरण

इस बेंचमार्क के लिए, मैं निम्नलिखित AWS EC2 वातावरण का उपयोग करके उत्पादन के लिए न्यूनतम सेटअप का उपयोग करने का इरादा रखता हूं:

इंस्टेंस-प्रकार:t2.xlarge उदाहरण
संग्रहण:gp2 (न्यूनतम 100 और अधिकतम 16000 IOPS के साथ SSD संग्रहण)
vCPUS:4
मेमोरी:16GiB
MySQL 5.7 संस्करण:MySQL कम्युनिटी सर्वर (GPL) 5.7.24
MySQL 8.0 वर्जन:MySQL कम्युनिटी सर्वर - GPL 8.0.14

कुछ उल्लेखनीय चर हैं जिन्हें मैंने इस बेंचमार्क के लिए भी निर्धारित किया है, जो हैं:

innodb_max_dirty_pages_pct =90 ## यह MySQL 8.0 में डिफ़ॉल्ट मान है। विवरण के लिए यहां देखें।
innodb_max_dirty_pages_pct_lwm=10 ## यह MySQL 8.0 में डिफ़ॉल्ट मान है
innodb_flush_neighbors=0
innodb_buffer_pool_instances=8
innodb_buffer_pool_size=8GiB

दोनों संस्करणों (MySQL 5.7 और MySQL 8.0) के लिए यहां सेट किए जा रहे बाकी चर पहले से ही अपने my.cnf टेम्पलेट के लिए ClusterControl द्वारा ट्यून किए गए हैं।

साथ ही, मैंने यहां इस्तेमाल किया उपयोगकर्ता MySQL 8.0 के नए प्रमाणीकरण के अनुरूप नहीं है जो caching_sha2_password का उपयोग करता है। इसके बजाय, दोनों सर्वर संस्करण mysql_native_password प्लस innodb_dedicated_server चर OFF (डिफ़ॉल्ट) का उपयोग करते हैं, जो कि MySQL 8.0 की एक नई विशेषता है।

जीवन को आसान बनाने के लिए, मैंने एक अलग होस्ट से क्लस्टरकंट्रोल के साथ MySQL 5.7 सामुदायिक संस्करण नोड को सेटअप किया और फिर क्लस्टर में नोड को हटा दिया और MySQL 5.7 नोड को निष्क्रिय (कोई निगरानी ट्रैफ़िक नहीं) बनाने के लिए ClusterControl होस्ट को बंद कर दिया। तकनीकी रूप से, दोनों नोड्स MySQL 5.7 और MySQL 8.0 निष्क्रिय हैं और कोई भी सक्रिय कनेक्शन नोड्स से नहीं गुजर रहा है, इसलिए यह अनिवार्य रूप से एक शुद्ध बेंचमार्किंग परीक्षण है।

प्रयुक्त कमांड और स्क्रिप्ट

इस कार्य के लिए, दो वातावरणों के लिए परीक्षण और लोड सिमुलेशन के लिए sysbench का उपयोग किया जाता है। इस परीक्षण में निम्नलिखित कमांड या स्क्रिप्ट का उपयोग किया जा रहा है:

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

तो स्क्रिप्ट बस sbtest स्कीमा तैयार करती है और टेबल और रिकॉर्ड को पॉप्युलेट करती है। फिर यह /usr/share/sysbench/oltp_read_write.lua स्क्रिप्ट का उपयोग करके रीड/राइट लोड टेस्ट करता है। स्क्रिप्ट वैश्विक स्थिति और MySQL चर को डंप करती है, CPU उपयोग एकत्र करती है, और स्क्रिप्ट innodb-ops-parser.py द्वारा संचालित InnoDB पंक्ति संचालन को पार्स करती है। तब स्क्रिप्ट बेंचमार्क के दौरान एकत्र किए गए डंप किए गए लॉग के आधार पर *.csv फ़ाइलें जेनरेट करती हैं, फिर मैंने *.csv फ़ाइलों से ग्राफ़ जेनरेट करने के लिए यहां एक एक्सेल स्प्रेडशीट का उपयोग किया। कृपया इस जीथब रिपोजिटरी में कोड यहां देखें।

अब, ग्राफ़ परिणामों के साथ आगे बढ़ते हैं!

InnoDB पंक्ति संचालन

मूल रूप से यहाँ, मैंने केवल InnoDB पंक्ति संचालन को निकाला है जो चयन (पढ़ता है), हटाता है, सम्मिलित करता है और अद्यतन करता है। जब थ्रेड्स की संख्या बढ़ जाती है, तो MySQL 8.0 MySQL 5.7 से काफी बेहतर प्रदर्शन करता है! दोनों संस्करणों में कोई विशिष्ट कॉन्फ़िगरेशन परिवर्तन नहीं है, लेकिन केवल मेरे द्वारा निर्धारित उल्लेखनीय चर हैं। इसलिए दोनों संस्करण काफी हद तक डिफ़ॉल्ट मानों का उपयोग कर रहे हैं।

दिलचस्प है, नए संस्करण में पढ़ने और लिखने के प्रदर्शन के बारे में MySQL सर्वर टीम के दावों के संबंध में, ग्राफ़ एक महत्वपूर्ण प्रदर्शन सुधार की ओर इशारा करते हैं, विशेष रूप से एक उच्च-लोड सर्वर में। अपने सभी InnoDB पंक्ति संचालन के लिए MySQL 5.7 बनाम MySQL 8.0 के बीच अंतर की कल्पना करें, विशेष रूप से थ्रेड्स की संख्या बढ़ने पर एक उच्च अंतर होता है। MySQL 8.0 से पता चलता है कि यह अपने कार्यभार की परवाह किए बिना कुशलता से प्रदर्शन कर सकता है।

लेन-देन संसाधित

जैसा कि ऊपर दिए गए ग्राफ में दिखाया गया है, MySQL 8.0 का प्रदर्शन लेनदेन को संसाधित करने में लगने वाले समय में फिर से एक बड़ा अंतर दिखाता है। यह जितना कम होगा, उतना ही बेहतर प्रदर्शन करेगा, जिसका अर्थ है कि लेनदेन को संसाधित करना तेज़ है। संसाधित लेनदेन (दूसरा ग्राफ) से यह भी पता चलता है कि लेनदेन की दोनों संख्याएं एक दूसरे से भिन्न नहीं हैं। मतलब, दोनों संस्करण लगभग समान संख्या में लेन-देन निष्पादित करते हैं लेकिन यह भिन्न होता है कि यह कितनी तेजी से समाप्त हो सकता है। हालांकि मैं कह सकता हूं, MySQL 5.7 अभी भी कम लोड पर बहुत कुछ संभाल सकता है, लेकिन विशेष रूप से उत्पादन में यथार्थवादी लोड अधिक होने की उम्मीद की जा सकती है - विशेष रूप से सबसे व्यस्त अवधि।

ऊपर दिया गया ग्राफ़ अभी भी उन लेन-देन को दिखाता है जो इसे संसाधित करने में सक्षम थे लेकिन पढ़ने को लिखने से अलग करते हैं। हालाँकि, ग्राफ़ में वास्तव में आउटलेयर हैं जिन्हें मैंने शामिल नहीं किया क्योंकि वे परिणाम के छोटे-छोटे संकेत हैं जो ग्राफ़ को तिरछा कर देंगे।

MySQL 8.0 विशेष रूप से पढ़ने के लिए एक महान सुधार दिखाता है। यह विशेष रूप से उच्च कार्यभार वाले सर्वरों के लिए लेखन में अपनी दक्षता प्रदर्शित करता है। संस्करण 8.0 में पढ़ने के लिए MySQL के प्रदर्शन को प्रभावित करने वाले कुछ बेहतरीन अतिरिक्त समर्थन अवरोही क्रम (या फॉरवर्ड इंडेक्स स्कैन) में एक इंडेक्स बनाने की क्षमता है। पिछले संस्करणों में केवल आरोही या पिछड़ा सूचकांक स्कैन था, और यदि MySQL को अवरोही क्रम की आवश्यकता होती है तो उसे फाइलसॉर्ट करना पड़ता था (यदि फाइलसॉर्ट की आवश्यकता है, तो आप max_length_for_sort_data के मान की जांच करने पर विचार कर सकते हैं)। अवरोही अनुक्रमणिका ऑप्टिमाइज़र के लिए बहु-स्तंभ अनुक्रमणिका का उपयोग करना भी संभव बनाती है जब सबसे कुशल स्कैन क्रम कुछ स्तंभों के लिए आरोही क्रम और दूसरों के लिए अवरोही क्रम को मिलाता है। अधिक विवरण के लिए यहां देखें।

CPU संसाधन

इस बेंचमार्किंग के दौरान, मैंने कुछ हार्डवेयर संसाधनों को लेने का फैसला किया, विशेष रूप से, CPU उपयोग।

मैं पहले समझाता हूं कि बेंचमार्किंग के दौरान मैं यहां सीपीयू संसाधन कैसे लेता हूं। जब आप किसी डेटाबेस को बेंचमार्क कर रहे होते हैं, तो प्रक्रिया के दौरान उपयोग किए गए या उपयोग किए गए हार्डवेयर संसाधनों के लिए sysbench में सामूहिक आँकड़े शामिल नहीं होते हैं। उसके कारण, मैंने जो किया वह एक फ़ाइल बनाकर एक ध्वज बनाना है, एसएसएच के माध्यम से लक्ष्य होस्ट से कनेक्ट करना है, और फिर लिनक्स कमांड "टॉप" से डेटा काटा और फिर से इकट्ठा करने से पहले एक सेकंड के लिए सोते समय इसे पार्स करना है। उसके बाद, mysqld प्रक्रिया के लिए CPU उपयोग की सबसे उत्कृष्ट वृद्धि लें और फिर फ़्लैग फ़ाइल को हटा दें। आप जीथब में मेरे पास मौजूद कोड की समीक्षा कर सकते हैं।

तो चलिए फिर से ग्राफ़ परिणाम के बारे में चर्चा करते हैं, ऐसा लगता है कि MySQL 8.0 बहुत अधिक CPU की खपत करता है। MySQL 5.7 से अधिक। हालाँकि, इसे MySQL 8.0 में जोड़े गए नए चरों से निपटना पड़ सकता है। उदाहरण के लिए, ये चर आपके MySQL 8.0 सर्वर को प्रभावित कर सकते हैं:

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

इस बेंचमार्क के लिए इसके मानों वाले वेरिएबल को इसके डिफ़ॉल्ट मानों द्वारा छोड़ दिया जाता है। पहले तीन वेरिएबल सीपीयू को फिर से लॉगिंग के लिए संभालते हैं, जो कि MySQL 8.0 में सुधार हुआ है क्योंकि इनो डीबी रेडो लॉग को कैसे लिखता है। चर innodb_log_spin_cpu_pct_hwm में CPU आत्मीयता है, जिसका अर्थ है कि यह अन्य CPU कोर को अनदेखा कर देगा यदि mysqld को केवल 4 कोर तक पिन किया गया है, उदाहरण के लिए। समानांतर रीड थ्रेड के लिए, MySQL 8.0 में, यह एक नया वेरिएबल जोड़ता है जिसके लिए आप ट्यून कर सकते हैं कि कितने थ्रेड्स का उपयोग करना है।

हालाँकि, मैंने इस विषय में और अधिक खुदाई नहीं की। MySQL 8.0 द्वारा पेश की जाने वाली सुविधाओं का लाभ उठाकर प्रदर्शन में सुधार के तरीके हो सकते हैं।

निष्कर्ष

MySQL 8.0 में बहुत सारे सुधार मौजूद हैं। बेंचमार्क परिणामों से पता चलता है कि न केवल रीड वर्कलोड को प्रबंधित करने पर, बल्कि MySQL 5.7 की तुलना में उच्च रीड/राइट वर्कलोड पर भी प्रभावशाली सुधार हुआ है।

MySQL 8.0 की नई सुविधाओं पर जाकर, ऐसा लगता है कि इसने न केवल सॉफ़्टवेयर पर सबसे अद्यतित तकनीकों का लाभ उठाया है (जैसे मेमकैच्ड के लिए महान सुधार, बेहतर DevOps कार्य के लिए दूरस्थ प्रबंधन, आदि) लेकिन हार्डवेयर में भी। उदाहरण के लिए, latin1 को UTF8MB4 के साथ डिफ़ॉल्ट वर्ण एन्कोडिंग के रूप में प्रतिस्थापित किया जाता है। इसका मतलब यह होगा कि इसे अधिक डिस्क स्थान की आवश्यकता होगी क्योंकि UTF8 को गैर-US-ASCII वर्णों पर 2-बाइट्स की आवश्यकता होती है। हालांकि इस बेंचमार्क ने caching_sha2_password के साथ नई प्रमाणीकरण पद्धति का उपयोग करने का लाभ नहीं उठाया, लेकिन यह एन्क्रिप्शन का उपयोग करता है या नहीं, यह प्रदर्शन को प्रभावित नहीं करेगा। एक बार प्रमाणित होने के बाद, इसे कैश में संग्रहीत किया जाता है जिसका अर्थ है कि प्रमाणीकरण केवल एक बार किया जाता है। इसलिए यदि आप अपने क्लाइंट के लिए एक उपयोगकर्ता का उपयोग कर रहे हैं, तो यह कोई समस्या नहीं होगी और पिछले संस्करणों की तुलना में अधिक सुरक्षित है।

चूंकि MySQL सबसे अप-टू-डेट हार्डवेयर और सॉफ़्टवेयर का लाभ उठाता है, इसलिए यह अपने डिफ़ॉल्ट वेरिएबल्स को बदल देता है। अधिक विवरण के लिए आप यहां पढ़ सकते हैं।

कुल मिलाकर, MySQL 8.0, MySQL 5.7 पर प्रभावी रूप से हावी है।