3.1 ACID தோன்றுதல்
ACID என்ற சுருக்கம் முதன்முதலில் 1983 இல் தியோ ஹெர்டர் மற்றும் ஆண்ட்ரியாஸ் ராய்ட்டர் ஆகியோரின் கட்டுரையில் தோன்றியது. உரையை எளிமைப்படுத்தவும், அதை மேலும் உறுதிபடுத்தவும், இந்த கட்டுரையின் ஒரு பகுதியின் மொழிபெயர்ப்பை (சிறிய குறைப்புகளுடன்) தருகிறேன். இந்த துணுக்கு ஒரு வங்கி பரிவர்த்தனையின் உதாரணத்தைப் பயன்படுத்துகிறது, அதில் ஒரு கணக்கிலிருந்து மற்றொரு கணக்கிற்கு பணம் மாற்றப்படுகிறது.
$BEGIN_TRANSACTIONமற்றும் இடையேயான தரவுத்தளத்துடனான அனைத்து தொடர்புகளையும் உள்ளடக்கிய ஒரு பரிவர்த்தனையின் கருத்து, $COMMIT_TRANSACTIONஅனைத்து செயல்களும் பிரிக்கப்படாமல் செய்யப்பட வேண்டும்: ஒன்று அனைத்து செயல்களும் தரவுத்தளத்தின் நிலையில் சரியாக பிரதிபலிக்கின்றன, அல்லது எதுவும் நடக்காது. எந்த நேரத்திலும் $COMMIT_TRANSACTIONபயனரை அடைவதற்கு முன் ஒரு அறிக்கையை உள்ளிடினால் ERROR, $RESTORE_TRANSACTIONதரவுத்தளத்தில் எந்த மாற்றமும் பிரதிபலிக்காது.
இந்த பிரிவினையை அடைய, ஒரு பரிவர்த்தனை பின்வரும் நான்கு பண்புகளைக் கொண்டிருக்க வேண்டும்:
அணுசக்தி (Atomicity). பரிவர்த்தனையானது மேலே விவரிக்கப்பட்ட அனைத்து அல்லது ஒன்றுமில்லாத வகையாக இருக்க வேண்டும், என்ன நடந்தாலும், பரிவர்த்தனை எந்த நிலையில் உள்ளது என்பதை பயனர் அறிந்திருக்க வேண்டும்.
நிலைத்தன்மை (Consistency). பரிவர்த்தனையின் இயல்பான முடிவை (EOT) அடைந்து அதன் முடிவுகள் தரவுத்தள நிலைத்தன்மையைப் பராமரிக்கும் பரிவர்த்தனை. வேறு வார்த்தைகளில் கூறுவதானால், ஒவ்வொரு வெற்றிகரமான பரிவர்த்தனையும், வரையறையின்படி, சரியான முடிவுகளை மட்டுமே செய்கிறது. நான்காவது சொத்தை ஆதரிக்க இந்த நிலை அவசியம் - ஆயுள்.
தனிமைப்படுத்தல் (தனிமைப்படுத்தல்). ஒரு பரிவர்த்தனையில் நிகழும் நிகழ்வுகள் மற்ற ஒரே நேரத்தில் செயல்படும் பரிவர்த்தனைகளிலிருந்து மறைக்கப்பட வேண்டும். இந்த நிபந்தனை பூர்த்தி செய்யப்படாவிட்டால், மேலே குறிப்பிட்டுள்ள காரணங்களுக்காக, பரிவர்த்தனை அதன் தொடக்கத்திற்குத் திரும்ப இயலாது. தனிமைப்படுத்தலை அடைய, ஒத்திசைவு எனப்படும் முறைகள் பயன்படுத்தப்படுகின்றன ...
நீடித்து நிலைப்பு (Durability). ஒரு பரிவர்த்தனையை முடித்து அதன் முடிவுகளை தரவுத்தளத்தில் ஒப்படைத்தவுடன், அந்த முடிவுகள் அடுத்தடுத்த தோல்விகளைத் தக்கவைப்பதை கணினி உறுதி செய்ய வேண்டும். பரிவர்த்தனைகளின் தொகுப்புகளை விரிவுபடுத்தும் கட்டுப்பாட்டு நோக்கம் இல்லாததால், தரவுத்தள மேலாண்மை அமைப்பு (DBMS) பரிவர்த்தனைகளின் எல்லைகளுக்கு அப்பால் எந்த கட்டுப்பாடும் இல்லை.
எனவே, ஏதாவது நடந்ததாக கணினி அவருக்குத் தெரிவித்தால், இந்த "ஏதோ" உண்மையில் நடந்துள்ளது என்று பயனருக்கு உத்தரவாதம் அளிக்க வேண்டும். வரையறையின்படி, எந்தவொரு (வெற்றிகரமாக முடிக்கப்பட்ட - எஸ்.கே.) பரிவர்த்தனை சரியானது என்பதால், தவிர்க்க முடியாமல் தோன்றும் தவறான பரிவர்த்தனைகளின் முடிவுகள் (அதாவது பிழையான தரவுகளைக் கொண்ட பரிவர்த்தனைகள்) தொடர்புடைய "எதிர்" பரிவர்த்தனை (எதிர் பரிவர்த்தனை) மூலம் மட்டுமே அகற்றப்படும்.
3.2 பரிவர்த்தனைகளின் தோற்றம்
இந்த நான்கு பண்புகள் - அணு, நிலைத்தன்மை, தனிமைப்படுத்தல் மற்றும் நீடித்து நிலைப்பு (ACID) - தரவுத்தள அமைப்பு வடிவமைப்பின் பல அம்சங்களைப் பாதிக்கும் பரிவர்த்தனை முன்னுதாரணத்தின் முக்கிய அம்சங்களை விவரிக்கிறது. எனவே, பரிவர்த்தனைகளை ஆதரிக்கும் எந்தவொரு அமைப்பின் திறனும் இந்த அமைப்பின் தரத்தின் டச்ஸ்டோன் (ACID சோதனை) என்று நாங்கள் நம்புகிறோம்.
ஒரு எளிய PL/1-SQL நிரல் ஒரு கணக்கிலிருந்து மற்றொரு கணக்கிற்கு பணத்தை மாற்றும்.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */உண்மையில், ACID பண்புகள், ஒருபுறம், பரிவர்த்தனைகளை ஆதரிப்பதாகக் கூறும் எந்தவொரு DBMSக்கான தேவைகளாகவும், மறுபுறம், பரிவர்த்தனையின் வரையறையாகவும் கருதலாம் என்பதை உங்களுக்கு நினைவூட்டுவதற்காக இந்தக் குறியீட்டின் உதாரணத்தை வழங்கினேன். ஒரு தரவுத்தள அமைப்பு . இந்த வரையறை உலக நடைமுறையுடன் முழுமையாக ஒத்துப்போகிறது. எடுத்துக்காட்டாக, ஒரு வாடிக்கையாளர் வங்கிப் பரிவர்த்தனையை (நேரடி மனித டெல்லரின் உதவியுடன் அல்லது இணைய வங்கியைப் பயன்படுத்தினால்) ACID இன் அனைத்துப் பண்புகளையும் வங்கி திருப்திப்படுத்தும் என்று எதிர்பார்க்கவில்லை என்று கற்பனை செய்வது கடினம். அதன் பரிவர்த்தனைகளுக்கு ACID பண்புகளை ஆதரிக்காத வங்கி, சிறந்த வாடிக்கையாளர்களை இழக்கும், மேலும் மோசமான நிலையில், திவாலாகிவிடும்.
3.3 ACID இணைப்பு
ACID பண்புகள் பிரிக்க முடியாதவை என்பது மிகவும் முக்கியமானது, அவற்றில் ஏதேனும் ஒன்றை நிராகரிப்பது மீதமுள்ள கலவையை அர்த்தமற்றதாக்குகிறது. குறிப்பாக, சீரான சொத்தை (மேலே உள்ள மேற்கோளில் பயன்படுத்திய பொருளில்) நிராகரித்தால், பரிவர்த்தனையின் சரியான தன்மைக்கான அளவுகோலை இழப்போம். பரிவர்த்தனைகள் அனுமதிக்கப்படுகிறதா இல்லையா என்பதை தரவுத்தள அமைப்பு எந்த அர்த்தமுள்ள விதத்திலும் தீர்மானிக்க முடியாது, மேலும் தரவுத்தளத்தின் தற்போதைய நிலையில் செய்யப்படும் செயல்பாடுகளின் சரியான தன்மைக்கான அனைத்து சோதனைகளும் பயன்பாட்டுக் குறியீட்டில் செய்யப்பட வேண்டும்.
இந்த விஷயத்தில் நாங்கள் தர்க்கரீதியான நிலைத்தன்மையைப் பற்றி பேசுகிறோம் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். வங்கியின் வாடிக்கையாளருக்கு அவரால் நிறுவப்பட்ட மற்றும் வாடிக்கையாளர்களுக்குத் தெரிந்த விதிகளின்படி வங்கி செயல்பட வேண்டும், இதனால் இந்த விதிகளை மீறும் எந்தவொரு பரிவர்த்தனையும் செய்ய முடியாது, இதனால் அதே வாடிக்கையாளரின் அடுத்த பரிவர்த்தனை ஒரு நிறுவனத்தில் செயல்படுத்தப்படுகிறது. சுற்றுச்சூழல் இந்த விதிகளின்படி ஒப்புக் கொள்ளப்பட்டது.
ஆன்லைன் ஸ்டோரின் வாடிக்கையாளருக்கு அவர் ஆர்டர் செய்த மற்றும் பணம் செலுத்திய பொருட்கள் சரியான நேரத்தில் அவருக்கு வழங்கப்பட வேண்டும் (வாடிக்கையாளருக்கு நிறுவப்பட்ட மற்றும் அறியப்பட்ட விதிகளின்படி). இல்லையெனில், அவர் இந்த கடையை நம்ப மாட்டார். அதே நேரத்தில், வங்கியின் வாடிக்கையாளரோ அல்லது இணைய அங்காடியின் வாடிக்கையாளரோ நிறுவனத்தின் உள் சமையலறையைப் பற்றி கவலைப்படுவதில்லை, அதன் பரிவர்த்தனையை முடிக்க என்ன உள் நடவடிக்கைகள் எடுக்கப்படுகின்றன. இந்த நிறுவனத்தின் உடல் நிலைத்தன்மை எவ்வாறு பராமரிக்கப்படுகிறது, உடல் மட்டத்தில் செயல்பாடுகள் எவ்வாறு செய்யப்படுகின்றன என்பதை வாடிக்கையாளர் கவலைப்படுவதில்லை.
பரிவர்த்தனைகளின் தருக்க நிலைத்தன்மையை (மற்றும் தரவுத்தளம்) பராமரிப்பதை DBMS கவனித்துக்கொண்டால், பயன்பாடுகள் எளிமையானதாகவும், புரிந்துகொள்ளக்கூடியதாகவும், மேலும் நம்பகமானதாகவும் மாறும். பரிவர்த்தனைகள் மற்றும் தரவின் செல்லுபடியாகும் நிலை தொடர்பான பயன்பாட்டுப் பகுதியின் (வங்கி, ஸ்டோர், கிடங்கு, முதலியன) அனைத்து தர்க்கங்களும் தரவுத்தள அமைப்பிற்குள் செல்கிறது. இந்த அமைப்பிற்கான தேவைகள் மிகவும் எளிமையானவை: ACID பரிவர்த்தனைகளுக்கான ஆதரவு, பயன்பாட்டினால் தரவுத்தளத்தில் வழங்கப்பட்ட நிலைத்தன்மை விதிகளை கணக்கில் எடுத்துக்கொள்வது. எனது பார்வையில், ACID பரிவர்த்தனைகளை நிராகரிப்பது பயன்பாட்டு டெவலப்பர்களுக்கு மிதமிஞ்சிய சிரமங்களை உருவாக்குகிறது, நீங்கள் விரும்பினாலும் விரும்பாவிட்டாலும், தங்கள் வாடிக்கையாளர்களின் இயல்பான தேவைகளைப் பூர்த்தி செய்வதற்காக தாங்களாகவே ஏதாவது ஒன்றைச் செயல்படுத்த வேண்டும்.
ACID பண்புகள், உண்மையில், ஒரு பரிவர்த்தனையின் கருத்தை வரையறுக்கின்றன என்பதை மீண்டும் நான் கவனிக்கிறேன். என் கருத்துப்படி, பரிவர்த்தனை நிலைத்தன்மையின் சொத்து ஆதரிக்கப்படாத ஒரு பரிவர்த்தனை தரவு மேலாண்மை அமைப்பைப் பற்றி பேசுவதற்கு குறைந்தபட்சம் சில வாய்ப்புகளைப் பெறுவதற்கு, இந்த விஷயத்தில் பரிவர்த்தனை என்ற வார்த்தையின் அர்த்தம் என்ன என்பதை வரையறுப்பது முற்றிலும் அவசியம்.
துரதிர்ஷ்டவசமாக, இன்று பல சந்தர்ப்பங்களில் (குறிப்பாக, இது NoSQL திசையின் சிறப்பியல்பு), மக்கள் OLTP பயன்பாடுகளை ஆதரிப்பதைப் பற்றி அவர்கள் எந்த வகையான பரிவர்த்தனைகளைக் குறிப்பிடுகிறார்கள் என்பதைக் குறிப்பிடாமல் பேசுகிறார்கள். எனவே, இந்தக் கட்டுரையில், உண்மையான பரிவர்த்தனைகளைக் குறிக்க, ACID பரிவர்த்தனை என்ற கலவையைப் பயன்படுத்துவேன், மேலும் தகுதியற்ற பரிவர்த்தனை என்பது முறைசாரா அர்த்தத்தில், வெவ்வேறு சூழல்களில் வேறுபட்டதாகப் பயன்படுத்தப்படும்.
இப்போது CAP இன் "தேற்றத்தை" கையாள்வோம் மற்றும் ப்ரூவரின் அர்த்தத்தில் நிலைத்தன்மை என்றால் என்ன என்பதைக் கண்டுபிடிக்க முயற்சிப்போம்.