NewSQL = NoSQL+ACID

Odnoklassniki இல் சமீபத்தில் வரை நிகழ்நேரத்தில் செயலாக்கப்பட்ட சுமார் 50 TB தரவு SQL சர்வரில் சேமிக்கப்பட்டது. அத்தகைய தொகுதிக்கு, SQL DBMS ஐப் பயன்படுத்தி வேகமான மற்றும் நம்பகமான தரவு மைய அணுகலை வழங்குவது கிட்டத்தட்ட சாத்தியமற்றது. பொதுவாக இதுபோன்ற சந்தர்ப்பங்களில் NoSQL கடைகளில் ஒன்று பயன்படுத்தப்படுகிறது, ஆனால் எல்லாவற்றையும் NoSQL க்கு மாற்ற முடியாது: சில நிறுவனங்களுக்கு ACID பரிவர்த்தனை உத்தரவாதங்கள் தேவைப்படுகின்றன.

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

இது எப்படி வேலை செய்கிறது மற்றும் என்ன நடந்தது - வெட்டு கீழ் படிக்கவும்.

இன்று, ஒட்னோக்ளாஸ்னிகியின் மாதாந்திர பார்வையாளர்கள் 70 மில்லியனுக்கும் அதிகமான தனிப்பட்ட பார்வையாளர்களாக உள்ளனர். நாங்கள் முதல் ஐந்து இடங்களுக்குள் நுழையுங்கள் உலகின் மிகப்பெரிய சமூக வலைப்பின்னல்கள் மற்றும் பயனர்கள் அதிக நேரம் செலவிடும் முதல் இருபது தளங்களில். "சரி" உள்கட்டமைப்பு மிக அதிக சுமைகளைக் கையாளுகிறது: முன்பக்கத்திற்கு ஒரு மில்லியனுக்கும் அதிகமான HTTP கோரிக்கைகள்/வினாடிகள். 8000 க்கும் மேற்பட்ட துண்டுகள் உள்ள சர்வர் பூங்காவின் பகுதிகள் ஒருவருக்கொருவர் நெருக்கமாக அமைந்துள்ளன - நான்கு மாஸ்கோ தரவு மையங்களில், அவற்றுக்கிடையே 1 ms க்கும் குறைவான பிணைய தாமதத்தை வழங்குவதை சாத்தியமாக்குகிறது.

பதிப்பு 2010 இல் தொடங்கி 0.6 ஆம் ஆண்டு முதல் கசாண்ட்ராவைப் பயன்படுத்துகிறோம். இன்று, பல டஜன் கிளஸ்டர்கள் செயல்படுகின்றன. அதிவேகமான கிளஸ்டர் வினாடிக்கு 4 மில்லியனுக்கும் அதிகமான செயல்பாடுகளைச் செய்கிறது, அதே சமயம் மிகப்பெரியது 260 TBஐச் சேமிக்கிறது.

இருப்பினும், இவை அனைத்தும் சேமிக்கப் பயன்படும் சாதாரண NoSQL கிளஸ்டர்கள் பலவீனமாக ஒருங்கிணைக்கப்பட்டது தகவல்கள். Odnoklassniki நிறுவப்பட்டதில் இருந்து பயன்படுத்தப்பட்டு வரும் முக்கிய நிலையான சேமிப்பகமான Microsoft SQL சர்வரை மாற்றவும் நாங்கள் விரும்புகிறோம். சேமிப்பகம் 300 க்கும் மேற்பட்ட SQL சர்வர் ஸ்டாண்டர்ட் எடிஷன் இயந்திரங்களைக் கொண்டிருந்தது, அதில் 50 TB தரவு இருந்தது - வணிக நிறுவனங்கள். இந்தத் தரவு ACID பரிவர்த்தனைகளின் ஒரு பகுதியாக மாற்றியமைக்கப்பட்டுள்ளது மற்றும் தேவைப்படுகிறது உயர் நிலைத்தன்மை.

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

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

• ஷார்டிங் செய்யும் போது, ​​நிறுவன ஐடி வேறொரு சர்வரில் இருக்கும் என்பதால், வெளிநாட்டு விசைக் கட்டுப்பாடுகளை நாங்கள் பயன்படுத்துவதில்லை.
• DBMS CPU இல் கூடுதல் சுமை இருப்பதால், சேமிக்கப்பட்ட நடைமுறைகள் மற்றும் தூண்டுதல்களைப் பயன்படுத்த மாட்டோம்.
• மேலே உள்ள அனைத்தும் மற்றும் வட்டில் இருந்து நிறைய சீரற்ற வாசிப்புகளின் காரணமாக நாங்கள் JOINகளைப் பயன்படுத்துவதில்லை.
• ஒரு பரிவர்த்தனைக்கு வெளியே, டெட்லாக்களைக் குறைக்க, நாங்கள் படிக்காதபடி தனிமைப்படுத்தப்பட்ட அளவைப் பயன்படுத்துகிறோம்.
• நாங்கள் குறுகிய பரிவர்த்தனைகளை மட்டுமே செய்கிறோம் (சராசரியாக 100msக்கும் குறைவாக).
• அதிக எண்ணிக்கையிலான முட்டுக்கட்டைகள் காரணமாக நாங்கள் பல வரிசை புதுப்பிப்பு மற்றும் நீக்குதலைப் பயன்படுத்துவதில்லை - ஒரு நேரத்தில் ஒரு பதிவை மட்டுமே புதுப்பிக்கிறோம்.
• வினவல்கள் எப்பொழுதும் குறியீடுகளால் மட்டுமே செயல்படுத்தப்படும் - முழு டேபிள் ஸ்கேன் திட்டத்துடன் கூடிய வினவல் என்பது தரவுத்தளத்தின் அதிக சுமை மற்றும் அதன் தோல்வி என்று பொருள்.

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

SQL இல் உள்ள சிக்கல்கள்

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

ஆனால் முக்கிய பிரச்சனை

தவறு சகிப்புத்தன்மை

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

SQL சேவையகத்தின் தவறு சகிப்புத்தன்மையை மேம்படுத்த என்ன செய்யலாம்? கட்டமைக்க விக்கிபீடியா எங்களை அழைக்கிறது மிகவும் கிடைக்கக்கூடிய கிளஸ்டர்: ஏதேனும் கூறுகள் தோல்வியுற்றால் காப்புப்பிரதி இருக்கும்.

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

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

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

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

எளிமையான பரிவர்த்தனை

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

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

அல்லது சூடோகோடில்:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

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

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

மற்ற சமமான முக்கியமான தேவைகள்:

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

முடிவுகள், முடிவுகள்

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

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

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

கசாண்ட்ரா மற்றும் CQL

எனவே, கசாண்ட்ராவைப் பற்றிய சுவாரஸ்யமானது என்ன, அதில் என்ன அம்சங்கள் உள்ளன?

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

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

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

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

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

கசாண்ட்ராவில் நாங்கள் தவறவிட்டவை

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

சி*ஒன்

எனவே புதிய டிபிஎம்எஸ் பிறந்தது சி*ஒன், மூன்று வகையான சர்வர் முனைகளைக் கொண்டது:

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

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

வாடிக்கையாளர்கள்

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

C*ஒரு பரிவர்த்தனை ஒருங்கிணைப்பாளர்

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

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

பூட்டுகள்

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

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

எங்கள் விஷயத்தில், SQL இல் உள்ள உள்ளூர் பரிவர்த்தனைகளின் குழுக்களிடையே தரவு ஏற்கனவே விநியோகிக்கப்பட்டுள்ளதால், ஒருங்கிணைப்பாளர்களுக்கு உள்ளூர் பரிவர்த்தனைகளின் குழுக்களை ஒதுக்க முடிவு செய்யப்பட்டது: ஒரு ஒருங்கிணைப்பாளர் அனைத்து பரிவர்த்தனைகளையும் 0 முதல் 9 வரையிலான டோக்கனுடன் செய்கிறார், இரண்டாவது - ஒரு டோக்கனுடன் 10 முதல் 19, மற்றும் பல. இதன் விளைவாக, ஒருங்கிணைப்பாளரின் ஒவ்வொரு நிகழ்வுகளும் பரிவர்த்தனை குழுவின் முதன்மையாக மாறும்.

பின்னர் ஒருங்கிணைப்பாளரின் நினைவாக பூட்டுகளை சாதாரணமான HashMap ஆக செயல்படுத்தலாம்.

ஒருங்கிணைப்பாளர்களின் மறுப்பு

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

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

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

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

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

இட ஒதுக்கீடு

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

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

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

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

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

பரிவர்த்தனை எவ்வாறு செயல்படுகிறது

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

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

செயலில் உள்ள பரிவர்த்தனையின் ஒரு பகுதியாக ஒரு கிளையன் தனது சொந்த மாற்றியமைக்கப்பட்ட தரவைக் கோரும்போது, ​​ஒருங்கிணைப்பாளர் பின்வருமாறு செயல்படுகிறார்:

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

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

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

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

மேலே விவரிக்கப்பட்ட மேம்பாடுகளின் விளைவாக, நாங்கள் ACID கொள்கைகளை செயல்படுத்தியுள்ளோம்:

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

குறியீடுகள் மூலம் படித்தல்

ஒரு எளிய அட்டவணையை எடுத்துக் கொள்வோம்:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

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

SELECT *
WHERE owner=?
AND modified>?

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

சி*ஒனில் உள்ள குறியீடுகள்

பதிவு ஐடி முதன்மை விசையாக இருக்கும் புகைப்படங்களுடன் ஆரம்ப அட்டவணை உள்ளது.

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

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

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

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

என்ன நடந்தது

நாங்கள் மூன்று ஆண்டுகளுக்கு முன்பு சி*ஒனை உருவாக்கி அதை வணிக ரீதியாக இயக்கினோம்.

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

பிரதி காரணி = 1 உடன் SQL ஐப் பயன்படுத்தியபோது (ஆனால் RAID 10 இல்), ஃபோட்டோ மெட்டா தகவல் 32 மைக்ரோசாஃப்ட் SQL சர்வர் இயந்திரங்களின் (கூடுதலாக 11 உதிரிபாகங்கள்) மிகவும் கிடைக்கக்கூடிய கிளஸ்டரில் சேமிக்கப்பட்டது. மேலும், காப்புப்பிரதிகளை சேமிப்பதற்காக 10 சர்வர்கள் ஒதுக்கப்பட்டன. மொத்தம் 50 விலை உயர்ந்த கார்கள். அதே நேரத்தில், கணினி ஒரு விளிம்பு இல்லாமல் மதிப்பிடப்பட்ட சுமையில் வேலை செய்தது.

ஒரு புதிய அமைப்பிற்கு இடம்பெயர்ந்த பிறகு, பிரதி காரணி = 3 - ஒவ்வொரு தரவு மையத்திலும் ஒரு நகல் கிடைத்தது. கணினி 63 கசாண்ட்ரா சேமிப்பக முனைகள் மற்றும் 6 ஒருங்கிணைப்பாளர் இயந்திரங்களைக் கொண்டுள்ளது, மொத்தம் 69 சேவையகங்கள். ஆனால் இந்த இயந்திரங்கள் மிகவும் மலிவானவை, மொத்தமாக ஒரு SQL அமைப்பின் விலையில் 30% ஆகும். இந்த வழக்கில், சுமை 30% அளவில் வைக்கப்படுகிறது.

C*Oன் அறிமுகத்துடன், தாமதமும் குறைந்தது: SQL இல், எழுதும் செயல்பாடு சுமார் 4,5 எம்எஸ் எடுத்தது. சி * ஒன்றில் - சுமார் 1,6 எம்.எஸ். ஒரு பரிவர்த்தனையின் கால அளவு சராசரியாக 40 ms க்கும் குறைவாக உள்ளது, உறுதிமொழி 2 ms இல் நிறைவடைகிறது, படிக்கும் மற்றும் எழுதும் காலம் சராசரியாக 2 ms ஆகும். 99வது சதவிகிதம் 3-3,1 எம்எஸ் மட்டுமே, காலக்கெடுவின் எண்ணிக்கை 100 மடங்கு குறைந்துள்ளது - இவை அனைத்தும் ஊகங்களின் பரவலான பயன்பாட்டின் காரணமாக.

இன்றுவரை, பெரும்பாலான SQL சர்வர் முனைகள் நீக்கப்பட்டுள்ளன, புதிய தயாரிப்புகள் C * One ஐப் பயன்படுத்தி மட்டுமே உருவாக்கப்படுகின்றன. எங்கள் கிளவுட்டில் வேலை செய்ய C*Oனை மாற்றியமைத்தோம் ஒரு மேகம், இது புதிய கிளஸ்டர்களின் வரிசைப்படுத்தலை விரைவுபடுத்தவும், உள்ளமைவை எளிதாக்கவும் மற்றும் செயல்பாட்டை தானியங்குபடுத்தவும் சாத்தியமாக்கியது. மூலக் குறியீடு இல்லாவிட்டால், இது மிகவும் கடினமானதாக இருக்கும்.

இப்போது எங்கள் மற்ற சேமிப்பகங்களை மேகக்கணிக்கு மாற்றும் பணியில் ஈடுபட்டுள்ளோம் - ஆனால் அது முற்றிலும் மாறுபட்ட கதை.

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