🥇மேலும் டெவலப்பர்கள் தரவுத்தளங்களைப் பற்றி தெரிந்து கொள்ள வேண்டும்

குறிப்பு. மொழிபெயர்: ஜானா டோகன் கூகுளில் அனுபவம் வாய்ந்த பொறியாளர் ஆவார், அவர் தற்போது கோவில் எழுதப்பட்ட நிறுவனத்தின் தயாரிப்பு சேவைகளை கவனிக்கும் பணியில் ஈடுபட்டுள்ளார். ஆங்கிலம் பேசும் பார்வையாளர்களிடையே பெரும் புகழைப் பெற்ற இந்தக் கட்டுரையில், பெரிய/தேவையான பயன்பாடுகளை உருவாக்குபவர்கள் கருத்தில் கொள்ள பயனுள்ள DBMSகள் (மற்றும் சில நேரங்களில் விநியோகிக்கப்பட்ட அமைப்புகள்) தொடர்பான முக்கியமான தொழில்நுட்ப விவரங்களை 17 புள்ளிகளில் சேகரித்தார்.

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

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

இம்மானுவேல் ஓடேக், ரெயின் ஹென்ரிச்ஸ் மற்றும் பிறருக்கு இந்தக் கட்டுரையின் முந்தைய பதிப்பைப் பற்றிய கருத்துக்கு நன்றி தெரிவிக்க விரும்புகிறேன்.

99,999% நேரம் நெட்வொர்க் சிக்கல்களை ஏற்படுத்தவில்லை என்றால் நீங்கள் அதிர்ஷ்டசாலி.

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

ஸ்பேனருக்கு 99,999% கிடைக்கும் விகிதத்துடன் (Google இன் உலகளாவிய விநியோக தரவுத்தளம்), கூகுள் கூறுகிறது 7,6% சிக்கல்கள் பிணையத்துடன் தொடர்புடையவை. அதே நேரத்தில், நிறுவனம் அதன் சிறப்பு நெட்வொர்க்கை அதிக கிடைக்கும் "முக்கிய தூண்" என்று அழைக்கிறது. படிப்பு பெய்லிஸ் மற்றும் கிங்ஸ்பரி2014 இல் நடத்தப்பட்ட, "விநியோகிக்கப்பட்ட கணினி பற்றிய தவறான எண்ணங்கள்", இது பீட்டர் டாய்ச் 1994 இல் உருவாக்கியது. நெட்வொர்க் உண்மையில் நம்பகமானதா?

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

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

ACID என்பது பல்வேறு விஷயங்களைக் குறிக்கிறது

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

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

ஒவ்வொரு DBMS யும் ACID இணக்கமாக இல்லை; அதே நேரத்தில், ACID ஐ ஆதரிக்கும் தரவுத்தள செயலாக்கங்கள் தேவைகளின் தொகுப்பை வித்தியாசமாக புரிந்து கொள்கின்றன. ACID செயலாக்கங்கள் சீரற்றதாக இருப்பதற்கான காரணங்களில் ஒன்று, ACID தேவைகளை செயல்படுத்துவதற்கு மேற்கொள்ள வேண்டிய பல பரிமாற்றங்கள் காரணமாகும். படைப்பாளிகள் தங்கள் தரவுத்தளங்களை ACID-இணக்கமானதாகக் காட்டலாம், ஆனால் எட்ஜ் கேஸ்களின் விளக்கம் வியத்தகு அளவில் மாறுபடலாம், "சாத்தியமற்ற" நிகழ்வுகளைக் கையாளும் பொறிமுறையைப் போலவே. குறைந்த பட்சம், டெவலப்பர்கள் தங்கள் சிறப்பு நடத்தை மற்றும் வடிவமைப்பு வர்த்தகம் பற்றிய சரியான புரிதலைப் பெற அடிப்படை செயலாக்கங்களின் நுணுக்கங்களைப் பற்றிய உயர்-நிலை புரிதலைப் பெறலாம்.

MongoDB ACID தேவைகளுக்கு இணங்குகிறதா என்பது பற்றிய விவாதம் பதிப்பு 4 வெளியான பிறகும் தொடர்கிறது. MongoDB நீண்ட காலமாக ஆதரிக்கப்படவில்லை மரம் வெட்டுதல், முன்னிருப்பாக தரவு ஒவ்வொரு 60 வினாடிகளுக்கும் ஒரு முறைக்கு மேல் வட்டில் செலுத்தப்படவில்லை. பின்வரும் சூழ்நிலையை கற்பனை செய்து பாருங்கள்: ஒரு பயன்பாடு இரண்டு எழுதுதல்களை இடுகையிடுகிறது (w1 மற்றும் w2). மோங்கோடிபி w1ஐ வெற்றிகரமாகச் சேமிக்கிறது, ஆனால் வன்பொருள் செயலிழப்பு காரணமாக w2 இழக்கப்பட்டது.

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

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

ஒவ்வொரு தரவுத்தளத்திற்கும் அதன் சொந்த நிலைத்தன்மை மற்றும் தனிமைப்படுத்தும் வழிமுறைகள் உள்ளன

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

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

தற்போதுள்ள ஒத்திசைவு மாதிரிகள் மற்றும் அவற்றுக்கிடையேயான உறவுகளின் மதிப்பாய்வு

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

SQL தரநிலை பின்வரும் தனிமை நிலைகளைக் குறிப்பிடுகிறது:

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

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

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

வெவ்வேறு DBMS களுக்கு வெவ்வேறு தனிமை நிலைகளில் ஒத்திசைவு முரண்பாடுகளின் மதிப்பாய்வு

மார்ட்டின் க்ளெப்மேன் தனது திட்டத்தில் ஹெர்மிட்டேஜ் வெவ்வேறு தனிமை நிலைகளை ஒப்பிடுகிறது, ஒத்திசைவு முரண்பாடுகளைப் பற்றி பேசுகிறது மற்றும் தரவுத்தளமானது ஒரு குறிப்பிட்ட தனிமைப்படுத்தல் நிலைக்கு இணங்க முடியுமா. க்ளெப்மேனின் ஆராய்ச்சி தரவுத்தள உருவாக்குநர்கள் தனிமைப்படுத்தப்பட்ட நிலைகளைப் பற்றி எப்படி வித்தியாசமாக நினைக்கிறார்கள் என்பதைக் காட்டுகிறது.

வழக்கமான ஒன்றைப் பராமரிப்பது கடினமாக இருக்கும்போது நம்பிக்கையான தடுப்பு மீட்புக்கு வருகிறது.

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

அழுக்கு வாசிப்பு மற்றும் தரவு இழப்பு தவிர மற்ற முரண்பாடுகள் உள்ளன

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

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

எடுத்துக்காட்டாக, ஒரு ஆபரேட்டர் எல்லா நேரங்களிலும் அழைப்பில் இருக்க வேண்டிய கண்காணிப்பு பயன்பாட்டைக் கருத்தில் கொள்வோம்:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

என்ன செய்வது என்பதில் தரவுத்தளமும் பயனரும் எப்போதும் உடன்படுவதில்லை

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

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

முதல் பார்வையில், கீழே உள்ள நிரலில், T1 மற்றும் T2 வரிசையாக அழைக்கப்படுகின்றன, ஆனால் இந்த செயல்பாடுகள் தடுக்கப்படாமல் இருந்தால், உடனடியாக படிவத்தில் முடிவைத் தரவும். வாக்குறுதி, பின்னர் அழைப்புகளின் வரிசை தரவுத்தளத்தில் நுழைந்த தருணங்களால் தீர்மானிக்கப்படும்:

முடிவு1 = T1() // உண்மையான முடிவுகள் வாக்குறுதிகள்
முடிவு2 = T2()

அணுசக்தி தேவை என்றால் (அதாவது, அனைத்து செயல்பாடுகளும் முடிக்கப்பட வேண்டும் அல்லது நிறுத்தப்பட வேண்டும்) மற்றும் வரிசை முக்கியமானதாக இருந்தால், T1 மற்றும் T2 செயல்பாடுகள் ஒரே பரிவர்த்தனைக்குள் செய்யப்பட வேண்டும்.

பயன்பாட்டு நிலை ஷார்டிங்கை பயன்பாட்டிற்கு வெளியே நகர்த்தலாம்

ஷார்டிங் என்பது தரவுத்தளத்தை கிடைமட்டமாக பிரிக்கும் ஒரு முறையாகும். சில தரவுத்தளங்கள் தானாக தரவை கிடைமட்டமாக பிரிக்கலாம், மற்றவை முடியாது, அல்லது நன்றாக இல்லை. தரவுக் கட்டமைப்பாளர்கள்/டெவலப்பர்கள், தரவு எவ்வாறு அணுகப்படும் என்பதைத் துல்லியமாகக் கணிக்க முடிந்தால், அவர்கள் இந்தப் பணியை தரவுத்தளத்திற்கு வழங்குவதற்குப் பதிலாக பயனர் இடத்தில் கிடைமட்ட பகிர்வுகளை உருவாக்கலாம். இந்த செயல்முறை "பயன்பாட்டு நிலை ஷார்டிங்" என்று அழைக்கப்படுகிறது. (விண்ணப்ப-நிலை பகிர்வு).

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

பயன்பாட்டு சேவையகங்கள் பகிர்வு சேவையிலிருந்து பிரிக்கப்பட்ட ஒரு கட்டமைப்பின் எடுத்துக்காட்டு

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

தன்னியக்க அதிகரிப்பு ஆபத்தானது

முதன்மை விசைகளை உருவாக்க AUTOINCREMENT ஒரு பொதுவான வழி. தரவுத்தளங்கள் ஐடி ஜெனரேட்டர்களாகப் பயன்படுத்தப்படும் போது அடிக்கடி வழக்குகள் உள்ளன, மேலும் தரவுத்தளத்தில் அடையாளங்காட்டிகளை உருவாக்க வடிவமைக்கப்பட்ட அட்டவணைகள் உள்ளன. தானியங்கு அதிகரிப்பைப் பயன்படுத்தி முதன்மை விசைகளை உருவாக்குவது சிறந்ததல்ல என்பதற்கு பல காரணங்கள் உள்ளன:

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

ஒரு அணுகுமுறையைத் தீர்மானிப்பதற்கு முன், தானாக அதிகரிக்கும் ஐடிகள் மற்றும் UUIDகள் அட்டவணைப்படுத்துதல், பகிர்வு செய்தல் மற்றும் பகிர்தல் ஆகியவற்றில் ஏற்படும் தாக்கத்தைக் கவனியுங்கள்.

பழைய தரவு பயனுள்ளதாக இருக்கும் மற்றும் பூட்டுதல் தேவையில்லை

மல்டிவர்ஷன் கன்கரன்சி கண்ட்ரோல் (எம்விசிசி) மேலே சுருக்கமாக விவாதிக்கப்பட்ட பல நிலைத்தன்மை தேவைகளை செயல்படுத்துகிறது. சில தரவுத்தளங்கள் (உதாரணமாக, Postgres, Spanner) தரவுத்தளத்தின் பழைய பதிப்புகளான ஸ்னாப்ஷாட்களுடன் பரிவர்த்தனைகளை "ஊட்ட" MVCC ஐப் பயன்படுத்துகின்றன. ஸ்னாப்ஷாட் பரிவர்த்தனைகள் சீரான தன்மையை உறுதிப்படுத்த வரிசைப்படுத்தப்படலாம். பழைய ஸ்னாப்ஷாட்டில் இருந்து படிக்கும் போது, காலாவதியான தரவு படிக்கப்படுகிறது.

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

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

சமீபத்திய பதிப்பு பசிபிக் பெருங்கடலின் மறுபுறத்தில் கிடைத்தாலும், பயன்பாட்டு சேவையகம் 5 வினாடிகள் காலாவதியான உள்ளூர் பிரதியிலிருந்து தரவைப் படிக்கும்

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

எந்த நேர ஆதாரங்களும் சிதைவுக்கு உட்பட்டவை

கணினி அறிவியலில் சிறந்த ரகசியம் என்னவென்றால், எல்லா நேர APIகளும் பொய்யாகின்றன. உண்மையில், எங்கள் இயந்திரங்களுக்கு சரியான தற்போதைய நேரம் தெரியாது. கணினிகளில் குவார்ட்ஸ் படிகங்கள் உள்ளன, அவை அதிர்வுகளை உருவாக்குகின்றன, அவை நேரத்தை வைத்திருக்கப் பயன்படுகின்றன. இருப்பினும், அவை போதுமான அளவு துல்லியமாக இல்லை மற்றும் சரியான நேரத்திற்கு முன்னால்/பின்தங்கியிருக்கலாம். ஷிப்ட் ஒரு நாளைக்கு 20 வினாடிகளை எட்டும். எனவே, எங்கள் கணினிகளில் உள்ள நேரம் அவ்வப்போது நெட்வொர்க்குடன் ஒத்திசைக்கப்பட வேண்டும்.

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

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

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

Google TrueTime முற்றிலும் மாறுபட்ட அணுகுமுறையை எடுக்கிறது. இந்த திசையில் கூகிளின் முன்னேற்றம் அணு மற்றும் ஜிபிஎஸ் கடிகாரங்களுக்கு சாதாரணமான மாற்றத்தால் விளக்கப்படுகிறது என்று பெரும்பாலான மக்கள் நம்புகிறார்கள், ஆனால் இது பெரிய படத்தின் ஒரு பகுதி மட்டுமே. TrueTime எவ்வாறு செயல்படுகிறது என்பது இங்கே:

TrueTime இரண்டு வெவ்வேறு ஆதாரங்களைப் பயன்படுத்துகிறது: GPS மற்றும் அணு கடிகாரங்கள். இந்த கடிகாரங்களில் தொடர்பு இல்லாத தோல்வி முறைகள் உள்ளன. [விவரங்களுக்கு பக்கம் 5 ஐப் பார்க்கவும் இங்கே - தோராயமாக மொழிபெயர்ப்பு.), எனவே அவர்களின் கூட்டு பயன்பாடு நம்பகத்தன்மையை அதிகரிக்கிறது.
TrueTime இல் அசாதாரண API உள்ளது. இது அளவீட்டு பிழை மற்றும் நிச்சயமற்ற தன்மையுடன் ஒரு இடைவெளியாக நேரத்தை வழங்குகிறது. நேரத்தின் உண்மையான தருணம் இடைவெளியின் மேல் மற்றும் கீழ் எல்லைகளுக்கு இடையில் எங்கோ உள்ளது. கூகிளின் விநியோகிக்கப்பட்ட தரவுத்தளமான ஸ்பேனர், தற்போதைய நேரம் வரம்பிற்கு அப்பாற்பட்டது என்று கூறுவது பாதுகாப்பானது வரை காத்திருக்கிறது. இந்த முறை கணினியில் சில தாமதங்களை அறிமுகப்படுத்துகிறது, குறிப்பாக முதுநிலை மீது நிச்சயமற்ற தன்மை அதிகமாக இருந்தால், ஆனால் உலகளவில் விநியோகிக்கப்பட்ட சூழ்நிலையிலும் சரியான தன்மையை உறுதி செய்கிறது.

ஸ்பேனர் கூறுகள் TrueTime ஐப் பயன்படுத்துகின்றன, அங்கு TT.now() ஒரு இடைவெளியைத் தருகிறது, எனவே தற்போதைய நேரம் ஒரு குறிப்பிட்ட புள்ளியைக் கடந்துவிட்டதாக நம்பக்கூடிய புள்ளி வரை ஸ்பேனர் தூங்குகிறது.

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

தாமதம் என்பதற்கு பல அர்த்தங்கள் உண்டு

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

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

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

அட்டவணை X இல் (50 மில்லியன் வரிசைகளுடன்) புதிய வரிசையைச் செருகும் போது, குறிப்பிட்ட கட்டுப்பாடுகள் மற்றும் தொடர்புடைய அட்டவணைகளில் வரிசை திணிப்பு ஆகியவற்றைச் செருகும்போது செயல்திறன் மற்றும் தாமதத்தை எழுதவும்.
சராசரி நண்பர்களின் எண்ணிக்கை 500 ஆக இருக்கும்போது குறிப்பிட்ட பயனரின் நண்பர்களின் நண்பர்களைக் காட்டுவதில் தாமதம்.
ஒரு மணிநேரத்திற்கு X உள்ளீடுகளுடன் 100 பிற பயனர்களைப் பயனர் பின்தொடரும் போது, ஒரு பயனரின் வரலாற்றிலிருந்து முதல் 500 உள்ளீடுகளை மீட்டெடுப்பதில் தாமதம்.

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

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

உள்ளமைக்கப்பட்ட பரிவர்த்தனைகள் ஆபத்தானவை

ஒவ்வொரு DBMS உள்ளமை பரிவர்த்தனைகளை ஆதரிக்காது, ஆனால் அவை செய்யும் போது, அத்தகைய பரிவர்த்தனைகள் எதிர்பாராத பிழைகளை ஏற்படுத்தலாம், அவை எப்போதும் எளிதில் கண்டறிய முடியாது (அதாவது, ஒருவித ஒழுங்கின்மை இருப்பது தெளிவாக இருக்க வேண்டும்).

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

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

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

மேலே உள்ள குறியீட்டின் வெளியீடு என்னவாக இருக்கும்? இது இரண்டு பரிவர்த்தனைகளையும் திரும்பப் பெறுமா அல்லது உள் ஒன்றை மட்டும் திரும்பப் பெறுமா? நமக்கான பரிவர்த்தனைகளை உருவாக்குவதை உள்ளடக்கிய நூலகங்களின் பல அடுக்குகளை நாம் நம்பினால் என்ன நடக்கும்? அத்தகைய நிகழ்வுகளை நாம் கண்டறிந்து மேம்படுத்த முடியுமா?

பல செயல்பாடுகளைக் கொண்ட தரவு அடுக்கை கற்பனை செய்து பாருங்கள் (எ.கா. newAccount) ஏற்கனவே அதன் சொந்த பரிவர்த்தனைகளில் செயல்படுத்தப்படுகிறது. அதன் சொந்த பரிவர்த்தனைக்குள் இயங்கும் உயர்நிலை வணிக தர்க்கத்தின் ஒரு பகுதியாக நீங்கள் அவற்றை இயக்கினால் என்ன நடக்கும்? இந்த வழக்கில் தனிமை மற்றும் நிலைத்தன்மை என்னவாக இருக்கும்?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

பரிவர்த்தனைகள் பயன்பாட்டு நிலைக்கு இணைக்கப்படக்கூடாது

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

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

வினவல் திட்டமிடுபவர்கள் தரவுத்தளத்தைப் பற்றி உங்களுக்கு நிறைய சொல்ல முடியும்

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

SELECT * FROM articles where author = "rakyll" order by title;

முடிவுகளை இரண்டு வழிகளில் மீட்டெடுக்கலாம்:

முழு டேபிள் ஸ்கேன்: நீங்கள் அட்டவணையில் உள்ள ஒவ்வொரு உள்ளீட்டையும் பார்த்து, பொருத்தமான ஆசிரியர் பெயருடன் கட்டுரைகளைத் திருப்பி அனுப்பலாம், பின்னர் அவற்றை ஆர்டர் செய்யலாம்.
குறியீட்டு ஸ்கேன்: பொருந்தக்கூடிய ஐடிகளைக் கண்டறிய, அந்த வரிசைகளைப் பெற, பின்னர் அவற்றை ஆர்டர் செய்ய நீங்கள் ஒரு குறியீட்டைப் பயன்படுத்தலாம்.

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

வினவல் திட்டமிடுபவர் வழங்கும் சில அளவீடுகள் சத்தத்திற்கு உட்பட்டதாக இருக்கலாம் (குறிப்பாக தாமதம் அல்லது CPU நேரத்தை மதிப்பிடும்போது). திட்டமிடுபவர்களுக்கு ஒரு நல்ல கூடுதலாக, செயல்படுத்தும் பாதையை தடமறிதல் மற்றும் கண்காணிப்பதற்கான கருவிகள் ஆகும். இத்தகைய சிக்கல்களைக் கண்டறிய அவை உங்களை அனுமதிக்கின்றன (ஐயோ, எல்லா DBMSகளும் அத்தகைய கருவிகளை வழங்குவதில்லை).

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

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

வெவ்வேறு ஆன்லைன் இடம்பெயர்வு மாதிரிகள் உள்ளன. அவற்றில் ஒன்று இதோ:

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

கூடுதல் தகவலுக்கு, நான் தொடர்பு கொள்ள பரிந்துரைக்கிறேன் கட்டுரை, இது இந்த மாதிரியின் அடிப்படையில் ஸ்ட்ரைப்பின் இடம்பெயர்வு உத்தியை விவரிக்கிறது.

தரவுத்தளத்தில் குறிப்பிடத்தக்க அதிகரிப்பு கணிக்க முடியாத அதிகரிப்பை ஏற்படுத்துகிறது

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

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

...

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

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

ஆதாரம்: www.habr.com

தரவுத்தளங்களைப் பற்றி அதிகமான டெவலப்பர்கள் இதை அறிந்திருக்க வேண்டும்