SQL सर्वर के बारे में डेवलपर को 7 बातें पता होनी चाहिए

नमस्कार। मैं एक पूर्व डेवलपर हूं, जो एक डेटाबेस प्रशासक बन गया, और नीचे मैंने इस बारे में लिखा था कि, नियत समय में, मैं खुद को सुनना चाहूंगा।

7. स्केलर यूडीएफ का प्रदर्शन खराब है

अच्छे डेवलपर्स कोड को फ़ंक्शंस में डालकर और इन फ़ंक्शंस को विभिन्न स्थानों से कॉल करना पसंद करते हैं। यह एप्लिकेशन स्तर पर बहुत अच्छा काम करता है, लेकिन डेटाबेस स्तर पर यह विशाल प्रदर्शन मुद्दों को जन्म दे सकता है।

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

यदि आप चाहते हैं कि आपका कोड पुन: उपयोग किया जाए, तो संग्रहीत प्रक्रियाओं और विचारों के बारे में सोचें। (वास्तव में, वे अपनी प्रदर्शन समस्याओं को पेश कर सकते हैं, लेकिन मैं आपको जल्द से जल्द सही रास्ते पर लाना चाहता हूं और UDF, अफसोस, ऐसा नहीं है।)

6. "बिना (NOLOCK)" का मतलब यह नहीं है कि वहाँ कोई ताले नहीं होंगे

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

जब आपकी क्वेरी किसी भी तालिका तक पहुंचती है, यहां तक ​​कि NOLOCK संकेत के साथ, आप स्कीमा स्थिरता लॉक (Sch-S) लगाते हैं। जब तक आपकी क्वेरी पूरी नहीं हो जाती तब तक कोई भी इस तालिका या इसके अनुक्रमणिका को नहीं बदल सकता है। जब तक आपको सूचकांक को हटाने की आवश्यकता नहीं होती है, तब तक यह एक गंभीर समस्या नहीं लगती है, लेकिन आप ऐसा नहीं कर सकते हैं, क्योंकि लोग इस तालिका के साथ लगातार काम करते हैं, यह पूरी तरह से सुनिश्चित करने के बाद कि वे कोई समस्या पैदा नहीं करते हैं, क्योंकि वे (NOLOCK) संकेत का उपयोग करते हैं ।

यहां कोई सिल्वर बुलेट नहीं है, लेकिन SQL सर्वर आइसोलेशन स्तरों के बारे में पढ़ना शुरू करें - मेरा मानना ​​है कि READ COMMITTED SNAPSHOT आइसोलेशन स्तर आपके आवेदन के लिए सबसे अच्छा विकल्प होगा। आपको कम लॉक मुद्दों के साथ पूरा डेटा प्राप्त होगा।

5. अपने आवेदन में तीन कनेक्शन स्ट्रिंग्स का उपयोग करें

मुझे पता है कि आपके पास अभी केवल एक SQL सर्वर है, लेकिन मेरा विश्वास करो, यह इसके लायक है। तीन कनेक्शन लाइनें बनाएं जो अब केवल एक सर्वर को संदर्भित करेगा, लेकिन फिर, जब आप स्केलिंग के बारे में सोचते हैं, तो आपके पास इनमें से प्रत्येक लाइन के "अलग-अलग" सर्वर की सेवा करने का अवसर होगा।

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

पहले कनेक्शन स्ट्रिंग को "स्केल" करना काफी कठिन है, SQL सर्वर में "स्केलिंग राइट ऑपरेशन" के लिए कई विकल्प नहीं हैं (ऐसे विकल्प हैं, लेकिन उन्हें लागू करना और उन्हें प्रबंधित करना बहुत मुश्किल है)। कनेक्शन "स्केल" की दूसरी और तीसरी लाइन बहुत आसान और सस्ती है। विभिन्न कनेक्शन स्ट्रिंग्स का उपयोग करने के बारे में अधिक जानकारी प्राप्त करने के लिए, आप इस पोस्ट को पढ़ सकते हैं।

4. एक मध्यवर्ती डेटाबेस का उपयोग करें

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

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

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

3. कल के लेख और पुस्तकें आज प्रासंगिक नहीं हो सकती हैं।

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

जब आप कुछ ऐसा सुनते हैं जो अच्छी सलाह की तरह लगता है, तो मेरा सुझाव है कि आप डॉ। फिल के विपरीत रणनीति का उपयोग करें। डॉ। फिल कहते हैं कि आपको 15 मिनट के लिए किसी भी विचार से "प्रेरित" होना चाहिए। इसके बजाय, इसे नफरत करने की कोशिश करें - उत्पादन में लागू करने से पहले आप जो भी पढ़ते हैं, उसका खंडन करने का प्रयास करें। भले ही सलाह अच्छी हो, लेकिन यह आपके सिस्टम पर बहुत उपयोगी नहीं हो सकती है। (हां, यह बात मेरी सलाह पर भी लागू होती है)।

2. आदेश का उपयोग कर से बचें; एप्लिकेशन में डेटा सॉर्ट करें

SQL सर्वर CPU क्वेरी को आपकी क्वेरी के परिणामों को छाँटता है। SQL सर्वर एंटरप्राइज़ संस्करण की लागत एक कोर के लिए लगभग 7,000 डॉलर है - प्रोसेसर के लिए नहीं, बल्कि स्वयं कोर के लिए। एक दोहरे सॉकेट, छह-कोर सर्वर की लागत लगभग 84,000 डॉलर होगी - और यह केवल लाइसेंस की कीमत है, हार्डवेयर की गिनती नहीं। आप $ 84k के लिए बहुत सारे एप्लिकेशन सर्वर (प्रत्येक पर 256 जीबी रैम के साथ) का एक नरक खरीद सकते हैं।

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

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

(और यह वह हिस्सा है जिसमें MySQL और PostgreSQL के प्रशंसक खुले स्रोत DBMS का उपयोग करके लाइसेंस की लागत को कम करने के बारे में बात करते हैं)। (और इस भाग में, आप मुझसे उम्मीद करते हैं कि मैं उन्हें मजाकिया ढंग से जवाब दूंगा, लेकिन मैंने ऐसा नहीं किया। यदि आप एक नया एप्लिकेशन विकसित कर रहे हैं और डेटाबेस चुनने के बारे में सोच रहे हैं, तो मेरे जवाब को पढ़ें StackOverflow के बारे में कि कौन सा डेटाबेस सबसे बड़ा भार झेलता है।)

1. SQL सर्वर में अड़चन खोजने के लिए अंतर्निहित उपकरण होते हैं जो प्रदर्शन को प्रभावित नहीं करते हैं

SQL सर्वर डायनेमिक एडमिनिस्ट्रेटिव व्यूज़ (DMV) आपको वे सभी स्थान दिखा सकता है जो प्रदर्शन के लिए हानिकारक हैं, अर्थात्:

• कौन सा अनुरोध आपके सर्वर पर सबसे अधिक लोड उत्पन्न करता है
• कौन सा इंडेक्स केवल स्पेस लेता है और इन्सर्ट / डिलीट / अपडेट ऑपरेशंस को धीमा करता है
• आपके सर्वर (सीपीयू, डिस्क, नेटवर्क, लॉक, आदि) पर क्या अड़चनें हैं?

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

अनुवादक का ध्यान दें: अनुवाद और शैली के बारे में कोई भी सुझाव और टिप्पणियां स्वागत योग्य हैं, हमेशा की तरह।