आप 3 प्रकार के ट्यूनिंग करने जा रहे हैं, 1 प्रतिक्रियाशील और 2 सक्रिय।
रिएक्टिव
नीले रंग में से, कुछ क्वेरी आपको समस्याएँ उत्पन्न करने लगती हैं। यह एक एप्लिकेशन बग या सुविधा, अपेक्षाओं से अधिक बढ़ने वाली तालिका, ट्रैफ़िक स्पाइक या क्वेरी ऑप्टिमाइज़र के "रचनात्मक" होने के कारण हो सकता है। यह मध्य-रात्रि ओह-बकवास-के-साइट-डाउन-डाउन प्रकार का मामला हो सकता है, या यह एक गैर-महत्वपूर्ण प्रकृति के सिस्टम सुस्ती के जवाब में हो सकता है। किसी भी तरह से, प्रतिक्रियाशील ट्यूनिंग का परिभाषित चरित्र यह है कि आपके पास पहले से ही एक समस्या है । कहने की जरूरत नहीं है, आप इसे जितना संभव हो उतना कम करना चाहते हैं। जो हमें लाता है ...
सक्रिय
टाइप 1: रूटीन मेंटेनेंस
किसी प्रकार के शेड्यूल के आधार पर, हर कुछ महीनों या हफ्तों में यह निर्भर करता है कि आपका स्कीमा कितनी बार बदलता है और आपका डेटा कितनी तेज़ी से बढ़ता है, आपको अपने डेटाबेस के प्रदर्शन विश्लेषण टूल (जैसे ओरेकल डीबीए के लिए AWR रिपोर्ट) के आउटपुट की समीक्षा करनी चाहिए। आप असंवेदनशील मुद्दों की तलाश कर रहे हैं, यानी ऐसी चीजें जो रिएक्टिव ट्यूनिंग, साथ ही कम लटकने वाले फलों की आवश्यकता के रास्ते पर हैं, जिन वस्तुओं को जल्द समस्या होने की संभावना नहीं है, लेकिन दूर तक रोकने की उम्मीद में थोड़े प्रयास से सुधार हो सकता है। -समस्या निवारण। आपको इस पर कितना समय बिताना चाहिए, यह इस बात पर निर्भर करेगा कि आपके पास कितना समय है, और आप इसे और क्या खर्च कर सकते हैं, लेकिन इष्टतम राशि कभी भी शून्य नहीं होती है। हालाँकि, आप आसानी से ...
टाइप 2: उचित डिजाइन
"प्रीमेच्योर ऑप्टिमाइज़ेशन" के खिलाफ नथ का पालन व्यापक रूप से जाना जाता है और विधिवत सम्मानित किया जाता है। लेकिन "समय से पहले" की उचित परिभाषा का उपयोग किया जाना चाहिए। कुछ एप्लिकेशन डेवलपर्स, जब अपने स्वयं के प्रश्नों को लिखने की अनुमति दी जाती है, तो उन पर जो पहली हिट होती है, उसे तार्किक रूप से सही मानने की प्रवृत्ति अपनाने की प्रवृत्ति होती है, और प्रदर्शन, वर्तमान या भविष्य के लिए कोई भी ध्यान नहीं देना चाहिए। या वे एक विकास डेटा सेट के खिलाफ परीक्षण कर सकते हैं जो उत्पादन वातावरण का प्रतिनिधि नहीं है (टिप: ऐसा न करें! डेवलपर्स को हमेशा परीक्षण के लिए यथार्थवादी डेटा तक पहुंच होनी चाहिए।) मुद्दा यह है कि किसी क्वेरी को ट्यून करने का उचित समय वह है जब इसे पहली बार तैनात किया जा रहा है, न कि जब यह खराब प्रदर्शन करने वाले SQL की सूची में दिखाई देता है, और निश्चित रूप से तब नहीं जब यह एक महत्वपूर्ण समस्या का कारण बनता है।
तो क्या डीबीए भूमि में समय से पहले अनुकूलन के रूप में योग्य होगा? मेरी सूची में सबसे ऊपर एक प्रदर्शन की आवश्यकता के बिना सामान्यीकरण का त्याग होगा। सुनिश्चित करें कि आप चाइल्ड रो से रनटाइम पर गणना करने के बजाय एक मूल पंक्ति पर एक राशि बनाए रख सकते हैं, लेकिन क्या आपको वास्तव में इसकी आवश्यकता है? यदि आप ट्विटर या अमेज़ॅन हैं, तो रणनीतिक डी-सामान्यकरण और पूर्व-गणना आपके सबसे अच्छे दोस्त हो सकते हैं। यदि आप 5 उपयोगकर्ताओं के लिए थोड़ा लेखांकन डेटाबेस डिज़ाइन कर रहे हैं, तो डेटा अखंडता की सुविधा के लिए उचित संरचना सर्वोच्च प्राथमिकता होनी चाहिए। अन्य समयपूर्व अनुकूलन भी इसी तरह प्राथमिकताओं की बात है। एक क्वेरी को दिन में एक बार चलाने में 10 घंटे लगते हैं और 10 सेकंड लगते हैं, भले ही आपको लगता है कि आप इसे 0.1 सेकंड तक काट सकते हैं। हो सकता है कि आपके पास प्रतिदिन 6 घंटे चलने वाली रिपोर्ट हो, लेकिन इसे ट्यूनिंग में समय लगाने से पहले इसे एक बैच की नौकरी के रूप में शेड्यूल करना। यदि आपका उत्पादन भार कभी भी 10% से ऊपर नहीं बढ़ता (मान लें कि आप सुरक्षा का प्रबंधन कर सकते हैं) एक अलग, वास्तविक समय की प्रतिकृति रिपोर्टिंग उदाहरण में निवेश न करें।
यथार्थवादी डेटा के खिलाफ परीक्षण करके, विकास और ट्रैफ़िक पैटर्न (स्पाइक्स के लिए अतिरिक्त भत्ते) पर शिक्षित अनुमान लगाते हुए, और अपने प्लेटफ़ॉर्म के ऑप्टिमाइज़र क्वर्क्स के अपने ज्ञान को लागू करते हुए, आप उन प्रश्नों को तैनात कर सकते हैं जो अभी नहीं, बल्कि भविष्य में ही (करीब) चल रहे हैं , और कम-से-आदर्श परिस्थितियों में। जब आप उचित तकनीकों को लागू करते हैं, तो क्वेरी प्रदर्शन का सटीक अनुमान लगाया जा सकता है, और अनुकूलित किया जा सकता है (प्रत्येक घटक के अर्थ में जितनी तेज़ी से इसे होने की आवश्यकता है)।
(और जब आप इस पर हों, तो आंकड़े सीखें! )