डेटाबेसमधील व्यवहार अलगाव पातळी कमकुवत केल्याने काय परिणाम होऊ शकतात?

सर्वांना नमस्कार. व्लादिस्लाव रॉडिन संपर्कात आहे. मी सध्या OTUS मधील हाय वर्कलोड आर्किटेक्ट कोर्ससाठी कोर्स लीडर आहे आणि सॉफ्टवेअर आर्किटेक्चर कोर्स देखील शिकवतो.

अध्यापनाच्या व्यतिरिक्त, तुमच्या लक्षात आले असेल की, मी Habré वरील OTUS ब्लॉगसाठी मूळ साहित्य लिहित आहे आणि मला आजच्या लेखाशी एकरूप व्हायचे आहे. "पोस्टग्रेएसक्यूएल", जे सध्या नावनोंदणीसाठी खुले आहे.

परिचय

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

इन्सुलेशन

अलगाव स्पर्धात्मक वातावरणात डेटा ऍक्सेस करण्याच्या समस्येचे निराकरण करते, मूलत: शर्यतीच्या परिस्थितीपासून संरक्षण प्रदान करते. तद्वतच, पृथक्करण म्हणजे अनुक्रमिकरण, ही एक अशी मालमत्ता आहे जी समांतरपणे व्यवहार पार पाडण्याचे परिणाम ते क्रमशः अंमलात आणल्याप्रमाणेच असल्याचे सुनिश्चित करते. या मालमत्तेची मुख्य समस्या अशी आहे की तांत्रिकदृष्ट्या प्रदान करणे खूप कठीण आहे आणि परिणामी, सिस्टम कार्यक्षमतेवर महत्त्वपूर्ण प्रभाव पडतो. म्हणूनच, विशिष्ट विसंगतींचे धोके स्वीकारून अलगाव अनेकदा कमकुवत होतो, ज्याची खाली चर्चा केली जाईल. विशिष्ट विसंगती उद्भवण्याची शक्यता व्यवहार अलगावची पातळी निश्चितपणे दर्शवते.

सर्वात सुप्रसिद्ध विसंगती आहेत: गलिच्छ वाचन, पुनरावृत्ती न करता येणारे वाचन, फॅंटम रीड, परंतु प्रत्यक्षात आणखी 5 आहेत: घाणेरडे लेखन, कर्सर गमावले अद्यतन, हरवलेले अद्यतन, तिरकस वाचणे, स्क्यू लिहिणे.

गलिच्छ लेखन

विसंगतीचा सार असा आहे की व्यवहार अप्रतिबंधित डेटा ओव्हरराइट करू शकतात.

ही विसंगती केवळ धोकादायक आहे कारण दोन्ही व्यवहार केल्यानंतर (चित्राप्रमाणे) डेटामध्ये संघर्ष होऊ शकतो, परंतु अणुत्वाचे उल्लंघन केल्यामुळे देखील: आम्ही अप्रतिबंधित डेटा ओव्हरराईट करण्याची परवानगी देत ​​असल्याने, दुसर्‍या व्यवहारावर परिणाम न करता एक व्यवहार कसा परत करायचा हे स्पष्ट होत नाही. .

विसंगती अगदी सोप्या पद्धतीने हाताळली जाऊ शकते: आम्ही रेकॉर्डिंग सुरू करण्यापूर्वी रेकॉर्डला एक लॉक जोडतो, लॉक काढून टाकेपर्यंत रेकॉर्ड बदलण्यापासून इतर व्यवहारांना प्रतिबंधित करतो.

गलिच्छ वाचा

डर्टी रीड म्हणजे अनकमिटेड डेटा वाचणे.

जेव्हा नमुन्याच्या आधारे कृती किंवा निर्णय घेणे आवश्यक असते तेव्हा समस्या उद्भवतात.

विसंगती दुरुस्त करण्यासाठी, तुम्ही रीड लॉक संलग्न करू शकता, परंतु हे कार्यप्रदर्शनावर मोठ्या प्रमाणात परिणाम करेल. हे सांगणे खूप सोपे आहे की रोलबॅक व्यवहारासाठी, डेटाची प्रारंभिक स्थिती (रेकॉर्डिंग सुरू होण्यापूर्वी) सिस्टममध्ये जतन करणे आवश्यक आहे. तिथून का वाचले नाही? हे पुरेसे स्वस्त आहे की बहुतेक डेटाबेस डीफॉल्टनुसार गलिच्छ वाचन काढून टाकतात.

अपडेट गमावले

हरवलेले अपडेट म्हणजे हरवलेले अपडेट, आणि भाषांतर अगदी अचूकपणे समस्येचे सार प्रतिबिंबित करते:

खरं तर, व्यवहार T2 चा परिणाम उलट झाला. ही परिस्थिती स्पष्ट किंवा अंतर्निहित लेखन लॉकद्वारे दुरुस्त केली जाऊ शकते. म्हणजेच, आम्ही एकतर फक्त रेकॉर्ड अद्ययावत करतो आणि नंतर एक अंतर्निहित लॉक उद्भवतो किंवा आम्ही कार्य करतो अद्यतनासाठी निवडा, ज्यामुळे वाचन आणि लेखन लॉक होते. कृपया लक्षात घ्या की असे ऑपरेशन खूप धोकादायक आहे: आमच्या "निर्दोष" वाचनासह, आम्ही इतर वाचन अवरोधित करतो. काही डेटाबेस अधिक सुरक्षित ऑफर करतात शेअरसाठी निवडा, डेटा वाचण्याची परवानगी देतो परंतु सुधारित नाही.

कर्सर अद्यतन गमावला

बारीक नियंत्रणासाठी, बेस इतर साधने देऊ शकतात, जसे की कर्सर. कर्सर ही एक रचना आहे ज्यामध्ये पंक्तींचा संच असतो आणि तुम्हाला त्यावर पुनरावृत्ती करण्याची परवानगी देते. सिलेक्ट_स्टेटमेंटसाठी कर्सर_नाव घोषित करा. कर्सरची सामग्री निवडून वर्णन केली जाते.

तुम्हाला कर्सरची गरज का आहे? वस्तुस्थिती अशी आहे की काही डेटाबेस सिलेक्ट (वाचन स्थिरता) द्वारे निवडलेल्या सर्व रेकॉर्डवर लॉक ऑफर करतात किंवा फक्त त्या रेकॉर्डवर ज्यावर कर्सर सध्या स्थित आहे (कर्सर स्थिरता). कर्सर स्थिरतेसह, लहान लॉक लागू केले जाते, जे आम्हाला डेटाच्या मोठ्या नमुन्यावर पुनरावृत्ती केल्यास लॉकची संख्या कमी करण्यास अनुमती देते. त्यामुळे, हरवलेली अपडेट विसंगती कर्सरसाठी वेगळी केली जाते.

पुनरावृत्ती न करता येणारे वाचन

पुनरावृत्ती न करता येणारे वाचन असे आहे की आमच्या व्यवहाराच्या अंमलबजावणीदरम्यान, समान रेकॉर्डचे सलग 2 वाचन भिन्न परिणामांना कारणीभूत ठरतील, कारण या दोन रीडमधील दुसर्‍या व्यवहाराने हस्तक्षेप केला, आमचा डेटा बदलला आणि वचनबद्ध झाले.

ही एक समस्या का आहे? कल्पना करा की चित्रातील T2 व्यवहाराचे उद्दिष्ट 150 USD पेक्षा कमी असलेल्या सर्व वस्तूंची निवड करणे आहे. इतर कोणीतरी किंमत $200 पर्यंत अपडेट केली. अशा प्रकारे, स्थापित फिल्टर कार्य करत नाही.

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

फॅन्टम वाचले

Phantom म्हणजे डेटाचे वाचन जे दुसर्‍या व्यवहाराद्वारे जोडले गेले.

उदाहरण म्हणून, जेव्हा ही विसंगती उद्भवते तेव्हा आम्ही सर्वात स्वस्त उत्पादनाची चुकीची निवड पाहू शकतो.

फॅंटम रीड्सपासून मुक्त होणे आधीच खूप कठीण आहे. नियमित अवरोधित करणे पुरेसे नाही, कारण आम्ही अद्याप अस्तित्वात नसलेली एखादी गोष्ट अवरोधित करू शकत नाही. 2PL सिस्टीम प्रेडिक्टिव लॉकिंगचा वापर करतात, तर MVCC सिस्टीममध्ये ट्रान्झॅक्शन शेड्युलर असतो जो इन्सर्टमुळे व्यत्यय आणू शकणारे व्यवहार परत आणतो. पहिली आणि दुसरी दोन्ही यंत्रणा खूप जड आहेत.

स्क्यू वाचा

जेव्हा आम्ही अनेक सारण्यांसह कार्य करतो तेव्हा रीड स्क्यू उद्भवते, त्यातील सामग्री सातत्याने बदलली पाहिजे.

समजा आमच्याकडे पोस्ट्स आणि त्यांच्या मेटा माहितीचे प्रतिनिधित्व करणारी सारणी आहेत:

एक व्यवहार सारण्यांमधून वाचतो, दुसरा त्यांना सुधारतो:

व्यवहार T1 च्या परिणामी, पोस्टमध्ये शीर्षक = चांगले, आणि अद्यतनित_बाय = T2 आहे, जे काही प्रकारची विसंगती आहे.

खरं तर, हे पुनरावृत्ती न करता येणारे वाचन आहे, परंतु अनेक सारण्यांचा भाग म्हणून.

याचे निराकरण करण्यासाठी, T1 वाचेल त्या सर्व पंक्तींवर लॉक लावू शकते, जे T2 ला माहिती बदलण्यापासून रोखेल. MVCC च्या बाबतीत, T2 व्यवहार रद्द केला जाईल. आपण कर्सर वापरल्यास या विसंगतीपासून संरक्षण महत्त्वाचे होऊ शकते.

तिरकस लिहा

ही विसंगती उदाहरणासह स्पष्ट करणे देखील सोपे आहे: समजा की आपल्या सिस्टममध्ये किमान एक डॉक्टर कर्तव्यावर असावा, परंतु दोन्ही डॉक्टरांनी त्यांचे कर्तव्य रद्द करण्याचा निर्णय घेतला:

या विसंगतीचा अर्थ असा होता की एकही डॉक्टर ड्युटीवर नसेल. असे का घडले? कारण व्यवहार दुसर्‍या व्यवहाराद्वारे उल्लंघन होऊ शकेल अशी स्थिती तपासत होता आणि अलगावमुळे आम्हाला हा बदल दिसला नाही.

हे असेच पुनरावृत्ती न करता येणारे वाचन आहे. वैकल्पिकरित्या, निवडक या रेकॉर्डवर लॉक ठेवू शकतात.

तिरकस लिहा आणि स्क्यू वाचणे हे मागील विसंगतींचे संयोजन आहेत. तुम्ही लेखन स्क्यूचा विचार करू शकता, जे मूलत: एक फॅन्टम रीड आहे. कर्मचार्‍यांची नावे, त्यांचे पगार आणि ते ज्या प्रकल्पावर काम करतात अशा तक्त्याचा विचार करा:

परिणामी, आम्हाला खालील चित्र मिळते: प्रत्येक व्यवस्थापकाला वाटले की त्यांच्या बदलामुळे बजेट ओलांडले जाणार नाही, म्हणून त्यांनी कर्मचारी बदल केले ज्यामुळे एकत्रितपणे खर्च वाढला.

समस्येचे कारण फॅंटम वाचनासारखेच आहे.

निष्कर्ष

डेटाबेसमधील व्यवहार अलगाव पातळी शिथिल करणे ही सुरक्षा आणि कार्यप्रदर्शन यांच्यातील एक व्यापार-बंद आहे; काही विसंगती आढळल्यास व्यवसायाच्या संभाव्य जोखमीच्या आधारावर या स्तराची निवड करणे आवश्यक आहे.

कोर्सबद्दल अधिक जाणून घ्या.

स्त्रोत: www.habr.com