ஒரு பயன்பாட்டில் ACID ஐ எவ்வாறு செயல்படுத்துவது: பயிற்சி

8.1 பரிவர்த்தனை ஐடிகள்

இது 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)

> ஒரு வேளை, நான் சொல்வேன்: \@மீண்டும் முயற்சி(...) என்பது "அலங்கரிப்பான்" எனப்படும் சிறப்பு பைதான் தொடரியல். இது ஒரு மறுமுயற்சி(...) செயல்பாடாகும், இது மற்றொரு செயல்பாட்டைச் சுற்றி, அதைச் செயல்படுத்துவதற்கு முன் அல்லது பின் ஏதாவது செய்கிறது.

நாம் பார்க்கிறபடி, மறு முயற்சிகள் ஆக்கப்பூர்வமாக வடிவமைக்கப்படலாம்:

• நீங்கள் முயற்சிகளை நேரம் (10 வினாடிகள்) அல்லது முயற்சிகளின் எண்ணிக்கை (5) மூலம் கட்டுப்படுத்தலாம்.
• அதிவேகமாக இருக்கலாம் (அதாவது, 2 ** சில அதிகரிக்கும் எண் n ). அல்லது வேறு எப்படியோ (உதாரணமாக, நிலையானது) தனி முயற்சிகளுக்கு இடையில் நேரத்தை அதிகரிக்க. அதிவேக மாறுபாடு "நெரிசல் சரிவு" என்று அழைக்கப்படுகிறது.
• சில வகையான பிழைகளுக்கு மட்டுமே நீங்கள் மீண்டும் முயற்சிக்க முடியும் (IOError).
• மறுமுயற்சி முயற்சிகள் பதிவில் சில சிறப்பு உள்ளீடுகளால் முன்னதாகவோ அல்லது முடிக்கப்படவோ முடியும்.

இப்போது நாங்கள் இளம் போர் பயிற்சியை முடித்துவிட்டோம் மற்றும் பயன்பாட்டுப் பக்கத்தில் பரிவர்த்தனைகளுடன் வேலை செய்ய வேண்டிய அடிப்படை கட்டுமானத் தொகுதிகளை அறிந்துள்ளோம், விநியோகிக்கப்பட்ட அமைப்புகளில் பரிவர்த்தனைகளைச் செயல்படுத்த அனுமதிக்கும் இரண்டு முறைகளைப் பற்றி அறிந்து கொள்வோம்.

8.3 பரிவர்த்தனை பிரியர்களுக்கான மேம்பட்ட கருவிகள்

இந்த தலைப்பு ஒரு தனி பெரிய கட்டுரைக்கு தகுதியானது என்பதால் நான் மிகவும் பொதுவான வரையறைகளை மட்டுமே தருகிறேன்.

இரண்டு-கட்ட உறுதி (2pc) . 2pc இரண்டு கட்டங்களைக் கொண்டுள்ளது: ஒரு தயாரிப்பு கட்டம் மற்றும் ஒரு உறுதி கட்டம். தயார் நிலையில், அனைத்து மைக்ரோ சர்வீஸும் அணு ரீதியாகச் செய்யக்கூடிய சில தரவு மாற்றங்களுக்குத் தயாராகும்படி கேட்கப்படும். அவை அனைத்தும் தயாரானதும், உறுதி கட்டம் உண்மையான மாற்றங்களைச் செய்யும். செயல்முறையை ஒருங்கிணைக்க, ஒரு உலகளாவிய ஒருங்கிணைப்பாளர் தேவை, இது தேவையான பொருட்களைப் பூட்டுகிறது - அதாவது, ஒருங்கிணைப்பாளர் அவற்றைத் திறக்கும் வரை அவை மாற்றங்களுக்கு அணுக முடியாததாகிவிடும். குறிப்பிட்ட மைக்ரோ சர்வீஸ் மாற்றங்களுக்குத் தயாராக இல்லை என்றால் (உதாரணமாக, பதிலளிக்கவில்லை), ஒருங்கிணைப்பாளர் பரிவர்த்தனையை நிறுத்திவிட்டு திரும்பப்பெறும் செயல்முறையைத் தொடங்குவார்.

இந்த நெறிமுறை ஏன் நல்லது? இது அணுசக்தியை வழங்குகிறது. கூடுதலாக, எழுதும் மற்றும் படிக்கும் போது இது தனிமைப்படுத்தப்படுவதற்கு உத்தரவாதம் அளிக்கிறது. ஒருங்கிணைப்பாளர் மாற்றங்களைச் செய்யும் வரை, ஒரு பரிவர்த்தனைக்கான மாற்றங்கள் மற்றவர்களுக்குத் தெரியாது. ஆனால் இந்த பண்புகளும் ஒரு குறைபாட்டைக் கொண்டுள்ளன: இந்த நெறிமுறை ஒத்திசைவானது (தடுத்தல்), இது கணினியை மெதுவாக்குகிறது (RPC அழைப்பு மிகவும் மெதுவாக இருந்தாலும்). மீண்டும், பரஸ்பரம் தடுக்கும் ஆபத்து உள்ளது.

சாகா . இந்த முறையில், விநியோகிக்கப்பட்ட பரிவர்த்தனையானது அனைத்து தொடர்புடைய மைக்ரோ சர்வீஸ்களிலும் ஒத்திசைவற்ற உள்ளூர் பரிவர்த்தனைகளால் செயல்படுத்தப்படுகிறது. ஒரு நிகழ்வு பஸ் மூலம் மைக்ரோ சர்வீஸ்கள் ஒருவருக்கொருவர் தொடர்பு கொள்கின்றன. எந்தவொரு மைக்ரோ சர்வீஸும் அதன் உள்ளூர் பரிவர்த்தனையை முடிக்கத் தவறினால், மாற்றங்களைத் திரும்பப்பெற மற்ற மைக்ரோ சர்வீஸ்கள் ஈடுசெய்யும் பரிவர்த்தனைகளைச் செய்யும்.

சாகாவின் நன்மை என்னவென்றால், எந்த பொருட்களும் தடுக்கப்படவில்லை. ஆனால், நிச்சயமாக, குறைபாடுகள் உள்ளன.

சாகா பிழைத்திருத்தம் செய்வது கடினம், குறிப்பாக பல மைக்ரோ சர்வீஸ்கள் சம்பந்தப்பட்டிருக்கும் போது. சாகா மாதிரியின் மற்றொரு தீமை என்னவென்றால், அதில் படிக்கும் தனிமை இல்லை. அதாவது, ACID இல் குறிப்பிடப்பட்டுள்ள பண்புகள் நமக்கு முக்கியமானதாக இருந்தால், சாகா நமக்கு மிகவும் பொருத்தமானது அல்ல.

இந்த இரண்டு நுட்பங்களின் விளக்கத்திலிருந்து நாம் என்ன பார்க்கிறோம்? விநியோகிக்கப்பட்ட அமைப்புகளில், அணு மற்றும் தனிமைப்படுத்துதலுக்கான பொறுப்பு பயன்பாட்டுடன் உள்ளது. ACID உத்தரவாதங்களை வழங்காத தரவுத்தளங்களைப் பயன்படுத்தும் போது இதுவே நடக்கும். அதாவது, மோதலைத் தீர்ப்பது, திரும்பப் பெறுதல், உறுதி செய்தல் மற்றும் இடத்தை விடுவித்தல் போன்ற விஷயங்கள் டெவலப்பரின் தோள்களில் விழுகின்றன.

8.4 எனக்கு ACID உத்தரவாதம் தேவைப்படும்போது எனக்கு எப்படித் தெரியும்?

ஒரு குறிப்பிட்ட பயனர்கள் அல்லது செயல்முறைகள் ஒரே நேரத்தில் ஒரே தரவில் வேலை செய்யும் அதிக நிகழ்தகவு இருக்கும் போது .

சாதாரணமானதற்கு மன்னிக்கவும், ஆனால் ஒரு பொதுவான உதாரணம் நிதி பரிவர்த்தனைகள்.

பரிவர்த்தனைகள் செயல்படுத்தப்படும் வரிசை முக்கியமானது.

உங்கள் நிறுவனம் FunnyYellowChat மெசஞ்சரில் இருந்து FunnyRedChat மெசஞ்சருக்கு மாற உள்ளது என்று கற்பனை செய்து பாருங்கள், ஏனெனில் FunnyRedChat உங்களை gifகளை அனுப்ப அனுமதிக்கிறது, ஆனால் FunnyYellowChat முடியாது. ஆனால் நீங்கள் தூதரை மட்டும் மாற்றவில்லை - உங்கள் நிறுவனத்தின் கடிதப் பரிமாற்றத்தை ஒரு தூதரிடமிருந்து மற்றொரு தூதருக்கு மாற்றுகிறீர்கள். உங்கள் புரோகிராமர்கள் நிரல்கள் மற்றும் செயல்முறைகளை எங்காவது மையமாக ஆவணப்படுத்த மிகவும் சோம்பேறியாக இருந்ததால் நீங்கள் இதைச் செய்கிறீர்கள், அதற்கு பதிலாக அவர்கள் எல்லாவற்றையும் வெவ்வேறு சேனல்களில் மெசஞ்சரில் வெளியிட்டனர். ஆம், உங்கள் விற்பனையாளர்கள் அதே இடத்தில் பேச்சுவார்த்தைகள் மற்றும் ஒப்பந்தங்களின் விவரங்களை வெளியிட்டனர். சுருக்கமாக, உங்கள் நிறுவனத்தின் முழு வாழ்க்கையும் உள்ளது, மேலும் ஆவணப்படுத்தலுக்கான சேவைக்கு முழு விஷயத்தையும் மாற்ற யாருக்கும் நேரம் இல்லை என்பதால், உடனடி தூதர்களைத் தேடுவது நன்றாக வேலை செய்கிறது, இடிபாடுகளை அகற்றுவதற்குப் பதிலாக எல்லாவற்றையும் நகலெடுக்க முடிவு செய்தீர்கள். ஒரு புதிய இடத்திற்கு செய்திகள். செய்திகளின் வரிசை முக்கியமானது

மூலம், ஒரு தூதரில் கடிதப் பரிமாற்றத்திற்கு, ஆர்டர் பொதுவாக முக்கியமானது, ஆனால் ஒரே நேரத்தில் இரண்டு பேர் ஒரே அரட்டையில் எதையாவது எழுதினால், பொதுவாக யாருடைய செய்தி முதலில் தோன்றும் என்பது அவ்வளவு முக்கியமல்ல. எனவே, இந்த குறிப்பிட்ட சூழ்நிலையில், ACID தேவைப்படாது.

மற்றொரு சாத்தியமான உதாரணம் உயிர் தகவலியல். இது எனக்குப் புரியவில்லை, ஆனால் மனித மரபணுவைப் புரிந்துகொள்ளும்போது ஒழுங்கு முக்கியமானது என்று நான் கருதுகிறேன். இருப்பினும், பயோ-இன்ஃபர்மேட்டிஷியன்கள் பொதுவாக எல்லாவற்றுக்கும் தங்கள் கருவிகளில் சிலவற்றைப் பயன்படுத்துகிறார்கள் என்று கேள்விப்பட்டேன் - ஒருவேளை அவர்கள் தங்கள் சொந்த தரவுத்தளங்களைக் கொண்டிருக்கலாம்.

நீங்கள் பயனருக்கு வழங்க முடியாதபோது அல்லது பழைய தரவை செயலாக்க முடியாது.

மீண்டும் - நிதி பரிவர்த்தனைகள். உண்மையைச் சொல்வதானால், வேறு எந்த உதாரணத்தையும் என்னால் நினைக்க முடியவில்லை.

நிலுவையில் உள்ள பரிவர்த்தனைகள் குறிப்பிடத்தக்க செலவுகளுடன் தொடர்புடையதாக இருக்கும்போது. ஒரு மருத்துவர் மற்றும் செவிலியர் இருவரும் ஒரே நேரத்தில் நோயாளியின் பதிவைப் புதுப்பித்து, ஒருவருக்கொருவர் மாற்றங்களை அழிக்கும்போது ஏற்படும் சிக்கல்களை கற்பனை செய்து பாருங்கள், ஏனெனில் தரவுத்தளமானது பரிவர்த்தனைகளை தனிமைப்படுத்த முடியாது. ஹெல்த்கேர் சிஸ்டம் என்பது நிதி தவிர, மற்றொரு பகுதி, இதில் ACID உத்தரவாதங்கள் முக்கியமானதாக இருக்கும்.

8.5 எனக்கு எப்போது ACID தேவையில்லை?

பயனர்கள் தங்கள் தனிப்பட்ட தரவுகளில் சிலவற்றை மட்டும் புதுப்பிக்கும்போது.

எடுத்துக்காட்டாக, ஒரு பயனர் வலைப்பக்கத்தில் கருத்துகள் அல்லது ஒட்டும் குறிப்புகளை விடுகிறார். அல்லது ஏதேனும் சேவை வழங்குனருடன் தனிப்பட்ட கணக்கில் தனிப்பட்ட தரவைத் திருத்துகிறது.

பயனர்கள் தரவைப் புதுப்பிக்காமல், புதியவற்றுடன் மட்டுமே துணைபுரியும்போது (சேர்க்கவும்).

எடுத்துக்காட்டாக, உங்கள் ரன்களில் தரவைச் சேமிக்கும் இயங்கும் பயன்பாடு: நீங்கள் எவ்வளவு ஓடியுள்ளீர்கள், எந்த நேரத்திற்கு, பாதை போன்றவை. ஒவ்வொரு புதிய ஓட்டமும் புதிய தரவு, பழையவை திருத்தப்படவே இல்லை. ஒருவேளை, தரவின் அடிப்படையில், நீங்கள் பகுப்பாய்வுகளைப் பெறுவீர்கள் - மேலும் இந்த சூழ்நிலையில் NoSQL தரவுத்தளங்கள் மட்டுமே நல்லது.

பரிவர்த்தனைகள் செய்யப்படும் ஒரு குறிப்பிட்ட வரிசையின் தேவையை வணிக தர்க்கம் தீர்மானிக்காதபோது.

அநேகமாக, அடுத்த நேரடி ஒளிபரப்பின் போது புதிய பொருட்களை தயாரிப்பதற்காக நன்கொடைகளை சேகரிக்கும் Youtube பதிவருக்கு, யார், எப்போது, ​​​​எந்த வரிசையில் பணத்தை வீசினார்கள் என்பது அவ்வளவு முக்கியமல்ல.

பயனர்கள் ஒரே இணையப் பக்கம் அல்லது பயன்பாட்டு சாளரத்தில் பல வினாடிகள் அல்லது நிமிடங்கள் கூட இருக்கும் போது, ​​அதனால் அவர்கள் எப்படியாவது பழைய தரவைப் பார்ப்பார்கள்.

கோட்பாட்டளவில், இவை ஏதேனும் ஆன்லைன் செய்தி ஊடகம் அல்லது அதே Youtube. அல்லது "ஹப்ர்". முழுமையடையாத பரிவர்த்தனைகளை கணினியில் தற்காலிகமாக சேமிக்க முடியும் என்பது உங்களுக்கு முக்கியமில்லாதபோது, ​​​​அவற்றை எந்த சேதமும் இல்லாமல் நீங்கள் புறக்கணிக்கலாம்.

நீங்கள் பல மூலங்களிலிருந்து தரவை ஒருங்கிணைத்து, அதிக அதிர்வெண்ணில் புதுப்பிக்கப்பட்ட தரவு - எடுத்துக்காட்டாக, குறைந்தது 5 நிமிடங்களுக்கு ஒரு நகரத்தில் வாகன நிறுத்துமிடங்களின் ஆக்கிரமிப்பு பற்றிய தரவு, கோட்பாட்டில் அது பெரிய பிரச்சனையாக இருக்காது. சில சமயங்களில் வாகன நிறுத்துமிடங்களில் ஒன்றின் பரிவர்த்தனை நடக்காது. இருப்பினும், நிச்சயமாக, இந்தத் தரவை நீங்கள் சரியாக என்ன செய்ய விரும்புகிறீர்கள் என்பதைப் பொறுத்தது.