உயர் செயல்திறன் மற்றும் சொந்த பகிர்வு: TimescaleDB ஆதரவுடன் Zabbix

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

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

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

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

உற்பத்தித்திறன் சவால்கள்

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

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

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

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

பழைய தரவை சுத்தம் செய்வது என்பது தரவுத்தள செயல்திறனை பெரிதும் பாதிக்கும் ஒரு முக்கியமான பிரச்சினை.

Zabbix இல் கேச்சிங்

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

Zabbix சேவையகத்தின் பக்கத்திலேயே தற்காலிக சேமிப்பு:

• கட்டமைப்பு கேச்;
• மதிப்பு கேச்;
• ஹிஸ்டரி கேச்;
• TrendsCache.

அவற்றை இன்னும் விரிவாகக் கருதுவோம்.

கட்டமைப்பு கேச்

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

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

தரவு சேகரிப்பு

வரைபடம் மிகவும் பெரியது, ஆனால் அதில் முக்கிய விஷயம் எடுப்பவர்கள். இவை பல்வேறு "வாக்கெடுப்புகள்" - சட்டசபை செயல்முறைகள். அவை பல்வேறு வகையான அசெம்பிளிகளுக்குப் பொறுப்பாகும்: அவை SNMP, IPMI வழியாகத் தரவைச் சேகரித்து, அனைத்தையும் PreProcessingக்கு மாற்றுகின்றன.

சேகரிப்பான்கள் ஆரஞ்சு நிறத்தில் கோடிட்டுக் காட்டப்பட்டுள்ளன.

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

முன்செயலாக்கம் வரலாற்று கேச்

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

PreProcessing, PreProcessing படிகளைப் பெற, ConfigurationCache ஐப் பயன்படுத்துகிறது. இது இந்தத் தரவை பல்வேறு வழிகளில் செயலாக்குகிறது.

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

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

மதிப்பு கேச், வரலாறு & போக்குகள் தற்காலிக சேமிப்பு

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

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

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

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

தரவுத்தளத்தில் தற்காலிக சேமிப்பு

நிகழ்வுகளின் வரைபடங்கள் அல்லது அறிக்கைகளைப் பார்க்க விரும்பும் போது தரவுத்தள பக்கத்தில் பல்வேறு தற்காலிக சேமிப்புகள் உள்ளன:

• Innodb_buffer_pool MySQL பக்கத்தில்;
• shared_buffers PostgreSQL பக்கத்தில்;
• effective_cache_size ஆரக்கிள் பக்கத்தில்;
• shared_pool DB2 பக்கத்தில்.

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

தரவுத்தள செயல்திறன் முக்கியமானது

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

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

பணிப்பெண்

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

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

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

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

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

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

ஹவுஸ் கீப்பர் முடக்கப்பட்டார், வரைபடங்கள் சமன் செய்யப்பட்டன - இந்த விஷயத்தில் என்ன சிக்கல்கள் இருக்கலாம் மற்றும் மூன்றாவது செயல்திறன் சவாலை தீர்க்க எது உதவும்?

பிரித்தல் - பிரித்தல் அல்லது பிரித்தல்

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

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

"அமைப்பு" மிகப் பெரியதாக இருந்தால் மதிப்புகள் மாறலாம். ஒரு சிறிய “அமைப்பு” 5 nvps (வினாடிக்கு புதிய மதிப்புகள்) வரை இருந்தால், நடுத்தரமானது 000 முதல் 5 வரை இருந்தால், பெரியது 000 nvps க்கு மேல் இருக்கும். இவை பெரிய மற்றும் மிகப் பெரிய நிறுவல்கள் ஆகும், அவை தரவுத்தளத்தின் கவனமாக உள்ளமைவு தேவைப்படும்.

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

பகிர்வு என்ன தருகிறது?

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

விரைவான நீக்கம் - DELETE. நீக்குவதற்கான வரிசைகளைத் தேர்ந்தெடுப்பதற்குப் பதிலாக, ஒரு கோப்பு/துணை அட்டவணை தேர்ந்தெடுக்கப்பட்டது.

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

பெரும்பாலும் பல தரவுத்தளங்களும் துரிதப்படுத்தப்படுகின்றன INSERT - குழந்தை அட்டவணையில் செருகல்கள்.

டைம்ஸ்கேல் டி.பி.

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

TimescaleDB ஒரு கருத்து உள்ளது உயர் அட்டவணை (ஹைபர்டேபிள்) நீங்கள் உருவாக்கும். இது கொண்டுள்ளது துண்டுகள் - பகிர்வுகள். துகள்கள் தானாக நிர்வகிக்கப்படும் ஹைபர்டேபிள் துண்டுகள், அவை மற்ற துண்டுகளை பாதிக்காது. ஒவ்வொரு பகுதிக்கும் அதன் சொந்த நேர வரம்பு உள்ளது.

TimescaleDB vs PostgreSQL

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

200 மில்லியன் வரிசைகளுக்குப் பிறகு, PostgreSQL பொதுவாக கணிசமாகத் தொய்வடையத் தொடங்குகிறது மற்றும் செயல்திறனை 0 ஆக இழக்கிறது. TimescaleDB எந்த அளவிலான தரவிற்கும் "செருகுகளை" திறம்படச் செருக அனுமதிக்கிறது.

நிறுவல்

TimescaleDB ஐ நிறுவுவது எந்தவொரு தொகுப்பிற்கும் மிகவும் எளிதானது. IN ஆவணங்கள் எல்லாம் விரிவாக விவரிக்கப்பட்டுள்ளது - இது அதிகாரப்பூர்வ PostgreSQL தொகுப்புகளைப் பொறுத்தது. TimescaleDB ஐ கைமுறையாக உருவாக்கலாம் மற்றும் தொகுக்கலாம்.

Zabbix தரவுத்தளத்திற்கு நாம் நீட்டிப்பைச் செயல்படுத்துகிறோம்:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

நீங்கள் செயல்படுத்துங்கள் extension மற்றும் அதை Zabbix தரவுத்தளத்திற்காக உருவாக்கவும். கடைசி படி ஹைபர்டேபிளை உருவாக்க வேண்டும்.

வரலாற்று அட்டவணைகளை TimescaleDBக்கு மாற்றுகிறது

இதற்கு ஒரு சிறப்பு செயல்பாடு உள்ளது create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

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

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

கடைசி படி - UPDATE: இல் db_extension வைத்தது timescaledbஇந்த நீட்டிப்பு இருப்பதை தரவுத்தளம் புரிந்து கொள்ளும். Zabbix அதை செயல்படுத்துகிறது மற்றும் தரவுத்தளத்திற்கான தொடரியல் மற்றும் வினவல்களை சரியாகப் பயன்படுத்துகிறது - TimescaleDB க்கு தேவையான அம்சங்கள்.

வன்பொருள் கட்டமைப்பு

நான் இரண்டு சேவையகங்களைப் பயன்படுத்தினேன். முதலில் - VMware இயந்திரம். இது மிகவும் சிறியது: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz செயலிகள், 16 GB ரேம் மற்றும் 200 GB SSD.

Debian 10.8-10.8.pgdg1+90 OS மற்றும் xfs கோப்பு முறைமையுடன் PostgreSQL 1 ஐ நிறுவினேன். இந்தக் குறிப்பிட்ட தரவுத்தளத்தைப் பயன்படுத்த, Zabbix தானே பயன்படுத்துவதைக் கழிக்க, எல்லாவற்றையும் குறைந்தபட்சமாக உள்ளமைத்தேன்.

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

ஆரம்பத்தில் உள்ளமைவு அடங்கியது 5 கூறுகள் ஒரு ஹோஸ்டுக்கான தரவு. ஏறக்குறைய ஒவ்வொரு உறுப்புகளும் உண்மையான நிறுவல்களுக்கு ஒத்ததாக மாற்றுவதற்கான தூண்டுதலைக் கொண்டிருந்தன. சில சந்தர்ப்பங்களில் ஒன்றுக்கு மேற்பட்ட தூண்டுதல்கள் இருந்தன. ஒரு பிணைய முனைக்கு இருந்தன 3-000 தூண்டுதல்கள்.

தரவு உருப்படி புதுப்பிப்பு இடைவெளி − 4-7 வினாடிகள். 50 ஏஜெண்டுகளை மட்டும் பயன்படுத்தாமல், மேலும் பலவற்றைச் சேர்ப்பதன் மூலம் சுமையைக் கட்டுப்படுத்தினேன். மேலும், தரவு கூறுகளைப் பயன்படுத்தி, சுமைகளை மாறும் வகையில் சரிசெய்து, புதுப்பிப்பு இடைவெளியை 4 வினாடிகளாகக் குறைத்தேன்.

PostgreSQL. 35 என்விபிஎஸ்

இந்த வன்பொருளில் எனது முதல் ஓட்டம் தூய PostgreSQL இல் இருந்தது - வினாடிக்கு 35 ஆயிரம் மதிப்புகள். நீங்கள் பார்க்க முடியும் என, தரவைச் செருகுவது ஒரு நொடியின் பின்னங்களை எடுக்கும் - எல்லாம் நன்றாகவும் வேகமாகவும் இருக்கிறது. ஒரே விஷயம் என்னவென்றால், 200 ஜிபி எஸ்எஸ்டி வட்டு விரைவாக நிரப்பப்படுகிறது.

இது ஒரு நிலையான Zabbix சேவையக செயல்திறன் டாஷ்போர்டு ஆகும்.

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

நான்காவது வரைபடம் HistoryCache பயன்பாட்டைக் காட்டுகிறது. தரவுத்தளத்தில் செருகுவதற்கு முன் இது ஒரு வகையான இடையகமாகும். பச்சை ஐந்தாவது வரைபடம் ValueCache பயன்பாட்டைக் காட்டுகிறது, அதாவது தூண்டுதல்களுக்கு எத்தனை ValueCache வெற்றிகள் - இது ஒரு வினாடிக்கு பல ஆயிரம் மதிப்புகள்.

PostgreSQL. 50 என்விபிஎஸ்

அதே வன்பொருளில் சுமையை வினாடிக்கு 50 ஆயிரம் மதிப்புகளாக அதிகரித்தேன்.

ஹவுஸ் கீப்பரிடமிருந்து ஏற்றும்போது, ​​10 ஆயிரம் மதிப்புகளைச் செருகுவதற்கு 2-3 வினாடிகள் ஆனது.

வீட்டுக்காரர் ஏற்கனவே வேலையில் தலையிட ஆரம்பித்துவிட்டார்.

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

PostgreSQL. 80 என்விபிஎஸ்

பின்னர் நான் சுமையை வினாடிக்கு 80 ஆயிரம் மதிப்புகளாக அதிகரித்தேன். இது தோராயமாக 400 ஆயிரம் தரவு கூறுகள் மற்றும் 280 ஆயிரம் தூண்டுதல்கள்.

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

நான் பல்வேறு அளவுருக்களை அதிகரித்துள்ளேன்: வரலாற்று ஒத்திசைவுகள், தற்காலிக சேமிப்புகள்.

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

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

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

இரண்டாவது சேவையகம்

நான் மற்றொரு சேவையகத்தை எடுத்தேன், அதில் ஏற்கனவே 48 செயலிகள் மற்றும் 128 ஜிபி ரேம் இருந்தது. நான் அதை டியூன் செய்தேன் - அதை 60 ஹிஸ்டரி சின்சராக அமைத்து, ஏற்றுக்கொள்ளக்கூடிய செயல்திறனை அடைந்தேன்.

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

டைம்ஸ்கேல்டிபி. 80 என்விபிஎஸ்

Zabbix சுமைக்கு எதிராக TimescaleDB இன் திறன்களை சோதிப்பதே எனது முக்கிய பணி. வினாடிக்கு 80 ஆயிரம் மதிப்புகள் நிறைய, அளவீடுகளை சேகரிக்கும் அதிர்வெண் (நிச்சயமாக யாண்டெக்ஸைத் தவிர) மற்றும் மிகவும் பெரிய "அமைப்பு".

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

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

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

டைம்ஸ்கேல்டிபி. 120 என்விபிஎஸ்

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

இது ஒரு வேலை "அமைப்பு" ஆகும், இது நீண்ட நேரம் வேலை செய்ய முடியும். ஆனால் எனது வட்டு 1,5 TB மட்டுமே என்பதால், அதை ஓரிரு நாட்களில் நிரப்பிவிட்டேன்.

மிக முக்கியமான விஷயம் என்னவென்றால், அதே நேரத்தில் புதிய TimescaleDB பகிர்வுகள் உருவாக்கப்பட்டன.

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

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

கண்டுபிடிப்புகள்

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

TimescaleDB கட்டமைக்க எளிதானது, செயல்திறன் ஆதாயங்களை அளிக்கிறது, Zabbix உடன் நன்றாக வேலை செய்கிறது மற்றும் PostgreSQL ஐ விட நன்மைகள் உள்ளன.

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

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

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

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