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

मॉस्को में एक महीने पहले से थोड़ा अधिक समय के बाद gree समुदाय PGConf.Russia 2019 का सबसे बड़ा सम्मेलन आयोजित किया गया था, जो मॉस्को स्टेट यूनिवर्सिटी में 700 से अधिक लोगों को एक साथ लाया था। हमने एक वीडियो पोस्ट करने और सबसे अच्छी रिपोर्ट ट्रांसक्रिप्ट करने का फैसला किया। PostgreSQL के साथ काम करते समय सामान्य त्रुटियों पर इवान फ्रोलकोव की प्रस्तुति सम्मेलन में सर्वश्रेष्ठ के रूप में नोट की गई थी, इसलिए हम इसके साथ शुरू करेंगे।

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



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

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

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



यहाँ एक वास्तविक उदाहरण है जो मुझे आया था। स्लाइड पर, आप देखते हैं कि विभिन्न स्तंभों में एक ही इकाई का नाम कैसे दिया गया। एक रिक्त स्थान के साथ भी हो सकता है। अन्य वस्तुओं को भी असंगत नाम दिया गया था। यदि आपको किसी अन्य तालिका में कुछ लेने की आवश्यकता है, तो आपको यह देखने की आवश्यकता है कि इसे वहां क्या कहा जाता है, क्या यह वही है। यदि आपके पास एक ही तालिका में id_user और user_id है, तो काम अनुसंधान से शुरू होता है: इसका क्या मतलब होगा।

अन्य ग्राहकों के लिए, सभी वस्तुओं को इस तरह नामित किया गया था: दो अक्षर, फिर पांच अंक। मुझे कहना होगा कि यह "1 सी" नहीं था। उन्होंने ऐसा क्यों किया - मुझे नहीं पता: इसमें कोई तर्क नहीं था, लेकिन प्रश्नों को अनुकूलित करने के लिए यह मेरा व्यवसाय है।

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



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



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



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

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

आप कल्पना भी नहीं कर सकते हैं (ठीक है, शायद कोई पहले से ही कल्पना करता है) भुगतान के विफल होने पर मामले से निपटने के लिए कितना अधिक सुविधाजनक है, जब यह पारित हुआ, लेकिन नहीं। खासकर यदि राशि बड़ी है। यह व्यक्तिगत अनुभव से है।



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

बाधा नाम आमतौर पर एक ORM या सिस्टम द्वारा उत्पन्न होते हैं, और आमतौर पर कोई भी विशेष रूप से बाधाओं को नाम देने के लिए परेशान नहीं होता है - लेकिन व्यर्थ! जब आप त्रुटि को संसाधित करना जारी रखते हैं, तो बाधा के नाम से, आप उपयोगकर्ता को एक स्पष्ट संदेश दे सकते हैं, त्रुटि को वर्गीकृत कर सकते हैं और आपको बता सकते हैं कि क्या फिर से ऑपरेशन करने का प्रयास करना है, या क्या यह ऑपरेशन अब आवश्यक नहीं है, या बस दोहराया नहीं जा सकता है।

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



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

यह डेटाबेस में सुविधाजनक है क्योंकि, मेरे अनुभव में, एक व्यवसाय नियमित रूप से तत्काल परिवर्तन जारी करता है: इसे हटा दें और इसे डालें और यह बहुत दूसरा है। यदि आपके पास संकलित कोड में तर्क है, तो आपको इकट्ठा करने, तैनाती करने की आवश्यकता है, देखें कि क्या हुआ। अक्सर यह असंभव है। डेटाबेस में, यह अधिक सुविधाजनक है। लेकिन एक अच्छी तरह से ज्ञात वाक्पटुता है: अनुभवी फोरट्रान प्रोग्रामर किसी भी भाषा में फोरट्रान में लिखते हैं। लगभग 80 सर्वर कोड पूरी तरह से प्रक्रियात्मक शैली में लिखा गया है: हमारे पास "get_user ()" फ़ंक्शन है और यह "उपयोगकर्ता" टाइप करता है, और यदि "get_list_users ()" है, तो यह "उपयोगकर्ताओं" की एक सरणी देता है। SQL या pgsql की तुलना में जावा में ऐसी चीजें लिखना वास्तव में अधिक सुविधाजनक है।



दूसरी ओर: आपको "get_user ()" फ़ंक्शन की आवश्यकता क्यों है? आप इसे केवल एक तालिका में या एक दृश्य में लेते हैं। चूंकि आपके पास एक संबंधपरक डेटाबेस है, इसलिए आपको लिखना होगा, जैसा कि मुझे लगता है, संबंधपरक। यह महत्वपूर्ण है, सबसे पहले, यह स्पष्ट रूप से निर्धारित करने के लिए कि हम किस डेटा के साथ काम कर रहे हैं: यदि हमारा डेटा कचरा या आधा कचरा है, तो परिणाम उचित होगा, और शायद मारना नहीं चाहिए। यदि डेटा हमारे लिए महत्वपूर्ण है, यदि यह धन, संपत्ति या कानूनी संचालन है, तो बाधा की आवश्यकता है और उतना ही बेहतर है। मैं दोहराता हूं: ऑपरेशन को गलत तरीके से नहीं करना बेहतर है। और एक रिलेशनल डेटाबेस में प्रक्रियात्मक कोड न लिखें: आप इसे बहुत पछताएंगे।



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

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



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

यदि आप डेटाबेस में दस्तावेजों को संग्रहीत करते हैं, तो आप उन्हें वहां संसाधित करने की संभावना नहीं रखते हैं: एक्सेल स्प्रेडशीट, बेशक, सर्वर पर संशोधित किया जा सकता है, लेकिन यह एक अजीब व्यवसाय है। सबसे अधिक संभावना है कि ऐसी फाइलें आमतौर पर आसानी से पढ़ी जाएंगी। दस्तावेजों के लिंक को स्टोर करना बेहतर है, और खुद को कुछ बाहरी भंडारण में। अंत में, आप तालिका के डिजिटल हस्ताक्षर रख सकते हैं - ताकि यह बदल न जाए (यदि आप संबंधित विधायी मुद्दों को तय करते हैं)।

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



एक और कारण है कि डेटाबेस बड़ा है अनावश्यक अनुक्रमित है। बिना इंडेक्स वाले मामले मुझे नहीं मिले, लेकिन अक्सर मैं उन ठिकानों से मिला जहां एक ही क्रम में एक ही कॉलम पर कई सूचकांक मिले। आधार आपको ऐसा करने की अनुमति देता है। जब आप एक इंडेक्स बनाते हैं, तो कृपया देखें कि क्या वह किसी मौजूदा को डुप्लिकेट करता है। आप यह देख सकते हैं कि pg_stat_user_indexes को देखने के लिए कौन से इंडेक्स की आवश्यकता नहीं है, यह देखने के लिए कि इंडेक्स का सक्रिय रूप से उपयोग कैसे किया जाता है। शायद उसकी आवश्यकता ही नहीं है।

मैं एक स्थिति में आया (वैसे, ठेठ), जब एक बहुत बड़ी मेज का विभाजन नहीं होता है। सभी DBMS में, बड़ी तालिकाओं का सबसे अच्छा विभाजन किया जाता है, लेकिन PostgreSQL में यह हमारे प्रिय VACUUM के कारण विशेष रूप से सच है। मैं शायद 100 गीगाबाइट के साथ शुरू होने वाली विभाजन विभाजन की सलाह दूंगा। शायद ५० से शुरू कर रहा हूँ। मैंने देखा कि बिना टेराबाइट की टेबल थी, और वे एसएसडी पर रहते थे। लेकिन यह थोड़ा अधिक है, उन्हें काटना बेहतर होगा।



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

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

[जारी रखा जाए।]