डेटाबेस इंडेक्स का उपयोग विभिन्न टेबल ऑपरेशंस को गति देने के लिए किया जाता है। हालाँकि, इससे पहले कि आप एक इंडेक्स बनाएं, यह जानना महत्वपूर्ण है कि क्या आपको वास्तव में एक इंडेक्स की आवश्यकता है? और अगर आपको एक इंडेक्स बनाने की जरूरत है तो कौन से महत्वपूर्ण बिंदु हैं जिन्हें ध्यान में रखा जाना चाहिए? यह वह जगह है जहाँ डेटाबेस इंडेक्स डिज़ाइन आता है।
इस लेख का उद्देश्य डेटाबेस इंडेक्स डिज़ाइन के बारे में इन सवालों का जवाब देना है और कुछ प्रमुख विचारों पर प्रकाश डालना है जो एक डेटाबेस डेवलपर को इंडेक्स डिजाइन करते समय ध्यान में रखना चाहिए।
<एच3>1. टेबल साइज
इंडेक्स बनाने से पहले एक डेटाबेस डेवलपर को जो पहला सवाल पूछना चाहिए, वह यह है कि टेबल इंडेक्स का कुशलतापूर्वक उपयोग करने के लिए पर्याप्त है या नहीं। यदि तालिका का आकार छोटा है, तो SQL सर्वर इंजन किसी अनुक्रमणिका के माध्यम से तालिका को खोजने की तुलना में पूरी तालिका को अधिक तेज़ी से स्कैन कर सकता है। ऐसे मामले में अनुक्रमणिका का कोई उपयोग नहीं होता है और डेटाबेस संचालन करते समय एक ओवरहेड बनाते हैं।
<एच3>2. कॉलम प्रकार
इंडेक्स को प्राथमिक कुंजी कॉलम या किसी भी कॉलम पर बनाया जाना चाहिए जिसमें अद्वितीय मान हों और जिसमें न्यूल बाधा न हो। इसके अलावा, संख्यात्मक स्तंभों पर अनुक्रमणिका बनाने की सलाह दी जाती है क्योंकि संख्यात्मक स्तंभों में गैर-संख्यात्मक स्तंभों की तुलना में अधिक विशिष्ट मान होते हैं। खराब डेटाबेस इंडेक्स डिज़ाइन उन स्तंभों पर अनुक्रमणिका का उपयोग करता है जिनमें बहुत कम विशिष्ट प्रविष्टियाँ होती हैं और इसके परिणामस्वरूप बहुत समय लेने वाली क्वेरी हो सकती हैं।
पेशेंट्स नाम की एक टेबल पर विचार करें जिसमें सैकड़ों हजारों रिकॉर्ड हैं। मरीजों की तालिका में "लिंग" नामक एक कॉलम होगा जिसमें केवल दो अद्वितीय मान "पुरुष" और "महिला" हो सकते हैं। यदि आप "जेंडर कॉलम" पर एक इंडेक्स बनाते हैं, तो रिकॉर्ड्स को आरोही या अवरोही वर्णानुक्रम में क्रमबद्ध किया जाएगा।
इसलिए यदि आपके पास मरीजों की तालिका में एक मिलियन रिकॉर्ड हैं और पुरुष और महिला रोगियों की संख्या समान है, तो सूचकांक में पहले आधे मिलियन रिकॉर्ड में लिंग "महिला" होगा और दूसरे आधे मिलियन में लिंग "पुरुष" होगा। अब यदि आप महिला रिकॉर्ड की 490,000वीं पंक्ति में मौजूद किसी महिला की खोज करना चाहते हैं, तो SQL सर्वर इंजन को 490,000 रिकॉर्ड के माध्यम से स्कैन करना होगा। दूसरी ओर, अद्वितीय संख्यात्मक मानों के साथ खोज बहुत तेज हो सकती है क्योंकि SQL सर्वर अनुक्रमणिका B + ट्री के रूप में संग्रहीत होती है, और इसलिए ट्री नोड्स में संख्यात्मक मान डेटाबेस संचालन को गति दे सकते हैं।
<एच3>3. अनुक्रमणिका की संख्या
आधिकारिक तौर पर आप प्रत्येक डेटाबेस तालिका के लिए एक क्लस्टर इंडेक्स और जितने चाहें उतने गैर-क्लस्टर इंडेक्स बना सकते हैं। हालांकि, यह एक अच्छा डेटाबेस इंडेक्स डिज़ाइन है जो एक क्लस्टर इंडेक्स और केवल सीमित संख्या में बिल्कुल आवश्यक गैर-क्लस्टर इंडेक्स बनाने के लिए है। बहुत अधिक गैर-संकुल अनुक्रमणिका बनाना वास्तव में अद्यतन और सम्मिलित संचालन को धीमा कर सकता है क्योंकि जब कोई रिकॉर्ड अद्यतन या सम्मिलित किया जाता है और एक स्तंभ मान बदल दिया जाता है, तो सभी संबद्ध अनुक्रमणिकाओं को अद्यतन करना पड़ता है।
एक ऐसे परिदृश्य पर विचार करें जहां हमारे पास दो गैर-संकुल सूचकांक हैं, पहला सूचकांक उम्र के आधार पर रिकॉर्ड को क्रमबद्ध करता है और दूसरा सूचकांक लिंग और उम्र दोनों के आधार पर रिकॉर्ड को क्रमबद्ध करता है।
यहाँ पहला सूचकांक है:
आयु | पता रिकॉर्ड करें |
10 | रिकॉर्ड पता |
22 | रिकॉर्ड पता |
29 | रिकॉर्ड पता |
32 | रिकॉर्ड पता |
33 | रिकॉर्ड पता |
36 | रिकॉर्ड पता |
40 | रिकॉर्ड पता |
49 | रिकॉर्ड पता |
54 | रिकॉर्ड पता |
59 | रिकॉर्ड पता |
और यहाँ दूसरा है:
लिंग | आयु | पता रिकॉर्ड करें |
महिला | 10 | रिकॉर्ड पता |
महिला | 29 | रिकॉर्ड पता |
महिला | 33 | रिकॉर्ड पता |
महिला | 40 | रिकॉर्ड पता |
महिला | 54 | रिकॉर्ड पता |
पुरुष | 22 | रिकॉर्ड पता |
पुरुष | 32 | रिकॉर्ड पता |
पुरुष | 36 | रिकॉर्ड पता |
पुरुष | 49 | रिकॉर्ड पता |
पुरुष | 59 | रिकॉर्ड पता |
अब यदि किसी कारण से 40 वर्ष की आयु वाले रिकॉर्ड को 15 वर्ष की आयु में अद्यतन करना है, तो सूचकांक को क्रमबद्ध रखने के लिए रिकॉर्ड को 7वें स्थान (40) से दूसरे स्थान पर ले जाने के लिए पहले सूचकांक को अद्यतन करना होगा। इसी तरह दूसरे इंडेक्स में चौथे इंडेक्स के रिकॉर्ड को दूसरे इंडेक्स में ले जाया जाएगा। काफी फेरबदल करना पड़ रहा है। इसलिए डेटाबेस इंडेक्स डिज़ाइन के बारे में सोचते समय नियमित रूप से अपडेट किए जाने वाले कॉलम के लिए इंडेक्स की संख्या को न्यूनतम रखना बुद्धिमानी है। साथ ही एक से अधिक गैर-संकुल अनुक्रमणिका में एक स्तंभ का उपयोग नहीं किया जाना चाहिए।
<एच3>4. अनुक्रमणिका का संग्रहण स्थान
किसी अनुक्रमणिका का संग्रहण स्थान अनुक्रमणिका का उपयोग करने वाले प्रश्नों के प्रदर्शन को प्रभावित कर सकता है और इसलिए यह अच्छे डेटाबेस अनुक्रमणिका डिज़ाइन का भी हिस्सा है। डिफ़ॉल्ट रूप से एक संकुल अनुक्रमणिका को उसी फ़ाइल समूह में संग्रहीत किया जाता है जिस तालिका पर अनुक्रमणिका बनाई जाती है। गैर-संकुल अनुक्रमणिका के लिए, अनुक्रमणिका को एक ही फ़ाइल समूह में या एकाधिक डिस्क ड्राइव में फैले विभिन्न फ़ाइल समूहों में संग्रहीत किया जा सकता है। गैर-संकुल अनुक्रमणिका के क्वेरी प्रदर्शन को एकाधिक डिस्क ड्राइव पर गैर-संकुल अनुक्रमणिका को संग्रहीत करके महत्वपूर्ण रूप से सुधारा जा सकता है। ऐसा इसलिए है क्योंकि ड्राइव के विभिन्न क्षेत्रों में डेटा वितरित किए जाने के परिणामस्वरूप क्वेरी के इनपुट/आउटपुट प्रदर्शन में सुधार होगा।
अनुक्रमणिका के डिफ़ॉल्ट संग्रहण स्थान को FILLFACTOR विकल्प के लिए मान निर्दिष्ट करके भी बदला जा सकता है। चूंकि, इंडेक्स भौतिक रूप से B+ ट्री के रूप में संग्रहीत होते हैं, इसलिए इंडेक्स डेटा को लीफ पेजों पर संग्रहीत किया जाता है। FILLFACTOR विकल्प के साथ, आप भरे जाने वाले लीफ-लेवल पेजों का प्रतिशत सेट कर सकते हैं। उदाहरण के लिए, यदि आप FILLFACTOR का मान 70% पर सेट करते हैं, तो लीफ-लेवल पेज के कुल स्पेस का केवल 70% इंडेक्स डेटा से भरा जाएगा। शेष 30% भविष्य में इंडेक्स डेटा के स्वचालित विकास के लिए छोड़ दिया जाएगा।
5. अनुक्रमणिका प्रकार
डेटाबेस इंडेक्स डिज़ाइन में एक और अत्यंत महत्वपूर्ण विचार उपयोग करने के लिए इंडेक्स का प्रकार है। पहले के एक लेख में ("क्लस्टर या नॉन-क्लस्टर्ड इंडेक्स का उपयोग कब करें" लेख में एक लिंक जोड़ें) मैंने क्लस्टर और गैर-क्लस्टर इंडेक्स के बीच अंतर को समझाया। मैंने यह भी बताया कि वे क्या हैं और उनका उपयोग कैसे किया जा सकता है। क्लस्टर्ड या नॉन-क्लस्टर इंडेक्स चुनने का निर्णय महत्वपूर्ण है और इस पर सावधानीपूर्वक विचार किया जाना चाहिए।
किस प्रकार के सूचकांक को चुनना है, यह तय करते समय निम्नलिखित बातों को ध्यान में रखा जाना चाहिए।
- सेलेक्ट/जॉइन/ग्रुप BY/BETWEEN क्वेरी में उपयोग किए जाने वाले कॉलम के लिए, क्लस्टर्ड इंडेक्स का उपयोग करें।
- उन स्तंभों के लिए गैर-संकुल अनुक्रमणिका का उपयोग करें जहां आप केवल उस विशिष्ट स्तंभ से मान प्राप्त करना चाहते हैं, न कि उसी पंक्ति के अन्य स्तंभों से। गैर-संकुल अनुक्रमणिका का उपयोग करके एकाधिक रिकॉर्ड पुनर्प्राप्त करने वाली क्वेरी का चयन धीमा हो सकता है क्योंकि SQL सर्वर इंजन पहले उन स्तंभ मानों की खोज करता है जिन पर अनुक्रमणिका बनाई गई है और फिर स्तंभ मान के लिए पंक्ति संदर्भ का उपयोग करके, वास्तविक डेटाबेस तालिकाओं से रिकॉर्ड पुनर्प्राप्त किए जाते हैं ।
- उन स्तंभों के लिए जो अक्सर INSERT और UPDATE संचालन से गुजरते हैं, गैर-संकुल अनुक्रमणिका का उपयोग करें। सुनिश्चित करें कि एक से अधिक गैर-संकुल अनुक्रमणिका में एक कॉलम का उपयोग न करें क्योंकि यह अद्यतन क्वेरी को धीमा कर सकता है। क्लस्टर इंडेक्स INSERT/UPDATE संचालन के लिए धीमा हो सकता है क्योंकि पूरी पंक्ति को केवल एक कॉलम मान के बजाय अद्यतन किया जाना चाहिए जैसा कि गैर-क्लस्टर इंडेक्स के मामले में होता है।
- चूंकि आप केवल एक क्लस्टर इंडेक्स बना सकते हैं, उनके मामले में जहां आपको कई इंडेक्स की आवश्यकता होती है, गैर-क्लस्टर इंडेक्स का उपयोग करें। हालाँकि, यदि डिस्क स्थान एक प्रमुख चिंता का विषय है, तो गैर-संकुल अनुक्रमणिका की संख्या को न्यूनतम रखें।
अन्य विचार
हालाँकि ये डेटाबेस इंडेक्स डिज़ाइन के पाँच सबसे महत्वपूर्ण भाग हैं, लेकिन ये सब कुछ नहीं हैं। अनुक्रमणिका में स्तंभों का सही क्रम निर्दिष्ट करना महत्वपूर्ण है। अंगूठे के एक नियम के रूप में, WHERE क्लॉज में निर्णय लेने के लिए उपयोग किए जाने वाले कॉलम, और (> से अधिक), (<) से कम आदि जैसी शर्तों को इन क्लॉज में शामिल नहीं होने वाले कॉलम से पहले रखा जाना चाहिए। WHERE क्लॉज में कई कॉलम के मामले में, सबसे विशिष्ट कॉलम नामों का उल्लेख इंडेक्स परिभाषा में जल्द से जल्द किया जाना चाहिए।
डेटाबेस इंडेक्स डिज़ाइन के अलावा, क्वेरी डिज़ाइन इंडेक्स डिज़ाइन के कुशल उपयोग में भी महत्वपूर्ण भूमिका निभाता है। छोटी संख्या में पंक्तियों पर काम करने वाली एकाधिक क्वेरी लिखने के बजाय अनुकूलित अनुक्रमणिका रखरखाव के लिए, कम क्वेरी लिखने का प्रयास करें जो बड़ी संख्या में तालिका पंक्तियों को प्रभावित करती हैं।
निष्कर्ष
यह आलेख कुछ प्रमुख विचारों की व्याख्या करता है जो एक डेटाबेस डेवलपर को डेटाबेस इंडेक्स डिज़ाइन को देखते समय ध्यान में रखना चाहिए। लेख इन विचारों के पीछे के तर्क को भी स्पष्ट करता है और यह सुनिश्चित करने के लिए और सुझाव देता है कि आपका डेटाबेस इंडेक्स डिज़ाइन कुशल है।