बी-ट्री बनाम हैश टेबल


103

MySQL में, एक इंडेक्स प्रकार एक बी-ट्री है, और एक ए-ट्री में एक तत्व का उपयोग लॉगरिदमिक amortized समय में है O(log(n))

दूसरी ओर, हैश तालिका में एक तत्व तक पहुँचने O(1)

डेटाबेस के अंदर डेटा तक पहुंचने के लिए बी-ट्री के बजाय हैश टेबल का उपयोग क्यों नहीं किया जाता है?


9
रेंज क्वेरीज़ का समर्थन नहीं करने के लिए हैश तालिकाओं, और ऑपरेशन के दौरान आसानी से विकसित या सिकुड़ नहीं सकते हैं।
हमखोलम ने मोनिका से

3
@HenningMakholm उन स्तंभों के लिए क्यों नहीं है, जिन्हें श्रेणी प्रश्नों की आवश्यकता नहीं है?
23

जवाबों:


115

आप हैशटेबल में केवल प्राथमिक कुंजी द्वारा तत्वों तक पहुंच सकते हैं। यह ट्री एल्गोरिथम ( ) के O(1)बजाय कीlog(n) तुलना में तेज़ है , लेकिन आप श्रेणियों ( बीच में xऔर सब कुछy ) का चयन नहीं कर सकते हैं । ट्री एल्गोरिदम इसका समर्थन करते हैं Log(n)जबकि हैश इंडेक्स का परिणाम पूर्ण तालिका स्कैन में हो सकता है O(n)। साथ ही हैश इंडेक्स का निरंतर ओवरहेड आमतौर पर बड़ा होता है ( जो थीटा नोटेशन का कोई कारक नहीं है, लेकिन यह अभी भी मौजूद है )। इसके अलावा पेड़ के एल्गोरिदम आमतौर पर बनाए रखने, डेटा, स्केल आदि के साथ बढ़ने में आसान होते हैं।

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

इसलिए यदि आपके पास छोटे आकार हैं, तो आपके पास छोटे तत्वों के लिए बहुत अधिक ओवरहेड है, बड़े आकार के परिणामस्वरूप आगे की स्कैनिंग होती है।

हैश टेबल एल्गोरिदम आमतौर पर बड़े पैमाने पर होते हैं, लेकिन स्केलिंग अक्षम हो सकती है।

वास्तव में स्केलेबल हैशिंग एल्गोरिदम हैं। मुझे मत पूछो कि यह कैसे काम करता है - इसका एक रहस्य मेरे लिए भी है। AFAIK वे स्केलेबल प्रतिकृति से विकसित हुए, जहां री-हैशिंग आसान नहीं है।

इसका नाम RUSH - R eplication U nder S calable H ashing है, और उन एल्गोरिदम को इस प्रकार RUSH एल्गोरिदम कहा जाता है।

हालाँकि, एक ऐसा बिंदु हो सकता है जहाँ आपका सूचकांक आपके हैश आकारों की तुलना में एक सहनीय आकार से अधिक हो और आपके पूरे सूचकांक को फिर से निर्मित करने की आवश्यकता हो। आमतौर पर यह कोई समस्या नहीं है, लेकिन विशाल-विशाल-विशाल डेटाबेस के लिए, इसमें कई दिन लग सकते हैं।

ट्री एल्गोरिदम के लिए व्यापार छोटा है और वे लगभग हर उपयोग के मामले में उपयुक्त हैं और इस प्रकार डिफ़ॉल्ट हैं।

हालाँकि यदि आपके पास बहुत सटीक उपयोग का मामला है और आप जानते हैं कि वास्तव में क्या और केवल क्या होना चाहिए, तो आप हैशिंग इंडेक्स का लाभ उठा सकते हैं।


क्या आप सूचकांक के पुनर्निर्माण पर अधिक व्याख्या कर सकते हैं? क्या इसका मतलब यह है कि x दिनों के लिए जब सूचकांक का पुनर्निर्माण होता है, उस अवधि के दौरान तालिका उपयोग के लिए पूरी तरह से अनुपलब्ध है?
पचेरियर

डेटाबेस सिस्टम के उपयोग पर निर्भर करता है। प्रश्न केवल सैद्धांतिक आकांक्षाओं को कवर करता है। मैं वास्तव में सामान्य डेटाबेस सिस्टम के कार्यान्वयन विवरण के बारे में नहीं जानता। लेकिन आमतौर पर ऐसा नहीं होना चाहिए क्योंकि दूसरा इंडेक्स तब बनाया जा सकता है जबकि पहला अभी भी इस्तेमाल किया जा रहा हो
The Surrican

"आप केवल तत्वों को उनकी प्राथमिक कुंजी द्वारा एक्सेस कर सकते हैं" - आपका मतलब उस कॉलम के मूल्य से है जिसमें सूचकांक सही है, चाहे वह प्राथमिक कुंजी हो या अन्य प्रकार का सूचकांक?
मार्क फिशर

90

दरअसल, ऐसा लगता है कि MySQL निम्नलिखित लिंक के अनुसार हैश टेबल या बी-ट्री दोनों तरह के इंडेक्स का उपयोग करता है ।

बी-ट्री और हैश टेबल का उपयोग करने के बीच का अंतर यह है कि पूर्व आपको उन अभिव्यक्तियों में स्तंभ तुलना का उपयोग करने की अनुमति देता है जो =,>,> =, <, <=, या BETWEEN ऑपरेटरों का उपयोग करते हैं, जबकि बाद वाले के लिए ही उपयोग किया जाता है समानता तुलना जो = या <=> ऑपरेटरों का उपयोग करती है।


9
यह अनुचित है। सबसे अच्छे उत्तर में सबसे कम अंक होते हैं।
Андрей Беньковский

6
यही वह है जिसकी तलाश में मैं हूं। मैंने इस बात की परवाह की कि तकनीकी विश्लेषण के बजाय यह मेरे प्रश्नों को कैसे प्रभावित करता है।
बेन डेहगन

हां! इस जवाब ने मुझे सबसे ज्यादा मदद की।
रॉन रॉस

बहुत बहुत धन्यवाद, लंबा समय हो गया है लेकिन यह उत्तर मुझे बहुत मदद करता है।
रेहम फ़ेमी

14

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


2
क्या db ऑनलाइन होने के दौरान रीशेज़िंग की जा सकती है? या क्या हमें सब कुछ फिर से करने के लिए मेज पर ताला लगाना होगा?
पचेरियर

1
पेसियर, MySQL के पास हैश सूचकांकों के लिए कोई समर्थन नहीं है। डेटाबेस के ऑनलाइन होने के दौरान, सूचकांक को पुन: प्राप्त करना सैद्धांतिक रूप से संभव है (पुराने इंडेक्स का उपयोग करते हुए, एक नया इंडेक्स बनाएं, जब यह पूरा हो जाए तो नए पर स्विच करें) लेकिन मुझे नहीं पता कि क्या लागू होने पर MySQL क्या करेगा? हैश संकेत देता है।
एमिल विक्रोत्तम

3
MySQL हैश अनुक्रमित का समर्थन करता है? : dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html
पेसियर

आप सही लग रहे हैं। वो मुझे खबर थी! मुझे विकास के साथ बने रहने की कोशिश करनी चाहिए :-) फिर आप अपने सवाल का जवाब देने में मुझसे कहीं बेहतर हैं, लेकिन जैसा कि मैंने कहा: यह सैद्धांतिक रूप से संभव है।
एमिल विक्रोत्तम

Btw, आप ऐसा क्यों कहते हैं कि "बीट्री को आसानी से डिस्क से बाहर किया जा सकता है लेकिन हैशटेबल नहीं हो सकता"? क्या कोई हैशटेबल डिस्क में संग्रहीत नहीं किया जा सकता है क्योंकि एक साधारण कुंजी लुकअप पर्याप्त होगा?
पचेरियर

6

मुझे लगता है कि हश्माप्स भी बड़े पैमाने पर नहीं हैं, और यह महंगा हो सकता है जब पूरे मानचित्र को फिर से व्यवस्थित करना होगा।


0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.