कहें कि मेरे पास बड़ी संख्या में पंक्तियों वाली एक तालिका है और एक स्तंभ जो मैं इंडेक्स करना चाहता हूं, में 20 मानों में से एक हो सकता है। अगर मुझे कॉलम पर एक इंडेक्स डालना था तो यह बड़ा होगा?अनुक्रमांक एसक्यूएल में चूसना है?
यदि हां, तो क्यों? यदि मैं डेटा को डेटा में 20 टेबल में विभाजित करना चाहता था, तो स्तंभ के प्रत्येक मान के लिए, सूचकांक का आकार छोटा होगा लेकिन अनुक्रमण प्रभाव समान होगा।
इंडेक्स पूरी तरह से प्रदर्शन के लिए हैं। यदि कोई इंडेक्स आपकी रुचि वाले प्रश्नों के प्रदर्शन को बढ़ावा नहीं देता है, तो यह बेकार है।
डिस्क उपयोग के लिए, आपको अपनी चिंताओं का वजन करना होगा। विभिन्न एसक्यूएल प्रदाता अलग-अलग इंडेक्स बनाते हैं, लेकिन एक ग्राहक के रूप में, आप आम तौर पर भरोसा करते हैं कि वे सबसे अच्छा कर सकते हैं जो किया जा सकता है। यदि आप वर्णन कर रहे हैं, तो क्लस्टर सूचकांक आकार और प्रदर्शन दोनों के लिए इष्टतम हो सकता है।
"यदि कोई इंडेक्स आपकी रुचि वाले प्रश्नों के प्रदर्शन को बढ़ावा नहीं देता है, तो यह बेकार है।" मैं अलग होना चाहता हूं। मैं सहमत हूं, अगर सूचकांक कोई उद्देश्य नहीं देता है, तो यह केवल अतिरिक्त ओवरहेड है। लेकिन उद्देश्य आपके द्वारा पूछे जाने वाले प्रश्न या प्रश्नों से कहीं अधिक व्यापक हो सकता है। – HLGEM
आप सही हैं ... मैंने थोड़ा बढ़ाया। पोस्ट करने के बाद मैंने सोचा, यह भविष्य के डेटा परिदृश्यों के लिए डिज़ाइन किया जा सकता है। – harpo
कहें कि मेरे पास बड़ी संख्या में पंक्तियों वाली एक तालिका है और एक कॉलम जिसे मैं इंडेक्स करना चाहता हूं, में से 20 मान हो सकते हैं। अगर मुझे कॉलम पर एक इंडेक्स डालना था तो क्या यह बड़ा होगा?
सूचकांक आकार आपकी पंक्तियों की संख्या और अनुक्रमित मानों की लंबाई के समान आनुपातिक होगा।
सूचकांक न केवल अनुक्रमित मूल्य, लेकिन यह भी (Oracle में ROWID, PostgreSQL में LCID, InnoDB आदि में प्राथमिक कुंजी) पंक्ति के लिए सूचक किसी तरह का रहता है।
यदि आपके पास 10,000 पंक्तियां और 1 विशिष्ट मान है, तो आपके पास अभी भी 10,000 रिकॉर्ड आपके सूचकांक में होंगे।
यदि हां, तो क्यों? अगर मैं 20 टेबल, स्तंभ के प्रत्येक मूल्य के लिए एक में डेटा में डेटा विभाजन के थे, सूचकांक आकार तुच्छ होगा, लेकिन अनुक्रमण प्रभाव इस मामले में एक ही
होगा, आप के साथ आते हैं 20 इंडेक्स कुल आकार में समान हैं जो आपके मूल के रूप में हैं।
इस तकनीक को कभी-कभी इस तरह के विभाजित इंडेक्स में उपयोग किया जाता है। इसके फायदे और कमियां हैं।
ओरेकल में, इंडेक्स निर्माण पर कंप्रेसर विकल्प इंडेक्स में दर्शाए गए समान अनुक्रमित मान की कई प्रतियों की आवश्यकता को कम कर सकता है। हालांकि, आपको अभी भी सभी पंक्तियों की आवश्यकता है। –
मेरा मुद्दा यह है कि यदि मैं 20 टेबल में विभाजित करता हूं तो मुझे कॉलम में किसी भी इंडेक्स की आवश्यकता नहीं होगी, क्योंकि मुझे पता है कि कॉलम की प्रत्येक पंक्ति का एक ही मूल्य है। –
यदि आप 20 टेबल में विभाजित हैं तो आपको कॉलम – Quassnoi
यह क्रमबद्ध क्रम में, सभी पंक्तियों के लिए उन मानों को पकड़ने के लिए पर्याप्त होगा।
कहें कि आपके पास 4 वर्णों के 20 अलग-अलग तार हैं, और 1 मिलियन पंक्तियां हैं, तो कम से कम 4 मिलियन बाइट्स (या 8-16-बिट यूनिकोड) होने पर यह मान रखने के लिए होगा।
कॉलम की भी आवश्यकता नहीं है, ठीक है, आवश्यक नहीं है। यदि किसी पृष्ठ पर सभी पंक्तियों का एक ही कॉलम मान था, उदाहरण के लिए, एक स्मार्ट इंडेक्सिंग इंजन इसके बजाय उस तथ्य को रिकॉर्ड करके कम स्थान का उपयोग करने में सक्षम हो सकता है। आईएमएचओ निश्चित रूप से, मैं आसानी से गलत हो सकता है ... –
संक्षिप्त उत्तर: अनुक्रमित चूसना करो: हाँ और नहीं
लंबा उत्तर: वे अगर ठीक से इस्तेमाल किया चूसना नहीं है। शायद आपको पढ़ना शुरू करना चाहिए कि इंडेक्स कैसे काम करते हैं, वे क्यों काम कर सकते हैं और वे कभी-कभी क्यों काम नहीं करते हैं।
अच्छा प्रारंभिक बिंदु: http://www.sqlservercentral.com/articles/Indexing/
यह नहीं है अनुक्रमित कि चूसना होगा। यह ग़लत कॉलम पर इंडेक्स डाल रहा है जो चूस जाएगा।
गंभीरता से, आपको एक कॉलम के साथ एक टेबल की आवश्यकता क्यों होगी? उस डेटा का अर्थ क्या होगा? इसका क्या उद्देश्य होगा?
और 20 टेबल? मेरा सुझाव है कि आप पहले database design पर पढ़ लें, या अन्यथा हमें आपके प्रश्न के संदर्भ की व्याख्या करें।
मैंने वास्तविक इकाइयों की प्रत्येक विशेषता के लिए एक अलग तालिका वाला डेटाबेस देखा है। क्यों: वे प्रत्येक विशेषता के लिए संस्करण इतिहास और समय-यात्रा चाहते हैं। कल्पना करें कि 300 टेबल वाले डेटाबेस, जहां अधिकांश फ़ील्ड "डेटटाइम" प्रकार के हैं ... – thijs
@thijs लेकिन आपको अभी भी दो कॉलम की आवश्यकता होगी, एक कुंजी के रूप में और एक विशेषता –
मैंने बुरी तरह से वाक्यांश दिया है। एक कॉलम है जिसे मैं इंडेक्स करना चाहता हूं, कुल मिलाकर एक कॉलम नहीं। मैं तालिका संरचना के अधिक विवरण के साथ अपने प्रश्न को संपादित करूंगा। –
क्षमा करें, मुझे पूरा यकीन नहीं है कि आपका मतलब "बड़ा" है।
अपने सूचकांक क्लस्टर है, तो प्रत्येक रिकॉर्ड के लिए सभी डेटा, एक ही पत्ता पृष्ठ पर होगा जिससे अपनी तालिका में सबसे कुशल सूचकांक उपलब्ध बनाने जब तक आप ठीक से इसके खिलाफ आपके प्रश्नों लिखें।
यदि आपकी अनुक्रमणिका गैर-क्लस्टर है, तो केवल सूचकांक संबंधित डेटा आपके पत्ते पृष्ठों पर होगा। फिर, इस तरह की चीजों के आधार पर आपके पास कितने अन्य इंडेक्स हैं, आपके भरने वाले कारक जैसे विवरणों के साथ, आपकी अनुक्रमणिका कुशल हो सकती है या नहीं भी हो सकती है। आम तौर पर, यदि आपके टेबल पर इंडेक्स का टन नहीं है, तो आपको सुरक्षित होना चाहिए।
आपकी अनुक्रमणिका की दक्षता भी कॉलम में जाने के 20 मूल्यों के डेटा प्रकार द्वारा निर्धारित की जाएगी। यदि वे पूर्व निर्धारित मान हैं, तो उनके विवरण शायद एक साधारण प्राथमिक कुंजी डेटाटाइप (जैसे इंट/नंबर) के साथ लुकअप टेबल में होना चाहिए। फिर कॉलम पर एक इंडेक्स के साथ एक विदेशी कुंजी के रूप में अपनी तालिका में उस कॉलम को जोड़ें।
आखिरकार, आप कॉलम पर एक आदर्श अनुक्रमणिका प्राप्त कर सकते हैं। लेकिन आपके द्वारा लिखे गए प्रश्नों के अधिकांश भाग के लिए इसका सबसे अच्छा उपयोग निर्धारित किया जाएगा। इसलिए यदि आपके प्रश्न इंडेक्स का उपयोग करते हैं, तो आप सुनहरे हैं।
तालिका में 600 मिलियन पंक्तियां हैं। लगभग 5 कॉलम हैं, जिनमें से सभी का चयन चयन फ़िल्टरिंग और डेटा कॉलम के लिए किया जाता है। लेकिन, इस प्रश्न के लिए हम कह सकते हैं कि 3 कॉलम हैं। कर्नल 1, कर्नल 2, कर्नल 3। कहें कि कर्नल 1 पीके है और col2 में 20 संभावित मान हैं और col3 –
डेटा कॉलम है। ऐसा लगता है कि अगर कुछ कर्नल 2 पर सूचकांक बड़े पैमाने पर है तो कुछ गड़बड़ है - क्योंकि मैं 20 टेबलों में विभाजित करके अपनी खुद की अनुक्रमणिका रोल कर सकता हूं, 1 प्रति कॉल 2 मूल्य। –
600 एम पंक्तियों पर, मुझे आशा है कि आप एक ओएलएपी तालिका के बारे में बात कर रहे हैं, न कि ओएलटीपी तालिका। प्रबंधन के लिए बहुत सारी पंक्तियां हैं! अब आप गंभीर गोदाम डीबी आर्किटेक्चर सिद्धांत में शामिल हो रहे हैं जिसे आपके डेटाबेस के कई अन्य कारकों पर विचार करना होगा। मुझे आपके अंतिम निर्णय को सुनना अच्छा लगेगा। – Boydski
मानक बी-पेड़ इंडेक्स काफी चुनिंदा इंडेक्स के लिए सबसे उपयुक्त हैं, जो यह उदाहरण नहीं होगा। आप यह नहीं कहते कि आप किस डीबीएमएस का उपयोग कर रहे हैं; ओरेकल में एक अन्य प्रकार की इंडेक्स है जिसे बिटमैप इंडेक्स कहा जाता है जो ओलाप वातावरण में कम-चयनशीलता इंडेक्स के लिए अधिक उपयुक्त है (क्योंकि इन इंडेक्स को बनाए रखने के लिए महंगा है, जिससे उन्हें OLTP वातावरण के लिए अनुपयुक्त बना दिया जाता है)।
ऑप्टिमाइज़र आंकड़ों पर आधार तय करेगा चाहे वह सोचता है कि सूचकांक सबसे तेज़ समय में डेटा प्राप्त करने में मदद करेगा; यदि यह नहीं होगा, तो ऑप्टिमिसर इसका उपयोग नहीं करेगा।
विभाजन एक और रणनीति है। ओरेकल में आप कॉलम के कुछ सेट पर विभाजन के रूप में एक तालिका को परिभाषित कर सकते हैं, और ऑप्टिमाइज़र स्वचालित रूप से आपके द्वारा सुझाए गए "विभाजन उन्मूलन" को निष्पादित कर सकता है।
FYI: कॉलम की सामग्री के आधार पर तालिका विभाजन (फ़ाइलों पर डेटा फैलाना) एमएसएसएलएल 2005 में भी संभव है और – thijs
इंडेक्स (या सूचकांक) चूसना नहीं है। बहुत से स्मार्ट लोगों ने पिछले कई दशकों के वास्तव में उल्लेखनीय समय बिताया है कि यह ऐसा है।
आपकी स्कीमा, हालांकि, समान मात्रा में विशेषज्ञता और प्रयास की कमी, वास्तव में बहुत बुरी तरह चूस सकती है।
विभाजन, क्लस्टरर्ड इंडेक्स को लागू करने के बराबर है। यदि तालिका को अन्यथा क्रमबद्ध किया गया है (या मनमाना क्रम में है) तो सूचकांक को अधिक जगह पर कब्जा करना होगा। प्लेटफ़ॉर्म के आधार पर, अनुक्रमित मूल्य वृद्धि के संबंध में पंक्तियों की क्रमबद्धता के रूप में एक गैर-क्लस्टर सूचकांक आकार में कम हो सकता है।
वाईएमएमवी।
अच्छा है! मुझे संदेह था कि यह विभाजन क्लस्टर्ड इंडेक्स का उपयोग करने जैसा था। यह मुझे प्रश्न पर ले जाता है: क्या क्लस्टर्ड इंडेक्स का उपयोग करके तालिका को स्वयं विभाजन करने का कोई मूल्य है? मुझे लगता है कि प्रदर्शन हिट सम्मिलित करने पर न्यूनतम होगा यदि मुझे केवल कॉर्रेक –
सही तालिका को सम्मिलित करने के लिए कोड का एक बिट जोड़ने की आवश्यकता है। यदि मैंने क्लस्टर्ड इंडेक्स का उपयोग किया तो क्या अधिक प्रदर्शन हिट होगा? क्या डेटा को प्रत्येक डालने पर बहुत कुछ स्थानांतरित करना पड़ता है जहां क्लस्टर्ड इंडेक्स होता है - या इससे बेहतर है? –
क्लस्टर्ड इंडेक्स वाली एक तालिका अनुक्रमित कॉलम पर क्रमबद्ध (परिभाषा के अनुसार) है। इसलिए सभी मूल्यों में सम्मिलित होने की संभावना है। यह वास्तव में विभाजित तालिका के साथ भी बदतर हो सकता है, हालांकि - आपको इसे चूसना और देखना होगा। तुलना में एक गैर-क्लस्टर सूचकांक को आजमाने के लिए मत भूलना, या तो! –
कोई अनुक्रमणिका नहीं चूसती है, लेकिन आपको ध्यान देना होगा कि आप उनका उपयोग कैसे करते हैं या वे आपके प्रश्नों के प्रदर्शन पर बैकफायर कर सकते हैं।
पहले: स्कीमा/डिजाइन
क्यों आप केवल एक स्तंभ के साथ एक मेज बनाएंगे? शायद यह एक कदम दूर सामान्यीकरण ले रहा है। डेटाबेस डिजाइन सबसे महत्वपूर्ण बातें प्रदर्शन
दूसरा अनुकूलन में विचार करने के लिए में से एक है: इंडेक्स
संक्षेप में अनुक्रमित डेटाबेस में मदद मिलेगी अपने रिकॉर्ड के एक द्विआधारी खोज करने के लिए। कॉलम (या स्तंभों के सेट) पर किसी इंडेक्स के बिना डेटाबेस अक्सर टेबल स्कैन पर वापस आ जाएगा। एक टेबल स्कैन बहुत महंगा है क्योंकि इसमें प्रत्येक रिकॉर्ड को गिनती करना शामिल है।
यह वास्तव में कोई फर्क नहीं पड़ता कि इंडेक्स स्कैन के लिए डेटाबेस तालिका में कितने रिकॉर्ड हैं। (संतुलित) बाइनरी पेड़ की खोज के कारण रिकॉर्ड की मात्रा दोगुनी हो जाएगी केवल एक अतिरिक्त खोज चरण में परिणाम होगा।
अपनी तालिका की प्राथमिक कुंजी निर्धारित करें, एसक्यूएल स्वचालित रूप से उस कॉलम पर क्लस्टर्ड इंडेक्स रखेगा। क्लस्टर्ड इंडेक्स वास्तव में अच्छा प्रदर्शन करते हैं। इसके अतिरिक्त आप कॉलम पर गैर-क्लस्टर इंडेक्स रख सकते हैं जो अक्सर चयन, जॉइन, कहां, ग्रुप बाय और ऑर्डर द्वारा ऑर्डर में उपयोग किए जाते हैं। याद रखें कि इंडेक्स के पास एक निश्चित ओवरलैप है, कभी भी अपने क्लस्टर्ड इंडेक्स को गैर-क्लस्टर इंडेक्स में शामिल करने का प्रयास न करें।
भी दिलचस्प इंडेक्स पर भरने वाला कारक हो सकता है। क्या आप अपनी तालिका को पढ़ने के लिए अनुकूलित करना चाहते हैं (उच्च भरने वाला कारक - कम भंडारण, कम आईओ) या लिखने के लिए (कम भरने वाला कारक अधिक संग्रहण, आपके डेटाबेस पृष्ठों को कम पुनर्निर्माण)।
तीसरा: विभाजन
कारणों विभाजन का उपयोग करने में से एक अपने डेटा का उपयोग का अनुकूलन है। मान लें कि आपके पास 1 मिलियन रिकॉर्ड हैं जिनमें से 500,000 रिकॉर्ड अब प्रासंगिक नहीं हैं बल्कि संग्रह उद्देश्यों के लिए संग्रहीत हैं। इस मामले में आप तालिका को विभाजित करने और धीमी भंडारण पर 500,000 पुराने रिकॉर्ड और फास्ट स्टोरेज पर अन्य 500,000 रिकॉर्ड स्टोर करने का निर्णय ले सकते हैं।
को मापने के लिए
पता करने के लिए क्या होता है को मापने के लिए क्या अपने CPU और कब होता है में जानकारी पाने के लिए सबसे अच्छा तरीका है। माइक्रोसॉफ्ट एसक्यूएल सर्वर में प्रबंधन स्टूडियो में प्रोफाइलर और निष्पादन योजनाओं जैसे कुछ टूल्स हैं जो आपको आपकी क्वेरी की अवधि, पढ़ने/लिखने और सीपीयू उपयोग की अवधि बताएंगे। इसके अलावा निष्पादन योजना आपको बताएगी कि कौन से या अगर इंडेक्स का उपयोग किया जा रहा है। आपके आश्चर्य के लिए आपको एक टेबल स्कैन दिखाई दे सकता है हालांकि आपने इसकी अपेक्षा नहीं की थी।
हेह के लिए +1, मेरा मतलब यह नहीं था कि तालिका में केवल एक कॉलम है। मेरा मतलब है कि इसमें विशेष रूप से एक कॉलम है जिसे मैं इंडेक्स करना चाहता हूं। मैंने यह स्पष्ट करने के लिए प्रश्न संपादित किया है। –
उत्कृष्ट जवाब। अधिक विस्तृत। –
इंडेक्सिंग प्रभाव वही होगा, लेकिन जब आप दूसरी अनुक्रमणिका चाहते हैं तो क्या होगा? –