HighLoad++, Andrey Gushchin (Zabbix): உயர் செயல்திறன் மற்றும் சொந்த பகிர்வு

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

ஹைலோட்++ சைபீரியா 2019. டாம்ஸ்க் ஹால். ஜூன் 24, 16:00. இவைகள் மற்றும் விளக்கக்காட்சி. அடுத்த HighLoad++ மாநாடு ஏப்ரல் 6 மற்றும் 7, 2020 அன்று செயின்ட் பீட்டர்ஸ்பர்க்கில் நடைபெறும். விவரங்கள் மற்றும் டிக்கெட்டுகள் இணைப்பு.

ஆண்ட்ரி குஷ்சின் (இனி - ஏஜி): - நான் ஒரு ZABBIX தொழில்நுட்ப ஆதரவு பொறியாளர் (இனி "Zabbix" என குறிப்பிடப்படுகிறது), ஒரு பயிற்சியாளர். நான் 6 ஆண்டுகளுக்கும் மேலாக தொழில்நுட்ப ஆதரவில் பணியாற்றி வருகிறேன் மற்றும் செயல்திறனில் நேரடி அனுபவம் பெற்றுள்ளேன். வழக்கமான PostgreSQL 10 உடன் ஒப்பிடும் போது TimescaleDB வழங்கக்கூடிய செயல்திறனைப் பற்றி இன்று நான் பேசுவேன். மேலும், பொதுவாக இது எவ்வாறு செயல்படுகிறது என்பது பற்றிய சில அறிமுகப் பகுதி.

சிறந்த உற்பத்தித்திறன் சவால்கள்: தரவு சேகரிப்பில் இருந்து தரவு சுத்திகரிப்பு வரை

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

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

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

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

கேச்சிங் பிரச்சனைகளை எப்படி தீர்ப்பது?

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

தரவு சேகரிப்பு மற்றும் செயலாக்கம் - இந்த எல்லா தரவையும் சேமிக்க RAM ஐப் பயன்படுத்துகிறோம். இந்த தரவு இப்போது இன்னும் விரிவாக விவாதிக்கப்படும்.

தரவுத்தள பக்கத்தில் முக்கிய தேர்வுகளுக்கு சில கேச்சிங் உள்ளது - வரைபடங்கள் மற்றும் பிற விஷயங்களுக்கு.

Zabbix சேவையகத்தின் பக்கத்திலேயே கேச்சிங்: எங்களிடம் ConfigurationCache, ValueCache, HistoryCache, TrendsCache உள்ளது. அது என்ன?

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

Zabbix இல் கேச்சிங். தரவு சேகரிப்பு

இங்கே வரைபடம் மிகவும் பெரியது:

இத்திட்டத்தில் உள்ள முக்கியமானவர்கள் இந்த சேகரிப்பாளர்கள்:

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

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

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

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

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

ஹிஸ்டரி சின்சரின் வேலை

Zabbix இன் முக்கிய செயல்முறை (இது ஒரு ஒற்றைக் கட்டிடக்கலை என்பதால்) ஹிஸ்டரி சின்சர் ஆகும். ஒவ்வொரு தரவு உறுப்புகளின் அணு செயலாக்கத்துடன் குறிப்பாக கையாளும் முக்கிய செயல்முறை இதுவாகும், அதாவது ஒவ்வொரு மதிப்பு:

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

தரவுத்தளம். கேச்சிங்

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

MySQL க்கு Innodb_buffer_pool உள்ளது, மேலும் கட்டமைக்கக்கூடிய பல்வேறு தற்காலிக சேமிப்புகள் உள்ளன.
ஆனால் இவை முதன்மையானவை:

• பகிரப்பட்ட_பஃபர்கள்;
• பயனுள்ள_கேச்_அளவு;
• பகிர்ந்த_குளம்.

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

தரவுத்தள செயல்திறன் பற்றி

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

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

வரலாற்றை அழிக்கிறது. ஜாபிக்ஸுக்கு ஹவுஸ் கீப்பர் இருக்கிறார்

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

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

அது பயனற்றது என்பதை எவ்வாறு புரிந்துகொள்வது? உள் செயல்முறைகளின் செயல்திறன் வரைபடங்களில் பின்வரும் படத்தை நீங்கள் பார்க்கலாம்:

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

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

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

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

பிரித்தல் (பிரிவு)

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

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

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

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

உங்களுக்கு ஏன் பகிர்வு தேவை?

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

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

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

NoSQL க்கான மீள் தேடல்

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

டைம்ஸ்கேல்டிபி. ஹைபர்டேபிள்ஸ்

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

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

TimescaleDB மற்றும் PostgreSQL

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

TimescaleDB ஐ எவ்வாறு நிறுவுவது? இது எளிமை!

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

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

மற்றும் கடைசி படி ...

டைம்ஸ்கேல்டிபி. வரலாற்று அட்டவணைகளின் இடம்பெயர்வு

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

உருவாக்க வேண்டிய புலம், மற்றும் chunk_time_interval (இது துகள்களின் இடைவெளி (பயன்படுத்த வேண்டிய பகிர்வுகள்) 86 என்பது ஒரு நாள்.

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

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

எங்கள் db_extention இல் கடைசி புதுப்பிப்பை நாங்கள் செய்கிறோம்: நாங்கள் timescaledb ஐ நிறுவுகிறோம், இதனால் தரவுத்தளமும், குறிப்பாக, db_extention இருப்பதை எங்கள் Zabbix புரிந்து கொள்ளும். டைம்ஸ்கேல்டிபிக்கு தேவையான அந்த “அம்சங்களை” பயன்படுத்தி, அவர் அதைச் செயல்படுத்தி, தரவுத்தளத்தில் சரியான தொடரியல் மற்றும் வினவல்களைப் பயன்படுத்துகிறார்.

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

நான் இரண்டு சேவையகங்களைப் பயன்படுத்தினேன். முதல் சர்வர் ஒரு சிறிய மெய்நிகர் இயந்திரம், 20 செயலிகள், 16 ஜிகாபைட் ரேம். நான் அதில் Postgres 10.8 ஐ கட்டமைத்தேன்:

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

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

50 ஏஜெண்டுகளை (மேலும் சேர்ப்பது) மட்டும் பயன்படுத்தாமல், டைனமிக் டேட்டா உறுப்புகளைப் பயன்படுத்தி புதுப்பிப்பு இடைவெளியை 4 வினாடிகளாகக் குறைப்பதன் மூலம் புதுப்பிப்பு இடைவெளியையும் சுமையையும் ஒழுங்குபடுத்தினேன்.

செயல்திறன் சோதனை. PostgreSQL: 36 ஆயிரம் NVPகள்

இந்த வன்பொருளில் (வினாடிக்கு 10 ஆயிரம் மதிப்புகள்) தூய PostreSQL 35 இல் நான் வைத்திருந்த முதல் துவக்கம், முதல் அமைப்பு. பொதுவாக, நீங்கள் திரையில் பார்க்க முடியும் என, தரவு செருகும் ஒரு நொடியின் பின்னங்கள் எடுக்கும் - எல்லாம் நன்றாக மற்றும் வேகமாக, SSD இயக்கிகள் (200 ஜிகாபைட்கள்). ஒரே விஷயம் என்னவென்றால், 20 ஜிபி மிக விரைவாக நிரப்பப்படுகிறது.

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

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

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

செயல்திறன் சோதனை. PostgreSQL: 50 ஆயிரம் NVPகள்

அடுத்து, அதே வன்பொருளில் சுமையை வினாடிக்கு 50 ஆயிரம் மதிப்புகளாக அதிகரித்தேன். வீட்டுக்காப்பாளரால் ஏற்றப்பட்டபோது, ​​​​10 ஆயிரம் மதிப்புகள் கணக்கீட்டுடன் 2-3 வினாடிகளில் பதிவு செய்யப்பட்டன. உண்மையில், பின்வரும் ஸ்கிரீன்ஷாட்டில் என்ன காட்டப்பட்டுள்ளது:

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

செயல்திறன் சோதனை. PostgreSQL: 80 ஆயிரம் NVPகள்

பின்னர் நான் அதை வினாடிக்கு 80 ஆயிரம் மதிப்புகளாக அதிகரித்தேன்:

இது தோராயமாக 400 ஆயிரம் தரவு கூறுகள், 280 ஆயிரம் தூண்டுதல்கள். நீங்கள் பார்க்க முடியும் என, வரலாற்று மூழ்கிகளின் சுமையின் அடிப்படையில் (அவற்றில் 30 இருந்தன) ஏற்கனவே மிகவும் அதிகமாக இருந்தது. பின்னர் நான் பல்வேறு அளவுருக்களை அதிகரித்தேன்: ஹிஸ்டரி சின்கர்கள், கேச்... இந்த வன்பொருளில், ஹிஸ்டரி சின்கர்களின் சுமை அதிகபட்சமாக அதிகரிக்கத் தொடங்கியது, கிட்டத்தட்ட “அலமாரியில்” - அதன்படி, ஹிஸ்டரி கேச் மிக அதிக சுமைக்கு சென்றது:

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

நான் ஏற்கனவே 48 செயலிகள் மற்றும் 128 ஜிகாபைட் ரேம் கொண்ட மற்றொரு சேவையகத்தை எடுத்தேன்:

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

செயல்திறன் சோதனை. டைம்ஸ்கேல்டிபி: 80 ஆயிரம் என்விபிகள்

டைம்ஸ்கேல்டிபியைப் பயன்படுத்துவதே எனது முக்கிய பணியாக இருந்தது. ஒவ்வொரு வரைபடமும் ஒரு சரிவைக் காட்டுகிறது:

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

PostgreSQL செயல்திறன் சோதனை: 120 ஆயிரம் NVPகள்

அடுத்து, தரவு உறுப்புகளின் எண்ணிக்கையின் மதிப்பை அரை மில்லியனாக உயர்த்தி, வினாடிக்கு 125 ஆயிரம் கணக்கிடப்பட்ட மதிப்பைப் பெற்றேன்:

எனக்கு இந்த வரைபடங்கள் கிடைத்தன:

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

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

சமூகத்தில் உதாரணங்கள் உள்ளன:

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

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

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

பார்வையாளர்களின் கேள்விகள்

பார்வையாளர்களிடமிருந்து கேள்வி (இனி - A): - டைம்ஸ்கேல்டிபி கட்டமைக்க மிகவும் எளிதானது மற்றும் அது போன்ற செயல்திறன் ஊக்கத்தை அளித்தால், போஸ்ட்கிரெஸுடன் Zabbix ஐ உள்ளமைக்க இது ஒரு சிறந்த நடைமுறையாக பயன்படுத்தப்பட வேண்டுமா? இந்த தீர்வில் ஏதேனும் குறைபாடுகள் மற்றும் தீமைகள் உள்ளதா, அல்லது எல்லாவற்றிற்கும் மேலாக, நானே Zabbix ஐ உருவாக்க முடிவு செய்தால், நான் Postgres ஐ எளிதாக எடுத்துக் கொள்ளலாம், உடனடியாக டைம்ஸ்கேலை நிறுவி, அதைப் பயன்படுத்த முடியுமா மற்றும் எந்த பிரச்சனையும் பற்றி சிந்திக்காமல் இருக்க முடியுமா?

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

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

ஆனால்: – சமூகத்தின் கடைசி வரைபடங்களில், “ஹவுஸ் கீப்பர்” என்று ஒரு வரைபடம் இருந்தது:

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

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

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

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

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

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

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

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

ஆனால்: – உதாரணமாக Clickhouse க்கு மாறினால் எல்லாம் எவ்வளவு வேகமாக வேலை செய்யும் என்பதை உங்களால் மதிப்பிட முடியுமா?

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

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

AG: - நாம் ஒருங்கிணைக்கும்போது, ​​இன்னும் துல்லியமான சோதனைகள் இருக்கும் என்று நினைக்கிறேன்.

ஆனால்: - நல்ல பழைய RRD எங்கே போனது? SQL தரவுத்தளங்களுக்கு நீங்கள் மாறியது எது? ஆரம்பத்தில், அனைத்து அளவீடுகளும் RRD இல் சேகரிக்கப்பட்டன.

AG: - Zabbix RRD ஐக் கொண்டிருந்தது, ஒருவேளை மிகவும் பழமையான பதிப்பில் இருக்கலாம். எப்போதும் SQL தரவுத்தளங்கள் உள்ளன - ஒரு உன்னதமான அணுகுமுறை. உன்னதமான அணுகுமுறை MySQL, PostgreSQL (அவை மிக நீண்ட காலமாக உள்ளன). SQL மற்றும் RRD தரவுத்தளங்களுக்கான பொதுவான இடைமுகத்தை நாங்கள் ஒருபோதும் பயன்படுத்தவில்லை.

சில விளம்பரங்கள் 🙂

எங்களுடன் தங்கியதற்கு நன்றி. எங்கள் கட்டுரைகளை விரும்புகிறீர்களா? மேலும் சுவாரஸ்யமான உள்ளடக்கத்தைப் பார்க்க வேண்டுமா? ஒரு ஆர்டரை வைப்பதன் மூலம் அல்லது நண்பர்களுக்கு பரிந்துரை செய்வதன் மூலம் எங்களை ஆதரிக்கவும், $4.99 இலிருந்து டெவலப்பர்களுக்கான கிளவுட் VPS, நுழைவு-நிலை சேவையகங்களின் தனித்துவமான அனலாக், இது உங்களுக்காக எங்களால் கண்டுபிடிக்கப்பட்டது: VPS (KVM) E5-2697 v3 (6 கோர்கள்) 10GB DDR4 480GB SSD 1Gbps பற்றிய முழு உண்மை $19 அல்லது எப்படி ஒரு சர்வரைப் பகிர்வது? (RAID1 மற்றும் RAID10 உடன் கிடைக்கும், 24 கோர்கள் வரை மற்றும் 40GB DDR4 வரை).

ஆம்ஸ்டர்டாமில் உள்ள Equinix Tier IV தரவு மையத்தில் Dell R730xd 2 மடங்கு மலிவானதா? இங்கே மட்டும் 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 இலிருந்து நெதர்லாந்தில்! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 முதல்! பற்றி படிக்கவும் உள்கட்டமைப்பு நிறுவனத்தை எவ்வாறு உருவாக்குவது. ஒரு பைசாவிற்கு 730 யூரோக்கள் மதிப்புள்ள Dell R5xd E2650-4 v9000 சேவையகங்களைப் பயன்படுத்தும் வகுப்பு?

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