2011-05-24 12 views
17

मैं एक बहुत बड़ी तालिका का विभाजन कर रहा हूं जिसमें अस्थायी डेटा है, और इस बात पर विचार करते हुए कि मुझे विभाजन को क्या करना चाहिए। पोस्टग्रेज़ partition documentation का दावा है कि "बड़ी संख्या में विभाजन क्वेरी प्लानिंग समय में काफी वृद्धि करने की संभावना है" और अनुशंसा करता है कि विभाजन का उपयोग "सौ से अधिक" विभाजनों के साथ किया जाए।पोस्टग्रेज़ में कितने टेबल विभाजन हैं?

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

+0

मैं पोस्टग्रेज़ पर टिप्पणी नहीं कर सकता, लेकिन मासिक विभाजन अधिक समझ में नहीं आता? –

+0

वे लगभग निश्चित रूप से करेंगे; मैंने बड़ी संख्या में वास्तविकता प्राप्त करने के लिए साप्ताहिक चुना है। कोई इसके बजाय 20 वर्षों में मासिक विभाजन पर विचार कर सकता है। मैं मुख्य रूप से बाधाओं में रूचि रखता हूं, और अंतर क्या है, यानी 50 वी। 100 विभाजन प्रति विभाजन पंक्तियों की संख्या के आधार पर – DNS

+0

अक्सर आरबीडीएमएस के लिए 'अंगूठे का नियम' होता है। एसक्यूएल सर्वर के लिए, यह लगभग 20 मिलियन पंक्तियां –

उत्तर

10

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

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

0

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

मुझे लगता है कि पंक्ति अनुकूलन कैश जो क्वेरी ऑप्टिमाइज़र का उपयोग करता है यह निर्धारित करने के लिए कि कौन से जुड़ने और प्रतिबंधों का उपयोग प्रत्येक विभाजन के साथ संग्रहीत किया जाता है, इसलिए संभवतः इसे क्वेरी की योजना बनाने के लिए प्रत्येक विभाजन के हिस्सों को लोड और पढ़ने की आवश्यकता होती है।

+1

है, मैं डेवलपर्स पर भरोसा करता हूं, लेकिन उनकी चेतावनी बहुत अस्पष्ट है, इसलिए मैं इसे बेहतर समझना चाहता हूं। मेरा सवाल, जैसे स्टैक ओवरफ्लो पर सबसे ज्यादा, पूछा गया था कि अगर कोई पहले से ही जवाब जानता है, तो मुझे अपने काम को पुन: पेश करने के लिए प्रतिनिधि परीक्षण सेटअप बनाने में घंटों खर्च नहीं करना पड़ता है। – DNS

+1

@DNS यह अस्पष्ट है क्योंकि यह आपके हार्डवेयर और सॉफ्टवेयर कॉन्फ़िगरेशन, डेटा और क्वेरी पर निर्भर करता है। एक व्यक्ति जो एक व्यक्ति के लिए सही है वह किसी अन्य व्यक्ति के लिए सही नहीं होगा। एसक्यूएल उस तरह सूक्ष्म है। –

1

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

4

"बड़ी संख्या में विभाजन क्वेरी प्लानिंग समय में काफी वृद्धि करने की संभावना है" और अनुशंसा करता है कि विभाजन "शायद सौ सौ" विभाजनों के साथ उपयोग किया जाए।

क्योंकि प्रत्येक अतिरिक्त विभाजन आमतौर पर चेक बाधाओं से बंधेगा, और यह योजनाकार को आश्चर्यचकित करेगा कि किस विभाजन के खिलाफ पूछताछ की जानी चाहिए। सबसे अच्छे मामले परिदृश्य में, योजनाकार यह पहचानता है कि आप केवल एक ही विभाजन को मार रहे हैं और append चरण से पूरी तरह से छुटकारा पा सकते हैं।

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

संबंधित मुद्दे