PostgreSQL प्रारंभिक डेटाबेस का आकार

Question

मेरे प्रश्न के 2 भाग हैं।

1. क्या PostgreSQL में डेटाबेस के प्रारंभिक आकार को निर्दिष्ट करने का एक तरीका है?
2. यदि समय के साथ डेटाबेस नहीं बढ़ता है, तो आप विखंडन से कैसे निपटते हैं?

मैंने हाल ही में MSSQL से Postgres में माइग्रेट किया है, और डेटाबेस बनाते समय हमने जो MSSQL दुनिया में किया था, उनमें से एक डेटाबेस और ट्रांजेक्शन लॉग के प्रारंभिक आकार को निर्दिष्ट करना था। इससे विखंडन कम हो गया और प्रदर्शन में वृद्धि हुई, खासकर अगर डेटाबेस का "सामान्य" आकार पहले से जाना जाता है।

आकार बढ़ने पर मेरे डेटाबेस का प्रदर्शन गिर जाता है। उदाहरण के लिए, जो कार्यभार मैं इसे सामान्य रूप से लगा रहा हूं उसमें 10 मिनट लगते हैं। जैसे-जैसे डेटाबेस बढ़ता है, यह समय बढ़ता है। VACUUM, VACUUM FULL और VACUUM FULL ANALYZE करने से समस्या हल नहीं होती है। क्या करता है प्रदर्शन समस्या का समाधान डेटाबेस को रोक रहा है, ड्राइव को डी-टुकड़े कर रहा है और फिर VACUUM FULL ANALYZE करने से मेरे परीक्षण का प्रदर्शन मूल 10 मिनट में वापस आ जाता है। इससे मुझे संदेह होता है कि विखंडन मुझे दर्द दे रहा है।

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

कोई संकेत?

समाधान

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

PostgreSQL तालिका डेटा के समवर्ती पहुँच प्रदान करने के लिए MVCC का उपयोग करता है । इस योजना के तहत, प्रत्येक अपडेट उस पंक्ति का एक नया संस्करण बनाता है जिसे अपडेट किया गया था (यह समय स्टाम्प या संस्करण संख्या के माध्यम से हो सकता है, कौन जानता है?)। पुराना डेटा तुरंत डिलीट नहीं किया जाता, बल्कि डिलीट करने के लिए चिह्नित किया जाता है। वास्तविक विलोपन तब होता है जब VACUUM ऑपरेशन किया जाता है।

यह भरण कारक से कैसे संबंधित है? 100 के टेबल डिफॉल्ट फिल फैक्टर पूरी तरह से टेबल पेजों को पैक करता है, जिसका अर्थ है कि अद्यतन पंक्तियों को रखने के लिए टेबल पेज के भीतर कोई स्थान नहीं है, अर्थात अद्यतन पंक्तियों को मूल पंक्ति से अलग टेबल पेज में रखा जाएगा। यह प्रदर्शन के लिए बुरा है, जैसा कि मेरा अनुभव दिखाता है। जैसे-जैसे मेरी सारांश सारणी बहुत बार अद्यतन (1500 पंक्तियों / सेकंड तक) हो जाती है, मैंने 20 का भरण कारक निर्धारित किया, अर्थात 20% तालिका सम्मिलित पंक्ति डेटा और अद्यतन डेटा के लिए 80% होगी। हालांकि यह अत्यधिक लग सकता है, अद्यतन पंक्तियों के लिए आरक्षित स्थान की बड़ी मात्रा का मतलब है कि अद्यतन पंक्तियाँ मूल के रूप में एक ही पृष्ठ के भीतर रहती हैं और जब तक अप्रचलित पंक्तियों को हटाने के लिए ऑटोवैक्यूम डेमन चलता है तब तक तालिका पृष्ठ पूर्ण नहीं होता है।

मेरे डेटाबेस को "ठीक" करने के लिए, मैंने निम्नलिखित कार्य किया।

1. मेरे सारांश तालिकाओं के भरण कारक को 20 पर सेट करें। आप इसे TATE बनाने के लिए एक पैरामीटर पास करके या ALTER TABLE के माध्यम से तथ्य के बाद निर्माण समय पर कर सकते हैं । मैंने निम्नलिखित plpgsql कमांड जारी की:ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. एक VACUUM FULL को जारी किया गया, क्योंकि यह तालिका फ़ाइल का एक पूर्ण रूप से नया संस्करण लिखता है और इस प्रकार निहितार्थ द्वारा नए फिल कारक के साथ एक नई तालिका फ़ाइल लिखता है ।

मेरे परीक्षणों को पुन: व्यवस्थित करते हुए, मुझे डेटाबेस के बड़े होने पर भी कोई प्रदर्शन गिरावट नहीं दिखती है क्योंकि मुझे कई लाखों पंक्तियों के साथ रहने की आवश्यकता है।

TL; DR - फ़ाइल विखंडन का कारण नहीं था, यह टेबल स्पेस विखंडन था। यह आपके विशेष उपयोग के मामले के अनुरूप तालिका के भरण कारक को मोड़कर कम किया जाता है।

Comments

मुझे संदेह है कि यह फ़ाइल आकार बदलने वाला ऑपरेशन है। मेरा अनुमान है कि अनुक्रमणिका बनाए रखना आवेषण को धीमा कर रहा है। इस बारे में पीजी मेलिंग सूची पर (हालांकि समाधान के बिना) एक वर्तमान चर्चा है: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

Answer 1

1. कोई भी एकमात्र चीज़ जो आपके पास नहीं है - जब आप सर्वर को --with-segsize स्विच के साथ संकलित करते हैं, तो इससे मदद मिल सकती है यदि आपकी तालिका एक टमटम से अधिक स्थान ले रही है और आपकी फ़ाइल प्रणाली किसी एक फ़ाइल को टमटम पर होने से संभाल सकती है। यदि आपका आवेषण 20 गिग्स है तो आपको इस स्विच का उपयोग नहीं करने पर 20 फाइलें बनानी होंगी। यदि आपका फ़ाइल सिस्टम एक फ़ाइल को टमटम पर संभाल सकता है तो आप इसे एक बड़े मूल्य पर सेट कर सकते हैं सबसे अधिक संभावना है कि कुछ लाभ देखें, सबसे खराब स्थिति एक छोटा लाभ।

2. एक नजर डालें पर क्लस्टर http://www.postgresql.org/docs/9.1/static/sql-cluster.html और FILLFACTOR http://www.postgresql.org/docs/9.1/static/sql-createtable.html , http://www.postgresql.org/docs/9.1/static/sql-createindex.html

ध्यान दें कि FILLFACTOR को टेबल और इंडेक्स दोनों पर लागू किया जा सकता है।

Answer 2

नाटक में एक और बात है जो आपके समीकरणों में अभी तक दर्ज नहीं हुई है: HOT अपडेट । संबंधित उत्तर:

• PostgreSQL अस्पष्टीकृत तालिका ब्लोट
• क्या नियमित VACUUM ANALYZE अभी भी 9.1 के तहत अनुशंसित हैं?
• Pg_stat_user_tables में n_live_tup और n_dead_tup का अर्थ क्या है
• धीमी गति से क्वेरी को कैसे गति दें

स्थापना FILLFACTORके रूप में कम के रूप में 20 करता है अत्यधिक लग रहे हैं। यह तालिका को उसके आकार से पांच गुना अधिक तक फुलाता है। यदि HOT अपडेट काम करते हैं, तो आपको उस कम - सामान्य रूप से नहीं जाना चाहिए ।

अपवाद हैं: HOT अपडेट केवल पिछले लेनदेन से मृत tuples का पुन: उपयोग कर सकते हैं , समान या समवर्ती लोगों से नहीं। इसलिए, एक ही पंक्तियों को बार-बार अपडेट करने वाले भारी समवर्ती लोड या लंबे लेनदेन ऐसी कम (या इससे भी कम) सेटिंग को वारंट कर सकते हैं।

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

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

अंत में, आप प्रति तालिका में ऑटोवैक्यूम पैरामीटर सेट कर सकते हैं । आप आक्रामक सेटिंग्स के साथ भारी अपडेट की गई तालिकाओं को लक्षित कर सकते हैं, जिससे केवल पंक्तियों की कुछ सख्त पैकिंग हो सकती है FILLFACTOR 20।

Comments

दिलचस्प बात यह है कि, मैं इसे पढ़ता हूँ और कोशिश करता हूँ कि मेरे सिस्टम के लिए HOT अपडेट्स का क्या मतलब है।

— CadentOrange

Answer 3

यदि आपकी समस्या फ़ाइल विखंडन है तो नहीं, वहाँ नहीं है। पोस्टग्रेज़ में प्रत्येक तालिका को फ़ाइल फ़ाइल या फ़ाइल सिस्टम में यदि TOAST का उपयोग किया जाता है, तो यह फ़ाइल का सेट है। यह ओरेकल (या जाहिरा तौर पर एमएस-एसक्यूएल) से भिन्न होता है, जहाँ आप अपनी टेबल को गिराने के लिए पूर्व-आकार की टेबलस्पेस फाइलें बनाते हैं - हालाँकि, भले ही आपके पास फ़ाइल सिस्टम विखंडन समस्याएँ हो सकती हैं यदि टेबलस्पेस फाइलें विस्तारित हो जाती हैं या फाइल सिस्टम है बुरी तरह से टुकड़े के साथ शुरू करने के लिए।

आपके दूसरे प्रश्न के रूप में ... मुझे नहीं पता कि MS-Windows के रूप में फ़ाइल सिस्टम विखंडन से कैसे निपटेंगे? इन दिनों की जरूरत है शायद डेटाबेस फ़ाइलों को अपनी डिस्क पर रखने से कुछ हद तक इसे कम किया जा सकता है।

Comments

ध्यान रखें कि आपके पास आंतरिक PostgreSQL डेटाबेस विखंडन है और आपके पास बाह्य फ़ाइल सिस्टम विखंडन है। आंतरिक मेरा मानना ​​है कि VACUUM के साथ कम किया जा सकता है और ग्राहकों और ग्राहकों का उपयोग किया जा सकता है। फ़ाइल सिस्टम को दिए गए फ़ाइल सिस्टम के लिए डीफ़्रैग चलाकर नियंत्रित किया जा सकता है। और लिनक्स / यूनिक्स फ़ाइल सिस्टम कार्य भार और फ़ाइल सिस्टम के प्रकार के आधार पर कुछ समय में खंडित हो सकते हैं।

— कुबेरचुन

फ़ाइल सिस्टम विखंडन वास्तव में आजकल NTFS के साथ एक बड़ा मुद्दा नहीं है।

— a_horse_with_no_name

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

— कुबेरचुन