कभी-कभी, PostgreSQL डेटाबेस को एकल या न्यूनतम चरणों में बड़ी मात्रा में डेटा आयात करने की आवश्यकता होती है। इसे आमतौर पर बल्क डेटा आयात के रूप में जाना जाता है जहां डेटा स्रोत आमतौर पर एक या अधिक बड़ी फ़ाइलें होती हैं। यह प्रक्रिया कभी-कभी अस्वीकार्य रूप से धीमी हो सकती है।
इस तरह के खराब प्रदर्शन के कई कारण हैं:इंडेक्स, ट्रिगर, विदेशी कुंजी, GUID प्राथमिक कुंजी, या यहां तक कि आगे लिखें लॉग (WAL) सभी देरी का कारण बन सकते हैं।
इस लेख में, हम PostgreSQL डेटाबेस में डेटा को थोक में आयात करने के लिए कुछ सर्वोत्तम अभ्यास युक्तियों को शामिल करेंगे। हालाँकि, ऐसी परिस्थितियाँ हो सकती हैं जहाँ इनमें से कोई भी सुझाव एक कुशल समाधान नहीं होगा। हम पाठकों को किसी भी विधि को लागू करने से पहले उसके फायदे और नुकसान पर विचार करने की सलाह देते हैं।
युक्ति 1:लक्ष्य तालिका को अन-लॉग मोड में बदलें
PostgreSQL 9.5 और इसके बाद के संस्करण के लिए, लक्ष्य तालिका को पहले UNLOGGED में बदला जा सकता है, फिर डेटा लोड होने के बाद वापस LOGGED में बदला जा सकता है:
ALTER TABLE <target table> SET UNLOGGED
<bulk data insert operations…>
ALTER TABLE <target table> LOGGED
UNLOGGED मोड सुनिश्चित करता है कि PostgreSQL टेबल राइट ऑपरेशंस को राइट अहेड लॉग (WAL) में नहीं भेज रहा है। यह लोड प्रक्रिया को काफी तेज कर सकता है। हालांकि, चूंकि संचालन लॉग नहीं होते हैं, लोड के दौरान क्रैश या अशुद्ध सर्वर शटडाउन होने पर डेटा पुनर्प्राप्त नहीं किया जा सकता है। एक बार पुनरारंभ होने के बाद PostgreSQL स्वचालित रूप से किसी भी अनलॉग टेबल को छोटा कर देगा।
साथ ही, अनलॉग की गई तालिकाएँ स्टैंडबाय सर्वरों पर दोहराई नहीं जाती हैं। ऐसे मामलों में, मौजूदा प्रतिकृति को लोड से पहले हटाना होगा और लोड के बाद फिर से बनाना होगा। प्राथमिक नोड में डेटा की मात्रा और स्टैंडबाय की संख्या के आधार पर, प्रतिकृति बनाने का समय काफी लंबा हो सकता है, और उच्च-उपलब्धता आवश्यकताओं द्वारा स्वीकार्य नहीं है।
गैर-लॉग की गई तालिकाओं में डेटा को बल्क में सम्मिलित करने के लिए हम निम्नलिखित सर्वोत्तम अभ्यासों की अनुशंसा करते हैं:
- अन-लॉग मोड में बदलने से पहले तालिका और डेटा का बैकअप बनाना
- डेटा लोड पूरा होने के बाद स्टैंडबाय सर्वर के लिए किसी भी प्रतिकृति को फिर से बनाना
- ऐसी तालिकाओं के लिए गैर-लॉग किए गए बल्क इंसर्ट का उपयोग करना जिन्हें आसानी से फिर से पॉप्युलेट किया जा सकता है (उदाहरण के लिए बड़ी लुकअप टेबल या आयाम तालिकाएं)
टिप 2:इंडेक्स को ड्रॉप और रीक्रिएट करें
मौजूदा इंडेक्स बल्क डेटा इंसर्ट के दौरान महत्वपूर्ण देरी का कारण बन सकते हैं। ऐसा इसलिए है क्योंकि जैसे-जैसे प्रत्येक पंक्ति जोड़ी जाती है, संबंधित अनुक्रमणिका प्रविष्टि को भी अद्यतन करना पड़ता है।
हम अनुशंसा करते हैं कि जहां संभव हो, लक्ष्य तालिका में अनुक्रमणिका को बल्क इंसर्ट शुरू करने से पहले छोड़ दें, और लोड पूरा होने के बाद अनुक्रमणिका को फिर से बनाएं। फिर से, बड़े टेबल पर इंडेक्स बनाना समय लेने वाला हो सकता है, लेकिन लोड के दौरान इंडेक्स को अपडेट करने की तुलना में यह आमतौर पर तेज़ होगा।
DROP INDEX <index_name1>, <index_name2> … <index_name_n>
<bulk data insert operations…>
CREATE INDEX <index_name> ON <target_table>(column1, …,column n)
रखरखाव_कार्य_मेम . को अस्थायी रूप से बढ़ाना उपयोगी हो सकता है अनुक्रमणिका बनाने से ठीक पहले कॉन्फ़िगरेशन पैरामीटर। बढ़ी हुई कार्यशील मेमोरी इंडेक्स को तेजी से बनाने में मदद कर सकती है।
सुरक्षित खेलने का एक अन्य विकल्प मौजूदा डेटा और इंडेक्स के साथ उसी डेटाबेस में लक्ष्य तालिका की प्रतिलिपि बनाना है। इस नई कॉपी की गई तालिका को दोनों परिदृश्यों के लिए बल्क इंसर्ट के साथ परीक्षण किया जा सकता है:ड्रॉप-एंड-रीक्रिएट इंडेक्स, या गतिशील रूप से उन्हें अपडेट करना। लाइव टेबल के लिए बेहतर प्रदर्शन देने वाली विधि का अनुसरण किया जा सकता है।
टिप 3:विदेशी कुंजियां छोड़ें और फिर से बनाएं
इंडेक्स की तरह, विदेशी कुंजी बाधाएं भी थोक लोड प्रदर्शन को प्रभावित कर सकती हैं। ऐसा इसलिए है क्योंकि प्रत्येक सम्मिलित पंक्ति में प्रत्येक विदेशी कुंजी को संबंधित प्राथमिक कुंजी के अस्तित्व के लिए जांचना पड़ता है। दृश्य के पीछे, PostgreSQL जाँच करने के लिए एक ट्रिगर का उपयोग करता है। बड़ी संख्या में पंक्तियों को लोड करते समय, प्रत्येक पंक्ति के लिए इस ट्रिगर को बंद करना पड़ता है, जो ओवरहेड में जुड़ जाता है।
जब तक व्यावसायिक नियमों द्वारा प्रतिबंधित न किया जाए, हम अनुशंसा करते हैं कि लक्ष्य तालिका से सभी विदेशी कुंजियों को हटा दें, डेटा को एक ही लेन-देन में लोड करें, फिर लेन-देन करने के बाद विदेशी कुंजियों को फिर से बनाएं।
ALTER TABLE <target_table>
DROP CONSTRAINT <foreign_key_constraint>
BEGIN TRANSACTION
<bulk data insert operations…>
COMMIT
ALTER TABLE <target_table>
ADD CONSTRAINT <foreign key constraint>
FOREIGN KEY (<foreign_key_field>)
REFERENCES <parent_table>(<primary key field>)...
एक बार फिर, रखरखाव_कार्य_मेम को बढ़ाना कॉन्फ़िगरेशन पैरामीटर विदेशी कुंजी बाधाओं को फिर से बनाने के प्रदर्शन में सुधार कर सकता है।
युक्ति 4:ट्रिगर अक्षम करें
INSERT या DELETE ट्रिगर (यदि लोड प्रक्रिया में लक्ष्य तालिका से रिकॉर्ड हटाना भी शामिल है) थोक डेटा लोडिंग में देरी का कारण बन सकता है। ऐसा इसलिए है क्योंकि प्रत्येक ट्रिगर में तर्क होगा जिसे जांचने की आवश्यकता होती है और संचालन जिन्हें प्रत्येक पंक्ति के ठीक बाद पूरा करने की आवश्यकता होती है, उन्हें सम्मिलित या हटा दिया जाता है।
हम डेटा को बल्क लोड करने से पहले लक्ष्य तालिका में सभी ट्रिगर्स को अक्षम करने और लोड समाप्त होने के बाद उन्हें सक्षम करने की अनुशंसा करते हैं। सभी ट्रिगर को अक्षम करने में सिस्टम ट्रिगर भी शामिल होते हैं जो विदेशी कुंजी बाधा जांच को लागू करते हैं।
ALTER TABLE <target table> DISABLE TRIGGER ALL
<bulk data insert operations…>
ALTER TABLE <target table> ENABLE TRIGGER ALL
टिप 5:कॉपी कमांड का उपयोग करें
हम PostgreSQL कॉपी . का उपयोग करने की सलाह देते हैं एक या अधिक फाइलों से डेटा लोड करने का आदेश। COPY को बल्क डेटा लोड के लिए अनुकूलित किया गया है। यह बड़ी संख्या में INSERT कथन या बहु-मूल्यवान INSERTS चलाने से भी अधिक कुशल है।
COPY <target table> [( column1>, … , <column_n>)]
FROM '<file_name_and_path>'
WITH (<option1>, <option2>, … , <option_n>)
कॉपी का उपयोग करने के अन्य लाभों में शामिल हैं:
- यह टेक्स्ट और बाइनरी फ़ाइल आयात दोनों का समर्थन करता है
- यह लेन-देन की प्रकृति का है
- यह इनपुट फ़ाइलों की संरचना निर्दिष्ट करने की अनुमति देता है
- यह WHERE क्लॉज का उपयोग करके डेटा को सशर्त रूप से लोड कर सकता है
युक्ति 6:बहु-मूल्यवान INSERT का उपयोग करें
थोक डेटा लोड के लिए कई हजार या कई सैकड़ों हजारों INSERT कथन चलाना एक खराब विकल्प हो सकता है। ऐसा इसलिए है क्योंकि प्रत्येक व्यक्तिगत INSERT कमांड को क्वेरी ऑप्टिमाइज़र द्वारा पार्स और तैयार किया जाना है, सभी बाधाओं की जाँच से गुजरना है, एक अलग लेनदेन के रूप में चलाना है, और WAL में लॉग इन करना है। बहु-मूल्यवान एकल INSERT कथन का उपयोग करने से इस ओवरहेड को बचाया जा सकता है।
INSERT INTO <target_table> (<column1>, <column2>, …, <column_n>)
VALUES
(<value a>, <value b>, …, <value x>),
(<value 1>, <value 2>, …, <value n>),
(<value A>, <value B>, …, <value Z>),
(<value i>, <value ii>, …, <value L>),
...
बहु-मूल्यवान INSERT प्रदर्शन मौजूदा अनुक्रमणिका से प्रभावित होता है। हम अनुशंसा करते हैं कि कमांड चलाने से पहले इंडेक्स को छोड़ दें और बाद में इंडेक्स को फिर से बनाएं।
एक अन्य क्षेत्र के बारे में पता होना चाहिए कि बहु-मूल्यवान INSERTs चलाने के लिए PostgreSQL के लिए उपलब्ध मेमोरी की मात्रा। जब एक बहु-मूल्यवान INSERT चलाया जाता है, तो बड़ी संख्या में इनपुट मानों को RAM में फिट करना होता है, और जब तक पर्याप्त मेमोरी उपलब्ध न हो, प्रक्रिया विफल हो सकती है।
हम प्रभावी_कैश_आकार . सेट करने की अनुशंसा करते हैं पैरामीटर 50%, और shared_buffer मशीन की कुल रैम के 25% के लिए पैरामीटर। साथ ही, सुरक्षित होने के लिए, यह बहु-मूल्यवान INSERTs की एक श्रृंखला चला रहा है, जिसमें प्रत्येक कथन का मान 1000 पंक्तियों के लिए है।
टिप 7:विश्लेषण चलाएँ
यह बल्क डेटा आयात प्रदर्शन में सुधार से संबंधित नहीं है, लेकिन हम दृढ़ता से विश्लेषण . चलाने की अनुशंसा करते हैं लक्ष्य तालिका पर कमांड तुरंत बाद थोक आयात। बड़ी संख्या में नई पंक्तियाँ स्तंभों में डेटा वितरण को महत्वपूर्ण रूप से तिरछा कर देंगी और तालिका में मौजूद किसी भी मौजूदा आँकड़े को पुराना बना देंगी। जब क्वेरी ऑप्टिमाइज़र पुराने आँकड़ों का उपयोग करता है, तो क्वेरी का प्रदर्शन अस्वीकार्य रूप से खराब हो सकता है। ANALYZE कमांड चलाने से यह सुनिश्चित हो जाएगा कि कोई भी मौजूदा आंकड़े अपडेट किए गए हैं।
अंतिम विचार
डेटाबेस एप्लिकेशन के लिए थोक डेटा आयात हर दिन नहीं हो सकता है, लेकिन जब यह चलता है तो क्वेरी पर एक प्रदर्शन प्रभाव पड़ता है। इसलिए जितना संभव हो सके लोड समय को कम से कम करना आवश्यक है। किसी भी आश्चर्य को कम करने के लिए डीबीए एक चीज कर सकता है जो समान सर्वर विनिर्देशों और पोस्टग्रेएसक्यूएल कॉन्फ़िगरेशन के साथ विकास या स्टेजिंग वातावरण में लोड ऑप्टिमाइज़ेशन का परीक्षण करना है। प्रत्येक डेटा लोड परिदृश्य अलग होता है, और प्रत्येक विधि को आज़माना और जो काम करता है उसे ढूंढना सबसे अच्छा होता है।
