பல நேரத் தொடர் தரவுத்தளங்களை நாங்கள் எவ்வாறு சோதித்தோம்

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

2019 ஆம் ஆண்டில் TSDB பயன்படுத்தத் தகுந்த ஒரு கட்டுரையில் ஒரே ஒரு வாக்கியம் மட்டுமே இருக்கும்: "கிளிக்ஹவுஸைப் பயன்படுத்தவும்." ஆனால்... நுணுக்கங்கள் உள்ளன.

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

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

பிரச்சனை அறிக்கை

முதலில், தேவையான முன்னுரை. நமக்கு ஏன் நமது சொந்த கண்காணிப்பு அமைப்பு தேவை, அது எப்படி வடிவமைக்கப்பட்டது?

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

எங்கள் முக்கிய தேவைகள்:

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

இந்த கட்டுரையில் நாம் கடைசி புள்ளியில் ஆர்வமாக உள்ளோம்.

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

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

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

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

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

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

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

2017 இல், சான் ஜோஸில் நடந்த பெர்கோனா லைவ் மாநாட்டில், கிளிக்ஹவுஸ் டெவலப்பர்கள் முதல் முறையாக தங்களைத் தாங்களே அறிவித்திருக்கலாம். முதல் பார்வையில், கணினி உற்பத்திக்கு தயாராக இருந்தது (நன்றாக, Yandex.Metrica ஒரு கடுமையான உற்பத்தி அமைப்பு), ஆதரவு வேகமாகவும் எளிமையாகவும் இருந்தது, மிக முக்கியமாக, செயல்பாடு எளிமையானது. 2018 முதல், நாங்கள் மாறுதல் செயல்முறையைத் தொடங்கியுள்ளோம். ஆனால் அந்த நேரத்தில், நிறைய "வயது வந்தவர்கள்" மற்றும் நேர-சோதனை செய்யப்பட்ட TSDB அமைப்புகள் இருந்தன, மேலும் எங்கள் தேவைகளுக்கு ஏற்ப கிளிக்ஹவுஸுக்கு மாற்று தீர்வுகள் இல்லை என்பதை உறுதிப்படுத்த கணிசமான நேரத்தை ஒதுக்கி மாற்றுகளை ஒப்பிட முடிவு செய்தோம்.

ஏற்கனவே குறிப்பிடப்பட்ட சேமிப்பக தேவைகளுக்கு கூடுதலாக, புதியவை தோன்றியுள்ளன:

• அதே அளவு வன்பொருளில் MySQL இன் அதே செயல்திறனையாவது புதிய அமைப்பு வழங்க வேண்டும்;
• புதிய அமைப்பின் சேமிப்பு கணிசமாக குறைந்த இடத்தை எடுக்க வேண்டும்;
• DBMS நிர்வகிக்க இன்னும் எளிதாக இருக்க வேண்டும்;
• DBMS ஐ மாற்றும்போது பயன்பாட்டை குறைந்தபட்சமாக மாற்ற விரும்பினேன்.

என்ன அமைப்புகளை நாங்கள் கருத்தில் கொள்ள ஆரம்பித்தோம்?

அப்பாச்சி ஹைவ்/அப்பாச்சி இம்பாலா
ஒரு பழைய, போரில் சோதிக்கப்பட்ட ஹடூப் ஸ்டேக். அடிப்படையில், இது HDFS இல் சொந்த வடிவங்களில் தரவைச் சேமிப்பதன் மேல் கட்டப்பட்ட SQL இடைமுகமாகும்.

ப்ரோஸ்.

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

கான்ஸ்.

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

எனினும்:

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

ட்ரூயிட்/பினோட்

குறிப்பாக TSDB பற்றி அதிகம் உள்ளது, ஆனால் மீண்டும், ஹடூப் ஸ்டேக்.

உள்ளன ட்ரூயிட் மற்றும் பினோட் மற்றும் கிளிக்ஹவுஸின் நன்மை தீமைகளை ஒப்பிடும் சிறந்த கட்டுரை .

ஒரு சில வார்த்தைகளில்: ட்ரூயிட்/பினோட் கிளிக்ஹவுஸை விட சிறப்பாக இருக்கும் சந்தர்ப்பங்களில்:

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

எதிர் சந்தர்ப்பங்களில், ClickHouse சிறப்பாக செயல்படுகிறது, இது எங்கள் வழக்கு.

கிளிக்ஹவுஸ்

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

சோதனைக்கான சுருக்கப்பட்டியலைப் பெறுகிறது.

InfluxDB

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

சோதனைக்கான சுருக்கப்பட்டியலைப் பெறுகிறது.

கசண்டிரா

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

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

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

பிரமீதீயஸ்

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

சோதனை முறை மற்றும் முடிவுகள்

எனவே, பின்வரும் 5 உள்ளமைவுகளில் 6 தரவுத்தளங்களைச் சோதித்தோம்: ClickHouse (1 முனை), ClickHouse (3 முனைகளுக்கான விநியோக அட்டவணை), InfluxDB, Mysql 8, Cassandra (3 முனைகள்) மற்றும் Prometheus. சோதனைத் திட்டம் பின்வருமாறு:

1. ஒரு வாரத்திற்கான வரலாற்றுத் தரவைப் பதிவேற்றவும் (ஒரு நாளைக்கு 840 மில்லியன் மதிப்புகள்; 208 ஆயிரம் அளவீடுகள்);
2. நாங்கள் ஒரு பதிவு சுமையை உருவாக்குகிறோம் (6 சுமை முறைகள் கருதப்பட்டன, கீழே காண்க);
3. பதிவுக்கு இணையாக, விளக்கப்படங்களுடன் பணிபுரியும் பயனரின் கோரிக்கைகளைப் பின்பற்றி, அவ்வப்போது தேர்வுகளைச் செய்கிறோம். விஷயங்களை மிகவும் சிக்கலாக்காமல் இருக்க, ஒரு வாரத்திற்கு 10 அளவீடுகளுக்கான (அதுவே CPU வரைபடத்தில் எத்தனை உள்ளன) தரவைத் தேர்ந்தெடுத்தோம்.

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

• தரவு எழுதப்பட்ட அளவீடுகளின் மொத்த எண்ணிக்கை;
• ஒரு மெட்ரிக் மதிப்புகளை அனுப்புவதற்கான இடைவெளி;
• தொகுதி அளவு.

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

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

இங்கே, இவை அனைத்தையும் கணக்கில் எடுத்துக் கொண்டால், எங்கள் 6 தரவுத்தள எழுதும் சுமை முறைகள்:

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

சோதனை முடிவுகள் பின்வருமாறு:

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

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

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