विभाजन क्यों नहीं?


10

जब कोई डेटाबेस विभाजन नहीं करना चाहेगा? (सोच MySQL विभाजन )

मेरे मामले में

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

यहां तक ​​कि अंतिम बिंदु के लिए, लुकअप सभी मामलों में समानांतर में नहीं चलता है , क्या यह जीत है ? विभाजन के लिए डाउनसाइड क्या हैं? यह ऐसा कुछ क्यों नहीं है जिसे हर कोई डिफ़ॉल्ट रूप से उपयोग करता है, कम से कम जब आप एक लाख + रिकॉर्ड देख रहे हों?

अद्यतन - मैंने zgguy के उत्तर का चयन किया लेकिन ध्यान दें कि मैंने अपने स्वयं के अनुसंधान के परिणामों के साथ अपना उत्तर जोड़ा, जिसमें एक समान प्रश्न पर वास्तव में अच्छा उत्तर देने के लिए एक लिंक भी शामिल था जो मेरे लिए बहुत उपयोगी था।

जवाबों:


5

प्रदर्शन समस्याओं के लिए कोई चांदी की गोली नहीं है, और विभाजन भी एक नहीं है।

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

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

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


इसलिए अद्वितीय / प्राथमिक कुंजी लुकअप वास्तव में बहुत (यदि कोई हो?) सुधार नहीं देखेंगे क्योंकि पीके इंडेक्स तेज है? क्या यह बोर्ड के पार है - क्या कोई ऐसा समय होता है जब पीके इंडेक्स धीमा होता है? यदि हाल ही में जोड़े गए PKs को लुकअप किया जाता है तो क्या होगा? पीके के आधार पर एक विभाजन होगा (मुझे लगता है कि विभाजन कुंजी अलग-अलग होना चाहिए मापांक या समान और नहीं हैश, ठीक है?) जो सबसे अधिक गतिविधि का कारण बनता है केवल एक विभाजन को हिट करने में सहायक होता है?
Chell

प्राथमिक / विशिष्ट कुंजी लुकअप में सबसे अच्छा प्रदर्शन में मामूली सुधार देखने को मिलेगा। दूसरी ओर, यदि आपका लक्ष्य डीएमएल बयानों के विवाद को कम करना है, तो आपको एक तरह से विभाजन करना चाहिए ताकि डीएमएल उनमें से कुछ पर केंद्रित होने के बजाय सभी विभाजनों में समान रूप से फैले।
zgguy

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

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

क्षमा करें, हाल ही में स्टैक एक्सचेंज का दौरा करने में सक्षम नहीं था। आपके द्वारा जुड़ा हुआ उत्तर बहुत अच्छा है। मेरा मानना ​​है कि यह आपके दोनों सवालों का जवाब देता है।
zgguy

2

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

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

मैंने यह भी उल्लेख किया है कि MySQL समानांतर में कभी कुछ नहीं करता है (कुछ लिंक या उस बारे में अधिक स्पष्टीकरण देखकर अच्छा लगेगा)।

नहीं देखा है कि कोई भी गतिविधि को लिखता है या नहीं, अलग-अलग विचार जोड़ता है।


मुझे नहीं लगता कि लेखन आपके उत्तर को बदलता है। आपने मेरे द्वारा उपयोग किए गए 4 मामलों में से 2 का उल्लेख किया है। अभी भी कोई समानता नहीं है, यहां तक ​​कि 8.0 में भी।
रिक जेम्स

1

बहुत पहली बात दिमाग में आती है विभाजन विभाजन ; अगर वह कुछ नहीं है जो आपके प्रश्नों का उपयोग कर सकता है।

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

और एक और बात जो कोई भी सोच सकता है वह है सरल तालिकाओं के लिए उपयोग में आसानी ... विभाजन को अतिरिक्त कार्य और रखरखाव की आवश्यकता होती है।


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