PostgreSQL வினவல்களின் மொத்த தேர்வுமுறை. கிரில் போரோவிகோவ் (டென்சர்)

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

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

ஆர்வமுள்ளவர் யார்? குறிப்பிட்ட சிக்கல்களின் பகுப்பாய்வு மற்றும் பல்வேறு தேர்வுமுறை நுட்பங்கள் PostgreSQL இல் SQL வினவல்கள் மற்றும் வழக்கமான DBA சிக்கல்களைத் தீர்ப்பது - உங்களாலும் முடியும் தொடர் கட்டுரைகளைப் படிக்கவும் இந்த தலைப்பில்.


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

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

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

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

நாங்கள் 2008 ஆம் ஆண்டு முதல் PostgreSQL உடன் பணிபுரிந்து வருகிறோம், மேலும் நாங்கள் செயலாக்குவதில் அதிக அளவு குவித்துள்ளோம் - கிளையன்ட் தரவு, புள்ளியியல், பகுப்பாய்வு, வெளிப்புற தகவல் அமைப்புகளின் தரவு - 400TBக்கு மேல். உற்பத்தியில் மட்டும் சுமார் 250 சேவையகங்கள் உள்ளன, மொத்தத்தில் நாங்கள் கண்காணிக்கும் சுமார் 1000 தரவுத்தள சேவையகங்கள் உள்ளன.

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

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

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

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

காரணங்கள் எப்போதும் ஒரே மாதிரியானவை:

• திறனற்ற வினவல் அல்காரிதம்
  டெவலப்பர்: "இப்போது நான் அவருக்கு SQL இல் 10 டேபிள்களை JOIN மூலம் தருகிறேன்..." - மேலும் அவரது நிலைமைகள் அற்புதமாக "அவிழ்க்கப்படும்" மற்றும் அவர் எல்லாவற்றையும் விரைவாகப் பெறுவார் என்று எதிர்பார்க்கிறார். ஆனால் அற்புதங்கள் நடக்காது, அத்தகைய மாறுபாடு கொண்ட எந்த அமைப்பும் (ஒன்றில் இருந்து 10 அட்டவணைகள்) எப்போதும் ஒருவித பிழையை அளிக்கிறது. [கட்டுரை]
• காலாவதியான புள்ளிவிவரங்கள்
  இந்த புள்ளி குறிப்பாக PostgreSQL க்கு மிகவும் பொருத்தமானது, நீங்கள் சர்வரில் ஒரு பெரிய தரவுத்தொகுப்பை "ஊற்றும்போது", கோரிக்கையை விடுங்கள், அது உங்கள் டேப்லெட்டை "செக்ஸ்கானிட்" செய்கிறது. ஏனென்றால் நேற்று அதில் 10 பதிவுகள் இருந்தன, இன்று 10 மில்லியன் உள்ளன, ஆனால் PostgreSQL இதைப் பற்றி இன்னும் அறியவில்லை, அதைப் பற்றி நாம் சொல்ல வேண்டும். [கட்டுரை]
• வளங்களில் "பிளக்"
  போதுமான வட்டு, நினைவகம் அல்லது செயலி செயல்திறன் இல்லாத பலவீனமான சர்வரில் பெரிய மற்றும் அதிக ஏற்றப்பட்ட தரவுத்தளத்தை நிறுவியுள்ளீர்கள். அவ்வளவுதான்... எங்கோ ஒரு செயல்திறன் உச்சவரம்பு உள்ளது, அதற்கு மேல் நீங்கள் குதிக்க முடியாது.
• தடுக்கும்
  இது ஒரு கடினமான விஷயம், ஆனால் அவை பல்வேறு மாற்றியமைக்கும் வினவல்களுக்கு மிகவும் பொருத்தமானவை (செருகுதல், புதுப்பித்தல், நீக்குதல்) - இது ஒரு தனி பெரிய தலைப்பு.

ஒரு திட்டத்தைப் பெறுதல்

...மற்றும் எல்லாவற்றிற்கும் நாங்கள் ஒரு திட்டம் வேண்டும்! சர்வருக்குள் என்ன நடக்கிறது என்று பார்க்க வேண்டும்.

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

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

வினவல் திட்டத்தைப் பெற, அறிக்கையை செயல்படுத்துவதே எளிதான வழி EXPLAIN. அனைத்து உண்மையான பண்புகளையும் பெற, அதாவது, அடிப்படையில் ஒரு வினவலை செயல்படுத்த - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

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

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

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

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

ஆனால் அது வெளிப்படையாக இல்லாவிட்டாலும், அது சிரமமாக இருந்தாலும், இன்னும் அடிப்படை சிக்கல்கள் உள்ளன:

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

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

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

திட்டமிடல் காட்சிப்படுத்தல்

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

நாங்கள் முதலில் "சந்தை வழியாக" சென்றோம் - என்ன இருக்கிறது என்பதைப் பார்க்க இணையத்தில் பார்க்கலாம்.

ஆனால் அதிகமாகவோ அல்லது குறைவாகவோ வளரும் ஒப்பீட்டளவில் "நேரடி" தீர்வுகள் மிகக் குறைவு - அதாவது ஒன்று மட்டுமே: விளக்கவும்.depesz.com Hubert Lubaczewski மூலம். நீங்கள் "ஊட்ட" புலத்தில் திட்டத்தின் உரைப் பிரதிநிதித்துவத்தை உள்ளிடும்போது, ​​அது பாகுபடுத்தப்பட்ட தரவுகளுடன் ஒரு அட்டவணையைக் காட்டுகிறது:

• முனையின் சொந்த செயலாக்க நேரம்
• முழு சப்ட்ரீக்கான மொத்த நேரம்
• புள்ளிவிவர ரீதியாக எதிர்பார்க்கப்பட்ட பதிவுகளின் எண்ணிக்கை மீட்டெடுக்கப்பட்டது
• கணு உடல் தன்னை

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

ஆனால் சிறிய பிரச்சனைகளும் உள்ளன.

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

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

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

ஆனால் இவை அனைத்தும் “பாடல் வரிகள்”, நாம் எப்படியாவது இதனுடன் வாழ முடியும், ஆனால் இந்த சேவையிலிருந்து எங்களை பெரிதும் விலக்கிய ஒரு விஷயம் உள்ளது. இவை பொதுவான அட்டவணை வெளிப்பாடு (CTE) மற்றும் InitPlan/SubPlan போன்ற பல்வேறு டைனமிக் முனைகளின் பகுப்பாய்வில் உள்ள பிழைகள்.

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

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

வலைச் சேவைகளுக்குப் பொதுவான ஒரு அடுக்கை எடுத்துள்ளோம்: Node.js + Express அடிப்படையிலான கோர், அழகான வரைபடங்களுக்கு பூட்ஸ்டார்ப் மற்றும் D3.js ஆகியவற்றைப் பயன்படுத்தியது. எங்கள் எதிர்பார்ப்புகள் முழுமையாக நியாயப்படுத்தப்பட்டன - 2 வாரங்களில் முதல் முன்மாதிரியைப் பெற்றோம்:

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

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

இது நாம் அழைக்கும் சுருக்கமான பிரதிநிதித்துவம் திட்ட வார்ப்புரு.

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

நாங்கள் முனையை சுட்டிக்காட்டி பார்க்கிறோம் - Seq ஸ்கேன் மொத்த நேரத்தின் கால் பகுதிக்கும் குறைவாகவே எடுத்தது, மீதமுள்ள 3/4 CTE ஸ்கேன் மூலம் எடுக்கப்பட்டது. திகில்! உங்கள் வினவல்களில் நீங்கள் தீவிரமாகப் பயன்படுத்தினால், CTE ஸ்கேன் "தீ விகிதம்" பற்றிய சிறிய குறிப்பு இது. அவை மிக வேகமாக இல்லை - அவை வழக்கமான டேபிள் ஸ்கேனிங்கை விடவும் தாழ்ந்தவை. [கட்டுரை] [கட்டுரை]

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

இயற்கையாகவே, இதில் சில "ரேக்குகள்" இருந்தன.

நாங்கள் முதலில் கண்டது ரவுண்டிங் பிரச்சனை. திட்டத்தில் ஒவ்வொரு தனிப்பட்ட முனையின் நேரமும் 1 μs துல்லியத்துடன் குறிக்கப்படுகிறது. முனை சுழற்சிகளின் எண்ணிக்கை எடுத்துக்காட்டாக, 1000 ஐத் தாண்டும்போது, ​​​​செயல்பாட்டிற்குப் பிறகு PostgreSQL "துல்லியமாக" வகுக்கப்படும், பின்னர் மீண்டும் கணக்கிடும்போது மொத்த நேரத்தை "0.95ms மற்றும் 1.05ms இடையே எங்காவது" பெறுவோம். எண்ணிக்கை மைக்ரோ விநாடிகளுக்குச் செல்லும்போது, ​​அது பரவாயில்லை, ஆனால் அது ஏற்கனவே [மில்லி]வினாடிகளாக இருக்கும்போது, ​​"யார் எவ்வளவு நுகர்ந்தார்கள்" திட்டத்தின் முனைகளில் வளங்களை "அவிழ்க்கும்போது" இந்தத் தகவலை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும்.

இரண்டாவது புள்ளி, மிகவும் சிக்கலானது, டைனமிக் முனைகளுக்கு இடையில் வளங்களின் விநியோகம் (அந்த இடையகங்கள்). இது முன்மாதிரியின் முதல் 2 வாரங்களுக்கும் மேலும் 4 வாரங்களுக்கும் செலவாகும்.

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

நாங்கள் திட்டத்தைப் பார்த்து புரிந்துகொள்கிறோம் - இது விசித்திரமானது, எங்களிடம் Seq ஸ்கேனில் 3 இடையகங்கள் (தரவுப் பக்கங்கள்) “நுகர்ந்தவை”, CTE ஸ்கேனில் மேலும் 1 மற்றும் இரண்டாவது CTE ஸ்கேனில் மேலும் 2 உள்ளன. அதாவது, எல்லாவற்றையும் சுருக்கமாகச் சொன்னால், நமக்கு 6 கிடைக்கும், ஆனால் டேப்லெட்டிலிருந்து நாம் 3 ஐ மட்டுமே படிக்கிறோம்! CTE ஸ்கேன் எங்கும் எதையும் படிக்காது, ஆனால் செயல்முறை நினைவகத்துடன் நேரடியாக வேலை செய்கிறது. அதாவது, இங்கே ஏதோ தவறு தெளிவாக உள்ளது!

உண்மையில், Seq ஸ்கேனிலிருந்து கோரப்பட்ட அந்த 3 பக்க தரவுகளும் இங்கே உள்ளன, முதலில் 1 வது CTE ஸ்கேன் கேட்கப்பட்டது, பின்னர் 1வது, மேலும் 2 அவருக்குப் படிக்கப்பட்டது. அதாவது மொத்தம் 2 பக்கங்கள் படிக்கப்பட்ட தரவு, 3 அல்ல.

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

சிறிது நேரம் மூச்சை வெளியேற்றினோம். அவர்கள் சொன்னார்கள்: “இப்போது, ​​நியோ, உனக்கு குங்ஃபூ தெரியும்! இப்போது எங்கள் அனுபவம் உங்கள் திரையில் உள்ளது. இப்போது நீங்கள் அதைப் பயன்படுத்தலாம்." [கட்டுரை]

பதிவு ஒருங்கிணைப்பு

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

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

முதலாவதாக, ஒரே தரவுத்தளத்தில் வெவ்வேறு திட்டங்களைப் பயன்படுத்தி ஒரே வினவல்களுக்கு இது ஒதுக்குகிறது வெவ்வேறு QueryIds. அதாவது, நீங்கள் முதலில் செய்தால் SET search_path = '01'; SELECT * FROM user LIMIT 1;பின்னர் SET search_path = '02'; மற்றும் அதே கோரிக்கை, பின்னர் இந்த தொகுதியின் புள்ளிவிவரங்கள் வெவ்வேறு பதிவுகளைக் கொண்டிருக்கும், மேலும் இந்த கோரிக்கை சுயவிவரத்தின் சூழலில், திட்டங்களை கணக்கில் எடுத்துக் கொள்ளாமல், பொதுவான புள்ளிவிவரங்களை என்னால் சேகரிக்க முடியாது.

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

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

அதனால, காப்பி பேஸ்ட்ல சண்டை போடணும்னு முடிவு பண்ணி எழுத ஆரம்பிச்சோம் கலெக்டர்.

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

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

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

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

இவை அனைத்தும் சேர்க்கப்பட வேண்டும், தரவு ஓட்டம் பெரியது மற்றும் செயலில் உள்ளது. உண்மையில், நாம் எதைக் கண்காணிக்கிறோம், எதைச் சமாளிக்க முடியும், எதைப் பயன்படுத்துகிறோம். PostgreSQLஐ தரவு சேமிப்பகமாகவும் பயன்படுத்துகிறோம். ஆபரேட்டரை விட அதில் தரவை "ஊற்ற" எதுவும் வேகமாக இல்லை COPY இதுவரை இல்லை.

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

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

இரண்டாவதாக, நாங்கள் கற்றுக்கொண்டோம் (கட்டாயப்படுத்தப்பட்டோம்) பயன்படுத்தி எழுதுவது மிக மிக வேகமாக COPY. அதாவது, மட்டுமல்ல COPYஏனெனில் அவர் வேகமானவர் INSERT, மற்றும் இன்னும் வேகமாக.

மூன்றாவது புள்ளி - நான் செய்ய வேண்டியிருந்தது முறையே தூண்டுதல்கள் மற்றும் வெளிநாட்டு விசைகளை கைவிடவும். அதாவது, எங்களிடம் குறிப்பு ஒருமைப்பாடு இல்லை. ஏனென்றால், உங்களிடம் ஒரு ஜோடி FKகள் இருக்கும் டேபிள் இருந்தால், தரவுத்தள அமைப்பில் "இங்கே FK ஆல் குறிப்பிடப்பட்ட ஒரு பதிவுப் பதிவு உள்ளது, எடுத்துக்காட்டாக, பதிவுகளின் குழுவிற்கு" என்று நீங்கள் கூறினால், நீங்கள் அதைச் செருகும்போது, ​​PostgreSQL அதை எப்படி எடுத்து நேர்மையாகச் செய்வது என்பதைத் தவிர வேறு எதுவும் இல்லை SELECT 1 FROM master_fk1_table WHERE ... நீங்கள் செருக முயற்சிக்கும் அடையாளங்காட்டியுடன் - இந்தப் பதிவு அங்கு இருக்கிறதா என்பதைச் சரிபார்க்க, உங்கள் செருகலுடன் இந்த வெளிநாட்டு விசையை "உடைக்க" வேண்டாம்.

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

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

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

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

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

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

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

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

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

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

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

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

டேட்டா ரெக்கார்டிங்கிற்கு இந்த அணுகுமுறையை அறிமுகப்படுத்துவதற்கு முன், எங்களிடம் தோராயமாக 4K எழுதும் ஆப்ஸ் இருந்தது, மேலும் இந்த வழியில் சுமையை 4 மடங்கு குறைத்தோம். புதிய கண்காணிக்கப்பட்ட தரவுத்தளங்களின் காரணமாக இப்போது அவை மேலும் 6 மடங்கு வளர்ந்துள்ளன - 100MB/s வரை. இப்போது நாங்கள் கடந்த 3 மாதங்களாக பதிவுகளை 10-15TB அளவில் சேமித்து வைத்திருக்கிறோம், மூன்றே மாதங்களில் எந்தவொரு டெவலப்பரும் எந்த பிரச்சனையையும் தீர்க்க முடியும் என்று நம்புகிறோம்.

பிரச்சனைகளை நாங்கள் புரிந்துகொள்கிறோம்

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

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

நாங்கள் மூன்று முக்கிய புள்ளிகளை அடையாளம் கண்டுள்ளோம்:

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

"யார்" எங்களுக்கு ஒரு கோரிக்கையை அனுப்பியது என்பதைப் புரிந்து கொள்ள, நாங்கள் ஒரு நிலையான கருவியைப் பயன்படுத்துகிறோம் - அமர்வு மாறியை அமைக்கவும்: SET application_name = '{bl-host}:{bl-method}'; — கோரிக்கை வரும் வணிக லாஜிக் ஹோஸ்டின் பெயரையும், அதைத் தொடங்கிய முறை அல்லது பயன்பாட்டின் பெயரையும் அனுப்புகிறோம்.

கோரிக்கையின் “உரிமையாளரை” நாங்கள் கடந்து சென்ற பிறகு, அது பதிவில் வெளியிடப்பட வேண்டும் - இதற்காக நாம் மாறியை உள்ளமைக்கிறோம் log_line_prefix = ' %m [%p:%v] [%d] %r %a'. ஆர்வமுள்ளவர்களுக்கு, இருக்கலாம் கையேட்டில் பாருங்கள்இது எல்லாம் என்ன அர்த்தம். பதிவில் நாம் பார்க்கிறோம் என்று மாறிவிடும்:

• время
• செயல்முறை மற்றும் பரிவர்த்தனை அடையாளங்காட்டிகள்
• தரவுத்தள பெயர்
• இந்தக் கோரிக்கையை அனுப்பியவரின் ஐ.பி
• மற்றும் முறையின் பெயர்

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

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

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

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

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

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

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

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

போன்ற கோரிக்கையிலிருந்து ஒரே டெம்ப்ளேட்டுடன் வரும் வெவ்வேறு பயன்பாடுகளை உடனடியாகக் காணலாம் SELECT * FROM users WHERE login = 'Vasya'. முன்பக்கம், பின்தளம், செயலாக்கம்... மேலும் பயனருடன் தொடர்பு கொள்ளாவிட்டால், செயலாக்கம் ஏன் அவரைப் படிக்கும் என்று நீங்கள் ஆச்சரியப்படுகிறீர்கள்.

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

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

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

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

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

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

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

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