வணக்கம், கப்ரோவ்ஸ்க் குடியிருப்பாளர்கள். பாடத்தின் முதல் குழுவிற்கான வகுப்புகள் இன்று தொடங்குகின்றன . இது சம்பந்தமாக, இந்த பாடத்திட்டத்தில் திறந்த வலையமைப்பு எவ்வாறு நடந்தது என்பதைப் பற்றி நாங்கள் உங்களுக்கு சொல்ல விரும்புகிறோம்.
В மேகங்கள் மற்றும் குபெர்னெட்டுகளின் சகாப்தத்தில் SQL தரவுத்தளங்கள் எதிர்கொள்ளும் சவால்களைப் பற்றி நாங்கள் பேசினோம். அதே நேரத்தில், இந்த சவால்களின் செல்வாக்கின் கீழ் SQL தரவுத்தளங்கள் எவ்வாறு மாற்றியமைக்கப்படுகின்றன மற்றும் மாற்றப்படுகின்றன என்பதைப் பார்த்தோம்.
வலைப்பூ நடைபெற்றது , EPAM சிஸ்டத்தில் Google Cloud Practice Delivery Manager.
மரங்கள் சிறியதாக இருந்த போது...
முதலில், கடந்த நூற்றாண்டின் இறுதியில் DBMS இன் தேர்வு எவ்வாறு தொடங்கியது என்பதை நினைவில் கொள்வோம். இருப்பினும், இது கடினமாக இருக்காது, ஏனென்றால் அந்த நாட்களில் டிபிஎம்எஸ் தேர்வு தொடங்கியது மற்றும் முடிந்தது Oracle .
90 களின் பிற்பகுதியிலும் 2 களின் முற்பகுதியிலும், தொழில்துறை அளவிடக்கூடிய தரவுத்தளங்களுக்கு வரும்போது அடிப்படையில் வேறு வழியில்லை. ஆம், ஐபிஎம் டிபிXNUMX, சைபேஸ் மற்றும் வேறு சில தரவுத்தளங்கள் வந்து சென்றன, ஆனால் பொதுவாக அவை ஆரக்கிளின் பின்னணியில் அவ்வளவு கவனிக்கப்படவில்லை. அதன்படி, அந்தக் கால பொறியாளர்களின் திறன்கள் எப்படியோ இருந்த ஒரே தேர்வோடு பிணைக்கப்பட்டன.
ஆரக்கிள் DBA செய்ய வேண்டியது:
- விநியோக தொகுப்பிலிருந்து ஆரக்கிள் சேவையகத்தை நிறுவவும்;
- ஆரக்கிள் சேவையகத்தை உள்ளமைக்கவும்:
- init.ora;
- கேட்பவர்.ஓரா;
- உருவாக்க:
- மேஜை இடைவெளிகள்;
- திட்டம்;
- பயனர்கள்;
- காப்புப்பிரதி மற்றும் மீட்டமைத்தல்;
- கண்காணிப்பை மேற்கொள்ளுங்கள்;
- துணை கோரிக்கைகளை கையாளவும்.
அதே நேரத்தில், Oracle DBA இலிருந்து சிறப்புத் தேவை எதுவும் இல்லை:
- தரவைச் சேமிப்பதற்கும் செயலாக்குவதற்கும் உகந்த DBMS அல்லது பிற தொழில்நுட்பத்தைத் தேர்வுசெய்ய முடியும்;
- அதிக கிடைக்கும் தன்மை மற்றும் கிடைமட்ட அளவிடுதல் (இது எப்போதும் ஒரு DBA பிரச்சினை அல்ல);
- பொருள் பகுதி, உள்கட்டமைப்பு, பயன்பாட்டு கட்டமைப்பு, OS பற்றிய நல்ல அறிவு;
- தரவை ஏற்றவும் இறக்கவும், வெவ்வேறு DBMS களுக்கு இடையில் தரவை நகர்த்தவும்.
பொதுவாக, அந்த நாட்களில் தேர்வைப் பற்றி பேசினால், அது 80 களின் பிற்பகுதியில் சோவியத் கடையில் உள்ள தேர்வை ஒத்திருக்கிறது:
எங்கள் நேரம்
அப்போதிருந்து, நிச்சயமாக, மரங்கள் வளர்ந்துள்ளன, உலகம் மாறிவிட்டது, அது இப்படி ஆனது:
DBMS சந்தையும் மாறிவிட்டது, கார்ட்னரின் சமீபத்திய அறிக்கையிலிருந்து தெளிவாகக் காணலாம்:
மேகங்கள், அதன் புகழ் வளர்ந்து வருகிறது, அவற்றின் முக்கிய இடத்தை ஆக்கிரமித்துள்ளன என்பதை இங்கே கவனத்தில் கொள்ள வேண்டும். அதே கார்ட்னர் அறிக்கையைப் படித்தால், பின்வரும் முடிவுகளைப் பார்ப்போம்:
- பல வாடிக்கையாளர்கள் மேகக்கணிக்கு பயன்பாடுகளை நகர்த்துவதற்கான பாதையில் உள்ளனர்.
- புதிய தொழில்நுட்பங்கள் முதலில் மேகக்கணியில் தோன்றுகின்றன, அவை எப்போதும் கிளவுட் அல்லாத உள்கட்டமைப்புக்கு நகரும் என்பது உண்மையல்ல.
- பணம் செலுத்தி விலை நிர்ணயம் செய்வது சாதாரணமாகிவிட்டது. எல்லோரும் தாங்கள் பயன்படுத்துவதற்கு மட்டுமே பணம் செலுத்த விரும்புகிறார்கள், இது ஒரு போக்கு கூட அல்ல, ஆனால் உண்மையில் ஒரு அறிக்கை.
இப்பொழுது என்ன?
இன்று நாம் அனைவரும் மேகத்தில் இருக்கிறோம். மேலும் நமக்கு எழும் கேள்விகள் விருப்பமான கேள்விகள். வளாகத்தில் உள்ள வடிவமைப்பில் DBMS தொழில்நுட்பங்களின் தேர்வு பற்றி மட்டுமே பேசினாலும், அது மிகப்பெரியது. எங்களிடம் சேவைகள் மற்றும் SaaS ஆகியவற்றையும் நிர்வகிக்கிறோம். எனவே, ஒவ்வொரு ஆண்டும் தேர்வு மிகவும் கடினமாகிறது.
தேர்வு கேள்விகளுடன், உள்ளன கட்டுப்படுத்தும் காரணிகள்:
- விலை. பல தொழில்நுட்பங்கள் இன்னும் பணம் செலவழிக்கின்றன;
- திறன்கள். நாம் கட்டற்ற மென்பொருளைப் பற்றி பேசினால், திறன்கள் பற்றிய கேள்வி எழுகிறது, ஏனெனில் இலவச மென்பொருளுக்கு அதை வரிசைப்படுத்தி இயக்கும் நபர்களிடமிருந்து போதுமான திறன் தேவைப்படுகிறது;
- செயல்பாட்டு. கிளவுட்டில் கிடைக்கும் மற்றும் கட்டமைக்கப்பட்ட அனைத்து சேவைகளும், அதே Postgres இல் கூட, Postgres On-premises போன்ற அம்சங்களைக் கொண்டிருக்கவில்லை. இது தெரிந்து கொள்ள வேண்டிய மற்றும் புரிந்து கொள்ள வேண்டிய ஒரு முக்கிய காரணியாகும். மேலும், இந்த காரணி ஒரு DBMS இன் சில மறைக்கப்பட்ட திறன்களைப் பற்றிய அறிவை விட முக்கியமானது.
DA/DE இலிருந்து இப்போது என்ன எதிர்பார்க்கப்படுகிறது:
- பொருள் பகுதி மற்றும் பயன்பாட்டு கட்டமைப்பு பற்றிய நல்ல புரிதல்;
- கையில் உள்ள பணியை கணக்கில் எடுத்துக்கொண்டு, பொருத்தமான டிபிஎம்எஸ் தொழில்நுட்பத்தை சரியாக தேர்ந்தெடுக்கும் திறன்;
- ஏற்கனவே உள்ள வரம்புகளின் பின்னணியில் தேர்ந்தெடுக்கப்பட்ட தொழில்நுட்பத்தை செயல்படுத்துவதற்கான உகந்த முறையைத் தேர்ந்தெடுக்கும் திறன்;
- தரவு பரிமாற்றம் மற்றும் இடம்பெயர்வு செய்யும் திறன்;
- தேர்ந்தெடுக்கப்பட்ட தீர்வுகளை செயல்படுத்த மற்றும் செயல்படுத்தும் திறன்.
கீழே உதாரணம் GCP அடிப்படையில் தரவுகளுடன் வேலை செய்வதற்கான ஒன்று அல்லது மற்றொரு தொழில்நுட்பத்தின் தேர்வு அதன் கட்டமைப்பைப் பொறுத்து எவ்வாறு செயல்படுகிறது என்பதை நிரூபிக்கிறது:
PostgreSQL திட்டத்தில் சேர்க்கப்படவில்லை என்பதை நினைவில் கொள்ளவும், மேலும் இது சொற்களஞ்சியத்தின் கீழ் மறைக்கப்பட்டுள்ளது கிளவுட் SQL. நாங்கள் கிளவுட் SQL க்கு வரும்போது, மீண்டும் ஒரு தேர்வு செய்ய வேண்டும்:
இந்த தேர்வு எப்போதும் தெளிவாக இல்லை என்பதை கவனத்தில் கொள்ள வேண்டும், எனவே பயன்பாட்டு டெவலப்பர்கள் பெரும்பாலும் உள்ளுணர்வால் வழிநடத்தப்படுகிறார்கள்.
மொத்தம்:
- நீங்கள் மேலும் செல்ல, தேர்வு பற்றிய கேள்வி இன்னும் அழுத்தமாகிறது. நீங்கள் GCP, நிர்வகிக்கப்பட்ட சேவைகள் மற்றும் SaaS ஆகியவற்றை மட்டும் பார்த்தாலும், RDBMS பற்றிய சில குறிப்புகள் 4வது படியில் மட்டுமே தோன்றும் (அங்கு ஸ்பேனர் அருகில் உள்ளது). கூடுதலாக, PostgreSQL இன் தேர்வு 5 வது படியில் தோன்றும், அதற்கு அடுத்ததாக MySQL மற்றும் SQL சேவையகமும் உள்ளன, அதாவது எல்லாம் நிறைய உள்ளது, ஆனால் நீங்கள் தேர்வு செய்ய வேண்டும்.
- சோதனையின் பின்னணிக்கு எதிரான கட்டுப்பாடுகளைப் பற்றி நாம் மறந்துவிடக் கூடாது. அடிப்படையில் எல்லோரும் ஸ்பேனரை விரும்புகிறார்கள், ஆனால் அது விலை உயர்ந்தது. இதன் விளைவாக, ஒரு பொதுவான கோரிக்கை இது போல் தெரிகிறது: "தயவுசெய்து எங்களை ஸ்பேனராக ஆக்குங்கள், ஆனால் கிளவுட் SQL இன் விலைக்கு, நீங்கள் தொழில் வல்லுநர்கள்!"
நாம் என்ன செய்ய வேண்டும்?
இறுதி உண்மை என்று கூறாமல், பின்வருவனவற்றைக் கூறுவோம்:
கற்றலுக்கான நமது அணுகுமுறையை நாம் மாற்ற வேண்டும்:
- டிபிஏக்கள் முன்பு கற்பிக்கப்பட்ட விதத்தில் கற்பிப்பதில் எந்தப் பயனும் இல்லை;
- ஒரு தயாரிப்பு பற்றிய அறிவு போதாது;
- ஆனால் ஒரு மட்டத்தில் டஜன் கணக்கானவற்றை அறிவது சாத்தியமற்றது.
தயாரிப்பு எவ்வளவு என்பதை நீங்கள் அறிந்து கொள்ள வேண்டும், ஆனால்:
- அதன் பயன்பாட்டின் பயன்பாட்டு வழக்கு;
- வெவ்வேறு வரிசைப்படுத்தல் முறைகள்;
- ஒவ்வொரு முறையின் நன்மைகள் மற்றும் தீமைகள்;
- ஒரே மாதிரியான மற்றும் மாற்று தயாரிப்புகள் ஒரு தகவலறிந்த மற்றும் உகந்த தேர்வு செய்ய மற்றும் எப்போதும் ஒரு பழக்கமான தயாரிப்புக்கு ஆதரவாக இருக்காது.
நீங்கள் தரவை நகர்த்தவும் மற்றும் ETL உடன் ஒருங்கிணைப்பதற்கான அடிப்படைக் கொள்கைகளைப் புரிந்துகொள்ளவும் முடியும்.
உண்மையான வழக்கு
சமீபத்திய காலங்களில், மொபைல் பயன்பாட்டிற்கான பின்தளத்தை உருவாக்குவது அவசியம். வேலை தொடங்கிய நேரத்தில், பின்தளம் ஏற்கனவே உருவாக்கப்பட்டது மற்றும் செயல்படுத்த தயாராக இருந்தது, மேலும் மேம்பாட்டுக் குழு இந்த திட்டத்தில் சுமார் இரண்டு ஆண்டுகள் செலவிட்டது. பின்வரும் பணிகள் அமைக்கப்பட்டன:
- CI/CD உருவாக்க;
- கட்டிடக்கலை மதிப்பாய்வு;
- அனைத்தையும் செயல்பாட்டிற்கு கொண்டு வந்தது.
பயன்பாடு மைக்ரோ சர்வீஸ் ஆகும், மேலும் பைதான்/ஜாங்கோ குறியீடு புதிதாக மற்றும் நேரடியாக GCP இல் உருவாக்கப்பட்டது. இலக்கு பார்வையாளர்களைப் பொறுத்தவரை, அமெரிக்கா மற்றும் ஐரோப்பிய ஒன்றியம் ஆகிய இரண்டு பகுதிகள் இருக்கும் என்று கருதப்பட்டது, மேலும் குளோபல் லோட் பேலன்சர் மூலம் போக்குவரத்து விநியோகிக்கப்பட்டது. அனைத்து பணிச்சுமைகளும் கணக்கீடு பணிச்சுமையும் Google Kubernetes இன்ஜினில் இயங்கின.
தரவுகளைப் பொறுத்தவரை, 3 கட்டமைப்புகள் இருந்தன:
- கிளவுட் ஸ்டோரேஜ்;
- தரவு சேமிப்பகம்;
- கிளவுட் SQL (PostgreSQL).
கிளவுட் SQL ஏன் தேர்ந்தெடுக்கப்பட்டது என்று ஒருவர் ஆச்சரியப்படலாம்? உண்மையைச் சொல்வதானால், இதுபோன்ற கேள்வி சமீபத்திய ஆண்டுகளில் ஒருவித மோசமான இடைநிறுத்தத்தை ஏற்படுத்தியுள்ளது - மக்கள் தொடர்புடைய தரவுத்தளங்களைப் பற்றி வெட்கப்படுகிறார்கள் என்ற உணர்வு உள்ளது, இருப்பினும் அவர்கள் தொடர்ந்து அவற்றை தீவிரமாகப் பயன்படுத்துகிறார்கள் ;-).
எங்கள் விஷயத்தைப் பொறுத்தவரை, பின்வரும் காரணங்களுக்காக கிளவுட் SQL தேர்ந்தெடுக்கப்பட்டது:
- குறிப்பிட்டுள்ளபடி, பயன்பாடு ஜாங்கோவைப் பயன்படுத்தி உருவாக்கப்பட்டது, மேலும் இது SQL தரவுத்தளத்திலிருந்து பைதான் பொருள்களுக்கு (ஜாங்கோ ORM) நிலையான தரவை மேப்பிங் செய்வதற்கான மாதிரியைக் கொண்டுள்ளது.
- கட்டமைப்பானது DBMSகளின் மிகவும் வரையறுக்கப்பட்ட பட்டியலை ஆதரித்தது:
- PostgreSQL;
- மரியாடிபி;
- MySQL;
- ஆரக்கிள்;
- SQLite.
அதன்படி, PostgreSQL இந்த பட்டியலிலிருந்து மிகவும் உள்ளுணர்வாக தேர்ந்தெடுக்கப்பட்டது (சரி, தேர்வு செய்வது ஆரக்கிள் அல்ல, உண்மையில்).
என்ன காணவில்லை:
- பயன்பாடு 2 பிராந்தியங்களில் மட்டுமே பயன்படுத்தப்பட்டது, மேலும் 3வது திட்டங்களில் (ஆசியா) தோன்றியது;
- தரவுத்தளம் வட அமெரிக்க பிராந்தியத்தில் (அயோவா) அமைந்துள்ளது;
- வாடிக்கையாளரின் தரப்பில் சாத்தியம் பற்றிய கவலைகள் இருந்தன அணுகல் தாமதங்கள் ஐரோப்பா மற்றும் ஆசியா மற்றும் தடங்கல்கள் சேவையில் DBMS வேலையில்லா நேரத்தின் போது.
ஜாங்கோ பல தரவுத்தளங்களுடன் இணையாக வேலை செய்து அவற்றைப் படிக்கவும் எழுதவும் பிரிக்க முடியும் என்ற உண்மை இருந்தபோதிலும், பயன்பாட்டில் அதிகம் எழுதப்படவில்லை (90% க்கும் அதிகமானோர் படிக்கிறார்கள்). மற்றும் பொதுவாக, மற்றும் பொதுவாக, அதை செய்ய முடிந்தால் ஐரோப்பா மற்றும் ஆசியாவில் உள்ள முக்கிய தளத்தின் படி-பிரதி, இது ஒரு சமரச தீர்வாக இருக்கும். சரி, இதில் என்ன சிக்கலானது?
சிரமம் என்னவென்றால், நிர்வகிக்கப்பட்ட சேவைகள் மற்றும் கிளவுட் SQL ஐப் பயன்படுத்துவதை வாடிக்கையாளர் கைவிட விரும்பவில்லை. கிளவுட் SQL இன் திறன்கள் தற்போது குறைவாகவே உள்ளன. கிளவுட் SQL உயர் கிடைக்கும் தன்மை (HA) மற்றும் Read Replica (RR) ஆகியவற்றை ஆதரிக்கிறது, ஆனால் அதே RR ஒரு பகுதியில் மட்டுமே ஆதரிக்கப்படும். அமெரிக்க பிராந்தியத்தில் ஒரு தரவுத்தளத்தை உருவாக்கியதால், கிளவுட் SQL ஐப் பயன்படுத்தி ஐரோப்பிய பிராந்தியத்தில் நீங்கள் ஒரு வாசிப்பு பிரதியை உருவாக்க முடியாது, இருப்பினும் போஸ்ட்கிரெஸ் உங்களை இதைச் செய்வதிலிருந்து தடுக்கவில்லை. கூகுள் ஊழியர்களுடனான கடிதப் பரிமாற்றம் எங்கும் செல்லவில்லை மற்றும் "பிரச்சினை எங்களுக்குத் தெரியும், அதைச் செயல்படுத்துகிறோம், என்றாவது ஒரு நாள் பிரச்சினை தீர்க்கப்படும்" என்ற பாணியில் வாக்குறுதிகளுடன் முடிந்தது.
Cloud SQL இன் திறன்களை சுருக்கமாக பட்டியலிட்டால், அது இப்படி இருக்கும்:
1. அதிக கிடைக்கும் தன்மை (HA):
- ஒரு பிராந்தியத்திற்குள்;
- வட்டு பிரதி மூலம்;
- PostgreSQL இயந்திரங்கள் பயன்படுத்தப்படவில்லை;
- தானியங்கி மற்றும் கைமுறை கட்டுப்பாடு சாத்தியம் - தோல்வி/தோல்வி;
- மாறும்போது, பல நிமிடங்களுக்கு DBMS கிடைக்காது.
2. பிரதியை (RR) படிக்கவும்:
- ஒரு பிராந்தியத்திற்குள்;
- சூடான காத்திருப்பு;
- PostgreSQL ஸ்ட்ரீமிங் பிரதி.
கூடுதலாக, வழக்கம் போல், ஒரு தொழில்நுட்பத்தைத் தேர்ந்தெடுக்கும்போது நீங்கள் எப்போதும் சிலவற்றை எதிர்கொள்கிறீர்கள் கட்டுப்பாடுகள்:
- GKE மூலம் தவிர, வாடிக்கையாளர் நிறுவனங்களை உருவாக்க மற்றும் IaaS ஐப் பயன்படுத்த விரும்பவில்லை;
- வாடிக்கையாளர் சுய சேவையான PostgreSQL/MySQL ஐ பயன்படுத்த விரும்பவில்லை;
- சரி, பொதுவாக, கூகிள் ஸ்பேனர் அதன் விலைக்கு இல்லாவிட்டால் மிகவும் பொருத்தமானதாக இருக்கும், இருப்பினும், ஜாங்கோ ORM அதனுடன் வேலை செய்ய முடியாது, ஆனால் இது ஒரு நல்ல விஷயம்.
நிலைமையைக் கருத்தில் கொண்டு, வாடிக்கையாளர் பின்தொடர்தல் கேள்வியைப் பெற்றார்: "கூகுள் ஸ்பேனரைப் போல, ஜாங்கோ ORM உடன் செயல்படும் வகையில், இதேபோன்ற ஒன்றைச் செய்ய முடியுமா?"
தீர்வு விருப்பம் எண். 0
முதலில் நினைவுக்கு வந்தது:
- CloudSQL இல் இருங்கள்;
- எந்த வடிவத்திலும் பிராந்தியங்களுக்கு இடையில் உள்ளமைக்கப்பட்ட பிரதிகள் இருக்காது;
- PostgreSQL மூலம் ஏற்கனவே உள்ள கிளவுட் SQL உடன் ஒரு பிரதியை இணைக்க முயற்சிக்கவும்;
- ஒரு PostgreSQL நிகழ்வை எங்காவது எப்படியாவது தொடங்கவும், ஆனால் குறைந்தபட்சம் மாஸ்டரைத் தொடாதீர்கள்.
ஐயோ, இதை செய்ய முடியாது என்று மாறியது, ஏனென்றால் ஹோஸ்டுக்கு அணுகல் இல்லை (இது முற்றிலும் வேறுபட்ட திட்டத்தில் உள்ளது) - pg_hba மற்றும் பல, மேலும் சூப்பர் யூசரின் கீழ் அணுகல் இல்லை.
தீர்வு விருப்பம் எண். 1
மேலும் சிந்தித்த பிறகு மற்றும் முந்தைய சூழ்நிலைகளை கணக்கில் எடுத்துக்கொண்ட பிறகு, சிந்தனையின் போக்கு ஓரளவு மாறியது:
- நாங்கள் இன்னும் CloudSQL இல் இருக்க முயற்சிக்கிறோம், ஆனால் நாங்கள் MySQL க்கு மாறுகிறோம், ஏனெனில் MySQL வழங்கும் Cloud SQL ஆனது வெளிப்புற முதன்மையைக் கொண்டுள்ளது:
- வெளிப்புற MySQL க்கான ப்ராக்ஸி ஆகும்;
- MySQL உதாரணம் போல் தெரிகிறது;
- பிற மேகங்கள் அல்லது வளாகத்தில் இருந்து தரவை நகர்த்துவதற்காக கண்டுபிடிக்கப்பட்டது.
MySQL பிரதியை அமைப்பதற்கு ஹோஸ்டுக்கான அணுகல் தேவையில்லை என்பதால், கொள்கையளவில் அனைத்தும் வேலை செய்தன, ஆனால் அது மிகவும் நிலையற்றதாகவும் சிரமமாகவும் இருந்தது. நாங்கள் மேலும் சென்றபோது, அது முற்றிலும் பயமாக மாறியது, ஏனென்றால் நாங்கள் முழு கட்டமைப்பையும் டெர்ராஃபார்முடன் பயன்படுத்தினோம், திடீரென்று வெளிப்புற மாஸ்டர் டெராஃபார்மால் ஆதரிக்கப்படவில்லை என்று மாறியது. ஆம், கூகிளில் ஒரு CLI உள்ளது, ஆனால் சில காரணங்களால் எல்லாம் இங்கே அவ்வப்போது வேலை செய்கிறது - சில சமயங்களில் இது உருவாக்கப்படும், சில சமயங்களில் உருவாக்கப்படாமல் இருக்கும். ஒருவேளை CLI ஆனது வெளிப்புற தரவு இடம்பெயர்வுக்காக கண்டுபிடிக்கப்பட்டது, மற்றும் பிரதிகளுக்காக அல்ல.
உண்மையில், இந்த கட்டத்தில் கிளவுட் SQL பொருந்தாது என்பது தெளிவாகியது. அவர்கள் சொல்வது போல், நாங்கள் எங்களால் முடிந்த அனைத்தையும் செய்தோம்.
தீர்வு விருப்பம் எண். 2
கிளவுட் SQL கட்டமைப்பிற்குள் இருக்க முடியாது என்பதால், சமரச தீர்வுக்கான தேவைகளை உருவாக்க முயற்சித்தோம். தேவைகள் பின்வருமாறு மாறியது:
- Kubernetes இல் பணிபுரிதல், Kubernetes (DCS, ...) மற்றும் GCP (LB, ...) ஆகியவற்றின் வளங்கள் மற்றும் திறன்களின் அதிகபட்ச பயன்பாடு;
- HA ப்ராக்ஸி போன்ற மேகக்கட்டத்தில் உள்ள தேவையற்ற விஷயங்களின் தொகுப்பிலிருந்து நிலைப்படுத்தல் இல்லாமை;
- முக்கிய HA பகுதியில் PostgreSQL அல்லது MySQL ஐ இயக்கும் திறன்; மற்ற பகுதிகளில் - முக்கிய பிராந்தியத்தின் RR இலிருந்து HA மற்றும் அதன் நகல் (நம்பகத்தன்மைக்காக);
- மல்டி மாஸ்டர் (நான் அவரைத் தொடர்பு கொள்ள விரும்பவில்லை, ஆனால் அது மிகவும் முக்கியமானது அல்ல)
.
இந்த கோரிக்கைகளின் விளைவாக, பபொருத்தமான DBMS மற்றும் பிணைப்பு விருப்பங்கள்:
- MySQL Galera;
- CockroachDB;
- PostgreSQL கருவிகள்
:
- pgpool-II;
- பட்ரோனி.
MySQL Galera
MySQL Galera தொழில்நுட்பம் கோடர்ஷிப்பால் உருவாக்கப்பட்டது மற்றும் இது InnoDBக்கான செருகுநிரலாகும். தனித்தன்மைகள்:
- பல மாஸ்டர்;
- ஒத்திசைவான பிரதிபலிப்பு;
- எந்த முனையிலிருந்தும் படித்தல்;
- எந்த முனையிலும் பதிவு செய்தல்;
- உள்ளமைக்கப்பட்ட HA பொறிமுறை;
- பிட்னாமியின் ஹெல்ம் விளக்கப்படம் உள்ளது.
கரப்பான் பூச்சி
விளக்கத்தின்படி, விஷயம் முற்றிலும் வெடிகுண்டு மற்றும் Go இல் எழுதப்பட்ட திறந்த மூல திட்டமாகும். முக்கிய பங்கேற்பாளர் கரப்பான் பூச்சி ஆய்வகங்கள் (கூகுள் நிறுவனத்தால் நிறுவப்பட்டது). இந்த தொடர்புடைய டிபிஎம்எஸ் முதலில் விநியோகிக்க வடிவமைக்கப்பட்டது (பெட்டிக்கு வெளியே கிடைமட்ட அளவீடுகளுடன்) மற்றும் தவறு-சகிப்புத்தன்மை கொண்டது. நிறுவனத்தைச் சேர்ந்த அதன் ஆசிரியர்கள், "SQL செயல்பாட்டின் செழுமையை NoSQL தீர்வுகளுக்கு நன்கு தெரிந்த கிடைமட்ட அணுகல்தன்மையுடன் இணைப்பதன்" இலக்கை கோடிட்டுக் காட்டியுள்ளனர்.
ஒரு நல்ல போனஸ் என்பது பிந்தைய கிரெஸ் இணைப்பு நெறிமுறைக்கான ஆதரவாகும்.
pgpool
இது PostgreSQL க்கு ஒரு துணை நிரலாகும், உண்மையில், அனைத்து இணைப்புகளையும் எடுத்து அவற்றை செயலாக்கும் ஒரு புதிய நிறுவனம். BSD உரிமத்தின் கீழ் உரிமம் பெற்ற அதன் சொந்த சுமை சமநிலை மற்றும் பாகுபடுத்தி உள்ளது. இது ஏராளமான வாய்ப்புகளை வழங்குகிறது, ஆனால் சற்றே பயமாக இருக்கிறது, ஏனெனில் ஒரு புதிய நிறுவனத்தின் இருப்பு சில கூடுதல் சாகசங்களுக்கு ஆதாரமாக மாறும்.
பட்ரோனி
இது என் கண்கள் கடைசியாக விழுந்தது, அது மாறியது போல், வீண் அல்ல. Patroni என்பது ஒரு திறந்த மூல பயன்பாடாகும், இது அடிப்படையில் ஒரு பைதான் டீமான் ஆகும், இது பல்வேறு வகையான நகலெடுப்பு மற்றும் தானியங்கி பங்கு மாறுதலுடன் PostgreSQL கிளஸ்டர்களை தானாக பராமரிக்க உங்களை அனுமதிக்கிறது. இது க்யூபருடன் நன்றாக ஒருங்கிணைத்து புதிய நிறுவனங்களை அறிமுகப்படுத்தாததால், விஷயம் மிகவும் சுவாரஸ்யமானதாக மாறியது.
இறுதியில் எதை தேர்ந்தெடுத்தீர்கள்?
தேர்வு எளிதானது அல்ல:
- கரப்பான் பூச்சி - தீ, ஆனால் இருண்ட;
- MySQL Galera - மேலும் மோசமாக இல்லை, இது பல இடங்களில் பயன்படுத்தப்படுகிறது, ஆனால் MySQL;
- pgpool - நிறைய தேவையற்ற நிறுவனங்கள், அதனால் கிளவுட் மற்றும் K8 களுடன் ஒருங்கிணைப்பு;
- பட்ரோனி - K8s உடன் சிறந்த ஒருங்கிணைப்பு, தேவையற்ற பொருட்கள் இல்லை, GCP LB உடன் நன்றாக ஒருங்கிணைக்கிறது.
இதனால், தேர்வு பட்ரோனி மீது விழுந்தது.
கண்டுபிடிப்புகள்
சுருக்கமாகச் சொல்ல வேண்டிய நேரம் இது. ஆம், ஐடி உள்கட்டமைப்பு உலகம் கணிசமாக மாறிவிட்டது, இது ஆரம்பம்தான். மேகங்கள் முன்பு மற்றொரு வகை உள்கட்டமைப்பு என்றால், இப்போது எல்லாம் வித்தியாசமானது. மேலும், மேகங்களில் புதுமைகள் தொடர்ந்து தோன்றும், அவை தோன்றும், ஒருவேளை, அவை மேகங்களில் மட்டுமே தோன்றும், அப்போதுதான், தொடக்கங்களின் முயற்சியால், அவை வளாகத்திற்கு மாற்றப்படும்.
SQL ஐப் பொறுத்தவரை, SQL வாழும். இதன் பொருள் நீங்கள் PostgreSQL மற்றும் MySQL ஐ அறிந்து அவற்றுடன் பணிபுரிய வேண்டும், ஆனால் அதைவிட முக்கியமானது அவற்றை சரியாகப் பயன்படுத்துவது.
ஆதாரம்: www.habr.com