BASE vs ACID

6.1 சுருக்கங்களின் போர்: BASE vs. ACID

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

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

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

6.2 ஒரு எதிரியாக அடிப்படை

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

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

பல NoSQL தரவுத்தளங்கள் தனிமைப்படுத்தல் உத்தரவாதத்தை துறந்து "இறுதி நிலைத்தன்மையை" வழங்குகின்றன, இதன் மூலம் நீங்கள் சரியான தரவைப் பார்ப்பீர்கள், ஆனால் உங்கள் பரிவர்த்தனை தவறான மதிப்புகளைப் படிக்கும் வாய்ப்பு உள்ளது - அதாவது, தற்காலிக, அல்லது ஓரளவு புதுப்பிக்கப்பட்ட அல்லது காலாவதியானது. படிக்கும் போது தரவு "சோம்பேறி" பயன்முறையில் சீராக மாறுவது சாத்தியம் ("படிக்கும் நேரத்தில் சோம்பேறித்தனமாக").

NoSQL நிகழ்நேர பகுப்பாய்வுக்கான தரவுத்தளமாக கருதப்பட்டது, மேலும் அதிக வேகத்தை அடைவதற்காக, அவை நிலைத்தன்மையை தியாகம் செய்தன. மற்றும் எரிக் ப்ரூவர், BASE என்ற வார்த்தையை உருவாக்கிய அதே நபர், "CAP தேற்றம்" என்று அழைக்கப்படுவதை உருவாக்கினார், அதன்படி:

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

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

நீங்கள் CAP இன் மிக எளிய விளக்கத்தை விரும்பினால், இங்கே நீங்கள் செல்லலாம்.

CAP தேற்றம் வேலை செய்யாது மற்றும் பொதுவாக மிகவும் சுருக்கமாக வடிவமைக்கப்பட்டுள்ளது என்ற கருத்துக்கள் உள்ளன. ஒரு வழி அல்லது வேறு, NoSQL தரவுத்தளங்கள் பெரும்பாலும் CAP தேற்றத்தின் சூழலில் நிலைத்தன்மையை மறுக்கின்றன, இது பின்வரும் சூழ்நிலையை விவரிக்கிறது: தரவு பல நிகழ்வுகளுடன் ஒரு கிளஸ்டரில் புதுப்பிக்கப்பட்டது, ஆனால் மாற்றங்கள் இன்னும் அனைத்து நிகழ்வுகளிலும் ஒத்திசைக்கப்படவில்லை. நினைவில் கொள்ளுங்கள், மேலே உள்ள DynamoDB உதாரணத்தை நான் குறிப்பிட்டேன், அது எனக்குச் சொன்னது: உங்கள் மாற்றங்கள் நீடித்தது - இதோ உங்களுக்காக ஒரு HTTP 200 - ஆனால் நான் மாற்றங்களை 10 வினாடிகளுக்குப் பிறகுதான் பார்த்தேன்? டெவலப்பரின் அன்றாட வாழ்க்கையிலிருந்து மற்றொரு உதாரணம் DNS, டொமைன் பெயர் அமைப்பு. யாருக்கும் தெரியாவிட்டால், http (s) முகவரிகளை IP முகவரிகளாக மொழிபெயர்க்கும் "அகராதி" இதுதான்.

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

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

ACID அல்லாத NoSQL தரவுத்தளங்கள் எண்ட்-டு-எண்ட் சீரான மாதிரியின் காரணமாக "மென்மையான நிலை" என்று அழைக்கப்படுகின்றன, அதாவது கணினியின் நிலை உள்ளீடு இல்லாமல் கூட காலப்போக்கில் மாறலாம். ஆனால் அத்தகைய அமைப்புகள் அதிக அணுகலை வழங்க முயற்சி செய்கின்றன. 100% கிடைக்கும் தன்மையை வழங்குவது ஒரு சிறிய பணி அல்ல, எனவே நாங்கள் "அடிப்படை கிடைக்கும் தன்மை" பற்றி பேசுகிறோம். மேலும் இந்த மூன்று கருத்துக்களும் சேர்ந்து: "அடிப்படையில் கிடைக்கும்", "மென்மையான நிலை" ("மென்மையான நிலை") மற்றும் "இறுதி நிலைத்தன்மை" ஆகியவை BASE என்ற சுருக்கத்தை உருவாக்குகின்றன.

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

6.3 எனவே BASE தரவுத்தளங்கள் ACID அளவுகோல்களை பூர்த்தி செய்யவில்லையா?

முக்கியமாக, ACID தரவுத்தளங்கள் ACID அல்லாதவற்றிலிருந்து வேறுபடும் போது, ​​ACID அல்லாதவை உண்மையில் தனிமைப்படுத்தப்படுவதைத் தவிர்க்கின்றன. இதைப் புரிந்துகொள்வது முக்கியம். ஆனால் தரவுத்தள ஆவணங்களைப் படித்து, ஹெர்மிடேஜ் திட்டத்தின் தோழர்கள் செய்யும் விதத்தில் அவற்றைச் சோதிப்பது இன்னும் முக்கியமானது. இந்த அல்லது அந்த தரவுத்தளத்தை உருவாக்கியவர்கள் தங்கள் மூளையை - ACID அல்லது BASE, CAP அல்லது CAP என்று எப்படி அழைக்கிறார்கள் என்பது அவ்வளவு முக்கியமல்ல. முக்கியமான விஷயம் என்னவென்றால், இந்த அல்லது அந்த தரவுத்தளம் சரியாக என்ன வழங்குகிறது.

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

• அணுசக்திக்கு DB உத்தரவாதம் அளிக்கவில்லை. சில NoSQL தரவுத்தளங்கள் அணு செயல்பாடுகளுக்கு தனி API வழங்கும் போது (எ.கா. DynamoDB);

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

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

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

6.4 வெவ்வேறு தரவுத்தளங்கள் குறியீட்டுத் தரவை எவ்வாறு பாதிக்கிறது, மேலும் இது எவ்வாறு ஆயுளைப் பாதிக்கிறது மற்றும் பல

தரவைச் சேமிப்பதற்கும் மீட்டெடுப்பதற்கும் இரண்டு முக்கிய அணுகுமுறைகள் உள்ளன.

தரவைச் சேமிப்பதற்கான எளிதான வழி, கோப்பின் முடிவில் பதிவு போன்ற முறையில் செயல்பாடுகளைச் சேர்ப்பதாகும் (அதாவது, ஒரு பிற்சேர்க்கை செயல்பாடு எப்போதும் நிகழ்கிறது): நாம் தரவைச் சேர்க்க, மாற்ற அல்லது நீக்க விரும்பினாலும் பரவாயில்லை - அனைத்தும் CRUD செயல்பாடுகள் வெறுமனே பதிவில் எழுதப்படுகின்றன. பதிவைத் தேடுவது திறமையற்றது, மேலும் குறியீட்டு எண் வருகிறது - தரவு சேமிக்கப்படும் இடம் பற்றிய மெட்டாடேட்டாவைச் சேமிக்கும் ஒரு சிறப்பு தரவு அமைப்பு. பதிவுகளுக்கான எளிய அட்டவணைப்படுத்தல் உத்தி, விசைகள் மற்றும் மதிப்புகளைக் கண்காணிக்கும் ஹாஷ் வரைபடமாகும். மதிப்புகள் கோப்பின் உள்ளே எழுதப்பட்ட தரவுக்கான பைட் ஆஃப்செட்டிற்கான குறிப்புகளாக இருக்கும், இது பதிவு (பதிவு) மற்றும் வட்டில் சேமிக்கப்படுகிறது. இந்த தரவு அமைப்பு முழுவதுமாக நினைவகத்தில் சேமிக்கப்படுகிறது, அதே நேரத்தில் தரவு வட்டில் இருக்கும், மேலும் இது LSM மரம் (பதிவு கட்டமைக்கப்பட்ட ஒன்றிணைப்பு) என்று அழைக்கப்படுகிறது.

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

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

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

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

இருப்பினும், குறியீட்டின் வடிவமைப்பு நேரடியாக தரவுத்தளத்தின் செயல்திறனை பாதிக்கிறது. ஒரு எல்எஸ்எம் மரத்தில், வட்டுக்கு எழுதுவது வரிசையாக இருக்கும், மேலும் பி-ட்ரீகள் பல சீரற்ற வட்டு அணுகலை ஏற்படுத்துகின்றன, எனவே பி-ட்ரீகளை விட எல்எஸ்எம் மூலம் எழுதும் செயல்பாடுகள் வேகமாக இருக்கும். மேக்னடிக் ஹார்ட் டிஸ்க் டிரைவ்களுக்கு (HDDs) வித்தியாசம் குறிப்பிடத்தக்கது, அங்கு சீரற்ற எழுத்துகளை விட வரிசையாக எழுதுவது மிக வேகமாக இருக்கும். எல்எஸ்எம் மரங்களில் வாசிப்பு மெதுவாக உள்ளது, ஏனெனில் நீங்கள் பல்வேறு தரவு கட்டமைப்புகள் மற்றும் சுருக்கத்தின் வெவ்வேறு நிலைகளில் உள்ள எஸ்எஸ் அட்டவணைகள் மூலம் பார்க்க வேண்டும். இன்னும் விரிவாக இது போல் தெரிகிறது. எல்எஸ்எம் மூலம் ஒரு எளிய தரவுத்தள வினவலை உருவாக்கினால், முதலில் மெம்டேபிளில் உள்ள விசையைத் தேடுவோம். அது இல்லை என்றால், நாங்கள் மிகவும் சமீபத்திய SSTable பார்க்கிறோம்; இல்லை என்றால், நாம் இறுதி SSTable மற்றும் பலவற்றைப் பார்க்கிறோம். கோரப்பட்ட விசை இல்லை என்றால், LSM உடன் இதை கடைசியாக அறிந்துகொள்வோம். LSM மரங்கள் பயன்படுத்தப்படுகின்றன, எடுத்துக்காட்டாக: LevelDB, RocksDB, Cassandra மற்றும் HBase.

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

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

6.5 இன்-மெமரி டிபிகள் எப்படி வேலை செய்கின்றன

மூலம், வட்டில் எழுதும் தரவுத்தளங்களுக்கு கூடுதலாக, RAM உடன் முக்கியமாக வேலை செய்யும் "in-memory" தரவுத்தளங்கள் உள்ளன. சுருக்கமாக, இன்-மெமரி தரவுத்தளங்கள் பொதுவாக வேகமாக எழுத மற்றும் படிக்கும் வேகத்திற்காக குறைந்த நீடித்துழைப்பை வழங்குகின்றன, ஆனால் சில பயன்பாடுகளுக்கு இது பொருத்தமானதாக இருக்கலாம்.

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

• நீங்கள் பேட்டரிகள் மூலம் இயக்கப்படும் ரேம் பயன்படுத்த முடியும்;
• மாற்ற பதிவுகளை வட்டில் எழுதலாம் (மேலே குறிப்பிட்டுள்ள WALகள் போன்றவை), ஆனால் தரவு அல்ல;
• தரவுத்தள நிலையின் நகல்களை நீங்கள் அவ்வப்போது வட்டுக்கு எழுதலாம் (இது, பிற விருப்பங்களைப் பயன்படுத்தாமல், உத்தரவாதத்தை அளிக்காது, ஆனால் ஆயுளை மட்டுமே மேம்படுத்துகிறது);
• நீங்கள் ரேமின் நிலையை மற்ற இயந்திரங்களுக்கு நகலெடுக்கலாம்.

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

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