தரவுத்தளங்கள் குபெர்னெட்ஸில் வாழ்கின்றனவா?

எப்படியோ, வரலாற்று ரீதியாக, IT தொழில் எந்த காரணத்திற்காகவும் இரண்டு நிபந்தனை முகாம்களாக பிரிக்கப்பட்டுள்ளது: "அதற்காக" இருப்பவர்கள் மற்றும் "எதிராக" இருப்பவர்கள். மேலும், சர்ச்சைகளின் பொருள் முற்றிலும் தன்னிச்சையாக இருக்கலாம். எந்த OS சிறந்தது: Win அல்லது Linux? Android அல்லது iOS ஸ்மார்ட்போனில் உள்ளதா? நீங்கள் எல்லாவற்றையும் மேகங்களில் சேமித்து வைக்க வேண்டுமா அல்லது குளிர்ந்த RAID சேமிப்பகத்தில் வைத்து திருகுகளை பாதுகாப்பாக வைக்க வேண்டுமா? PHP நபர்களுக்கு புரோகிராமர்கள் என்று அழைக்க உரிமை உள்ளதா? இந்த சர்ச்சைகள், சில சமயங்களில், இயற்கையில் பிரத்தியேகமாக இருத்தலுக்கானவை மற்றும் விளையாட்டு ஆர்வத்தைத் தவிர வேறு எந்த அடிப்படையும் இல்லை.

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

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

பிரகாசமான பக்கம்

லைட் சைட்டின் வாதத்தை ஒரு சொற்றொடரில் சுருக்கமாக விவரிக்கலாம்: "ஹலோ, 2k19 சாளரத்திற்கு வெளியே உள்ளது!" இது ஜனரஞ்சகமாகத் தெரிகிறது, ஆனால் நீங்கள் நிலைமையை விரிவாக ஆராய்ந்தால், அதன் நன்மைகள் உள்ளன. இப்போது அவற்றை வரிசைப்படுத்துவோம்.

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

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

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

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

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

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

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

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

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

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

இப்போது தரவுத்தள கிளஸ்டரிங் எதிர்ப்பாளர்களாக மாற வேண்டிய நேரம் இது.

இருண்ட பக்கம்

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

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

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

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

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

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

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

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

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

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

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

வெளியீட்டிற்கு பதிலாக

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

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

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