क्या बी-पेड़ और अन्य डेटा संरचनाएं ठोस राज्य ड्राइव के आगमन के साथ अप्रचलित हो जाएंगी?

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

क्या सॉलिड स्टेट ड्राइव (SSD) को पारंपरिक हार्ड डिस्क (HDD) को पूरी तरह से विस्थापित करना चाहिए, हालांकि, क्या हम कह सकते हैं कि B- पेड़ और विविधताएं अप्रचलित हो जाएंगी, डेटा संरचनाओं के लिए जगह दे रही है जो डायरेक्ट एक्सेस मेमोरी पर अधिक कुशल ऑपरेटिंग हैं? यदि हां, तो वे संरचनाएँ क्या होंगी? (जैसे, हैश टेबल, एवीएल पेड़)

database data-structures

— डैनियल स्कोको
स्रोत

क्या आप पूछ रहे हैं कि क्या वे डेटाबेस कार्यान्वयन के दृष्टिकोण से या सामान्य रूप से अप्रचलित हो जाएंगे क्योंकि डेटाबेस अनुप्रयोगों के बाहर बहुत सारे अन्य अनुप्रयोग हैं।

— पेमदास

डेटाबेस बिंदु से।

— डैनियल स्कोको

जवाबों:

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

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

वैसे भी, यदि आपके डेटाबेस को एसएसडी पर संग्रहीत किया जाता है, तो यह अभी भी एक ब्लॉक-ओरिएंटेड स्टोरेज डिवाइस है, और बी-पेड़ और अन्य मल्टीवे पेड़ों का उपयोग करने के लिए अभी भी एक फायदा है।

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

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

कैश-विस्मृत डेटा संरचनाओं में वैन एमड बोस लेआउट बहुत महत्वपूर्ण है।

MIT OpenCoursware एल्गोरिदम पाठ्यक्रम में कैश विस्मृत डेटा संरचनाओं के कुछ कवरेज शामिल हैं।

— steve314
स्रोत

दिलचस्प। आपने इस विषय का और अन्वेषण करने के लिए कुछ अच्छे संकेत दिए (कोई भी उद्देश्य नहीं!)। धन्यवाद।

— डैनियल स्कोको

इस MIT कोर्स में कैश विस्मृत डेटा संरचनाओं के बारे में जानकारी है।

— dan_waterworth

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

— यांग बो

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

— स्टीव 314

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

डिस्क पर सिर को सही स्थान पर ले जाएँ (~ 10ms)।
डिस्क को घुमाने के लिए प्रतीक्षा करें (10k rpm पर, इसका मतलब है कि प्रति सेकंड 167 घुमाव, लेकिन औसतन हम केवल आधे रोटेशन की प्रतीक्षा करते हैं, इसलिए ~ 3ms)।
ब्लॉक पढ़ें (~ 3ms)।
RAM में संशोधित करें। (~ 10ns)
फिर से डिस्क पर सिर को सही स्थान पर ले जाएँ (~ 10ms फिर से)।
डिस्क को फिर से घुमाने के लिए प्रतीक्षा करें (~ 3ms फिर से)।
ब्लॉक लिखें (~ 3ms)।

वह 10 + 3 + 3 + 10 + 3 + 3 = 34 एमएस है

डिस्क पर स्थिति की परवाह किए बिना, औसतन, SSD पर ऐसा करना केवल 1ms है।

और जब से एक हैशटेबल बहुत तेजी से होता है, हम सोच सकते हैं कि एक हैशटेबल एक बेहतर प्रतिस्थापन होगा।

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

देख:

अगला और पिछला क्यों महत्वपूर्ण है? कल्पना कीजिए कि सभी तत्व x से बड़े और z से छोटे हैं, आपको पिछले खोजने और अगले के साथ अनुक्रमित का उपयोग करने की आवश्यकता है।

खैर, एकमात्र समस्या यह है कि हमें आदेश संरक्षण क्षमताओं के साथ हैशटेबल्स नहीं मिले हैं। हो सकता है कि बी-ट्री में बाल्टी का आकार महत्वपूर्ण होगा लेकिन यह कैश विस्मृत एल्गोरिदम के साथ हल हो जाता है।

तो मैं कहूंगा कि यह एक ओपन एंडेड समस्या है।

— विल्हेम वान एंडे बोस
स्रोत

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

— स्टीव 314

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

— स्टीव