PostgreSQL में सम्मिलन प्रदर्शन को कैसे तेज करें

पोस्टग्रेएसक्यूएल मैनुअल में एक डेटाबेस को पॉप्युलेट करें, इस विषय पर डिप्सज़ का उत्कृष्ट-सामान्य लेख, और यह SO प्रश्न देखें।

(ध्यान दें कि यह उत्तर किसी मौजूदा डीबी में बल्क-लोडिंग डेटा के बारे में है या एक नया बनाने के लिए है। यदि आप रुचि रखते हैं तो डीबी pg_restore के साथ प्रदर्शन को पुनर्स्थापित करता है। या psql pg_dump . का निष्पादन आउटपुट, इसमें से अधिकांश pg_dump . के बाद से लागू नहीं होता है और pg_restore स्कीमा+डेटा पुनर्स्थापना समाप्त करने के बाद ट्रिगर और अनुक्रमणिका बनाने जैसी चीज़ें पहले से ही कर लें) ।

बहुत कुछ किया जाना है। एक UNLOGGED . में आयात करना आदर्श समाधान होगा अनुक्रमणिका के बिना तालिका, फिर इसे लॉग में बदलें और अनुक्रमणिका जोड़ें। दुर्भाग्य से PostgreSQL 9.4 में UNLOGGED . से टेबल बदलने के लिए कोई समर्थन नहीं है लॉग इन करने के लिए। 9.5 ALTER TABLE ... SET LOGGED . जोड़ता है आपको ऐसा करने की अनुमति देने के लिए।

यदि आप थोक आयात के लिए अपने डेटाबेस को ऑफ़लाइन ले जा सकते हैं, तो pg_bulkload . का उपयोग करें ।

अन्यथा:

• टेबल पर किसी भी ट्रिगर को अक्षम करें

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

• यदि एक ही लेन-देन के भीतर आयात कर रहे हैं, तो विदेशी कुंजी बाधाओं को छोड़ना, आयात करना और प्रतिबद्ध होने से पहले बाधाओं को फिर से बनाना सुरक्षित है। यदि आयात कई लेन-देन में विभाजित है, तो ऐसा न करें क्योंकि आप अमान्य डेटा पेश कर सकते हैं।

• यदि संभव हो तो COPY का प्रयोग करें INSERT . के बजाय एस

• यदि आप COPY का उपयोग नहीं कर सकते हैं बहु-मूल्यवान INSERT . का उपयोग करने पर विचार करें एस यदि व्यावहारिक है। ऐसा लगता है कि आप पहले से ही ऐसा कर रहे हैं। भी को सूचीबद्ध करने का प्रयास न करें एक VALUES . में अनेक मान हालांकि; उन मूल्यों को स्मृति में एक-दो बार फिट होना है, इसलिए इसे कुछ सौ प्रति कथन पर रखें।

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

• synchronous_commit=off का उपयोग करें और एक बहुत बड़ा commit_delay fsync() लागत को कम करने के लिए। हालांकि, अगर आपने अपने काम को बड़े लेन-देन में बैच दिया है तो इससे बहुत मदद नहीं मिलेगी।

• INSERT या COPY कई कनेक्शनों से समानांतर में। आपके हार्डवेयर के डिस्क सबसिस्टम पर कितने निर्भर करते हैं; एक नियम के रूप में, यदि आप प्रत्यक्ष संलग्न संग्रहण का उपयोग कर रहे हैं, तो आप प्रति भौतिक हार्ड ड्राइव पर एक कनेक्शन चाहते हैं।

• एक उच्च max_wal_size सेट करें मान (checkpoint_segments पुराने संस्करणों में) और log_checkpoints enable को सक्षम करें . PostgreSQL लॉग्स को देखें और सुनिश्चित करें कि यह बहुत अधिक बार होने वाली चौकियों के बारे में शिकायत नहीं कर रहा है।

• यदि और केवल अगर आपको अपने संपूर्ण PostgreSQL क्लस्टर (आपका डेटाबेस और एक ही क्लस्टर पर कोई अन्य) को विनाशकारी भ्रष्टाचार में खोने से कोई फर्क नहीं पड़ता है, यदि सिस्टम आयात के दौरान दुर्घटनाग्रस्त हो जाता है, तो आप Pg को रोक सकते हैं, fsync=off सेट कर सकते हैं। कोड> , Pg प्रारंभ करें, अपना आयात करें, फिर (अनिवार्य रूप से) Pg को रोकें और fsync=on सेट करें दोबारा। वाल विन्यास देखें। ऐसा न करें यदि आपके PostgreSQL इंस्टाल पर किसी डेटाबेस में पहले से कोई डेटा आपके लिए महत्वपूर्ण है। अगर आप fsync=off set सेट करते हैं आप full_page_writes=off . भी सेट कर सकते हैं; फिर से, डेटाबेस भ्रष्टाचार और डेटा हानि को रोकने के लिए अपने आयात के बाद इसे वापस चालू करना याद रखें। पीजी मैनुअल में गैर-टिकाऊ सेटिंग्स देखें।

आपको अपने सिस्टम को ट्यून करने पर भी ध्यान देना चाहिए:

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

• यदि आप प्रत्यक्ष संलग्न संग्रहण के लिए RAID 5 या RAID 6 का उपयोग कर रहे हैं, तो अभी रुकें। अपने डेटा का बैकअप लें, अपने RAID सरणी को RAID 10 में पुनर्गठित करें, और पुनः प्रयास करें। RAID 5/6 बल्क राइट परफॉर्मेंस के लिए निराशाजनक है - हालांकि बड़े कैश के साथ एक अच्छा RAID कंट्रोलर मदद कर सकता है।

• यदि आपके पास बड़े बैटरी-समर्थित राइट-बैक कैश के साथ हार्डवेयर RAID नियंत्रक का उपयोग करने का विकल्प है, तो यह वास्तव में बहुत सारे कामों के साथ वर्कलोड के लिए लेखन प्रदर्शन में सुधार कर सकता है। यदि आप कमिट_डेले के साथ एसिंक्स कमिट का उपयोग कर रहे हैं या यदि आप बल्क लोडिंग के दौरान कम बड़े लेनदेन कर रहे हैं तो यह उतनी मदद नहीं करता है।

• यदि संभव हो तो WAL (pg_wal को स्टोर करें , या pg_xlog पुराने संस्करणों में) एक अलग डिस्क / डिस्क सरणी पर। एक ही डिस्क पर एक अलग फाइल सिस्टम का उपयोग करने का कोई मतलब नहीं है। लोग अक्सर WAL के लिए RAID1 जोड़ी का उपयोग करना चुनते हैं। फिर, इसका उच्च प्रतिबद्ध दरों वाले सिस्टम पर अधिक प्रभाव पड़ता है, और यदि आप डेटा लोड लक्ष्य के रूप में एक अनलॉग टेबल का उपयोग कर रहे हैं तो इसका बहुत कम प्रभाव पड़ता है।

तेज़ परीक्षण के लिए आपकी रुचि PostgreSQL को ऑप्टिमाइज़ करने में भी हो सकती है.