प्रश्न ट्यूनिंग सक्रिय या प्रतिक्रियाशील होना चाहिए?


23

एक सॉफ्टवेयर डेवलपर और एक महत्वाकांक्षी डीबीए के रूप में, मैं अपने एसक्यूएल सर्वर डेटाबेस (जब मेरा सॉफ्टवेयर एसक्यूएल सर्वर के शीर्ष पर बैठता है) का 99% डिजाइन करते समय सर्वोत्तम प्रथाओं को पुन: स्थापित करने का प्रयास करता है। मैं विकास से पहले और उसके दौरान सबसे अच्छा संभव डिजाइन बनाता हूं।

लेकिन, किसी भी अन्य सॉफ्टवेयर डेवलपर की तरह, इसमें जोड़ा गया कार्यशीलता, बग्स, और बस आवश्यकताओं में बदलाव है जो डेटाबेस ऑब्जेक्ट्स को बदल / निर्मित करता है।

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

या मुझे बस इस बात की जानकारी होनी चाहिए कि कम-से-औसत प्रदर्शन एक डेटाबेस चेक होना चाहिए और लौकिक चाकबोर्ड पर वापस जाना चाहिए?

क्वेरी ट्यूनिंग में बहुत समय लग सकता है, और प्रारंभिक डेटाबेस डिजाइन के आधार पर यह न्यूनतम लाभ हो सकता है। मैं स्वीकृत मोडस ऑपरेंडी के लिए उत्सुक हूं।


7
समयपूर्व अनुकूलन सभी बुराई की जड़ है - डोनाल्डकंट
21

@Drasill, क्या आप उस पर विस्तार कर सकते हैं? व्यर्थ देव समय के रूप में बुराई?
थॉमस स्ट्रिंगर

वास्तव में आपके प्रश्न ने मुझे इस प्रसिद्ध उद्धरण के बारे में सोचा ( Google देखें )। लेकिन यह सॉफ्टवेयर विकास के उद्देश्य से अधिक है, मुझे लगता है कि यह वास्तव में डीबीए फिट नहीं है। अंत में, मैं खुद कहूंगा कि "समय से पहले सूक्ष्म अनुकूलन बुराई है"।
ड्रिल सिप

इस विषय पर एक पुरानी कोडिंग डरावनी पोस्ट भी देखें :)
Drasill

जवाबों:


17

दोनों, लेकिन ज्यादातर सक्रिय

यथार्थवादी संस्करणों और डेटा की गुणवत्ता के खिलाफ विकास के दौरान परीक्षण करना महत्वपूर्ण है। यह अविश्वसनीय रूप से सामान्य है कि एक डेवलपर्स 100 या 1000 पंक्तियों पर चल रहा है, फिर 10 मिलियन उत्पादन पंक्तियों के साथ सपाट हो।

यह आपको "सूचकांक यहां मदद कर सकता है" के बारे में भी नोट्स बनाने की अनुमति देता है। या "मुझे फिर से आना"। या "अगले DB संस्करण में नई सुविधा xxx के साथ ठीक कर देगा"।

हालाँकि, कुछ प्रश्न समय की कसौटी पर खरे नहीं उतरेंगे। डेटा वितरण बदल जाता है या यह घातांक हो जाता है क्योंकि ऑप्टिमाइज़र एक अलग सम्मिलित प्रकार का उपयोग करने का निर्णय लेता है। इस मामले में, आप केवल प्रतिक्रिया कर सकते हैं।

यह कहते हुए कि, SQL सर्वर के लिए, कम से कम, विभिन्न "लापता सूचकांक" और "सबसे लंबी क्वेरी" DMV क्वेरी फ़ोन कॉल के दौरान समस्या क्षेत्रों को इंगित कर सकते हैं

संपादित करें: स्पष्ट करने के लिए ...

प्रोएक्टिव का मतलब अब हर क्वेरी को ट्यून करना नहीं है। इसका मतलब यह है कि एक उचित प्रतिक्रिया समय के लिए आपको (अक्सर चलाने की) क्या जरूरत है। अधिकतर साप्ताहिक 3 रविवार की रिपोर्ट प्रश्नों को अनदेखा करते हैं।


16

ठीक है, मैं काटता हूँ और एक विरोधाभासी दृश्य लेता हूँ। सबसे पहले, मैं कहूंगा कि आपको कभी भी कुछ ऐसा नहीं करना चाहिए जो आपको पता हो कि आपको परेशानी में ले जाएगा। यदि आप इसे लागू करने वाली सर्वोत्तम प्रथाओं को कॉल करना चाहते हैं, तो आगे बढ़ें। जहाँ तक प्रोएक्टिव होना चाहिए, यह है।

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

जब आपको पता चलता है कि कुछ आपके डिज़ाइन स्पेक्स पर काम नहीं कर रहा है, या यदि कोई चीज़ आपके प्रोफाइलर की प्रतिक्रिया समय की सूची के 10% या 20% से नीचे आ रही है, तो उस समय का निवेश करें, जो कुछ भी हो टूटा हुआ।

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


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

4
हारून, सहमत - प्रदर्शन-वार को बेकार करने वाले और प्रदर्शन और स्केलेबिलिटी के बारे में कठिन विचार किए बिना कुछ बनाने और चार्ज न करने वाली किसी भी चीज़ को कभी भी वितरित न करें। "दो बार मापें, एक बार काटें" प्रोग्रामर के बम्पर स्टिकर पर निर्भर करता है जितना कि यह बढ़ई पर होता है। उसी समय, मैंने महसूस किया कि अन्य उत्तरों का सामान्य टेनर "प्रोएक्टिव> रिएक्टिव" था और मैंने महसूस किया कि एक अंडर-रिप्रेजेंटेड राय थी कि "रियलिटी == रिएक्टिव" और इसलिए कुंजी इतना समय बर्बाद करने के लिए नहीं है सक्रिय होने के नाते कि आपके पास कठोर, अक्सर अप्रत्याशित वास्तविकताओं से निपटने के लिए समय या धन नहीं बचा है।
जोएल ब्राउन

15

आप 3 प्रकार के ट्यूनिंग करने जा रहे हैं, 1 प्रतिक्रियाशील और 2 सक्रिय।

रिएक्टिव

नीले रंग में से, कुछ क्वेरी आपको समस्याएँ उत्पन्न करने लगती हैं। यह एक एप्लिकेशन बग या सुविधा, अपेक्षाओं से अधिक बढ़ने वाली तालिका, ट्रैफ़िक स्पाइक या क्वेरी ऑप्टिमाइज़र के "रचनात्मक" होने के कारण हो सकता है। यह मध्य-रात्रि ओह-बकवास-के-साइट-डाउन-डाउन प्रकार का मामला हो सकता है, या यह एक गैर-महत्वपूर्ण प्रकृति के सिस्टम सुस्ती के जवाब में हो सकता है। किसी भी तरह से, प्रतिक्रियाशील ट्यूनिंग का परिभाषित चरित्र यह है कि आपके पास पहले से ही एक समस्या है । कहने की जरूरत नहीं है, आप इसे जितना संभव हो उतना कम करना चाहते हैं। जो हमें लाता है ...

सक्रिय

टाइप 1: रूटीन मेंटेनेंस

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

टाइप 2: उचित डिजाइन

"प्रीमेच्योर ऑप्टिमाइज़ेशन" के खिलाफ नथ का पालन व्यापक रूप से जाना जाता है और विधिवत सम्मानित किया जाता है। लेकिन "समय से पहले" की उचित परिभाषा का उपयोग किया जाना चाहिए। कुछ एप्लिकेशन डेवलपर्स, जब अपने स्वयं के प्रश्नों को लिखने की अनुमति दी जाती है, तो उन पर जो पहली हिट होती है, उसे तार्किक रूप से सही मानने की प्रवृत्ति अपनाने की प्रवृत्ति होती है, और प्रदर्शन, वर्तमान या भविष्य के लिए कोई भी ध्यान नहीं देना चाहिए। या वे एक विकास डेटा सेट के खिलाफ परीक्षण कर सकते हैं जो उत्पादन वातावरण का प्रतिनिधि नहीं है (टिप: ऐसा न करें! डेवलपर्स को हमेशा परीक्षण के लिए यथार्थवादी डेटा तक पहुंच होनी चाहिए।) मुद्दा यह है कि किसी क्वेरी को ट्यून करने का उचित समय वह है जब इसे पहली बार तैनात किया जा रहा है, न कि जब यह खराब प्रदर्शन करने वाले SQL की सूची में दिखाई देता है, और निश्चित रूप से तब नहीं जब यह एक महत्वपूर्ण समस्या का कारण बनता है।

तो क्या डीबीए भूमि में समय से पहले अनुकूलन के रूप में योग्य होगा? मेरी सूची में सबसे ऊपर एक प्रदर्शन की आवश्यकता के बिना सामान्यीकरण का त्याग होगा। सुनिश्चित करें कि आप चाइल्ड रो से रनटाइम पर गणना करने के बजाय एक मूल पंक्ति पर एक राशि बनाए रख सकते हैं, लेकिन क्या आपको वास्तव में इसकी आवश्यकता है? यदि आप ट्विटर या अमेज़ॅन हैं, तो रणनीतिक डी-सामान्यकरण और पूर्व-गणना आपके सबसे अच्छे दोस्त हो सकते हैं। यदि आप 5 उपयोगकर्ताओं के लिए थोड़ा लेखांकन डेटाबेस डिज़ाइन कर रहे हैं, तो डेटा अखंडता की सुविधा के लिए उचित संरचना सर्वोच्च प्राथमिकता होनी चाहिए। अन्य समयपूर्व अनुकूलन भी इसी तरह प्राथमिकताओं की बात है। एक क्वेरी को दिन में एक बार चलाने में 10 घंटे लगते हैं और 10 सेकंड लगते हैं, भले ही आपको लगता है कि आप इसे 0.1 सेकंड तक काट सकते हैं। हो सकता है कि आपके पास प्रतिदिन 6 घंटे चलने वाली रिपोर्ट हो, लेकिन इसे ट्यूनिंग में समय लगाने से पहले इसे एक बैच की नौकरी के रूप में शेड्यूल करना। यदि आपका उत्पादन भार कभी भी 10% से ऊपर नहीं बढ़ता (मान लें कि आप सुरक्षा का प्रबंधन कर सकते हैं) एक अलग, वास्तविक समय की प्रतिकृति रिपोर्टिंग उदाहरण में निवेश न करें।

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

(और जब आप इस पर हों, तो आंकड़े सीखें! )


उचित डिजाइन प्रदर्शन और मापनीयता का 95% है।
मार्क स्टीवर्ट

6

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

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


5

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.