प्रॉम्प्ट और संदर्भ
साक्षात्कारकर्ता आपको दो समवर्ती (concurrent) लेनदेन देता है। वे एक ही व्यावसायिक नियम (business rule) को पढ़ते हैं लेकिन विभिन्न रिकॉर्ड अपडेट करते हैं। दोनों पर्याप्त क्षमता देखते हैं, फिर भी अंतिम स्थिति नियम का उल्लंघन करती है। समझाएं कि एक कमजोर आइसोलेशन स्तर क्या अनुमति देता है, Serializable इस परिणाम को कैसे रोकता है, और एप्लिकेशन विफलता को कैसे संभालता है।
यह डेटाबेस समवर्ती नियंत्रण (concurrency control) की सीमाओं का परीक्षण करता है। केवल चार आइसोलेशन-स्तर के नामों को याद करके दोहराने के बजाय स्नैपशॉट दृश्यता, लॉक प्रतीक्षा, टकराव का पता लगाना (conflict detection) और एप्लिकेशन पुनः प्रयासों के बीच अंतर करें।
साक्षात्कारकर्ता क्या परख रहा है
वे एक ठोस इंटरलीविंग चाहते हैं जो विसंगति को स्पष्ट करे, "किसी क्रमिक क्रम (serial order) के समकक्ष" और "प्रत्येक लेनदेन कतार (queue) में लगता है" के बीच का अंतर, और यह व्याख्या कि लेनदेन को रद्द (abort) करना सुरक्षा का हिस्सा क्यों है। Amazon का उत्पाद साक्षात्कार मार्गदर्शन उम्मीदवारों से निर्णयों को मेट्रिक्स और साक्ष्य से जोड़ने के लिए कहता है; एक तकनीकी उत्तर को भी इसी तरह गारंटी, लागत और एप्लिकेशन कार्रवाइयों को स्पष्ट करने की आवश्यकता होती है।
पहले स्पष्ट करने योग्य प्रश्न
पूछें कि कौन सा डेटाबेस और कार्यान्वयन शामिल है, डिफ़ॉल्ट आइसोलेशन स्तर क्या है, रीड/राइट पैटर्न क्या है, क्या इनवेरिएंट को डेटाबेस बाधा (constraint) के रूप में व्यक्त किया जा सकता है, और क्या कॉलर लेनदेन को सुरक्षित रूप से फिर से कर सकता है। PostgreSQL Repeatable Read एक लेनदेन स्नैपशॉट का उपयोग करता है; Serializable संभावित सीरियलाइज़ेशन विसंगतियों का पता लगाना जोड़ता है और एक लेनदेन को रद्द (abort) कर देता है। डेटाबेस में डिफ़ॉल्ट और कार्यान्वयन भिन्न होते हैं।
30-सेकंड की उत्तर संरचना
निष्कर्ष से शुरू करें: Serializable के लिए आवश्यक है कि कमिट किए गए परिणाम किसी क्रमिक निष्पादन (serial execution) के समकक्ष हों, लेकिन इसका मतलब यह नहीं है कि सभी लेनदेन कतार में लग जाएं। Repeatable Read की सीमा दिखाने के लिए दो-लेनदेन वाले राइट-स्क्यू (write-skew) इंटरलीविंग का उपयोग करें, फिर समझाएं कि Serializable एक खतरनाक निर्भरता का पता लगाता है और सीरियलाइज़ेशन विफलता लौटाता है। पूरे लेनदेन को पुनः प्रयास करने, सीमित प्रयासों, इडेम्पोटेंसी (idempotency) और टकराव की निगरानी के साथ समाप्त करें।
चरण-दर-चरण विश्लेषण
चरण 1: इंटरलीविंग के साथ विसंगति का वर्णन करें
मान लीजिए कि नियम है "कम से कम एक ऑन-कॉल डॉक्टर सक्रिय रहना चाहिए।" लेनदेन A पढ़ता है कि डॉक्टर B सक्रिय है; लेनदेन B पढ़ता है कि डॉक्टर A सक्रिय है। A खुद को ड्यूटी से हटा देता है और B भी ऐसा ही करता है। प्रत्येक लेनदेन केवल अपनी पंक्ति को अपडेट करता है, इसलिए कोई प्रत्यक्ष राइट-राइट टकराव नहीं होता है, लेकिन अंतिम स्थिति में कोई भी ऑन-कॉल नहीं रहता है। यह राइट स्क्यू दिखाता है कि व्यक्तिगत रूप से मान्य स्नैपशॉट हर संयुक्त व्यावसायिक इनवेरिएंट को बनाए नहीं रखते हैं।
चरण 2: स्नैपशॉट स्थिरता को क्रमिक तुल्यता से अलग करें
Repeatable Read एक लेनदेन को एक स्थिर दृश्य देता है और बाद के समवर्ती कमिट को उजागर नहीं करता है। यह वादा नहीं करता है कि रीड और राइट के पूर्ण सेट को एक ऐसे क्रमिक क्रम में व्यवस्थित किया जा सकता है जो प्रत्येक व्यावसायिक नियम को संरक्षित करता हो। स्नैपशॉट आइसोलेशन समवर्तीता में सुधार कर सकता है, लेकिन एप्लिकेशन को पता होना चाहिए कि यह किन विसंगतियों को रोकता है और किन्हें संभव छोड़ता है।
चरण 3: Serializable की गारंटी बताएं
Serializable का लक्ष्य कमिट किए गए परिणामों को ऐसे निष्पादन के समकक्ष बनाना है जिसमें लेनदेन एक-एक करके चलते हैं। एक कार्यान्वयन में लॉक, टकराव का पता लगाना या Serializable Snapshot Isolation का उपयोग किया जा सकता है; इसके लिए प्रत्येक रीड को प्रत्येक अन्य लेनदेन को ब्लॉक करने की आवश्यकता नहीं होती है। PostgreSQL रीड-राइट निर्भरताओं की निगरानी करता है और जब वे एक सीरियलाइज़ेशन विसंगति बना सकते हैं, तो लेनदेन को विफल कर देता है।
चरण 4: बताएं कि पूरे लेनदेन को पुनः प्रयास क्यों करना चाहिए
विफलता कमिट पर या कमिट के करीब हो सकती है, और डेटाबेस यह निष्कर्ष नहीं निकाल सकता है कि एप्लिकेशन लॉजिक को फिर से चलाना सुरक्षित है या नहीं। केवल अंतिम UPDATE को फिर से भेजने के बजाय रोल बैक करें और पहले रीड से फिर से चलाएं। पुनः प्रयासों को सीमित करें और बैकऑफ़ का उपयोग करें। बाहरी साइड इफेक्ट्स को कमिट के बाद ले जाएं, या उन्हें इडेम्पोटेंसी कुंजियों और एक टिकाऊ इवेंट रिकॉर्ड के साथ अलग करें।
चरण 5: लागतों की तुलना करें और चुनें
Serializable एक्सेस पैटर्न के आधार पर टकराव, पुनः प्रयास, मेमोरी या लॉक-प्रबंधन कार्य और विलंबता (latency) को बढ़ा सकता है। मजबूत इनवेरिएंट वाले बैलेंस, इन्वेंट्री या कोटा के लिए, लागत उचित हो सकती है। सन्निकटन (approximation) को सहन करने वाली केवल-पठन (read-only) रिपोर्ट कमजोर स्तर का उपयोग कर सकती हैं। इनवेरिएंट, समवर्तीता, विलंबता लक्ष्य और विफलता-संचालन क्षमता को एक साथ देखकर चयन करें।
उच्च गुणवत्ता वाला नमूना उत्तर
Serializable गारंटी देता है कि प्रत्येक कमिट किया गया परिणाम किसी क्रमिक क्रम के समकक्ष है; इसके लिए डेटाबेस को सभी लेनदेनों को कतारबद्ध करने की आवश्यकता नहीं होती है। "कम से कम एक डॉक्टर ऑन-कॉल है" नियम के साथ, दो Repeatable Read लेनदेन प्रत्येक दूसरे डॉक्टर को ऑन-कॉल देख सकते हैं और फिर खुद को ड्यूटी से हटा सकते हैं। वे एक ही पंक्ति को अपडेट नहीं करते हैं, फिर भी मिलकर राइट स्क्यू बनाते हैं और इनवेरिएंट का उल्लंघन करते हैं।
Serializable उस रीड-राइट निर्भरता का पता लगाता है जो इस विसंगति को पैदा कर सकती है और एक लेनदेन को सीरियलाइज़ेशन विफलता के साथ समाप्त करता है। एप्लिकेशन को रोल बैक करना चाहिए और सीमित प्रयासों और बैकऑफ़ के साथ शुरुआत से पुनः प्रयास करना चाहिए। ईमेल, चार्जिंग और अन्य बाहरी प्रभाव कमिट के बाद या इडेम्पोटेंसी कुंजी के पीछे होने चाहिए। मैं इन्वेंट्री, बैलेंस और कोटा के लिए मजबूत स्तर का उपयोग करूंगा, और विसंगति और पुनः प्रयास दरों की निगरानी करते हुए अनुमानित रिपोर्टों के लिए कमजोर आइसोलेशन का मूल्यांकन करूंगा।
सामान्य गलतियाँ और सुधार
- यह कहना कि Serializable का अर्थ वैश्विक कतारबद्धता (global queuing) है: कहें "किसी क्रमिक क्रम के समकक्ष।"
- केवल लॉक का उल्लेख करना: टकराव का पता लगाना और कार्यान्वयन अंतर शामिल करें।
- केवल अंतिम SQL स्टेटमेंट का पुनः प्रयास करना: संपूर्ण लेनदेन को फिर से चलाएं।
- साइड इफेक्ट्स को अनदेखा करना: पोस्ट-कमिट इवेंट, इडेम्पोटेंसी कुंजियों या डिडुप्लीकेशन रिकॉर्ड का उपयोग करें।
- यह कहना कि Repeatable Read में कोई विसंगतियां नहीं हैं: राइट स्क्यू या सीरियलाइज़ेशन विसंगतियों को स्वीकार करें।
अनुवर्ती प्रश्न और उत्तर
केवल-पठन (read-only) लेनदेन अभी भी Serializable पर विफल क्यों हो सकता है?
इसके रीड ऐसी निर्भरताओं में भाग ले सकते हैं जो किसी अन्य लेनदेन के कमिट किए गए परिणाम को गैर-क्रमबद्ध (non-serializable) बनाती हैं। वैश्विक गारंटी को बनाए रखने के लिए डेटाबेस लेनदेन को रद्द कर सकता है; जब ऑपरेशन को दोहराना सुरक्षित हो तो एप्लिकेशन को त्रुटि को पुनः प्रयास करने योग्य मानना चाहिए।
क्या प्रत्येक अनुरोध को Serializable का उपयोग करना चाहिए?
नहीं। व्यावसायिक इनवेरिएंट और वर्कलोड से शुरुआत करें। जहां कोई विसंगति अस्वीकार्य हो वहां मजबूत स्तर का उपयोग करें, और जहां अनुमानित रीड स्वीकार्य हों और प्रदर्शन ट्रेड-ऑफ मापा गया हो वहां कमजोर स्तर चुनें।
पुनः प्रयास में सभी रीड्स क्यों शामिल होने चाहिए?
टकराव का निर्णय पूर्ण रीड और राइट सेट पर निर्भर करता है। केवल अंतिम राइट को फिर से चलाने से पुराने अनुमानों का उपयोग हो सकता है और वही विसंगति दोबारा उत्पन्न हो सकती है।
आप कैसे निरीक्षण करते हैं कि पुनः प्रयास स्वस्थ हैं या नहीं?
लेनदेन प्रकार के आधार पर सीरियलाइज़ेशन विफलताओं, पुनः प्रयास सफलता दर, पुनः प्रयास विलंबता, समाप्त हो चुके प्रयासों और उपयोगकर्ता-दृश्यमान त्रुटियों को ट्रैक करें। एक उच्च पुनः प्रयास दर एक अत्यधिक प्रतिस्पर्धी (hot) इनवेरिएंट या ऐसे एक्सेस पैटर्न का संकेत दे सकती है जिसे पुनर्गठन (redesign) की आवश्यकता है।