हे हाबर! म तपाईंको ध्यानाकर्षणमा लेखको अनुवाद प्रस्तुत गर्दछु
"रिलेसनल डाटाबेसले कसरी काम गर्छ".

जब यो रिलेशनल डाटाबेस को लागी आउँदछ म मद्दत गर्न सक्दिन तर केहि छुटेको छ जस्तो लाग्छ। तिनीहरू सबै ठाउँमा प्रयोग गरिन्छ। त्यहाँ धेरै फरक डाटाबेसहरू उपलब्ध छन्, सानो र उपयोगी SQLite देखि शक्तिशाली Teradata सम्म। तर डाटाबेसले कसरी काम गर्छ भनेर व्याख्या गर्ने केही लेखहरू मात्र छन्। त्यहाँ कति थोरै नतिजाहरू छन् भनेर हेर्नको लागि तपाईंले "howdoesarelationaldatabasework" प्रयोग गरेर आफैलाई खोज्न सक्नुहुन्छ। यसबाहेक, यी लेखहरू छोटो छन्। यदि तपाइँ भर्खरको बजी टेक्नोलोजीहरू (बिगडेटा, NoSQL वा JavaScript) खोज्दै हुनुहुन्छ भने, तपाइँ तिनीहरूले कसरी काम गर्छन् भनेर व्याख्या गर्ने थप गहन लेखहरू फेला पार्नुहुनेछ।

के रिलेसनल डाटाबेसहरू धेरै पुरानो र धेरै बोरिंग विश्वविद्यालय पाठ्यक्रमहरू, अनुसन्धान पत्रहरू र पुस्तकहरू बाहिर व्याख्या गर्न सकिन्छ?

एक विकासकर्ताको रूपमा, मैले नबुझेको कुरा प्रयोग गरेर मलाई घृणा गर्छु। र यदि डाटाबेसहरू 40 वर्ष भन्दा बढीको लागि प्रयोग गरिएको छ भने, त्यहाँ एक कारण हुनुपर्छ। वर्षौंको दौडान, मैले हरेक दिन प्रयोग गर्ने यी अनौठो ब्ल्याक बक्सहरूलाई साँच्चै बुझ्न सयौं घण्टा खर्च गरेको छु। सम्बन्धगत डाटाबेस धेरै रोचक किनभने तिनीहरू उपयोगी र पुन: प्रयोज्य अवधारणाहरूमा आधारित। यदि तपाइँ एक डाटाबेस बुझ्न रुचि राख्नुहुन्छ, तर यो व्यापक विषय मा जान को लागी समय वा झुकाव कहिल्यै छैन, तपाइँ यो लेख को मजा लिनु पर्छ।

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

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

किनकि यो लामो र प्राविधिक लेख हो जसमा धेरै एल्गोरिदम र डेटा संरचनाहरू समावेश छन्, यसलाई पढ्नको लागि आफ्नो समय लिनुहोस्। केही अवधारणाहरू बुझ्न गाह्रो हुन सक्छ; तपाईं तिनीहरूलाई छोड्न सक्नुहुन्छ र अझै पनि सामान्य विचार प्राप्त गर्न सक्नुहुन्छ।

तपाईहरु मध्ये अधिक जानकारहरु को लागी, यो लेख 3 भागहरु मा विभाजित छ:

• निम्न-स्तर र उच्च-स्तर डाटाबेस घटकहरूको सिंहावलोकन
• क्वेरी अप्टिमाइजेसन प्रक्रियाको अवलोकन
• लेनदेन र बफर पूल व्यवस्थापन को सिंहावलोकन

आधारभूत कुराहरूमा फर्कनुहोस्

वर्ष पहिले (गालेक्सीमा टाढा, धेरै टाढा...), विकासकर्ताहरूले तिनीहरूले कोडिङ गरिरहेका अपरेसनहरूको सङ्ख्या ठ्याक्कै थाहा पाउनुपर्थ्यो। उनीहरूले आफ्नो एल्गोरिदम र डाटा संरचनाहरू हृदयबाट थाहा पाएका थिए किनभने उनीहरूले आफ्नो ढिलो कम्प्युटरहरूको CPU र मेमोरी बर्बाद गर्न खर्च गर्न सक्दैनन्।

यस भागमा, म तपाईंलाई यी केही अवधारणाहरू सम्झाउनेछु किनभने तिनीहरू डाटाबेस बुझ्न आवश्यक छन्। म अवधारणा पनि प्रस्तुत गर्नेछु डाटाबेस सूचकांक.

O(1) बनाम O(n2)

आजकल, धेरै विकासकर्ताहरूले एल्गोरिदमको समय जटिलताको वास्ता गर्दैनन्... र तिनीहरू सही छन्!

तर जब तपाईं धेरै डाटासँग व्यवहार गर्दै हुनुहुन्छ (म हजारौं कुरा गरिरहेको छैन) वा यदि तपाईं मिलिसेकेन्डमा संघर्ष गर्दै हुनुहुन्छ भने, यो अवधारणा बुझ्न महत्त्वपूर्ण हुन्छ। र तपाईले कल्पना गर्न सक्नुहुन्छ, डाटाबेसहरूले दुबै अवस्थाहरूसँग व्यवहार गर्नुपर्छ! म तपाईंलाई बिन्दु पार गर्न आवश्यक भन्दा बढी समय खर्च गर्न लगाउने छैन। यसले हामीलाई पछि लागतमा आधारित अनुकूलनको अवधारणा बुझ्न मद्दत गर्नेछ (लागत आधारित अनुकूलन).

अवधारणा

एल्गोरिथ्मको समय जटिलता एल्गोरिदमले डेटाको दिइएको मात्राको लागि पूरा गर्न कति समय लिन्छ भनेर हेर्न प्रयोग गरिन्छ। यो जटिलता वर्णन गर्न, हामी ठूलो O गणितीय नोटेशन प्रयोग गर्दछौं। यो नोटेशन एक प्रकार्यको साथ प्रयोग गरिन्छ जसले निर्दिष्ट संख्याको इनपुटहरूको लागि एल्गोरिदमलाई कति अपरेशनहरू चाहिन्छ भनेर वर्णन गर्दछ।

उदाहरणका लागि, जब म भन्छु "यो एल्गोरिदममा जटिलता O(some_function()) छ", यसको मतलब यो हो कि एल्गोरिदमलाई निश्चित मात्रामा डाटा प्रशोधन गर्न some_function(a_certain_amount_of_data) अपरेशनहरू आवश्यक हुन्छ।

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

यस ग्राफमा तपाईले विभिन्न प्रकारका एल्गोरिथ्म समय जटिलताहरूको लागि इनपुट डेटाको मात्रा बनाम अपरेसनहरूको संख्या देख्न सक्नुहुन्छ। मैले तिनीहरूलाई प्रदर्शन गर्न लगरिदमिक स्केल प्रयोग गरें। अर्को शब्दमा, डाटाको मात्रा 1 देखि 1 बिलियनमा छिटो बढ्छ। हामी देख्न सक्छौं कि:

• O(1) वा स्थिर जटिलता स्थिर रहन्छ (अन्यथा यसलाई स्थिर जटिलता भनिदैन)।
• O(लग(n)) अर्बौं डाटा भए पनि न्यून रहन्छ.
• सबैभन्दा ठूलो कठिनाई - O(n2), जहाँ सञ्चालनको संख्या द्रुत रूपमा बढ्छ.
• अन्य दुई जटिलताहरू चाँडै बढ्छन्।

उदाहरण

थोरै मात्रामा डाटाको साथ, O(1) र O(n2) बीचको भिन्नता नगण्य छ। उदाहरण को लागी, मानौं तपाईसँग एउटा एल्गोरिथ्म छ जुन 2000 तत्वहरू प्रशोधन गर्न आवश्यक छ।

• O(1) एल्गोरिदमले तपाईंलाई 1 सञ्चालन खर्च गर्नेछ
• O(log(n)) एल्गोरिदमले तपाईंलाई 7 कार्यहरू खर्च गर्नेछ
• O(n) एल्गोरिथ्मले तपाईंलाई २,००० सञ्चालन खर्च गर्नेछ
• O(n*log(n)) एल्गोरिदमले तपाईंलाई 14 सञ्चालन खर्च गर्नेछ
• O(n2) एल्गोरिदमले तपाईंलाई 4 सञ्चालन खर्च गर्नेछ

O(1) र O(n2) बीचको भिन्नता ठूलो देखिन्छ (4 मिलियन अपरेशनहरू) तर तपाईंले अधिकतम 2 ms गुमाउनुहुनेछ, केवल आफ्नो आँखा झिम्काउने समय। वास्तवमा, आधुनिक प्रोसेसरहरूले प्रक्रिया गर्न सक्छन् प्रति सेकेन्ड लाखौं अपरेशनहरू। यसैले धेरै आईटी परियोजनाहरूमा प्रदर्शन र अप्टिमाइजेसन एक मुद्दा होइन।

मैले भनेझैं, डेटाको ठूलो मात्रामा काम गर्दा यो अवधारणा जान्न अझै महत्त्वपूर्ण छ। यदि यस पटक एल्गोरिदमले 1 तत्वहरू प्रशोधन गर्नुपर्छ (जुन डाटाबेसको लागि त्यति धेरै होइन):

• O(1) एल्गोरिदमले तपाईंलाई 1 सञ्चालन खर्च गर्नेछ
• O(log(n)) एल्गोरिदमले तपाईंलाई 14 कार्यहरू खर्च गर्नेछ
• O(n) एल्गोरिथ्मले तपाईंलाई 1 सञ्चालन खर्च गर्नेछ
• O(n*log(n)) एल्गोरिथ्मले तपाईंलाई 14 सञ्चालन खर्च गर्नेछ।
• O(n2) एल्गोरिथ्मले तपाईंलाई 1 सञ्चालन खर्च गर्नेछ।

मैले गणित गरेको छैन, तर म भन्न चाहन्छु कि O(n2) एल्गोरिदमको साथ तपाईंसँग कफी पिउने समय छ (दुई पनि!)। यदि तपाईंले डेटा भोल्युममा अर्को ० थप्नुभयो भने, तपाईंसँग निदाउनको लागि समय हुनेछ।

गहिराइमा जाऔं

सन्दर्भको लागि:

• राम्रो ह्यास तालिका लुकअपले O(1) मा एउटा तत्व फेला पार्छ।
• राम्रो सन्तुलित रूखको खोजी गर्दा O(log(n)) मा परिणामहरू उत्पन्न हुन्छ।
• एरे मार्फत खोजी गर्दा O(n) मा परिणामहरू उत्पादन गर्दछ।
• उत्तम क्रमबद्ध एल्गोरिदमको जटिलता O(n*log(n)) छ।
• खराब क्रमबद्ध एल्गोरिदममा जटिलता O(n2) छ।

नोट: निम्न भागहरूमा हामी यी एल्गोरिदम र डेटा संरचनाहरू देख्नेछौं।

त्यहाँ एल्गोरिथ्म समय जटिलता को धेरै प्रकार छन्:

• औसत केस परिदृश्य
• उत्तम केस परिदृश्य
• र सबैभन्दा खराब अवस्था

समय जटिलता प्राय: सबैभन्दा खराब अवस्था हो।

मैले एल्गोरिदमको समय जटिलताको बारेमा मात्र कुरा गरिरहेको थिएँ, तर जटिलता यसमा पनि लागू हुन्छ:

• एल्गोरिथ्मको मेमोरी खपत
• डिस्क I/O खपत एल्गोरिथ्म

निस्सन्देह, त्यहाँ n2 भन्दा खराब जटिलताहरू छन्, उदाहरणका लागि:

• n4: यो भयानक छ! उल्लेख गरिएका केही एल्गोरिदमहरूमा यो जटिलता छ।
• 3n: यो अझ खराब छ! हामीले यस लेखको बीचमा देख्ने एउटा एल्गोरिदममा यो जटिलता छ (र यो वास्तवमा धेरै डेटाबेसहरूमा प्रयोग गरिन्छ)।
• factorial n: तपाईले थोरै मात्रामा डाटाको साथ पनि तपाईको नतिजा कहिले पनि प्राप्त गर्नुहुने छैन।
• nn: यदि तपाईंले यो जटिलताको सामना गर्नुभयो भने, तपाईंले आफैलाई सोध्नु पर्छ कि यो साँच्चै तपाईंको गतिविधिको क्षेत्र हो ...

नोट: मैले तपाईंलाई ठूलो O पदनामको वास्तविक परिभाषा दिएको छैन, केवल एक विचार। तपाईं यो लेख मा पढ्न सक्नुहुन्छ विकिपेडिया वास्तविक (एसिम्प्टोटिक) परिभाषाको लागि।

मर्ज क्रम

तपाईंले संग्रह क्रमबद्ध गर्न आवश्यक हुँदा के गर्नुहुन्छ? के? तपाईंले sort() प्रकार्यलाई कल गर्नुहुन्छ... ठीक छ, राम्रो जवाफ... तर डाटाबेसको लागि, तपाईंले यो sort() प्रकार्यले कसरी काम गर्छ भनेर बुझ्नुपर्छ।

त्यहाँ धेरै राम्रो क्रमबद्ध एल्गोरिदमहरू छन्, त्यसैले म सबैभन्दा महत्त्वपूर्णमा फोकस गर्नेछु: क्रमबद्ध मर्ज। तपाईंले अहिले डेटा क्रमबद्ध गर्नु किन उपयोगी छ भन्ने कुरा बुझ्न सक्नुहुन्न, तर तपाईंले क्वेरी अप्टिमाइजेसन भाग पछि गर्नुपर्छ। यसबाहेक, मर्ज क्रम बुझ्दा हामीलाई सामान्य डाटाबेस जोइन अपरेसन भनिन्छ भनेर बुझ्न मद्दत गर्नेछ मर्ज सामेल (एकीकरण संघ).

मर्ज गर्नुहोस्

धेरै उपयोगी एल्गोरिदमहरू जस्तै, मर्ज क्रम एउटा चालमा निर्भर गर्दछ: N/2 आकारको 2 क्रमबद्ध एरेहरूलाई N-तत्व क्रमबद्ध एरेमा संयोजन गर्दा N सञ्चालनहरू मात्र खर्च हुन्छ। यो कार्यलाई मर्जर भनिन्छ।

एक साधारण उदाहरण संग यसको अर्थ के हेरौं:

यो आंकडाले देखाउँछ कि अन्तिम क्रमबद्ध 8-तत्व एरे निर्माण गर्न, तपाईंले 2 4-तत्व arrays मा एक पटक मात्र पुनरावृत्ति गर्न आवश्यक छ। किनकि दुबै 4-तत्व arrayहरू पहिले नै क्रमबद्ध छन्:

• 1) तपाइँ दुई एरे मा दुबै वर्तमान तत्वहरू तुलना गर्नुहुन्छ (सुरुमा वर्तमान = पहिलो)
• 2) त्यसपछि यसलाई 8 तत्व एरेमा राख्नको लागि सबैभन्दा सानो लिनुहोस्
• 3) र एरेमा अर्को तत्वमा जानुहोस् जहाँ तपाईंले सबैभन्दा सानो तत्व लिनुभयो
• र 1,2,3 दोहोर्याउनुहोस् जब सम्म तपाईं arrays को अन्तिम तत्व सम्म पुग्नुहुन्न।
• त्यसपछि तपाईले अन्य एरेका बाँकी तत्वहरूलाई 8 तत्व एरेमा राख्नको लागि लिनुहुन्छ।

यसले काम गर्दछ किनभने दुबै 4-तत्व एरेहरू क्रमबद्ध छन् र त्यसैले तपाईंले ती एरेहरूमा "फिर्ता जानु" पर्दैन।

अब जब हामीले चाल बुझ्यौं, मर्जको लागि मेरो स्यूडोकोड यहाँ छ:

array mergeSort(array a)
   if(length(a)==1)
      return a[0];
   end if

   //recursive calls
   [left_array right_array] := split_into_2_equally_sized_arrays(a);
   array new_left_array := mergeSort(left_array);
   array new_right_array := mergeSort(right_array);

   //merging the 2 small ordered arrays into a big one
   array result := merge(new_left_array,new_right_array);
   return result;

मर्ज क्रमले समस्यालाई साना समस्याहरूमा तोड्छ र त्यसपछि मूल समस्याको परिणाम प्राप्त गर्न साना समस्याहरूको नतिजा फेला पार्छ (नोट: यस प्रकारको एल्गोरिदमलाई विभाजन र विजय भनिन्छ)। यदि तपाईंले यो एल्गोरिदम बुझ्नुभएको छैन भने, चिन्ता नगर्नुहोस्; पहिलो पटक देख्दा बुझिन । यदि यसले तपाईंलाई मद्दत गर्न सक्छ भने, म यो एल्गोरिदमलाई दुई-चरण एल्गोरिथ्मको रूपमा देख्छु:

• विभाजन चरण, जहाँ array सानो arrays मा विभाजित छ
• क्रमबद्ध चरण हो जहाँ साना एरेहरू जोडिएको हुन्छ (युनियन प्रयोग गरेर) ठूलो एरे बनाउनको लागि।

विभाजन चरण

विभाजन चरणमा, एरेलाई 3 चरणहरूमा एकात्मक एरेहरूमा विभाजित गरिएको छ। चरणहरूको औपचारिक संख्या log(N) (N=8, log(N) = 3 देखि) हो।

मलाई यो कसरी थाहा छ?

म जीनियस हुँ! एक शब्द मा - गणित। विचार यो हो कि प्रत्येक चरणले मूल एरेको साइजलाई 2 द्वारा विभाजित गर्दछ। चरणहरूको संख्या भनेको तपाईंले मूल एरेलाई दुईमा विभाजन गर्न सक्नु भएको संख्या हो। यो एक लोगारिदम (आधार 2) को सही परिभाषा हो।

क्रमबद्ध चरण

क्रमबद्ध चरणमा, तपाइँ एकात्मक (एकल-तत्व) arrays सँग सुरु गर्नुहुन्छ। प्रत्येक चरणको बखत तपाईले धेरै मर्ज अपरेशनहरू लागू गर्नुहुन्छ र कुल लागत N = 8 अपरेशनहरू हो:

• पहिलो चरणमा तपाइँसँग 4 मर्जहरू छन् जसमा प्रत्येक 2 अपरेशनहरू खर्च हुन्छन्
• दोस्रो चरणमा तपाइँसँग 2 मर्जहरू छन् जसमा प्रत्येक 4 अपरेशनहरू खर्च हुन्छन्
• तेस्रो चरणमा तपाइँसँग 1 मर्ज छ जसको लागत 8 अपरेशनहरू छन्

त्यहाँ लग (N) चरणहरू भएकोले, कुल लागत एन * लग (एन) सञ्चालन.

मर्ज क्रमका फाइदाहरू

यो एल्गोरिथ्म किन यति शक्तिशाली छ?

किनभने:

• तपाइँ यसलाई मेमोरी फुटप्रिन्ट कम गर्न परिवर्तन गर्न सक्नुहुन्छ ताकि तपाइँ नयाँ एरेहरू सिर्जना गर्नुहुन्न तर सिधै इनपुट एरे परिमार्जन गर्नुहोस्।

नोट: यस प्रकारको एल्गोरिथ्म भनिन्छ in-ठाउँ (अतिरिक्त मेमोरी बिना क्रमबद्ध)।

• तपाईले यसलाई डिस्क स्पेस र एकै समयमा मेमोरीको सानो मात्रा प्रयोग गर्न महत्त्वपूर्ण डिस्क I/O ओभरहेड खर्च नगरी परिवर्तन गर्न सक्नुहुन्छ। विचार मेमोरीमा केवल ती भागहरू लोड गर्ने हो जुन हाल प्रशोधन भइरहेको छ। यो महत्त्वपूर्ण छ जब तपाइँ एक 100-मेगाबाइट मेमोरी बफर संग बहु-गीगाबाइट तालिका क्रमबद्ध गर्न आवश्यक छ।

नोट: यस प्रकारको एल्गोरिथ्म भनिन्छ बाह्य प्रकार.

• तपाईं यसलाई धेरै प्रक्रियाहरू/थ्रेडहरू/सर्भरहरूमा चलाउन परिवर्तन गर्न सक्नुहुन्छ।

उदाहरणका लागि, वितरित मर्ज क्रम मुख्य घटक मध्ये एक हो Hadoop (जुन ठूलो डाटा मा एक संरचना हो)।

• यो एल्गोरिथ्मले नेतृत्वलाई सुनमा परिणत गर्न सक्छ (वास्तवमा!)

यो क्रमबद्ध गर्ने एल्गोरिथ्म धेरै जसो (यदि सबै होइन) डाटाबेसमा प्रयोग गरिन्छ, तर यो एक मात्र होइन। यदि तपाइँ थप जान्न चाहनुहुन्छ भने, तपाइँ यो पढ्न सक्नुहुन्छ अनुसन्धान कार्य, जसले सामान्य डाटाबेस क्रमबद्ध एल्गोरिदमको फाइदा र विपक्षमा छलफल गर्दछ।

एरे, ट्री र ह्यास तालिका

अब जब हामीले समय जटिलता र क्रमबद्ध गर्ने विचार बुझ्छौं, मैले तपाईंलाई 3 डेटा संरचनाहरूको बारेमा बताउनुपर्दछ। यो महत्त्वपूर्ण छ किनभने तिनीहरू आधुनिक डाटाबेस को आधार हो। म अवधारणा पनि प्रस्तुत गर्नेछु डाटाबेस सूचकांक.

एर्रे

दुई-आयामी एरे सबैभन्दा सरल डेटा संरचना हो। तालिकालाई एरेको रूपमा सोच्न सकिन्छ। उदाहरणका लागि:

यो २-आयामी एरे पङ्क्ति र स्तम्भहरू भएको तालिका हो:

• प्रत्येक रेखाले एक इकाईलाई प्रतिनिधित्व गर्दछ
• स्तम्भहरूले एकाइको वर्णन गर्ने गुणहरू भण्डार गर्दछ।
• प्रत्येक स्तम्भले एक विशेष प्रकारको डाटा भण्डारण गर्दछ (पूर्णांक, स्ट्रिङ, मिति...)।

यो डाटा भण्डारण र दृश्यावलोकन गर्न को लागी सुविधाजनक छ, तथापि, जब तपाइँ एक विशिष्ट मान फेला पार्न आवश्यक छ, यो उपयुक्त छैन।

उदाहरणका लागि, यदि तपाइँ UK मा काम गर्ने सबै केटाहरू फेला पार्न चाहानुहुन्छ भने, तपाइँले प्रत्येक पङ्क्तिलाई हेर्नु पर्छ कि त्यो पङ्क्ति UK को हो कि भनेर निर्धारण गर्न। यसले तपाईंलाई N लेनदेन खर्च गर्नेछकहाँ N - लाइनहरूको संख्या, जुन खराब छैन, तर त्यहाँ छिटो बाटो हुन सक्छ? अब हामी रुखहरु संग परिचित हुन को लागी समय हो।

नोट: धेरै आधुनिक डाटाबेसहरूले कुशलतापूर्वक तालिकाहरू भण्डारण गर्न विस्तारित एरेहरू प्रदान गर्दछ: हिप-संगठित तालिकाहरू र अनुक्रमणिका-संगठित तालिकाहरू। तर यसले स्तम्भहरूको समूहमा एक विशेष अवस्था पत्ता लगाउने समस्यालाई परिवर्तन गर्दैन।

डाटाबेस रूख र अनुक्रमणिका

बाइनरी खोज रूख एक विशेष गुण भएको बाइनरी रूख हो, प्रत्येक नोडमा कुञ्जी हुनुपर्छ:

• बायाँ सबट्रीमा भण्डारण गरिएका सबै कुञ्जीहरू भन्दा ठूलो
• दायाँ सबट्रीमा भण्डारण गरिएका सबै कुञ्जीहरू भन्दा कम

हेरौं यो दृश्य अर्थ के हो

आइडिया

यो रूखमा N = 15 तत्वहरू छन्। मानौं म 208 खोज्दै छु:

• म रूटबाट सुरु गर्छु जसको कुञ्जी 136 हो। 136<208 देखि, म नोड 136 को दायाँ सबट्रीमा हेर्छु।
• 398>208 त्यसैले म नोड 398 को बायाँ सबट्री हेर्दै छु
• 250>208 त्यसैले म नोड 250 को बायाँ सबट्री हेर्दै छु
• 200 <208, त्यसैले म नोड 200 को दायाँ सबट्री हेर्दै छु। तर 200 को कुनै दायाँ सबट्री छैन, मूल्य अवस्थित छैन (यदि यो अवस्थित छ भने, यो सही सबट्री 200 मा हुनेछ)।

अब मानौं म ४० खोज्दै छु

• म रूटबाट सुरु गर्छु जसको कुञ्जी 136 हो। 136 > 40 देखि, म नोड 136 को बायाँ सबट्रीमा हेर्छु।
• 80 > 40, त्यसैले म नोड 80 को बायाँ सबट्री हेर्दै छु
• ४० = ४०, नोड अवस्थित छ। म नोड भित्र पङ्क्ति ID पुनःप्राप्त गर्छु (चित्रमा देखाइएको छैन) र दिइएको पङ्क्ति ID को लागि तालिकामा हेर्नुहोस्।
• पङ्क्ति ID थाहा पाउँदा मलाई तालिकामा डाटा कहाँ छ भनेर थाहा पाउन अनुमति दिन्छ, त्यसैले म यसलाई तुरुन्तै पुन: प्राप्त गर्न सक्छु।

अन्तमा, दुबै खोजहरूले मलाई रूख भित्रको स्तरहरूको संख्या खर्च गर्नेछ। यदि तपाइँ मर्ज क्रमको बारेमा भाग सावधानीपूर्वक पढ्नुहुन्छ भने, तपाइँले त्यहाँ लग (N) स्तरहरू देख्नुपर्दछ। यो बाहिर जान्छ, खोज लागत लग (N), खराब छैन!

हाम्रो समस्यामा फर्कौं

तर यो धेरै अमूर्त छ, त्यसैले हाम्रो समस्यामा फर्कौं। साधारण पूर्णांकको सट्टा, अघिल्लो तालिकामा कसैको देशलाई प्रतिनिधित्व गर्ने स्ट्रिङको कल्पना गर्नुहोस्। मानौं तपाईंसँग एउटा रूख छ जसमा तालिकाको "देश" क्षेत्र (स्तम्भ ३) समावेश छ:

• यदि तपाइँ युकेमा कसले काम गर्छ भनेर जान्न चाहनुहुन्छ भने
• तपाईंले ग्रेट ब्रिटेनको प्रतिनिधित्व गर्ने नोड प्राप्त गर्न रूखलाई हेर्नुहुन्छ
• "UKnode" भित्र तपाईंले UK कार्यकर्ता रेकर्डहरूको स्थान पाउनुहुनेछ।

यदि तपाईंले एरे सीधै प्रयोग गर्नुभयो भने यो खोजले N अपरेसनहरूको सट्टा लग(N) सञ्चालनहरू खर्च गर्नेछ। तपाईंले भर्खरै प्रस्तुत गर्नुभएको थियो डाटाबेस सूचकांक.

तपाईले कुनै पनि समूह (स्ट्रिङ, नम्बर, 2 लाइन, नम्बर र स्ट्रिङ, मिति...) को लागि एक अनुक्रमणिका रूख निर्माण गर्न सक्नुहुन्छ जबसम्म तपाइँसँग कुञ्जीहरू (जस्तै फिल्ड समूहहरू) तुलना गर्ने प्रकार्य छ ताकि तपाइँ सेट गर्न सक्नुहुन्छ। कुञ्जीहरू बीच अर्डर गर्नुहोस् (जुन डाटाबेसमा कुनै पनि आधारभूत प्रकारको मामला हो)।

B+TreeIndex

जबकि यो रूख एक विशिष्ट मूल्य प्राप्त गर्न को लागी राम्रो काम गर्दछ, त्यहाँ एक ठूलो समस्या छ जब तपाईलाई आवश्यक छ दुई मानहरू बीच धेरै तत्वहरू प्राप्त गर्नुहोस्। यसको लागत O(N) हुनेछ किनभने तपाईंले रूखको प्रत्येक नोडलाई हेर्नु पर्छ र यो यी दुई मानहरू (जस्तै, रूखको अर्डर गरिएको ट्र्याभर्सलको साथ) बीचमा छ कि छैन भनेर जाँच गर्नुपर्नेछ। यसबाहेक, यो अपरेशन डिस्क I/O अनुकूल छैन किनकि तपाईंले सम्पूर्ण रूख पढ्नु पर्छ। हामीले कुशलतापूर्वक कार्यान्वयन गर्ने बाटो खोज्नुपर्छ दायरा अनुरोध। यो समस्या समाधान गर्न, आधुनिक डाटाबेसले B+Tree भनिने अघिल्लो रूखको परिमार्जित संस्करण प्रयोग गर्दछ। B+ रुखमा:

• केवल तल्लो नोडहरू (पातहरू) जानकारी भण्डारण (सम्बन्धित तालिकामा पङ्क्तिहरूको स्थान)
• बाँकी नोडहरू यहाँ छन् रुटिङका ​​लागि सही नोडमा खोजीको क्रममा.

तपाईले देख्न सक्नुहुन्छ, यहाँ थप नोडहरू छन् (दुई पटक)। वास्तवमा, तपाईंसँग अतिरिक्त नोडहरू छन्, "निर्णय नोडहरू", जसले तपाईंलाई सही नोडहरू फेला पार्न मद्दत गर्दछ (जसले सम्बन्धित तालिकामा पङ्क्तिहरूको स्थान भण्डार गर्दछ)। तर खोजी जटिलता अझै O(log(N)) छ (त्यहाँ केवल एक थप स्तर छ)। ठूलो भिन्नता त्यो हो तल्लो तहमा नोडहरू तिनीहरूका उत्तराधिकारीहरूसँग जोडिएका छन्.

यस B+Tree को साथ, यदि तपाईं 40 र 100 बीचको मानहरू खोज्दै हुनुहुन्छ भने:

• तपाईंले भर्खरै 40 खोज्नु पर्छ (वा 40 पछिको सबैभन्दा नजिकको मान यदि 40 अवस्थित छैन भने) तपाईंले अघिल्लो रूखको साथ गर्नुभयो।
• त्यसपछि 40 उत्तराधिकारीहरू प्रत्यक्ष उत्तराधिकारी लिङ्कहरू प्रयोग गरेर जम्मा गर्नुहोस् जबसम्म तपाईं 100 पुग्नुहुन्न।

मानौं कि तपाईंले M उत्तराधिकारीहरू फेला पार्नुभयो र रूखमा N नोडहरू छन्। अघिल्लो रूख जस्तै एक विशिष्ट नोड लागत लग (N) पत्ता लगाउन। तर एकचोटि तपाईंले यो नोड प्राप्त गर्नुभयो, तपाईंले M अपरेशनहरूमा उनीहरूको उत्तराधिकारीहरूको सन्दर्भमा M उत्तराधिकारीहरू पाउनुहुनेछ। यो खोज M+log(N) को मात्र लागत अघिल्लो रूखमा N सञ्चालनहरूको तुलनामा सञ्चालनहरू। यसबाहेक, तपाईंले पूर्ण रूख (केवल M+log(N) नोडहरू पढ्नु पर्दैन), जसको अर्थ डिस्कको कम प्रयोग हो। यदि M सानो छ (जस्तै 200 पङ्क्तिहरू) र N ठूलो छ (1 पङ्क्तिहरू), त्यहाँ ठूलो भिन्नता हुनेछ।

तर यहाँ नयाँ समस्याहरू छन् (फेरि!)। यदि तपाइँ डेटाबेसमा पङ्क्ति थप्नुहुन्छ वा मेटाउनुहुन्छ (र त्यसकारण सम्बन्धित B+Tree अनुक्रमणिकामा):

• तपाईंले B+Tree भित्र नोडहरू बीचको क्रमलाई कायम राख्नुपर्छ, अन्यथा तपाईंले क्रमबद्ध नगरिएको रूख भित्र नोडहरू फेला पार्न सक्नुहुने छैन।
• तपाईंले B+Tree मा न्यूनतम सम्भावित स्तरहरू राख्नु पर्छ, अन्यथा O(log(N)) समय जटिलता O(N) हुन्छ।

अर्को शब्दमा, B+Tree आत्म-क्रम र सन्तुलित हुनुपर्छ। सौभाग्य देखि, यो स्मार्ट मेटाउने र सम्मिलित अपरेसन संग सम्भव छ। तर यो लागतमा आउँछ: B+ रूख लागत O(log(N)) मा सम्मिलित र मेटाउने। त्यसकारण तपाईंहरू मध्ये केहीले यो सुनेका छन् धेरै अनुक्रमणिकाहरू प्रयोग गर्नु राम्रो विचार होइन। साँच्चै, तपाइँ तालिकामा पङ्क्तिको छिटो सम्मिलित/अपडेट/मेटाउने कामलाई सुस्त गर्दै हुनुहुन्छकिनभने डाटाबेसले प्रत्येक अनुक्रमणिकाको लागि महँगो O(log(N)) अपरेशन प्रयोग गरेर तालिकाको अनुक्रमणिका अद्यावधिक गर्न आवश्यक छ। यसबाहेक, अनुक्रमणिकाहरू थप्नु भनेको थप कार्यभार हो लेनदेन प्रबन्धक (लेखको अन्त्यमा वर्णन गरिनेछ)।

थप विवरणहरूको लागि, तपाइँ विकिपिडियामा लेख हेर्न सक्नुहुन्छ B+ट्री। यदि तपाइँ डेटाबेसमा B+Tree लागू गर्ने उदाहरण चाहनुहुन्छ भने, हेर्नुहोस् यो लेख и यो लेख एक अग्रणी MySQL विकासकर्ताबाट। तिनीहरू दुवैले कसरी InnoDB (MySQL इन्जिन) अनुक्रमणिकाहरू ह्यान्डल गर्छ भन्ने कुरामा केन्द्रित छन्।

नोट: एक पाठकले मलाई भने कि, कम-स्तर अनुकूलनको कारणले, B+ रूख पूर्ण रूपमा सन्तुलित हुनुपर्छ।

ह्यासटेबल

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

ह्यास टेबल एक डाटा संरचना हो जसले चाँडै आफ्नो कुञ्जी द्वारा एक तत्व फेला पार्छ। ह्यास तालिका निर्माण गर्न तपाईंले परिभाषित गर्न आवश्यक छ:

• कुञ्जी तपाईंको तत्वहरूको लागि
• ह्यास प्रकार्य कुञ्जीहरूको लागि। कम्प्युटेड कुञ्जी ह्यासहरूले तत्वहरूको स्थान दिन्छ (जसलाई भनिन्छ खण्डहरू ).
• कुञ्जीहरू तुलना गर्न कार्य। एकचोटि तपाईंले सही खण्ड फेला पार्नुभयो, तपाईंले यो तुलना प्रयोग गरेर खण्ड भित्र खोज्नु भएको तत्व फेला पार्नु पर्छ।

सरल उदाहरण

स्पष्ट उदाहरण लिऔं:

यो ह्यास तालिकामा १० खण्डहरू छन्। किनभने म अल्छी छु, मैले केवल 10 खण्डहरू चित्रण गरें, तर मलाई थाहा छ तपाईं स्मार्ट हुनुहुन्छ, त्यसैले म तपाईंलाई अरू 5 खण्डहरू आफैं चित्रण गर्न दिनेछु। मैले कुञ्जीको ह्यास प्रकार्य मोड्युलो १० प्रयोग गरें। अर्को शब्दमा, म यसको खण्ड फेला पार्न तत्वको कुञ्जीको अन्तिम अंक मात्र भण्डार गर्छु:

• यदि अन्तिम अंक ० हो भने, तत्व खण्ड ० मा पर्छ,
• यदि अन्तिम अंक ० हो भने, तत्व खण्ड ० मा पर्छ,
• यदि अन्तिम अंक २ हो भने, तत्व क्षेत्र २ मा पर्दछ,
• ...

मैले प्रयोग गरेको तुलना प्रकार्य दुई पूर्णांकहरू बीचको समानता हो।

मानौं तपाईं तत्व 78 प्राप्त गर्न चाहनुहुन्छ:

• ह्यास तालिकाले 78 को लागि ह्यास कोड गणना गर्दछ, जुन 8 हो।
• ह्यास तालिकाले खण्ड 8 मा हेर्छ, र यो फेला पार्ने पहिलो तत्व 78 हो।
• उसले तपाईलाई वस्तु 78 फिर्ता गर्छ
• खोज खर्च मात्र 2 अपरेशनहरू (एउटा ह्यास मान गणना गर्न र अर्को खण्ड भित्र तत्व हेर्न)।

अब मानौं तपाईं तत्व 59 प्राप्त गर्न चाहनुहुन्छ:

• ह्यास तालिकाले 59 को लागि ह्यास कोड गणना गर्दछ, जुन 9 हो।
• ह्यास तालिकाले खण्ड 9 मा खोज्छ, पहिलो तत्व 99 पाइन्छ। 99!=59 देखि, तत्व 99 मान्य तत्व होइन।
• एउटै तर्क प्रयोग गरेर, दोस्रो तत्व (9), तेस्रो (79), ..., अन्तिम (29) लिइन्छ।
• तत्व फेला परेन।
• खोज लागत 7 अपरेशन.

राम्रो ह्यास प्रकार्य

तपाईले देख्न सक्नुहुन्छ, तपाईले खोज्नु भएको मूल्यमा निर्भर गर्दै, लागत समान छैन!

यदि मैले अब कुञ्जीको ह्यास प्रकार्य मोड्युलो 1 परिवर्तन गर्छु (अर्थात, अन्तिम 000 अंक लिँदै), दोस्रो लुकअपले 000 अपरेशन मात्र खर्च गर्छ किनभने त्यहाँ खण्ड 6 मा कुनै तत्वहरू छैनन्। वास्तविक चुनौती भनेको राम्रो ह्यास प्रकार्य फेला पार्नु हो जसले धेरै सानो संख्यामा तत्वहरू भएको बाल्टिनहरू सिर्जना गर्दछ.

मेरो उदाहरणमा, राम्रो ह्यास प्रकार्य फेला पार्न सजिलो छ। तर यो एक साधारण उदाहरण हो, राम्रो ह्यास प्रकार्य फेला पार्न धेरै गाह्रो छ जब कुञ्जी हो:

• स्ट्रिङ (उदाहरणका लागि - अन्तिम नाम)
• २ रेखाहरू (उदाहरणका लागि - अन्तिम नाम र पहिलो नाम)
• 2 रेखा र मिति (उदाहरणका लागि - अन्तिम नाम, पहिलो नाम र जन्म मिति)
• ...

राम्रो ह्यास प्रकार्यको साथ, ह्यास तालिका लुकअप लागत O(1).

एरे बनाम ह्यास तालिका

किन एरे प्रयोग नगर्ने?

हम्म, राम्रो प्रश्न।

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

थप जानकारीको लागि, तपाईं लेख पढ्न सक्नुहुन्छ Javaहशम्याप, जुन ह्यास तालिकाको कुशल कार्यान्वयन हो; तपाईंले यस लेखमा समेटिएका अवधारणाहरू बुझ्न जाभा बुझ्न आवश्यक छैन।

स्रोत: www.habr.com