postgresql இல் வீக்கத்திற்கு வழிவகுக்கும் பயன்பாடுகளில் வழக்கமான பிழைகள். ஆண்ட்ரி சல்னிகோவ்

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

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

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

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

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

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

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

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

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

சேவையகத்தின் சராசரி மறுமொழி நேரமும் நிலையானது மற்றும் குறுகியது. இது மேல் வலதுபுற வரைபடம்.

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

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

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

இப்போது எங்களுக்கு ஒரு சோகம் உள்ளது. சில காரணங்களால் நீண்ட காலமாக மறக்கப்பட்ட பரிவர்த்தனை உள்ளது. காரணங்கள் பொதுவாக சாதாரணமானவை:

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

இது போன்ற விஷயங்கள் எங்கு செல்கிறது?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

விபத்தின் போது என்ன நடந்தது? இந்த செயல்முறை அங்கு எப்படி நடந்தது?

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

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

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

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

நமக்கு என்ன விளைவுகள் ஏற்படக்கூடும்?

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

இந்த நோக்கத்திற்காக ஒரு குறிப்பிட்ட சுழற்சி வேலை செய்யப்படுகிறது.

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

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

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

எல்லாவற்றையும் சரிசெய்து, எல்லாம் சரியாக இருப்பதை உறுதிசெய்த பிறகு, எதிர்காலத்தில் இந்த சூழ்நிலையை எவ்வாறு தடுப்பது என்பதை நாம் தெரிந்து கொள்ள வேண்டும்:

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

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

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

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

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

இரண்டாவது கதை, இதில் நாங்கள் சுமைகளை விநியோகிக்கிறோம் மற்றும் சேவையக வளங்களை மேம்படுத்துகிறோம்

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

அதே வழியில் விளைவுகளை அகற்றுவோம்:

• வீங்கிய அட்டவணைகளைக் காண்கிறோம்.
• மேலும் நமக்கு ஏற்ற மிகவும் வசதியான கருவி மூலம் அதை சுருக்குகிறோம்.

இரண்டாவது கதை இத்துடன் முடிகிறது. மூன்றாவது கதைக்கு செல்வோம்.

நாம் இடம்பெயர்வது எங்களுக்கு மிகவும் பொதுவானது.

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

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

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

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

இடம்பெயர்வு வெற்றிகரமாக இருந்தது, ஆனால்:

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

இது மீண்டும் வீக்கம், இது மீண்டும் நம் வாழ்க்கையை அழிக்கிறது.

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

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

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

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

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

இங்குதான் மூன்றாவது கதை முடிகிறது.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

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

வீக்கத்தைத் தேடுவதற்கு முன், நீங்கள் நீட்டிப்பை நிறுவ வேண்டும் pgstattuple.

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

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

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

இப்போது வீக்கத்தை எவ்வாறு சரிசெய்வது என்பது பற்றி:

• எங்களிடம் ஒரு சிறிய டேப்லெட் மற்றும் நல்ல வட்டுகள் இருந்தால், அதாவது, ஒரு ஜிகாபைட் வரையிலான டேப்லெட்டில், VACUUM FULL ஐப் பயன்படுத்துவது மிகவும் சாத்தியமாகும். அவர் உங்களிடமிருந்து ஒரு பிரத்யேக பூட்டை மேசையில் சில நொடிகளுக்கு எடுத்துச் சென்று சரி செய்வார், ஆனால் அவர் எல்லாவற்றையும் விரைவாகவும் கடுமையாகவும் செய்வார். VACUUM FULL என்ன செய்கிறது? இது மேசையில் ஒரு பிரத்யேக பூட்டை எடுத்து, பழைய டேபிள்களில் இருந்து நேரடி வரிசைகளை புதிய அட்டவணையில் மீண்டும் எழுதுகிறது. இறுதியில் அவர் அவர்களை மாற்றுகிறார். இது பழைய கோப்புகளை நீக்குகிறது மற்றும் பழைய கோப்புகளை புதியதாக மாற்றுகிறது. ஆனால் அதன் வேலையின் காலத்திற்கு, அது மேஜையில் ஒரு பிரத்யேக பூட்டை எடுக்கும். இந்த அட்டவணையில் நீங்கள் எதையும் செய்ய முடியாது என்பதே இதன் பொருள்: அதற்கு எழுதவோ, படிக்கவோ அல்லது மாற்றவோ வேண்டாம். மேலும் VACUUM FULL க்கு தரவை எழுத கூடுதல் வட்டு இடம் தேவைப்படுகிறது.
• அடுத்த கருவி pg_repack. அதன் கொள்கையில், இது VACUUM FULL க்கு மிகவும் ஒத்திருக்கிறது, ஏனெனில் இது பழைய கோப்புகளிலிருந்து புதியவற்றுக்கு தரவை மீண்டும் எழுதுகிறது மற்றும் அவற்றை அட்டவணையில் மாற்றுகிறது. ஆனால் அதே நேரத்தில், இது அதன் வேலையின் ஆரம்பத்தில் மேசையில் ஒரு பிரத்யேக பூட்டை எடுக்காது, ஆனால் கோப்புகளை மாற்றுவதற்கு ஏற்கனவே தயாராக தரவு இருக்கும் தருணத்தில் மட்டுமே அதை எடுக்கும். அதன் வட்டு வள தேவைகள் VACUUM FULL இன் தேவைகளைப் போலவே இருக்கும். உங்களுக்கு கூடுதல் வட்டு இடம் தேவை, மேலும் உங்களிடம் டெராபைட் அட்டவணைகள் இருந்தால் இது சில நேரங்களில் முக்கியமானதாக இருக்கும். மேலும் இது செயலிக்கு மிகவும் பசியாக உள்ளது, ஏனெனில் இது I/O உடன் செயலில் வேலை செய்கிறது.
• மூன்றாவது பயன்பாடாகும் pgcompactable. இது சற்று மாறுபட்ட கொள்கைகளின்படி செயல்படுவதால், வளங்களில் மிகவும் கவனமாக உள்ளது. pgcompactable இன் முக்கிய யோசனை என்னவென்றால், இது அட்டவணையில் உள்ள புதுப்பிப்புகளைப் பயன்படுத்தி அனைத்து நேரடி வரிசைகளையும் அட்டவணையின் தொடக்கத்திற்கு நகர்த்துகிறது. பின்னர் அது இந்த அட்டவணையில் ஒரு வெற்றிடத்தை இயக்குகிறது, ஏனென்றால் தொடக்கத்தில் நேரடி வரிசைகளும் இறுதியில் இறந்த வரிசைகளும் உள்ளன என்பதை நாங்கள் அறிவோம். வெற்றிடமே இந்த வாலைத் துண்டிக்கிறது, அதாவது இதற்கு அதிக கூடுதல் வட்டு இடம் தேவையில்லை. அதே நேரத்தில், அது இன்னும் வளங்களின் அடிப்படையில் பிழியப்படலாம்.

கருவிகளுடன் எல்லாம்.

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

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - இது எனது சக ஊழியரின் அறிக்கை. போஸ்ட்கிரெஸின் இடம் அதன் வேலை மற்றும் வாழ்க்கையின் போது எங்கு செல்கிறது என்பது பொதுவானது. தரவுத்தள நிர்வாகிகளுக்கு ப்ளோட் பற்றி மிகப் பெரிய மற்றும் விரிவான தொழில்நுட்பத் துண்டு உள்ளது.
• https://github.com/dataegret/pg-utils - இது எங்கள் களஞ்சியத்திற்கான இணைப்பு, தரவுத்தளத்தின் நிலையைச் சரிபார்க்க பயனுள்ள ஸ்கிரிப்ட்களை நாங்கள் சேமித்து வைக்கிறோம். அங்கு நீங்கள் ப்ளோட்டைத் தேட ஸ்கிரிப்ட்களைக் காணலாம்.
• மூன்றாவது и நான்காவது அறிகுறிகளை சுருக்க உதவும் கருவிகளுக்கான இணைப்புகள்.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - இது எனது சக ஊழியரின் இடுகை. அங்கு அவர் மிகவும் தீவிரமாகவும் தொழில்நுட்ப ரீதியாகவும் நிர்வாகிகளுக்கு நெருக்கமான மட்டத்தில் வீக்கத்தை விரிவாக பகுப்பாய்வு செய்கிறார்.

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

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

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

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

நான் ஒரு நிர்வாகி.

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

ஒவ்வொரு 5 நிமிடங்களுக்கும் நான் வந்து பார்க்க வேண்டுமா?

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

இது ஏன் நடக்கிறது என்பதற்கு ஏதேனும் வெளிப்படையான காரணங்கள் உள்ளதா?

சிலவற்றை பட்டியலிட்டுள்ளேன். மற்ற மிகவும் சிக்கலான எடுத்துக்காட்டுகள். மேலும் நீண்ட நேரம் உரையாடலாம்.

அறிக்கைக்கு நன்றி! நான் pg_repack பயன்பாடு பற்றி தெளிவுபடுத்த விரும்பினேன். அவள் பிரத்தியேக பூட்டைச் செய்யவில்லை என்றால், பிறகு...

அவள் ஒரு பிரத்தியேக பூட்டை செய்கிறாள்.

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

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

அதாவது, அவர் உண்மையில் அதை இறுதியில் செய்கிறாரா?

இறுதியில், இந்த கோப்புகளை மாற்றுவதற்கு அவர் ஒரு பிரத்யேக பூட்டை எடுக்கிறார்.

இது VACUUM FULL ஐ விட வேகமாக இருக்குமா?

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

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

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

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

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

அறிக்கைக்கு நன்றி! கால அளவைக் கட்டுப்படுத்த, அறிக்கை காலாவதி வினவல்களைப் பயன்படுத்துவது ஏற்கத்தக்கதா?

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

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

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

அதாவது, புதுப்பித்த உடனேயே அது மூடப்படும்?

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

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

சர்வரில் உள்ள இடத்தை சரியாக கண்காணிக்க வேண்டும்.

எடுத்துக்காட்டாக, டிபிஏ தேநீருக்குச் சென்றது, ரிசார்ட்டில் இருந்தது போன்றவை.

ஒரு கோப்பு முறைமை உருவாக்கப்படும்போது, ​​தரவு எழுதப்படாத இடத்தில் குறைந்தபட்சம் சில வகையான காப்புப்பிரதிகள் உருவாக்கப்படும்.

பூஜ்ஜியத்திற்குக் கீழே முழுமையாக இருந்தால் என்ன செய்வது?

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

வேறு ஏதேனும் கருவிகள் உள்ளதா?

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

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

அவர்களும் பேக் செய்கிறார்கள்.

ஆனால் வெற்றிடமானது குறியீட்டை பாதிக்கவில்லையா?

சிலர் குறியீட்டுடன் வேலை செய்கிறார்கள். எடுத்துக்காட்டாக, pg_rapack, pgcompactable. வெற்றிடமானது குறியீடுகளை மீண்டும் உருவாக்கி அவற்றைப் பாதிக்கிறது. VACUUM FULL மூலம் எல்லாவற்றையும் மேலெழுத வேண்டும், அதாவது இது அனைவருடனும் வேலை செய்கிறது.

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

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

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

இது ஒரு சேவை ஓக்மீட்டர்.

இது வணிகப் பொருளா?

ஆம். இது ஒரு வணிக தயாரிப்பு.

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