टेबल विभाजन कैसे मदद करता है?


28

मुझे टेबल विभाजन के पेशेवरों और विपक्षों के विचार को हथियाने में कठिनाई हो रही है। मैं एक ऐसी परियोजना पर काम शुरू करने जा रहा हूं, जिसमें 8 टेबल होंगे और उनमें से एक मुख्य डेटा टेबल होगा जो 180-260 मिलियन रिकॉर्ड रखेगा। जैसा कि यह ठीक से अनुक्रमित तालिका होगी, इसलिए मैं तालिका के रिकॉर्ड को 20 मिलियन तक सीमित करने के बारे में सोच रहा हूं इस तरह मुझे 9-13 टेबल बनाने होंगे।

लेकिन मुझे इस बारे में पूरा यकीन नहीं है कि यह प्रदर्शन में सुधार कैसे करेगा क्योंकि वे एक ही मशीन (32 जीबी रैम) पर बैठे होंगे?

मैं MySQL का उपयोग कर रहा हूं और तालिकाओं में MyISAM होगा और बड़ी तालिका में id फ़ील्ड पर अनुक्रमणिका होगी और इसमें आगे की जटिलताएं नहीं हैं, जैसे कि कोई पाठ फ़ील्ड आदि।

कृपया डेटाबेस विभाजन के विरुद्ध तालिका विभाजन पर भी प्रकाश डालें।


कृपया समझाएं कि आईडी के अलावा तालिका के विरुद्ध किस प्रकार की अनुक्रमित खोज की जाएगी। यह विभाजन के प्रकार पर आपको सुराग देगा।
RolandoMySQLDBA

यह केवल आईडी होगा।
रिक जेम्स

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

1
यहाँ इस धागे को शुरू करने के 5 साल बाद मेरी भावनाएँ हैं।
रिक जेम्स

जवाबों:


32

निम्नलिखित केवल पागल पागल और पागल है ...

यदि आप एक तालिका में सभी डेटा छोड़ते हैं (कोई विभाजन नहीं), तो आपके पास कुंजी का उपयोग करके ओ (लॉग एन) खोज समय होगा। चलो दुनिया में सबसे खराब सूचकांक लेते हैं, बाइनरी ट्री। प्रत्येक ट्री नोड में एक कुंजी होती है। 268,435,455 (2 ^ 28 - 1) पेड़ के नोड्स के साथ एक पूरी तरह से संतुलित बाइनरी ट्री 28 की ऊंचाई होगी। यदि आप इस बाइनरी ट्री को 16 अलग-अलग पेड़ों में विभाजित करते हैं, तो आपको 16,777,215 (2: 24 - 1) के साथ प्रत्येक 16 बाइनरी पेड़ मिलते हैं। 24 की ऊंचाई के लिए ट्री नोड्स। खोज मार्ग 4 नोड्स, एक 14.2857% ऊंचाई में कमी है। यदि खोज समय माइक्रोसेकंड में है, तो खोज समय में 14.2857% की कमी शून्य से नगण्य है।

अब असली दुनिया में, BTREE इंडेक्स में कई कुंजियों वाले टरिनोड होंगे। प्रत्येक BTREE खोज पृष्ठ के भीतर बाइनरी खोज को किसी अन्य पेज में संभावित सभ्य के साथ प्रदर्शित करेगी। उदाहरण के लिए, यदि प्रत्येक BTREE पेज में 1024 कुंजियाँ होती हैं, तो 3 या 4 की एक पेड़ की ऊँचाई वास्तव में एक छोटी पेड़ की ऊँचाई होगी।

ध्यान दें कि तालिका का एक भाग बीटीआरईई की ऊंचाई को कम नहीं करता है जो पहले से ही छोटा है। 260 मिलीयन पंक्तियों के विभाजन को देखते हुए, समान ऊंचाई वाले कई BTREE होने की प्रबल संभावना है। एक कुंजी की खोज हर बार सभी रूट बीटीआरई पृष्ठों से गुजर सकती है। केवल एक ही आवश्यक खोज सीमा का मार्ग पूरा करेगा।

अब इस पर विस्तार करें। सभी विभाजन एक ही मशीन पर मौजूद हैं। यदि आपके पास प्रत्येक विभाजन के लिए अलग डिस्क नहीं है, तो आपके पास डिस्क I / O होगा और विभाजन खोज प्रदर्शन के बाहर एक स्वचालित अड़चन के रूप में धुरी घुमाव होगा।

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

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

समग्र प्रभाव में कम से कम दो विभाजन होने चाहिए: एक बार-बार एक्सेस किए गए आईडी के लिए, और बाकी आईडी के लिए अन्य परिच्छेद। यदि अक्सर एक्सेस की गई आईडी काफी बड़ी है, तो आप वैकल्पिक रूप से विभाजन कर सकते हैं।


16

200 मिलियन पंक्तियाँ निश्चित रूप से उस श्रेणी में हैं जहाँ आप तालिका विभाजन से लाभ उठा सकते हैं। आपके आवेदन के आधार पर, आप नीचे सूचीबद्ध कुछ लाभों पर शर्त लगा सकते हैं:

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

  • एकाधिक डिस्क वॉल्यूम विभाजन आपको गति के लिए कई डिस्क संस्करणों में डिस्क ट्रैफ़िक को वितरित करने के लिए डेटा को विभाजित करने की अनुमति देता है। आधुनिक RAID नियंत्रक के साथ यह ओपी के लिए एक समस्या होने की संभावना नहीं है।

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

    एक आम फिल्टर (आमतौर पर समय या अवधि आधारित) के द्वारा विभाजन तालिका के बड़े हिस्से को ऐसे प्रश्नों से दूर करने की अनुमति देता है यदि विभाजन कुंजी के खिलाफ विधेय को हल किया जा सकता है। यह तालिका को कई संस्करणों में विभाजित करने की अनुमति देता है, जो बड़े डेटा सेट के लिए महत्वपूर्ण प्रदर्शन लाभ दे सकता है। आम तौर पर, यह परिचालन प्रणालियों के लिए एक मुद्दा नहीं है।

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


1

विभाजन, यदि आपके सभी अनुक्रमित विभाजन हैं, तो विभाजन द्वारा समवर्ती पुर्जों की अनुमति देता है। यदि नहीं, तो विभाजन अभी भी बहुत छोटे हैं और रीगॉर के लिए कम कार्यक्षेत्र का उपयोग करते हैं। और, आंतरिक रूप से, कोई भी "अच्छा" DBMS विभाजित तालिकाओं के साथ समानांतर में चीजें कर सकता है। इस संभावना में MySQL या MyISAM, tho शामिल नहीं है ...।


विभाजन में शामिल होने पर भी MySQL कोई समानांतर प्रसंस्करण नहीं करता है। MySQL केवल एक विभाजन को अनुक्रमित करता है ; इसलिए UNIQUEऔर FOREIGN KEYविभाजन तालिका में वास्तव में उपलब्ध नहीं हैं। MyISAM बनाम InnoDB पर विभाजन - इस सूत्र में चर्चा की गई चीजों के संबंध में कोई अंतर नहीं है।
रिक जेम्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.