प्रमुख विचार
मैं ढेर के लिए एक महत्वपूर्ण लाभ देखता हूं और एक संकुल टेबल के लिए, साथ ही एक तीसरा विचार जो किसी भी तरह से जा सकता है।
एक ढेर आपको अप्रत्यक्ष की एक परत बचाता है। अनुक्रमणिका में पंक्ति ID होती है, जो एक डिस्क स्थान पर सीधे (अच्छी तरह से, वास्तव में नहीं, बल्कि यथासंभव सीधे) इंगित करती है। इस प्रकार, एक ढेर के खिलाफ एक सूचकांक की तलाश एक क्लस्टर तालिका के खिलाफ लगभग आधे गैर-संकुल सूचकांक की लागत होनी चाहिए।
एक संकुल सूचकांक क्रमबद्ध किया जाता है, प्रति (लगभग) मुक्त सूचकांक के लिए धन्यवाद। क्योंकि डेटा के भौतिक क्रम में क्लस्टरिंग इंडेक्स परिलक्षित होता है, यह वास्तविक डेटा के शीर्ष पर अपेक्षाकृत कम जगह लेता है, जो कि आपको वैसे भी स्टोर करना होगा। क्योंकि यह शारीरिक रूप से आदेश दिया गया है, इस सूचकांक के खिलाफ एक रेंज स्कैन प्रारंभ बिंदु तक पहुंच सकता है और फिर अंत में बहुत कुशलता से ज़िप कर सकता है।
संकेत पर संदर्भ RIDs, जो 64 बिट हैं। जैसा कि उल्लेख किया गया है, गुच्छेदार मेज पर गैर-क्लस्टर किए गए सूचकांक क्लस्टरिंग कुंजी को संदर्भित करते हैं, जो छोटा (32-बिट INT), समान (64-बिट BIGINT), या बड़ा (48-बिट DATETIME2()प्लस 32-बिट) हो सकता है INT। या 128-बिट GUID)। जाहिर है एक व्यापक संदर्भ बड़े और अधिक महंगे सूचकांकों के लिए बनाता है।
जगह की जरूरतें
इन दो तालिकाओं के साथ:
CREATE TABLE TmpClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpClustered ADD CONSTRAINT PK_Tmp1 PRIMARY KEY CLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp1 ON TmpClustered (ID2)
CREATE TABLE TmpNonClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpNonClustered ADD CONSTRAINT PK_Tmp2 PRIMARY KEY NONCLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp2 ON TmpNonClustered (ID2)
... प्रत्येक 8.7 एम रिकॉर्ड के साथ आबादी, दोनों के लिए डेटा के लिए आवश्यक स्थान 150 एमबी था; संकुल तालिका सूचकांकों के लिए 120 एमबी, गैर-संकुल सारणी के सूचकांकों के लिए 310 एमबी। यह दर्शाता है कि क्लस्टर इंडेक्स RID की तुलना में संकरा है और क्लस्टरिंग इंडेक्स ज्यादातर "फ्रीबी" है। अनूठे सूचकांकों के बिना ID2, सूचकांक स्थान को गैर-संकुल तालिका (आधा, जैसा कि आप उम्मीद करेंगे) के लिए 155 एमबी की आवश्यकता होती है, लेकिन क्लस्टर पीके के लिए सिर्फ 150 केबी - कुछ भी नहीं।
तो 32-बिट इंडेक्स में 32-बिट फ़ील्ड का एक गैर-क्लस्टर इंडेक्स 32-बिट इंडेक्स (कुल 64 बिट, नाममात्र) के साथ 120 एमबी लिया गया, जबकि 64-बिट के साथ एक ढेर में 32-बिट फ़ील्ड का एक इंडेक्स RID (कुल 96 बिट्स, नाममात्र) ने 155 एमबी लिया, जो 50% की वृद्धि की तुलना में थोड़ा कम है वह भली-भांति 64-बिट से 96-बिट कुंजियों तक जाने की उम्मीद करेगा, लेकिन निश्चित रूप से ओवरहेड है जो आकार में प्रभावी अंतर को कम करता है।
दो तालिकाओं को आबाद करने और उनके सूचक बनाने के लिए प्रत्येक तालिका के लिए समान समय लिया गया। स्कैन या साइक्स से जुड़े सरल परीक्षण चलाने पर, मुझे टेबल्स के बीच कोई भौतिक प्रदर्शन अंतर नहीं मिला, जो कि Microsoft श्वेत पत्र से मेल खाता है जो gbn द्वारा सहायक रूप से जुड़ा हुआ है। कहा कागज अत्यधिक समवर्ती पहुँच के लिए एक महत्वपूर्ण अंतर दिखाती है; मुझे यकीन नहीं है कि ऐसा क्यों होता है, उम्मीद है कि उच्च-मात्रा वाले ओएलटीपी सिस्टम वाले मेरे अनुभव से अधिक कोई हमें बता सकता है।
यादृच्छिक चर-लंबाई डेटा के ~ 40 बाइट्स जोड़ने से इस तुल्यता को सराहनीय रूप से नहीं बदला गया। INTविस्तृत यूयूआईडी के साथ एस को प्रतिस्थापित करना या तो नहीं था (प्रत्येक तालिका को उसी सीमा तक धीमा कर दिया गया था)। आपका माइलेज अलग-अलग हो सकता है, लेकिन ज्यादातर मामलों में कि क्या इंडेक्स उपलब्ध है, किस तरह से ज्यादा महत्वपूर्ण है।
कण एवं टुकड़े
एक गैर-संकुलित सूचकांक के खिलाफ एक सीमा स्कैन करना - या तो क्योंकि तालिका एक ढेर है या सूचकांक क्लस्टर सूचकांक नहीं है - इसमें सूचकांक को स्कैन करना और फिर प्रत्येक हिट के लिए तालिका के खिलाफ एक खोज करना शामिल है। यह बहुत महंगा हो सकता है, इसलिए इसे कभी-कभी केवल टेबल स्कैन करना सस्ता पड़ता है। आप इसके चारों ओर एक कवरिंग इंडेक्स के साथ काम कर सकते हैं। यह लागू होता है कि क्या आपने अपनी तालिका को क्लस्टर किया है या नहीं।
जैसा कि @ बरन ने बताया, ढेर को कॉम्पैक्ट करने का कोई सरल तरीका नहीं है। हालांकि, यदि आपकी तालिका धीरे-धीरे समय के साथ बढ़ती है - एक बहुत ही सामान्य मामला - वहाँ बहुत कम कचरा होगा क्योंकि हटाए गए रिक्त स्थान को नए डेटा से भरा जाएगा।
ढेर बनाम गुच्छेदार तालिका चर्चाओं में से कई मैंने देखा है कि एक जिज्ञासु स्ट्रोमैन तर्क देते हैं कि अनुक्रमित के बिना एक ढेर एक अव्यवस्थित तालिका से नीच है, इसमें हमेशा टेबल स्कैन की आवश्यकता होती है। यह निश्चित रूप से सच है, लेकिन अधिक सार्थक तुलना "बड़ी अच्छी तरह से अनुक्रमित क्लस्टरिंग टेबल" बनाम "बड़ी अच्छी तरह से अनुक्रमित ढेर" है। यदि आपकी तालिका बहुत छोटी है या आप हमेशा टेबल स्कैन करने जा रहे हैं, तो यह बहुत मायने नहीं रखता है यदि आप इसे क्लस्टर करते हैं या नहीं।
क्योंकि क्लस्टर तालिका में प्रत्येक सूचकांक क्लस्टरिंग इंडेक्स को संदर्भित करता है, वे सभी सूचकांकों को कवर करने वाले प्रभाव में होते हैं। एक क्वेरी जो एक अनुक्रमित स्तंभ और क्लस्टरिंग कॉलम (s) को संदर्भित करता है, बिना किसी टेबल लुकअप के एक इंडेक्स स्कैन कर सकता है। यह आमतौर पर मूल्यवान नहीं है यदि आपका क्लस्टरिंग इंडेक्स एक सिंथेटिक कुंजी है, लेकिन अगर यह एक व्यवसाय कुंजी है जिसे आपको किसी भी तरह से पुनर्प्राप्त करना होगा, तो यह एक अच्छी सुविधा है।
टी एल; डॉ
मैं डेटा वेयरहाउसिंग आदमी हूं, ओएलटीपी विशेषज्ञ नहीं। वास्तव में तालिकाओं के लिए मैं लगभग हमेशा फ़ील्ड पर एक क्लस्टरिंग इंडेक्स का उपयोग करता हूं, जिसमें अधिकतर रेंज स्कैन की आवश्यकता होती है, आमतौर पर एक दिनांक फ़ील्ड। आयाम तालिकाओं के लिए I PK पर क्लस्टर करता है, इसलिए यह तथ्य तालिकाओं के विरुद्ध मर्ज जॉइन के लिए प्रस्तुत किया जाता है।
क्लस्टरिंग सूचकांकों का उपयोग करने के कई कारण हैं, लेकिन यदि उन कारणों में से कोई भी लागू नहीं होता है, तो ओवरहेड सार्थक नहीं हो सकता है। मुझे संदेह है कि "हमने हमेशा इसे इस तरह से किया है" और सार्वभौमिक रूप से क्लस्टर इंडेक्स का उपयोग करने वाले लोगों के पीछे "यह सिर्फ सबसे अच्छा अभ्यास है"। अपने डेटा और अपने लोड दोनों के साथ प्रयास करें और देखें कि सबसे अच्छा क्या काम करता है।