एक क्लस्टर सूचकांक की कहानी

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

वास्तव में, यह जानवर पूरी तरह से निडर है और यहां तक ​​कि बहुत उपयोगी है। आइए जानने की कोशिश करें कि इसकी आवश्यकता क्यों है और इसका उपयोग कैसे करना है।

फ़ाइलें, पृष्ठ, RID

किसी भी तालिका का डेटा भौतिक रूप से डेटाबेस फ़ाइल में संग्रहीत होता है। डेटाबेस फ़ाइल पृष्ठों (पेज) में विभाजित है - सर्वर के लिए तार्किक भंडारण इकाइयाँ। MS SQL सर्वर के एक पृष्ठ का आकार 8 किलोबाइट (8192 बाइट्स) होना चाहिए, जिसमें से 8060 बाइट्स डेटा के लिए दिए गए हैं। प्रत्येक पंक्ति के लिए, आप इसका भौतिक पता, तथाकथित पंक्ति ID (RID) निर्दिष्ट कर सकते हैं: यह किस फ़ाइल में स्थित है, इस फ़ाइल के पृष्ठ के किस क्रम में, पृष्ठ के किस स्थान पर है। संपूर्ण तालिका एक पृष्ठ प्रदान करती है - एक पृष्ठ पर केवल एक तालिका का डेटा हो सकता है। इसके अलावा, यदि किसी पंक्ति को पढ़ना / लिखना आवश्यक है, तो सर्वर पूरे पृष्ठ को पढ़ता / लिखता है, क्योंकि यह बहुत तेज है।

बी-ट्री इंडेक्स की व्यवस्था कैसे की जाती है?

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



जब आप तालिका में एक प्रविष्टि जोड़ते हैं, तो आपको इसे सूचकांक में भी जोड़ना होगा। एक नया सूचकांक प्रविष्टि जो तालिका प्रविष्टि को संदर्भित करता है उसे लीफ लेवल पेज में डाला जाता है। यह पता चल सकता है कि इस पृष्ठ पर कोई खाली जगह नहीं है। तब:

1. सूचकांक को एक नया पृष्ठ आवंटित किया जाता है - पत्ती के स्तर पर भी।
2. पिछले पृष्ठ की प्रविष्टियों में से आधे को नए में स्थानांतरित कर दिया गया है (ताकि उन्हें क्रमिक रूप से जोड़ते समय, आपको ऐसी स्थिति में नहीं चलना चाहिए जहां आपको अगली पंक्ति के लिए फिर से पृष्ठ का चयन करना होगा)। एक नया पृष्ठ क्षैतिज लिंक में एम्बेड किया गया है: पिछला अगला के बजाय, पिछला नया अगला लिंक कॉन्फ़िगर किया गया है।
3. संबंधित कुंजी के साथ मूल पृष्ठ में एक नए पृष्ठ का लिंक दिया गया है। उसी समय, मूल पृष्ठ ओवरफ्लो हो सकता है - फिर डेटा पृथक्करण की प्रक्रिया उच्च स्तर पर दोहराई जाएगी। यदि अतिप्रवाह बहुत ऊपर तक पहुंच जाता है, तो रूट पेज दो में विभाजित हो जाएगा, और एक नई जड़ दिखाई देगी, और पेड़ की ऊंचाई 1 से बढ़ जाएगी।

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

ढेर छोटा है

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

मान लीजिए कि एक तालिका में 200 हजार प्रविष्टियाँ हैं, और प्रत्येक पृष्ठ पर 48 से 52 प्रविष्टियाँ रखी गई हैं। हम मानते हैं कि तालिका में 4000 पृष्ठ हैं। मान लीजिए कि हमें उन सभी रिकॉर्डों को खोजने की आवश्यकता है जिनमें [शहर] क्षेत्र का मान 'पर्म' है। हम यह भी मानते हैं कि उनमें से केवल 3 हैं, लेकिन हम इसके बारे में अभी तक नहीं जानते हैं।

सर्वर को सभी 4,000 पृष्ठों को स्कैन करना होगा। यहां तक ​​कि अगर सर्वर को सभी 3 प्रविष्टियां मिलती हैं, तो भी इसे अंत तक जाना होगा - इस बात की कोई गारंटी नहीं है कि अधिक प्रविष्टियों की आवश्यकता नहीं है। इसलिए, अनुरोध को पूरा करने के लिए, आपको 4,000 तार्किक पृष्ठ पढ़ने की आवश्यकता है।
और अगर हमारे पास एक सूचकांक है जिसमें आप एक द्विआधारी खोज के साथ खोज कर सकते हैं - कहते हैं, ऊंचाई 3 का पेड़? तब सर्वर को पहले रिकॉर्ड का पता खोजने के लिए सूचकांक पृष्ठों की 3 रीडिंग की आवश्यकता होगी। दूसरे और तीसरे रिकॉर्ड के पते अगल-बगल में होंगे - या तो एक ही पेज में या निम्नलिखित में: इंडेक्स पेज लिंक के साथ क्षैतिज रूप से जुड़े होते हैं। यानी, अधिकतम 4 रीडिंग के बाद, सर्वर संभवतः तीनों रिकॉर्ड्स की RID जानता है। यदि आप बहुत अशुभ हैं, तो सभी 3 प्रविष्टियाँ विभिन्न पृष्ठों में हैं। इस प्रकार, यदि पृष्ठ के 7 तार्किक रीड के बाद एक सूचकांक है, तो सभी 3 रिकॉर्ड संभवतः मिल जाएंगे। 7 बनाम 4000 - प्रभावशाली।

लेकिन यह बहुत अच्छा होगा जब कुछ रिकॉर्ड होंगे। और अगर यह 'पर्म' नहीं है, लेकिन 'मॉस्को', और आवश्यक रिकॉर्ड 3 नहीं, बल्कि 20 हजार हैं? यह बहुत अधिक नहीं है, रिकॉर्ड की कुल संख्या का केवल 10 प्रतिशत। लेकिन तस्वीर इतनी जल्दी बदरंग नहीं हो रही है।

3 रीडिंग के लिए, सर्वर को पहला रिकॉर्ड मिलेगा। और फिर उसे एक पंक्ति प्राप्त करने के लिए 20 हजार आरआईडी पढ़ने और पृष्ठ को 20 हजार बार पढ़ने की आवश्यकता होगी: हमें याद है कि सर्वर केवल पूरे पृष्ठों में डेटा पढ़ता है। यह अच्छी तरह से पता लगा सकता है कि आवश्यक रिकॉर्ड पूरे तालिका में बिखरे हुए हैं, और 20 हजार तार्किक रीडिंग सुनिश्चित करने के लिए, डिस्क से अधिकांश पृष्ठों को पढ़ना आवश्यक होगा। फिर भी अच्छा है, अगर सभी नहीं। 4 हजार तार्किक रीडिंग के बजाय, हमें 20 हजार मिलते हैं।

बहुत कम मान प्राप्त करने पर इंडेक्स बहुत अच्छा काम करता है, लेकिन बड़ी रेंज में जाने पर यह अच्छी तरह से काम नहीं करता है।

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

लेकिन पर्वतमाला के बारे में क्या?

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

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

आइए हम अपने मॉडल उदाहरण पर लौटते हैं। मान लें कि किसी क्वेरी के लिए आवश्यक कॉलम इंडेक्स में शामिल हैं। सादगी के लिए, मान लीजिए कि ठीक 50 रिकॉर्ड (कुंजी, जोड़े गए कॉलम, रिकॉर्ड के लिंक) सूचकांक के पत्ती पृष्ठ में आते हैं। फिर 20 हजार रिकॉर्ड को स्कैन करने के लिए केवल 400 इंडेक्स पेज पढ़ने की आवश्यकता होगी - एक गैर-कवरिंग इंडेक्स के लिए 20 हजार तार्किक रीडिंग के बजाय।

20 हजार के मुकाबले 400 - अंतर 50 गुना है। यह बिना कारण के नहीं है कि क्वेरी ऑप्टिमाइज़र इंडेक्स में कुछ स्तंभों सहित प्रस्ताव करना पसंद करता है।
या हो सकता है कि यह सभी स्तंभों को सूचकांक में जोड़ने के लायक है? फिर किसी भी अनुरोध को सूचकांक द्वारा कवर किया जाएगा। इसके अलावा, तब RID की पत्तियों में भी आवश्यकता नहीं होती है, क्योंकि इस तरह के सूचकांक किसी भी डेटा के लिए तालिका में नहीं जाएंगे, इसमें सब कुछ हाथ में है। हां, इस मामले में, तालिका की अब आवश्यकता नहीं है!

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

पकड़ कहां है?

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

एक दूसरा कैच है। एक संकुल सूचकांक के साथ, RID को अब पंक्ति पते के रूप में उपयोग नहीं किया जा सकता है। क्लस्टर किए गए अनुक्रमणिका में प्रविष्टियाँ क्रमबद्ध हैं (भौतिक रूप से - पृष्ठ के भीतर, तार्किक रूप से - पृष्ठों के बीच क्षैतिज लिंक के साथ)। जब आप कोई रिकॉर्ड जोड़ते हैं या कुंजी फ़ील्ड बदलते हैं, तो रिकॉर्ड सही जगह पर ले जाता है - अक्सर पृष्ठ के भीतर, लेकिन किसी अन्य पेज पर जाना भी संभव है। दूसरे शब्दों में, क्लस्टर सूचकांक में आरआईडी विशिष्ट रूप से रिकॉर्ड की पहचान करने के लिए बंद हो जाता है । इसलिए, पंक्ति के पते के रूप में जो इसे विशिष्ट रूप से पहचानता है, संकुल कुंजी की कुंजी का उपयोग किया जाता है।

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

एक गुच्छे पर निर्मित गैर-संकुल सूचकांक द्वारा 20 हजार रिकॉर्ड की श्रेणी को स्कैन करने की कल्पना करें। अब आपको ज्ञात RID के अनुसार पृष्ठ की 20 हजार तार्किक रीडिंग करने की आवश्यकता नहीं है, लेकिन एक क्लस्टर इंडेक्स में 20 हजार खोजें - और प्रत्येक खोज के लिए 3, या इससे भी अधिक, तार्किक रीडिंग की आवश्यकता होगी।

और अगर क्लस्टर इंडेक्स की कुंजी अद्वितीय नहीं है? और ऐसा नहीं होता है। सर्वर के लिए, यह आवश्यक रूप से अद्वितीय है। यदि उपयोगकर्ता ने एक गैर-अद्वितीय क्लस्टर इंडेक्स बनाने के लिए कहा, तो सर्वर प्रत्येक कुंजी को 4-बाइट पूर्णांक देगा, जो कुंजी की विशिष्टता को सुनिश्चित करेगा। यह उपयोगकर्ताओं के लिए पारदर्शी रूप से किया जाता है: सर्वर न केवल उन्हें संख्या का सही मूल्य बताता है, बल्कि इसकी उपस्थिति का तथ्य भी नहीं बताता है। रिकॉर्ड की स्पष्ट पहचान की संभावना के लिए कुंजी की विशिष्टता की सटीक आवश्यकता है - ताकि क्लस्टर इंडेक्स की कुंजी पंक्ति के पते के रूप में काम कर सके।

तो करें या न करें?

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

निम्नलिखित चयन एल्गोरिथ्म प्रस्तावित है:

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

उपसंहार। वह केवल एक ही क्यों है?

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

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

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

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

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

अपने अनुक्रमणिका क्लस्टरिंग में सभी को शुभकामनाएँ!