एक क्वेरी आउटलेयर क्या है और इसे कैसे ठीक करें

MySQL डेटाबेस वर्कलोड को प्रोसेस किए जाने वाले प्रश्नों की संख्या से निर्धारित किया जाता है। ऐसी कई स्थितियाँ हैं जिनमें MySQL धीमापन उत्पन्न हो सकता है। पहली संभावना यह है कि यदि कोई प्रश्न हैं जो उचित अनुक्रमण का उपयोग नहीं कर रहे हैं। जब कोई क्वेरी किसी अनुक्रमणिका का उपयोग नहीं कर सकती है, तो MySQL सर्वर को उस क्वेरी को संसाधित करने के लिए अधिक संसाधनों और समय का उपयोग करना पड़ता है। प्रश्नों की निगरानी करके, आपके पास SQL कोड को इंगित करने की क्षमता है जो मंदी का मूल कारण है और समग्र प्रदर्शन में गिरावट आने से पहले इसे ठीक कर सकता है।

इस ब्लॉग पोस्ट में, हम ClusterControl में उपलब्ध Query Outlier फीचर को हाइलाइट करने जा रहे हैं और देखें कि यह डेटाबेस के प्रदर्शन को बेहतर बनाने में हमारी मदद कैसे कर सकता है। सामान्य तौर पर, ClusterControl दो तरह से MySQL क्वेरी सैंपलिंग करता है:

प्रदर्शन स्कीमा से क्वेरी प्राप्त करें (अनुशंसित )।
MySQL स्लो क्वेरी की सामग्री को पार्स करें।

यदि प्रदर्शन स्कीमा अक्षम है, तो ClusterControl स्लो क्वेरी लॉग में डिफ़ॉल्ट हो जाएगा। ClusterControl इसे कैसे करता है, इस बारे में अधिक जानने के लिए, इस ब्लॉग पोस्ट को देखें, MySQL, MariaDB और Percona सर्वर के लिए ClusterControl Query Monitor का उपयोग कैसे करें।

क्वेरी आउटलेयर क्या हैं?

एक बाहरी एक क्वेरी है जो उस प्रकार के सामान्य क्वेरी समय से अधिक समय लेती है। इसे शाब्दिक रूप से "खराब तरीके से लिखे गए" प्रश्नों के रूप में न लें। इसे संभावित उप-इष्टतम सामान्य प्रश्नों के रूप में माना जाना चाहिए जिन्हें सुधारा जा सकता है। कई नमूनों के बाद और जब ClusterControl के पास पर्याप्त आँकड़े हों, तो यह निर्धारित कर सकता है कि विलंबता सामान्य से अधिक है (2 सिग्मा + औसत_क्वेरी_टाइम) तो यह एक बाहरी है और इसे क्वेरी आउटलेयर में जोड़ा जाएगा।

यह सुविधा शीर्ष क्वेरी सुविधा पर निर्भर है। यदि क्वेरी मॉनिटरिंग सक्षम है और शीर्ष क्वेरी को कैप्चर और पॉप्युलेट किया जाता है, तो क्वेरी आउटलेयर इन्हें सारांशित करेंगे और टाइमस्टैम्प के आधार पर एक फ़िल्टर प्रदान करेंगे। उन प्रश्नों की सूची देखने के लिए जिन पर ध्यान देने की आवश्यकता है, ClusterControl -> Query Monitor -> Query Outliers पर जाएं और कुछ प्रश्नों को सूचीबद्ध (यदि कोई हो) देखना चाहिए:

जैसा कि आप ऊपर दिए गए स्क्रीनशॉट से देख सकते हैं, आउटलेयर मूल रूप से क्वेरी हैं जो औसत क्वेरी समय से कम से कम 2 गुना अधिक समय लगा। पहली पहली प्रविष्टि, औसत समय 34.41 एमएस है जबकि बाहरी का क्वेरी समय 140 एमएस (औसत समय से 2 गुना अधिक) है। इसी तरह, अगली प्रविष्टियों के लिए, क्वेरी समय और औसत क्वेरी समय कॉलम किसी विशेष बाहरी क्वेरी के बकाया को सही ठहराने के लिए दो महत्वपूर्ण चीजें हैं।

एक सप्ताह पहले की तरह बड़ी समयावधि को देखकर किसी विशेष क्वेरी के पैटर्न को बाहरी रूप से खोजना अपेक्षाकृत आसान है, जैसा कि निम्न स्क्रीनशॉट में हाइलाइट किया गया है:

प्रत्येक पंक्ति पर क्लिक करके, आप पूरी क्वेरी देख सकते हैं जो वास्तव में है समस्या को इंगित करने और समझने में मददगार, जैसा कि अगले भाग में दिखाया गया है।

क्वेरी आउटलेर्स को ठीक करना

आउटलेर्स को ठीक करने के लिए, हमें क्वेरी की प्रकृति, टेबल के स्टोरेज इंजन, डेटाबेस वर्जन, क्लस्टरिंग प्रकार और क्वेरी कितनी प्रभावशाली है, इसे समझने की जरूरत है। कुछ मामलों में, बाहरी क्वेरी वास्तव में समग्र डेटाबेस प्रदर्शन के लिए अपमानजनक नहीं है। जैसा कि इस उदाहरण में, हमने देखा है कि क्वेरी पूरे सप्ताह के लिए खड़ी रही है और यह एकमात्र क्वेरी प्रकार थी जिसे कैप्चर किया जा रहा था, इसलिए यदि संभव हो तो इस क्वेरी को ठीक करना या सुधारना एक अच्छा विचार है।

जैसा कि हमारे मामले में, बाहरी क्वेरी है:

SELECT i2l.country_code AS country_code, i2l.country_name AS country_name 
FROM ip2location i2l 
WHERE (i2l.ip_to >= INET_ATON('104.144.171.139') 
AND i2l.ip_from <= INET_ATON('104.144.171.139')) 
LIMIT 1 
OFFSET 0;

और क्वेरी का परिणाम है:

+--------------+---------------+
| country_code | country_name  |
+--------------+---------------+
| US           | United States |
+--------------+---------------+

EXPLAIN का उपयोग करना

तालिका ip2location पर किसी IP पते के लिए उपयोगकर्ता की भौगोलिक स्थिति की जानकारी (देश कोड और देश का नाम) निर्धारित करने के लिए क्वेरी केवल-पढ़ने के लिए श्रेणी चयन क्वेरी है। EXPLAIN कथन का उपयोग करने से हमें क्वेरी निष्पादन योजना को समझने में मदद मिल सकती है:

mysql> EXPLAIN SELECT i2l.country_code AS country_code, i2l.country_name AS country_name 
FROM ip2location i2l 
WHERE (i2l.ip_to>=INET_ATON('104.144.171.139') 
AND i2l.ip_from<=INET_ATON('104.144.171.139')) 
LIMIT 1 OFFSET 0;
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys                        | key         | key_len | ref  | rows  | filtered | Extra                              |
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+
|  1 | SIMPLE      | i2l   | NULL       | range | idx_ip_from,idx_ip_to,idx_ip_from_to | idx_ip_from | 5       | NULL | 66043 |    50.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+

क्वेरी को 50% संभावित पंक्तियों (फ़िल्टर किए गए) के साथ इंडेक्स idx_ip_from का उपयोग करके टेबल पर रेंज स्कैन के साथ निष्पादित किया जाता है।

उचित संग्रहण इंजन

ip2 स्थान की तालिका संरचना को देखते हुए:

mysql> SHOW CREATE TABLE ip2location\G
*************************** 1. row ***************************
       Table: ip2location
Create Table: CREATE TABLE `ip2location` (
  `ip_from` int(10) unsigned DEFAULT NULL,
  `ip_to` int(10) unsigned DEFAULT NULL,
  `country_code` char(2) COLLATE utf8_bin DEFAULT NULL,
  `country_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  KEY `idx_ip_from` (`ip_from`),
  KEY `idx_ip_to` (`ip_to`),
  KEY `idx_ip_from_to` (`ip_from`,`ip_to`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

यह तालिका IP2 स्थान डेटाबेस पर आधारित है और इसे शायद ही कभी अपडेट/लिखा जाता है, आमतौर पर केवल कैलेंडर माह के पहले दिन (विक्रेता द्वारा अनुशंसित)। तो एक विकल्प तालिका को MyISAM (MySQL) या Aria (MariaDB) स्टोरेज इंजन में निश्चित पंक्ति प्रारूप के साथ बेहतर रीड-ओनली प्रदर्शन प्राप्त करने के लिए परिवर्तित करना है। ध्यान दें कि यह केवल तभी लागू होता है जब आप MySQL या MariaDB स्टैंडअलोन या प्रतिकृति पर चल रहे हों। Galera Cluster और Group Replication पर, कृपया InnoDB स्टोरेज इंजन से चिपके रहें (जब तक कि आप नहीं जानते कि आप क्या कर रहे हैं)।

वैसे भी, तालिका को InnoDB से MyISAM में निश्चित पंक्ति प्रारूप में बदलने के लिए, बस निम्नलिखित कमांड चलाएँ:

ALTER TABLE ip2location ENGINE=MyISAM ROW_FORMAT=FIXED;

हमारे माप में, 1000 रैंडम आईपी एड्रेस लुकअप परीक्षणों के साथ, MyISAM और निश्चित पंक्ति प्रारूप के साथ क्वेरी प्रदर्शन में लगभग 20% सुधार हुआ:

औसत समय (InnoDB):21.467823 ms
औसत समय (MyISAM निश्चित):17.175942 ms
सुधार:19.9921575555301%

आप उम्मीद कर सकते हैं कि यह परिणाम तालिका में बदलाव के तुरंत बाद होगा। उच्च स्तरीय (एप्लिकेशन/लोड बैलेंसर) पर कोई संशोधन आवश्यक नहीं है।

क्वेरी को ट्यून करना

दूसरा तरीका है क्वेरी योजना का निरीक्षण करना और बेहतर क्वेरी निष्पादन योजना के लिए अधिक कुशल दृष्टिकोण का उपयोग करना। नीचे दिए गए सबक्वेरी का उपयोग करके वही प्रश्न भी लिखा जा सकता है:

SELECT `country_code`, `country_name` FROM 
  (SELECT `country_code`, `country_name`, `ip_from` 
   FROM `ip2location` 
   WHERE ip_to >= INET_ATON('104.144.171.139') 
   LIMIT 1) 
AS temptable 
WHERE ip_from <= INET_ATON('104.144.171.139');

ट्यून की गई क्वेरी में निम्न क्वेरी निष्पादन योजना है:

mysql> EXPLAIN SELECT `country_code`,`country_name` FROM 
(SELECT `country_code`, `country_name`, `ip_from` 
FROM `ip2location` 
WHERE ip_to >= INET_ATON('104.144.171.139') 
LIMIT 1) 
AS temptable 
WHERE ip_from <= INET_ATON('104.144.171.139');
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+
| id | select_type | table        | partitions | type   | possible_keys | key       | key_len | ref  | rows  | filtered | Extra                 |
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+
|  1 | PRIMARY     | <derived2>   | NULL       | system | NULL          | NULL      | NULL    | NULL |     1 |   100.00 | NULL                  |
|  2 | DERIVED     | ip2location  | NULL       | range  | idx_ip_to     | idx_ip_to | 5       | NULL | 66380 |   100.00 | Using index condition |
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+

सबक्वायरी का उपयोग करके, हम एक इंडेक्स पर केंद्रित व्युत्पन्न तालिका का उपयोग करके क्वेरी को ऑप्टिमाइज़ कर सकते हैं। क्वेरी को केवल 1 रिकॉर्ड वापस करना चाहिए जहां ip_to मान IP पता मान से अधिक या उसके बराबर है। यह संभावित पंक्तियों (फ़िल्टर किए गए) को 100% तक पहुंचने की अनुमति देता है जो सबसे कुशल है। फिर, जांचें कि ip_from IP पता मान से कम या उसके बराबर है। अगर ऐसा है, तो हमें रिकॉर्ड ढूंढना चाहिए। अन्यथा, IP पता ip2 स्थान तालिका में मौजूद नहीं है।

हमारे मापन में, एक सबक्वेरी का उपयोग करके क्वेरी के प्रदर्शन में लगभग 99% सुधार हुआ:

औसत समय (InnoDB + रेंज स्कैन):22.87112 ms
औसत समय (InnoDB + सबक्वेरी):0.14744 ms
सुधार:99.355344207017 %

उपरोक्त अनुकूलन के साथ, हम इस प्रकार की क्वेरी का उप-मिलीसेकंड क्वेरी निष्पादन समय देख सकते हैं, जो कि पिछले औसत समय 22 एमएस को देखते हुए एक बड़ा सुधार है। हालांकि, इस ट्यून की गई क्वेरी से लाभ उठाने के लिए हमें उच्च स्तरीय (एप्लिकेशन/लोड बैलेंसर) में कुछ संशोधन करने की आवश्यकता है।

पैचिंग या क्वेरी पुनर्लेखन

ट्यून की गई क्वेरी का उपयोग करने के लिए अपने एप्लिकेशन को पैच करें या डेटाबेस सर्वर तक पहुंचने से पहले बाहरी क्वेरी को फिर से लिखें। हम इसे MySQL लोड बैलेंसर जैसे ProxySQL (क्वेरी रूल्स) या MariaDB MaxScale (स्टेटमेंट रीराइटिंग फिल्टर) या MySQL Query Rewriter प्लगइन का उपयोग करके प्राप्त कर सकते हैं। निम्नलिखित उदाहरण में, हम अपने डेटाबेस क्लस्टर के सामने ProxySQL का उपयोग करते हैं और हम धीमी क्वेरी को तेज़ क्वेरी में फिर से लिखने के लिए बस एक नियम बना सकते हैं, उदाहरण के लिए:

क्वेरी रूल सेव करें और ClusterControl में क्वेरी आउटलायर्स पेज को मॉनिटर करें। क्वेरी नियम सक्रिय होने के बाद यह सुधार स्पष्ट रूप से सूची से बाहरी प्रश्नों को हटा देगा।

निष्कर्ष

क्वेरी आउटलेयर एक सक्रिय क्वेरी मॉनिटरिंग टूल है जो नियंत्रण से बाहर होने से पहले प्रदर्शन समस्या को समझने और ठीक करने में हमारी सहायता कर सकता है। जैसे-जैसे आपका एप्लिकेशन बढ़ता है और अधिक मांग वाला होता जाता है, यह टूल आपको एक अच्छा डेटाबेस प्रदर्शन बनाए रखने में मदद कर सकता है।