வாழ்க்கையில் எல்லாவற்றையும் ஒரு முறையாவது முயற்சி செய்வது மதிப்புக்குரியது என்று அவர்கள் கூறுகிறார்கள். நீங்கள் தொடர்புடைய DBMS களுடன் பணிபுரியப் பழகினால், நடைமுறையில் NoSQL உடன் பழகுவது மதிப்பு, முதலில், குறைந்தபட்சம் பொது வளர்ச்சிக்காக. இப்போது, இந்த தொழில்நுட்பத்தின் விரைவான வளர்ச்சியின் காரணமாக, இந்த தலைப்பில் நிறைய முரண்பட்ட கருத்துக்கள் மற்றும் சூடான விவாதங்கள் உள்ளன, இது குறிப்பாக ஆர்வத்தை தூண்டுகிறது.
இந்த அனைத்து சர்ச்சைகளின் சாராம்சத்தை நீங்கள் ஆராய்ந்தால், அவை தவறான அணுகுமுறையால் எழுவதை நீங்கள் காணலாம். NoSQL தரவுத்தளங்களைத் தேவையான இடங்களில் பயன்படுத்துபவர்கள் திருப்தியடைந்து இந்தத் தீர்விலிருந்து அனைத்து நன்மைகளையும் பெறுகிறார்கள். இந்த தொழில்நுட்பத்தை ஒரு சஞ்சீவியாக நம்பியிருக்கும் சோதனையாளர்கள், இது பொருந்தாது, குறிப்பிடத்தக்க பலன்களைப் பெறாமல் தொடர்புடைய தரவுத்தளங்களின் வலிமையை இழந்து ஏமாற்றமடைகின்றனர்.
கசாண்ட்ரா டிபிஎம்எஸ் அடிப்படையிலான தீர்வைச் செயல்படுத்துவதில் எங்களின் அனுபவத்தைப் பற்றி நான் உங்களுக்குச் சொல்கிறேன்: நாம் என்ன எதிர்கொள்ள வேண்டியிருந்தது, கடினமான சூழ்நிலைகளில் இருந்து எப்படி வெளியேறினோம், NoSQL ஐப் பயன்படுத்துவதன் மூலம் நாம் பயனடைய முடியுமா மற்றும் கூடுதல் முயற்சிகள்/நிதிகளை எங்கே முதலீடு செய்ய வேண்டும் .
சில வகையான சேமிப்பகத்தில் அழைப்புகளைப் பதிவுசெய்யும் அமைப்பை உருவாக்குவதே ஆரம்பப் பணி.
அமைப்பின் செயல்பாட்டுக் கொள்கை பின்வருமாறு. அழைப்பின் கட்டமைப்பை விவரிக்கும் ஒரு குறிப்பிட்ட கட்டமைப்பைக் கொண்ட கோப்புகளை உள்ளீடு கொண்டுள்ளது. இந்த அமைப்பு பொருத்தமான நெடுவரிசைகளில் சேமிக்கப்படுவதை பயன்பாடு உறுதி செய்கிறது. எதிர்காலத்தில், சந்தாதாரர்களுக்கு (கட்டணங்கள், அழைப்புகள், இருப்பு வரலாறு) போக்குவரத்து நுகர்வு பற்றிய தகவலைக் காட்ட சேமிக்கப்பட்ட அழைப்புகள் பயன்படுத்தப்படும்.
அவர்கள் ஏன் கசாண்ட்ராவைத் தேர்ந்தெடுத்தார்கள் என்பது தெளிவாகத் தெரிகிறது - அவள் ஒரு இயந்திர துப்பாக்கியைப் போல எழுதுகிறாள், எளிதில் அளவிடக்கூடியவள், மற்றும் தவறுகளை பொறுத்துக்கொள்ளக்கூடியவள்.
எனவே, இது நமக்கு அனுபவம் கொடுத்தது
ஆம், தோல்வியுற்ற முனை ஒரு சோகம் அல்ல. கசாண்ட்ராவின் தவறு சகிப்புத்தன்மையின் சாராம்சம் இதுதான். ஆனாலும் ஒரு முனை உயிருடன் இருக்கும் அதே நேரத்தில் செயல்திறனில் பாதிக்கப்படத் தொடங்கும். அது முடிந்தவுடன், இது முழு கிளஸ்டரின் செயல்திறனை உடனடியாக பாதிக்கிறது.
ஆரக்கிள் உங்களை அதன் கட்டுப்பாடுகளால் காப்பாற்றிய இடத்தில் கசாண்ட்ரா உங்களைப் பாதுகாக்காது. விண்ணப்பத்தின் ஆசிரியர் இதை முன்கூட்டியே புரிந்து கொள்ளவில்லை என்றால், கசாண்ட்ராவுக்கு வந்த இரட்டிப்பு அசலை விட மோசமானது அல்ல. அது வந்ததும், அதை வைப்போம்.
இலவச கசாண்ட்ராவை IB கடுமையாக விரும்பவில்லை: பயனர் செயல்களின் பதிவு இல்லை, உரிமைகள் வேறுபாடு இல்லை. அழைப்புகள் பற்றிய தகவல்கள் தனிப்பட்ட தரவுகளாகக் கருதப்படுகின்றன, அதாவது எந்த வகையிலும் அதைக் கோருவதற்கான/மாற்றுவதற்கான அனைத்து முயற்சிகளும் அடுத்தடுத்த தணிக்கையின் சாத்தியத்துடன் பதிவு செய்யப்பட வேண்டும். மேலும், வெவ்வேறு பயனர்களுக்கு வெவ்வேறு நிலைகளில் உரிமைகளைப் பிரிக்க வேண்டியதன் அவசியத்தை நீங்கள் அறிந்திருக்க வேண்டும். ஒரு எளிய செயல்பாட்டு பொறியாளர் மற்றும் முழு விசைவெளியையும் சுதந்திரமாக நீக்கக்கூடிய ஒரு சூப்பர் நிர்வாகி ஆகியோர் வெவ்வேறு பாத்திரங்கள், வெவ்வேறு பொறுப்புகள் மற்றும் திறன்கள். அணுகல் உரிமைகளில் இத்தகைய வேறுபாடு இல்லாமல், தரவின் மதிப்பு மற்றும் ஒருமைப்பாடு எந்த நிலைத்தன்மையையும் விட விரைவாக கேள்விக்குள்ளாகும்.
அழைப்புகளுக்கு தீவிர பகுப்பாய்வு மற்றும் பல்வேறு நிபந்தனைகளுக்கு அவ்வப்போது மாதிரிகள் தேவை என்பதை நாங்கள் கணக்கில் எடுத்துக்கொள்ளவில்லை. தேர்ந்தெடுக்கப்பட்ட பதிவுகள் பின்னர் நீக்கப்பட்டு மீண்டும் எழுதப்பட வேண்டும் என்பதால் (பணியின் ஒரு பகுதியாக, தரவு ஆரம்பத்தில் எங்கள் லூப்பில் தவறாக நுழைந்தபோது தரவைப் புதுப்பிக்கும் செயல்முறையை நாங்கள் ஆதரிக்க வேண்டும்), கசாண்ட்ரா இங்கே எங்கள் நண்பர் அல்ல. கசாண்ட்ரா ஒரு உண்டியலைப் போன்றது - பொருட்களை வைப்பது வசதியானது, ஆனால் நீங்கள் அதில் எண்ண முடியாது.
சோதனை மண்டலங்களுக்கு தரவை மாற்றுவதில் சிக்கலை எதிர்கொண்டோம் (சோதனையில் 5 முனைகள் மற்றும் நாட்டியத்தில் 20). இந்த வழக்கில், டம்ப் பயன்படுத்த முடியாது.
கசாண்ட்ராவிற்கு எழுதும் பயன்பாட்டின் தரவுத் திட்டத்தைப் புதுப்பிப்பதில் சிக்கல். திரும்பப் பெறுவது பல கல்லறைகளை உருவாக்கும், இது கணிக்க முடியாத வழிகளில் உற்பத்தி இழப்புகளுக்கு வழிவகுக்கும்.. கசாண்ட்ரா பதிவு செய்வதற்கு உகந்ததாக உள்ளது, மேலும் எழுதுவதற்கு முன் அதிகம் யோசிப்பதில்லை. ஏற்கனவே உள்ள தரவுகளைக் கொண்ட எந்தவொரு செயலும் ஒரு பதிவுதான். அதாவது, தேவையற்றவற்றை நீக்குவதன் மூலம், நாங்கள் இன்னும் அதிகமான பதிவுகளை உருவாக்குவோம், அவற்றில் சில மட்டுமே கல்லறைகளால் குறிக்கப்படும்.
செருகும் போது நேரம் முடிந்தது. பதிவில் கசாண்ட்ரா அழகாக இருக்கிறது, ஆனால் சில சமயங்களில் உள்வரும் ஓட்டம் அவளைக் கணிசமான அளவில் குழப்பலாம். பயன்பாடு சில காரணங்களால் செருக முடியாத பல பதிவுகளைச் சுற்றி வரத் தொடங்கும் போது இது நிகழ்கிறது. மேலும், ஜிசி.லாக், சிஸ்டம் மற்றும் பிழைத்திருத்தப் பதிவுகளை மெதுவான வினவல்கள், காம்பாக்ஷன் நிலுவையில் உள்ள அளவீடுகள் ஆகியவற்றைக் கண்காணிக்கும் உண்மையான டிபிஏ நமக்குத் தேவைப்படும்.
ஒரு கிளஸ்டரில் பல தரவு மையங்கள். எங்கிருந்து படிக்க வேண்டும், எங்கு எழுத வேண்டும்?
ஒருவேளை வாசிப்பு மற்றும் எழுதுதல் என்று பிரிந்திருக்கலாம்? அப்படியானால், எழுத அல்லது படிக்க விண்ணப்பத்திற்கு அருகில் DC இருக்க வேண்டுமா? தவறான நிலைத்தன்மையைத் தேர்ந்தெடுத்தால், உண்மையான பிளவு மூளையுடன் முடிவடையாதா? நிறைய கேள்விகள், நிறைய தெரியாத அமைப்புகள், நீங்கள் உண்மையில் டிங்கர் செய்ய விரும்பும் சாத்தியக்கூறுகள் உள்ளன.
நாங்கள் எப்படி முடிவு செய்தோம்
முனை மூழ்குவதைத் தடுக்க, SWAP முடக்கப்பட்டது. இப்போது, நினைவக குறைபாடு இருந்தால், முனை கீழே செல்ல வேண்டும் மற்றும் பெரிய gc இடைநிறுத்தங்களை உருவாக்கக்கூடாது.
எனவே, நாங்கள் இனி தரவுத்தளத்தில் தர்க்கத்தை நம்பவில்லை. அப்ளிகேஷன் டெவலப்பர்கள் தங்களைத் தாங்களே மீண்டும் பயிற்றுவித்துக் கொள்கிறார்கள் மற்றும் தங்கள் சொந்த குறியீட்டில் முன்னெச்சரிக்கை நடவடிக்கைகளை தீவிரமாக எடுக்கத் தொடங்குகின்றனர். தரவு சேமிப்பு மற்றும் செயலாக்கத்தின் சிறந்த தெளிவான பிரிப்பு.
நாங்கள் DataStax இலிருந்து ஆதரவை வாங்கினோம். பெட்டி கசாண்ட்ராவின் வளர்ச்சி ஏற்கனவே நிறுத்தப்பட்டுள்ளது (கடைசியாக பிப்ரவரி 2018 இல் இருந்தது). அதே நேரத்தில், டேட்டாஸ்டாக்ஸ் சிறந்த சேவையை வழங்குகிறது மற்றும் ஏற்கனவே உள்ள ஐபி தீர்வுகளுக்கு அதிக எண்ணிக்கையிலான மாற்றியமைக்கப்பட்ட மற்றும் மாற்றியமைக்கப்பட்ட தீர்வுகளை வழங்குகிறது.
தேர்வு வினவல்களுக்கு கசாண்ட்ரா மிகவும் வசதியானது அல்ல என்பதையும் நான் கவனிக்க விரும்புகிறேன். நிச்சயமாக, CQL என்பது பயனர்களுக்கு ஒரு பெரிய படியாகும் (Trift உடன் ஒப்பிடும்போது). ஆனால் இதுபோன்ற வசதியான இணைப்புகளுக்குப் பழக்கப்பட்ட முழுத் துறைகளும் உங்களிடம் இருந்தால், எந்தத் துறையிலும் இலவச வடிகட்டுதல் மற்றும் வினவல் தேர்வுமுறை திறன்கள் மற்றும் இந்தத் துறைகள் புகார்கள் மற்றும் விபத்துகளைத் தீர்க்கும் பணியில் ஈடுபட்டிருந்தால், கசாண்ட்ராவின் தீர்வு அவர்களுக்கு விரோதமாகவும் முட்டாள்தனமாகவும் தெரிகிறது. எங்கள் சகாக்கள் மாதிரிகளை எவ்வாறு உருவாக்க வேண்டும் என்பதை நாங்கள் தீர்மானிக்க ஆரம்பித்தோம்.
நாங்கள் இரண்டு விருப்பங்களைக் கருத்தில் கொண்டோம். முதல் விருப்பத்தில், C* இல் மட்டுமல்ல, காப்பகப்படுத்தப்பட்ட Oracle தரவுத்தளத்திலும் அழைப்புகளை எழுதுகிறோம். C* போலல்லாமல், இந்த தரவுத்தளம் நடப்பு மாதத்திற்கான அழைப்புகளை மட்டுமே சேமிக்கிறது (கேஸ்களை ரீசார்ஜ் செய்வதற்கு போதுமான அழைப்பு சேமிப்பு ஆழம்). இங்கே நாம் உடனடியாக பின்வரும் சிக்கலைக் கண்டோம்: நாம் ஒத்திசைவாக எழுதினால், விரைவான செருகலுடன் தொடர்புடைய C* இன் அனைத்து நன்மைகளையும் இழக்கிறோம்; நாம் ஒத்திசைவற்ற முறையில் எழுதினால், தேவையான அனைத்து அழைப்புகளும் ஆரக்கிளில் கிடைத்தன என்பதற்கு எந்த உத்தரவாதமும் இல்லை. ஒரு பிளஸ் இருந்தது, ஆனால் பெரியது: செயல்பாட்டிற்கு அதே பரிச்சயமான PL/SQL டெவலப்பர் உள்ளது, அதாவது "முகப்பு" வடிவத்தை நடைமுறையில் செயல்படுத்துகிறோம். மாற்று விருப்பம். C* இலிருந்து அழைப்புகளை இறக்கி, ஆரக்கிளில் உள்ள தொடர்புடைய அட்டவணையில் இருந்து செறிவூட்டலுக்காக சில தரவை இழுத்து, அதன் விளைவாக வரும் மாதிரிகளை இணைத்து, முடிவை நமக்குத் தருகின்ற ஒரு பொறிமுறையை நாங்கள் செயல்படுத்துகிறோம், அதை நாங்கள் எப்படியாவது பயன்படுத்துவோம் (பின்னோக்கிச் செல்லுங்கள், மீண்டும் செய்யவும், பகுப்பாய்வு செய்யவும், பாராட்டவும்). பாதகம்: செயல்முறை மிகவும் பல படிகள், கூடுதலாக, செயல்பாட்டு ஊழியர்களுக்கு இடைமுகம் இல்லை.
இறுதியில், நாங்கள் இரண்டாவது விருப்பத்தைத் தீர்த்தோம். அப்பாச்சி ஸ்பார்க் வெவ்வேறு ஜாடிகளில் இருந்து மாதிரியாக பயன்படுத்தப்பட்டது. பொறிமுறையின் சாராம்சம் ஜாவா குறியீடாகக் குறைக்கப்பட்டது, இது குறிப்பிட்ட விசைகளைப் பயன்படுத்தி (சந்தாதாரர், அழைப்பின் நேரம் - பிரிவு விசைகள்), C* இலிருந்து தரவை வெளியே இழுக்கிறது, அத்துடன் வேறு எந்த தரவுத்தளத்திலிருந்தும் செறிவூட்டுவதற்குத் தேவையான தரவு. அதன் பிறகு அது அவற்றை அதன் நினைவகத்தில் இணைத்து அதன் விளைவாக வரும் அட்டவணையில் முடிவைக் காண்பிக்கும். தீப்பொறியின் மேல் ஒரு வலை முகத்தை வரைந்தோம், அது மிகவும் பயன்படுத்தக்கூடியதாக மாறியது.
தொழில்துறை சோதனைத் தரவைப் புதுப்பிப்பதில் சிக்கலைத் தீர்க்கும்போது, நாங்கள் மீண்டும் பல தீர்வுகளைக் கருத்தில் கொண்டோம். Sstloader வழியாக பரிமாற்றம் மற்றும் சோதனை மண்டலத்தில் உள்ள கிளஸ்டரை இரண்டு பகுதிகளாகப் பிரிப்பதற்கான விருப்பம் ஆகிய இரண்டும், ஒவ்வொன்றும் மாறி மாறி ஒரே கிளஸ்டரை விளம்பரத்துடன் இணைக்கும், இதனால் இயக்கப்படுகிறது. சோதனையைப் புதுப்பிக்கும்போது, அவற்றை மாற்றுவதற்கு திட்டமிடப்பட்டது: சோதனையில் பணிபுரிந்த பகுதி அழிக்கப்பட்டு உற்பத்தியில் நுழைந்தது, மற்றொன்று தரவுகளுடன் தனித்தனியாக வேலை செய்யத் தொடங்குகிறது. எவ்வாறாயினும், மீண்டும் யோசித்த பிறகு, பரிமாற்றத் தகுந்த தரவை நாங்கள் மிகவும் பகுத்தறிவுடன் மதிப்பிட்டோம், மேலும் அழைப்புகள் சோதனைகளுக்கு ஒரு சீரற்ற நிறுவனம் என்பதை உணர்ந்தோம், தேவைப்பட்டால் விரைவாக உருவாக்கப்படும், மேலும் இது விளம்பரத் தரவுத் தொகுப்பாகும். சோதனை. நகரும் மதிப்புள்ள பல சேமிப்பக பொருள்கள் உள்ளன, ஆனால் இவை உண்மையில் இரண்டு அட்டவணைகள், மற்றும் மிகவும் கனமானவை அல்ல. எனவே நாம் ஒரு தீர்வாக, ஸ்பார்க் மீண்டும் மீட்புக்கு வந்தது, அதன் உதவியுடன் நாங்கள் எழுதினோம் மற்றும் அட்டவணைகள், ப்ரோம்-டெஸ்ட் இடையே தரவை மாற்றுவதற்கு ஒரு ஸ்கிரிப்டை தீவிரமாக பயன்படுத்த ஆரம்பித்தோம்.
எங்களின் தற்போதைய வரிசைப்படுத்தல் கொள்கையானது, பின்வாங்கல்கள் இல்லாமல் வேலை செய்ய அனுமதிக்கிறது. விளம்பரத்திற்கு முன், ஒரு கட்டாய சோதனை ஓட்டம் உள்ளது, அங்கு ஒரு தவறு மிகவும் விலை உயர்ந்ததல்ல. தோல்வியுற்றால், நீங்கள் எப்பொழுதும் கேஸ்பேஸை கைவிட்டு, முழு திட்டத்தையும் ஆரம்பத்தில் இருந்தே உருட்டலாம்.
கசாண்ட்ரா தொடர்ந்து கிடைப்பதை உறுதி செய்ய, உங்களுக்கு ஒரு டிபிஏ தேவை, அது மட்டுமல்ல. பயன்பாட்டுடன் பணிபுரியும் ஒவ்வொருவரும் தற்போதைய சூழ்நிலையை எங்கு, எப்படிப் பார்ப்பது மற்றும் சரியான நேரத்தில் சிக்கல்களைக் கண்டறிவது எப்படி என்பதைப் புரிந்து கொள்ள வேண்டும். இதைச் செய்ய, நாங்கள் DataStax OpsCenter (பணிச்சுமைகளின் நிர்வாகம் மற்றும் கண்காணிப்பு), கசாண்ட்ரா டிரைவர் சிஸ்டம் அளவீடுகள் (C* க்கு எழுதுவதற்கான காலக்கெடுவின் எண்ணிக்கை, C* இலிருந்து படிக்கும் காலக்கெடுவின் எண்ணிக்கை, அதிகபட்ச தாமதம் போன்றவை) செயல்பாட்டைக் கண்காணிக்கவும். பயன்பாடு தன்னை, கசாண்ட்ரா வேலை.
முந்தைய கேள்வியைப் பற்றி யோசித்தபோது, எங்கள் முக்கிய ஆபத்து எங்குள்ளது என்பதை நாங்கள் உணர்ந்தோம். இவை பல சுயாதீன வினவல்களிலிருந்து சேமிப்பகத்திற்கு தரவைக் காண்பிக்கும் தரவு காட்சி வடிவங்கள். இந்த வழியில் நாம் மிகவும் சீரற்ற தகவல்களை பெற முடியும். ஆனால் நாம் ஒரே ஒரு தரவு மையத்தில் பணிபுரிந்தால் இந்த சிக்கல் மிகவும் பொருத்தமானதாக இருக்கும். எனவே இங்கே மிகவும் நியாயமான விஷயம், நிச்சயமாக, மூன்றாம் தரப்பு பயன்பாட்டில் தரவைப் படிக்க ஒரு தொகுதி செயல்பாட்டை உருவாக்குவது, இது ஒரு குறிப்பிட்ட காலப்பகுதியில் தரவு பெறப்படுவதை உறுதி செய்யும். செயல்திறன் அடிப்படையில் வாசிப்பு மற்றும் எழுதுதல் பிரிவைப் பொறுத்தவரை, DC களுக்கு இடையில் சில இணைப்பு இழப்புடன், ஒருவருக்கொருவர் முற்றிலும் பொருந்தாத இரண்டு கிளஸ்டர்களுடன் முடிவடையும் அபாயத்தால் நாங்கள் நிறுத்தப்பட்டோம்.
இதன் விளைவாக, இப்போதைக்கு EACH_QUORUM எழுதுவதற்கு நிலைத்தன்மை நிலையில் நிறுத்தப்பட்டது, படிக்க - LOCAL_QUORUM
சுருக்கமான பதிவுகள் மற்றும் முடிவுகள்
செயல்பாட்டு ஆதரவு மற்றும் மேலும் வளர்ச்சிக்கான வாய்ப்புகள் ஆகியவற்றின் பார்வையில் இருந்து விளைந்த தீர்வை மதிப்பீடு செய்வதற்காக, அத்தகைய வளர்ச்சியை வேறு எங்கு பயன்படுத்தலாம் என்பதைப் பற்றி சிந்திக்க முடிவு செய்தோம்.
மட்டையிலிருந்து வெளியேறி, பின்னர் "வசதியாக இருக்கும்போது பணம் செலுத்துங்கள்" (சி*யில் தகவலை ஏற்றுகிறோம், ஸ்பார்க் ஸ்கிரிப்ட்களைப் பயன்படுத்தி கணக்கீடு செய்கிறோம்), பகுதி வாரியாக ஒருங்கிணைத்து உரிமைகோரல்களைக் கணக்கிட்டல், பாத்திரங்களைச் சேமித்தல் மற்றும் பங்கின் அடிப்படையில் பயனர் அணுகல் உரிமைகளைக் கணக்கிடுதல் போன்ற நிரல்களுக்கான டேட்டா ஸ்கோரிங் அணி
நீங்கள் பார்க்க முடியும் என, திறமை பரந்த மற்றும் மாறுபட்டது. NoSQL இன் ஆதரவாளர்கள்/எதிர்ப்பாளர்களின் முகாமை நாங்கள் தேர்வுசெய்தால், நாங்கள் எங்கள் நன்மைகளைப் பெற்றதால், நாங்கள் எதிர்பார்த்த இடத்திலேயே ஆதரவாளர்களுடன் இணைவோம்.
பெட்டிக்கு வெளியே உள்ள கசாண்ட்ரா விருப்பம் கூட நிகழ்நேரத்தில் கிடைமட்ட அளவிடுதலை அனுமதிக்கிறது, கணினியில் தரவு அதிகரிக்கும் சிக்கலை முற்றிலும் வலியின்றி தீர்க்கிறது. தனித்தனி சர்க்யூட்டில் அழைப்புத் தொகுப்புகளைக் கணக்கிடுவதற்கான மிக அதிக-சுமை பொறிமுறையை நகர்த்த முடிந்தது, மேலும் பயன்பாட்டுத் திட்டம் மற்றும் தர்க்கத்தைப் பிரித்து, தனிப்பயன் வேலைகள் மற்றும் பொருள்களை தரவுத்தளத்திலேயே எழுதும் மோசமான நடைமுறையிலிருந்து விடுபட முடிந்தது. தேர்வுசெய்து கட்டமைக்க, வேகப்படுத்த, எந்த டிசிகளில் கணக்கீடுகளைச் செய்வோம், எந்தெந்தவற்றில் தரவைப் பதிவுசெய்வோம் என்பதைத் தேர்வுசெய்து கட்டமைக்க வாய்ப்பு கிடைத்தது.
புதிய திட்டங்களுக்கு எங்கள் கட்டிடக்கலையைப் பயன்படுத்துதல் மற்றும் ஏற்கனவே சில அனுபவங்கள் இருப்பதால், மேலே விவரிக்கப்பட்ட நுணுக்கங்களை உடனடியாக கணக்கில் எடுத்துக்கொள்ளவும், சில தவறுகளைத் தடுக்கவும், ஆரம்பத்தில் தவிர்க்க முடியாத சில கூர்மையான மூலைகளை மென்மையாக்கவும் விரும்புகிறேன்.
உதாரணமாக, கசாண்ட்ராவின் புதுப்பிப்புகளை சரியான நேரத்தில் கண்காணிக்கவும்ஏனெனில் எமக்குக் கிடைத்த சில பிரச்சனைகள் ஏற்கனவே அறியப்பட்டு சரி செய்யப்பட்டுள்ளன.
டேட்டாபேஸ் மற்றும் ஸ்பார்க் இரண்டையும் ஒரே முனைகளில் வைக்க வேண்டாம் (அல்லது அனுமதிக்கக்கூடிய ஆதாரப் பயன்பாட்டின் அளவைக் கொண்டு கண்டிப்பாகப் பிரிக்கவும்), ஏனெனில் ஸ்பார்க் எதிர்பார்த்ததை விட அதிகமான OP ஐ உண்ண முடியும், மேலும் எங்கள் பட்டியலில் இருந்து சிக்கல் எண் 1 ஐ விரைவாகப் பெறுவோம்.
திட்ட சோதனை கட்டத்தில் கண்காணிப்பு மற்றும் செயல்பாட்டுத் திறனை மேம்படுத்துதல். ஆரம்பத்தில், எங்கள் தீர்வின் சாத்தியமான அனைத்து நுகர்வோரையும் முடிந்தவரை கணக்கில் எடுத்துக் கொள்ளுங்கள், ஏனெனில் இதுவே தரவுத்தள அமைப்பு இறுதியில் சார்ந்திருக்கும்.
சாத்தியமான தேர்வுமுறைக்கு பல முறை விளைவாக சுற்று சுழற்று. எந்தெந்த புலங்களை வரிசைப்படுத்தலாம் என்பதைத் தேர்ந்தெடுக்கவும். மிகவும் சரியாகவும், உகந்ததாகவும் கணக்கில் எடுத்துக்கொள்வதற்கு என்ன கூடுதல் அட்டவணைகளை உருவாக்க வேண்டும் என்பதைப் புரிந்துகொண்டு, கோரிக்கையின் பேரில் தேவையான தகவலை வழங்க வேண்டும் (உதாரணமாக, ஒரே தரவை வெவ்வேறு அட்டவணைகளில் சேமிக்க முடியும் என்று கருதி, வெவ்வேறு முறிவுகளை கணக்கில் எடுத்துக்கொள்கிறோம். வெவ்வேறு அளவுகோல்கள், வாசிப்பு கோரிக்கைகளுக்கான CPU நேரத்தை கணிசமாக சேமிக்க முடியும்).
மோசமாக இல்லை TTL ஐ இணைப்பதற்கும் காலாவதியான தரவை சுத்தம் செய்வதற்கும் உடனடியாக வழங்கவும்.
கசாண்ட்ராவிலிருந்து தரவைப் பதிவிறக்கும் போது பயன்பாட்டு தர்க்கம் FETCH கொள்கையில் செயல்பட வேண்டும், இதனால் அனைத்து வரிசைகளும் ஒரே நேரத்தில் நினைவகத்தில் ஏற்றப்படாது, ஆனால் அவை தொகுதிகளாக தேர்ந்தெடுக்கப்படுகின்றன.
விவரிக்கப்பட்ட தீர்வுக்கு திட்டத்தை மாற்றுவதற்கு முன் இது அறிவுறுத்தப்படுகிறது தொடர்ச்சியான செயலிழப்பு சோதனைகளை நடத்துவதன் மூலம் கணினியின் தவறு சகிப்புத்தன்மையை சரிபார்க்கவும், ஒரு தரவு மையத்தில் தரவு இழப்பு, ஒரு குறிப்பிட்ட காலப்பகுதியில் சேதமடைந்த தரவை மீட்டமைத்தல், தரவு மையங்களுக்கு இடையில் நெட்வொர்க் கைவிடுதல் போன்றவை. இத்தகைய சோதனைகள் முன்மொழியப்பட்ட கட்டிடக்கலையின் நன்மை தீமைகளை மதிப்பீடு செய்ய அனுமதிக்கும், ஆனால் அவற்றை நடத்தும் பொறியாளர்களுக்கு நல்ல வெப்பமூட்டும் பயிற்சியை வழங்கும், மேலும் உற்பத்தியில் கணினி தோல்விகள் மீண்டும் உருவாக்கப்பட்டால் பெறப்பட்ட திறன் மிதமிஞ்சியதாக இருக்காது.
முக்கியமான தகவலுடன் (பில்லிங்கிற்கான தரவு, சந்தாதாரர் கடனைக் கணக்கிடுதல் போன்றவை) நாங்கள் பணிபுரிந்தால், DBMS இன் அம்சங்களால் ஏற்படும் அபாயங்களைக் குறைக்கும் கருவிகளிலும் கவனம் செலுத்துவது மதிப்பு. எடுத்துக்காட்டாக, nodesync பயன்பாட்டை (Datastax) பயன்படுத்தவும், அதன் பயன்பாட்டிற்கான உகந்த உத்தியை வரிசையாக உருவாக்கி நிலைத்தன்மைக்காக, கசாண்ட்ராவில் அதிக சுமையை உருவாக்க வேண்டாம் ஒரு குறிப்பிட்ட காலப்பகுதியில் குறிப்பிட்ட அட்டவணைகளுக்கு மட்டுமே இதைப் பயன்படுத்தவும்.
ஆறு மாத வாழ்க்கைக்குப் பிறகு கசாண்ட்ராவுக்கு என்ன நடக்கும்? பொதுவாக, தீர்க்கப்படாத பிரச்சினைகள் எதுவும் இல்லை. கடுமையான விபத்துக்கள் அல்லது தரவு இழப்பை நாங்கள் அனுமதிக்கவில்லை. ஆம், முன்னர் எழாத சில சிக்கல்களுக்கு ஈடுசெய்வது பற்றி நாங்கள் சிந்திக்க வேண்டியிருந்தது, ஆனால் இறுதியில் இது எங்கள் கட்டடக்கலை தீர்வை பெரிதும் மறைக்கவில்லை. நீங்கள் விரும்பினால் மற்றும் புதிதாக ஒன்றை முயற்சிக்க பயப்படாவிட்டால், அதே நேரத்தில் மிகவும் ஏமாற்றமடைய விரும்பவில்லை என்றால், எதுவும் இலவசம் இல்லை என்பதற்கு தயாராகுங்கள். நீங்கள் புரிந்து கொள்ள வேண்டும், ஆவணங்களை ஆராய்ந்து, பழைய பாரம்பரிய தீர்வை விட உங்கள் சொந்த தனிப்பட்ட ரேக்கை இணைக்க வேண்டும், மேலும் எந்த ரேக் உங்களுக்காக காத்திருக்கிறது என்பதை எந்த கோட்பாடும் உங்களுக்கு முன்கூட்டியே சொல்லாது.
ஆதாரம்: www.habr.com