PostgreSQL के साथ काम करते समय विशिष्ट त्रुटियां। भाग २

हम PGConf.Russia 2019 सम्मेलन से सर्वश्रेष्ठ रिपोर्ट के वीडियो और टेप प्रकाशित करना जारी रखते हैं। इवान फ्रोलकोव की बात के पहले भाग में , यह असंगत नामकरण के बारे में था, बाधाओं के बारे में, जहां तर्क को केंद्रित करना बेहतर है - डेटाबेस में या एप्लिकेशन में। इस भाग में, आपको पार्सिंग एरर हैंडलिंग, समवर्ती एक्सेस, नॉन-कैंसेबल ऑपरेशन्स, सीटीई और जेन्सन मिलेंगे।



मैं ऐसी कहानी बताऊंगा। हमारा ग्राहक कहता है: “डेटाबेस धीरे-धीरे काम कर रहा है, और हमारा आवेदन आबादी की सेवा में लगा हुआ है। हमें डर है कि वे हमें यहां कांटे के लिए खड़ा करेंगे। ” यह पता चला कि लेन-देन की स्थिति में उनके पास निष्क्रिय प्रक्रियाएं थीं। आवेदन ने लेनदेन शुरू किया, कुछ भी नहीं करता है, लेकिन लेनदेन पूरा नहीं होता है। यदि आप कुछ बाहरी सेवाओं के साथ बातचीत करते हैं, तो, सिद्धांत रूप में, यह एक सामान्य स्थिति है। एक और बात यह है कि यदि लेन-देन की स्थिति में आपकी निष्क्रियता लंबे समय तक रहती है (यह एक मिनट से अधिक समय तक पहले से ही संदिग्ध है), तो यह बुरा है क्योंकि PostgreSQL वास्तव में लंबे लेनदेन को पसंद नहीं करता है: VACUUM उन सभी लाइनों को साफ करने में सक्षम नहीं होगा जो इसे देख सकती थीं, और लंबे समय तक लटका रही थीं। लेनदेन प्रभावी रूप से VACUUM को अवरुद्ध करता है। तालिकाओं में सूजन होने लगती है, सूचकांक कम और कम प्रभावी होते जा रहे हैं।



इस मामले में, लोगों ने अनुरोधों को सही ढंग से नहीं लिखा और कार्टेशियन उत्पादों को प्राप्त किया - ऐसे अनुरोध कई दिनों तक पूरे किए गए थे। खैर, उपयोगकर्ता, वह बटन दबाएगा, परिणाम की प्रतीक्षा करें और, यदि कोई परिणाम नहीं है, तो फिर से बटन दबाएं।

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

इसके बारे में क्या करना है? सबसे पहले, आपको हमेशा त्रुटियों को संभालना होगा। यदि कोई त्रुटि आपके पास आती है, तो कृपया इसे अनदेखा न करें। यह अच्छा है अगर PostgreSQL कनेक्शन खो गया: यह लेनदेन वापस करता है, हम जीवित रहते हैं। इस पर मैं रुक जाऊंगा। ठीक है, अगर कोई कोड है जिसमें संपादन करने का समय नहीं है, तो हमारे पास अभी भी लेनदेन में अधिकतम निष्क्रियता है - आप इसे डाल सकते हैं, और यह सिर्फ निष्क्रिय लेनदेन को खत्म कर देगा।



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



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



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

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



इसके अलावा, यदि आपके पास अच्छी तरह से परिभाषित बाधाएं हैं, तो आप डेटाबेस से नहीं, बल्कि त्रुटि को संसाधित करते समय एक अपवाद फेंक सकते हैं। वसंत में , क्रमशः php में , set_exception_handler एक अपवाद अनुवाद है । उन उपकरणों पर ध्यान दें जो आपके ढांचे आपको प्रदान करते हैं, वे एक कारण से वहां दिखाई दिए।

तो: उस त्रुटि को न पकड़ें जिसके साथ आप नहीं जानते कि क्या करना है; नाम त्रुटियों ध्यान से और सही; त्रुटियों को वर्गीकृत करें।



व्यक्तिगत रूप से, मैं ऐसे मानदंडों द्वारा वर्गीकृत करता हूं: ऑपरेशन दोहराया जा सकता है (उदाहरण के लिए, हमारे पास गतिरोध था); ऑपरेशन दोहराया नहीं जा सकता है, यह पहले ही पूरा हो चुका है; ऑपरेशन सिद्धांत रूप में नहीं किया जा सकता है।

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



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

अधिकांश डेवलपर्स का मानना ​​है कि वे अकेले डेटाबेस के साथ काम करते हैं, और उनके आवेदन सख्ती से क्रमिक रूप से संचालन करते हैं। और यह सभी संबंधपरक DBMS के लिए एक प्लस है क्योंकि, अजीब तरह से पर्याप्त, सब कुछ काम करता है, एक नियम के रूप में, बहुत अच्छी तरह से, मानक अलगाव स्तर READ COMMITTED के साथ, और न कि SERIALIZABLE। उसी समय, स्थिति तब होती है जब अपडेट खो जाते हैं: एक फॉर्म को लोड करता है, दूसरा उसी फॉर्म को लोड करता है, एक ने लिखा और बचाया, दूसरे ने पुराने को बचाया - परिवर्तन मिट गए। पहला शपथ आया: "ऐसा कैसे, मैंने बहुत लिखा, और सब कुछ खो गया।"



मेरे अनुभव से: सप्ताह में एक बार शुक्रवार को, दो प्रबंधकों ने भुगतान किया। उन्हें चाहिए
हर बार बदल रहे थे, लेकिन, फिर भी, एक ही समय पर चढ़ गए और प्रति व्यक्ति दो भुगतान किए। यदि आपके पास कम से कम प्रतिस्पर्धी एक्सेस त्रुटि का कुछ मौका है, तो यह जल्दी या बाद में होगा। सवाल यह है कि

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



एक दो बार मैं पूरी तरह से बुरे सपने में आया था: एक बाहरी वेब सेवा को डेटाबेस से बुलाया जाता है। कुछ ऑपरेशन थे जो बाहरी संस्थाओं को बदलते हैं। यह बुरा है क्योंकि एक लेनदेन को डेटाबेस में वापस लाया जा सकता है, लेकिन दूरस्थ सेवा के संचालन को अस्वीकार नहीं किया जाएगा।

एक और भी अधिक सूक्ष्म बिंदु गतिरोध है। आइए कल्पना करें: हम एक लेनदेन की प्रक्रिया करते हैं, एक बाहरी वेब सेवा को कॉल करते हैं, कुछ बदलते हैं, उसके बाद हम गतिरोध प्राप्त करते हैं, और हम वापस रोल करते हैं, फिर हम फिर से ऑपरेशन करने की कोशिश करते हैं, फिर से कॉल करते हैं, अच्छी परिस्थितियों में, गतिरोध फिर से होता है, फिर से रोल बैक - यह कर सकते हैं
कई बार होता है (मैं एक सौ दोहराव के पार आया)। और अब आप इन गतिरोधों को कम या ज्यादा सही तरीके से संसाधित करते हैं, संचालन दोहराते हैं और अचानक पता चलता है कि आप दो महीने के भीतर किसी को दोहरी राशि का भुगतान कर रहे हैं।



मैं उन भुगतान सेवाओं के साथ मिला, जिनके पास एक खराब एपीआई था: "ऐसे और इस तरह के एक उपयोगकर्ता को ऐसी राशि का भुगतान करें"; फ़ंक्शन परिणाम देता है - भुगतान किया / भुगतान नहीं किया गया। सबसे पहले, एक दोहराने के मामले में एक समस्या है, और दूसरी बात, यह स्पष्ट नहीं है कि कनेक्शन बाधित होने पर क्या करना है। किसी कारण से, बहुत कम लोग इस विषय पर परेशान होते हैं।



एक उदाहरण स्लाइड पर है: इस तरह के ऑपरेशन को दो चरणों में किया जाना चाहिए: जैसे कि एक चेतावनी - "हम अब कुछ करेंगे"; ऑपरेशन ही।



अगर हम अचानक बाधित होते हैं - आप कभी नहीं जानते हैं, तो शक्ति को बंद कर दिया - हम ऑपरेशन को फिर से कर सकते हैं। यदि हम दूसरे चरण में मर गए, तो, पूरी दुनिया में, दूसरी बार हम ऐसा नहीं करेंगे, और यह मैन्युअल रूप से असंतुष्ट हो सकता है। वास्तव में, इस तरह के संचालन का अधिकांश हिस्सा सामान्य रूप से पहली बार काम करता है, लेकिन ये उपाय सैद्धांतिक निर्माण नहीं हैं। सब कुछ सामान्य रूप से महीनों तक काम कर सकता है, और अचानक नेटवर्क से समझदार होना शुरू हो जाता है, सेवा सक्रिय रूप से चमकने लगती है - और समस्याएं शुरू हो गईं।


स्लाइड पर 4 प्रकार के गैर-रद्द करने योग्य संचालन हैं। उत्तरार्द्ध नॉन-इम्पोटेंट ऑपरेशन है। यह बहुत दुखद मामला है। शुरुआत में मैंने एक ऐसे कॉमरेड के बारे में बात की, जिसने अपने ऑपरेशन की बेकरारी सुनिश्चित करने के लिए ट्रिगर्स पर सबकुछ किया।


सम्मेलन में लोग कॉमन टेबल एक्सप्रेशंस के बारे में बात करेंगे कि यह कितना अच्छा है। दुर्भाग्य से, PostgreSQL CTE मुक्त नहीं हैं: उन्हें अपने लिए वर्क_म की आवश्यकता होती है। यदि आपके पास एक छोटा सा नमूना है, तो, सामान्य तौर पर, यह ठीक है। और अगर आपके पास अचानक यह बड़ा है, तो आपकी समस्याएं शुरू हो जाती हैं। लोग अक्सर सीटीई का उपयोग एक तरह के मिनी-व्यू के रूप में करते हैं - ताकि आप किसी तरह से एप्लिकेशन को संरचना कर सकें। CTE की मांग बहुत ज्यादा है।





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



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

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



- जब कई उपयोगकर्ता स्ट्रिंग के साथ काम करते हैं, तो कैसे जांचें? क्या विकल्प हैं?

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

- आप कहते हैं कि बाधाओं को अच्छे नाम कहा जाना चाहिए ताकि उपयोगकर्ता समझ सके कि क्या हो रहा है। लेकिन प्रति बाधा नाम की 60 वर्ण सीमा है। यह अक्सर पर्याप्त नहीं होता है। इससे कैसे निपटें?

- मुझे लगता है कि आत्म-संयम से लड़ना चाहिए। PostgreSQL में, यह एक विशेष प्रकार की लंबाई 64 है। सिद्धांत रूप में, आप एक लंबी लंबाई के लिए recompile कर सकते हैं, लेकिन यह बहुत अच्छा नहीं है।

- रिपोर्ट में, आपने हमें इस तथ्य से रूबरू कराया कि हमें अभिलेखागार के साथ कुछ करने की आवश्यकता है। पुराने संग्रह के लिए कौन सा तंत्र सबसे सही माना जाता है?

- जैसा कि मैंने शुरुआत में ही कहा था, पूरी लगन के साथ सब कुछ काम करता है। आपके लिए कौन सी विधि सबसे सुविधाजनक है, इसलिए इसका उपयोग करें।


समय: रिपोर्ट का भाग 2 25:16 से शुरू होता है

- एक निश्चित प्रक्रिया है जिसे कई उपयोगकर्ता समानांतर में कहते हैं। इस प्रक्रिया के समानांतर निष्पादन को सीमित करने के लिए, अर्थात् सभी का निर्माण कैसे करें
उपयोगकर्ताओं को कतार में इसलिए कि जब तक कोई प्रक्रिया पूरी नहीं कर लेता, तब तक अगला उसका उपयोग शुरू नहीं कर सकता है?

- ठीक प्रक्रिया? या यह पर्याप्त लेनदेन है?

- यह प्रक्रिया है जिसे कुछ लेनदेन में कहा जाता है।

- आप ऑब्जेक्ट पर लॉक लगा सकते हैं। यदि आपके पास एक ही समय में 3 से अधिक नहीं है, तो यह कहना मुश्किल होगा। लेकिन यह साकार है। मैं आमतौर पर लेन-देन के ताले का उपयोग करता हूं, लेकिन गैर-लेन-देन वाले भी संभव हैं।

- मैं अभी भी एक बार फिर से अभिलेखीय डेटा पर लौटना चाहूंगा। आपने बात की
संग्रह भंडारण विकल्प ताकि आवेदन से डेटा भी उपलब्ध हो। यह मेरे लिए एक अलग संग्रह डेटाबेस बनाने के लिए हुआ। अन्य विकल्प क्या हैं?

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

- संग्रह डेटा के बारे में सवाल: आप विभाजन का उपयोग कर सकते हैं - 11 वें संस्करण के नए चिप्स, जब हम पूरी तालिका को विभाजित करते हैं, और फिर बस विभाजन का विस्तार करते हैं और इसे संग्रह के रूप में छोड़ देते हैं। इसे भी एक्सेस किया जा सकता है।

"बेशक, क्यों नहीं।" मैं अगले स्पीकर को रास्ता देता हूं।