डाटाबेसमा लेनदेन अलगाव स्तर कमजोर गर्दा के परिणाम हुन सक्छ?

नमस्ते सबै। Vladislav Rodin सम्पर्कमा हुनुहुन्छ। म हाल OTUS मा हाई वर्कलोड आर्किटेक्ट कोर्सको लागि कोर्स लीडर हुँ र सफ्टवेयर आर्किटेक्चर पाठ्यक्रमहरू पनि सिकाउँछु।

अध्यापनको अतिरिक्त, तपाईले याद गर्नु भएको हुनसक्छ, म Habré मा OTUS ब्लगको लागि मौलिक सामग्री लेख्दै छु र म आजको लेखलाई पाठ्यक्रमको सुरुवातसँग मेल खान चाहन्छु। "PostgreSQL", जुन अहिले भर्नाको लागि खुला छ।

परिचय

В अन्तिम पटक हामीले तथ्यको बारेमा कुरा गर्यौं कि डाटाबेसमा लेनदेनले दुई समस्याहरू समाधान गर्न सेवा गर्दछ: गल्ती सहिष्णुता र प्रतिस्पर्धात्मक वातावरणमा डेटामा पहुँच सुनिश्चित गर्ने। यी कार्यहरू पूर्ण रूपमा गर्नको लागि, लेनदेनमा ACID गुणहरू हुनुपर्छ। आज हामी पत्र बारे विस्तृत कुरा गर्नेछौं म (अलगाव) यस संक्षिप्तमा।

इन्सुलेशन

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

सबैभन्दा प्रख्यात विसंगतिहरू हुन्: फोहोर पढ्ने, दोहोर्याउन नसकिने पढ्ने, फ्यान्टम पढ्ने, तर वास्तवमा त्यहाँ 5 थप छन्: फोहोर लेख, कर्सर हराएको अपडेट, हराएको अद्यावधिक, स्क्यू पढ्नुहोस्, स्क्यु लेख्नुहोस्।

फोहोर लेखे

विसंगतिको सार यो हो कि लेनदेनले असीमित डेटा अधिलेखन गर्न सक्छ।

यो विसंगति खतरनाक छ किनभने डेटा दुवै लेनदेन (तस्बिरमा जस्तै) कमिट पछि विवाद हुन सक्छ, तर परमाणुता उल्लङ्घन भएको कारण पनि: हामीले असीमित डेटालाई अधिलेखन गर्न अनुमति दिनुभएकोले, यो स्पष्ट छैन कि कसरी अर्को लेनदेनलाई असर नगरी फिर्ता गर्ने। ।

विसंगतिलाई एकदम सरल रूपमा व्यवहार गर्न सकिन्छ: हामी रेकर्डिङ सुरु गर्नु अघि रेकर्डमा लक जोड्छौं, लक नहटाएसम्म रेकर्ड परिवर्तन गर्न अन्य लेनदेनहरूलाई निषेध गर्दछ।

फोहोर पढियो

डर्टी रिड भनेको अनकमिटेड डाटा पढ्नु हो।

नमूनाको आधारमा कार्य वा निर्णय गर्न आवश्यक हुँदा समस्याहरू उत्पन्न हुन्छन्।

विसंगति सच्याउन, तपाइँ पढ्ने लक संलग्न गर्न सक्नुहुन्छ, तर यसले कार्यसम्पादनमा ठूलो प्रभाव पार्छ। यो भन्न धेरै सरल छ कि रोलब्याक लेनदेनको लागि, डाटाको प्रारम्भिक अवस्था (रेकर्डिङ सुरु हुनु अघि) प्रणालीमा सुरक्षित हुनुपर्छ। त्यहाँबाट किन नपढ्ने ? यो पर्याप्त सस्तो छ कि धेरै डाटाबेसहरू पूर्वनिर्धारित रूपमा फोहोर पढाइ हटाउँछन्।

अपडेट हरायो

हराएको अपडेट भनेको हराएको अपडेट हो, र अनुवादले समस्याको सारलाई एकदम सही रूपमा प्रतिबिम्बित गर्दछ:

वास्तवमा, लेनदेन T2 को परिणाम उल्टो थियो। यो अवस्था स्पष्ट वा निहित लेखन लकहरू द्वारा सच्याउन सकिन्छ। त्यो हो, हामी या त केवल रेकर्ड अपडेट गर्छौं, र त्यसपछि एक निहित लक हुन्छ, वा हामी प्रदर्शन गर्छौं अपडेटका लागि चयन गर्नुहोस्, पढ्ने र लेख्ने लक हुने कारण। कृपया ध्यान दिनुहोस् कि यस्तो अपरेशन एकदम खतरनाक छ: हाम्रो "निर्दोष" पढाइको साथ, हामी अन्य पठनहरू रोक्छौं। केही डाटाबेसहरू थप सुरक्षित प्रस्ताव गर्छन् साझेदारीको लागि चयन गर्नुहोस्, डेटा पढ्न तर परिमार्जन गर्न अनुमति दिँदै।

कर्सर हरायो अपडेट

राम्रो नियन्त्रणको लागि, आधारहरूले अन्य उपकरणहरू प्रस्ताव गर्न सक्छ, जस्तै कर्सर। कर्सर एक संरचना हो जसले पङ्क्तिहरूको सेट समावेश गर्दछ र तपाईंलाई तिनीहरूमा दोहोर्याउन अनुमति दिन्छ। चयन_स्टेटमेन्टको लागि कर्सर_नाम घोषणा गर्नुहोस्। कर्सरको सामग्री चयन गरेर वर्णन गरिएको छ।

तपाईलाई कर्सर किन चाहिन्छ? तथ्य यो हो कि केहि डाटाबेसहरूले चयन (पढ्नुहोस् स्थिरता) द्वारा चयन गरिएका सबै रेकर्डहरूमा लक प्रदान गर्दछ, वा केवल रेकर्डमा जहाँ कर्सर हाल अवस्थित छ (कर्सर स्थिरता)। कर्सर स्थिरताको साथ, छोटो लक लागू गरिएको छ, जसले हामीलाई लकहरूको संख्या घटाउन अनुमति दिन्छ यदि हामी डेटाको ठूलो नमूनामा दोहोर्याउँछौं। यसैले, हराएको अद्यावधिक विसंगति कर्सरको लागि अलग अलग गरिएको छ।

दोहोर्याउन नसकिने पढाइ

दोहोर्याउन नसकिने पढाइ यो हो कि हाम्रो लेनदेनको कार्यान्वयनको क्रममा, एउटै रेकर्डको लगातार २ वटा पढाइले फरक परिणाम ल्याउनेछ, किनभने अर्को लेनदेनले यी दुई पढाइहरू बीच हस्तक्षेप गर्‍यो, हाम्रो डेटा परिवर्तन भयो र प्रतिबद्ध भयो।

यो पनि किन समस्या हो? कल्पना गर्नुहोस् कि चित्रमा लेनदेन T2 को लक्ष्य सबै सामानहरू चयन गर्नु हो जसको मूल्य 150 USD भन्दा कम छ। अरू कसैले $200 मा मूल्य अद्यावधिक गर्नुभयो। यसरी, स्थापित फिल्टरले काम गरेन।

यी विसंगतिहरू बन्द हुन्छन् जब दुई-चरण इन्टरलकहरू थपिन्छन् वा जब MVCC मेकानिज्म प्रयोग गरिन्छ, जुन म छुट्टै छलफल गर्न चाहन्छु।

प्रेत पढियो

Phantom डेटाको पढाइ हो जुन अर्को लेनदेन द्वारा थपिएको थियो।

उदाहरणको रूपमा, यो विसंगति हुँदा हामी सस्तो उत्पादनको गलत चयन अवलोकन गर्न सक्छौं।

फ्यान्टम रिड्सबाट छुटकारा पाउन पहिले नै धेरै गाह्रो छ। नियमित अवरुद्ध पर्याप्त छैन, किनकि हामी अझै अवस्थित नभएको कुरालाई रोक्न सक्दैनौं। 2PL प्रणालीहरूले भविष्यवाणी गर्ने लकिङ प्रयोग गर्दछ, जबकि MVCC प्रणालीहरूमा लेनदेन अनुसूचक छ जसले लेनदेनहरू रोल ब्याक गर्छ जुन घुसाउन सक्छ। दुवै पहिलो र दोस्रो संयन्त्र एकदम भारी छन्।

स्क्यु पढ्नुहोस्

रिड स्क्यु तब हुन्छ जब हामी धेरै तालिकाहरूसँग काम गर्छौं, जसको सामग्रीहरू लगातार परिवर्तन हुनुपर्छ।

मानौं हामीसँग पोष्टहरू र तिनीहरूको मेटा जानकारी प्रतिनिधित्व गर्ने तालिकाहरू छन्:

एउटा लेनदेन टेबलबाट पढ्छ, अर्कोले तिनीहरूलाई परिमार्जन गर्दछ:

लेनदेन T1 को परिणामको रूपमा, पोस्टमा शीर्षक = राम्रो, र अपडेट गरिएको_द्वारा = T2 छ, जुन केहि प्रकारको असंगतता हो।

वास्तवमा, यो एक दोहोर्याउन नसकिने पढ्ने हो, तर धेरै तालिकाहरूको भागको रूपमा।

यसलाई ठीक गर्न, T1 ले पढ्ने सबै पङ्क्तिहरूमा लकहरू राख्न सक्छ, जसले लेनदेन T2 लाई जानकारी परिवर्तन गर्नबाट रोक्छ। MVCC को अवस्थामा, T2 लेनदेन रद्द हुनेछ। यदि हामीले कर्सरहरू प्रयोग गर्छौं भने यो विसंगति विरुद्ध सुरक्षा महत्त्वपूर्ण हुन सक्छ।

तिरछा लेख्नुहोस्

यो विसंगतिलाई उदाहरणको साथ व्याख्या गर्न पनि सजिलो छ: मानौं कि हाम्रो प्रणालीमा कम्तिमा एक डाक्टर ड्युटीमा हुनुपर्छ, तर दुबै डाक्टरहरूले आफ्नो कर्तव्य रद्द गर्ने निर्णय गरे:

विसंगतिको अर्थ कोही पनि डाक्टर ड्युटीमा छैनन्। किन यस्तो भयो ? किनभने लेनदेनले अर्को लेनदेनले उल्लङ्घन गर्न सक्ने अवस्थाको जाँच गरिरहेको थियो, र अलगावका कारण हामीले यो परिवर्तन देखेनौं।

यो उस्तै नदोहोरिने पढ्ने हो। वैकल्पिक रूपमा, चयनहरूले यी रेकर्डहरूमा लकहरू राख्न सक्छन्।

स्क्यू लेख्नुहोस् र स्क्यू पढ्नुहोस् अघिल्लो विसंगतिहरूको संयोजन हो। तपाईले लेख्ने स्क्यूलाई विचार गर्न सक्नुहुन्छ, जुन अनिवार्य रूपमा एक प्रेत पढ्ने हो। एउटा तालिकालाई विचार गर्नुहोस् जसमा कर्मचारीहरूको नाम, तिनीहरूको तलब, र तिनीहरूले काम गर्ने परियोजना समावेश छन्:

नतिजाको रूपमा, हामीले निम्न तस्विर पाउँछौं: प्रत्येक प्रबन्धकले सोचेका थिए कि तिनीहरूको परिवर्तनले बजेटमा जानेछैन, त्यसैले तिनीहरूले कर्मचारी परिवर्तनहरू गरे जसले सँगै लागत ओभररन निम्त्यायो।

समस्याको कारण ठ्याक्कै प्रेत पढाइमा जस्तै छ।

निष्कर्ष

डाटाबेसमा लेनदेन अलगाव स्तरलाई आराम गर्नु सुरक्षा र कार्यसम्पादन बीचको व्यापार हो; यस स्तरको छनोटलाई व्यवसायमा हुने सम्भावित जोखिमहरूको आधारमा सम्पर्क गरिनु पर्छ यदि निश्चित विसंगतिहरू देखा पर्छन्।

पाठ्यक्रम बारे थप जान्नुहोस्।

स्रोत: www.habr.com