அனைவருக்கும் வணக்கம்! என் பெயர் கோலோவ் நிகோலே. முன்னதாக, நான் Avito இல் பணிபுரிந்தேன் மற்றும் ஆறு ஆண்டுகளாக தரவு தளத்தை நிர்வகித்தேன், அதாவது, பகுப்பாய்வு (வெர்டிகா, கிளிக்ஹவுஸ்), ஸ்ட்ரீமிங் மற்றும் OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL) அனைத்து தரவுத்தளங்களிலும் பணிபுரிந்தேன். இந்த நேரத்தில், நான் அதிக எண்ணிக்கையிலான தரவுத்தளங்களைக் கையாண்டேன் - மிகவும் வித்தியாசமான மற்றும் அசாதாரணமான, மற்றும் அவற்றின் பயன்பாட்டின் தரமற்ற நிகழ்வுகளுடன்.
நான் தற்போது ManyChat இல் பணிபுரிகிறேன். சாராம்சத்தில், இது ஒரு தொடக்கமாகும் - புதியது, லட்சியமானது மற்றும் வேகமாக வளர்ந்து வருகிறது. நான் முதன்முதலில் நிறுவனத்தில் சேர்ந்தபோது, ஒரு உன்னதமான கேள்வி எழுந்தது: "இளம் ஸ்டார்ட்அப் இப்போது DBMS மற்றும் தரவுத்தள சந்தையில் இருந்து என்ன எடுக்க வேண்டும்?"
இந்த கட்டுரையில், எனது அறிக்கையின் அடிப்படையில் , இந்த கேள்விக்கு நான் பதிலளிப்பேன். அறிக்கையின் வீடியோ பதிப்பு இங்கே கிடைக்கிறது .
பொதுவாக அறியப்பட்ட தரவுத்தளங்கள் 2020
இது 2020, நான் சுற்றிப் பார்த்தேன், மூன்று வகையான தரவுத்தளங்களைப் பார்த்தேன்.
முதல் வகை - கிளாசிக் OLTP தரவுத்தளங்கள்: PostgreSQL, SQL சர்வர், ஆரக்கிள், MySQL. அவை நீண்ட காலத்திற்கு முன்பு எழுதப்பட்டவை, ஆனால் அவை டெவலப்பர் சமூகத்திற்கு மிகவும் பரிச்சயமானவை என்பதால் இன்னும் பொருத்தமானவை.
இரண்டாவது வகை "பூஜ்யம்" இலிருந்து அடிப்படைகள். அவர்கள் SQL, பாரம்பரிய கட்டமைப்புகள் மற்றும் ACID ஆகியவற்றைக் கைவிட்டு, உள்ளமைக்கப்பட்ட ஷார்டிங் மற்றும் பிற கவர்ச்சிகரமான அம்சங்களைச் சேர்ப்பதன் மூலம் கிளாசிக் வடிவங்களிலிருந்து விலகிச் செல்ல முயன்றனர். எடுத்துக்காட்டாக, இது கசாண்ட்ரா, மோங்கோடிபி, ரெடிஸ் அல்லது டரான்டூல். இந்த தீர்வுகள் அனைத்தும் சந்தையில் புதிதாக ஒன்றை வழங்க விரும்பின மற்றும் அவற்றின் முக்கிய இடத்தைப் பிடித்தன, ஏனெனில் அவை சில பணிகளுக்கு மிகவும் வசதியானவை. இந்த தரவுத்தளங்களை NOSQL என்ற குடைச் சொல்லுடன் குறிப்பேன்.
"பூஜ்ஜியங்கள்" முடிந்துவிட்டன, நாங்கள் NOSQL தரவுத்தளங்களுடன் பழகிவிட்டோம், மேலும் உலகம், எனது பார்வையில், அடுத்த படியை எடுத்தது - நிர்வகிக்கப்பட்ட தரவுத்தளங்கள். இந்த தரவுத்தளங்கள் கிளாசிக் OLTP தரவுத்தளங்கள் அல்லது புதிய NoSQL தரவுத்தளங்களின் அதே மையத்தைக் கொண்டுள்ளன. ஆனால் அவர்களுக்கு DBA மற்றும் DevOps தேவை இல்லை மற்றும் மேகங்களில் நிர்வகிக்கப்படும் வன்பொருளில் இயங்குகின்றன. ஒரு டெவலப்பரைப் பொறுத்தவரை, இது எங்காவது வேலை செய்யும் "ஒரு அடிப்படை" ஆகும், ஆனால் இது சர்வரில் எவ்வாறு நிறுவப்பட்டுள்ளது, யார் சர்வரை உள்ளமைத்தார்கள் மற்றும் யார் புதுப்பிக்கிறார்கள் என்பதை யாரும் கவனிப்பதில்லை.
அத்தகைய தரவுத்தளங்களின் எடுத்துக்காட்டுகள்:
- AWS RDS என்பது PostgreSQL/MySQL க்கான நிர்வகிக்கப்படும் ரேப்பர் ஆகும்.
- DynamoDB என்பது ரெடிஸ் மற்றும் மோங்கோடிபி போன்ற ஆவண அடிப்படையிலான தரவுத்தளத்தின் AWS அனலாக் ஆகும்.
- Amazon Redshift என்பது நிர்வகிக்கப்பட்ட பகுப்பாய்வு தரவுத்தளமாகும்.
இவை அடிப்படையில் பழைய தரவுத்தளங்கள், ஆனால் வன்பொருளுடன் வேலை செய்ய வேண்டிய அவசியம் இல்லாமல் நிர்வகிக்கப்பட்ட சூழலில் வளர்க்கப்படுகின்றன.
குறிப்பு. எடுத்துக்காட்டுகள் AWS சூழலுக்காக எடுக்கப்பட்டவை, ஆனால் அவற்றின் ஒப்புமைகள் Microsoft Azure, Google Cloud அல்லது Yandex.Cloud ஆகியவற்றிலும் உள்ளன.
இதில் புதிதாக என்ன இருக்கிறது? 2020 இல், இவை எதுவும் இல்லை.
சேவையில்லாத கருத்து
2020 ஆம் ஆண்டில் சந்தையில் உண்மையில் புதியது சர்வர்லெஸ் அல்லது சர்வர்லெஸ் தீர்வுகள்.
வழக்கமான சேவை அல்லது பின்தளப் பயன்பாட்டின் உதாரணத்தைப் பயன்படுத்தி இதன் அர்த்தம் என்ன என்பதை விளக்க முயற்சிக்கிறேன்.
வழக்கமான பின்தளப் பயன்பாட்டைப் பயன்படுத்த, நாங்கள் ஒரு சேவையகத்தை வாங்குகிறோம் அல்லது வாடகைக்கு விடுகிறோம், அதில் குறியீட்டை நகலெடுக்கிறோம், இறுதிப் புள்ளியை வெளியிடுகிறோம் மற்றும் வாடகை, மின்சாரம் மற்றும் டேட்டா சென்டர் சேவைகளுக்குத் தொடர்ந்து பணம் செலுத்துகிறோம். இது நிலையான திட்டம்.
வேறு வழி இருக்கிறதா? சர்வர்லெஸ் சேவைகள் மூலம் உங்களால் முடியும்.
இந்த அணுகுமுறையின் கவனம் என்ன: சேவையகம் இல்லை, கிளவுட்டில் ஒரு மெய்நிகர் நிகழ்வு கூட வாடகைக்கு இல்லை. சேவையைப் பயன்படுத்த, குறியீட்டை (செயல்பாடுகள்) களஞ்சியத்திற்கு நகலெடுத்து இறுதிப் புள்ளியில் வெளியிடவும். இந்த செயல்பாட்டிற்கான ஒவ்வொரு அழைப்புக்கும் நாங்கள் பணம் செலுத்துகிறோம், அது செயல்படுத்தப்படும் வன்பொருளை முற்றிலும் புறக்கணிக்கிறோம்.
இந்த அணுகுமுறையை படங்களுடன் விளக்க முயற்சிப்பேன்.
கிளாசிக் வரிசைப்படுத்தல். எங்களிடம் ஒரு குறிப்பிட்ட சுமையுடன் ஒரு சேவை உள்ளது. நாங்கள் இரண்டு நிகழ்வுகளை எழுப்புகிறோம்: இயற்பியல் சேவையகங்கள் அல்லது AWS இல் உள்ள நிகழ்வுகள். வெளிப்புற கோரிக்கைகள் இந்த நிகழ்வுகளுக்கு அனுப்பப்பட்டு அங்கு செயலாக்கப்படும்.
நீங்கள் படத்தில் பார்க்க முடியும் என, சர்வர்கள் சமமாக அகற்றப்படவில்லை. ஒன்று 100% பயன்படுத்தப்பட்டது, இரண்டு கோரிக்கைகள் உள்ளன, ஒன்று 50% மட்டுமே - ஓரளவு செயலற்ற நிலையில் உள்ளது. மூன்று கோரிக்கைகள் வரவில்லை என்றால், ஆனால் 30, பின்னர் முழு அமைப்பும் சுமைகளை சமாளிக்க முடியாது மற்றும் மெதுவாக தொடங்கும்.
சேவையகமற்ற வரிசைப்படுத்தல். சர்வர் இல்லாத சூழலில், அத்தகைய சேவைக்கு நிகழ்வுகள் அல்லது சேவையகங்கள் இல்லை. ஒரு குறிப்பிட்ட அளவிலான சூடான வளங்கள் உள்ளன - பயன்படுத்தப்பட்ட செயல்பாட்டுக் குறியீட்டைக் கொண்ட சிறிய தயாரிக்கப்பட்ட டோக்கர் கொள்கலன்கள். கணினி வெளிப்புற கோரிக்கைகளைப் பெறுகிறது மற்றும் அவை ஒவ்வொன்றிற்கும் சேவையகமற்ற கட்டமைப்பானது குறியீட்டைக் கொண்ட ஒரு சிறிய கொள்கலனை எழுப்புகிறது: இது இந்த குறிப்பிட்ட கோரிக்கையைச் செயல்படுத்துகிறது மற்றும் கொள்கலனைக் கொல்லும்.
ஒரு கோரிக்கை - ஒரு கொள்கலன் உயர்த்தப்பட்டது, 1000 கோரிக்கைகள் - 1000 கொள்கலன்கள். வன்பொருள் சேவையகங்களில் வரிசைப்படுத்துவது ஏற்கனவே கிளவுட் வழங்குநரின் வேலை. இது சர்வர்லெஸ் கட்டமைப்பால் முற்றிலும் மறைக்கப்பட்டுள்ளது. இந்த கருத்தில் நாம் ஒவ்வொரு அழைப்புக்கும் பணம் செலுத்துகிறோம். உதாரணமாக, ஒரு நாளைக்கு ஒரு அழைப்பு வந்தது - ஒரு அழைப்புக்கு நாங்கள் பணம் செலுத்தினோம், நிமிடத்திற்கு ஒரு மில்லியன் வந்தது - நாங்கள் ஒரு மில்லியனுக்கு பணம் செலுத்தினோம். அல்லது ஒரு நொடியில் இதுவும் நடக்கும்.
சர்வர்லெஸ் செயல்பாட்டை வெளியிடும் கருத்து நிலையற்ற சேவைக்கு ஏற்றது. உங்களுக்கு (ஸ்டேட்) ஸ்டேட்ஃபுல் சேவை தேவைப்பட்டால், நாங்கள் சேவையில் ஒரு தரவுத்தளத்தைச் சேர்க்கிறோம். இந்த வழக்கில், மாநிலத்துடன் பணிபுரியும் போது, ஒவ்வொரு ஸ்டேட்ஃபுல் செயல்பாடும் தரவுத்தளத்திலிருந்து எழுதுகிறது மற்றும் படிக்கிறது. மேலும், கட்டுரையின் தொடக்கத்தில் விவரிக்கப்பட்டுள்ள மூன்று வகைகளில் ஏதேனும் ஒரு தரவுத்தளத்திலிருந்து.
இந்த தரவுத்தளங்களின் பொதுவான வரம்பு என்ன? இவை தொடர்ந்து பயன்படுத்தப்படும் கிளவுட் அல்லது வன்பொருள் சேவையகத்தின் (அல்லது பல சேவையகங்களின்) செலவுகளாகும். நாங்கள் கிளாசிக் அல்லது நிர்வகிக்கப்பட்ட தரவுத்தளத்தைப் பயன்படுத்துகிறோமா, எங்களிடம் டெவொப்ஸ் மற்றும் நிர்வாகி இருக்கிறாரா இல்லையா என்பது முக்கியமல்ல, வன்பொருள், மின்சாரம் மற்றும் டேட்டா சென்டர் வாடகைக்கு 24/7 செலுத்துகிறோம். எங்களிடம் ஒரு உன்னதமான அடிப்படை இருந்தால், எஜமானருக்கும் அடிமைக்கும் நாங்கள் பணம் செலுத்துகிறோம். இது மிகவும் ஏற்றப்பட்ட துண்டிக்கப்பட்ட தரவுத்தளமாக இருந்தால், நாங்கள் 10, 20 அல்லது 30 சேவையகங்களுக்கு பணம் செலுத்துகிறோம், நாங்கள் தொடர்ந்து பணம் செலுத்துகிறோம்.
செலவு கட்டமைப்பில் நிரந்தரமாக ஒதுக்கப்பட்ட சேவையகங்கள் இருப்பது அவசியமான தீமையாக முன்னர் கருதப்பட்டது. வழக்கமான தரவுத்தளங்கள் இணைப்புகளின் எண்ணிக்கையின் வரம்புகள், அளவிடுதல் கட்டுப்பாடுகள், புவி-விநியோகிக்கப்பட்ட ஒருமித்த கருத்து போன்ற பிற சிரமங்களையும் கொண்டுள்ளன - அவை எப்படியாவது சில தரவுத்தளங்களில் தீர்க்கப்படலாம், ஆனால் ஒரே நேரத்தில் அல்ல, சிறந்தவை அல்ல.
சர்வர்லெஸ் தரவுத்தளம் - கோட்பாடு
2020 இன் கேள்வி: தரவுத்தளத்தையும் சேவையகமற்றதாக மாற்ற முடியுமா? சர்வர்லெஸ் பேக்எண்ட் பற்றி அனைவரும் கேள்விப்பட்டிருப்பீர்கள்... டேட்டாபேஸை சர்வர்லெஸ் ஆக்க முயற்சிப்போம்?
இது விசித்திரமாகத் தெரிகிறது, ஏனெனில் தரவுத்தளமானது ஒரு முழுமையான சேவையாகும், இது சேவையகமற்ற உள்கட்டமைப்புக்கு மிகவும் பொருத்தமானதல்ல. அதே நேரத்தில், தரவுத்தளத்தின் நிலை மிகவும் பெரியது: ஜிகாபைட்கள், டெராபைட்கள் மற்றும் பகுப்பாய்வு தரவுத்தளங்களில் பெட்டாபைட்கள் கூட. இலகுரக டோக்கர் கொள்கலன்களில் அதை வளர்ப்பது அவ்வளவு எளிதானது அல்ல.
மறுபுறம், கிட்டத்தட்ட அனைத்து நவீன தரவுத்தளங்களும் ஒரு பெரிய அளவு தர்க்கம் மற்றும் கூறுகளைக் கொண்டிருக்கின்றன: பரிவர்த்தனைகள், ஒருமைப்பாடு ஒருங்கிணைப்பு, நடைமுறைகள், தொடர்புடைய சார்புகள் மற்றும் நிறைய தர்க்கம். நிறைய தரவுத்தள தர்க்கத்திற்கு, ஒரு சிறிய நிலை போதுமானது. ஜிகாபைட்கள் மற்றும் டெராபைட்கள் நேரடியாக வினவல்களை செயல்படுத்துவதில் ஈடுபட்டுள்ள தரவுத்தள தர்க்கத்தின் ஒரு சிறிய பகுதியால் மட்டுமே நேரடியாகப் பயன்படுத்தப்படுகின்றன.
அதன்படி, யோசனை: தர்க்கத்தின் ஒரு பகுதி நிலையற்ற மரணதண்டனையை அனுமதித்தால், அடித்தளத்தை மாநில மற்றும் நிலையற்ற பகுதிகளாக ஏன் பிரிக்கக்கூடாது.
OLAP தீர்வுகளுக்கு சேவையில்லாதது
தரவுத்தளத்தை ஸ்டேட்ஃபுல் மற்றும் ஸ்டேட்லெஸ் பகுதிகளாக வெட்டுவது நடைமுறை உதாரணங்களைப் பயன்படுத்தி எப்படி இருக்கும் என்று பார்ப்போம்.
எடுத்துக்காட்டாக, எங்களிடம் ஒரு பகுப்பாய்வு தரவுத்தளம் உள்ளது: வெளிப்புற தரவு (இடதுபுறத்தில் சிவப்பு சிலிண்டர்), தரவுத்தளத்தில் தரவை ஏற்றும் ஒரு ETL செயல்முறை மற்றும் தரவுத்தளத்திற்கு SQL வினவல்களை அனுப்பும் ஒரு ஆய்வாளர். இது ஒரு உன்னதமான தரவுக் கிடங்கு செயல்பாட்டுத் திட்டமாகும்.
இந்த திட்டத்தில், ETL நிபந்தனையுடன் ஒருமுறை செய்யப்படுகிறது. ETL நிரப்பப்பட்ட தரவுகளுடன் தரவுத்தளம் இயங்கும் சேவையகங்களுக்கு நீங்கள் தொடர்ந்து பணம் செலுத்த வேண்டும், இதனால் வினவல்களை அனுப்ப ஏதாவது உள்ளது.
AWS Athena Serverless இல் செயல்படுத்தப்பட்ட மாற்று அணுகுமுறையைப் பார்ப்போம். பதிவிறக்கம் செய்யப்பட்ட தரவு சேமிக்கப்படும் நிரந்தரமாக அர்ப்பணிக்கப்பட்ட வன்பொருள் எதுவும் இல்லை. இதற்கு பதிலாக:
- பயனர் அதீனாவிடம் SQL வினவலை சமர்ப்பிக்கிறார். அதீனா ஆப்டிமைசர் SQL வினவலைப் பகுப்பாய்வு செய்து, வினவலைச் செயல்படுத்தத் தேவையான குறிப்பிட்ட தரவுகளுக்காக மெட்டாடேட்டா ஸ்டோரில் (மெட்டாடேட்டா) தேடுகிறது.
- உகப்பாக்கி, சேகரிக்கப்பட்ட தரவின் அடிப்படையில், தேவையான தரவை வெளிப்புற மூலங்களிலிருந்து தற்காலிக சேமிப்பகத்திற்கு (தற்காலிக தரவுத்தளத்தில்) பதிவிறக்குகிறது.
- பயனரிடமிருந்து ஒரு SQL வினவல் தற்காலிக சேமிப்பகத்தில் செயல்படுத்தப்பட்டு அதன் முடிவு பயனருக்குத் திருப்பியளிக்கப்படும்.
- தற்காலிக சேமிப்பு அழிக்கப்பட்டு ஆதாரங்கள் வெளியிடப்பட்டன.
இந்த கட்டமைப்பில், கோரிக்கையை நிறைவேற்றும் செயல்முறைக்கு மட்டுமே நாங்கள் பணம் செலுத்துகிறோம். கோரிக்கைகள் இல்லை - செலவுகள் இல்லை.
இது ஒரு வேலை செய்யும் அணுகுமுறை மற்றும் அதீனா சர்வர்லெஸில் மட்டுமல்ல, ரெட்ஷிஃப்ட் ஸ்பெக்ட்ரமிலும் (AWS இல்) செயல்படுத்தப்படுகிறது.
அதீனா உதாரணம், சர்வர்லெஸ் தரவுத்தளம் உண்மையான வினவல்களில் பத்து மற்றும் நூற்றுக்கணக்கான டெராபைட் தரவுகளுடன் செயல்படுகிறது என்பதைக் காட்டுகிறது. நூற்றுக்கணக்கான டெராபைட்டுகளுக்கு நூற்றுக்கணக்கான சேவையகங்கள் தேவைப்படும், ஆனால் அவற்றை நாங்கள் செலுத்த வேண்டியதில்லை - கோரிக்கைகளுக்கு நாங்கள் பணம் செலுத்துகிறோம். வெர்டிகா போன்ற சிறப்பு பகுப்பாய்வு தரவுத்தளங்களுடன் ஒப்பிடும்போது ஒவ்வொரு கோரிக்கையின் வேகமும் (மிகவும்) குறைவாக உள்ளது, ஆனால் வேலையில்லா நேரங்களுக்கு நாங்கள் பணம் செலுத்துவதில்லை.
இத்தகைய தரவுத்தளம் அரிதான பகுப்பாய்வு தற்காலிக வினவல்களுக்குப் பொருந்தும். எடுத்துக்காட்டாக, சில பிரம்மாண்டமான தரவுகளின் மீது கருதுகோளைச் சோதிக்க நாம் தன்னிச்சையாக முடிவு செய்தால். இந்த நிகழ்வுகளுக்கு அதீனா சரியானது. வழக்கமான கோரிக்கைகளுக்கு, அத்தகைய அமைப்பு விலை உயர்ந்தது. இந்த வழக்கில், சில சிறப்பு தீர்வுகளில் தரவை தேக்ககப்படுத்தவும்.
OLTP தீர்வுகளுக்கு சேவையில்லாதது
முந்தைய உதாரணம் OLAP (பகுப்பாய்வு) பணிகளைப் பார்த்தது. இப்போது OLTP பணிகளைப் பார்ப்போம்.
அளவிடக்கூடிய PostgreSQL அல்லது MySQL ஐ கற்பனை செய்வோம். குறைந்தபட்ச ஆதாரங்களுடன் வழக்கமான நிர்வகிக்கப்படும் நிகழ்வான PostgreSQL அல்லது MySQL ஐ உயர்த்துவோம். நிகழ்வு அதிக சுமைகளைப் பெறும்போது, கூடுதல் பிரதிகளை இணைப்போம், அதில் வாசிப்பு சுமையின் ஒரு பகுதியை விநியோகிப்போம். கோரிக்கைகள் அல்லது ஏற்றங்கள் இல்லை என்றால், நாங்கள் பிரதிகளை அணைப்போம். முதல் நிகழ்வு மாஸ்டர், மற்றவை பிரதிகள்.
இந்த யோசனை Aurora Serverless AWS எனப்படும் தரவுத்தளத்தில் செயல்படுத்தப்படுகிறது. கொள்கை எளிதானது: வெளிப்புற பயன்பாடுகளின் கோரிக்கைகள் ப்ராக்ஸி கடற்படையால் ஏற்றுக்கொள்ளப்படுகின்றன. சுமை அதிகரிப்பதைக் கண்டு, அது முன்-வெப்பப்படுத்தப்பட்ட குறைந்தபட்ச நிகழ்வுகளிலிருந்து கணினி வளங்களை ஒதுக்குகிறது - இணைப்பு முடிந்தவரை விரைவாக செய்யப்படுகிறது. செயலிழப்பு நிகழ்வுகள் அதே வழியில் நிகழ்கின்றன.
அரோராவிற்குள் அரோரா திறன் அலகு, ACU என்ற கருத்து உள்ளது. இது (நிபந்தனையுடன்) ஒரு உதாரணம் (சர்வர்). ஒவ்வொரு குறிப்பிட்ட ACU ஒரு மாஸ்டர் அல்லது அடிமையாக இருக்கலாம். ஒவ்வொரு கொள்ளளவு அலகுக்கும் அதன் சொந்த ரேம், செயலி மற்றும் குறைந்தபட்ச வட்டு உள்ளது. அதன்படி, ஒருவர் மாஸ்டர், மீதமுள்ளவை பிரதிகள் மட்டுமே படிக்கப்படுகின்றன.
இயங்கும் இந்த அரோரா திறன் அலகுகளின் எண்ணிக்கை ஒரு கட்டமைக்கக்கூடிய அளவுருவாகும். குறைந்தபட்ச அளவு ஒன்று அல்லது பூஜ்ஜியமாக இருக்கலாம் (இந்த வழக்கில், கோரிக்கைகள் இல்லை என்றால் தரவுத்தளம் இயங்காது).
அடிப்படை கோரிக்கைகளைப் பெறும்போது, ப்ராக்ஸி ஃப்ளீட் அரோரா திறன் அலகுகளை உயர்த்தி, கணினியின் செயல்திறன் வளங்களை அதிகரிக்கிறது. வளங்களை அதிகரிக்க மற்றும் குறைக்கும் திறன் கணினியை வளங்களை "வித்தை" செய்ய அனுமதிக்கிறது: தனிப்பட்ட ACU களை தானாகவே காண்பிக்கும் (அவற்றை புதியவற்றுடன் மாற்றுகிறது) மற்றும் திரும்பப் பெறப்பட்ட ஆதாரங்களுக்கு தற்போதைய அனைத்து புதுப்பிப்புகளையும் வெளியிடுகிறது.
அரோரா சர்வர்லெஸ் பேஸ் வாசிப்பு சுமையை அளவிட முடியும். ஆனால் ஆவணங்கள் இதை நேரடியாகக் கூறவில்லை. அவர்களால் பல மாஸ்டரை உயர்த்த முடியும் என உணரலாம். மந்திரம் இல்லை.
கணிக்க முடியாத அணுகலைக் கொண்ட கணினிகளில் பெரும் தொகையைச் செலவழிப்பதைத் தவிர்க்க இந்தத் தரவுத்தளம் மிகவும் பொருத்தமானது. எடுத்துக்காட்டாக, MVP உருவாக்கும்போது அல்லது வணிக அட்டை தளங்களை சந்தைப்படுத்தும்போது, நிலையான சுமையை நாங்கள் பொதுவாக எதிர்பார்க்க மாட்டோம். அதன்படி, அணுகல் இல்லை என்றால், நாங்கள் நிகழ்வுகளுக்கு பணம் செலுத்த மாட்டோம். எதிர்பாராத சுமை ஏற்படும் போது, உதாரணமாக ஒரு மாநாடு அல்லது விளம்பரப் பிரச்சாரத்திற்குப் பிறகு, மக்கள் கூட்டம் கூட்டமாக தளத்தைப் பார்வையிடுகிறது மற்றும் சுமை வியத்தகு அளவில் அதிகரிக்கிறது, அரோரா சர்வர்லெஸ் தானாகவே இந்த சுமையை எடுத்து, காணாமல் போன ஆதாரங்களை (ACU) விரைவாக இணைக்கிறது. பின்னர் மாநாடு கடந்து செல்கிறது, எல்லோரும் முன்மாதிரியை மறந்துவிடுகிறார்கள், சேவையகங்கள் (ACU) இருட்டாகின்றன, மேலும் செலவுகள் பூஜ்ஜியமாகக் குறைகிறது - வசதியானது.
இந்த தீர்வு நிலையான உயர் ஏற்றத்திற்கு ஏற்றது அல்ல, ஏனெனில் இது எழுதும் சுமையை அளவிடாது. இந்த இணைப்புகள் மற்றும் ஆதாரங்களின் துண்டிப்புகள் அனைத்தும் "ஸ்கேல் பாயிண்ட்" என்று அழைக்கப்படும் இடத்தில் நிகழ்கின்றன - தரவுத்தளமானது பரிவர்த்தனை அல்லது தற்காலிக அட்டவணைகளால் ஆதரிக்கப்படாத ஒரு புள்ளியாகும். எடுத்துக்காட்டாக, ஒரு வாரத்திற்குள் அளவு புள்ளி நடக்காமல் போகலாம், மேலும் அடிப்படை அதே ஆதாரங்களில் வேலை செய்கிறது மற்றும் வெறுமனே விரிவாக்கவோ சுருங்கவோ முடியாது.
எந்த மந்திரமும் இல்லை - இது வழக்கமான PostgreSQL. ஆனால் இயந்திரங்களைச் சேர்ப்பது மற்றும் அவற்றைத் துண்டிக்கும் செயல்முறை ஓரளவு தானியங்கு ஆகும்.
வடிவமைப்பால் சேவையகமற்றது
அரோரா சர்வர்லெஸ் என்பது சர்வர்லெஸின் சில நன்மைகளைப் பயன்படுத்த கிளவுட்க்காக மீண்டும் எழுதப்பட்ட பழைய தரவுத்தளமாகும். சர்வர்லெஸ்-பை-டிசைன் - சர்வர்லெஸ் அணுகுமுறைக்காக முதலில் கிளவுட்க்காக எழுதப்பட்ட தளத்தைப் பற்றி இப்போது நான் உங்களுக்குச் சொல்கிறேன். இது இயற்பியல் சேவையகங்களில் இயங்கும் என்ற அனுமானம் இல்லாமல் உடனடியாக உருவாக்கப்பட்டது.
இந்த தளம் ஸ்னோஃப்ளேக் என்று அழைக்கப்படுகிறது. இது மூன்று முக்கிய தொகுதிகளைக் கொண்டுள்ளது.
முதலாவது மெட்டாடேட்டா தொகுதி. இது ஒரு வேகமான இன்-மெமரி சேவையாகும், இது பாதுகாப்பு, மெட்டாடேட்டா, பரிவர்த்தனைகள் மற்றும் வினவல் மேம்படுத்தல் (இடதுபுறத்தில் உள்ள விளக்கப்படத்தில் காட்டப்பட்டுள்ளது) ஆகியவற்றில் உள்ள சிக்கல்களைத் தீர்க்கிறது.
இரண்டாவது தொகுதி என்பது கணக்கீடுகளுக்கான மெய்நிகர் கம்ப்யூட்டிங் கிளஸ்டர்களின் தொகுப்பாகும் (விளக்கத்தில் நீல வட்டங்களின் தொகுப்பு உள்ளது).
மூன்றாவது தொகுதி S3 அடிப்படையிலான தரவு சேமிப்பு அமைப்பு ஆகும். S3 என்பது AWS இல் பரிமாணமற்ற பொருள் சேமிப்பகம், வணிகத்திற்கான பரிமாணமற்ற டிராப்பாக்ஸ் போன்றது.
ஸ்னோஃப்ளேக் எப்படி வேலை செய்கிறது என்று பார்ப்போம், ஒரு குளிர் ஆரம்பம் என்று வைத்துக்கொள்வோம். அதாவது, ஒரு தரவுத்தளம் உள்ளது, தரவு அதில் ஏற்றப்பட்டது, இயங்கும் வினவல்கள் எதுவும் இல்லை. அதன்படி, தரவுத்தளத்திற்கு கோரிக்கைகள் எதுவும் இல்லை என்றால், வேகமான இன்-மெமரி மெட்டாடேட்டா சேவையை (முதல் தொகுதி) உயர்த்தியுள்ளோம். எங்களிடம் S3 சேமிப்பகம் உள்ளது, அங்கு அட்டவணை தரவு சேமிக்கப்படுகிறது, மைக்ரோபார்டிஷன்கள் என அழைக்கப்படும். எளிமைக்காக: அட்டவணையில் பரிவர்த்தனைகள் இருந்தால், மைக்ரோ பார்ட்டிஷன்கள் என்பது பரிவர்த்தனைகளின் நாட்கள். ஒவ்வொரு நாளும் ஒரு தனி மைக்ரோபார்டிஷன், ஒரு தனி கோப்பு. தரவுத்தளம் இந்த பயன்முறையில் செயல்படும் போது, தரவு ஆக்கிரமித்துள்ள இடத்திற்கு மட்டுமே நீங்கள் பணம் செலுத்துவீர்கள். மேலும், ஒரு இருக்கைக்கான விகிதம் மிகவும் குறைவாக உள்ளது (குறிப்பாக குறிப்பிடத்தக்க சுருக்கத்தை கணக்கில் எடுத்துக்கொள்வது). மெட்டாடேட்டா சேவையும் தொடர்ந்து இயங்குகிறது, ஆனால் வினவல்களை மேம்படுத்த உங்களுக்கு நிறைய ஆதாரங்கள் தேவையில்லை, மேலும் சேவையை ஷேர்வேராகக் கருதலாம்.
இப்போது ஒரு பயனர் எங்கள் தரவுத்தளத்திற்கு வந்து SQL வினவலை அனுப்பினார் என்று கற்பனை செய்து கொள்வோம். SQL வினவல் செயலாக்கத்திற்காக மெட்டாடேட்டா சேவைக்கு உடனடியாக அனுப்பப்படும். அதன்படி, ஒரு கோரிக்கையைப் பெற்றவுடன், இந்த சேவை கோரிக்கை, கிடைக்கக்கூடிய தரவு, பயனர் அனுமதிகள் ஆகியவற்றை பகுப்பாய்வு செய்கிறது மற்றும் அனைத்தும் நன்றாக இருந்தால், கோரிக்கையை செயலாக்குவதற்கான திட்டத்தை வரைகிறது.
அடுத்து, சேவையானது கம்ப்யூட்டிங் கிளஸ்டரின் துவக்கத்தைத் தொடங்குகிறது. கம்ப்யூட்டிங் கிளஸ்டர் என்பது கணக்கீடுகளைச் செய்யும் சேவையகங்களின் தொகுப்பாகும். அதாவது, இது 1 சர்வர், 2 சர்வர்கள், 4, 8, 16, 32 - நீங்கள் விரும்பும் பலவற்றைக் கொண்டிருக்கும் ஒரு கிளஸ்டர் ஆகும். நீங்கள் ஒரு கோரிக்கையை விடுங்கள் மற்றும் இந்த கிளஸ்டரின் துவக்கம் உடனடியாக தொடங்குகிறது. இது உண்மையில் வினாடிகள் எடுக்கும்.
அடுத்து, கிளஸ்டர் தொடங்கிய பிறகு, உங்கள் கோரிக்கையைச் செயலாக்கத் தேவையான மைக்ரோபார்ட்டிஷன்கள் S3 இலிருந்து கிளஸ்டரில் நகலெடுக்கத் தொடங்கும். அதாவது, ஒரு SQL வினவலை இயக்க உங்களுக்கு ஒரு அட்டவணையில் இருந்து இரண்டு பகிர்வுகள் மற்றும் இரண்டாவது பகிர்வுகள் தேவை என்று கற்பனை செய்யலாம். இந்த வழக்கில், தேவையான மூன்று பகிர்வுகள் மட்டுமே கிளஸ்டருக்கு நகலெடுக்கப்படும், மேலும் அனைத்து அட்டவணைகளும் முழுமையாக இல்லை. அதனால்தான், எல்லாமே ஒரு தரவு மையத்திற்குள் அமைந்திருப்பதாலும், மிக வேகமான சேனல்களால் இணைக்கப்பட்டிருப்பதாலும், முழு பரிமாற்ற செயல்முறையும் மிக விரைவாக நிகழ்கிறது: நொடிகளில், மிக அரிதாக நிமிடங்களில், சில பயங்கரமான கோரிக்கைகளைப் பற்றி பேசாவிட்டால். அதன்படி, மைக்ரோ பார்ட்டிஷன்கள் கம்ப்யூட்டிங் கிளஸ்டருக்கு நகலெடுக்கப்படுகின்றன, மேலும், முடிந்ததும், இந்த கம்ப்யூட்டிங் கிளஸ்டரில் SQL வினவல் செயல்படுத்தப்படும். இந்தக் கோரிக்கையின் விளைவாக ஒரு வரி, பல வரிகள் அல்லது அட்டவணை இருக்கலாம் - அவை பயனருக்கு வெளிப்புறமாக அனுப்பப்படும், இதனால் அவர் அதைப் பதிவிறக்கலாம், அவருடைய BI கருவியில் காட்டலாம் அல்லது வேறு வழியில் பயன்படுத்தலாம்.
ஒவ்வொரு SQL வினவலும் முன்பு ஏற்றப்பட்ட தரவிலிருந்து மொத்தங்களை மட்டும் படிக்க முடியாது, ஆனால் தரவுத்தளத்தில் புதிய தரவை ஏற்ற/உருவாக்கும். அதாவது, இது ஒரு வினவலாக இருக்கலாம், எடுத்துக்காட்டாக, புதிய பதிவுகளை மற்றொரு அட்டவணையில் செருகுவது, இது கம்ப்யூட்டிங் கிளஸ்டரில் ஒரு புதிய பகிர்வின் தோற்றத்திற்கு வழிவகுக்கிறது, இது ஒரு S3 சேமிப்பகத்தில் தானாகவே சேமிக்கப்படும்.
மேலே விவரிக்கப்பட்ட காட்சி, பயனரின் வருகையிலிருந்து கிளஸ்டரை உயர்த்துவது, தரவை ஏற்றுவது, வினவல்களைச் செயல்படுத்துவது, முடிவுகளைப் பெறுவது, உயர்த்தப்பட்ட மெய்நிகர் கம்ப்யூட்டிங் கிளஸ்டர், மெய்நிகர் கிடங்கு ஆகியவற்றைப் பயன்படுத்தும் நிமிடங்களுக்கு விகிதத்தில் செலுத்தப்படுகிறது. AWS மண்டலம் மற்றும் கிளஸ்டர் அளவைப் பொறுத்து விகிதம் மாறுபடும், ஆனால் சராசரியாக இது ஒரு மணி நேரத்திற்கு சில டாலர்கள் ஆகும். நான்கு இயந்திரங்கள் கொண்ட ஒரு கொத்து இரண்டு இயந்திரங்கள் கொண்ட ஒரு கிளஸ்டரை விட இரண்டு மடங்கு விலை அதிகம், மேலும் எட்டு இயந்திரங்கள் கொண்ட ஒரு கிளஸ்டர் இன்னும் இரண்டு மடங்கு விலை அதிகம். கோரிக்கைகளின் சிக்கலான தன்மையைப் பொறுத்து 16, 32 இயந்திரங்களின் விருப்பங்கள் கிடைக்கின்றன. ஆனால் கிளஸ்டர் உண்மையில் இயங்கும் அந்த நிமிடங்களுக்கு மட்டுமே நீங்கள் பணம் செலுத்துகிறீர்கள், ஏனென்றால் கோரிக்கைகள் எதுவும் இல்லாதபோது, நீங்கள் உங்கள் கைகளை கழற்றலாம், மேலும் 5-10 நிமிட காத்திருப்புக்குப் பிறகு (கட்டமைக்கக்கூடிய அளவுரு) அது தானாகவே வெளியேறும், வளங்களை விடுவித்து சுதந்திரமாகுங்கள்.
நீங்கள் ஒரு கோரிக்கையை அனுப்பும் போது, க்ளஸ்டர் மேலெழுகிறது, ஒப்பீட்டளவில், ஒரு நிமிடத்தில், அது மற்றொரு நிமிடம், பின்னர் ஐந்து நிமிடங்கள் நிறுத்தப்படும், மேலும் இந்த கிளஸ்டரின் ஏழு நிமிட செயல்பாட்டிற்கு நீங்கள் செலுத்த வேண்டியிருக்கும். மாதங்கள் மற்றும் ஆண்டுகள் அல்ல.
ஒற்றை-பயனர் அமைப்பில் ஸ்னோஃப்ளேக்கைப் பயன்படுத்தி விவரிக்கப்பட்ட முதல் காட்சி. இப்போது பல பயனர்கள் இருப்பதாக கற்பனை செய்யலாம், இது உண்மையான சூழ்நிலைக்கு நெருக்கமாக உள்ளது.
எங்களிடம் ஏராளமான ஆய்வாளர்கள் மற்றும் அட்டவணை அறிக்கைகள் உள்ளன, அவை எங்கள் தரவுத்தளத்தை அதிக எண்ணிக்கையிலான எளிய பகுப்பாய்வு SQL வினவல்களுடன் தொடர்ந்து தாக்குகின்றன.
கூடுதலாக, தரவு மூலம் பயங்கரமான விஷயங்களைச் செய்ய முயற்சிக்கும், பல்லாயிரக்கணக்கான டெராபைட்களுடன் செயல்படும், பில்லியன் கணக்கான மற்றும் டிரில்லியன் கணக்கான தரவு வரிசைகளை பகுப்பாய்வு செய்யும் கண்டுபிடிப்பு தரவு விஞ்ஞானிகள் எங்களிடம் உள்ளனர் என்று சொல்லலாம்.
மேலே விவரிக்கப்பட்ட இரண்டு வகையான பணிச்சுமைகளுக்கு, ஸ்னோஃப்ளேக் பல்வேறு திறன்களைக் கொண்ட பல சுயாதீன கணினி கிளஸ்டர்களை உயர்த்த உங்களை அனுமதிக்கிறது. மேலும், இந்த கம்ப்யூட்டிங் கிளஸ்டர்கள் சுயாதீனமாக வேலை செய்கின்றன, ஆனால் பொதுவான நிலையான தரவுகளுடன்.
அதிக எண்ணிக்கையிலான ஒளி வினவல்களுக்கு, நீங்கள் 2-3 சிறிய கிளஸ்டர்களை, ஒவ்வொன்றும் தோராயமாக 2 இயந்திரங்களை எழுப்பலாம். இந்த நடத்தை மற்றவற்றுடன், தானியங்கி அமைப்புகளைப் பயன்படுத்தி செயல்படுத்தப்படலாம். எனவே நீங்கள் சொல்கிறீர்கள், “ஸ்னோஃப்ளேக், ஒரு சிறிய கிளஸ்டரை உயர்த்துங்கள். ஒரு குறிப்பிட்ட அளவுருவை விட அதன் சுமை அதிகரித்தால், இதேபோன்ற இரண்டாவது, மூன்றாவது உயர்த்தவும். சுமை குறையத் தொடங்கும் போது, அதிகப்படியானவற்றை அணைக்கவும். அதனால் எத்தனை ஆய்வாளர்கள் வந்து அறிக்கைகளைப் பார்க்கத் தொடங்கினாலும், அனைவருக்கும் போதுமான ஆதாரங்கள் உள்ளன.
அதே நேரத்தில், ஆய்வாளர்கள் தூங்கிவிட்டால், அறிக்கைகளை யாரும் பார்க்கவில்லை என்றால், கொத்துகள் முற்றிலும் இருட்டாகிவிடும், மேலும் நீங்கள் அவர்களுக்கு பணம் செலுத்துவதை நிறுத்துவீர்கள்.
அதே நேரத்தில், அதிக கேள்விகளுக்கு (தரவு விஞ்ஞானிகளிடமிருந்து), நீங்கள் 32 இயந்திரங்களுக்கு ஒரு மிகப் பெரிய கிளஸ்டரை உருவாக்கலாம். உங்கள் மாபெரும் கோரிக்கை அங்கு இயங்கும் நிமிடங்கள் மற்றும் மணிநேரங்களுக்கு மட்டுமே இந்தக் கிளஸ்டரும் செலுத்தப்படும்.
மேலே விவரிக்கப்பட்ட வாய்ப்பு, 2 ஐ மட்டுமல்ல, பல வகையான பணிச்சுமைகளையும் கிளஸ்டர்களாகப் பிரிக்க உங்களை அனுமதிக்கிறது (ETL, கண்காணிப்பு, அறிக்கை பொருள்மயமாக்கல்,...).
ஸ்னோஃப்ளேக்கை சுருக்கமாகக் கூறுவோம். அடிப்படை ஒரு அழகான யோசனை மற்றும் செயல்படுத்தக்கூடிய செயல்படுத்தலை ஒருங்கிணைக்கிறது. ManyChat இல், எங்களிடம் உள்ள எல்லா தரவையும் பகுப்பாய்வு செய்ய ஸ்னோஃப்ளேக்கைப் பயன்படுத்துகிறோம். எங்களிடம் மூன்று கிளஸ்டர்கள் இல்லை, எடுத்துக்காட்டில் உள்ளது, ஆனால் 5 முதல் 9 வரை, வெவ்வேறு அளவுகள். எங்களிடம் வழக்கமான 16-மெஷின், 2-மெஷின் மற்றும் சில பணிகளுக்கு சூப்பர்-சிறிய 1-மெஷின் உள்ளது. அவர்கள் சுமைகளை வெற்றிகரமாக விநியோகிக்கிறார்கள் மற்றும் நிறைய சேமிக்க அனுமதிக்கிறார்கள்.
தரவுத்தளம் வாசிப்பு மற்றும் எழுதும் சுமையை வெற்றிகரமாக அளவிடுகிறது. வாசிப்பு சுமையை மட்டுமே சுமந்த அதே "அரோரா" உடன் ஒப்பிடும்போது இது ஒரு பெரிய வித்தியாசம் மற்றும் மிகப்பெரிய திருப்புமுனையாகும். ஸ்னோஃப்ளேக் இந்த கம்ப்யூட்டிங் கிளஸ்டர்கள் மூலம் உங்கள் எழுதும் பணிச்சுமையை அளவிட அனுமதிக்கிறது. அதாவது, நான் குறிப்பிட்டது போல், நாங்கள் பல க்ளஸ்டர்களைப் பல சேட்டில் பயன்படுத்துகிறோம், சிறிய மற்றும் சூப்பர்-சிறிய கிளஸ்டர்கள் முக்கியமாக ETL க்கு, தரவை ஏற்றுவதற்குப் பயன்படுத்தப்படுகின்றன. ஆய்வாளர்கள் ஏற்கனவே நடுத்தர கிளஸ்டர்களில் வாழ்கின்றனர், அவை ETL சுமையால் முற்றிலும் பாதிக்கப்படுவதில்லை, எனவே அவை மிக விரைவாக வேலை செய்கின்றன.
அதன்படி, தரவுத்தளம் OLAP பணிகளுக்கு மிகவும் பொருத்தமானது. இருப்பினும், துரதிருஷ்டவசமாக, OLTP பணிச்சுமைகளுக்கு இது இன்னும் பொருந்தாது. முதலாவதாக, இந்த தரவுத்தளம் நெடுவரிசையானது, அடுத்தடுத்த அனைத்து விளைவுகளுடன். இரண்டாவதாக, ஒவ்வொரு கோரிக்கைக்கும், தேவைப்பட்டால், நீங்கள் ஒரு கம்ப்யூட்டிங் கிளஸ்டரை உயர்த்தி, அதை தரவுகளால் நிரப்பும்போது, அணுகுமுறையானது OLTP சுமைகளுக்கு இன்னும் வேகமாக இல்லை. OLAP பணிகளுக்கு வினாடிகள் காத்திருப்பது இயல்பானது, ஆனால் OLTP பணிகளுக்கு இது ஏற்றுக்கொள்ள முடியாதது; 100 எம்எஸ் சிறப்பாக இருக்கும் அல்லது 10 எம்எஸ் இன்னும் சிறப்பாக இருக்கும்.
இதன் விளைவாக
தரவுத்தளத்தை ஸ்டேட்லெஸ் மற்றும் ஸ்டேட்ஃபுல் பகுதிகளாகப் பிரிப்பதன் மூலம் சர்வர்லெஸ் டேட்டாபேஸ் சாத்தியமாகும். மேலே உள்ள எல்லா எடுத்துக்காட்டுகளிலும், ஸ்டேட்ஃபுல் பகுதியானது, ஒப்பீட்டளவில், S3 இல் மைக்ரோ-பார்ட்டிஷன்களை சேமித்து வைப்பதை நீங்கள் கவனித்திருக்கலாம், மேலும் ஸ்டேட்லெஸ் என்பது மெட்டாடேட்டாவுடன் பணிபுரியும், சுதந்திரமான இலகுரக நிலையற்ற சேவைகளாக எழுப்பப்படும் பாதுகாப்புச் சிக்கல்களைக் கையாள்வது.
SQL வினவல்களை இயக்குவது ஸ்னோஃப்ளேக் கம்ப்யூட்டிங் கிளஸ்டர்கள் போன்ற சர்வர்லெஸ் பயன்முறையில் பாப்-அப் செய்யக்கூடிய லைட்-ஸ்டேட் சேவைகளாகவும் கருதப்படலாம், தேவையான தரவை மட்டும் பதிவிறக்கம் செய்து, வினவலை இயக்கி "வெளியே போ".
சேவையில்லாத உற்பத்தி நிலை தரவுத்தளங்கள் ஏற்கனவே பயன்பாட்டிற்கு கிடைக்கின்றன, அவை செயல்படுகின்றன. இந்த சர்வர்லெஸ் தரவுத்தளங்கள் ஏற்கனவே OLAP பணிகளை கையாள தயாராக உள்ளன. துரதிருஷ்டவசமாக, OLTP பணிகளுக்கு அவை பயன்படுத்தப்படுகின்றன... நுணுக்கங்களுடன், வரம்புகள் இருப்பதால். ஒருபுறம், இது ஒரு மைனஸ். ஆனால், மறுபுறம், இது ஒரு வாய்ப்பு. அரோராவின் வரம்புகள் இல்லாமல், OLTP தரவுத்தளத்தை முற்றிலும் சேவையகமற்றதாக மாற்றும் வழியை வாசகர்களில் ஒருவர் கண்டுபிடிப்பார்.
நீங்கள் அதை சுவாரஸ்யமாகக் கண்டீர்கள் என்று நம்புகிறேன். சர்வர்லெஸ் தான் எதிர்காலம் :)
ஆதாரம்: www.habr.com