ऍप्लिकेशनमध्ये ACID कसे लागू करावे: सराव

८.१ व्यवहार आयडी

हे XID किंवा TxID म्हणून नियुक्त केले आहे (जर काही फरक असेल तर मला सांगा). टाइमस्टॅम्प्स TxID म्हणून वापरले जाऊ शकतात, जे आम्हाला वेळेत सर्व क्रिया पुनर्संचयित करायचे असल्यास हातात खेळू शकतात. टाइमस्टॅम्प पुरेसा दाणेदार नसल्यास समस्या उद्भवू शकते - नंतर व्यवहारांना समान आयडी मिळू शकतो.

म्हणून, सर्वात विश्वासार्ह पर्याय म्हणजे अद्वितीय UUID प्रोड आयडी तयार करणे. पायथनमध्ये हे खूप सोपे आहे:

>>> import uuid 
>>> str(uuid.uuid4()) 
'f50ec0b7-f960-400d-91f0-c42a6d44e3d0' 
>>> str(uuid.uuid4()) 
'd15bed89-c0a5-4a72-98d9-5507ea7bc0ba' 

व्यवहार-परिभाषित डेटाचा संच हॅश करण्याचा आणि हा हॅश TxID म्हणून वापरण्याचा पर्याय देखील आहे.

8.2 पुन्हा प्रयत्न

जर आपल्याला माहित असेल की एखादे विशिष्ट फंक्शन किंवा प्रोग्राम अशक्त आहे, तर याचा अर्थ असा आहे की त्रुटी आढळल्यास आपण त्याचा कॉल पुन्हा करण्याचा प्रयत्न करू शकतो आणि केला पाहिजे. आणि आम्हाला फक्त या वस्तुस्थितीसाठी तयार असले पाहिजे की काही ऑपरेशन्स त्रुटी देईल - आधुनिक अनुप्रयोग नेटवर्क आणि हार्डवेअरवर वितरित केले जातात हे लक्षात घेता, त्रुटी अपवाद म्हणून नव्हे तर सामान्य मानली पाहिजे. सर्व्हर क्रॅश, नेटवर्क एरर, रिमोट अॅप्लिकेशन कंजेशन यामुळे त्रुटी येऊ शकते. आमचा अर्ज कसा वागला पाहिजे? ते बरोबर आहे, ऑपरेशन पुन्हा करण्याचा प्रयत्न करा.

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

import logging
import random
import sys
from tenacity import retry, stop_after_attempt, stop_after_delay, wait_exponential, retry_if_exception_type, before_log

logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
logger = logging.getLogger(__name__)

@retry(
	stop=(stop_after_delay(10) | stop_after_attempt(5)),
	wait=wait_exponential(multiplier=1, min=4, max=10),
	retry=retry_if_exception_type(IOError),
	before=before_log(logger, logging.DEBUG)
)
def do_something_unreliable():
	if random.randint(0, 10) > 1:
    	raise IOError("Broken sauce, everything is hosed!!!111one")
	else:
    	return "Awesome sauce!"

print(do_something_unreliable.retry.statistics)

> फक्त बाबतीत, मी म्हणेन: \@retry(...) एक विशेष पायथन वाक्यरचना आहे ज्याला "डेकोरेटर" म्हणतात. हे फक्त एक retry(...) फंक्शन आहे जे दुसरे फंक्शन गुंडाळते आणि ते कार्यान्वित होण्यापूर्वी किंवा नंतर काहीतरी करते.

जसे आपण पाहू शकतो, पुन्हा प्रयत्न सर्जनशीलपणे डिझाइन केले जाऊ शकतात:

• तुम्ही वेळेनुसार (10 सेकंद) किंवा प्रयत्नांच्या संख्येनुसार (5) प्रयत्न मर्यादित करू शकता.
• घातांक असू शकते (म्हणजे, 2 ** काही वाढणारी संख्या n). किंवा वेगळ्या प्रयत्नांमधील वेळ वाढवण्यासाठी (उदाहरणार्थ, निश्चित). घातांकीय प्रकाराला "कंजेशन कोलॅप्स" असे म्हणतात.
• तुम्ही फक्त विशिष्ट प्रकारच्या त्रुटींसाठी (IOError) पुन्हा प्रयत्न करू शकता.
• लॉगमधील काही विशेष नोंदींद्वारे पुन्हा प्रयत्न करण्याचा प्रयत्न आधी केला जाऊ शकतो किंवा पूर्ण केला जाऊ शकतो.

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

8.3 व्यवहार प्रेमींसाठी प्रगत साधने

मी फक्त सामान्य व्याख्या देईन, कारण हा विषय वेगळ्या मोठ्या लेखासाठी पात्र आहे.

दोन-फेज कमिट (2pc) . 2pc चे दोन टप्पे आहेत: तयारीचा टप्पा आणि कमिट फेज. तयारीच्या टप्प्यात, सर्व मायक्रोसर्व्हिसेसना काही डेटा बदलांसाठी तयार करण्यास सांगितले जाईल जे अणू पद्धतीने केले जाऊ शकतात. एकदा ते सर्व तयार झाल्यानंतर, कमिट फेज वास्तविक बदल करेल. प्रक्रियेचे समन्वय करण्यासाठी, एक जागतिक समन्वयक आवश्यक आहे, जो आवश्यक वस्तू लॉक करतो - म्हणजेच, समन्वयक त्यांना अनलॉक करेपर्यंत ते बदलांसाठी अगम्य बनतात. जर एखादी विशिष्ट मायक्रोसेवा बदलांसाठी तयार नसेल (उदाहरणार्थ, प्रतिसाद देत नाही), तर समन्वयक व्यवहार रद्द करेल आणि रोलबॅक प्रक्रिया सुरू करेल.

हा प्रोटोकॉल चांगला का आहे? हे अणुत्व प्रदान करते. याव्यतिरिक्त, ते लिहिताना आणि वाचताना अलगावची हमी देते. याचा अर्थ असा की जोपर्यंत समन्वयक बदल करत नाही तोपर्यंत एका व्यवहारातील बदल इतरांना दिसत नाहीत. परंतु या गुणधर्मांचा एक तोटा देखील आहे: हा प्रोटोकॉल सिंक्रोनस (ब्लॉकिंग) असल्याने, ते सिस्टमला गती कमी करते (आरपीसी कॉल स्वतःच खूप मंद आहे हे तथ्य असूनही). आणि पुन्हा, परस्पर अवरोधित होण्याचा धोका आहे.

गाथा _ या पॅटर्नमध्ये, सर्व संबंधित मायक्रो सर्व्हिसेसमध्ये असिंक्रोनस स्थानिक व्यवहारांद्वारे वितरित व्यवहार अंमलात आणला जातो. मायक्रोसर्व्हिसेस इव्हेंट बसद्वारे एकमेकांशी संवाद साधतात. कोणतीही मायक्रोसर्व्हिसेस त्याचा स्थानिक व्यवहार पूर्ण करण्यात अयशस्वी झाल्यास, इतर मायक्रोसर्व्हिसेस बदल परत करण्यासाठी नुकसानभरपाईचे व्यवहार करतील.

सागाचा फायदा असा आहे की कोणतीही वस्तू अवरोधित केलेली नाही. पण, अर्थातच तोटे आहेत.

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

या दोन तंत्रांच्या वर्णनावरून आपल्याला काय दिसते? वस्तुस्थिती ही आहे की वितरित प्रणालींमध्ये, अणू आणि अलगावची जबाबदारी अनुप्रयोगावर आहे. ACID हमी प्रदान न करणारे डेटाबेस वापरतानाही असेच घडते. म्हणजेच, विवाद निराकरण, रोलबॅक, कमिट आणि जागा मोकळी करणे यासारख्या गोष्टी विकसकाच्या खांद्यावर येतात.

8.4 मला ACID हमींची आवश्यकता असते तेव्हा मला कसे कळेल?

जेव्हा वापरकर्त्यांचा विशिष्ट संच किंवा प्रक्रिया एकाच वेळी समान डेटावर कार्य करतील अशी उच्च संभाव्यता असते .

सामान्यपणाबद्दल क्षमस्व, परंतु एक सामान्य उदाहरण म्हणजे आर्थिक व्यवहार.

कोणत्या क्रमाने व्यवहार केले जातात हे महत्त्वाचे असते.

कल्पना करा की तुमची कंपनी FunnyYellowChat मेसेंजरवरून FunnyRedChat मेसेंजरवर स्विच करणार आहे, कारण FunnyRedChat तुम्हाला gif पाठवण्याची परवानगी देते, परंतु FunnyYellowChat करू शकत नाही. परंतु तुम्ही फक्त मेसेंजर बदलत नाही आहात - तुम्ही तुमच्या कंपनीचा पत्रव्यवहार एका मेसेंजरवरून दुसऱ्याकडे स्थलांतरित करत आहात. तुम्ही असे करता कारण तुमचे प्रोग्रामर कुठेतरी मध्यवर्ती ठिकाणी कार्यक्रम आणि प्रक्रियांचे दस्तऐवजीकरण करण्यात खूप आळशी होते आणि त्याऐवजी त्यांनी मेसेंजरमध्ये सर्व काही वेगवेगळ्या चॅनेलमध्ये प्रकाशित केले. होय, आणि तुमच्या विक्री करणार्‍यांनी त्याच ठिकाणी वाटाघाटी आणि करारांचे तपशील प्रकाशित केले. थोडक्यात, तुमच्या कंपनीचे संपूर्ण आयुष्य तेथे आहे, आणि दस्तऐवजीकरणासाठी सर्व गोष्टी एका सेवेकडे हस्तांतरित करण्यासाठी कोणाकडेही वेळ नसल्यामुळे, आणि इन्स्टंट मेसेंजरचा शोध चांगला कार्य करतो, तुम्ही कचरा साफ करण्याऐवजी फक्त सर्व कॉपी करण्याचा निर्णय घेतला. नवीन ठिकाणी संदेश. संदेशांचा क्रम महत्त्वाचा आहे

तसे, मेसेंजरमधील पत्रव्यवहारासाठी, ऑर्डर सामान्यतः महत्त्वाची असते, परंतु जेव्हा दोन लोक एकाच वेळी एकाच चॅटमध्ये काहीतरी लिहितात, तेव्हा सर्वसाधारणपणे कोणाचा संदेश प्रथम दिसेल हे इतके महत्त्वाचे नसते. त्यामुळे, या विशिष्ट परिस्थितीसाठी, ACID ची गरज भासणार नाही.

दुसरे संभाव्य उदाहरण म्हणजे बायोइन्फॉर्मेटिक्स. मला हे अजिबात समजत नाही, परंतु मी असे गृहीत धरतो की मानवी जीनोमचा उलगडा करताना क्रम महत्त्वाचा आहे. तथापि, मी ऐकले आहे की बायोइन्फॉरमॅटिशियन सामान्यतः प्रत्येक गोष्टीसाठी त्यांची काही साधने वापरतात - कदाचित त्यांचे स्वतःचे डेटाबेस आहेत.

जेव्हा तुम्ही वापरकर्ता देऊ शकत नाही किंवा जुना डेटा प्रक्रिया करू शकत नाही.

आणि पुन्हा - आर्थिक व्यवहार. खरे सांगायचे तर, मी इतर कोणत्याही उदाहरणाचा विचार करू शकत नाही.

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

8.5 मला ACID ची कधी गरज नसते?

जेव्हा वापरकर्ते त्यांचा काही खाजगी डेटा अपडेट करतात.

उदाहरणार्थ, वापरकर्ता वेब पृष्ठावर टिप्पण्या किंवा चिकट नोट्स सोडतो. किंवा कोणत्याही सेवा प्रदात्यासह वैयक्तिक खात्यातील वैयक्तिक डेटा संपादित करते.

जेव्हा वापरकर्ते डेटा अद्ययावत करत नाहीत, परंतु केवळ नवीन (जोड) सह पूरक करतात.

उदाहरणार्थ, धावणारा अनुप्रयोग जो तुमच्या धावांवर डेटा वाचवतो: तुम्ही किती धावले, कोणत्या वेळेसाठी, मार्ग इ. प्रत्येक नवीन रन नवीन डेटा असतो आणि जुने अजिबात संपादित केले जात नाहीत. कदाचित, डेटावर आधारित, तुम्हाला विश्लेषणे मिळतील - आणि फक्त NoSQL डेटाबेस या परिस्थितीसाठी चांगले आहेत.

जेव्हा व्यवसाय तर्कशास्त्र विशिष्ट ऑर्डरची आवश्यकता ठरवत नाही ज्यामध्ये व्यवहार केले जातात.

कदाचित, पुढील थेट प्रसारणादरम्यान नवीन सामग्रीच्या निर्मितीसाठी देणग्या गोळा करणार्‍या यूट्यूब ब्लॉगरसाठी, कोणी, केव्हा आणि कोणत्या क्रमाने त्याला पैसे फेकले हे इतके महत्त्वाचे नाही.

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

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

जर तुम्ही अनेक स्त्रोतांकडून डेटा एकत्रित करत असाल आणि उच्च वारंवारतेने अद्यतनित केलेला डेटा - उदाहरणार्थ, शहरातील पार्किंगच्या जागेचा डेटा जो किमान दर 5 मिनिटांनी बदलतो, तर सिद्धांततः ही मोठी समस्या होणार नाही. जर एखाद्या वेळी पार्किंग लॉटपैकी एकाचा व्यवहार होणार नसेल तर तुमच्यासाठी. जरी, अर्थातच, आपण या डेटासह नक्की काय करू इच्छिता यावर अवलंबून आहे.