PostgreSQL Antipatterns: "मृत" की भीड़ से लड़ना

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

से संक्षिप्त कहानी बढ़िया लेख:

जब किसी पंक्ति को अपडेट कमांड द्वारा संशोधित किया जाता है, तो वास्तव में दो ऑपरेशन किए जाते हैं: हटाएं और डालें। में स्ट्रिंग का वर्तमान संस्करण xmax को अद्यतन करने वाले लेनदेन की संख्या के बराबर सेट किया गया है। फिर इसे बनाया जाता है एक नया संस्करण वही पंक्ति; इसका xmin मान पिछले संस्करण के xmax मान से मेल खाता है।

इस लेन-देन के पूरा होने के कुछ समय बाद, पुराना या नया संस्करण, इस पर निर्भर करता है COMMIT/ROOLBACK, पहचाना जाएगा "मृत" (मृत टुपल्स) गुजरते समय VACUUM तालिका के अनुसार और साफ़ किया गया।

लेकिन यह तुरंत नहीं होगा, लेकिन "मृत" के साथ समस्याएं बहुत जल्दी हासिल की जा सकती हैं - बार-बार या के साथ अभिलेखों का बड़े पैमाने पर अद्यतनीकरण एक बड़ी मेज पर, और थोड़ी देर बाद आप उसी स्थिति का सामना करेंगे वैक्यूम मदद नहीं कर पाएगा.

#1: मुझे इसे स्थानांतरित करना पसंद है

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

UPDATE tbl SET X = <newX> WHERE pk = $1;

फिर, जैसे-जैसे निष्पादन आगे बढ़ता है, यह पता चलता है कि Y फ़ील्ड को भी अद्यतन किया जाना चाहिए:

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... और फिर Z भी - छोटी-छोटी बातों पर समय क्यों बर्बाद करें?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

अब हमारे पास डेटाबेस में इस रिकॉर्ड के कितने संस्करण हैं? हाँ, 4 टुकड़े! इनमें से, एक प्रासंगिक है, और 3 को आपके बाद [ऑटो]VACUUM द्वारा साफ़ करना होगा।

इसे इस तरह मत करो! उपयोग एक अनुरोध में सभी फ़ील्ड अपडेट करना - लगभग हमेशा विधि का तर्क इस प्रकार बदला जा सकता है:

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: उपयोग ल्यूक से अलग है!

तो, आप अभी भी चाहते थे एक तालिका में अनेक, अनेक रिकॉर्ड अद्यतन करें (उदाहरण के लिए, किसी स्क्रिप्ट या कनवर्टर के उपयोग के दौरान)। और स्क्रिप्ट में कुछ इस तरह उड़ता है:

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

बहुत से लोगों को ऐसे अद्भुत ऑपरेटर के अस्तित्व के बारे में जानकारी नहीं है, इसलिए यहां एक चीट शीट दी गई है IS DISTINCT FROM और अन्य तार्किक ऑपरेटर मदद के लिए:

... और कॉम्प्लेक्स पर संचालन के बारे में थोड़ा ROW()-भाव:

#3: मैं अपनी प्रियतमा को... ब्लॉक करके पहचानता हूं

लॉन्च किए जा रहे हैं दो समान समानांतर प्रक्रियाएं, जिनमें से प्रत्येक प्रविष्टि को चिह्नित करने का प्रयास करता है कि यह "प्रगति पर" है:

UPDATE tbl SET processing = TRUE WHERE pk = $1;

भले ही ये प्रक्रियाएं वास्तव में एक-दूसरे से स्वतंत्र कार्य करती हों, लेकिन एक ही आईडी के भीतर, पहला लेनदेन पूरा होने तक इस अनुरोध पर दूसरा ग्राहक "लॉक" रहेगा।

निर्णय संख्या 1: कार्य पिछले वाले तक कम हो गया है

चलिए इसे फिर से जोड़ते हैं IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

इस रूप में, दूसरा अनुरोध डेटाबेस में कुछ भी नहीं बदलेगा, सब कुछ पहले से ही वैसा ही है - इसलिए, अवरोधन नहीं होगा। इसके बाद, हम लागू एल्गोरिदम में रिकॉर्ड "नहीं ढूंढ पाने" के तथ्य पर कार्रवाई करते हैं।

निर्णय संख्या 2: सलाहकार ताले

एक अलग लेख के लिए एक बड़ा विषय, जिसके बारे में आप पढ़ सकते हैं आवेदन के तरीके और अनुशंसात्मक अवरोधन की "रेक"।.

निर्णय संख्या 3: बेवकूफी भरी कॉल

लेकिन आपके साथ बिल्कुल यही होना चाहिए एक ही रिकॉर्ड के साथ एक साथ काम करना? या क्या आपने उदाहरण के लिए, क्लाइंट साइड पर बिजनेस लॉजिक को कॉल करने के लिए एल्गोरिदम के साथ गड़बड़ी की है? और अगर आप इसके बारे में सोचते हैं?

स्रोत: www.habr.com