விக்டோரியாமெட்ரிக்ஸில் மேம்படுத்தல்களுக்குச் செல்லவும். அலெக்சாண்டர் வால்யால்கின்

2019 ஆம் ஆண்டின் பிற்பகுதியில் அலெக்சாண்டர் வால்கின் அறிக்கையின் டிரான்ஸ்கிரிப்டைப் படிக்குமாறு நான் பரிந்துரைக்கிறேன் "விக்டோரியாமெட்ரிக்ஸில் கோ ஆப்டிமைசேஷன்ஸ்"

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

இந்த அறிக்கையின் வீடியோ இணைப்பு இதோ - https://youtu.be/MZ5P21j_HLE

ஸ்லைடுகள்

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

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

அறிக்கையின் சுருக்கம் பின்வருமாறு:

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

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

விக்டோரியாமெட்ரிக்ஸ் மற்ற நேரத் தொடர் தரவுத்தளங்களை விட சிறந்த தரவு சுருக்கத்தை வழங்குகிறது.

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

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

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

நேரத் தொடர் என்றால் என்னவென்று யாருக்குத் தெரியும்? அவருக்கும் நிறைய பேரை தெரியும். நேரத் தொடர் என்பது ஜோடிகளின் தொடர் (timestamp, значение), இந்த ஜோடிகள் காலத்தால் வரிசைப்படுத்தப்படுகின்றன. மதிப்பு ஒரு மிதக்கும் புள்ளி எண் - float64.

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

நேரத் தொடரின் உதாரணம் இங்கே. இந்தத் தொடரின் முக்கிய ஜோடிகளின் பட்டியல்: __name__="cpu_usage" மெட்ரிக் பெயர், instance="my-server" - இந்த மெட்ரிக் சேகரிக்கப்பட்ட கணினி இது, datacenter="us-east" - இந்த கணினி அமைந்துள்ள தரவு மையம் இது.

மூன்று முக்கிய-மதிப்பு ஜோடிகளைக் கொண்ட நேரத் தொடரின் பெயரை நாங்கள் முடித்தோம். இந்த விசை ஜோடிகளின் பட்டியலுக்கு ஒத்திருக்கிறது (timestamp, value). t1, t3, t3, ..., tN - இவை நேர முத்திரைகள், 10, 20, 12, ..., 15 - தொடர்புடைய மதிப்புகள். இது கொடுக்கப்பட்ட தொடருக்கான ஒரு குறிப்பிட்ட நேரத்தில் cpu-பயன்பாடு ஆகும்.

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

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

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

உங்களுக்கு ஏன் நேரத் தொடர் தரவுத்தளம் தேவை? நேரத் தொடரைச் சேமிக்க நீங்கள் ஏன் வழக்கமான தொடர்புடைய தரவுத்தளத்தைப் பயன்படுத்த முடியாது?

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

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

விக்டோரியாமெட்ரிக்ஸை உதாரணமாகப் பயன்படுத்தி நவீன காலத் தொடர் தரவுத்தளக் கட்டமைப்பு இதுவாகும்.

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

தரவுத்தளத்தில் ஒரு புதிய பதிவு வரும்போது, ​​கொடுக்கப்பட்ட தொகுப்பிற்கான நேரத் தொடர் அடையாளங்காட்டியைக் கண்டறிய முதலில் தலைகீழ் குறியீட்டை அணுகுவோம். label=value கொடுக்கப்பட்ட அளவீட்டுக்கு. இந்த அடையாளங்காட்டியைக் கண்டுபிடித்து, டேட்டா ஸ்டோரில் மதிப்பைச் சேமிக்கிறோம்.

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

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

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

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

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

இது உண்மையில் எளிமையானது. இது ஒரு மதிப்புக்கான விசையை வரைபடமாக்கும் அகராதி. சாவி என்றால் என்ன? இந்த ஜோடி label=valueஅங்கு label и value - இவை வரிகள். மற்றும் மதிப்புகள் ஒரு தொகுப்பு timeseries_ids, இதில் கொடுக்கப்பட்ட ஜோடி அடங்கும் label=value.

தலைகீழ் குறியீடு எல்லாவற்றையும் விரைவாகக் கண்டுபிடிக்க உங்களை அனுமதிக்கிறது timeseries_ids, கொடுத்துள்ளனர் label=value.

விரைவாகக் கண்டுபிடிக்கவும் இது உங்களை அனுமதிக்கிறது timeseries_ids பல ஜோடிகளுக்கான நேரத் தொடர் label=value, அல்லது ஜோடிகளுக்கு label=regexp. இது எப்படி நடக்கிறது? தொகுப்பின் குறுக்குவெட்டைக் கண்டறிவதன் மூலம் timeseries_ids ஒவ்வொரு ஜோடிக்கும் label=value.

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

செயல்பாடு getMetricIDs சரங்களின் பட்டியலைப் பெறுகிறது. ஒவ்வொரு வரியும் கொண்டுள்ளது label=value. இந்த செயல்பாடு ஒரு பட்டியலை வழங்குகிறது metricIDs.

எப்படி இது செயல்படுகிறது? இங்கே நமக்கு ஒரு உலகளாவிய மாறி உள்ளது invertedIndex. இது வழக்கமான அகராதி (map), இது சரத்தை ஸ்லைஸ் இன்ட்களுக்கு வரைபடமாக்கும். வரி கொண்டுள்ளது label=value.

செயல்பாடு செயல்படுத்தல்: கிடைக்கும் metricIDs முதலாவதாக label=value, பின்னர் நாம் எல்லாவற்றையும் கடந்து செல்கிறோம் label=value, நாங்கள் அதைப் பெறுகிறோம் metricIDs அவர்களுக்காக. மற்றும் செயல்பாட்டை அழைக்கவும் intersectInts, இது கீழே விவாதிக்கப்படும். இந்த செயல்பாடு இந்த பட்டியல்களின் குறுக்குவெட்டை வழங்குகிறது.

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

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

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

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

• முதல் செயல்பாடு பதிவு ключ-значение இந்த தரவுத்தளத்திற்கு. அவள் இதை மிக விரைவாக செய்கிறாள், எங்கே ключ-значение தன்னிச்சையான சரங்கள்.
• கொடுக்கப்பட்ட விசையைப் பயன்படுத்தி மதிப்பை விரைவாகத் தேடுவது இரண்டாவது செயல்பாடு.
• மூன்றாவது செயல்பாடு, கொடுக்கப்பட்ட முன்னொட்டு மூலம் அனைத்து மதிப்புகளுக்கும் விரைவான தேடலாகும்.

LevelDB மற்றும் RocksDB - இந்த தரவுத்தளங்கள் கூகுள் மற்றும் பேஸ்புக் மூலம் உருவாக்கப்பட்டது. முதலில் LevelDB வந்தது. பின்னர் பேஸ்புக்கின் தோழர்கள் LevelDB ஐ எடுத்து அதை மேம்படுத்தத் தொடங்கினர், அவர்கள் RocksDB ஐ உருவாக்கினர். RocksDB மற்றும் MySQL க்கு மாற்றப்பட்டவை உட்பட, கிட்டத்தட்ட அனைத்து உள் தரவுத்தளங்களும் Facebook இல் RocksDB இல் வேலை செய்கின்றன. அவருக்குப் பெயரிட்டனர் MyRocks.

ஒரு தலைகீழ் குறியீட்டை LevelDB ஐப் பயன்படுத்தி செயல்படுத்தலாம். அதை எப்படி செய்வது? நாங்கள் ஒரு திறவுகோலாக சேமிக்கிறோம் label=value. மேலும் மதிப்பு என்பது ஜோடி இருக்கும் நேரத் தொடரின் அடையாளங்காட்டியாகும் label=value.

கொடுக்கப்பட்ட ஜோடியுடன் பல நேரத் தொடர்கள் இருந்தால் label=value, பின்னர் இந்த தரவுத்தளத்தில் ஒரே விசை மற்றும் வேறுபட்ட பல வரிசைகள் இருக்கும் timeseries_ids. எல்லாவற்றின் பட்டியலையும் பெற timeseries_ids, இதிலிருந்து தொடங்கும் label=prefix, இந்த தரவுத்தளம் உகந்ததாக இருக்கும் வரம்பில் ஸ்கேன் செய்கிறோம். அதாவது, தொடங்கும் அனைத்து வரிகளையும் நாங்கள் தேர்ந்தெடுக்கிறோம் label=prefix மற்றும் தேவையானவற்றைப் பெறுங்கள் timeseries_ids.

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

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

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

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

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

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

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

Mergeset ஆனது MergeTree தரவு கட்டமைப்பை அடிப்படையாகக் கொண்டது. இந்த தரவு அமைப்பு ClickHouse இலிருந்து கடன் வாங்கப்பட்டது. வெளிப்படையாக, mergeset விரைவான தேடலுக்கு உகந்ததாக இருக்க வேண்டும் timeseries_ids கொடுக்கப்பட்ட விசையின் படி. மெர்ஜெசெட் முழுவதும் கோவில் எழுதப்பட்டுள்ளது. நீங்கள் பார்க்க முடியும் GitHub இல் VictoriaMetrics ஆதாரங்கள். ஒன்றிணைப்பை செயல்படுத்துவது கோப்புறையில் உள்ளது /lib/mergeset. அங்கு என்ன நடக்கிறது என்பதை நீங்கள் கண்டுபிடிக்க முயற்சி செய்யலாம்.

mergeset API ஆனது LevelDB மற்றும் RocksDBஐப் போலவே உள்ளது. அதாவது, புதிய பதிவுகளை விரைவாகச் சேமிக்கவும், கொடுக்கப்பட்ட முன்னொட்டு மூலம் பதிவுகளை விரைவாகத் தேர்ந்தெடுக்கவும் இது உங்களை அனுமதிக்கிறது.

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

அவை ஏன் எழுந்தன?

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

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

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

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

ஒரு மெட்ரிக்கில் இருந்து ஒரு கணினிக்கு 40 x 8 = 320 மெட்ரிக்குகள் கிடைத்தன. 100 ஆல் பெருக்கினால், 32க்கு பதிலாக 000 கிடைக்கும்.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

இப்போது எங்கள் ஆடுகளுக்கு - குறுக்குவெட்டு செயல்பாட்டிற்கு திரும்புவோம் timeseries_ids. என்ன செயலாக்கங்கள் இருக்கக்கூடும் என்பதைக் கருத்தில் கொள்வோம். இந்த செயல்பாடு நீங்கள் கண்டுபிடிக்க அனுமதிக்கிறது timeseries_ids கொடுக்கப்பட்ட தொகுப்பிற்கு label=value.

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

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

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

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

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

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

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

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

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

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

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

இந்த நடைமுறையின் தீமை என்னவென்றால், அது அவ்வளவு வெளிப்படையானது அல்ல, அற்பமானது அல்ல.

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

இந்த கட்டமைப்பை செயல்படுத்துவதை கருத்தில் கொள்வோம். நீங்கள் பார்க்க விரும்பினால், அது விக்டோரியாமெட்ரிக்ஸ் மூலங்களில், கோப்புறையில் அமைந்துள்ளது lib/uint64set. இது குறிப்பாக விக்டோரியாமெட்ரிக்ஸ் வழக்கில் உகந்ததாக உள்ளது timeseries_id 64-பிட் மதிப்பு, இதில் முதல் 32 பிட்கள் அடிப்படையில் நிலையானதாகவும் கடைசி 32 பிட்கள் மட்டுமே மாறும்.

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

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

செயல்பாடுகள் உள்ளன add, இது புதிய மதிப்புகளைச் சேர்க்கிறது. ஒரு செயல்பாடு உள்ளது has, இது புதிய மதிப்புகளை சரிபார்க்கிறது. மற்றும் ஒரு செயல்பாடு உள்ளது del, இது மதிப்புகளை நீக்குகிறது. உதவியாளர் செயல்பாடு உள்ளது len, இது தொகுப்பின் அளவை வழங்குகிறது. செயல்பாடு clone நிறைய குளோன்கள். மற்றும் செயல்பாடு appendto இந்த தொகுப்பை ஸ்லைஸாக மாற்றுகிறது timeseries_ids.

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

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

• இரண்டாவது களம் buckets. இது கட்டமைப்பிலிருந்து ஒரு துண்டு bucket32. ஒவ்வொரு கட்டமைப்பும் சேமிக்கிறது hi களம். இவை மேல் 32 பிட்கள். மற்றும் இரண்டு துண்டுகள் - b16his и buckets из bucket16 கட்டமைப்புகள்.

16-பிட் கட்டமைப்பின் இரண்டாம் பகுதியின் முதல் 64 பிட்கள் இங்கே சேமிக்கப்பட்டுள்ளன. மேலும் இங்கு ஒவ்வொரு பைட்டின் கீழ் 16 பிட்களுக்கும் பிட்செட்டுகள் சேமிக்கப்படுகின்றன.

Bucket64 ஒரு வரிசையை கொண்டுள்ளது uint64. இந்த மாறிலிகளைப் பயன்படுத்தி நீளம் கணக்கிடப்படுகிறது. ஒன்றில் bucket16 அதிகபட்சமாக சேமிக்க முடியும் 2^16=65536 பிட். இதை 8 ஆல் வகுத்தால் 8 கிலோபைட் ஆகும். மீண்டும் 8 ஆல் வகுத்தால் 1000 uint64 பொருள். அது Bucket16 - இது எங்கள் 8-கிலோபைட் அமைப்பு.

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

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

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

இது செயல்பாட்டின் செயல்படுத்தல் ஆகும் b32.add. இது முந்தைய நடைமுறையைப் போன்றது. நாங்கள் மிகவும் குறிப்பிடத்தக்க 16 பிட்கள், குறைந்த முக்கியத்துவம் வாய்ந்த 16 பிட்களைக் கணக்கிடுகிறோம்.

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

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

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

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

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

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

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

எனக்கு இரண்டாவது கேள்வி உள்ளது. InfluxDB இலிருந்து அடிப்படை வேறுபாடு என்ன?

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

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

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

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

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

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

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

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

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

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

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

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

தரவைக் கடக்க நாம் ஏன் கர்சர்களைப் பயன்படுத்தக்கூடாது?

ஆமாம்.

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

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

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

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

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

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

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

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

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

மற்றொரு அம்சம் என்னவென்றால், VictoriaMetrics இந்தத் தரவை திறம்பட சுருக்குகிறது. உற்பத்தியில் சராசரியாக சுருக்கமானது ஒரு புள்ளிக்கு 0,4 முதல் 0,8 பைட்டுகள் வரை இருக்கும். ஒவ்வொரு புள்ளியும் ஒரு நேர முத்திரை + மதிப்பு. மேலும் இது சராசரியாக ஒரு பைட்டிற்கும் குறைவாக சுருக்கப்பட்டுள்ளது.

செர்ஜி. எனக்கு ஒரு கேள்வி. குறைந்தபட்ச பதிவு நேர குவாண்டம் என்ன?

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

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

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

நன்றி! மற்றும் மற்றொரு கேள்வி. PromQL இல் இணக்கத்தன்மை என்றால் என்ன?

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

டெலிகிராம் சேனல் விக்டோரியாமெட்ரிக்ஸ்.

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

Prometheus க்கான நீண்ட கால சேமிப்பகமாக VictoriaMetrics க்கு மாறுவதில் இருந்து உங்களைத் தடுப்பது எது? (கருத்துகளில் எழுதுங்கள், நான் அதை வாக்கெடுப்பில் சேர்ப்பேன்))

• 71,4%நான் Prometheus5 ஐப் பயன்படுத்துவதில்லை

• 28,6%VictoriaMetrics2 பற்றி தெரியாது

7 பயனர்கள் வாக்களித்தனர். 12 பயனர்கள் வாக்களிக்கவில்லை.

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