DBA போட் ஜோ. அனடோலி ஸ்டான்ஸ்லர் (Postgres.ai)

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

வீடியோக்கள்:

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

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

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

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

உற்பத்தியில் நேரடியாக குறியீடுகளை உருவாக்கியவர் அல்லது ஏதேனும் மாற்றங்களைச் செய்தவர் யார்? கொஞ்சம். தரவு தொலைந்து போனது அல்லது வேலையில்லா நேரம் இருப்பது யாருக்கு வழிவகுத்தது? அப்போதுதான் இந்த வலி தெரியும். கடவுளுக்கு நன்றி காப்புப்பிரதிகள் உள்ளன.

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

இது வலிக்கிறது, அது விலை உயர்ந்தது. ஒருவேளை செய்யாமல் இருப்பது நல்லது.

மற்றும் அதைச் செய்வதற்கான சிறந்த வழி என்ன?

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

இது சில பிழைகளை அகற்ற அனுமதிக்கும், அதாவது அவை தயாரிப்பில் இருப்பதைத் தடுக்கும்.

பிரச்சனைகள் என்ன?

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

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

இது முந்தைய அணுகுமுறையை விட சிறந்தது, ஆனால் இன்னும் சில வகையான பிழைகள் உற்பத்திக்கு செல்லும் அதிக நிகழ்தகவு உள்ளது.

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

டெராபைட்டை விட பெரிய தரவுத்தளத்தை வைத்திருப்பவர் யார்? பாதி அறைக்கு மேல்.

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

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

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

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

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

மேலும் இது சாத்தியம்.

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

உண்மையான உதாரணம்:

• DB - 4,5 டெராபைட்கள்.

• 30 வினாடிகளில் சுதந்திரமான நகல்களைப் பெறலாம்.

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

இது அருமை. இங்கே நாம் மந்திரம் மற்றும் ஒரு இணையான பிரபஞ்சத்தைப் பற்றி பேசுகிறோம்.

எங்கள் விஷயத்தில், இது OpenZFS அமைப்பைப் பயன்படுத்தி செயல்படுகிறது.

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

பிற விருப்பங்கள் உள்ளன:

• எல்விஎம்,

• சேமிப்பு (உதாரணமாக, தூய சேமிப்பு).

நான் சொல்லும் டேட்டாபேஸ் லேப் மாடுலர். இந்த விருப்பங்களைப் பயன்படுத்தி செயல்படுத்தலாம். ஆனால் இப்போதைக்கு, நாங்கள் OpenZFS இல் கவனம் செலுத்தியுள்ளோம், ஏனெனில் குறிப்பாக LVM இல் சிக்கல்கள் இருந்தன.

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

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

இந்த பயனர் அத்தகைய தரவு தொகுப்புடன் வேலை செய்வார். அவர் படிப்படியாக அவற்றை மாற்றி, தனது சொந்த ஸ்னாப்ஷாட்களை உருவாக்குவார்.

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

அத்தகைய அமைப்பை வீட்டில் வரிசைப்படுத்த, நீங்கள் இரண்டு சிக்கல்களை தீர்க்க வேண்டும்:

• முதலாவது தரவுகளின் ஆதாரம், நீங்கள் அதை எங்கிருந்து எடுப்பீர்கள். நீங்கள் உற்பத்தி மூலம் பிரதியை அமைக்கலாம். நீங்கள் ஏற்கனவே கட்டமைத்த காப்புப்பிரதிகளைப் பயன்படுத்தலாம், நான் நம்புகிறேன். WAL-E, WAL-G அல்லது Barman. நீங்கள் RDS அல்லது Cloud SQL போன்ற கிளவுட் தீர்வைப் பயன்படுத்தினாலும், நீங்கள் லாஜிக்கல் டம்ப்களைப் பயன்படுத்தலாம். ஆனால் காப்புப்பிரதிகளைப் பயன்படுத்த நாங்கள் இன்னும் உங்களுக்கு அறிவுறுத்துகிறோம், ஏனெனில் இந்த அணுகுமுறையின் மூலம் நீங்கள் கோப்புகளின் இயற்பியல் கட்டமைப்பைத் தக்கவைத்துக்கொள்வீர்கள், இது இருக்கும் சிக்கல்களைப் பிடிக்க தயாரிப்பில் நீங்கள் காணும் அளவீடுகளுக்கு இன்னும் நெருக்கமாக இருக்க அனுமதிக்கும்.

• இரண்டாவது நீங்கள் தரவுத்தள ஆய்வகத்தை ஹோஸ்ட் செய்ய விரும்பும் இடம். அது கிளவுடாக இருக்கலாம், ஆன்-பிரைமைஸாக இருக்கலாம். ZFS தரவு சுருக்கத்தை ஆதரிக்கிறது என்பதை இங்கே கூறுவது முக்கியம். மற்றும் அது நன்றாக செய்கிறது.

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

அத்தகைய அமைப்பு வெவ்வேறு நிகழ்வுகளுக்கு பயன்படுத்தப்படலாம்.

• இவை டெவலப்பர்கள், வினவல் சரிபார்ப்புக்கான டிபிஏக்கள், தேர்வுமுறைக்கு.

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

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

இந்த அணுகுமுறையுடன்:

1. முழு அளவிலான தரவுகளில் அனைத்து மாற்றங்களையும் நாங்கள் சோதித்ததால், "prod" இல் பிழைகள் ஏற்படுவதற்கான நிகழ்தகவு குறைவு.

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

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

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

• நாம் மாற்ற முடியாத மாற்றங்களை மாற்ற முடியும். இது நிலையான அணுகுமுறை அல்ல.

1. சோதனை பெஞ்சுகளின் வளங்களை நாங்கள் பகிர்ந்து கொள்வதால் இது நன்மை பயக்கும்.

ஏற்கனவே நல்லது, ஆனால் வேறு என்ன துரிதப்படுத்த முடியும்?

அத்தகைய அமைப்புக்கு நன்றி, அத்தகைய சோதனையில் நுழைவதற்கான நுழைவாயிலை நாம் பெரிதும் குறைக்க முடியும்.

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

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

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

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

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

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

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

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

உற்பத்தியில் உள்ள அதே வன்பொருளை வைத்திருப்பது நன்றாக இருக்கும், ஆனால் அது வேறுபட்டிருக்கலாம்.

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

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

இரண்டாவது கேச் கிடைக்கக்கூடிய அனைத்து இடத்தையும் பயன்படுத்துகிறது.

ஒரு கணினியில் பல குளோன்களை உருவாக்கும்போது, ​​படிப்படியாக நினைவகத்தை நிரப்புகிறோம். மேலும் ஒரு நல்ல வழியில், ஷேர்டு பஃபர் கேச் என்பது கணினியில் கிடைக்கும் மொத்த நினைவகத்தின் 25% ஆகும்.

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

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

எடுத்துக்காட்டாக, ப்ராடில் ஒரு பெரிய கேச் இருந்தால், Postgres ஒரு குறியீட்டைப் பயன்படுத்த விரும்புகிறது. இல்லையெனில், SeqScan இருக்கும். எங்கள் திட்டங்கள் ஒத்துப்போகவில்லை என்றால் என்ன பயன்?

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

Effective_cache_size என்பது நமக்குக் கிடைக்கும் தற்காலிக சேமிப்பின் மதிப்பிடப்பட்ட அளவு, அதாவது Buffer Cache மற்றும் கோப்பு முறைமை தற்காலிக சேமிப்பின் கூட்டுத்தொகை. இது கட்டமைப்பால் அமைக்கப்பட்டுள்ளது. இந்த நினைவகம் ஒதுக்கப்படவில்லை.

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

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

• இது தற்போது உற்பத்தியில் இருக்கும் சுமையைப் பொறுத்தது.

• இது இயந்திரத்தின் பண்புகளைப் பொறுத்தது.

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

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

ஜோ குறிப்பாக எப்படி உகந்ததாக இருக்கிறார் என்பதைப் பார்ப்போம்.

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

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

திட்டம் மற்றும் அளவீடுகளின் அடிப்படையில் பி ஜோ உங்களுக்கு தானியங்கி பரிந்துரைகளைக் காண்பிப்பார்.

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

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

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

வினவலில் உள்ள நிபந்தனைகளும் குறியீட்டில் உள்ள நிபந்தனைகளும் ஓரளவு பொருந்தாததால் இது திட்டத்தில் நடந்தது.

குறியீட்டை இன்னும் துல்லியமாக்க முயற்சிப்போம், அதன் பிறகு வினவல் செயல்படுத்தல் எவ்வாறு மாறுகிறது என்பதைப் பார்ப்போம்.

குறியீட்டை உருவாக்க நீண்ட நேரம் எடுத்தது, ஆனால் இப்போது வினவலைச் சரிபார்த்து, 2,5 நிமிடங்களுக்குப் பதிலாக நேரம் 156 மில்லி விநாடிகள் மட்டுமே உள்ளது, இது போதுமானது. மேலும் நாம் 6 மெகாபைட் தரவுகளை மட்டுமே படிக்கிறோம்.

இப்போது நாம் குறியீட்டை மட்டும் ஸ்கேன் பயன்படுத்துகிறோம்.

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

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

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

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

மேலும் இந்த தலைப்பை இன்னும் ஆராயாத டெவலப்பர்கள் விளக்கவும்.depesz.com ஐப் பயன்படுத்துகின்றனர், ஏனெனில் எந்த அளவீடுகள் முக்கியமானவை மற்றும் எது இல்லை என்பதைக் கண்டுபிடிப்பது அவர்களுக்கு எளிதாக இருக்கும்.

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

இணைந்து

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

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

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

இங்குதான் நான் முடிக்கிறேன். நன்றி!

உங்கள் கேள்விகள்

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

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

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

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

ஒவ்வொரு குளோனுக்கும் சில ttl உள்ளது. அடிப்படையில், எங்களிடம் ஒரு நிலையான ttl உள்ளது.

என்ன, ஒரு ரகசியம் இல்லையென்றால்?

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

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

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

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

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

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

ஆனால் ZFS அனைவருக்கும் கிடைக்கிறது. DelPhix ஏற்கனவே போதுமானது, அவர்களுக்கு 300 வாடிக்கையாளர்கள் உள்ளனர். இவற்றில், Fortune 100 க்கு 50 வாடிக்கையாளர்கள் உள்ளனர், அதாவது அவர்கள் NASA போன்றவற்றை இலக்காகக் கொண்டுள்ளனர். இந்த தொழில்நுட்பத்தை அனைவரும் பெற வேண்டிய நேரம் இது. அதனால்தான் எங்களிடம் திறந்த மூல கோர் உள்ளது. திறந்த மூலமாக இல்லாத ஒரு இடைமுகப் பகுதி எங்களிடம் உள்ளது. இதுதான் நாங்கள் காண்பிக்கும் தளம். ஆனால் அனைவருக்கும் அணுகக்கூடியதாக இருக்க வேண்டும் என்று நாங்கள் விரும்புகிறோம். அனைத்து சோதனையாளர்களும் மடிக்கணினிகளில் யூகிப்பதை நிறுத்தும் வகையில் ஒரு புரட்சியை உருவாக்க விரும்புகிறோம். SELECT என்று எழுதி, அது மெதுவாக இருப்பதை உடனடியாகப் பார்க்க வேண்டும். DBA அதைப் பற்றி உங்களுக்குச் சொல்லும் வரை காத்திருப்பதை நிறுத்துங்கள். இங்கே முக்கிய குறிக்கோள். நாம் அனைவரும் இதற்கு வருவோம் என்று நினைக்கிறேன். இந்த விஷயத்தை நாம் அனைவரும் வைத்திருக்கிறோம். எனவே ZFS, ஏனெனில் அது எல்லா இடங்களிலும் கிடைக்கும். சிக்கல்களைத் தீர்ப்பதற்கும் திறந்த மூல உரிமம் போன்றவற்றைப் பெற்றதற்கும் சமூகத்திற்கு நன்றி*

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

இரண்டாவது கேள்வி ஸ்டாண்டுகளின் ஒற்றுமையின்மை பற்றியது. இங்கே என்னிடம் ZFS உள்ளது மற்றும் எல்லாம் அருமையாக உள்ளது என்று வைத்துக்கொள்வோம், ஆனால் தயாரிப்பில் உள்ள கிளையண்டில் ZFS இல்லை, ஆனால் ext4, எடுத்துக்காட்டாக. இந்த விஷயத்தில் எப்படி?

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

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

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

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

MySQL பற்றி. இந்த அமைப்பை வட்டில் சேமிக்கும் எதற்கும் பயன்படுத்தலாம். நாங்கள் Postgres செய்வதால், முதலில் Postgresக்கான அனைத்து ஆட்டோமேஷனையும் செய்து வருகிறோம். காப்புப்பிரதியிலிருந்து தரவைப் பெறுவதை தானியங்குபடுத்த விரும்புகிறோம். Postgres ஐ சரியாக உள்ளமைக்கிறோம். திட்டங்களைப் பொருத்துவது போன்றவற்றை எவ்வாறு உருவாக்குவது என்பது எங்களுக்குத் தெரியும்.

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

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

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

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

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

ஒவ்வொரு முறையும் குறியீடு உருவாக்கப்படுமா?

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

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

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

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

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

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

புதுப்பிப்பு கூடுதல் லேயராக நடைபெறும் என்று மாறிவிடும், மேலும் இந்த லேயரின் அடிப்படையில் அனைத்து புதிய படங்களும் ஏற்கனவே செல்லும், இல்லையா?

முந்தைய பிரதிகளிலிருந்து முந்தைய அடுக்குகளிலிருந்து.

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

பொதுவாக, ஆம்.

அதன் பின் விளைவாக ஒரு அத்திப்பழம் வரை அடுக்குகள் இருக்கும். காலப்போக்கில் அவை சுருக்கப்பட வேண்டுமா?

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

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

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

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

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

எனக்கு இந்த அடுக்கு தேவையில்லை, ஆனால் எனக்கு அத்தகைய வாய்ப்பு தேவை.

பின்னர் ஆம், அதை செய்ய முடியும்.

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