HighLoad++ மாஸ்கோ 2018, காங்கிரஸ் ஹால். நவம்பர் 9, 15:00
சுருக்கம் மற்றும் விளக்கக்காட்சி:
யூரி நஸ்ரெட்டினோவ் (VKontakte): எங்கள் நிறுவனத்தில் கிளிக்ஹவுஸை செயல்படுத்திய அனுபவத்தைப் பற்றி அறிக்கை பேசும் - நமக்கு இது ஏன் தேவை, எவ்வளவு தரவு சேமிக்கிறோம், அதை எவ்வாறு எழுதுகிறோம் மற்றும் பல.
கூடுதல் பொருட்கள்:
யூரி நஸ்ரெட்டினோவ்: - அனைவருக்கும் வணக்கம்! என் பெயர் யூரி நஸ்ரெட்டினோவ், நான் ஏற்கனவே அறிமுகப்படுத்தப்பட்டேன். நான் VKontakte இல் வேலை செய்கிறேன். எங்கள் சர்வர் ஃப்ளீட்டில் (பல்லாயிரக்கணக்கான) இருந்து கிளிக்ஹவுஸில் தரவை எவ்வாறு செருகுவது என்பது பற்றி நான் பேசுவேன்.
பதிவுகள் என்றால் என்ன, அவற்றை ஏன் சேகரிக்க வேண்டும்?
நாங்கள் உங்களுக்கு என்ன சொல்வோம்: நாங்கள் என்ன செய்தோம், எங்களுக்கு ஏன் “கிளிக்ஹவுஸ்” தேவை, ஏன் அதைத் தேர்ந்தெடுத்தோம், சிறப்பாக எதையும் உள்ளமைக்காமல் நீங்கள் எந்த வகையான செயல்திறனைப் பெறலாம். இடையக அட்டவணைகள், அவற்றுடன் எங்களுக்கு ஏற்பட்ட சிக்கல்கள் மற்றும் திறந்த மூலத்திலிருந்து நாங்கள் உருவாக்கிய தீர்வுகள் பற்றி நான் உங்களுக்கு மேலும் கூறுவேன் - KittenHouse மற்றும் Lighthouse.
நாம் ஏன் எதையும் செய்ய வேண்டும் (VKontakte இல் எல்லாம் எப்போதும் நன்றாக இருக்கிறது, இல்லையா?). பிழைத்திருத்த பதிவுகளை சேகரிக்க விரும்புகிறோம் (மற்றும் நூற்றுக்கணக்கான டெராபைட் தரவுகள் இருந்தன), ஒருவேளை எப்படியாவது புள்ளிவிவரங்களைக் கணக்கிடுவது மிகவும் வசதியாக இருக்கும்; எங்களிடம் பல்லாயிரக்கணக்கான சேவையகங்கள் உள்ளன, இவை அனைத்தும் செய்யப்பட வேண்டும்.
ஏன் முடிவு செய்தோம்? பதிவுகளை சேமிப்பதற்கான தீர்வுகள் எங்களிடம் இருக்கலாம். இங்கே - அத்தகைய பொது "பின்னணி VK" உள்ளது. அதற்கு குழுசேர நான் மிகவும் பரிந்துரைக்கிறேன்.
பதிவுகள் என்றால் என்ன? இது வெற்று வரிசைகளை வழங்கும் இயந்திரம். VK இல் உள்ள என்ஜின்களை மற்றவர்கள் மைக்ரோ சர்வீஸ் என்று அழைக்கிறார்கள். இதோ சிரிக்கும் ஸ்டிக்கர் (நிறைய விருப்பங்கள்). எப்படி? சரி, மேலும் கேளுங்கள்!
பதிவுகளை சேமிக்க என்ன பயன்படுத்தலாம்? ஹடுப்பை குறிப்பிடாமல் இருக்க முடியாது. பின்னர், எடுத்துக்காட்டாக, Rsyslog (இந்த பதிவுகளை கோப்புகளில் சேமித்தல்). எல்.எஸ்.டி. LSD என்றால் என்னவென்று யாருக்குத் தெரியும்? இல்லை, இந்த LSD அல்ல. கோப்புகளை முறையே சேமிக்கவும். சரி, கிளிக்ஹவுஸ் ஒரு விசித்திரமான விருப்பம்.
கிளிக்ஹவுஸ் மற்றும் போட்டியாளர்கள்: தேவைகள் மற்றும் வாய்ப்புகள்
நமக்கு என்ன வேண்டும்? செயல்பாட்டைப் பற்றி நாங்கள் அதிகம் கவலைப்பட வேண்டியதில்லை என்பதை உறுதிசெய்ய விரும்புகிறோம், எனவே இது பெட்டிக்கு வெளியே செயல்படும், முன்னுரிமை குறைந்தபட்ச உள்ளமைவுடன். நாங்கள் நிறைய எழுத விரும்புகிறோம், விரைவாக எழுதுகிறோம். நாங்கள் அதை அனைத்து வகையான மாதங்கள், ஆண்டுகள், அதாவது நீண்ட காலத்திற்கு வைத்திருக்க விரும்புகிறோம். அவர்கள் எங்களிடம் வந்து, "இங்கே ஏதோ வேலை செய்யவில்லை" என்று கூறிய சில பிரச்சனைகளை நாங்கள் புரிந்து கொள்ள விரும்பலாம், அது 3 மாதங்களுக்கு முன்பு இருந்தது), மேலும் 3 மாதங்களுக்கு முன்பு என்ன நடந்தது என்பதைப் பார்க்க விரும்புகிறோம்" தரவு சுருக்கம் - அது ஏன் கூடுதலாக இருக்கும் என்பது தெளிவாகிறது - ஏனெனில் அது எடுக்கும் இடத்தின் அளவைக் குறைக்கிறது.
எங்களிடம் இதுபோன்ற ஒரு சுவாரஸ்யமான தேவை உள்ளது: சில நேரங்களில் சில கட்டளைகளின் வெளியீட்டை எழுதுகிறோம் (எடுத்துக்காட்டாக, பதிவுகள்), இது 4 கிலோபைட்டுகளுக்கு மேல் மிக எளிதாக இருக்கும். இந்த விஷயம் UDP இல் வேலை செய்தால், அது செலவழிக்க வேண்டிய அவசியமில்லை... இணைப்புக்கான "மேல்நிலை" எதுவும் இருக்காது, மேலும் அதிக எண்ணிக்கையிலான சேவையகங்களுக்கு இது ஒரு பிளஸ் ஆகும்.
ஓப்பன் சோர்ஸ் என்ன வழங்குகிறது என்று பார்ப்போம். முதலில், எங்களிடம் பதிவுகள் இயந்திரம் உள்ளது - இது எங்கள் இயந்திரம்; கொள்கையளவில், அவர் எல்லாவற்றையும் செய்ய முடியும், அவர் நீண்ட வரிகளை கூட எழுத முடியும். சரி, இது தரவை வெளிப்படையாக சுருக்காது - நாம் விரும்பினால் பெரிய நெடுவரிசைகளை நாமே சுருக்கலாம் ... நிச்சயமாக நாங்கள் விரும்பவில்லை (முடிந்தால்). ஒரே பிரச்சனை என்னவென்றால், அவர் தனது நினைவில் பொருந்துவதை மட்டுமே கொடுக்க முடியும்; மீதமுள்ளவற்றைப் படிக்க, நீங்கள் இந்த இயந்திரத்தின் பின்லாக்கைப் பெற வேண்டும், அதன்படி, இது நீண்ட நேரம் எடுக்கும்.
வேறு என்ன விருப்பங்கள் உள்ளன? உதாரணமாக, "ஹடப்". செயல்பாட்டின் எளிமை... ஹடப்பை அமைப்பது எளிது என்று யார் நினைக்கிறார்கள்? நிச்சயமாக, பதிவு செய்வதில் எந்த பிரச்சனையும் இல்லை. படிக்கும் போது சில சமயம் கேள்விகள் எழும். கொள்கையளவில், குறிப்பாக பதிவுகளுக்கு இல்லை என்று நான் கூறுவேன். நீண்ட கால சேமிப்பு - நிச்சயமாக, ஆம், தரவு சுருக்கம் - ஆம், நீண்ட சரங்கள் - நீங்கள் பதிவு செய்யலாம் என்பது தெளிவாகிறது. ஆனால் அதிக எண்ணிக்கையிலான சர்வர்களில் இருந்து பதிவு செய்தல்... இன்னும் நீங்களே ஏதாவது செய்ய வேண்டும்!
Rsyslog. உண்மையில், நாங்கள் அதை ஒரு காப்பு விருப்பமாகப் பயன்படுத்தினோம், இதனால் பின்லாக்கைக் கொட்டாமல் படிக்க முடியும், ஆனால் நீண்ட வரிகளை எழுத முடியாது; கொள்கையளவில், இது 4 கிலோபைட்டுகளுக்கு மேல் எழுத முடியாது. நீங்கள் அதே வழியில் தரவு சுருக்கம் செய்ய வேண்டும். கோப்புகளிலிருந்து வாசிப்பு வரும்.
பின்னர் LSD இன் "badushka" வளர்ச்சி உள்ளது. அடிப்படையில் "Rsyslog" போன்றது: இது நீண்ட சரங்களை ஆதரிக்கிறது, ஆனால் UDP வழியாக வேலை செய்ய முடியாது, உண்மையில், இதன் காரணமாக, துரதிர்ஷ்டவசமாக, நிறைய விஷயங்களை மீண்டும் எழுத வேண்டும். பல்லாயிரக்கணக்கான சேவையகங்களில் இருந்து பதிவு செய்யக்கூடிய வகையில் LSD மறுவடிவமைப்பு செய்யப்பட வேண்டும்.
மற்றும் இங்கே! ஒரு வேடிக்கையான விருப்பம் ElasticSearch ஆகும். எப்படி சொல்ல? அவர் வாசிப்பதில் நன்றாக இருக்கிறார், அதாவது, அவர் விரைவாகப் படிக்கிறார், ஆனால் எழுதுவதில் நன்றாக இல்லை. முதலாவதாக, இது தரவை சுருக்கினால், அது மிகவும் பலவீனமானது. பெரும்பாலும், முழு தேடலுக்கு அசல் தொகுதியை விட பெரிய தரவு கட்டமைப்புகள் தேவை. இது செயல்பட கடினமாக உள்ளது மற்றும் அடிக்கடி பிரச்சினைகள் எழுகின்றன. மேலும், மீண்டும், எலாஸ்டிக்கில் பதிவு செய்தல் - எல்லாவற்றையும் நாமே செய்ய வேண்டும்.
இங்கே கிளிக்ஹவுஸ் ஒரு சிறந்த வழி, நிச்சயமாக. ஒரே விஷயம் என்னவென்றால், பல்லாயிரக்கணக்கான சேவையகங்களிலிருந்து பதிவு செய்வது ஒரு சிக்கல். ஆனால் குறைந்தபட்சம் ஒரு பிரச்சனை உள்ளது, அதை எப்படியாவது தீர்க்க முயற்சி செய்யலாம். மீதமுள்ள அறிக்கை இந்த சிக்கலைப் பற்றியது. ClickHouse இலிருந்து என்ன வகையான செயல்திறனை நீங்கள் எதிர்பார்க்கலாம்?
நாம் அதை எவ்வாறு செருகப் போகிறோம்? MergeTree
உங்களில் யார் "கிளிக்ஹவுஸ்" பற்றி கேள்விப்படாத அல்லது அறிந்திருக்கவில்லை? நான் உங்களிடம் சொல்ல வேண்டும், இல்லையா? மிகவும் வேகமாக. அங்கு செருகுவது - வினாடிக்கு 1-2 ஜிகாபிட்கள், வினாடிக்கு 10 ஜிகாபிட்கள் வரை வெடிப்புகள் உண்மையில் இந்த உள்ளமைவைத் தாங்கும் - இரண்டு 6-கோர் ஜியோன்கள் உள்ளன (அதாவது, மிகவும் சக்தி வாய்ந்தது கூட இல்லை), 256 ஜிகாபைட் ரேம், 20 டெராபைட்கள் RAID இல் (யாரும் உள்ளமைக்கப்படவில்லை, இயல்புநிலை அமைப்புகள்). கிளிக்ஹவுஸ் டெவலப்பரான அலெக்ஸி மிலோவிடோவ், நாங்கள் எதையும் உள்ளமைக்காததால் அழுதுகொண்டே இருக்கலாம் (எல்லாமே எங்களுக்கு வேலை செய்தது). அதன்படி, தரவு நன்கு சுருக்கப்பட்டால், ஒரு வினாடிக்கு சுமார் 6 பில்லியன் கோடுகள் ஸ்கேனிங் வேகத்தைப் பெறலாம். நீங்கள் ஒரு உரை சரத்தில் % என விரும்பினால் - வினாடிக்கு 100 மில்லியன் வரிகள், அதாவது, அது மிக வேகமாகத் தெரிகிறது.
நாம் அதை எவ்வாறு செருகப் போகிறோம்? VK PHP ஐப் பயன்படுத்துகிறது என்பது உங்களுக்குத் தெரியும். ஒவ்வொரு PHP பணியாளரிடமிருந்தும் HTTP வழியாக "ClickHouse" இல், ஒவ்வொரு பதிவுக்கும் MergeTree அட்டவணையில் செருகுவோம். இந்தத் திட்டத்தில் சிக்கலை யார் பார்க்கிறார்கள்? சில காரணங்களால், எல்லோரும் தங்கள் கைகளை உயர்த்தவில்லை. சொல்கிறேன்.
முதலாவதாக, நிறைய சேவையகங்கள் உள்ளன - அதன்படி, நிறைய இணைப்புகள் (மோசமானவை) இருக்கும். வினாடிக்கு ஒரு முறைக்கு மேல் MergeTree இல் தரவைச் செருகுவது நல்லது. ஏன் என்று யாருக்குத் தெரியும்? சரி சரி. இதைப் பற்றி இன்னும் கொஞ்சம் சொல்கிறேன். மற்றொரு சுவாரஸ்யமான கேள்வி என்னவென்றால், நாங்கள் பகுப்பாய்வு செய்யவில்லை, தரவை வளப்படுத்த தேவையில்லை, எங்களுக்கு இடைநிலை சேவையகங்கள் தேவையில்லை, நாங்கள் நேரடியாக "ClickHouse" இல் செருக விரும்புகிறோம் (முன்னுரிமை - இன்னும் நேரடியாக, சிறந்தது).
அதன்படி, MergeTree இல் செருகல் எவ்வாறு செய்யப்படுகிறது? வினாடிக்கு ஒரு முறை அல்லது குறைவாக அடிக்கடி அதில் செருகுவது ஏன் நல்லது? உண்மை என்னவென்றால், “கிளிக்ஹவுஸ்” என்பது ஒரு நெடுவரிசை தரவுத்தளமாகும், மேலும் தரவை முதன்மை விசையின் ஏறுவரிசையில் வரிசைப்படுத்துகிறது, மேலும் நீங்கள் செருகும்போது, தரவு வரிசைப்படுத்தப்பட்ட நெடுவரிசைகளின் எண்ணிக்கைக்கு சமமாக பல கோப்புகள் உருவாக்கப்படுகின்றன. முதன்மை விசையின் ஏறுவரிசையில் (ஒரு தனி அடைவு உருவாக்கப்படுகிறது, ஒவ்வொரு செருகலுக்கும் வட்டில் உள்ள கோப்புகளின் தொகுப்பு). பின்னர் அடுத்த செருகல் வருகிறது, பின்னணியில் அவை பெரிய "பகிர்வுகளாக" இணைக்கப்படுகின்றன. தரவு வரிசைப்படுத்தப்பட்டதால், அதிக நினைவகத்தை உட்கொள்ளாமல் இரண்டு வரிசைப்படுத்தப்பட்ட கோப்புகளை "ஒன்றிணைக்க" முடியும்.
ஆனால், நீங்கள் யூகித்தபடி, ஒவ்வொரு செருகலுக்கும் 10 கோப்புகளை எழுதினால், கிளிக்ஹவுஸ் (அல்லது உங்கள் சர்வர்) விரைவில் முடிவடையும், எனவே பெரிய தொகுதிகளில் செருக பரிந்துரைக்கப்படுகிறது. அதன்படி, உற்பத்தியில் முதல் திட்டத்தை நாங்கள் தொடங்கவே இல்லை. நாங்கள் உடனடியாக ஒன்றைத் தொடங்கினோம், அது இங்கே எண். 2 இல் உள்ளது:
இங்கே கற்பனை செய்து பாருங்கள், நாங்கள் தொடங்கியுள்ள சுமார் ஆயிரம் சேவையகங்கள் உள்ளன, PHP மட்டுமே உள்ளது. ஒவ்வொரு சேவையகத்திலும் எங்கள் உள்ளூர் முகவர் இருக்கிறார், அதை நாங்கள் "கிட்டன்ஹவுஸ்" என்று அழைத்தோம், இது "ClickHouse" உடன் ஒரு இணைப்பைப் பராமரிக்கிறது மற்றும் ஒவ்வொரு சில வினாடிகளிலும் தரவைச் செருகுகிறது. MergeTree இல் தரவைச் செருகாமல், ஒரு இடையக அட்டவணையில் செருகும், இது MergeTree இல் நேரடியாகச் செருகுவதைத் தவிர்க்க துல்லியமாக உதவுகிறது.
இடையக அட்டவணைகளுடன் பணிபுரிதல்
அது என்ன? இடையக அட்டவணைகள் என்பது துண்டாக்கப்பட்ட நினைவகத்தின் ஒரு பகுதி (அதாவது, அதை அடிக்கடி அதில் செருகலாம்). அவை பல துண்டுகளைக் கொண்டிருக்கின்றன, மேலும் ஒவ்வொரு துண்டுகளும் ஒரு சுயாதீன இடையகமாக செயல்படுகின்றன, மேலும் அவை சுயாதீனமாக சுத்தப்படுத்தப்படுகின்றன (உங்களிடம் இடையகத்தில் பல துண்டுகள் இருந்தால், வினாடிக்கு பல செருகல்கள் இருக்கும்). இந்த அட்டவணையில் இருந்து படிக்க முடியும் - பின்னர் நீங்கள் இடையக மற்றும் பெற்றோர் அட்டவணையின் உள்ளடக்கங்களின் ஒன்றியத்தைப் படிக்கிறீர்கள், ஆனால் இந்த நேரத்தில் எழுதுவது தடுக்கப்பட்டுள்ளது, எனவே அங்கிருந்து படிக்காமல் இருப்பது நல்லது. மற்றும் இடையக அட்டவணைகள் மிகச் சிறந்த QPS ஐக் காட்டுகின்றன, அதாவது 3 ஆயிரம் QPS வரை செருகும் போது உங்களுக்கு எந்த பிரச்சனையும் இருக்காது. சேவையகம் சக்தியை இழந்தால், தரவு இழக்கப்படலாம் என்பது தெளிவாகிறது, ஏனெனில் அது நினைவகத்தில் மட்டுமே சேமிக்கப்படுகிறது.
அதே நேரத்தில், ஒரு இடையகத்துடன் கூடிய திட்டம் ALTER ஐ சிக்கலாக்குகிறது, ஏனென்றால் நீங்கள் முதலில் பழைய இடையக அட்டவணையை பழைய திட்டத்துடன் கைவிட வேண்டும் (தரவு எங்கும் மறைந்துவிடாது, ஏனெனில் அட்டவணை நீக்கப்படுவதற்கு முன்பு அது சுத்தப்படுத்தப்படும்). உங்களுக்குத் தேவையான அட்டவணையை "மாற்றி" மீண்டும் இடையக அட்டவணையை உருவாக்கவும். அதன்படி, இடையக அட்டவணை இல்லாதபோது, உங்கள் தரவு எங்கும் செல்லாது, ஆனால் நீங்கள் அதை உள்ளூரில் குறைந்தபட்சம் வட்டில் வைத்திருக்கலாம்.
கிட்டன்ஹவுஸ் என்றால் என்ன, அது எப்படி வேலை செய்கிறது?
கிட்டன்ஹவுஸ் என்றால் என்ன? இது ஒரு ப்ராக்ஸி. எந்த மொழியை யூகிக்க? எனது அறிக்கையில் மிகவும் பிரபலமான தலைப்புகளை நான் சேகரித்தேன் - “கிளிக்ஹவுஸ்”, போ, ஒருவேளை எனக்கு வேறு ஏதாவது நினைவில் இருக்கலாம். ஆம், இது Go இல் எழுதப்பட்டுள்ளது, ஏனென்றால் எனக்கு C இல் எழுதத் தெரியாது, நான் விரும்பவில்லை.
அதன்படி, இது ஒவ்வொரு சர்வருடனும் ஒரு இணைப்பைப் பராமரிக்கிறது மற்றும் நினைவகத்தில் எழுத முடியும். எடுத்துக்காட்டாக, கிளிக்ஹவுஸுக்கு பிழை பதிவுகளை எழுதினால், கிளிக்ஹவுஸுக்கு தரவைச் செருக நேரம் இல்லை என்றால் (எல்லாவற்றிற்கும் மேலாக, அதிகமாக எழுதப்பட்டிருந்தால்), பின்னர் நாம் நினைவகத்தை அதிகரிக்க மாட்டோம் - மீதமுள்ளவற்றை வெறுமனே வெளியேற்றுவோம். ஏனென்றால், ஒரு வினாடிக்கு பல ஜிகாபிட் பிழைகளை எழுதினால், சிலவற்றை வெளியேற்றலாம். கிட்டன்ஹவுஸ் இதைச் செய்யலாம். கூடுதலாக, இது நம்பகமான விநியோகத்தைச் செய்ய முடியும், அதாவது, உள்ளூர் கணினியில் வட்டுக்கு எழுதுகிறது மற்றும் ஒவ்வொரு முறையும் (அங்கு, ஒவ்வொரு இரண்டு வினாடிகளுக்கும் ஒரு முறை) இந்த கோப்பிலிருந்து தரவை வழங்க முயற்சிக்கிறது. முதலில் நாங்கள் வழக்கமான மதிப்புகள் வடிவமைப்பைப் பயன்படுத்தினோம் - சில பைனரி வடிவம் அல்ல, ஒரு உரை வடிவம் (வழக்கமான SQL போல).
ஆனால் பின்னர் இது நடந்தது. நாங்கள் நம்பகமான விநியோகத்தைப் பயன்படுத்தினோம், பதிவுகளை எழுதினோம், பின்னர் முடிவு செய்தோம் (இது நிபந்தனைக்குட்பட்ட சோதனைக் கிளஸ்டர்)... இது பல மணிநேரங்களுக்கு வெளியிடப்பட்டது மற்றும் மீண்டும் கொண்டு வரப்பட்டது, மேலும் ஆயிரம் சர்வர்களில் இருந்து ஒரு செருகல் தொடங்கியது - கிளிக்ஹவுஸில் இன்னும் உள்ளது “த்ரெட் ஆன் கனெக்ஷன்” - அதன்படி, ஆயிரம் இணைப்புகளில், செயலில் உள்ள செருகல் சுமார் ஒன்றரை ஆயிரம் சர்வரில் சுமை சராசரிக்கு வழிவகுக்கிறது. ஆச்சரியப்படும் விதமாக, சேவையகம் கோரிக்கைகளை ஏற்றுக்கொண்டது, ஆனால் சிறிது நேரம் கழித்து தரவு இன்னும் செருகப்பட்டது; ஆனால் சர்வருக்கு அதை வழங்குவது மிகவும் கடினமாக இருந்தது...
nginx ஐச் சேர்க்கவும்
ஒரு இணைப்பு மாதிரிக்கான த்ரெட்க்கான அத்தகைய தீர்வு nginx ஆகும். நாங்கள் கிளிக்ஹவுஸுக்கு முன்னால் nginx ஐ நிறுவினோம், அதே நேரத்தில் இரண்டு பிரதிகளுக்கான சமநிலையை அமைத்தோம் (எங்கள் செருகும் வேகம் 2 மடங்கு அதிகரித்தது, இருப்பினும் இது உண்மை இல்லை) மற்றும் கிளிக்ஹவுஸிற்கான இணைப்புகளின் எண்ணிக்கையை மட்டுப்படுத்தியது. அப்ஸ்ட்ரீம் மற்றும், அதன்படி, மேலும் , 50 இணைப்புகளை விட, செருகுவதில் எந்த அர்த்தமும் இல்லை.
இந்த திட்டத்தில் பொதுவாக குறைபாடுகள் இருப்பதை நாங்கள் உணர்ந்தோம், ஏனென்றால் எங்களிடம் ஒரே ஒரு nginx மட்டுமே உள்ளது. அதன்படி, இந்த nginx செயலிழந்தால், பிரதிகள் இருந்தபோதிலும், நாங்கள் தரவை இழக்கிறோம் அல்லது குறைந்தபட்சம் எங்கும் எழுத வேண்டாம். அதனால்தான் நாங்களே சுமை சமநிலையை உருவாக்கினோம். "கிளிக்ஹவுஸ்" இன்னும் பதிவுகளுக்கு ஏற்றது என்பதை நாங்கள் உணர்ந்தோம், மேலும் "பிசாசு" தனது பதிவுகளை "கிளிக்ஹவுஸ்" இல் எழுதத் தொடங்கினார் - மிகவும் வசதியானது, நேர்மையாக இருக்க வேண்டும். நாங்கள் இன்னும் அதை மற்ற "பேய்களுக்கு" பயன்படுத்துகிறோம்.
இந்த சுவாரஸ்யமான சிக்கலை நாங்கள் கண்டுபிடித்தோம்: நீங்கள் SQL பயன்முறையில் செருகுவதற்கான தரமற்ற முறையைப் பயன்படுத்தினால், அது ஒரு முழு அளவிலான AST- அடிப்படையிலான SQL பாகுபடுத்தியை கட்டாயப்படுத்துகிறது, இது மிகவும் மெதுவாக உள்ளது. அதன்படி, இது ஒருபோதும் நடக்காது என்பதை உறுதிப்படுத்த அமைப்புகளைச் சேர்த்துள்ளோம். லோட் பேலன்சிங், ஹெல்த் செக்கஸ் செய்தோம், அதனால் ஒருவர் இறந்தாலும், டேட்டாவை விட்டுவிடுவோம். எங்களிடம் இப்போது பல டேபிள்கள் உள்ளன, அவை வெவ்வேறு கிளிக்ஹவுஸ் கிளஸ்டர்களைக் கொண்டிருக்க வேண்டும். மற்ற பயன்பாடுகளைப் பற்றியும் சிந்திக்கத் தொடங்கினோம் - எடுத்துக்காட்டாக, நாங்கள் nginx தொகுதிகளிலிருந்து பதிவுகளை எழுத விரும்பினோம், ஆனால் எங்கள் RPC ஐப் பயன்படுத்தி எவ்வாறு தொடர்புகொள்வது என்பது அவர்களுக்குத் தெரியாது. சரி, எப்படியாவது எப்படியாவது அனுப்புவது என்பதை அவர்களுக்குக் கற்பிக்க விரும்புகிறேன் - எடுத்துக்காட்டாக, UDP வழியாக லோக்கல் ஹோஸ்டில் நிகழ்வுகளைப் பெறுவது மற்றும் கிளிக்ஹவுஸுக்கு அனுப்புவது.
தீர்வுக்கு ஒரு படி தூரம்
இறுதித் திட்டம் இப்படித் தோன்றத் தொடங்கியது (இந்தத் திட்டத்தின் நான்காவது பதிப்பு): கிளிக்ஹவுஸுக்கு முன்னால் உள்ள ஒவ்வொரு சேவையகத்திலும் nginx (அதே சேவையகத்தில்) உள்ளது, மேலும் இது 50 இணைப்புகளின் எண்ணிக்கையில் வரம்புடன் லோக்கல் ஹோஸ்டுக்கான கோரிக்கைகளை ப்ராக்ஸி செய்கிறது. துண்டுகள். இந்த திட்டம் ஏற்கனவே நன்றாக வேலை செய்தது, எல்லாம் நன்றாக இருந்தது.
இப்படியே சுமார் ஒரு மாதம் வாழ்ந்தோம். எல்லோரும் மகிழ்ச்சியாக இருந்தார்கள், அவர்கள் அட்டவணைகளைச் சேர்த்தார்கள், அவர்கள் சேர்த்தார்கள், சேர்த்தார்கள்... பொதுவாக, நாங்கள் இடையக அட்டவணைகளைச் சேர்த்த விதம் மிகவும் உகந்ததாக இல்லை என்று மாறியது (அதை அப்படியே வைக்கலாம்). நாங்கள் ஒவ்வொரு அட்டவணையிலும் 16 துண்டுகள் செய்தோம் மற்றும் இரண்டு வினாடிகளின் ஃபிளாஷ் இடைவெளி; எங்களிடம் 20 அட்டவணைகள் இருந்தன, ஒவ்வொரு அட்டவணையும் வினாடிக்கு 8 செருகல்களைப் பெற்றன - இந்த கட்டத்தில் “கிளிக்ஹவுஸ்” தொடங்கியது... பதிவுகள் மெதுவாகத் தொடங்கின. அவர்கள் தேர்ச்சி பெறவில்லை என்பது மட்டுமல்ல... முன்னிருப்பாக, nginx ஆனது அப்ஸ்ட்ரீமில் இணைப்புகள் முடிவடைந்தால், அது அனைத்து புதிய கோரிக்கைகளுக்கும் “502”ஐத் திருப்பி அனுப்பும்.
இங்கே எங்களிடம் உள்ளது (நான் கிளிக்ஹவுஸில் உள்ள பதிவுகளைப் பார்த்தேன்) சுமார் அரை சதவீத கோரிக்கைகள் தோல்வியடைந்தன. அதன்படி, வட்டு பயன்பாடு அதிகமாக இருந்தது, நிறைய இணைப்புகள் இருந்தன. சரி, நான் என்ன செய்தேன்? இயற்கையாகவே, இணைப்பு மற்றும் அப்ஸ்ட்ரீம் ஏன் சரியாக முடிந்தது என்பதைக் கண்டுபிடிக்க நான் கவலைப்படவில்லை.
nginxஐ ரிவர்ஸ் ப்ராக்ஸியுடன் மாற்றுகிறது
இதை நாமே நிர்வகிக்க வேண்டும் என்று முடிவு செய்தேன், அதை nginx க்கு விட தேவையில்லை - கிளிக்ஹவுஸில் என்ன அட்டவணைகள் உள்ளன என்று nginx க்கு தெரியாது, மேலும் nginx ஐ ஒரு தலைகீழ் ப்ராக்ஸியுடன் மாற்றினேன், அதை நானே எழுதினேன்.
அவன் என்ன செய்கிறான்? இது fasthttp நூலகமான "goshnoy" ஐ அடிப்படையாகக் கொண்டு செயல்படுகிறது, அதாவது வேகமாக, கிட்டத்தட்ட nginx போன்ற வேகமாக. மன்னிக்கவும், இகோர், நீங்கள் இங்கே இருந்தால் (குறிப்பு: இகோர் சிசோவ் nginx இணைய சேவையகத்தை உருவாக்கிய ரஷ்ய புரோகிராமர் ஆவார்). இவை என்ன வகையான வினவல்கள் என்பதை இது புரிந்து கொள்ள முடியும் - INSERT அல்லது SELECT - அதன்படி, இது பல்வேறு வகையான வினவல்களுக்கு வெவ்வேறு இணைப்புக் குளங்களை வைத்திருக்கிறது.
அதன்படி, செருகும் கோரிக்கைகளை முடிக்க எங்களுக்கு நேரம் இல்லாவிட்டாலும், "தேர்வுகள்" கடந்து செல்லும், மற்றும் நேர்மாறாகவும். மேலும் இது தரவை இடையக அட்டவணைகளாக - ஒரு சிறிய இடையகத்துடன் தொகுக்கிறது: ஏதேனும் பிழைகள், தொடரியல் பிழைகள் மற்றும் பல இருந்தால் - அவை மற்ற தரவை பெரிதும் பாதிக்காது, ஏனெனில் நாங்கள் வெறுமனே இடையக அட்டவணையில் செருகும்போது, நாங்கள் சிறிய "பாச்சி" இருந்தது, மேலும் அனைத்து தொடரியல் பிழைகளும் இந்த சிறிய பகுதியை மட்டுமே பாதித்தன; இங்கே அவை ஏற்கனவே ஒரு பெரிய இடையகத்தை பாதிக்கும். சிறியது 1 மெகாபைட், அதாவது சிறியது அல்ல.
ஒரு ஒத்திசைவைச் செருகுவது மற்றும் அடிப்படையில் nginx ஐ மாற்றுவது, அடிப்படையில் nginx முன்பு செய்ததைப் போலவே செய்கிறது - இதற்காக நீங்கள் உள்ளூர் "கிட்டன்ஹவுஸ்" ஐ மாற்ற வேண்டியதில்லை. மேலும் இது fasthttp ஐப் பயன்படுத்துவதால், இது மிகவும் வேகமானது - தலைகீழ் ப்ராக்ஸி மூலம் ஒற்றை செருகல்களுக்கு வினாடிக்கு 100 ஆயிரத்துக்கும் மேற்பட்ட கோரிக்கைகளை நீங்கள் செய்யலாம். கோட்பாட்டளவில், கிட்டன்ஹவுஸ் ரிவர்ஸ் ப்ராக்ஸியில் ஒரு நேரத்தில் ஒரு வரியைச் செருகலாம், ஆனால் நிச்சயமாக நாங்கள் அதைச் செய்ய மாட்டோம்.
இந்தத் திட்டம் இப்படித் தோன்றத் தொடங்கியது: “கிட்டன்ஹவுஸ்”, ரிவர்ஸ் ப்ராக்ஸி பல கோரிக்கைகளை அட்டவணைகளாக தொகுக்கிறது, மேலும், இடையக அட்டவணைகள் அவற்றை முக்கியவற்றில் செருகுகின்றன.
கொலையாளி ஒரு தற்காலிக தீர்வு, பூனைக்குட்டி நிரந்தரம்
இது ஒரு சுவாரசியமான பிரச்சனை... உங்களில் யாராவது fasthttp உபயோகித்திருக்கிறீர்களா? POST கோரிக்கைகளுடன் fasthttp ஐப் பயன்படுத்தியவர் யார்? ஒருவேளை, இது உண்மையில் செய்திருக்கக் கூடாது, ஏனெனில் இது இயல்பாகவே கோரிக்கை அமைப்பைத் தாங்கும், மேலும் எங்கள் இடையக அளவு 16 மெகாபைட்டுகளாக அமைக்கப்பட்டுள்ளது. ஒரு கட்டத்தில் செருகுவது நிறுத்தப்பட்டது, மேலும் 16-மெகாபைட் துண்டுகள் அனைத்து பல்லாயிரக்கணக்கான சேவையகங்களிலிருந்தும் வரத் தொடங்கின, மேலும் அவை அனைத்தும் கிளிக்ஹவுஸுக்கு அனுப்பப்படுவதற்கு முன்பு நினைவகத்தில் இடையகப்படுத்தப்பட்டன. அதன்படி, நினைவகம் தீர்ந்துவிட்டது, அவுட்-ஆஃப்-மெமரி கில்லர் வந்து ரிவர்ஸ் ப்ராக்ஸியைக் கொன்றார் (அல்லது "கிளிக்ஹவுஸ்", இது கோட்பாட்டளவில் தலைகீழ் ப்ராக்ஸியை விட அதிகமாக "சாப்பிட" முடியும்). சுழற்சி மீண்டும் மீண்டும். மிகவும் இனிமையான பிரச்சனை இல்லை. என்றாலும் பல மாதங்கள் ஆபரேஷன் செய்த பிறகுதான் நாங்கள் இதில் தடுமாறினோம்.
நான் என்ன செய்தேன்? மீண்டும், சரியாக என்ன நடந்தது என்பதைப் புரிந்து கொள்ள எனக்குப் பிடிக்கவில்லை. நீங்கள் நினைவகத்தில் பஃபர் செய்யக்கூடாது என்பது தெளிவாகத் தெரிகிறது என்று நினைக்கிறேன். நான் முயற்சித்த போதிலும், என்னால் fasthttp ஐ இணைக்க முடியவில்லை. ஆனால் நான் அதை உருவாக்க ஒரு வழியைக் கண்டுபிடித்தேன், அதனால் எதையும் ஒட்ட வேண்டிய அவசியமில்லை, மேலும் HTTP இல் எனது சொந்த முறையைக் கொண்டு வந்தேன் - நான் அதை KITTEN என்று அழைத்தேன். சரி, இது தர்க்கரீதியானது - “வி.கே”, “பூனைக்குட்டி”... வேறு என்ன?..
பூனைக்குட்டி முறையுடன் சேவையகத்திற்கு கோரிக்கை வந்தால், சேவையகம் "மியாவ்" - தர்க்கரீதியாக பதிலளிக்க வேண்டும். இதற்கு அவர் பதிலளித்தால், அவர் இந்த நெறிமுறையைப் புரிந்துகொண்டார் என்று கருதப்படுகிறது, பின்னர் நான் இணைப்பை இடைமறிக்கிறேன் (fasthttp அத்தகைய முறையைக் கொண்டுள்ளது), மேலும் இணைப்பு "raw" பயன்முறையில் செல்கிறது. எனக்கு ஏன் அது தேவை? TCP இணைப்புகளிலிருந்து எப்படிப் படிக்க வேண்டும் என்பதை நான் கட்டுப்படுத்த விரும்புகிறேன். TCP ஒரு அற்புதமான சொத்து உள்ளது: யாரும் மறுபுறம் இருந்து படிக்கவில்லை என்றால், பின்னர் எழுதும் காத்திருக்க தொடங்குகிறது, மற்றும் நினைவகம் குறிப்பாக இந்த செலவிடப்படவில்லை.
அதனால் நான் ஒரே நேரத்தில் சுமார் 50 வாடிக்கையாளர்களிடமிருந்து படித்தேன் (ஐம்பதில் இருந்து, ஏனெனில் ஐம்பது கண்டிப்பாக போதுமானதாக இருக்க வேண்டும், மற்றொரு DC யில் இருந்து விகிதம் வந்தாலும் கூட)... இந்த அணுகுமுறையால் நுகர்வு குறைந்தது 20 முறை குறைந்துள்ளது, ஆனால் நான், நேர்மையாக இருக்க வேண்டும் , எந்த நேரத்தை என்னால் சரியாக அளவிட முடியவில்லை, ஏனென்றால் அது ஏற்கனவே அர்த்தமற்றது (இது ஏற்கனவே பிழையின் அளவை எட்டிவிட்டது). நெறிமுறை பைனரி, அதாவது அட்டவணையின் பெயர் மற்றும் தரவைக் கொண்டுள்ளது; http தலைப்புகள் எதுவும் இல்லை, எனவே நான் ஒரு வலை சாக்கெட்டைப் பயன்படுத்தவில்லை (உலாவிகளுடன் தொடர்பு கொள்ள வேண்டிய அவசியமில்லை - எங்கள் தேவைகளுக்கு ஏற்ற நெறிமுறையை உருவாக்கினேன்). மேலும் அவருடன் எல்லாம் சரியாகிவிட்டது.
தாங்கல் அட்டவணை சோகமாக உள்ளது
சமீபத்தில், இடையக அட்டவணையின் மற்றொரு சுவாரஸ்யமான அம்சத்தைக் கண்டோம். இந்த பிரச்சனை ஏற்கனவே மற்றவர்களை விட மிகவும் வேதனையானது. இந்த சூழ்நிலையை கற்பனை செய்து பாருங்கள்: நீங்கள் ஏற்கனவே கிளிக்ஹவுஸைப் பயன்படுத்துகிறீர்கள், உங்களிடம் டஜன் கணக்கான கிளிக்ஹவுஸ் சேவையகங்கள் உள்ளன, மேலும் உங்களிடம் சில கோரிக்கைகள் உள்ளன, அவை படிக்க நீண்ட நேரம் எடுக்கும் (60 வினாடிகளுக்கு மேல் என்று வைத்துக்கொள்வோம்); இந்த நேரத்தில் நீங்கள் வந்து ஆல்டர் செய்யுங்கள்... இதற்கிடையில், "ஆல்டர்" க்கு முன் தொடங்கிய "தேர்வுகள்" இந்த அட்டவணையில் சேர்க்கப்படாது, "ஆல்டர்" தொடங்காது - ஒருவேளை "கிளிக்ஹவுஸ்" எவ்வாறு செயல்படுகிறது என்பதற்கான சில அம்சங்கள் இந்த இடம். ஒருவேளை இதை சரிசெய்ய முடியுமா? அல்லது முடியாததா?
பொதுவாக, உண்மையில் இது ஒரு பெரிய பிரச்சனை அல்ல என்பது தெளிவாகிறது, ஆனால் இடையக அட்டவணைகள் மிகவும் வேதனையாகின்றன. ஏனெனில், உங்கள் “மாற்று” நேரம் முடிந்துவிட்டால் (மற்றும் அது மற்றொரு ஹோஸ்டில் காலாவதியாகலாம் - உங்களுடையது அல்ல, ஆனால் ஒரு பிரதியில், எடுத்துக்காட்டாக), பிறகு... நீங்கள் இடையக அட்டவணையை நீக்கிவிட்டீர்கள், உங்கள் “மாற்று” ( அல்லது வேறு சில ஹோஸ்ட்) காலாவதியானது. பின்னர் "மாற்றியமை" பிழை ஏற்பட்டது) - தரவு தொடர்ந்து எழுதப்படுவதை நீங்கள் உறுதிப்படுத்த வேண்டும்: நீங்கள் இடையக அட்டவணையை மீண்டும் உருவாக்குகிறீர்கள் (பெற்றோர் அட்டவணையின் அதே திட்டத்தின் படி), பின்னர் "Alter" வழியாகச் சென்று, முடிவடைகிறது, மேலும் அட்டவணையானது பெற்றோரிடமிருந்து ஸ்கீமாவில் வேறுபடத் தொடங்குகிறது. "மாற்று" என்ன என்பதைப் பொறுத்து, செருகல் இந்த இடையக அட்டவணைக்கு செல்லாமல் போகலாம் - இது மிகவும் வருத்தமாக இருக்கிறது.
அத்தகைய அடையாளமும் உள்ளது (ஒருவேளை யாராவது அதைக் கவனித்திருக்கலாம்) - இது Clickhouse இன் புதிய பதிப்புகளில் query_thread_log என்று அழைக்கப்படுகிறது. இயல்பாக, சில பதிப்பில் ஒன்று இருந்தது. இங்கு ஓரிரு மாதங்களில் (840 ஜிகாபைட்) 100 மில்லியன் பதிவுகளைக் குவித்துள்ளோம். "செருகுகள்" அங்கு எழுதப்பட்டிருப்பதே இதற்குக் காரணம் (ஒருவேளை இப்போது, அவை எழுதப்படவில்லை). நான் உங்களுக்குச் சொன்னது போல், எங்கள் “செருகுகள்” சிறியவை - இடையக அட்டவணையில் எங்களிடம் நிறைய “செருகுகள்” உள்ளன. இது முடக்கப்பட்டுள்ளது என்பது தெளிவாகிறது - எங்கள் சர்வரில் நான் பார்த்ததைச் சொல்கிறேன். ஏன்? இது இடையக அட்டவணைகளைப் பயன்படுத்துவதற்கு எதிரான மற்றொரு வாதம்! ஸ்பாட்டி மிகவும் வருத்தமாக இருக்கிறது.
இந்த பையனின் பெயர் ஸ்பாட்டி என்று யாருக்குத் தெரியும்? VK ஊழியர்கள் கைகளை உயர்த்தினார்கள். சரி.
"கிட்டன்ஹவுஸ்" திட்டங்கள் பற்றி
திட்டங்கள் பொதுவாக பகிரப்படுவதில்லை, இல்லையா? திடீரென்று நீங்கள் அவற்றை நிறைவேற்ற மாட்டீர்கள், மற்றவர்களின் பார்வையில் மிகவும் அழகாக இருக்க மாட்டீர்கள். ஆனால் நான் ரிஸ்க் எடுப்பேன்! நாங்கள் பின்வருவனவற்றைச் செய்ய விரும்புகிறோம்: இடையக அட்டவணைகள், இன்னும் ஊன்றுகோல் என்று எனக்குத் தோன்றுகிறது, மேலும் செருகலை நாமே இடையகப்படுத்த வேண்டும். ஆனால் நாம் இன்னும் அதை வட்டில் இடையகப்படுத்த விரும்பவில்லை, எனவே நினைவகத்தில் செருகுவதை இடையகப்படுத்துவோம்.
அதன்படி, ஒரு “செருகு” செய்யப்படும்போது, அது இனி ஒத்திசைவாக இருக்காது - இது ஏற்கனவே ஒரு இடையக அட்டவணையாக வேலை செய்யும், பெற்றோர் அட்டவணையில் (சரி, ஒரு நாள் கழித்து) செருகப்படும் மற்றும் ஒரு தனி சேனல் வழியாகப் புகாரளிக்கும். இன்னும் இல்லை.
ஒத்திசைவான செருகலை நான் ஏன் விட்டுவிட முடியாது? இது மிகவும் வசதியானது. உண்மை என்னவென்றால், நீங்கள் 10 ஆயிரம் ஹோஸ்ட்களில் இருந்து செருகினால், எல்லாம் நன்றாக இருக்கிறது - ஒவ்வொரு ஹோஸ்டிலிருந்தும் நீங்கள் சிறிது சிறிதளவு பெறுவீர்கள், ஒரு வினாடிக்கு ஒருமுறை அங்கு செருகினால், எல்லாம் நன்றாக இருக்கிறது. ஆனால் இந்த திட்டம் செயல்பட வேண்டும் என்று நான் விரும்புகிறேன், எடுத்துக்காட்டாக, இரண்டு இயந்திரங்களில் இருந்து, நீங்கள் அதிவேகத்தில் பதிவிறக்கம் செய்யலாம் - ஒருவேளை கிளிக்ஹவுஸிலிருந்து அதிகபட்சமாகப் பெற முடியாது, ஆனால் ஒரு கணினியிலிருந்து தலைகீழ் ப்ராக்ஸி மூலம் வினாடிக்கு குறைந்தது 100 மெகாபைட்களை எழுதுங்கள் - இந்த திட்டம் பெரிய மற்றும் சிறிய அளவுகளுக்கு அளவிடப்பட வேண்டும், எனவே ஒவ்வொரு செருகலுக்கும் ஒரு நொடி காத்திருக்க முடியாது, எனவே அது ஒத்திசைவற்றதாக இருக்க வேண்டும். அதே வழியில், செருகல் முடிந்ததும் ஒத்திசைவற்ற உறுதிப்படுத்தல்கள் வர வேண்டும். அது நிறைவேறியதா இல்லையா என்பதை நாங்கள் அறிவோம்.
மிக முக்கியமான விஷயம் என்னவென்றால், இந்த திட்டத்தில் செருகல் நடந்ததா இல்லையா என்பதை நாங்கள் உறுதியாக அறிவோம். இந்த சூழ்நிலையை கற்பனை செய்து பாருங்கள்: உங்களிடம் ஒரு இடையக அட்டவணை உள்ளது, நீங்கள் அதில் ஏதாவது எழுதியுள்ளீர்கள், பின்னர், அட்டவணை படிக்க மட்டும் பயன்முறையில் சென்று இடையகத்தை பறிக்க முயற்சித்தது என்று வைத்துக்கொள்வோம். தரவு எங்கே போகும்? அவை இடையகத்திலேயே இருக்கும். ஆனால் இதைப் பற்றி நாம் உறுதியாக இருக்க முடியாது - வேறு ஏதேனும் பிழை இருந்தால், அதன் காரணமாக தரவு இடையகத்திலேயே இருக்காது ... (அலெக்ஸி மிலோவிடோவ், யாண்டெக்ஸ், கிளிக்ஹவுஸ் டெவலப்பர் முகவரிகள்) அல்லது அது அப்படியே இருக்குமா? எப்போதும்? எல்லாம் சரியாகிவிடும் என்று அலெக்ஸி நம்மை நம்ப வைக்கிறார். அவரை நம்பாததற்கு எங்களுக்கு எந்த காரணமும் இல்லை. ஆனால் ஒரே மாதிரியானவை: நாங்கள் இடையக அட்டவணையைப் பயன்படுத்தாவிட்டால், அவற்றில் எந்த பிரச்சனையும் இருக்காது. இரண்டு மடங்கு அட்டவணைகளை உருவாக்குவதும் சிரமமாக உள்ளது, இருப்பினும் கொள்கையளவில் பெரிய சிக்கல்கள் எதுவும் இல்லை. இதுதான் திட்டம்.
வாசிப்பு பற்றி பேசலாம்
இப்போது வாசிப்பு பற்றி பேசலாம். நாங்கள் எங்கள் சொந்த கருவியையும் இங்கே எழுதினோம். உங்கள் சொந்த கருவியை ஏன் இங்கே எழுத வேண்டும் என்று தோன்றுகிறது?.. மற்றும் Tabix ஐப் பயன்படுத்தியது யார்? எப்படியோ சிலர் கையை உயர்த்தினார்கள்... மேலும் Tabix இன் நடிப்பில் யார் திருப்தி அடைகிறார்கள்? சரி, நாங்கள் அதில் மகிழ்ச்சியடையவில்லை, மேலும் தரவைப் பார்ப்பதற்கு இது மிகவும் வசதியாக இல்லை. பகுப்பாய்விற்கு இது நன்றாக இருக்கிறது, ஆனால் பார்ப்பதற்கு இது தெளிவாக உகந்ததாக இல்லை. எனவே எனது சொந்த, எனது சொந்த இடைமுகத்தை எழுதினேன்.
இது மிகவும் எளிமையானது - இது தரவை மட்டுமே படிக்க முடியும். அவருக்கு கிராபிக்ஸ் காட்டத் தெரியாது, எதுவும் செய்யத் தெரியாது. ஆனால் இது நமக்குத் தேவையானதைக் காண்பிக்கும்: எடுத்துக்காட்டாக, அட்டவணையில் எத்தனை வரிசைகள் உள்ளன, எவ்வளவு இடம் எடுக்கும் (அதை நெடுவரிசைகளாகப் பிரிக்காமல்), அதாவது, மிக அடிப்படையான இடைமுகம் நமக்குத் தேவை.
இது சீக்வெல் ப்ரோவைப் போலவே தோன்றுகிறது, ஆனால் ட்விட்டரின் பூட்ஸ்டார்ப் மற்றும் இரண்டாவது பதிப்பில் மட்டுமே உருவாக்கப்பட்டது. நீங்கள் கேட்கிறீர்கள்: "யூரி, இரண்டாவது பதிப்பில் ஏன்?" என்ன வருடம்? 2018? பொதுவாக, "தசை" (MySQL) க்காக நான் இதை நீண்ட காலத்திற்கு முன்பு செய்தேன், மேலும் அங்குள்ள வினவல்களில் இரண்டு வரிகளை மாற்றினேன், மேலும் இது "கிளிக்ஹவுஸ்" க்காக வேலை செய்யத் தொடங்கியது, இதற்கு சிறப்பு நன்றி! ஏனெனில் பாகுபடுத்தி "தசை" ஒன்றுடன் மிகவும் ஒத்திருக்கிறது, மேலும் வினவல்கள் மிகவும் ஒத்தவை - மிகவும் வசதியானது, குறிப்பாக முதலில்.
சரி, இது அட்டவணைகளை வடிகட்டலாம், அட்டவணையின் கட்டமைப்பு மற்றும் உள்ளடக்கங்களைக் காட்டலாம், வரிசைப்படுத்தவும், நெடுவரிசைகள் மூலம் வடிகட்டவும் உங்களை அனுமதிக்கிறது, விளைவாக விளைந்த வினவலைக் காட்டுகிறது, பாதிக்கப்பட்ட வரிசைகள் (இதன் விளைவாக எத்தனை), அதாவது, தரவைப் பார்ப்பதற்கான அடிப்படை விஷயங்கள். மிக வேகமாக.
எடிட்டரும் இருக்கிறார். நான் நேர்மையாக Tabix இலிருந்து முழு எடிட்டரையும் திருட முயற்சித்தேன், ஆனால் என்னால் முடியவில்லை. ஆனால் எப்படியோ அது வேலை செய்கிறது. கொள்கையளவில், அவ்வளவுதான்.
"கிளிக்ஹவுஸ்" குகைகளுக்கு ஏற்றது
கிளிக்ஹவுஸ், விவரிக்கப்பட்டுள்ள அனைத்து சிக்கல்களையும் மீறி, பதிவுகளுக்கு மிகவும் பொருத்தமானது என்பதை நான் உங்களுக்குச் சொல்ல விரும்புகிறேன். மிக முக்கியமாக, இது எங்கள் சிக்கலை தீர்க்கிறது - இது மிக வேகமாக உள்ளது மற்றும் நெடுவரிசைகள் மூலம் பதிவுகளை வடிகட்ட உங்களை அனுமதிக்கிறது. கொள்கையளவில், இடையக அட்டவணைகள் சிறப்பாக செயல்படவில்லை, ஆனால் பொதுவாக யாருக்கும் ஏன் என்று தெரியாது... ஒருவேளை இப்போது உங்களுக்கு எங்கே பிரச்சனைகள் இருக்கும் என்பது உங்களுக்கு நன்றாகத் தெரியும்.
TCP? பொதுவாக, VK இல் UDP ஐப் பயன்படுத்துவது வழக்கம். நான் TCP ஐப் பயன்படுத்தியபோது ... நிச்சயமாக, யாரும் என்னிடம் சொல்லவில்லை: "யூரி, நீங்கள் எதைப் பற்றி பேசுகிறீர்கள்! உங்களால் முடியாது, உங்களுக்கு UDP தேவை." TCP மிகவும் பயமாக இல்லை என்று மாறியது. ஒரே விஷயம் என்னவென்றால், நீங்கள் எழுதும் பல்லாயிரக்கணக்கான செயலில் உள்ள கலவைகள் இருந்தால், நீங்கள் அதை இன்னும் கொஞ்சம் கவனமாக தயார் செய்ய வேண்டும்; ஆனால் அது சாத்தியம் மற்றும் மிகவும் எளிதானது.
எங்கள் பொது "VK பின்தளத்தில்" அனைவரும் குழுசேர்ந்தால், ஹைலோட் சைபீரியாவில் "கிட்டன்ஹவுஸ்" மற்றும் "லைட்ஹவுஸ்" ஆகியவற்றை இடுகையிடுவதாக நான் உறுதியளித்தேன்... உங்களுக்குத் தெரியும், எல்லோரும் குழுசேரவில்லை. பொது உங்களில் இன்னும் பலர் உள்ளனர், யாராவது புண்படுத்தப்படலாம், ஆனால் இன்னும், தயவுசெய்து குழுசேரவும் (இங்கே நான் பூனையின் கண்களைப் போல உருவாக்க வேண்டும்). அது . மிக்க நன்றி! கிதுப் எங்களுடையது . கிளிக்ஹவுஸ் மூலம் உங்கள் தலைமுடி மென்மையாகவும், பட்டு போலவும் இருக்கும்.
முன்னணி: - நண்பர்களே, இப்போது கேள்விகளுக்கு. நாங்கள் பாராட்டுச் சான்றிதழையும் VHS பற்றிய உங்கள் அறிக்கையையும் வழங்கிய உடனேயே.
யூரி நஸ்ரெட்டினோவ் (இனிமேல் YN என குறிப்பிடப்படுகிறது): – VHS இல் எனது அறிக்கை முடிந்துவிட்டால் உங்களால் எப்படி பதிவு செய்ய முடிந்தது?
முன்னணி: - "கிளிக்ஹவுஸ்" எவ்வாறு செயல்படும் அல்லது இல்லையா என்பதை நீங்கள் முழுமையாக தீர்மானிக்க முடியாது! நண்பர்களே, கேள்விகளுக்கு 5 நிமிடங்கள்!
உங்கள் கேள்விகள்
பார்வையாளர்களிடமிருந்து கேள்வி (இனி கே என குறிப்பிடப்படுகிறது): - மதிய வணக்கம். அறிக்கைக்கு மிக்க நன்றி. என்னிடம் இரண்டு கேள்விகள் உள்ளன. நான் அற்பமான ஒன்றைத் தொடங்குவேன்: வரைபடங்களில் (3, 4, 7...) "கிட்டன்ஹவுஸ்" என்ற பெயரில் t என்ற எழுத்துக்களின் எண்ணிக்கை பூனைகளின் திருப்தியைப் பாதிக்கிறதா?
ஒய்என்: - என்ன அளவு?
Z: – கடிதம் டி. மூன்று டிகள் உள்ளன, எங்காவது மூன்று டிகள் உள்ளன.
ஒய்என்: - நான் அதை சரிசெய்யவில்லையா? சரி, நிச்சயமாக அது செய்கிறது! இவை வெவ்வேறு தயாரிப்புகள் - இந்த நேரத்தில் நான் உங்களை ஏமாற்றிக்கொண்டிருந்தேன். சரி, நான் கேலி செய்கிறேன் - அது முக்கியமில்லை. ஆ, இங்கேயே! இல்லை, அதே விஷயம், நான் எழுத்துப்பிழை செய்தேன்.
Z: - நன்றி. இரண்டாவது கேள்வி தீவிரமானது. நான் புரிந்து கொண்டவரை, கிளிக்ஹவுஸில், இடையக அட்டவணைகள் நினைவகத்தில் பிரத்தியேகமாக வாழ்கின்றன, வட்டில் இடையகப்படுத்தப்படாது, அதன்படி, நிலைத்திருக்காது.
ஒய்என்: - ஆம்.
Z: - அதே நேரத்தில், உங்கள் கிளையன்ட் வட்டுக்கு இடையகப்படுத்துகிறது, இது இதே பதிவுகளை வழங்குவதற்கான சில உத்தரவாதத்தைக் குறிக்கிறது. ஆனால் கிளிக்ஹவுஸில் இதற்கு எந்த வகையிலும் உத்தரவாதம் இல்லை. உத்தரவாதம் எவ்வாறு மேற்கொள்ளப்படுகிறது, எதன் காரணமாக?
ஒய்என்: - ஆம், கோட்பாட்டளவில் இங்கு முரண்பாடுகள் எதுவும் இல்லை, ஏனென்றால் கிளிக்ஹவுஸ் வீழ்ச்சியடையும் போது, நீங்கள் உண்மையில் ஒரு மில்லியன் வெவ்வேறு வழிகளில் அதைக் கண்டறியலாம். கிளிக்ஹவுஸ் செயலிழந்தால் (அது தவறாக முடிவடைந்தால்), தோராயமாகச் சொன்னால், நீங்கள் எழுதிவைத்த உங்கள் பதிவில் சிறிது ரிவைண்ட் செய்து, எல்லாம் சரியாக இருந்த தருணத்திலிருந்து தொடங்கலாம். ஒரு நிமிடம் ரீவைண்ட் செய்யுங்கள் என்று வைத்துக்கொள்வோம்.
Z: - அதாவது, "கிட்டன்ஹவுஸ்" ஜன்னலை நீண்ட நேரம் வைத்திருக்கிறது, விழுந்தால், அதை அடையாளம் கண்டு அதை முன்னாடி செய்ய முடியுமா?
ஒய்என்: - ஆனால் இது கோட்பாட்டில் உள்ளது. நடைமுறையில், நாங்கள் இதைச் செய்ய மாட்டோம், மேலும் நம்பகமான விநியோகம் பூஜ்ஜியத்திலிருந்து முடிவிலி முறை வரை இருக்கும். ஆனால் சராசரியாக ஒன்று. சில காரணங்களுக்காக கிளிக்ஹவுஸ் செயலிழந்தால் அல்லது சேவையகங்கள் "மறுதொடக்கம்" செய்தால், நாங்கள் கொஞ்சம் இழக்கிறோம் என்பதில் நாங்கள் திருப்தி அடைகிறோம். மற்ற எல்லா சந்தர்ப்பங்களிலும், எதுவும் நடக்காது.
Z: - வணக்கம். அறிக்கையின் ஆரம்பத்திலிருந்தே நீங்கள் உண்மையில் UDP ஐப் பயன்படுத்துவீர்கள் என்று ஆரம்பத்தில் இருந்தே எனக்குத் தோன்றியது. உங்களிடம் http உள்ளது, அதெல்லாம்... மேலும் நீங்கள் விவரித்த பெரும்பாலான பிரச்சனைகள், நான் புரிந்து கொண்டபடி, இந்த குறிப்பிட்ட தீர்வினால் ஏற்பட்டவை...
ஒய்என்: - நாம் TCP எதைப் பயன்படுத்துகிறோம்?
Z: - அடிப்படையில் ஆம்.
ஒய்என்: - இல்லை.
Z: - fasthttp இல் தான் உங்களுக்கு சிக்கல்கள் இருந்தன, இணைப்பில் உங்களுக்கு சிக்கல்கள் இருந்தன. நீங்கள் UDP ஐப் பயன்படுத்தியிருந்தால் சிறிது நேரத்தைச் சேமித்திருப்பீர்கள். நீண்ட செய்திகள் அல்லது வேறு ஏதாவது பிரச்சனைகள் இருக்கும்...
ஒய்என்: - எதனுடன்?
Z: – நீண்ட செய்திகளுடன், அது MTU க்கு பொருந்தாமல் போகலாம் என்பதால், வேறு ஏதாவது... சரி, அவர்களுடைய சொந்த பிரச்சனைகள் இருக்கலாம். கேள்வி: ஏன் UDP இல்லை?
ஒய்என்: – டிசிபி/ஐபியை உருவாக்கிய ஆசிரியர்கள் என்னை விட மிகவும் புத்திசாலிகள் என்றும், பாக்கெட்டுகளை வரிசைப்படுத்துவது எப்படி என்று என்னை விட நன்றாகத் தெரியும் என்றும் நான் நம்புகிறேன் (அதன் மூலம் அவை செல்கின்றன), அதே நேரத்தில் அனுப்பும் சாளரத்தை சரிசெய்யவும், நெட்வொர்க்கை ஓவர்லோட் செய்யாமல், எதைப் பற்றி கருத்து தெரிவிக்கவும் படிக்கவில்லை, மறுபுறம் எண்ணவில்லை... இந்தப் பிரச்சனைகள் அனைத்தும், UDP இல் இருக்கும் என்பது என் கருத்து, அதே விஷயத்தை நானே செயல்படுத்துவதற்கு நான் ஏற்கனவே எழுதியதை விட அதிகமான குறியீட்டை எழுத வேண்டும். மோசமாக. சியில் எழுதுவது கூட எனக்குப் பிடிக்கவில்லை, அங்கே ஒருபுறம் இருக்கட்டும்...
Z: - வசதியானது! அனுப்பப்பட்டது சரி, எதற்கும் காத்திருக்க வேண்டாம் - இது முற்றிலும் ஒத்திசைவற்றது. எல்லாம் நன்றாக இருக்கிறது என்று ஒரு அறிவிப்பு வந்தது - அது வந்துவிட்டது என்று அர்த்தம்; அது வரவில்லை என்றால், அது மோசமானது என்று அர்த்தம்.
ஒய்என்: - எனக்கு இரண்டும் தேவை - டெலிவரிக்கான உத்தரவாதத்துடன் மற்றும் டெலிவரிக்கான உத்தரவாதம் இல்லாமல் இரண்டையும் என்னால் அனுப்ப முடியும். இவை இரண்டு வெவ்வேறு காட்சிகள். நான் சில பதிவுகளை இழக்கக்கூடாது அல்லது காரணத்துக்குள் அவற்றை இழக்கக்கூடாது.
Z: - நான் நேரத்தை வீணடிக்க மாட்டேன். இது மேலும் விவாதிக்கப்பட வேண்டும். நன்றி.
முன்னணி: – யாருக்கு கேள்விகள் – கைகள் வானத்தை நோக்கி!
Z: - வணக்கம், நான் சாஷா. அறிக்கையின் நடுவில் எங்காவது, டிசிபிக்கு கூடுதலாக, ஒரு ஆயத்த தீர்வைப் பயன்படுத்த முடியும் என்ற உணர்வு தோன்றியது - சில வகையான காஃப்கா.
ஒய்என்: – சரி... நான் இடைநிலை சேவையகங்களைப் பயன்படுத்த விரும்பவில்லை என்று சொன்னேன், ஏனென்றால்... காஃப்காவில், எங்களிடம் பத்தாயிரம் ஹோஸ்ட்கள் உள்ளன என்று மாறிவிடும்; உண்மையில், எங்களிடம் அதிகம் - பல்லாயிரக்கணக்கான ஹோஸ்ட்கள் உள்ளன. எந்த ப்ராக்ஸியும் இல்லாமல் காஃப்காவுடன் செய்வது வேதனையாக இருக்கும். கூடுதலாக, மிக முக்கியமாக, இது இன்னும் "தாமதத்தை" தருகிறது, இது உங்களிடம் இருக்க வேண்டிய கூடுதல் ஹோஸ்ட்களை வழங்குகிறது. ஆனால் நான் அவற்றைப் பெற விரும்பவில்லை - எனக்கு வேண்டும் ...
Z: "ஆனால் இறுதியில் அது எப்படியும் மாறியது."
ஒய்என்: - இல்லை, ஹோஸ்ட்கள் இல்லை! இவை அனைத்தும் Clickhouse ஹோஸ்ட்களில் வேலை செய்யும்.
Z: - சரி, மற்றும் "கிட்டன்ஹவுஸ்", இது தலைகீழ் - அவர் எங்கே வசிக்கிறார்?
ஒய்என்: – Clickhouse ஹோஸ்டில், அது வட்டில் எதையும் எழுதாது.
Z: - நாம் வைத்துக்கொள்வோம்.
முன்னணி: - நீங்கள் திருப்தியா? சம்பளம் தர முடியுமா?
Z: - ஆமாம் உன்னால் முடியும். உண்மையில், அதே விஷயத்தைப் பெறுவதற்கு நிறைய ஊன்றுகோல்கள் உள்ளன, இப்போது - TCP என்ற தலைப்பில் முந்தைய பதில் முரண்படுகிறது, என் கருத்துப்படி, இந்த சூழ்நிலை. எல்லாவற்றையும் மிகக் குறைந்த நேரத்தில் என் மண்டியிட்டுச் செய்திருக்கலாம் என்று உணர்கிறது.
ஒய்என்: - மேலும் நான் ஏன் காஃப்காவைப் பயன்படுத்த விரும்பவில்லை, ஏனென்றால் கிளிக்ஹவுஸ் டெலிகிராம் அரட்டையில் நிறைய புகார்கள் இருந்தன, எடுத்துக்காட்டாக, காஃப்காவிடமிருந்து செய்திகள் தொலைந்துவிட்டன. காஃப்காவிலிருந்தே அல்ல, ஆனால் காஃப்கா மற்றும் கிளிக்ஹாஸின் ஒருங்கிணைப்பில்; அல்லது ஏதோ ஒன்று அங்கு இணைக்கப்படவில்லை. தோராயமாகச் சொன்னால், காஃப்காவுக்கு ஒரு கிளையண்ட் எழுதுவது அவசியம். எளிமையான அல்லது நம்பகமான தீர்வு இருக்க முடியும் என்று நான் நினைக்கவில்லை.
Z: - சொல்லுங்கள், நீங்கள் ஏன் வரிசைகள் அல்லது சில பொதுவான பஸ்ஸை முயற்சிக்கவில்லை? ஒத்திசைவின்மையுடன் நீங்கள் பதிவுகளை வரிசை வழியாக அனுப்பலாம் மற்றும் வரிசையின் மூலம் ஒத்திசைவற்ற முறையில் பதிலைப் பெறலாம் என்று நீங்கள் கூறுகிறீர்களா?
ஒய்என்: - என்ன வரிசைகளைப் பயன்படுத்தலாம் என்று பரிந்துரைக்கவும்?
Z: - ஏதேனும், அவை ஒழுங்காக உள்ளன என்பதற்கான உத்தரவாதம் இல்லாமல் கூட. சில வகையான ரெடிஸ், RMQ...
ஒய்என்: - கிளிக்ஹவுஸை வெளியே இழுக்கும் ஒரு ஹோஸ்டில் (பல சேவையகங்களின் அர்த்தத்தில்) கூட ரெடிஸ் அத்தகைய செருகலின் அளவை பெரும்பாலும் இழுக்க முடியாது என்று நான் உணர்கிறேன். இதை எந்த ஆதாரத்துடன் என்னால் ஆதரிக்க முடியாது (நான் அதை பெஞ்ச்மார்க் செய்யவில்லை), ஆனால் இங்கு ரெடிஸ் சிறந்த தீர்வு அல்ல என்று எனக்குத் தோன்றுகிறது. கொள்கையளவில், இந்த அமைப்பை மேம்படுத்தப்பட்ட செய்தி வரிசையாகக் கருதலாம், ஆனால் இது "கிளிக்ஹவுஸ்" க்காக மட்டுமே வடிவமைக்கப்பட்டுள்ளது.
முன்னணி: - யூரி, மிக்க நன்றி. கேள்விகள் மற்றும் பதில்களை இங்கே முடித்துவிட்டு கேள்வி கேட்டவர்களில் யாருக்கு புத்தகம் கொடுப்போம் என்று கூற முன்மொழிகிறேன்.
ஒய்என்: – முதலில் கேள்வி கேட்டவருக்கு புத்தகம் கொடுக்க விரும்புகிறேன்.
முன்னணி: - அற்புதம்! நன்று! அற்புதமான! மிக்க நன்றி!
சில விளம்பரங்கள் 🙂
எங்களுடன் தங்கியதற்கு நன்றி. எங்கள் கட்டுரைகளை விரும்புகிறீர்களா? மேலும் சுவாரஸ்யமான உள்ளடக்கத்தைப் பார்க்க வேண்டுமா? ஒரு ஆர்டரை வைப்பதன் மூலம் அல்லது நண்பர்களுக்கு பரிந்துரை செய்வதன் மூலம் எங்களை ஆதரிக்கவும், , நுழைவு-நிலை சேவையகங்களின் தனித்துவமான அனலாக், இது உங்களுக்காக எங்களால் கண்டுபிடிக்கப்பட்டது: (RAID1 மற்றும் RAID10 உடன் கிடைக்கும், 24 கோர்கள் வரை மற்றும் 40GB DDR4 வரை).
ஆம்ஸ்டர்டாமில் உள்ள Equinix Tier IV தரவு மையத்தில் Dell R730xd 2 மடங்கு மலிவானதா? இங்கே மட்டும் நெதர்லாந்தில்! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 முதல்! பற்றி படிக்கவும்
ஆதாரம்: www.habr.com