एक व्यापक पीके बनाम एक अलग सिंथेटिक कुंजी और यूक्यू का उपयोग करने के बीच प्रदर्शन के विचार क्या हैं?

Question

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

• सादगी; कोई बाहरी क्षेत्र और सिर्फ एक सूचकांक नहीं हैं
• क्लस्टरिंग तेजी से मर्ज जॉन्स और रेंज-आधारित फ़िल्टर के लिए अनुमति देता है

हालांकि, मैंने एक सिंथेटिक IDENTITY INTपीके बनाने के लिए किए गए एक मामले को सुना है , और इसके बजाय एक अलग UNIQUEबाधा के साथ व्यापार कुंजी को लागू करने के लिए । लाभ यह है कि संकीर्ण पीके बहुत छोटे माध्यमिक सूचकांकों के लिए बनाता है।

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

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

Comments

आप साइट पर अन्य सवालों के बीच यह या यह मददगार हो सकता है

— जैक कहते हैं कि topanswers.xyz की कोशिश करें

Answer 1

क्लस्टर किए गए सूचकांक के रूप में प्राकृतिक कुंजी का उपयोग करके कोई महत्वपूर्ण नुकसान नहीं है

• कोई गैर-क्लस्टर इंडेक्स नहीं हैं
• इस तालिका को संदर्भित करने वाली कोई विदेशी कुंजी नहीं (यह एक मूल पंक्ति है)

नीचे की ओर पृष्ठ विभाजन को बढ़ाया जाएगा क्योंकि अंत के बजाय डेटा आवेषण पूरे डेटा में वितरित किए जाएंगे।

जहाँ आपके पास FK या NC इंडेक्स होते हैं, एक संकीर्ण, संख्यात्मक, बढ़ते क्लस्टर इंडेक्स का उपयोग करने के फायदे हैं। आप केवल NC या FK प्रविष्टि प्रति डेटा के कुछ बाइट्स दोहराते हैं, जबकि व्यवसाय / प्राकृतिक कुंजी नहीं।

क्यों, Google से भी 5 लेख पढ़ें

नोट मैंने "प्राथमिक कुंजी" के उपयोग से बचा था।

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

अंत में, यह एक सरोगेट कुंजी है, लेकिन हर मेज पर आँख बंद करके समझ में नहीं आ सकता है : कई-कई तालिकाओं को एक की आवश्यकता नहीं है, या जहां माता-पिता की मेज से एक यौगिक कुंजी पर्याप्त होगी

Comments

अनुक्रमण के लिए संदर्भ मिसेज ट्रिप एक्सेलेंट लेखों के लिए +1।

— फैब्रिकियो अराजू

+1 इस बात के लिए कि प्रदर्शन का प्राथमिक कुंजी और सूचकांक के साथ करने के लिए सब कुछ नहीं है।

— nvogel

Answer 2

हालांकि मैं स्पष्ट बताते हुए जोखिम रखता हूं, सरोगेट कुंजी (आईडी नंबर) पर एक इंडेक्स उपयोगी है यदि आपको किसी आईडी नंबर से चीजों का पता लगाने की जरूरत है। उपयोगकर्ता आईडी नंबर से निपटने नहीं जा रहे हैं; वे मानव-पठनीय पाठ से निपटने जा रहे हैं। इसलिए आपको टेक्स्ट और उसके आईडी नंबर के आस-पास से गुजरना होगा, इसलिए यूजर इंटरफेस टेक्स्ट को प्रदर्शित कर सकता है और आईडी नंबर पर काम कर सकता है।

Dbms विदेशी कुंजी का समर्थन करने के लिए उस तरह के सूचकांक का उपयोग करेगा, यदि आप उन्हें इस तरह परिभाषित करते हैं।

आप कभी-कभी आईडी नंबरों को विदेशी कुंजी के रूप में उपयोग करके प्रदर्शन में सुधार कर सकते हैं, लेकिन यह एक पूर्ण सुधार नहीं है। हमारे ओएलटीपी सिस्टम पर, प्राकृतिक कुंजियों का उपयोग करने वाली विदेशी कुंजियों ने लगभग 130 के परीक्षण सूट पर आईडी संख्याओं का उपयोग करके विदेशी कुंजियों का बहिर्वाह किया है (मुझे लगता है कि) प्रतिनिधि प्रश्न। (क्योंकि महत्वपूर्ण सूचनाओं को अक्सर कुंजियों में ले जाया जाता है, प्राकृतिक कुंजियों का उपयोग करके बहुत सारे जोड़ से बचा जाता है।) मध्यिका गति 85 का कारक था (पंक्तियों का उपयोग करने के लिए आईडी संख्या का उपयोग करने वाले जोड़ों को 85 गुना अधिक समय लगता है)।

टेस्ट से पता चला कि आईडी संख्या में जुड़ने से हमारे डेटाबेस में प्राकृतिक कुंजी पर रीड की तुलना में तेजी से प्रदर्शन नहीं होगा, जब तक कि कुछ तालिकाएं कई लाखों पंक्तियों तक नहीं पहुंच जातीं। पंक्ति की चौड़ाई के साथ बहुत कुछ किया जाता है - व्यापक पंक्तियों का मतलब है कि एक पृष्ठ पर कम पंक्तियाँ फिट होती हैं, इसलिए आपको 'n' पंक्तियाँ प्राप्त करने के लिए अधिक पृष्ठों को पढ़ना होगा। लगभग सभी हमारे टेबल 5 एनएफ में हैं; अधिकांश टेबल काफी संकरी हैं।

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

Answer 3

मेरे पास एक संपूर्ण oltp डेटाबेस है जिसे क्लस्टरिंग + pk के लिए पहचान कॉलम का उपयोग करके डिज़ाइन किया गया है। यह इन्सर्ट / लाइक्स पर बहुत तेजी से काम करता है, लेकिन मैंने कुछ समस्याएं देखी हैं:
1. इंडेक्स फिल ऑप्शन बेकार है क्योंकि इन्सर्ट केवल इंडेक्स के अंत में होता है
। 2. अधिक स्टोरेज स्पेस। मेरे पास लाखों रिकॉर्ड के साथ टेबल हैं और 1 इंट खुद के द्वारा जगह लेता है। पीके के लिए एक पहचान स्तंभ के साथ प्रत्येक तालिका में व्यापार के लिए एक और सूचकांक होना चाहिए, इसलिए और भी अधिक भंडारण की आवश्यकता होती है।
3. स्केलेबिलिटी। यह सबसे खराब समस्या है। क्योंकि प्रत्येक इंसर्ट इंडेक्स के अंत में जाता है, प्रत्येक इंसर्ट केवल इंडेक्स के अंत (आवंटन, राइट्स के लिए io, आदि) पर जोर देगा। क्लस्टरिंग कुंजी के रूप में व्यवसाय कुंजी का उपयोग करके आप आवेषण को समान रूप से सूचकांक पर वितरित कर सकते हैं। इसका मतलब है कि आपने एक बड़ा हॉटस्पॉट खत्म कर दिया है। आप आसानी से एक सूचकांक के लिए अधिक फ़ाइलों का उपयोग कर सकते हैं, प्रत्येक फ़ाइल एक अलग ड्राइव पर, प्रत्येक ड्राइव अलग से काम कर रही है।

मैंने अपनी टेबल को एक पहचान कॉलम से प्राकृतिक कुंजी में बदलना शुरू कर दिया (शायद क्लस्टरिंग और पीके के लिए अलग)। यह अभी बेहतर महसूस करता है।

मैं निम्नलिखित सुझाव दूंगा (कम से कम एक oltp db के लिए):
1. एक क्लस्टरिंग कुंजी के रूप में सही क्रम में सही कॉलम का उपयोग करें जैसा कि सबसे लगातार प्रश्नों को अनुकूलित करने के लिए
2. एक पीके सही कॉलम का उपयोग करें जो आपके लिए समझ में आता है

यदि क्लस्टर की गई कुंजी सरल नहीं है और इसमें char (char [], varchar, nvarchar) शामिल हैं, तो मुझे लगता है कि उत्तर 'यह निर्भर करता है' है, आपको प्रत्येक मामले का व्यक्तिगत रूप से विश्लेषण करना चाहिए।

मैं निम्नलिखित सिद्धांत रखता हूं: सबसे खराब स्थिति को कम करते हुए सबसे सामान्य क्वेरी के लिए अनुकूलित करें।

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

Comments

आपकी "हॉटस्पॉट" अवधारणा एक मिथक है: dba.stackexchange.com/questions/1584/… और जब आप कहते हैं "यह अभी बेहतर लगता है।" क्या आपने बेंचमार्क किया?

— gbn

हां, लिखता है डिस्क में नहीं सीधे मेमोरी में। यदि आप किसी पृष्ठ पर 20 नई पंक्तियाँ लिखते हैं तो चेकपॉइंट होने पर डेटा फ़ाइल में केवल 1 भौतिक लिखना है।

— मर्देनी

सूचकांक के अंत तक सबकुछ लिखने वाले पर्याप्त आवेषण के साथ @mrdenny एक ही फ़ाइल में सभी io लिखने का अनुरोध भेजेगा। मुझे संदेह है कि सामान्य oltp लेनदेन का उपयोग करके इस परिदृश्य को पुन: पेश करना मुश्किल होगा, लेकिन कुछ विशेष परिदृश्यों जैसे कि बल्क / बैच डालने के रिकॉर्ड का उपयोग करना, कुछ व्यावसायिक डेटा को स्थानांतरित करने के लिए ssis का उपयोग करना आपको वहां मिलेगा।

— कैटालिन एडलर

@ user973156 हां सभी अनुरोध एक ही फाइल के लिए करते हैं, लेकिन राइट्स वास्तव में डिस्क तक नहीं जाते हैं जब तक कि चेकपॉइंट जो केवल हर मिनट (डिफ़ॉल्ट रूप से) होता है या जब लेखन बफर 50% भरा होता है। इससे कोई फर्क नहीं पड़ता कि आप इस नियम को लागू करने वाले डेटा को कैसे लिखते हैं।

— mrdenny

@ user973156 बेतरतीब ढंग से वितरित क्लस्टरिंग कुंजी का उपयोग करने से सूचकांक के विखंडन का कारण होगा। सूचकांक विखंडन प्रदर्शन समस्याओं का कारण होगा। और आपकी तालिका पर्याप्त बड़ी हो जाएगी कि अनुक्रमणिका डीफ़्रैग्मेन्टेशन करने में "लंबा समय" लगेगा, और लॉग स्पेस और संभावित टेम्पेडी स्पेस को खा जाएगा। जब मेरे पास किम्बर्ली ट्रिप जैसे लोग हैं, जो मुझसे कह रहे हैं कि यह एक अच्छा विचार है, तो मैं सुनता हूं। ( sqlskills.com/BLOGS/KIMBERLY/post/… )

— मैट एम

Answer 4

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

प्रदर्शन चयन और अनुक्रमणिका के प्रकार और अन्य भंडारण विकल्पों द्वारा निर्धारित किया जाता है और जिस तरह से प्रश्नों और कोड में कुंजियों का उपयोग किया जाता है।