அன்பே நீக்கு. நிகோலாய் சமோக்வலோவ் (Postgres.ai)

தொலைதூர எதிர்காலத்தில், தேவையற்ற தரவை தானாக அகற்றுவது DBMS இன் முக்கியமான பணிகளில் ஒன்றாக இருக்கும் [1]. இதற்கிடையில், தேவையற்ற தரவை நீக்குவதையோ அல்லது குறைந்த விலை சேமிப்பக அமைப்புகளுக்கு நகர்த்துவதையோ நாமே கவனித்துக் கொள்ள வேண்டும். சில மில்லியன் வரிசைகளை நீக்க முடிவு செய்துள்ளீர்கள் என்று வைத்துக்கொள்வோம். மிகவும் எளிமையான பணி, குறிப்பாக நிபந்தனை தெரிந்திருந்தால் மற்றும் பொருத்தமான குறியீடு இருந்தால். "அட்டவணை 1 இல் இருந்து நீக்கு col1 = :மதிப்பு" - எது எளிமையாக இருக்க முடியும், இல்லையா?

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

• நான் ஹைலோடு திட்டக் குழுவில் முதல் வருடம் முதல், அதாவது 2007 முதல் இருந்தேன்.

• நான் 2005 முதல் போஸ்ட்கிரெஸுடன் இருக்கிறேன். பல திட்டங்களில் பயன்படுத்தப்பட்டது.

• 2007 முதல் RuPostges உடன் குழு.

• மீட்அப்பில் 2100+ பங்கேற்பாளர்களாக நாங்கள் வளர்ந்துள்ளோம். இது நியூயார்க்கிற்குப் பிறகு உலகில் இரண்டாவது இடத்தில் உள்ளது, நீண்ட காலமாக சான் பிரான்சிஸ்கோவால் முந்தியது.

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

https://postgres.ai/ எனது நிறுவனம். வளர்ச்சி மந்தநிலையை நீக்கும் பணிகளை தானியக்கமாக்குவதில் நாங்கள் ஈடுபட்டுள்ளோம்.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

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

ஜெட்டாபைட்டுகளின் உலகில் அதிகமான தரவுகள் உள்ளன - அது 1 பெட்டாபைட்டுகள். இப்போது உலகில் 000 zettabytes க்கும் அதிகமான தரவு சேமிக்கப்பட்டுள்ளது என்று ஏற்கனவே மதிப்பிடப்பட்டுள்ளது. மேலும் அவற்றில் அதிகமானவை உள்ளன.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

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

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

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

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

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

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

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

தரவுத்தளம் வளர்ந்து வளர்கிறது. தினசரி DELETE இன்னும் கொஞ்சம் மெதுவாக வேலை செய்யத் தொடங்குகிறது.

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

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

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

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

ஏதோ தவறு நடந்துவிட்டது? என்ன தவறு நடந்திருக்கலாம் என்பதற்கான பட்டியல் இங்கே. இவற்றில் எது மிக முக்கியமானது?

• எடுத்துக்காட்டாக, மதிப்பாய்வு எதுவும் இல்லை, அதாவது DBA நிபுணர் அதைப் பார்க்கவில்லை. அவர் உடனடியாக ஒரு அனுபவமிக்க கண் மூலம் சிக்கலைக் கண்டுபிடிப்பார், தவிர, பல மில்லியன் வரிகள் குவிந்துள்ள தயாரிப்புக்கான அணுகல் அவருக்கு உள்ளது.

• ஒருவேளை அவர்கள் ஏதாவது தவறாகச் சரிபார்த்திருக்கலாம்.

• ஒருவேளை வன்பொருள் காலாவதியானது மற்றும் நீங்கள் இந்த தளத்தை மேம்படுத்த வேண்டும்.

• அல்லது தரவுத்தளத்திலேயே ஏதோ தவறு உள்ளது, மேலும் நாம் Postgres இலிருந்து MySQL க்கு செல்ல வேண்டும்.

• அல்லது ஆபரேஷனில் ஏதேனும் தவறு இருக்கலாம்.

• வேலை அமைப்பில் சில தவறுகள் இருக்கலாம் மற்றும் நீங்கள் ஒருவரை பணிநீக்கம் செய்து சிறந்த நபர்களை பணியமர்த்த வேண்டுமா?

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

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

http://bit.ly/nancy-hl2018-2

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

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

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

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

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

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

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

Postgres இல் உள்ள அமைப்புகள் பின்தங்கி உள்ளன. அவை 10-15 ஆண்டுகள் பழமையான தரவு மற்றும் பரிவர்த்தனைகளுக்காக வடிவமைக்கப்பட்டுள்ளன. மற்றும் சோதனைச் சாவடி விதிவிலக்கல்ல.

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

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

மேலும் இயல்பாக max_wal_saze 1 ஜிகாபைட்டாக அமைக்கப்பட்டுள்ளது. உண்மையில், இது உண்மையில் 300-400 மெகாபைட்டுகளுக்குப் பிறகு போஸ்ட்கிரெஸில் நடக்கும். நீங்கள் பல தரவை மாற்றியுள்ளீர்கள், உங்கள் சோதனைச் சாவடி நடக்கிறது.

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

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

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

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

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

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

அடுத்து நாம் max_wal_size ஐ அதிகரிக்கிறோம். மீண்டும் சொல்கிறோம். நாங்கள் அதிகரிக்கிறோம், மீண்டும் செய்கிறோம். மற்றும் பல முறை. கொள்கையளவில், 10 புள்ளிகள் நல்லது, அங்கு 1, 2, 4, 8 ஜிகாபைட்கள். ஒரு குறிப்பிட்ட அமைப்பின் நடத்தையைப் பார்க்கிறோம். இங்கே உபகரணங்கள் தயாரிப்பில் இருக்க வேண்டும் என்பது தெளிவாகிறது. உங்களிடம் ஒரே வட்டுகள், அதே அளவு நினைவகம் மற்றும் அதே Postgres அமைப்புகள் இருக்க வேண்டும்.

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

ரஷ்ய மொழியில் சோதனைச் சாவடிகள் சோதனைச் சாவடிகள்.

எடுத்துக்காட்டு: குறியீட்டின்படி பல மில்லியன் வரிசைகளை நீக்கவும், வரிசைகள் பக்கங்களில் "சிதறடிக்கப்படுகின்றன".

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

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

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

மேலும் 64 ஜிகாபைட்கள் முற்றிலும் சிறப்பாக மாறியிருப்பதைக் காணலாம். ஏற்கனவே பற்கள் உச்சரிக்கப்படுகின்றன, மற்ற செயல்பாடுகளைத் தக்கவைத்து, வட்டுடன் ஏதாவது செய்ய அதிக வாய்ப்புகள் உள்ளன.

அது ஏன்?

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

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

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

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

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

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

மேலும், அதன்படி, சோதனைச் சாவடி மீண்டும் நடந்தால், நாம் புதிதாக எல்லாவற்றையும் மீண்டும் தொடங்கி முழு பக்கத்தையும் தள்ள வேண்டும். அடிக்கடி சோதனைச் சாவடிகளில், அதே பக்கங்களில் நடக்கும்போது, ​​full_page_writes = on என்பது அதை விட அதிகமாக இருக்கும், அதாவது அதிக WAL ஐ உருவாக்குகிறோம். மேலும் பிரதிகள், காப்பகத்திற்கு, வட்டுக்கு அனுப்பப்படும்.

மேலும், அதன்படி, எங்களுக்கு இரண்டு பணிநீக்கங்கள் உள்ளன.

நாம் max_wal_size ஐ அதிகரித்தால், சோதனைச் சாவடி மற்றும் வால் ரைட்டர் ஆகிய இரண்டிற்கும் எளிதாக்குகிறோம். அதுவும் நன்றாக இருக்கிறது.

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

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

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

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

வெவ்வேறு max_wal_size அளவுகளுக்கு இதுபோன்ற சூழ்நிலையை நாங்கள் அளவிடுகிறோம் மற்றும் max_wal_size 64 ஜிகாபைட்களாக இருந்தால், இரட்டை மோசமான நிலையில் 10 நிமிடங்களுக்கு ஏறுவோம். அது நமக்குப் பொருந்துகிறதா இல்லையா என்று நாம் சிந்திக்கிறோம். இது ஒரு வணிகக் கேள்வி. வணிக முடிவுகளுக்குப் பொறுப்பானவர்களிடம் இந்தப் படத்தைக் காட்டி, “ஒரு பிரச்சனை ஏற்பட்டால் அதிகபட்சம் எவ்வளவு நேரம் படுக்கலாம்? மோசமான சூழ்நிலையில் 3-5 நிமிடங்கள் படுக்க முடியுமா? மற்றும் நீங்கள் ஒரு முடிவை எடுங்கள்.

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

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

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

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

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

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

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

ROLLBACK உடன் இந்த DELETE ஆனது செக்பாயிண்ட் டியூனிங்கிற்கு ஏற்றதாக இருக்கும், உங்களிடம் சரியான தரவுத்தள ஆய்வகங்கள் இல்லாவிட்டாலும் கூட.

"i" என்ற ஒரு நெடுவரிசையுடன் ஒரு தட்டு செய்தோம். Postgres பயன்பாட்டு நெடுவரிசைகளைக் கொண்டுள்ளது. குறிப்பாகக் கேட்கப்படாவிட்டால் அவை கண்ணுக்குத் தெரியாதவை. அவை: ctid, xmid, xmax.

Ctid என்பது ஒரு உடல் முகவரி. பூஜ்ஜிய பக்கம், பக்கத்தின் முதல் டூப்பிள்.

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

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

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

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

உடைப்பது ஏன் முக்கியம்?

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

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

https://postgres.ai/products/joe/

இது மிகவும் சுவாரஸ்யமானது. டெவலப்பர்கள் கேட்பதை நான் அடிக்கடி பார்க்கிறேன்: "நான் எந்த பேக் அளவை தேர்வு செய்ய வேண்டும்?".

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

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

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

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

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

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

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

பகிர்வு உத்திகள் என்ன? தொகுப்பில் உள்ள டெவலப்பர்கள் பயன்படுத்தும் 3 வெவ்வேறு பகிர்வு உத்திகளை நான் காண்கிறேன்.

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

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

முதல் மூலோபாயத்திலும், நீங்கள் இதை பல நூல்களில் செய்யலாம். இது கடினம் அல்ல.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

பொதுவாக, இன்டெக்ஸ் ஸ்கேன் செய்வதை விட இன்டெக்ஸ் மட்டும் ஸ்கேன் வேகமானது.

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

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

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

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

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

நீண்ட பரிவர்த்தனைகள் https://gitlab.com/snippets/1890447

தடுக்கப்பட்ட ஆட்டோவாக்யூம் - https://gitlab.com/snippets/1889668

தடுக்கும் பிரச்சனை - https://gitlab.com/snippets/1890428

தவறு #5 பெரியது. Okmeter இலிருந்து Nikolai Postgres கண்காணிப்பு பற்றி பேசினார். ஐடியல் போஸ்ட்கிரெஸ் கண்காணிப்பு, துரதிருஷ்டவசமாக, இல்லை. சிலர் நெருக்கமாக இருக்கிறார்கள், சிலர் தொலைவில் இருக்கிறார்கள். ஆக்மீட்டர் சரியானதாக இருக்கும் அளவுக்கு நெருக்கமாக உள்ளது, ஆனால் நிறைய காணவில்லை மற்றும் சேர்க்க வேண்டும். இதற்கு நீங்கள் தயாராக இருக்க வேண்டும்.

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

ஒரு பெரிய IO இருந்தால், இது நல்லதல்ல என்பது தெளிவாகிறது.

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

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

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

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

சில நேரங்களில் இந்த பிழைகள் அனைத்தும் கூட்டுத்தொகையில் நிகழ்கின்றன.

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

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

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

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

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

நாம் செய்வது ஓப்பன் சோர்ஸ். இது GitLab இல் வெளியிடப்பட்டது. DBA இல்லாவிட்டாலும் மக்கள் சரிபார்க்கும் வகையில் நாங்கள் இதைச் செய்கிறோம். நாங்கள் ஒரு தரவுத்தள ஆய்வகத்தைச் செய்கிறோம், அதாவது ஜோ தற்போது பணிபுரியும் அடிப்படை கூறுகளை நாங்கள் அழைக்கிறோம். நீங்கள் தயாரிப்பின் நகலை எடுக்கலாம். இப்போது ஜோ ஃபார் ஸ்லாக்கின் செயலாக்கம் உள்ளது, நீங்கள் அங்கு கூறலாம்: "அத்தகைய மற்றும் அத்தகைய கோரிக்கையை விளக்குங்கள்" மற்றும் உங்கள் தரவுத்தளத்தின் நகலுக்கான முடிவை உடனடியாகப் பெறுங்கள். நீங்கள் அங்கு கூட நீக்கலாம், யாரும் அதை கவனிக்க மாட்டார்கள்.

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

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

எடுத்துக்காட்டு: 5 டெராபைட் தரவுத்தளம், 30 வினாடிகளுக்குள் நகலைப் பெறுதல். மேலும் இது அளவைப் பொறுத்தது அல்ல, அதாவது எத்தனை டெராபைட்கள் என்பது முக்கியமல்ல.

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

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

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

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

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

நீங்கள் GitHub இல் pg_repack ஐப் பார்த்தால், அங்கு, ஒரு ஐடியை int 4 இலிருந்து int 8 ஆக மாற்றும் பணி இருக்கும்போது, ​​​​pg_repack ஐப் பயன்படுத்த ஒரு யோசனை இருந்தது. இதுவும் சாத்தியம், ஆனால் இது ஒரு ஹேக், ஆனால் இதற்கும் இது வேலை செய்யும். pg_repack பயன்படுத்தும் தூண்டுதலில் நீங்கள் தலையிட்டு, "இந்தத் தரவு எங்களுக்குத் தேவையில்லை" என்று கூறலாம், அதாவது நமக்குத் தேவையானதை மட்டும் மாற்றுவோம். பின்னர் அவர் மாறுகிறார், அவ்வளவுதான்.

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

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

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

ஆனால் அது 90% இருந்தால் மட்டுமே. நம்மிடம் 5% இருந்தால், அதைப் பயன்படுத்துவது மிகவும் நல்லதல்ல.

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

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

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

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

குறியீடுகளுடன் முடிந்தது.

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

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

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

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

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

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

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

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

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

போஸ்ட்கிரெஸில் autovacuum தானாகவே இதைத்தான் செய்கிறது.

ஓ, அவர் அதை செய்கிறாரா?

Autovacuum குப்பை சேகரிப்பான்.

நன்றி!

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

நிச்சயமாக உள்ளது.

பயன்படுத்தக்கூடாத மேஜையைப் பூட்டியிருந்தால் நம்மைப் பாதுகாத்துக்கொள்ள முடியுமா?

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

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