ஏப்ரலில், Avito பொறியாளர்கள் முக்கிய ClickHouse டெவலப்பர் அலெக்ஸி மிலோவிடோவ் மற்றும் Integros இன் கோலாங் டெவலப்பரான Kirill Shvakov ஆகியோருடன் ஆன்லைன் சந்திப்புகளுக்கு கூடினர். தரவுத்தள மேலாண்மை அமைப்பை நாங்கள் எவ்வாறு பயன்படுத்துகிறோம் மற்றும் என்ன சிரமங்களை எதிர்கொள்கிறோம் என்பதை நாங்கள் விவாதித்தோம்.
சந்திப்பின் அடிப்படையில், காப்புப்பிரதிகள், தரவு மறுபகிர்வு, வெளிப்புற அகராதிகள், கோலாங் இயக்கி மற்றும் கிளிக்ஹவுஸ் பதிப்புகளைப் புதுப்பித்தல் பற்றிய எங்கள் மற்றும் பார்வையாளர்களின் கேள்விகளுக்கு நிபுணர்களின் பதில்களுடன் ஒரு கட்டுரையைத் தொகுத்துள்ளோம். ஏற்கனவே Yandex DBMS உடன் தீவிரமாக பணிபுரியும் மற்றும் அதன் தற்போதைய மற்றும் எதிர்காலத்தில் ஆர்வமுள்ள டெவலப்பர்களுக்கு இது பயனுள்ளதாக இருக்கும். இயல்பாக, பதில்கள் அலெக்ஸி மிலோவிடோவ், இல்லையெனில் எழுதப்பட்டால் தவிர.
கவனமாக இருங்கள், வெட்டுக்குக் கீழே நிறைய உரை உள்ளது. கேள்விகளைக் கொண்ட உள்ளடக்கம் வழிசெலுத்த உதவும் என்று நம்புகிறோம்.
உள்ளடக்கம்
நீங்கள் உரையைப் படிக்க விரும்பவில்லை என்றால், கூட்டங்களின் பதிவைப் பார்க்கலாம் . வீடியோவின் கீழ் முதல் கருத்துரையில் நேரக் குறியீடுகள் உள்ளன.
ClickHouse தொடர்ந்து புதுப்பிக்கப்படுகிறது, ஆனால் எங்கள் தரவு இல்லை. அதற்கு என்ன செய்வது?
ClickHouse தொடர்ந்து புதுப்பிக்கப்படுகிறது, மேலும் மேம்படுத்தப்பட்ட இறுதி செயலாக்கப்பட்ட எங்கள் தரவு புதுப்பிக்கப்படவில்லை மற்றும் காப்பு பிரதியில் உள்ளது.
எங்களுக்கு சில சிக்கல்கள் மற்றும் தரவு தொலைந்துவிட்டதாக வைத்துக்கொள்வோம். நாங்கள் மீட்டமைக்க முடிவு செய்தோம், மேலும் காப்புப்பிரதி சேவையகங்களில் சேமிக்கப்பட்டுள்ள பழைய பகிர்வுகள், கிளிக்ஹவுஸின் தற்போது பயன்படுத்தப்படும் பதிப்பிலிருந்து மிகவும் வேறுபட்டவை என்று மாறியது. அத்தகைய சூழ்நிலையில் என்ன செய்வது, அது சாத்தியமா?
பழைய வடிவத்தில் காப்புப்பிரதியிலிருந்து தரவை மீட்டெடுத்த சூழ்நிலை, ஆனால் அது புதிய பதிப்போடு இணைக்கப்படாமல் இருப்பது சாத்தியமற்றது. ClickHouse இல் உள்ள தரவு வடிவம் எப்போதும் பின்னோக்கி இணக்கமாக இருப்பதை உறுதிசெய்கிறோம். அரிதாகப் பயன்படுத்தப்படும் சில செயல்பாட்டின் நடத்தை மாறியிருந்தால், செயல்பாட்டில் பின்தங்கிய இணக்கத்தன்மையை விட இது மிகவும் முக்கியமானது. கிளிக்ஹவுஸின் புதிய பதிப்பானது வட்டில் சேமிக்கப்பட்டுள்ள தரவை எப்போதும் படிக்கக்கூடியதாக இருக்க வேண்டும். இதுதான் சட்டம்.
ClickHouse இலிருந்து தரவை காப்புப் பிரதி எடுப்பதற்கான தற்போதைய சிறந்த நடைமுறைகள் யாவை?
இறுதிச் செயல்பாடுகள், டெராபைட்டுகளின் மிகப்பெரிய தரவுத்தளம் மற்றும் கடந்த மூன்று நாட்களாகப் புதுப்பிக்கப்பட்ட தரவு, மற்றும் அதற்குப் பிறகு எந்த நடைமுறையும் நடக்கவில்லை என்பதை கணக்கில் எடுத்துக்கொண்டு, காப்புப்பிரதிகளை எவ்வாறு உருவாக்குவது?
நாங்கள் எங்கள் சொந்த தீர்வை உருவாக்கி, பாஷில் எழுதலாம்: இந்த காப்பு பிரதிகளை இதுபோன்ற மற்றும் ஒரு வழியில் சேகரிக்கவும். ஒருவேளை ஊன்றுகோல் எதுவும் தேவையில்லை, மற்றும் சைக்கிள் நீண்ட காலத்திற்கு முன்பே கண்டுபிடிக்கப்பட்டதா?
சிறந்த நடைமுறைகளுடன் ஆரம்பிக்கலாம். காப்புப்பிரதிகள் பற்றிய கேள்விகளுக்கு பதிலளிக்கும் விதமாக, இந்த சிக்கல் ஏற்கனவே தீர்க்கப்பட்ட Yandex.Cloud சேவையைப் பற்றி அவர்களுக்கு நினைவூட்ட எனது சகாக்கள் எப்போதும் அறிவுறுத்துகிறார்கள். எனவே முடிந்தால் பயன்படுத்தவும்.
காப்புப்பிரதிகளுக்கு முழுமையான தீர்வு இல்லை, நூறு சதவீதம் ClickHouse இல் கட்டமைக்கப்பட்டுள்ளது. பயன்படுத்தக்கூடிய சில வெற்றிடங்கள் உள்ளன. ஒரு முழுமையான தீர்வைப் பெற, நீங்கள் சிறிது கைமுறையாக டிங்கர் செய்ய வேண்டும் அல்லது ஸ்கிரிப்ட் வடிவில் ரேப்பர்களை உருவாக்க வேண்டும்.
தரவின் அளவு மற்றும் க்ளஸ்டரின் அளவைப் பொறுத்து, எளிமையான தீர்வுகளுடன் தொடங்கி, அதிநவீன தீர்வுகளுடன் முடிப்பேன். பெரிய கொத்து, தீர்வு மிகவும் சிக்கலானதாக மாறும்.
தரவு கொண்ட அட்டவணை சில ஜிகாபைட்களை மட்டுமே ஆக்கிரமித்திருந்தால், காப்புப்பிரதியை இப்படிச் செய்யலாம்:
- டேபிள் வரையறையை சேமி, அதாவது மெட்டாடேட்டா - அட்டவணையை உருவாக்கவும்.
- கிளிக்ஹவுஸ் கிளையண்டைப் பயன்படுத்தி டம்ப் செய்யுங்கள் - தேர்வு * மேஜையில் இருந்து தாக்கல் செய்ய. இயல்பாக நீங்கள் TabSeparated வடிவத்தில் ஒரு கோப்பைப் பெறுவீர்கள். நீங்கள் இன்னும் திறமையாக இருக்க விரும்பினால், நீங்கள் அதை நேட்டிவ் வடிவத்தில் செய்யலாம்.
தரவு அளவு பெரியதாக இருந்தால், காப்புப்பிரதி அதிக நேரத்தையும் அதிக இடத்தையும் எடுக்கும். இது தருக்க காப்புப்பிரதி என்று அழைக்கப்படுகிறது; இது ClickHouse தரவு வடிவத்துடன் இணைக்கப்படவில்லை. அது இருந்தால், கடைசி முயற்சியாக நீங்கள் காப்புப்பிரதியை எடுத்து மீட்டெடுக்க MySQL இல் பதிவேற்றலாம்.
மேலும் மேம்பட்ட நிகழ்வுகளுக்கு, உள்ளூர் கோப்பு முறைமையில் பகிர்வுகளின் ஸ்னாப்ஷாட்டை உருவாக்கும் திறனை ClickHouse கொண்டுள்ளது. இந்த அம்சம் கோரிக்கையாகக் கிடைக்கிறது அட்டவணை முடக்கம் பகிர்வை மாற்றவும். அல்லது வெறுமனே அட்டவணை முடக்கத்தை மாற்றவும் - இது முழு அட்டவணையின் ஸ்னாப்ஷாட்.
ஸ்னாப்ஷாட் ஒரு டேபிளில் ஒரு டேபிளுக்கு தொடர்ச்சியாக உருவாக்கப்படும், அதாவது முழு கிளஸ்டரின் சீரான ஸ்னாப்ஷாட்டை இந்த வழியில் உருவாக்குவது சாத்தியமில்லை. ஆனால் பெரும்பாலான பணிகளுக்கு அத்தகைய தேவை இல்லை, மேலும் ஒவ்வொரு ஷார்டிலும் ஒரு கோரிக்கையை இயக்கி, நிலையான ஸ்னாப்ஷாட்டைப் பெறுவது போதுமானது. இது ஹார்ட்லிங்க் வடிவத்தில் உருவாக்கப்பட்டது, எனவே கூடுதல் இடத்தை எடுத்துக் கொள்ளாது. அடுத்து, இந்த ஸ்னாப்ஷாட்டை காப்புப் பிரதி சேவையகம் அல்லது காப்புப்பிரதிகளுக்கு நீங்கள் பயன்படுத்தும் சேமிப்பகத்திற்கு நகலெடுக்கவும்.
அத்தகைய காப்புப்பிரதியை மீட்டெடுப்பது மிகவும் எளிதானது. முதலில், ஏற்கனவே உள்ள அட்டவணை வரையறைகளைப் பயன்படுத்தி அட்டவணைகளை உருவாக்கவும். அடுத்து, பகிர்வுகளின் சேமித்த ஸ்னாப்ஷாட்களை இந்த அட்டவணைகளுக்கான கோப்பகத்திலிருந்து பிரிக்கப்பட்டதாக நகலெடுத்து வினவலை இயக்கவும் பகிர்வை இணைக்கவும். இந்த தீர்வு மிகவும் தீவிரமான தரவுகளுக்கு மிகவும் பொருத்தமானது.
ஒவ்வொரு சர்வரிலும் நூற்றுக்கணக்கான டெராபைட்கள் மற்றும் நூற்றுக்கணக்கான சர்வர்கள் இருக்கும் சந்தர்ப்பங்களில் - சில நேரங்களில் உங்களுக்கு இன்னும் குளிர்ச்சியான ஒன்று தேவைப்படும். Yandex.Metrica இலிருந்து எனது சக ஊழியர்களிடமிருந்து நான் எடுத்த ஒரு தீர்வு இங்கே உள்ளது. நான் அதை அனைவருக்கும் பரிந்துரைக்க மாட்டேன் - அதைப் படித்து அது பொருத்தமானதா இல்லையா என்பதை நீங்களே முடிவு செய்யுங்கள்.
முதலில் நீங்கள் பெரிய வட்டு அலமாரிகளுடன் பல சேவையகங்களை உருவாக்க வேண்டும். அடுத்து, இந்த சேவையகங்களில், பல கிளிக்ஹவுஸ் சேவையகங்களை உயர்த்தி, அதே துண்டுகளுக்கு மற்றொரு பிரதியாக செயல்படும் வகையில் அவற்றை உள்ளமைக்கவும். இந்த சேவையகங்களில் கோப்பு முறைமை அல்லது சில கருவிகளைப் பயன்படுத்தவும், இது ஸ்னாப்ஷாட்களை உருவாக்க உங்களை அனுமதிக்கிறது. இங்கே இரண்டு விருப்பங்கள் உள்ளன. முதல் விருப்பம் LVM ஸ்னாப்ஷாட்கள், இரண்டாவது விருப்பம் லினக்ஸில் ZFS ஆகும்.
அதன் பிறகு, ஒவ்வொரு நாளும் நீங்கள் ஒரு ஸ்னாப்ஷாட்டை உருவாக்க வேண்டும், அது பொய் மற்றும் சிறிது இடத்தை எடுக்கும். இயற்கையாகவே, தரவு மாறினால், காலப்போக்கில் இடத்தின் அளவு அதிகரிக்கும். இந்த ஸ்னாப்ஷாட் எந்த நேரத்திலும் எடுக்கப்படலாம் மற்றும் தரவு மீட்டமைக்கப்படலாம், இது போன்ற ஒரு விசித்திரமான தீர்வு. கூடுதலாக, இந்த பிரதிகளை கட்டமைப்பில் நாம் கட்டுப்படுத்த வேண்டும், இதனால் அவர்கள் தலைவர்களாக மாற முயற்சிக்க மாட்டார்கள்.
தண்டுகளில் உள்ள பிரதிகளின் கட்டுப்படுத்தப்பட்ட பின்னடைவை ஒழுங்கமைக்க முடியுமா?
இந்த ஆண்டு நீங்கள் ClickHouse இல் தண்டுகளை உருவாக்க திட்டமிட்டுள்ளீர்கள். அவற்றில் கட்டுப்படுத்தப்பட்ட பின்னடைவு பிரதிகளை ஒழுங்கமைக்க முடியுமா? மாற்றங்கள் மற்றும் பிற மாற்றங்களுடன் எதிர்மறையான சூழ்நிலைகளில் இருந்து நம்மைப் பாதுகாத்துக் கொள்ள இதைப் பயன்படுத்த விரும்புகிறோம்.
மாற்றங்களுக்கு சில வகையான ரோல் பேக் செய்ய முடியுமா? எடுத்துக்காட்டாக, ஏற்கனவே உள்ள ஷாஃப்ட்டில், இந்த நிமிடம் வரை நீங்கள் மாற்றங்களைப் பயன்படுத்துகிறீர்கள் என்று எடுத்துச் சொல்லுங்கள், மேலும் இந்த தருணத்திலிருந்து மாற்றங்களைப் பயன்படுத்துவதை நிறுத்துகிறீர்களா?
எங்கள் கிளஸ்டருக்கு ஒரு கட்டளை வந்து அதை உடைத்தால், ஒரு மணிநேர தாமதத்துடன் ஒரு நிபந்தனை பிரதி உள்ளது, அதை இந்த நேரத்தில் பயன்படுத்துவோம் என்று சொல்லலாம், ஆனால் கடைசி பத்து நிமிடங்களுக்கு அதில் மாற்றங்களைச் செய்ய மாட்டோம்?
முதலில், பிரதிகளின் கட்டுப்படுத்தப்பட்ட பின்னடைவு பற்றி. பயனர்களிடமிருந்து இது போன்ற கோரிக்கை இருந்தது, மேலும் கிதுப்பில் ஒரு சிக்கலை உருவாக்கினோம்: "யாருக்காவது இது தேவைப்பட்டால், அதை விரும்புங்கள், இதயத்தை வைக்கவும்." யாரும் வழங்கவில்லை, சிக்கல் மூடப்பட்டது. இருப்பினும், ClickHouse அமைப்பதன் மூலம் இந்த வாய்ப்பை நீங்கள் ஏற்கனவே பெறலாம். உண்மை, பதிப்பு 20.3 இலிருந்து மட்டுமே தொடங்குகிறது.
கிளிக்ஹவுஸ் தொடர்ந்து பின்னணியில் தரவுகளை ஒன்றிணைக்கிறது. ஒரு இணைப்பு முடிந்ததும், ஒரு குறிப்பிட்ட தரவுத் துண்டுகள் பெரிய துண்டுடன் மாற்றப்படும். அதே நேரத்தில், முன்பு இருந்த தரவுத் துண்டுகள் சிறிது நேரம் வட்டில் தொடர்ந்து இருக்கும்.
முதலில், தடுக்காத செயல்பாட்டை வழங்குவதற்காக, அவற்றைப் பயன்படுத்தும் தேர்ந்தெடுக்கப்பட்ட வினவல்கள் இருக்கும் வரை அவை தொடர்ந்து சேமிக்கப்படும். தேர்ந்தெடுக்கப்பட்ட வினவல்கள் பழைய பகுதிகளிலிருந்து எளிதாகப் படிக்கப்படுகின்றன.
இரண்டாவதாக, நேர வரம்பும் உள்ளது - பழைய தரவுத் துண்டுகள் வட்டில் எட்டு நிமிடங்கள் கிடக்கின்றன. இந்த எட்டு நிமிடங்களை தனிப்பயனாக்கலாம் மற்றும் ஒரு நாளாக கூட மாற்றலாம். இது வட்டு இடத்தை செலவழிக்கும்: தரவு ஓட்டத்தைப் பொறுத்து, கடைசி நாளில் தரவு இரட்டிப்பாவது மட்டுமல்லாமல், அது ஐந்து மடங்கு அதிகமாகவும் மாறும். ஆனால் கடுமையான சிக்கல் இருந்தால், நீங்கள் கிளிக்ஹவுஸ் சேவையகத்தை நிறுத்தி எல்லாவற்றையும் வரிசைப்படுத்தலாம்.
இப்போது இது எவ்வாறு மாற்றங்களிலிருந்து பாதுகாக்கிறது என்ற கேள்வி எழுகிறது. இங்கே ஆழமாகப் பார்ப்பது மதிப்புக்குரியது, ஏனென்றால் கிளிக்ஹவுஸின் பழைய பதிப்புகளில், மாற்றானது நேரடியாக துண்டுகளை மாற்றும் வகையில் வேலை செய்தது. சில கோப்புகளுடன் தரவுத் துண்டு உள்ளது, எடுத்துக்காட்டாக, நாங்கள் செய்கிறோம், துளி நெடுவரிசையை மாற்றவும். பின்னர் இந்த நெடுவரிசை அனைத்து துண்டுகளிலிருந்தும் உடல் ரீதியாக அகற்றப்படும்.
ஆனால் பதிப்பு 20.3 இல் தொடங்கி, மாற்று பொறிமுறை முற்றிலும் மாற்றப்பட்டுள்ளது, இப்போது தரவுத் துண்டுகள் எப்போதும் மாறாதவை. அவை மாறவே இல்லை - மாற்றியமைப்பவர்கள் இப்போது ஒன்றிணைவது போலவே வேலை செய்கின்றன. அந்த இடத்தில் ஒரு பகுதியை மாற்றுவதற்கு பதிலாக, புதிய ஒன்றை உருவாக்குகிறோம். புதிய துண்டில், மாறாத கோப்புகள் கடின இணைப்புகளாக மாறும், மேலும் ஒரு நெடுவரிசையை நீக்கினால், அது புதிய துண்டில் காணாமல் போகும். எட்டு நிமிடங்களுக்குப் பிறகு பழைய துண்டு இயல்பாக நீக்கப்படும், மேலும் இங்கே நீங்கள் மேலே குறிப்பிட்டுள்ள அமைப்புகளை மாற்றலாம்.
பிறழ்வுகள் போன்ற மாற்றங்களுக்கும் இது பொருந்தும். நீங்கள் செய்யும் போது நீக்குவதை மாற்றவும் அல்லது புதுப்பிப்பை மாற்றவும், இது துண்டை மாற்றாது, ஆனால் புதிய ஒன்றை உருவாக்குகிறது. பின்னர் பழையதை நீக்குகிறது.
அட்டவணை அமைப்பு மாறியிருந்தால் என்ன செய்வது?
பழைய திட்டத்தில் செய்யப்பட்ட காப்புப்பிரதியை எவ்வாறு மீட்டெடுப்பது? இரண்டாவது கேள்வி ஸ்னாப்ஷாட்கள் மற்றும் கோப்பு முறைமை கருவிகளைப் பற்றியது. லினக்ஸ் எல்விஎம்மில் ZFSக்கு பதிலாக Btrfs நல்லதா?
நீங்கள் செய்தால் பகிர்வை இணைக்கவும் வேறு கட்டமைப்பைக் கொண்ட பகிர்வுகள், பின்னர் கிளிக்ஹவுஸ் இது சாத்தியமில்லை என்று உங்களுக்குத் தெரிவிக்கும். இதுதான் தீர்வு. முதலாவது, MergeTree வகையின் ஒரு தற்காலிக அட்டவணையை பழைய கட்டமைப்புடன் உருவாக்கி, அட்டாட்சைப் பயன்படுத்தி தரவை அங்கே இணைத்து, மாற்று வினவலை உருவாக்குவது. நீங்கள் இந்தத் தரவை நகலெடுக்கலாம் அல்லது மாற்றலாம் மற்றும் மீண்டும் இணைக்கலாம் அல்லது கோரிக்கையைப் பயன்படுத்தலாம் அட்டவணை நகர்த்த பகிர்வை மாற்றவும்.
இப்போது இரண்டாவது கேள்வி Btrfs ஐப் பயன்படுத்த முடியுமா என்பதுதான். தொடங்குவதற்கு, உங்களிடம் எல்விஎம் இருந்தால், எல்விஎம் ஸ்னாப்ஷாட்கள் போதும், கோப்பு முறைமை ext4 ஆக இருக்கலாம், அது ஒரு பொருட்டல்ல. Btrts உடன், எல்லாமே அதைப் பயன்படுத்துவதில் உங்கள் அனுபவத்தைப் பொறுத்தது. இது ஒரு முதிர்ந்த கோப்பு முறைமை, ஆனால் ஒரு குறிப்பிட்ட சூழ்நிலையில் நடைமுறையில் அனைத்தும் எவ்வாறு செயல்படும் என்பதில் இன்னும் சில சந்தேகங்கள் உள்ளன. நீங்கள் தயாரிப்பில் Btrfs இல்லாவிடில் இதைப் பயன்படுத்த நான் பரிந்துரைக்க மாட்டேன்.
தரவு மறுபரிசீலனையில் தற்போதைய சிறந்த நடைமுறைகள் யாவை?
மறுபகிர்வு பிரச்சினை சிக்கலானது மற்றும் பன்முகத்தன்மை கொண்டது. இங்கே பல சாத்தியமான பதில்கள் உள்ளன. நீங்கள் ஒரு பக்கத்திலிருந்து சென்று இதைச் சொல்லலாம் - ClickHouse இல் உள்ளமைக்கப்பட்ட மறுபகிர்வு அம்சம் இல்லை. ஆனால் இந்த பதில் யாருக்கும் பொருந்தாது என்று நான் பயப்படுகிறேன். எனவே, நீங்கள் மறுபக்கத்திலிருந்து சென்று தரவை மறுபகிர்வு செய்ய கிளிக்ஹவுஸ் பல வழிகளைக் கொண்டுள்ளது என்று கூறலாம்.
கிளஸ்டரில் இடம் இல்லாமல் போனால் அல்லது அது சுமைகளைக் கையாள முடியாவிட்டால், நீங்கள் புதிய சேவையகங்களைச் சேர்க்கவும். ஆனால் இந்த சேவையகங்கள் முன்னிருப்பாக காலியாக உள்ளன, அவற்றில் தரவு இல்லை, சுமை இல்லை. நீங்கள் தரவை மறுசீரமைக்க வேண்டும், இதனால் புதிய, பெரிய கிளஸ்டர் முழுவதும் சமமாக பரவுகிறது.
கோரிக்கையைப் பயன்படுத்தி பகிர்வுகளின் ஒரு பகுதியை புதிய சேவையகங்களுக்கு நகலெடுப்பதே இதைச் செய்வதற்கான முதல் வழி அட்டவணையைப் பெறுதல் பகிர்வை மாற்றவும். எடுத்துக்காட்டாக, உங்களிடம் மாதவாரியாக பகிர்வுகள் இருந்தன, மேலும் 2017 இன் முதல் மாதத்தை எடுத்து புதிய சேவையகத்திற்கு நகலெடுத்து, மூன்றாவது மாதத்தை வேறு ஏதேனும் புதிய சேவையகத்திற்கு நகலெடுக்கவும். அது அதிகமாகவோ அல்லது குறைவாகவோ மாறும் வரை நீங்கள் இதைச் செய்யுங்கள்.
பதிவின் போது மாறாத பகிர்வுகளுக்கு மட்டுமே இடமாற்றம் செய்ய முடியும். புதிய பகிர்வுகளுக்கு, பதிவு முடக்கப்பட வேண்டும், ஏனெனில் அவற்றின் பரிமாற்றம் அணு அல்ல. இல்லையெனில், நீங்கள் தரவு நகல் அல்லது இடைவெளிகளுடன் முடிவடையும். இருப்பினும், இந்த முறை நடைமுறை மற்றும் மிகவும் திறம்பட செயல்படுகிறது. ஆயத்த சுருக்கப்பட்ட பகிர்வுகள் பிணையத்தில் அனுப்பப்படுகின்றன, அதாவது தரவு சுருக்கப்படவில்லை அல்லது மீண்டும் குறியாக்கம் செய்யப்படவில்லை.
இந்த முறை ஒரு குறைபாட்டைக் கொண்டுள்ளது, மேலும் இது ஷார்டிங் திட்டத்தைப் பொறுத்தது, இந்த ஷார்டிங் திட்டத்திற்கு நீங்கள் உறுதியளித்தீர்களா, உங்களிடம் என்ன ஷார்டிங் விசை உள்ளது. அளவீடுகளுக்கான உங்கள் எடுத்துக்காட்டில், ஷார்டிங் கீ என்பது பாதையின் ஹாஷ் ஆகும். நீங்கள் ஒரு விநியோகிக்கப்பட்ட அட்டவணையைத் தேர்ந்தெடுக்கும்போது, அது ஒரே நேரத்தில் கிளஸ்டரில் உள்ள அனைத்து துண்டுகளுக்கும் சென்று அங்கிருந்து தரவை எடுக்கிறது.
இதன் பொருள் என்னவென்றால், எந்தத் துண்டில் என்ன தரவு முடிந்தது என்பது உண்மையில் உங்களுக்கு முக்கியமில்லை. முக்கிய விஷயம் என்னவென்றால், ஒரு பாதையில் உள்ள தரவு ஒரு துண்டில் முடிவடைகிறது, ஆனால் எது முக்கியமல்ல. இந்த வழக்கில், ஆயத்த பகிர்வுகளை மாற்றுவது சரியானது, ஏனெனில் தேர்ந்தெடுக்கப்பட்ட வினவல்களுடன் நீங்கள் முழுமையான தரவையும் பெறுவீர்கள் - மறுபகிர்வு செய்வதற்கு முன் அல்லது அதற்குப் பிறகு, திட்டம் உண்மையில் ஒரு பொருட்டல்ல.
ஆனால் மிகவும் சிக்கலான வழக்குகள் உள்ளன. பயன்பாட்டு லாஜிக் மட்டத்தில் நீங்கள் ஒரு சிறப்பு பகிர்வு திட்டத்தை நம்பினால், இந்த கிளையன்ட் அத்தகைய மற்றும் அத்தகைய ஷார்டில் அமைந்துள்ளது, மேலும் கோரிக்கையை நேரடியாக அங்கு அனுப்பலாம், விநியோக அட்டவணைக்கு அல்ல. அல்லது நீங்கள் கிளிக்ஹவுஸின் மிகச் சமீபத்திய பதிப்பைப் பயன்படுத்துகிறீர்கள் மற்றும் அமைப்பை இயக்கியுள்ளீர்கள் பயன்படுத்தப்படாத துண்டுகளை தவிர்க்கவும். இந்த வழக்கில், தேர்ந்தெடுக்கப்பட்ட வினவலின் போது, பிரிவில் உள்ள வெளிப்பாடு பகுப்பாய்வு செய்யப்படும் மற்றும் ஷார்டிங் திட்டத்தின் படி எந்த துண்டுகள் பயன்படுத்தப்பட வேண்டும் என்று கணக்கிடப்படும். இந்த ஷார்டிங் திட்டத்தின்படி தரவு சரியாகப் பிரிக்கப்படுவதை இது வழங்குகிறது. நீங்கள் அவற்றை கைமுறையாக மறுசீரமைத்தால், கடிதப் பரிமாற்றம் மாறக்கூடும்.
எனவே இந்த முறை எண் ஒன்று. உங்கள் பதிலுக்காக நான் காத்திருக்கிறேன், முறை பொருத்தமானதா, அல்லது தொடரலாம்.
Vladimir Kolobaev, Avito இல் முன்னணி கணினி நிர்வாகி: அலெக்ஸி, வாசிப்பு உட்பட சுமைகளைப் பரப்ப வேண்டியிருக்கும் போது நீங்கள் குறிப்பிட்ட முறை சரியாக வேலை செய்யாது. நாம் மாதாந்திர பகிர்வை எடுக்கலாம் மற்றும் முந்தைய மாதத்தை மற்றொரு முனைக்கு எடுத்துச் செல்லலாம், ஆனால் இந்தத் தரவுக்கான கோரிக்கை வந்தால், அதை மட்டுமே ஏற்றுவோம். ஆனால் நாங்கள் முழு கிளஸ்டரையும் ஏற்ற விரும்புகிறோம், இல்லையெனில், சிறிது நேரம் முழு வாசிப்பு சுமையும் இரண்டு துண்டுகளால் செயலாக்கப்படும்.
அலெக்ஸி மிலோவிடோவ்: இங்கே பதில் விசித்திரமானது - ஆம், இது மோசமானது, ஆனால் அது வேலை செய்யக்கூடும். எப்படி என்பதை நான் சரியாக விளக்குகிறேன். உங்கள் தரவின் பின்னால் வரும் சுமை காட்சியைப் பார்ப்பது மதிப்பு. இது தரவைக் கண்காணிப்பதாக இருந்தால், பெரும்பாலான கோரிக்கைகள் புதிய தரவுகளுக்கானவை என்று நாம் நிச்சயமாகச் சொல்லலாம்.
நீங்கள் புதிய சேவையகங்களை நிறுவியுள்ளீர்கள், பழைய பகிர்வுகளை மாற்றியுள்ளீர்கள், ஆனால் புதிய தரவு எவ்வாறு பதிவு செய்யப்படுகிறது என்பதையும் மாற்றியுள்ளீர்கள். மேலும் புதிய தரவு கிளஸ்டர் முழுவதும் பரவும். எனவே, ஐந்து நிமிடங்களுக்குப் பிறகு, கடைசி ஐந்து நிமிடங்களுக்கான கோரிக்கைகள் கிளஸ்டரை சமமாக ஏற்றும்; ஒரு நாளுக்குப் பிறகு, XNUMX மணிநேரத்திற்கான கோரிக்கைகள் கிளஸ்டரை சமமாக ஏற்றும். முந்தைய மாதத்திற்கான கோரிக்கைகள், துரதிர்ஷ்டவசமாக, கிளஸ்டர் சேவையகங்களின் ஒரு பகுதிக்கு மட்டுமே செல்லும்.
ஆனால் பெரும்பாலும் பிப்ரவரி 2019க்கான கோரிக்கைகள் உங்களிடம் இருக்காது. பெரும்பாலும், கோரிக்கைகள் 2019 இல் சென்றால், அவை 2019 முழுவதும் இருக்கும் - ஒரு பெரிய காலத்திற்கு, சில சிறிய வரம்பிற்கு அல்ல. மேலும் இதுபோன்ற கோரிக்கைகள் கிளஸ்டரை சமமாக ஏற்றவும் முடியும். ஆனால் பொதுவாக, இது ஒரு தற்காலிக தீர்வு என்ற உங்கள் கருத்து முற்றிலும் சரியானது, இது தரவை முழுமையாக சமமாக பரப்பாது.
கேள்விக்கு பதிலளிக்க இன்னும் சில புள்ளிகள் என்னிடம் உள்ளன. அவற்றில் ஒன்று, முதலில் ஒரு ஷார்டிங் திட்டத்தை எவ்வாறு வடிவமைப்பது என்பது பற்றியது, இதனால் மீண்டும் ஷார்டிங் குறைந்த வலியை ஏற்படுத்தும். இது எப்போதும் சாத்தியமில்லை.
உதாரணமாக, உங்களிடம் கண்காணிப்பு தரவு உள்ளது. கண்காணிப்பு தரவு மூன்று காரணங்களுக்காக வளர்ந்து வருகிறது. முதலாவது வரலாற்றுத் தரவுகளின் குவிப்பு. இரண்டாவது போக்குவரத்து வளர்ச்சி. மூன்றாவது, கண்காணிப்புக்கு உட்பட்ட விஷயங்களின் எண்ணிக்கையில் அதிகரிப்பு. புதிய மைக்ரோ சர்வீஸ்கள் மற்றும் அளவீடுகள் சேமிக்கப்பட வேண்டும்.
இவற்றில், மிகப்பெரிய அதிகரிப்பு மூன்றாவது காரணத்துடன் தொடர்புடையது - கண்காணிப்பின் பயன்பாட்டின் அதிகரிப்பு. இந்த விஷயத்தில், சுமையின் தன்மையைப் பார்ப்பது மதிப்பு, முக்கிய தேர்ந்தெடுக்கப்பட்ட வினவல்கள் என்ன. அடிப்படைத் தேர்ந்தெடுக்கப்பட்ட வினவல்கள் பெரும்பாலும் அளவீடுகளின் சில துணைக்குழுக்களின் அடிப்படையில் இருக்கும்.
எடுத்துக்காட்டாக, சில சேவைகளால் சில சேவையகங்களில் CPU பயன்பாடு. இந்தத் தரவைப் பெறுவதற்கு ஒரு குறிப்பிட்ட விசைகளின் துணைக்குழு உள்ளது என்று மாறிவிடும். இந்தத் தரவிற்கான கோரிக்கை மிகவும் எளிமையானது மற்றும் பல்லாயிரக்கணக்கான மில்லி விநாடிகளில் முடிக்கப்படும். சேவைகள் மற்றும் டாஷ்போர்டுகளை கண்காணிக்க பயன்படுகிறது. இதை நான் சரியாகப் புரிந்துகொண்டேன் என்று நம்புகிறேன்.
விளாடிமிர் கோலோபேவ்: உண்மை என்னவென்றால், வரலாற்றுத் தரவுகளுக்கு நாங்கள் அடிக்கடி முறையிடுகிறோம், ஏனெனில் தற்போதைய சூழ்நிலையை வரலாற்று நிலைமையுடன் உண்மையான நேரத்தில் ஒப்பிடுகிறோம். அதிக அளவிலான தரவை விரைவாக அணுகுவது எங்களுக்கு முக்கியம், மேலும் கிளிக்ஹவுஸ் இதை சிறப்பாகச் செய்கிறது.
நீங்கள் சொல்வது முற்றிலும் சரி, எந்த கண்காணிப்பு அமைப்பையும் போலவே, பெரும்பாலான வாசிப்பு கோரிக்கைகளை நாங்கள் கடைசி நாளில் அனுபவிக்கிறோம். ஆனால் அதே நேரத்தில், வரலாற்று தரவுகளின் சுமை மிகவும் பெரியது. இது அடிப்படையில் ஒவ்வொரு முப்பது வினாடிக்கும் செல்லும் ஒரு எச்சரிக்கை அமைப்பிலிருந்து வந்து கிளிக்ஹவுஸிடம் கூறுகிறது: “கடந்த ஆறு வாரங்களுக்கான தரவை எனக்குக் கொடுங்கள். இப்போது அவர்களிடமிருந்து ஒருவித நகரும் சராசரியை உருவாக்குங்கள், தற்போதைய மதிப்பை வரலாற்று மதிப்புடன் ஒப்பிடுவோம்.
இதுபோன்ற மிக சமீபத்திய கோரிக்கைகளுக்கு எங்களிடம் மற்றொரு சிறிய அட்டவணை உள்ளது, அதில் இரண்டு நாட்கள் தரவை மட்டுமே சேமித்து வைக்கிறோம், மேலும் முக்கிய கோரிக்கைகள் அதில் பறக்கின்றன. நாங்கள் பெரிய வரலாற்று வினவல்களை மட்டுமே பெரிய துண்டாக்கப்பட்ட அட்டவணைக்கு அனுப்புகிறோம்.
அலெக்ஸி மிலோவிடோவ்: துரதிர்ஷ்டவசமாக, இது உங்கள் காட்சிக்கு சரியாகப் பொருந்தாது, ஆனால் பயன்படுத்தத் தேவையில்லாத, ஆனால் எனது நண்பர்களின் சேவையில் பயன்படுத்தப்படும் இரண்டு மோசமான மற்றும் சிக்கலான பகிர்வுத் திட்டங்களின் விளக்கத்தை நான் உங்களுக்குச் சொல்கிறேன்.
Yandex.Metrica நிகழ்வுகளுடன் ஒரு முக்கிய கிளஸ்டர் உள்ளது. நிகழ்வுகள் என்பது பக்கக் காட்சிகள், கிளிக்குகள் மற்றும் மாற்றங்கள். பெரும்பாலான கோரிக்கைகள் ஒரு குறிப்பிட்ட இணையதளத்திற்குச் செல்கின்றன. நீங்கள் Yandex.Metrica சேவையைத் திறக்கிறீர்கள், உங்களிடம் ஒரு வலைத்தளம் உள்ளது - avito.ru, அறிக்கைக்குச் செல்லவும், உங்கள் வலைத்தளத்திற்கு ஒரு கோரிக்கை செய்யப்படுகிறது.
ஆனால் மற்ற கோரிக்கைகள் உள்ளன - பகுப்பாய்வு மற்றும் உலகளாவிய - அவை உள் ஆய்வாளர்களால் செய்யப்படுகின்றன. ஒரு வேளை, உள் ஆய்வாளர்கள் Yandex சேவைகளுக்கு மட்டுமே கோரிக்கைகளை வைக்கிறார்கள் என்பதை நான் கவனிக்கிறேன். ஆயினும்கூட, யாண்டெக்ஸ் சேவைகள் கூட எல்லா தரவிலும் குறிப்பிடத்தக்க பங்கைக் கொண்டுள்ளன. இவை குறிப்பிட்ட கவுண்டர்களுக்கான கோரிக்கைகள் அல்ல, ஆனால் பரந்த வடிகட்டலுக்கான கோரிக்கைகள்.
ஒரு கவுண்டருக்கும், உலகளாவிய வினவல்களுக்கும் எல்லாம் திறமையாக செயல்படும் வகையில் தரவை எவ்வாறு ஒழுங்கமைப்பது? மற்றொரு சிரமம் என்னவென்றால், மெட்ரிக்ஸ் கிளஸ்டருக்கான கிளிக்ஹவுஸில் உள்ள கோரிக்கைகளின் எண்ணிக்கை வினாடிக்கு பல ஆயிரம் ஆகும். அதே நேரத்தில், ஒரு கிளிக்ஹவுஸ் சேவையகம் அற்பமான கோரிக்கைகளை கையாள முடியாது, எடுத்துக்காட்டாக, வினாடிக்கு பல ஆயிரம்.
கிளஸ்டர் அளவு அறுநூறு-ஏதாவது சர்வர்கள். இந்த க்ளஸ்டரின் மேல் ஒரு விநியோகிக்கப்பட்ட அட்டவணையை இழுத்து, பல ஆயிரம் கோரிக்கைகளை அனுப்பினால், அது ஒரு சேவையகத்திற்கு அனுப்புவதை விட மோசமாகிவிடும். மறுபுறம், தரவு சமமாக பரவி, நாங்கள் சென்று அனைத்து சேவையகங்களிடமிருந்தும் கோருகிறோம் என்ற விருப்பம் உடனடியாக நிராகரிக்கப்படுகிறது.
முற்றிலும் எதிர்மாறான ஒரு விருப்பம் உள்ளது. தளங்கள் முழுவதும் தரவைப் பகிர்ந்தால், ஒரு தளத்திற்கான கோரிக்கை ஒரு துண்டிற்குச் சென்றால் கற்பனை செய்து பாருங்கள். இப்போது கிளஸ்டரால் வினாடிக்கு பத்தாயிரம் கோரிக்கைகளைக் கையாள முடியும், ஆனால் ஒரு துண்டில் ஏதேனும் ஒரு கோரிக்கை மிக மெதுவாக வேலை செய்யும். செயல்திறனின் அடிப்படையில் இது இனி அளவிடப்படாது. குறிப்பாக இது avito.ru தளமாக இருந்தால். RuNet இல் அதிகம் பார்வையிடப்பட்ட தளங்களில் Avito ஒன்று என்று நான் கூறினால் இரகசியத்தை வெளிப்படுத்த மாட்டேன். அதை ஒரு துண்டில் செயலாக்குவது பைத்தியக்காரத்தனமாக இருக்கும்.
எனவே, ஷார்டிங் திட்டம் மிகவும் தந்திரமான முறையில் வடிவமைக்கப்பட்டுள்ளது. முழு கொத்தும் பல கிளஸ்டர்களாக பிரிக்கப்பட்டுள்ளது, அதை நாம் அடுக்குகள் என்று அழைக்கிறோம். ஒவ்வொரு கிளஸ்டரிலும் ஒரு டஜன் முதல் பல டஜன் துண்டுகள் உள்ளன. மொத்தம் முப்பத்தி ஒன்பது கொத்துகள் உள்ளன.
இவை அனைத்தும் எவ்வாறு அளவிடப்படுகின்றன? கொத்துகளின் எண்ணிக்கை மாறாது - சில ஆண்டுகளுக்கு முன்பு முப்பத்தொன்பதாக இருந்ததால், அது அப்படியே உள்ளது. ஆனால் அவை ஒவ்வொன்றிற்குள்ளும், தரவுகளைக் குவிக்கும் போது, படிப்படியாக துண்டுகளின் எண்ணிக்கையை அதிகரிக்கிறோம். ஒட்டுமொத்தமாக பகிர்தல் திட்டம் இது போன்றது: இந்த கிளஸ்டர்கள் வலைத்தளங்களாக பிரிக்கப்பட்டுள்ளன, மேலும் எந்த வலைத்தளம் எந்த கிளஸ்டரில் உள்ளது என்பதைப் புரிந்து கொள்ள, MySQL இல் ஒரு தனி மெட்டாபேஸ் பயன்படுத்தப்படுகிறது. ஒரு தளம் - ஒரு கிளஸ்டரில். அதன் உள்ளே, பார்வையாளர் ஐடிகளின் படி ஷார்டிங் ஏற்படுகிறது.
பதிவு செய்யும் போது, பார்வையாளர் ஐடியின் மீதமுள்ள பிரிவின் மூலம் அவற்றைப் பிரிப்போம். ஆனால் ஒரு புதிய துண்டைச் சேர்க்கும் போது, ஷார்டிங் திட்டம் மாறுகிறது; நாங்கள் தொடர்ந்து பிரிக்கிறோம், ஆனால் மீதமுள்ள பிரிவை மற்றொரு எண்ணால். இதன் பொருள் ஒரு பார்வையாளர் ஏற்கனவே பல சேவையகங்களில் இருக்கிறார், இதை நீங்கள் நம்ப முடியாது. தரவு சிறப்பாக சுருக்கப்பட்டிருப்பதை உறுதி செய்வதற்காக மட்டுமே இது செய்யப்படுகிறது. கோரிக்கைகளைச் செய்யும்போது, நாங்கள் விநியோகிக்கப்பட்ட அட்டவணைக்குச் செல்கிறோம், இது கிளஸ்டரைப் பார்த்து டஜன் கணக்கான சேவையகங்களை அணுகும். இது ஒரு முட்டாள்தனமான திட்டம்.
ஆனால் இந்த திட்டத்தை நாங்கள் கைவிட்டோம் என்று நான் கூறாவிட்டால் எனது கதை முழுமையடையாது. புதிய திட்டத்தில், கிளிக்ஹவுஸ்-காப்பியர் மூலம் அனைத்தையும் மாற்றி, எல்லா தரவையும் நகலெடுத்தோம்.
புதிய திட்டத்தில், அனைத்து தளங்களும் இரண்டு வகைகளாக பிரிக்கப்பட்டுள்ளன - பெரிய மற்றும் சிறிய. வாசல் எவ்வாறு தேர்ந்தெடுக்கப்பட்டது என்று எனக்குத் தெரியவில்லை, ஆனால் இதன் விளைவாக பெரிய தளங்கள் ஒரு கிளஸ்டரில் பதிவு செய்யப்பட்டுள்ளன, அங்கு ஒவ்வொன்றும் மூன்று பிரதிகளுடன் 120 துண்டுகள் உள்ளன - அதாவது 360 சேவையகங்கள். ஷார்டிங் திட்டம் எந்த கோரிக்கையும் ஒரே நேரத்தில் அனைத்து துண்டுகளுக்கும் செல்லும். Yandex.Metrica இல் avito.ru க்கான எந்த அறிக்கைப் பக்கத்தையும் நீங்கள் இப்போது திறந்தால், கோரிக்கை 120 சேவையகங்களுக்குச் செல்லும். RuNet இல் சில பெரிய தளங்கள் உள்ளன. மேலும் கோரிக்கைகள் வினாடிக்கு ஆயிரம் அல்ல, ஆனால் நூற்றுக்கும் குறைவானது. இவை அனைத்தும் விநியோகிக்கப்பட்ட அட்டவணையால் அமைதியாக மெல்லப்படுகின்றன, அவை ஒவ்வொன்றும் 120 சேவையகங்களுடன் செயலாக்கப்படுகின்றன.
இரண்டாவது கிளஸ்டர் சிறிய தளங்களுக்கானது. தள ஐடியின் அடிப்படையில் ஒரு பகிர்தல் திட்டம் இங்கே உள்ளது, மேலும் ஒவ்வொரு கோரிக்கையும் சரியாக ஒரு ஷார்டுக்கு செல்கிறது.
ClickHouse ஆனது clickhouse-copier பயன்பாட்டைக் கொண்டுள்ளது. அவளைப் பற்றி சொல்ல முடியுமா?
இந்த தீர்வு மிகவும் சிக்கலானது மற்றும் சற்றே குறைவான உற்பத்தி என்று நான் இப்போதே கூறுவேன். நன்மை என்னவென்றால், நீங்கள் குறிப்பிடும் முறைக்கு ஏற்ப இது தரவை முழுமையாக ஸ்மியர் செய்கிறது. ஆனால் பயன்பாட்டின் குறைபாடு என்னவென்றால், அது மறுபரிசீலனை செய்யப்படவில்லை. இது ஒரு கிளஸ்டர் திட்டத்திலிருந்து மற்றொரு கிளஸ்டர் திட்டத்திற்கு தரவை நகலெடுக்கிறது.
இதன் பொருள் இது வேலை செய்ய நீங்கள் இரண்டு கிளஸ்டர்களைக் கொண்டிருக்க வேண்டும். அவை ஒரே சேவையகங்களில் அமைந்திருக்கலாம், இருப்பினும், தரவு படிப்படியாக நகர்த்தப்படாது, ஆனால் நகலெடுக்கப்படும்.
உதாரணமாக, நான்கு சேவையகங்கள் இருந்தன, இப்போது எட்டு உள்ளன. நீங்கள் அனைத்து சேவையகங்களிலும், புதிய உள்ளூர் அட்டவணைகளிலும் புதிய விநியோகிக்கப்பட்ட அட்டவணையை உருவாக்கி, கிளிக்ஹவுஸ்-நகலியைத் தொடங்கவும், அதில் இருந்து படிக்க வேண்டிய வேலைத் திட்டத்தைக் குறிப்பிடுகிறது, புதிய பகிர்வு திட்டத்தை ஏற்று, தரவை அங்கு மாற்றவும். பழைய சர்வர்களில் இப்போது இருப்பதை விட ஒன்றரை மடங்கு அதிக இடம் தேவைப்படும், ஏனெனில் பழைய தரவு அவற்றில் இருக்க வேண்டும், மேலும் அதே பழைய தரவுகளில் பாதி அவற்றின் மேல் வரும். தரவு மறுபகிர்வு செய்யப்பட வேண்டும் மற்றும் இடம் உள்ளது என்று நீங்கள் முன்கூட்டியே நினைத்திருந்தால், இந்த முறை பொருத்தமானது.
கிளிக்ஹவுஸ்-காப்பியர் உள்ளே எப்படி வேலை செய்கிறது? ஒரு டேபிளின் ஒரு பகிர்வை ஒரு துண்டில் செயலாக்குவதற்கான பணிகளின் தொகுப்பாக இது அனைத்து வேலைகளையும் உடைக்கிறது. இந்தப் பணிகள் அனைத்தும் இணையாகச் செய்யப்படலாம், மேலும் கிளிக்ஹவுஸ்-நகலியை வெவ்வேறு கணினிகளில் பல நிகழ்வுகளில் இயக்கலாம், ஆனால் ஒரு பகிர்வுக்குச் செய்வது செருகுத் தேர்வைத் தவிர வேறில்லை. தரவு படிக்கப்பட்டு, சுருக்கப்பட்டு, மறுபகிர்வு செய்யப்பட்டு, மீண்டும் சுருக்கப்பட்டு, எங்காவது எழுதப்பட்டு, மீண்டும் வரிசைப்படுத்தப்படும். இது ஒரு கடினமான முடிவு.
நீங்கள் மறுபரிசீலனை என்று ஒரு பைலட் விஷயம் இருந்தது. அவளுடன் என்ன?
2017 இல், நீங்கள் மறுபரிசீலனை என்று ஒரு பைலட் விஷயத்தை வைத்திருந்தீர்கள். கிளிக்ஹவுஸில் ஒரு விருப்பம் கூட உள்ளது. நான் புரிந்து கொண்டபடி, அது எடுபடவில்லை. இது ஏன் நடந்தது என்று சொல்ல முடியுமா? இது மிகவும் பொருத்தமானதாகத் தெரிகிறது.
முழு பிரச்சனை என்னவென்றால், தரவை மறுபரிசீலனை செய்வது அவசியமானால், அணு ரீதியாக இதைச் செய்வதற்கு மிகவும் சிக்கலான ஒத்திசைவு தேவைப்படுகிறது. இந்த ஒத்திசைவு எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்கத் தொடங்கியபோது, அடிப்படை சிக்கல்கள் இருப்பது தெளிவாகத் தெரிந்தது. இந்த அடிப்படை சிக்கல்கள் கோட்பாட்டு ரீதியாக மட்டுமல்ல, உடனடியாக நடைமுறையில் தங்களை மிகவும் எளிமையாக விளக்கக்கூடிய வடிவத்தில் காட்டத் தொடங்கின - எதுவும் செயல்படவில்லை.
மெதுவான வட்டுகளுக்கு நகர்த்துவதற்கு முன் எல்லா தரவையும் ஒன்றாக இணைக்க முடியுமா?
ஒன்றிணைக்கும் சூழலில் ஸ்லோ டிஸ்க் விருப்பத்தை நகர்த்துவதன் மூலம் TTL பற்றிய கேள்வி. மெதுவான வட்டுகளுக்கு நகர்த்துவதற்கு முன், அனைத்து பகுதிகளையும் ஒன்றாக இணைக்க, கிரான் வழியாகத் தவிர வேறு வழி உள்ளதா?
கேள்விக்கான பதில் என்னவென்றால், எல்லா துண்டுகளையும் மாற்றுவதற்கு முன் எப்படியாவது தானாக ஒட்டுவது சாத்தியமாகும் - இல்லை. இது தேவையில்லை என்று நினைக்கிறேன். நீங்கள் அனைத்து பகுதிகளையும் ஒன்றாக இணைக்க வேண்டியதில்லை, ஆனால் அவை தானாகவே மெதுவான வட்டுகளுக்கு மாற்றப்படும் என்ற உண்மையை எண்ணுங்கள்.
பரிமாற்ற விதிகளுக்கு எங்களிடம் இரண்டு அளவுகோல்கள் உள்ளன. முதல் ஒரு அது நிரப்பப்பட்ட உள்ளது. தற்போதைய சேமிப்பக அடுக்கில் குறிப்பிட்ட சதவீதத்திற்கும் குறைவான இடவசதி இருந்தால், ஒரு பகுதியைத் தேர்ந்தெடுத்து, அதை மெதுவான சேமிப்பகத்திற்கு நகர்த்துவோம். அல்லது மாறாக, மெதுவாக அல்ல, ஆனால் அடுத்தது - நீங்கள் கட்டமைத்தபடி.
இரண்டாவது அளவுகோல் அளவு. இது பெரிய துண்டுகளை நகர்த்துவது பற்றியது. வேகமான வட்டில் உள்ள இலவச இடத்திற்கு ஏற்ப நீங்கள் வாசலை சரிசெய்யலாம், மேலும் தரவு தானாகவே மாற்றப்படும்.
இணக்கத்தன்மையை முன்கூட்டியே சரிபார்க்க வழி இல்லை என்றால், ClickHouse இன் புதிய பதிப்புகளுக்கு இடம்பெயர்வது எப்படி?
இந்த தலைப்பு அடிக்கடி விவாதிக்கப்படுகிறது வெவ்வேறு பதிப்புகளை கணக்கில் எடுத்துக்கொண்டு, இன்னும். பதிப்பு 19.11 இலிருந்து 19.16 க்கு மேம்படுத்துவது மற்றும் எடுத்துக்காட்டாக, 19.16 இலிருந்து 20.3 க்கு மேம்படுத்துவது எவ்வளவு பாதுகாப்பானது. சாண்ட்பாக்ஸில் உள்ள இணக்கத்தன்மையை முன்கூட்டியே சரிபார்க்க முடியாமல் புதிய பதிப்புகளுக்கு நகர்த்துவதற்கான சிறந்த வழி எது?
இங்கே பல "தங்க" விதிகள் உள்ளன. முதலில் - . இது பெரியது, ஆனால் பின்னோக்கி இணக்கமற்ற மாற்றங்கள் பற்றி தனித்தனி பத்திகள் உள்ளன. இந்த புள்ளிகளை சிவப்பு கொடியாக கருத வேண்டாம். இவை பொதுவாக நீங்கள் பயன்படுத்தாத சில விளிம்பு செயல்பாடுகளை உள்ளடக்கிய சிறிய இணக்கமின்மைகள்.
இரண்டாவதாக, சாண்ட்பாக்ஸில் பொருந்தக்கூடிய தன்மையை சரிபார்க்க வழி இல்லை என்றால், உற்பத்தியில் உடனடியாக புதுப்பிக்க விரும்பினால், இதை நீங்கள் செய்ய வேண்டியதில்லை என்பது பரிந்துரை. முதலில் ஒரு சாண்ட்பாக்ஸை உருவாக்கி சோதிக்கவும். சோதனை சூழல் இல்லை என்றால், உங்களிடம் மிகப் பெரிய நிறுவனம் இல்லை, அதாவது உங்கள் லேப்டாப்பில் சில தரவை நகலெடுத்து அதில் எல்லாம் சரியாக வேலை செய்கிறது என்பதை உறுதிப்படுத்திக் கொள்ளலாம். உங்கள் கணினியில் உள்ளூரில் பல பிரதிகளை கூட நீங்கள் உயர்த்தலாம். அல்லது அருகிலுள்ள எங்காவது ஒரு புதிய பதிப்பை எடுத்து, அங்கு சில தரவைப் பதிவேற்றலாம் - அதாவது, மேம்படுத்தப்பட்ட சோதனை சூழலை உருவாக்கவும்.
மற்றொரு விதி என்னவென்றால், தயாரிப்பில் உள்ள பிழைகள் மற்றும் அடுத்தடுத்த விரைவான திருத்தங்கள் காரணமாக பதிப்பு வெளியான ஒரு வாரத்திற்கு புதுப்பிக்கக்கூடாது. குழப்பமடையாமல் இருக்க கிளிக்ஹவுஸ் பதிப்புகளின் எண்ணிக்கையைக் கண்டுபிடிப்போம்.
பதிப்பு 20.3.4 உள்ளது. எண் 20 உற்பத்தி ஆண்டு குறிக்கிறது - 2020. உள்ளே என்ன பார்வையில் இருந்து, இது ஒரு பொருட்டல்ல, எனவே நாம் அதை கவனம் செலுத்த மாட்டோம். அடுத்து - 20.3. நாம் இரண்டாவது எண்ணை அதிகரிக்கிறோம் - இந்த வழக்கில் 3 - ஒவ்வொரு முறையும் சில புதிய செயல்பாடுகளுடன் வெளியீட்டை வெளியிடுகிறோம். கிளிக்ஹவுஸில் சில அம்சங்களைச் சேர்க்க விரும்பினால், இந்த எண்ணிக்கையை அதிகரிக்க வேண்டும். அதாவது, பதிப்பு 20.4 இல் ClickHouse இன்னும் சிறப்பாக செயல்படும். மூன்றாவது இலக்கம் 20.3.4. இங்கே 4 என்பது பேட்ச் வெளியீடுகளின் எண்ணிக்கையாகும், அதில் நாங்கள் புதிய அம்சங்களைச் சேர்க்கவில்லை, ஆனால் சில பிழைகளை சரிசெய்துள்ளோம். மற்றும் 4 என்றால் நான்கு முறை செய்தோம்.
இது பயங்கரமான ஒன்று என்று நினைக்க வேண்டாம். வழக்கமாக பயனர் சமீபத்திய பதிப்பை நிறுவ முடியும் மற்றும் இது வருடத்திற்கு இயக்க நேரத்துடன் எந்த பிரச்சனையும் இல்லாமல் வேலை செய்யும். ஆனால் பிட்மேப்களை செயலாக்குவதற்கான சில செயல்பாட்டில், எங்கள் சீன தோழர்களால் சேர்க்கப்பட்டது, தவறான வாதங்களை அனுப்பும்போது சேவையகம் செயலிழக்கிறது. இதை சரி செய்ய வேண்டிய பொறுப்பு நமக்கு உள்ளது. நாங்கள் புதிய பேட்ச் பதிப்பை வெளியிடுவோம், மேலும் கிளிக்ஹவுஸ் மேலும் நிலையானதாக மாறும்.
நீங்கள் ClickHouse தயாரிப்பில் இயங்கினால், மேலும் ClickHouse இன் புதிய பதிப்பு கூடுதல் அம்சங்களுடன் வெளிவருகிறது - எடுத்துக்காட்டாக, 20.4.1 தான் முதன்மையானது, முதல் நாளிலேயே அதைத் தயாரிக்க அவசரப்பட வேண்டாம். அது ஏன் தேவைப்படுகிறது? நீங்கள் ஏற்கனவே ClickHouse ஐப் பயன்படுத்தவில்லை என்றால், நீங்கள் அதை நிறுவலாம், பெரும்பாலும் எல்லாம் சரியாகிவிடும். ஆனால் ClickHouse ஏற்கனவே சீராக இயங்கினால், நாம் என்ன பிரச்சனைகளை சரிசெய்கிறோம் என்பதைப் பார்க்க, பேட்ச்கள் மற்றும் புதுப்பிப்புகளில் ஒரு கண் வைத்திருங்கள்.
கிரில் ஷ்வகோவ்: சோதனை சூழல்களைப் பற்றி கொஞ்சம் சேர்க்க விரும்புகிறேன். எல்லோரும் சோதனைச் சூழல்களுக்கு மிகவும் பயப்படுகிறார்கள், சில காரணங்களால் உங்களிடம் மிகப் பெரிய ClickHouse கிளஸ்டர் இருந்தால், சோதனைச் சூழல் குறைவாகவோ அல்லது குறைந்தது பத்து மடங்கு சிறியதாகவோ இருக்க வேண்டும் என்று அவர்கள் நம்புகிறார்கள். அப்படியெல்லாம் இல்லை.
எனது சொந்த உதாரணத்திலிருந்து நான் உங்களுக்கு சொல்ல முடியும். என்னிடம் ஒரு திட்டம் உள்ளது, கிளிக்ஹவுஸ் உள்ளது. எங்கள் சோதனை சூழல் அவருக்கு மட்டுமே - இது ஹெட்ஸ்னரில் இருபது யூரோக்களுக்கு ஒரு சிறிய மெய்நிகர் இயந்திரம், அங்கு முற்றிலும் அனைத்தும் பயன்படுத்தப்படுகின்றன. இதைச் செய்ய, அன்சிபில் முழு ஆட்டோமேஷன் உள்ளது, எனவே, கொள்கையளவில், எங்கு செல்ல வேண்டும் என்பதில் எந்த வித்தியாசமும் இல்லை - வன்பொருள் சேவையகங்களுக்கு அல்லது மெய்நிகர் இயந்திரங்களில் வரிசைப்படுத்துங்கள்.
என்ன செய்ய முடியும்? உங்கள் சொந்த வீட்டில் ஒரு சிறிய கிளஸ்டரை எவ்வாறு வரிசைப்படுத்துவது என்பது குறித்த கிளிக்ஹவுஸ் ஆவணத்தில் ஒரு உதாரணத்தை வழங்குவது நல்லது - டோக்கரில், எல்எக்ஸ்சியில், ஒரு அன்சிபிள் பிளேபுக்கை உருவாக்கலாம், ஏனெனில் வெவ்வேறு நபர்கள் வெவ்வேறு வரிசைப்படுத்தல்களைக் கொண்டுள்ளனர். இது நிறைய எளிமையாக்கும். ஐந்து நிமிடங்களில் ஒரு கிளஸ்டரை எடுத்து வரிசைப்படுத்தினால், எதையாவது கண்டுபிடிக்க முயற்சிப்பது மிகவும் எளிதானது. இது மிகவும் வசதியானது, ஏனென்றால் நீங்கள் சோதிக்காத ஒரு தயாரிப்பு பதிப்பில் உருட்டுவது எங்கும் செல்ல முடியாத பாதை. சில நேரங்களில் அது வேலை செய்கிறது மற்றும் சில நேரங்களில் அது இல்லை. எனவே, வெற்றியை எதிர்பார்ப்பது மோசமானது.
மாக்சிம் கோட்யகோவ், மூத்த பின்தள பொறியாளர் Avito: பெரிய நிறுவனங்கள் எதிர்கொள்ளும் தொடர்ச்சியான சிக்கல்களில் இருந்து சோதனை சூழல்களைப் பற்றி சிறிது சேர்க்கிறேன். எங்களிடம் ஒரு முழுமையான கிளிக்ஹவுஸ் ஏற்றுக்கொள்ளும் கிளஸ்டர் உள்ளது; தரவுத் திட்டங்கள் மற்றும் அமைப்புகளின் அடிப்படையில், இது தயாரிப்பில் உள்ளவற்றின் சரியான நகலாகும். இந்த கிளஸ்டர், குறைந்த பட்ச ஆதாரங்களைக் கொண்ட மிகவும் தீர்வறிக்கை கொள்கலன்களில் பயன்படுத்தப்படுகிறது. உற்பத்தித் தரவின் ஒரு குறிப்பிட்ட சதவீதத்தை நாங்கள் அங்கு எழுதுகிறோம், அதிர்ஷ்டவசமாக காஃப்காவில் ஸ்ட்ரீமைப் பிரதிபலிக்க முடியும். அங்குள்ள அனைத்தும் ஒத்திசைக்கப்பட்டு அளவிடப்படுகின்றன - திறன் மற்றும் ஓட்டம் ஆகிய இரண்டிலும், கோட்பாட்டில், மற்ற அனைத்தும் சமமாக இருப்பதால், அளவீடுகளின் அடிப்படையில் உற்பத்தியைப் போலவே செயல்பட வேண்டும். வெடிக்கக்கூடிய அனைத்தும் முதலில் இந்த ஸ்டாண்டில் உருட்டப்பட்டு, தயாராகும் வரை பல நாட்களுக்கு அங்கேயே விடப்படும். ஆனால் இயற்கையாகவே, இந்த தீர்வு விலை உயர்ந்தது, கடினமானது மற்றும் பூஜ்ஜியமற்ற ஆதரவு செலவுகளைக் கொண்டுள்ளது.
அலெக்ஸி மிலோவிடோவ்: Yandex.Metrica இன் எங்கள் நண்பர்களின் சோதனை சூழல் எப்படி இருக்கிறது என்பதை நான் உங்களுக்கு சொல்கிறேன். ஒரு கிளஸ்டரில் 600-ஒற்றைப்படை சேவையகங்கள் இருந்தன, மற்றொன்று 360, மற்றும் மூன்றாவது மற்றும் பல கிளஸ்டர்கள் உள்ளன. அவற்றில் ஒன்றுக்கான சோதனை சூழல், ஒவ்வொன்றிலும் இரண்டு பிரதிகள் கொண்ட இரண்டு துண்டுகள் மட்டுமே. ஏன் இரண்டு துண்டுகள்? அதனால் நீங்கள் தனியாக இல்லை. மேலும் பிரதிகளும் இருக்க வேண்டும். நீங்கள் வாங்கக்கூடிய ஒரு குறிப்பிட்ட குறைந்தபட்ச தொகை.
இந்தச் சோதனைச் சூழல் உங்கள் வினவல்கள் செயல்படுகிறதா மற்றும் ஏதேனும் பெரிய அளவில் உடைந்ததா எனச் சரிபார்க்க உங்களை அனுமதிக்கிறது. ஆனால் பெரும்பாலும் பிரச்சினைகள் முற்றிலும் வேறுபட்ட இயல்புடன் எழுகின்றன, எல்லாம் வேலை செய்யும் போது, ஆனால் சுமைகளில் சில சிறிய மாற்றங்கள் உள்ளன.
ஒரு உதாரணம் சொல்கிறேன். ClickHouse இன் புதிய பதிப்பை நிறுவ முடிவு செய்தோம். இது ஒரு சோதனை சூழலில் வெளியிடப்பட்டது, தானியங்கு சோதனைகள் Yandex.Metrica இல் முடிக்கப்பட்டுள்ளன, இது பழைய பதிப்பு மற்றும் புதியது, முழு பைப்லைனையும் இயக்கும் தரவை ஒப்பிடுகிறது. நிச்சயமாக, எங்கள் CI இன் பச்சை சோதனைகள். இல்லையெனில், இந்த பதிப்பை நாங்கள் முன்மொழிந்திருக்க மாட்டோம்.
எல்லாம் நன்றாக இருக்கிறது. உற்பத்தியில் இறங்கத் தொடங்குகிறோம். வரைபடங்களின் சுமை பல மடங்கு அதிகரித்துள்ளது என்ற செய்தியை நான் பெறுகிறேன். நாங்கள் பதிப்பை திரும்பப் பெறுகிறோம். நான் வரைபடத்தைப் பார்த்துப் பார்க்கிறேன்: வெளியீட்டின் போது சுமை உண்மையில் பல மடங்கு அதிகரித்தது, மேலும் அவை உருட்டும்போது மீண்டும் குறைந்தது. பின்னர் நாங்கள் பதிப்பை திரும்பப் பெறத் தொடங்கினோம். மேலும் சுமை அதே வழியில் அதிகரித்து மீண்டும் அதே வழியில் விழுந்தது. எனவே முடிவு இதுதான்: தளவமைப்பு காரணமாக சுமை அதிகரித்துள்ளது, ஆச்சரியப்படுவதற்கில்லை.
புதிய பதிப்பை நிறுவ சக ஊழியர்களை சமாதானப்படுத்துவது கடினம். நான் சொல்கிறேன்: “பரவாயில்லை, உருட்டவும். உங்கள் விரல்களை குறுக்காக வைத்திருங்கள், எல்லாம் வேலை செய்யும். இப்போது வரைபடங்களில் சுமை அதிகரித்துள்ளது, ஆனால் எல்லாம் நன்றாக இருக்கிறது. அங்கேயே இரு." பொதுவாக, நாங்கள் இதைச் செய்தோம், அவ்வளவுதான் - பதிப்பு உற்பத்திக்காக வெளியிடப்பட்டது. ஆனால் கிட்டத்தட்ட ஒவ்வொரு அமைப்பிலும் இதே போன்ற சிக்கல்கள் எழுகின்றன.
கில் வினவல் வினவல்களைக் கொல்ல வேண்டும், ஆனால் அது இல்லை. ஏன்?
ஒரு பயனர், ஒருவித ஆய்வாளர், என்னிடம் வந்து, எனது கிளிக்ஹவுஸ் கிளஸ்டரை வைத்து ஒரு கோரிக்கையை உருவாக்கினார். கோரிக்கை எந்தப் பிரதி அல்லது ஷார்டுக்குச் சென்றது என்பதைப் பொறுத்து, சில முனை அல்லது முழு கிளஸ்டரும். இந்த சர்வரில் உள்ள அனைத்து CPU ஆதாரங்களும் ஒரு அலமாரியில் இருப்பதை நான் காண்கிறேன், எல்லாம் சிவப்பு நிறத்தில் உள்ளது. அதே நேரத்தில், கிளிக்ஹவுஸ் கோரிக்கைகளுக்கு பதிலளிக்கிறது. நான் எழுதுகிறேன்: "தயவுசெய்து எனக்குக் காட்டுங்கள், செயல்முறை பட்டியல், என்ன கோரிக்கை இந்த பைத்தியக்காரத்தனத்தை உருவாக்கியது."
நான் இந்த கோரிக்கையை கண்டுபிடித்து அதை கொல்ல எழுதுகிறேன். மேலும் எதுவும் நடக்கவில்லை என்பதை நான் காண்கிறேன். எனது சேவையகம் ஒரு அலமாரியில் உள்ளது, கிளிக்ஹவுஸ் எனக்கு சில கட்டளைகளை வழங்குகிறது, சேவையகம் உயிருடன் இருப்பதைக் காட்டுகிறது, எல்லாம் நன்றாக இருக்கிறது. ஆனால் நான் அனைத்து பயனர் கோரிக்கைகளிலும் சிதைவைக் கொண்டுள்ளேன், கிளிக்ஹவுஸில் உள்ள பதிவுகளில் சிதைவு தொடங்குகிறது, மேலும் எனது கொலை வினவல் வேலை செய்யாது. ஏன்? கொலை வினவல் வினவல்களைக் கொல்ல வேண்டும் என்று நினைத்தேன், ஆனால் அது இல்லை.
இப்போது ஒரு வித்தியாசமான பதில் இருக்கும். வினவல்களைக் கொல்லுவது வினவல்களைக் கொல்வதில்லை என்பதுதான் முக்கிய விஷயம்.
கில் வினவல் "இந்த வினவல் கொல்லப்பட வேண்டும்" என்று அழைக்கப்படும் சிறிய பெட்டியை சரிபார்க்கிறது. ஒவ்வொரு தொகுதியையும் செயலாக்கும்போது கோரிக்கையே இந்தக் கொடியைப் பார்க்கிறது. அது அமைக்கப்பட்டால், கோரிக்கை வேலை செய்வதை நிறுத்தும். கோரிக்கையை யாரும் கொல்லவில்லை என்று மாறிவிடும், அவரே எல்லாவற்றையும் சரிபார்த்து நிறுத்த வேண்டும். கோரிக்கையானது தரவுத் தொகுதிகளைச் செயலாக்கும் நிலையில் இருக்கும் எல்லா நிகழ்வுகளிலும் இது செயல்பட வேண்டும். இது அடுத்த தரவுத் தொகுதியைச் செயலாக்கும், கொடியைச் சரிபார்த்து, நிறுத்தும்.
சில செயல்பாட்டில் கோரிக்கை தடுக்கப்பட்ட சந்தர்ப்பங்களில் இது வேலை செய்யாது. உண்மை, பெரும்பாலும் இது உங்கள் வழக்கு அல்ல, ஏனென்றால், உங்களைப் பொறுத்தவரை, இது ஒரு டன் சேவையக வளங்களைப் பயன்படுத்துகிறது. வெளிப்புற வரிசையாக்கம் மற்றும் வேறு சில விவரங்களில் இது வேலை செய்யாது. ஆனால் பொதுவாக இது நடக்கக்கூடாது, இது ஒரு பிழை. கிளிக்ஹவுஸைப் புதுப்பிக்க நான் பரிந்துரைக்கக்கூடிய ஒரே விஷயம்.
வாசிப்பு சுமையின் கீழ் மறுமொழி நேரத்தை எவ்வாறு கணக்கிடுவது?
பல்வேறு கவுண்டர்கள் - பொருள் திரட்டுகளை சேமிக்கும் ஒரு அட்டவணை உள்ளது. வரிகளின் எண்ணிக்கை சுமார் நூறு மில்லியன். 1K உருப்படிகளுக்கு 1K RPS ஐ ஊற்றினால், கணிக்கக்கூடிய மறுமொழி நேரத்தை எண்ணுவது சாத்தியமா?
சூழலின் அடிப்படையில் ஆராயும்போது, நாங்கள் வாசிப்பு சுமை பற்றி பேசுகிறோம், ஏனென்றால் எழுதுவதில் எந்த பிரச்சனையும் இல்லை - ஆயிரம், ஒரு லட்சம், மற்றும் சில நேரங்களில் பல மில்லியன் வரிசைகள் செருகப்படலாம்.
வாசிப்பு கோரிக்கைகள் மிகவும் வேறுபட்டவை. தேர்ந்தெடுக்கப்பட்ட 1 இல், ClickHouse ஆனது ஒரு வினாடிக்கு சுமார் பல்லாயிரக்கணக்கான கோரிக்கைகளைச் செய்ய முடியும், எனவே ஒரு விசைக்கான கோரிக்கைகளுக்கு ஏற்கனவே சில ஆதாரங்கள் தேவைப்படும். சில முக்கிய மதிப்பு தரவுத்தளங்களை விட இதுபோன்ற புள்ளி வினவல்கள் மிகவும் கடினமாக இருக்கும், ஏனெனில் ஒவ்வொரு வாசிப்புக்கும் குறியீட்டின் மூலம் தரவுகளின் தொகுதியைப் படிக்க வேண்டியது அவசியம். எங்கள் குறியீடு ஒவ்வொரு பதிவையும் அல்ல, ஒவ்வொரு வரம்பையும் குறிக்கிறது. அதாவது, நீங்கள் முழு வரம்பையும் படிக்க வேண்டும் - இது முன்னிருப்பாக 8192 வரிகள். நீங்கள் சுருக்கப்பட்ட தரவுத் தொகுதியை 64 KB இலிருந்து 1 MB வரை குறைக்க வேண்டும். பொதுவாக, இத்தகைய இலக்கு வினவல்கள் முடிக்க சில மில்லி விநாடிகள் ஆகும். ஆனால் இது எளிமையான விருப்பம்.
சில எளிய எண்கணிதத்தை முயற்சிப்போம். சில மில்லி விநாடிகளை ஆயிரத்தால் பெருக்கினால், சில வினாடிகள் கிடைக்கும். ஒரு வினாடிக்கு ஆயிரம் கோரிக்கைகளைத் தொடர முடியாது என்பது போல் உள்ளது, ஆனால் உண்மையில் இது சாத்தியம், ஏனெனில் எங்களிடம் பல செயலி கோர்கள் உள்ளன. எனவே, கொள்கையளவில், ClickHouse சில நேரங்களில் 1000 RPS ஐ வைத்திருக்க முடியும், ஆனால் குறுகிய கோரிக்கைகளுக்கு, குறிப்பாக இலக்கு வைக்கப்பட்டவை.
எளிய கோரிக்கைகளின் எண்ணிக்கையால் நீங்கள் கிளிக்ஹவுஸ் கிளஸ்டரை அளவிட வேண்டும் என்றால், நான் எளிமையான விஷயத்தை பரிந்துரைக்கிறேன் - பிரதிகளின் எண்ணிக்கையை அதிகரிக்கவும் மற்றும் கோரிக்கைகளை சீரற்ற பிரதிக்கு அனுப்பவும். ஒரு பிரதி வினாடிக்கு ஐநூறு கோரிக்கைகளை வைத்திருந்தால், அது முற்றிலும் யதார்த்தமானது, மூன்று பிரதிகள் ஒன்றரை ஆயிரத்தைக் கையாளும்.
சில நேரங்களில், நிச்சயமாக, நீங்கள் அதிகபட்ச புள்ளி அளவீடுகளுக்கு ClickHouse ஐ கட்டமைக்கலாம். இதற்கு என்ன தேவை? முதலாவதாக, குறியீட்டின் கிரானுலாரிட்டியைக் குறைப்பது. இந்த வழக்கில், இது ஒன்றுக்கு குறைக்கப்படக்கூடாது, ஆனால் குறியீட்டில் உள்ளீடுகளின் எண்ணிக்கை பல மில்லியன் அல்லது ஒரு சேவையகத்திற்கு பத்து மில்லியன்களாக இருக்கும். அட்டவணையில் நூறு மில்லியன் வரிசைகள் இருந்தால், கிரானுலாரிட்டியை 64 ஆக அமைக்கலாம்.
சுருக்கப்பட்ட தொகுதியின் அளவை நீங்கள் குறைக்கலாம். இதற்கான அமைப்புகள் உள்ளன நிமிட சுருக்க தொகுதி அளவு, அதிகபட்ச சுருக்க தொகுதி அளவு. அவை குறைக்கப்படலாம், தரவை நிரப்பலாம், பின்னர் இலக்கு வினவல்கள் வேகமாக இருக்கும். ஆனாலும், ClickHouse ஒரு முக்கிய மதிப்பு தரவுத்தளமாக இல்லை. அதிக எண்ணிக்கையிலான சிறிய கோரிக்கைகள் ஒரு சுமை எதிர்ப்பு வடிவமாகும்.
கிரில் ஷ்வகோவ்: அங்கு சாதாரண கணக்குகள் இருந்தால் நான் ஆலோசனை வழங்குவேன். ClickHouse சில வகையான கவுண்டரைச் சேமிக்கும் போது இது மிகவும் நிலையான சூழ்நிலையாகும். எனக்கு ஒரு பயனர் இருக்கிறார், அவர் அத்தகைய நாட்டைச் சேர்ந்தவர், மேலும் சில மூன்றாம் துறையைச் சேர்ந்தவர், மேலும் நான் எதையாவது அதிகரிக்க வேண்டும். MySQL ஐ எடுத்து, ஒரு தனித்துவமான விசையை உருவாக்கவும் - MySQL இல் இது ஒரு நகல் விசை, மற்றும் PostgreSQL இல் இது ஒரு முரண்பாடானது - மேலும் ஒரு கூட்டல் குறியைச் சேர்க்கவும். இது மிகவும் சிறப்பாக செயல்படும்.
உங்களிடம் அதிக தரவு இல்லாதபோது, ClickHouse ஐப் பயன்படுத்துவதில் அதிகப் பயனில்லை. வழக்கமான தரவுத்தளங்கள் உள்ளன, அவை இதை நன்றாகச் செய்கின்றன.
கூடுதல் தரவு தற்காலிக சேமிப்பில் இருக்க கிளிக்ஹவுஸில் நான் என்ன மாற்றங்களைச் செய்யலாம்?
ஒரு சூழ்நிலையை கற்பனை செய்வோம் - சேவையகங்களில் 256 ஜிபி ரேம் உள்ளது, தினசரி வழக்கமான கிளிக்ஹவுஸ் 60-80 ஜிபி ஆகும், உச்சத்தில் - 130 வரை. எதை இயக்கலாம் மற்றும் மாற்றலாம், இதனால் அதிக தரவு தற்காலிக சேமிப்பில் இருக்கும், அதன்படி, வட்டுக்கு குறைவான பயணங்கள் உள்ளனவா?
பொதுவாக, ஆப்பரேட்டிங் சிஸ்டத்தின் பக்க கேச் இதைச் சிறப்பாகச் செய்கிறது. நீங்கள் மேலே திறந்தால், தற்காலிக சேமிப்பில் அல்லது இலவசம் என்று பாருங்கள் - அது எவ்வளவு தற்காலிகமாக சேமிக்கப்பட்டுள்ளது என்பதையும் கூறுகிறது - பின்னர் அனைத்து இலவச நினைவகமும் தற்காலிக சேமிப்பிற்கு பயன்படுத்தப்படுவதை நீங்கள் கவனிப்பீர்கள். இந்தத் தரவைப் படிக்கும்போது, அது வட்டில் இருந்து அல்ல, ஆனால் RAM இலிருந்து படிக்கப்படும். அதே சமயம், சுருக்கப்பட்ட தரவுகள் தற்காலிகமாக சேமிக்கப்படுவதால், கேச் திறம்பட பயன்படுத்தப்படுகிறது என்று என்னால் சொல்ல முடியும்.
இருப்பினும், நீங்கள் சில எளிய வினவல்களை இன்னும் விரைவுபடுத்த விரும்பினால், கிளிக்ஹவுஸில் உள்ள டிகம்ப்ரஸ் செய்யப்பட்ட தரவுகளில் தற்காலிக சேமிப்பை இயக்க முடியும். அது அழைக்கபடுகிறது சுருக்கப்படாத தற்காலிக சேமிப்பு. config.xml உள்ளமைவு கோப்பில், சுருக்கப்படாத கேச் அளவை உங்களுக்குத் தேவையான மதிப்புக்கு அமைக்கவும் - இலவச ரேமில் பாதிக்கு மேல் இல்லை என்று நான் பரிந்துரைக்கிறேன், ஏனென்றால் மீதமுள்ளவை பக்க தற்காலிக சேமிப்பின் கீழ் செல்லும்.
கூடுதலாக, இரண்டு கோரிக்கை நிலை அமைப்புகள் உள்ளன. முதல் அமைப்பு - சுருக்கப்படாத தற்காலிக சேமிப்பைப் பயன்படுத்தவும் - அதன் பயன்பாடு அடங்கும். அனைத்து தரவையும் படித்து தற்காலிக சேமிப்பை பறிக்கக்கூடிய கனமானவை தவிர, அனைத்து கோரிக்கைகளுக்கும் இதை இயக்க பரிந்துரைக்கப்படுகிறது. இரண்டாவது அமைப்பானது தற்காலிக சேமிப்பைப் பயன்படுத்துவதற்கான அதிகபட்ச வரிகளைப் போன்றது. இது தானாகவே பெரிய வினவல்களைக் கட்டுப்படுத்துகிறது, இதனால் அவை தற்காலிக சேமிப்பைத் தவிர்க்கின்றன.
ரேமில் சேமிப்பிற்காக நான் எப்படி storage_configuration ஐ உள்ளமைப்பது?
புதிய ClickHouse ஆவணத்தில் தொடர்புடைய பகுதியைப் படித்தேன் . விளக்கத்தில் வேகமான SSD உடன் ஒரு எடுத்துக்காட்டு உள்ளது.
அதே விஷயத்தை வால்யூம் ஹாட் மெமரியுடன் எவ்வாறு கட்டமைக்க முடியும் என்று எனக்கு ஆச்சரியமாக இருக்கிறது. மேலும் ஒரு கேள்வி. இந்த தரவு நிறுவனத்துடன் தேர்ந்தெடுக்கப்பட்ட அமைப்பு எவ்வாறு செயல்படுகிறது, அது முழு தொகுப்பையும் படிக்குமா அல்லது வட்டில் உள்ள ஒன்றை மட்டும் படிக்குமா, மேலும் இந்தத் தரவு நினைவகத்தில் சுருக்கப்பட்டதா? அத்தகைய தரவு நிறுவனத்துடன் ப்ரீவேர் பிரிவு எவ்வாறு செயல்படுகிறது?
இந்த அமைப்பு தரவுத் துண்டுகளின் சேமிப்பைப் பாதிக்கிறது, மேலும் அவற்றின் வடிவம் எந்த வகையிலும் மாறாது.
இன்னும் விரிவாகப் பார்ப்போம்.
நீங்கள் RAM இல் தரவு சேமிப்பகத்தை உள்ளமைக்கலாம். வட்டுக்கு கட்டமைக்கப்பட்ட அனைத்தும் அதன் பாதை. நீங்கள் ஒரு tmpfs பகிர்வை உருவாக்குகிறீர்கள், அது கோப்பு முறைமையில் சில பாதையில் ஏற்றப்படுகிறது. வெப்பமான பகிர்வுக்கான தரவைச் சேமிப்பதற்கான பாதையாக இந்தப் பாதையை நீங்கள் குறிப்பிடுகிறீர்கள், தரவுத் துண்டுகள் வந்து அங்கு எழுதப்படும், எல்லாம் நன்றாக இருக்கிறது.
ஆனால் குறைந்த நம்பகத்தன்மை காரணமாக இதைச் செய்ய நான் பரிந்துரைக்கவில்லை, இருப்பினும் வெவ்வேறு தரவு மையங்களில் குறைந்தது மூன்று பிரதிகள் இருந்தால், அது சாத்தியமாகும். ஏதேனும் நடந்தால், தரவு மீட்டமைக்கப்படும். சர்வர் திடீரென்று அணைக்கப்பட்டு மீண்டும் இயக்கப்பட்டது என்று கற்பனை செய்வோம். பகிர்வு மீண்டும் ஏற்றப்பட்டது, ஆனால் அங்கு எதுவும் இல்லை. கிளிக்ஹவுஸ் சேவையகம் தொடங்கும் போது, அதில் இந்த துண்டுகள் இல்லை என்று பார்க்கிறது, இருப்பினும், ZooKeeper மெட்டாடேட்டாவின் படி, அவை இருக்க வேண்டும். எந்தப் பிரதிகள் உள்ளன என்பதைப் பார்த்து, அவற்றைக் கேட்டு, பதிவிறக்கம் செய்கிறார். இந்த வழியில் தரவு மீட்டமைக்கப்படும்.
இந்த அர்த்தத்தில், RAM இல் தரவை சேமிப்பது வட்டில் சேமிப்பதில் இருந்து அடிப்படையில் வேறுபட்டதல்ல, ஏனெனில் தரவு வட்டில் எழுதப்படும் போது, அது முதலில் பக்க தற்காலிக சேமிப்பில் முடிவடைகிறது மற்றும் பின்னர் எழுதப்படும். இது கோப்பு முறைமை மவுண்டிங் விருப்பத்தைப் பொறுத்தது. ஆனால் ஒரு வேளை, செருகும் போது ClickHouse fsync ஆகாது என்று கூறுவேன்.
இந்த வழக்கில், RAM இல் உள்ள தரவு வட்டில் உள்ள அதே வடிவத்தில் சேமிக்கப்படுகிறது. தேர்ந்தெடுக்கப்பட்ட வினவல் அதே வழியில் படிக்க வேண்டிய துண்டுகளைத் தேர்ந்தெடுத்து, துண்டுகளில் தேவையான தரவு வரம்புகளைத் தேர்ந்தெடுத்து அவற்றைப் படிக்கிறது. தரவு RAM இல் இருந்ததா அல்லது வட்டில் இருந்ததா என்பதைப் பொருட்படுத்தாமல், prewhere சரியாக வேலை செய்கிறது.
குறைந்த கார்டினாலிட்டி எவ்வளவு தனிப்பட்ட மதிப்புகள் வரை பயனுள்ளதாக இருக்கும்?
குறைந்த கார்டினாலிட்டி புத்திசாலித்தனமாக வடிவமைக்கப்பட்டுள்ளது. இது தரவு அகராதிகளைத் தொகுக்கிறது, ஆனால் அவை உள்ளூர். முதலாவதாக, ஒவ்வொரு பகுதிக்கும் வெவ்வேறு அகராதிகள் உள்ளன, இரண்டாவதாக, ஒரு துண்டுக்குள் கூட அவை ஒவ்வொரு வரம்பிற்கும் வித்தியாசமாக இருக்கலாம். தனித்துவமான மதிப்புகளின் எண்ணிக்கை ஒரு வாசலை எட்டும்போது - ஒரு மில்லியன், நான் நினைக்கிறேன் - அகராதி வெறுமனே கிடப்பில் போடப்பட்டு புதியது உருவாக்கப்பட்டது.
பதில் பொதுவாக உள்ளது: ஒவ்வொரு உள்ளூர் வரம்பிற்கும் - சொல்லுங்கள், ஒவ்வொரு நாளும் - எங்காவது ஒரு மில்லியன் தனிப்பட்ட மதிப்புகள் குறைந்த கார்டினலிட்டி பயனுள்ளதாக இருக்கும். அதன்பிறகு ஒரு பின்னடைவு இருக்கும், அதில் ஒன்று மட்டும் இல்லாமல் பல வேறுபட்ட அகராதிகள் பயன்படுத்தப்படும். இது ஒரு வழக்கமான சரம் நெடுவரிசையைப் போலவே செயல்படும், ஒருவேளை செயல்திறன் குறைவாக இருக்கலாம், ஆனால் தீவிர செயல்திறன் சிதைவு இருக்காது.
ஐந்து பில்லியன் வரிசைகள் கொண்ட அட்டவணையை முழு உரை தேடுவதற்கான சிறந்த நடைமுறைகள் யாவை?
வெவ்வேறு பதில்கள் உள்ளன. கிளிக்ஹவுஸ் ஒரு முழு உரை தேடுபொறி அல்ல என்று முதலில் கூற வேண்டும். இதற்கு சிறப்பு அமைப்புகள் உள்ளன, எடுத்துக்காட்டாக, и . இருப்பினும், எலாஸ்டிக் தேடலில் இருந்து கிளிக்ஹவுஸுக்கு மாறுவதாக மக்கள் கூறுவதை நான் அதிகளவில் பார்க்கிறேன்.
இது ஏன் நடக்கிறது? குறியீடுகளின் கட்டுமானத்தில் தொடங்கி, சில தொகுதிகளில் சுமைகளைச் சமாளிப்பதை Elasticsearch நிறுத்துகிறது என்பதன் மூலம் அவர்கள் இதை விளக்குகிறார்கள். குறியீடுகள் மிகவும் சிக்கலானதாக மாறும், மேலும் நீங்கள் தரவை கிளிக்ஹவுஸுக்கு மாற்றினால், அவை தொகுதி அடிப்படையில் பல மடங்கு திறமையாக சேமிக்கப்படும் என்று மாறிவிடும். அதே நேரத்தில், தேடல் வினவல்கள் பெரும்பாலும் தரவுகளின் முழு அளவிலும் சில சொற்றொடரைக் கண்டுபிடிக்க வேண்டிய அவசியமில்லை, உருவவியல் கணக்கில் எடுத்துக் கொள்ள வேண்டும், ஆனால் முற்றிலும் வேறுபட்டவை. எடுத்துக்காட்டாக, கடந்த சில மணிநேரங்களில் பதிவுகளில் பைட்டுகளின் சில தொடர்களைக் கண்டறியவும்.
இந்த வழக்கில், நீங்கள் கிளிக்ஹவுஸில் ஒரு குறியீட்டை உருவாக்குகிறீர்கள், அதன் முதல் புலம் தேதி மற்றும் நேரமாக இருக்கும். மேலும் மிகப்பெரிய டேட்டா கட்-ஆஃப் தேதி வரம்பின் அடிப்படையில் இருக்கும். தேர்ந்தெடுக்கப்பட்ட தேதி வரம்பிற்குள், ஒரு விதியாக, ப்ரூட் ஃபோர்ஸ் முறையைப் பயன்படுத்தி கூட, முழு உரைத் தேடலை மேற்கொள்வது ஏற்கனவே சாத்தியமாகும். கிளிக்ஹவுஸில் உள்ள லைக் ஆபரேட்டர், நீங்கள் கண்டுபிடிக்கக்கூடிய ஆபரேட்டரைப் போன்ற மிகவும் திறமையானவர். நீங்கள் ஏதாவது சிறப்பாகக் கண்டால், சொல்லுங்கள்.
ஆனால் இன்னும், ஒரு முழு ஸ்கேன் உள்ளது. முழு ஸ்கேன் CPU இல் மட்டுமல்ல, வட்டிலும் மெதுவாக இருக்கும். திடீரென்று ஒரு நாளைக்கு ஒரு டெராபைட் டேட்டா இருந்தால், பகலில் ஒரு வார்த்தையைத் தேடினால், நீங்கள் டெராபைட்டை ஸ்கேன் செய்ய வேண்டும். மேலும் இது வழக்கமான ஹார்டு டிரைவ்களில் இருக்கலாம், இறுதியில் அவை ஏற்றப்படும், இதனால் நீங்கள் SSH வழியாக இந்த சேவையகத்தை அணுக முடியாது.
இந்த நிலையில், நான் இன்னும் ஒரு சிறிய தந்திரத்தை வழங்க தயாராக இருக்கிறேன். இது சோதனையானது - இது வேலை செய்யலாம், அது இல்லாமல் இருக்கலாம். ClickHouse ட்ரைகிராம் ப்ளூம் வடிப்பான்களின் வடிவத்தில் முழு உரை குறியீடுகளைக் கொண்டுள்ளது. அரினாடேட்டாவில் உள்ள எங்கள் சகாக்கள் ஏற்கனவே இந்த குறியீடுகளை முயற்சித்துள்ளனர், மேலும் அவை பெரும்பாலும் நோக்கம் கொண்டபடியே செயல்படுகின்றன.
அவற்றைச் சரியாகப் பயன்படுத்த, அவை எவ்வாறு செயல்படுகின்றன என்பதைப் பற்றி நீங்கள் நன்கு புரிந்து கொள்ள வேண்டும்: டிரிகிராம் ப்ளூம் வடிகட்டி என்றால் என்ன, அதன் அளவை எவ்வாறு தேர்வு செய்வது. தரவுகளில் அரிதாகக் காணப்படும் சில அரிய சொற்றொடர்கள், துணைச்சரங்கள் பற்றிய வினவல்களுக்கு அவை உதவும் என்று என்னால் சொல்ல முடியும். இந்த வழக்கில், துணை வரம்புகள் குறியீடுகளால் தேர்ந்தெடுக்கப்படும் மற்றும் குறைவான தரவு படிக்கப்படும்.
சமீபத்தில், கிளிக்ஹவுஸ் முழு உரை தேடலுக்காக இன்னும் மேம்பட்ட செயல்பாடுகளைச் சேர்த்துள்ளது. இது, முதலாவதாக, UTF-8 அல்லது ASCII க்கு மட்டுமே ஆதரவுடன் கேஸ்-சென்சிட்டிவ், கேஸ்-சென்சிட்டிவ் ஆகிய விருப்பங்கள் உட்பட, ஒரே பாஸில் ஒரே நேரத்தில் சப்ஸ்ட்ரிங்க்களைத் தேடுவது. உங்களுக்குத் தேவையான மிகவும் பயனுள்ள ஒன்றைத் தேர்ந்தெடுக்கவும்.
ஒரே பாஸில் பல ரெகுலர் எக்ஸ்ப்ரெஷன்களுக்கான தேடல் தோன்றியுள்ளது. நீங்கள் X ஐ ஒரு சப்ஸ்ட்ரிங் போலவும் X ஐ மற்றொரு சப்ஸ்ட்ரிங் போலவும் எழுத வேண்டியதில்லை. நீங்கள் இப்போதே எழுதுங்கள், எல்லாம் முடிந்தவரை திறமையாக செய்யப்படுகிறது.
மூன்றாவதாக, இப்போது regexps க்கான தோராயமான தேடல் மற்றும் சப்ஸ்ட்ரிங்க்களுக்கான தோராயமான தேடல் உள்ளது. யாராவது ஒரு வார்த்தையை தவறாக எழுதியிருந்தால், அது அதிகபட்ச பொருத்தத்திற்காக தேடப்படும்.
அதிக எண்ணிக்கையிலான பயனர்களுக்கு ClickHouseக்கான அணுகலை ஒழுங்கமைக்க சிறந்த வழி எது?
அதிக எண்ணிக்கையிலான நுகர்வோர் மற்றும் ஆய்வாளர்களுக்கான அணுகலை எவ்வாறு சிறப்பாக ஒழுங்கமைப்பது என்பதை எங்களிடம் கூறுங்கள். எப்படி ஒரு வரிசையை உருவாக்குவது, அதிகபட்ச ஒரே நேரத்தில் வினவல்களுக்கு முன்னுரிமை அளிப்பது மற்றும் என்ன கருவிகளைக் கொண்டு?
கிளஸ்டர் போதுமானதாக இருந்தால், மேலும் இரண்டு சேவையகங்களை உயர்த்துவது ஒரு நல்ல தீர்வாக இருக்கும், இது ஆய்வாளர்களுக்கான நுழைவுப் புள்ளியாக மாறும். அதாவது, பகுப்பாய்வாளர்களை கிளஸ்டரில் உள்ள குறிப்பிட்ட துகள்களை அணுக அனுமதிக்காதீர்கள், ஆனால் தரவு இல்லாமல் இரண்டு வெற்று சேவையகங்களை உருவாக்கி, அவற்றில் அணுகல் உரிமைகளை உள்ளமைக்கவும். இந்த வழக்கில், விநியோகிக்கப்பட்ட கோரிக்கைகளுக்கான பயனர் அமைப்புகள் தொலை சேவையகங்களுக்கு மாற்றப்படும். அதாவது, இந்த இரண்டு சேவையகங்களிலும் நீங்கள் அனைத்தையும் உள்ளமைக்கிறீர்கள், மேலும் அமைப்புகள் முழு கிளஸ்டரிலும் தாக்கத்தை ஏற்படுத்துகின்றன.
கொள்கையளவில், இந்த சேவையகங்களுக்கு தரவு இல்லை, ஆனால் கோரிக்கைகளை நிறைவேற்றுவதற்கு அவற்றில் உள்ள ரேம் அளவு மிகவும் முக்கியமானது. வெளிப்புற ஒருங்கிணைப்பு அல்லது வெளிப்புற வரிசையாக்கம் இயக்கப்பட்டிருந்தால், வட்டு தற்காலிகத் தரவிற்கும் பயன்படுத்தப்படலாம்.
சாத்தியமான அனைத்து வரம்புகளுடன் தொடர்புடைய அமைப்புகளைப் பார்ப்பது முக்கியம். நான் இப்போது Yandex.Metrica கிளஸ்டருக்கு ஆய்வாளராகச் சென்று ஒரு கோரிக்கையைக் கேட்டால் வெற்றிகளிலிருந்து எண்ணிக்கையைத் தேர்ந்தெடுக்கவும், பின்னர் நான் கோரிக்கையை நிறைவேற்ற முடியாது என்று எனக்கு உடனடியாக விதிவிலக்கு வழங்கப்படும். நான் ஸ்கேன் செய்ய அனுமதிக்கப்பட்ட வரிசைகளின் அதிகபட்ச எண்ணிக்கை நூறு பில்லியன் ஆகும், மேலும் மொத்தமாக ஐம்பது டிரில்லியன் வரிசைகள் கிளஸ்டரில் ஒரு அட்டவணையில் உள்ளன. இது முதல் வரம்பு.
வரிசை வரம்பை நீக்கிவிட்டு வினவலை மீண்டும் இயக்குகிறேன் என்று வைத்துக்கொள்வோம். பின்னர் நான் பின்வரும் விதிவிலக்கைப் பார்ப்பேன் - அமைப்பு இயக்கப்பட்டது தேதி அடிப்படையில் கட்டாய குறியீட்டு. தேதி வரம்பைக் குறிப்பிடவில்லை என்றால், வினவலை முடிக்க முடியாது. அதை கைமுறையாகக் குறிப்பிட நீங்கள் ஆய்வாளர்களை நம்ப வேண்டியதில்லை. ஒரு பொதுவான வழக்கு என்பது ஒரு தேதி வரம்பு எழுதப்பட்டால், அங்கு நிகழ்வின் தேதி வாரத்திற்கு இடையில் இருக்கும். பின்னர் அவர்கள் ஒரு அடைப்புக்குறியை தவறான இடத்தில் குறிப்பிட்டனர், அதற்கு பதிலாக அது அல்லது - அல்லது URL பொருத்தமாக மாறியது. வரம்பு இல்லை என்றால், அது URL நெடுவரிசையை வலம் வந்து ஒரு டன் வளங்களை வீணடிக்கும்.
கூடுதலாக, ClickHouse இரண்டு முன்னுரிமை அமைப்புகளைக் கொண்டுள்ளது. துரதிர்ஷ்டவசமாக, அவை மிகவும் பழமையானவை. ஒன்று வெறுமனே அழைக்கப்படுகிறது முன்னுரிமை. முன்னுரிமை ≠ 0, மற்றும் சில முன்னுரிமைகள் கொண்ட கோரிக்கைகள் செயல்படுத்தப்பட்டாலும், அதை விட குறைவான முன்னுரிமை மதிப்பைக் கொண்ட கோரிக்கை, அதாவது அதிக முன்னுரிமை, அதிக முன்னுரிமை மதிப்பைக் கொண்ட கோரிக்கை செயல்படுத்தப்படுகிறது, அதாவது குறைந்த முன்னுரிமை , வெறுமனே இடைநிறுத்தப்பட்டது மற்றும் இந்த நேரத்தில் வேலை செய்யாது.
இது மிகவும் கச்சா அமைப்பாகும், மேலும் கிளஸ்டரில் நிலையான சுமை இருக்கும் சந்தர்ப்பங்களில் இது பொருந்தாது. ஆனால் உங்களிடம் குறுகிய, பர்ஸ்ட் கோரிக்கைகள் இருந்தால், மற்றும் கிளஸ்டர் பெரும்பாலும் செயலற்ற நிலையில் இருந்தால், இந்த அமைப்பு பொருத்தமானது.
அடுத்த முன்னுரிமை அமைப்பு அழைக்கப்படுகிறது OS நூல் முன்னுரிமை. இது லினக்ஸ் திட்டமிடலுக்கான அனைத்து கோரிக்கை செயல்படுத்தல் நூல்களுக்கும் நல்ல மதிப்பை அமைக்கிறது. இது மிகவும் வேலை செய்கிறது, ஆனால் அது இன்னும் வேலை செய்கிறது. நீங்கள் குறைந்தபட்ச நல்ல மதிப்பை அமைத்தால் - இது மதிப்பில் மிகப்பெரியது, எனவே மிகக் குறைந்த முன்னுரிமை - மற்றும் அதிக முன்னுரிமை கொண்ட கோரிக்கைகளுக்கு -19 ஐ அமைத்தால், CPU குறைந்த முன்னுரிமை கோரிக்கைகளை அதிக முன்னுரிமையை விட நான்கு மடங்கு குறைவாக பயன்படுத்தும்.
அதிகபட்ச கோரிக்கை செயல்படுத்தும் நேரத்தையும் நீங்கள் கட்டமைக்க வேண்டும் - ஐந்து நிமிடங்கள் என்று சொல்லுங்கள். வினவல் செயலாக்கத்தின் குறைந்தபட்ச வேகம் சிறந்த விஷயம். இந்த அமைப்பு நீண்ட காலமாக உள்ளது, மேலும் கிளிக்ஹவுஸ் மெதுவாக இல்லை என்பதை வலியுறுத்துவது மட்டுமல்லாமல், அதை கட்டாயப்படுத்தவும் இது தேவைப்படுகிறது.
கற்பனை செய்து பாருங்கள், நீங்கள் அமைத்துள்ளீர்கள்: சில வினவல்கள் ஒரு வினாடிக்கு ஒரு மில்லியன் வரிசைகளுக்கு குறைவாக செயல்பட்டால், உங்களால் அதைச் செய்ய முடியாது. இது நமது நல்ல பெயரை, நமது நல்ல தரவுத்தளத்தை இழிவுபடுத்துகிறது. இதை மட்டும் தடை செய்வோம். உண்மையில் இரண்டு அமைப்புகள் உள்ளன. ஒருவர் அழைக்கப்படுகிறார் நிமிட செயலாக்க வேகம் - வினாடிக்கு வரிகளில், மற்றும் இரண்டாவது நிமிட செயலாக்க வேகத்தை சரிபார்க்கும் முன் காலாவதி என்று அழைக்கப்படுகிறது - இயல்பாக பதினைந்து வினாடிகள். அதாவது, பதினைந்து வினாடிகள் சாத்தியம், பின்னர், அது மெதுவாக இருந்தால், விதிவிலக்கை எறிந்து கோரிக்கையை நிறுத்தவும்.
நீங்கள் ஒதுக்கீடுகளையும் அமைக்க வேண்டும். ClickHouse ஆனது வள நுகர்வைக் கணக்கிடும் உள்ளமைக்கப்பட்ட ஒதுக்கீடு அம்சத்தைக் கொண்டுள்ளது. ஆனால், துரதிர்ஷ்டவசமாக, CPU, டிஸ்க்குகள் போன்ற வன்பொருள் வளங்கள் அல்ல, ஆனால் தருக்கமானவை - செயலாக்கப்பட்ட கோரிக்கைகள், கோடுகள் மற்றும் பைட்டுகளின் எண்ணிக்கை. நீங்கள் கட்டமைக்க முடியும், எடுத்துக்காட்டாக, ஐந்து நிமிடங்களுக்குள் அதிகபட்சம் நூறு கோரிக்கைகள் மற்றும் ஒரு மணி நேரத்திற்கு ஆயிரம் கோரிக்கைகள்.
அது ஏன் முக்கியம்? ஏனெனில் சில பகுப்பாய்வு வினவல்கள் ClickHouse கிளையண்டிலிருந்து நேரடியாக கைமுறையாகச் செய்யப்படும். மேலும் அனைத்தும் நன்றாக இருக்கும். ஆனால் உங்கள் நிறுவனத்தில் மேம்பட்ட ஆய்வாளர்கள் இருந்தால், அவர்கள் ஒரு ஸ்கிரிப்டை எழுதுவார்கள், மேலும் ஸ்கிரிப்ட்டில் பிழை இருக்கலாம். இந்த பிழையானது கோரிக்கையை எல்லையற்ற சுழற்சியில் செயல்படுத்தும். இதில் இருந்து நாம் நம்மை பாதுகாத்துக் கொள்ள வேண்டும்.
ஒரு கேள்வியின் முடிவுகளை பத்து வாடிக்கையாளர்களுக்கு வழங்க முடியுமா?
ஒரே நேரத்தில் மிகப் பெரிய கோரிக்கைகளுடன் வர விரும்பும் பல பயனர்கள் எங்களிடம் உள்ளனர். கோரிக்கை பெரியது மற்றும் கொள்கையளவில், விரைவாக செயல்படுத்தப்படுகிறது, ஆனால் ஒரே நேரத்தில் இதுபோன்ற பல கோரிக்கைகள் இருப்பதால், அது மிகவும் வேதனையாகிறது. தொடர்ந்து பத்து முறை வந்த அதே கோரிக்கையை, ஒருமுறை நிறைவேற்றி, பத்து வாடிக்கையாளர்களுக்கு ரிசல்ட் கொடுக்க முடியுமா?
சிக்கல் என்னவென்றால், இடைநிலை தரவுகளின் கேச் அல்லது கேச் முடிவுகள் எங்களிடம் இல்லை. இயக்க முறைமையின் ஒரு பக்க கேச் உள்ளது, இது வட்டில் இருந்து தரவை மீண்டும் படிப்பதைத் தடுக்கும், ஆனால், துரதிர்ஷ்டவசமாக, தரவு இன்னும் சுருக்கப்பட்டு, சீரழிக்கப்பட்டு மீண்டும் செயலாக்கப்படும்.
இடைநிலைத் தரவைத் தேக்ககப்படுத்துவதன் மூலமாகவோ அல்லது இதே போன்ற வினவல்களை ஏதேனும் ஒரு வரிசையில் வரிசைப்படுத்தி முடிவுகள் தற்காலிக சேமிப்பைச் சேர்ப்பதன் மூலமாகவோ இதை எப்படியாவது தவிர்க்க விரும்புகிறேன். தற்போது எங்களிடம் ஒரு இழுத்தல் கோரிக்கையை உருவாக்கி உள்ளது, அது கோரிக்கை தற்காலிக சேமிப்பைச் சேர்க்கிறது, ஆனால் இன் மற்றும் சேர் பிரிவுகளில் உள்ள துணை வினவல்களுக்கு மட்டுமே - அதாவது தீர்வு முழுமையடையாது.
எனினும் நாமும் அவ்வாறானதொரு நிலைமையை எதிர்நோக்குகின்றோம். ஒரு குறிப்பாக நியமன உதாரணம் பக்க வினவல்கள். ஒரு அறிக்கை உள்ளது, அதில் பல பக்கங்கள் உள்ளன, மேலும் வரம்பு 10க்கான கோரிக்கை உள்ளது. பின்னர் அதே விஷயம், ஆனால் வரம்பு 10,10. பின்னர் மற்றொரு அடுத்த பக்கம். மேலும் கேள்வி என்னவென்றால், இதையெல்லாம் ஏன் ஒவ்வொரு முறையும் எண்ணுகிறோம்? ஆனால் இப்போது தீர்வு இல்லை, தவிர்க்க வழி இல்லை.
கிளிக்ஹவுஸுக்கு அடுத்ததாக ஒரு பக்கவாட்டாக வைக்கப்படும் மாற்று தீர்வு உள்ளது - .
கிரில் ஷ்வகோவ்: ClickHouse ப்ராக்ஸியில் உள்ளமைக்கப்பட்ட வீத வரம்பு மற்றும் உள்ளமைக்கப்பட்ட முடிவுகள் கேச் உள்ளது. இதேபோன்ற சிக்கல் தீர்க்கப்படுவதால் அங்கு நிறைய அமைப்புகள் செய்யப்பட்டன. ப்ராக்ஸி கோரிக்கைகளை வரிசைப்படுத்துவதன் மூலம் அவற்றைக் கட்டுப்படுத்தவும், கோரிக்கை கேச் எவ்வளவு காலம் வாழ்கிறது என்பதை உள்ளமைக்கவும் உங்களை அனுமதிக்கிறது. கோரிக்கைகள் ஒரே மாதிரியாக இருந்தால், ப்ராக்ஸி அவற்றை பல முறை அனுப்பும், ஆனால் கிளிக்ஹவுஸுக்கு ஒரு முறை மட்டுமே செல்லும்.
Nginx இலவச பதிப்பில் ஒரு தற்காலிக சேமிப்பையும் கொண்டுள்ளது, இதுவும் வேலை செய்யும். ஒரே நேரத்தில் கோரிக்கைகள் வந்தால், ஒன்று முடிவடையும் வரை அது மற்றவர்களின் வேகத்தைக் குறைக்கும் அமைப்புகளையும் Nginx கொண்டுள்ளது. ஆனால் கிளிக்ஹவுஸ் ப்ராக்ஸியில் தான் செட்டப் சிறப்பாக செய்யப்பட்டுள்ளது. இது குறிப்பாக ClickHouse க்காக உருவாக்கப்பட்டது, குறிப்பாக இந்த கோரிக்கைகளுக்காக, இது மிகவும் பொருத்தமானது. சரி, அதை நிறுவுவது எளிது.
ஒத்திசைவற்ற செயல்பாடுகள் மற்றும் பொருளடக்கம் செய்யப்பட்ட காட்சிகள் பற்றி என்ன?
ரீப்ளே எஞ்சினுடனான செயல்பாடுகள் ஒத்திசைவற்றதாக இருப்பதில் சிக்கல் உள்ளது - முதலில் தரவு எழுதப்பட்டது, பின்னர் அது சரிகிறது. சில தொகுப்புகளைக் கொண்ட ஒரு பொருளடக்கம் செய்யப்பட்ட டேப்லெட் அடையாளத்தின் கீழ் இருந்தால், அதற்கு நகல் எழுதப்படும். சிக்கலான தர்க்கம் இல்லை என்றால், தரவு நகலெடுக்கப்படும். அதற்கு நீங்கள் என்ன செய்ய முடியும்?
ஒரு தெளிவான தீர்வு உள்ளது - ஒத்திசைவற்ற சரிவு செயல்பாட்டின் போது ஒரு குறிப்பிட்ட வகை மேட்வியூகளில் ஒரு தூண்டுதலை செயல்படுத்த. இதேபோன்ற செயல்பாட்டை செயல்படுத்த ஏதேனும் வெள்ளி தோட்டாக்கள் அல்லது திட்டங்கள் உள்ளதா?
இரட்டிப்பு எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்வது மதிப்பு. நான் இப்போது உங்களுக்குச் சொல்வது கேள்விக்கு பொருத்தமானதல்ல, ஆனால் அதை நினைவில் கொள்வது மதிப்பு.
பிரதி அட்டவணையில் செருகும் போது, முழு செருகப்பட்ட தொகுதிகளின் துப்பறிதல் உள்ளது. அதே வரிசையில் அதே வரிசைகளின் அதே எண்ணிக்கையைக் கொண்ட அதே தொகுதியை மீண்டும் செருகினால், தரவு நகலெடுக்கப்படும். செருகுவதற்குப் பதில் "சரி" என்பதை நீங்கள் பெறுவீர்கள், ஆனால் உண்மையில் ஒரு பாக்கெட் தரவு எழுதப்படும், மேலும் அது நகலெடுக்கப்படாது.
உறுதிக்கு இது அவசியம். செருகும் போது "சரி" எனப் பெற்றால், உங்கள் தரவு செருகப்பட்டது. நீங்கள் ClickHouse இலிருந்து பிழையைப் பெற்றால், அவை செருகப்படவில்லை என்று அர்த்தம் மற்றும் நீங்கள் செருகலை மீண்டும் செய்ய வேண்டும். ஆனால் செருகும் போது இணைப்பு உடைந்தால், தரவு செருகப்பட்டதா இல்லையா என்பது உங்களுக்குத் தெரியாது. மீண்டும் செருகுவதை மீண்டும் செய்வதே ஒரே வழி. தரவு உண்மையில் செருகப்பட்டு, நீங்கள் அதை மீண்டும் செருகினால், தொகுதி விலக்கு உள்ளது. நகல்களைத் தவிர்க்க இது அவசியம்.
மேலும், அது எவ்வாறு செயல் படுகிறது என்பதும் முக்கியம். மெயின் டேபிளில் செருகப்படும் போது தரவு நகலெடுக்கப்பட்டிருந்தால், அது பொருளடக்கம் செய்யப்பட்ட பார்வைக்கும் செல்லாது.
இப்போது கேள்வி பற்றி. தனிப்பட்ட வரிகளின் நகல்களை நீங்கள் பதிவு செய்வதால் உங்கள் நிலைமை மிகவும் சிக்கலானது. அதாவது, இது முழு பேக் நகல் அல்ல, ஆனால் குறிப்பிட்ட கோடுகள், மேலும் அவை பின்னணியில் சரிந்துவிடும். உண்மையில், தரவு பிரதான அட்டவணையில் சரிந்து விடும், ஆனால் சுருக்கப்படாத தரவு மெட்டீரியல் காட்சிக்கு செல்லும், மேலும் ஒன்றிணைக்கும் போது பொருள்படுத்தப்பட்ட காட்சிகளுக்கு எதுவும் நடக்காது. ஏனென்றால், பொருள்படுத்தப்பட்ட பார்வை ஒரு செருகும் தூண்டுதலைத் தவிர வேறில்லை. மற்ற செயல்பாடுகளின் போது, கூடுதலாக எதுவும் நடக்காது.
மேலும் நான் உங்களை இங்கு சந்தோஷப்படுத்த முடியாது. இந்த வழக்கில் நீங்கள் ஒரு குறிப்பிட்ட தீர்வைத் தேட வேண்டும். எடுத்துக்காட்டாக, அதை ஒரு மெட்டீரியல் பார்வையில் மீண்டும் இயக்குவது சாத்தியமா, மேலும் துப்பறியும் முறையும் அதே வழியில் செயல்படலாம். ஆனால் துரதிருஷ்டவசமாக, எப்போதும் இல்லை. அது திரட்டினால், அது வேலை செய்யாது.
கிரில் ஷ்வகோவ்: நாங்கள் அன்று ஊன்றுகோல் கட்டுமானத்தையும் கொண்டிருந்தோம். விளம்பர இம்ப்ரெஷன்கள் இருப்பதில் சிக்கல் உள்ளது, மேலும் நிகழ்நேரத்தில் காட்டக்கூடிய சில தரவுகள் உள்ளன - இவை வெறும் பதிவுகள் மட்டுமே. அவை அரிதாகவே நகலெடுக்கப்படுகின்றன, ஆனால் இது நடந்தால், பின்னர் எப்படியும் அவற்றை உடைப்போம். மேலும் நகலெடுக்க முடியாத விஷயங்கள் இருந்தன - கிளிக்குகள் மற்றும் இந்த முழு கதையும். ஆனால் நான் அவற்றை உடனடியாகக் காட்ட விரும்பினேன்.
பொருள்மயமாக்கப்பட்ட காட்சிகள் எவ்வாறு உருவாக்கப்பட்டன? இது நேரடியாக எழுதப்பட்ட காட்சிகள் இருந்தன - இது மூல தரவுகளுக்கு எழுதப்பட்டது மற்றும் பார்வைகளுக்கு எழுதப்பட்டது. அங்கு, ஒரு கட்டத்தில் தரவு மிகவும் சரியாக இல்லை, அது நகல், மற்றும் பல. அட்டவணையின் இரண்டாவது பகுதி உள்ளது, அங்கு அவை பொருள்மயமாக்கப்பட்ட காட்சிகளைப் போலவே இருக்கும், அதாவது அவை கட்டமைப்பில் முற்றிலும் ஒரே மாதிரியானவை. எப்போதாவது நாங்கள் தரவை மீண்டும் கணக்கிடுகிறோம், நகல் இல்லாமல் தரவை எண்ணுகிறோம், அந்த அட்டவணைகளுக்கு எழுதுகிறோம்.
நாங்கள் API மூலம் சென்றோம் - இது கிளிக்ஹவுஸில் கைமுறையாக வேலை செய்யாது. ஏபிஐ தோற்றமளிக்கிறது: அட்டவணையில் கடைசியாகச் சேர்த்த தேதி என்னிடம் இருக்கும்போது, சரியான தரவு ஏற்கனவே கணக்கிடப்பட்டுள்ளது என்று உத்தரவாதம் அளிக்கப்படுகிறது, மேலும் இது ஒரு அட்டவணைக்கும் மற்றொரு அட்டவணைக்கும் கோரிக்கையை வைக்கிறது. ஒன்றிலிருந்து கோரிக்கையானது ஒரு குறிப்பிட்ட நேரத்தைத் தேர்ந்தெடுக்கிறது, மற்றொன்றில் இருந்து இதுவரை கணக்கிடப்படாததைப் பெறுகிறது. அது வேலை செய்கிறது, ஆனால் ClickHouse மூலம் மட்டும் அல்ல.
உங்களிடம் சில வகையான API இருந்தால் - ஆய்வாளர்களுக்கு, பயனர்களுக்கு - பின்னர், கொள்கையளவில், இது ஒரு விருப்பமாகும். நீங்கள் எப்போதும் எண்ணுகிறீர்கள், எப்போதும் எண்ணுகிறீர்கள். இதை ஒரு நாளைக்கு ஒரு முறை அல்லது வேறு சில நேரங்களில் செய்யலாம். உங்களுக்குத் தேவையில்லாத மற்றும் முக்கியமானதாக இல்லாத வரம்பை நீங்களே தேர்வு செய்கிறீர்கள்.
கிளிக்ஹவுஸில் நிறைய பதிவுகள் உள்ளன. சர்வருக்கு நடக்கும் அனைத்தையும் ஒரே பார்வையில் எப்படிப் பார்ப்பது?
ClickHouse ஆனது மிகப் பெரிய எண்ணிக்கையிலான பல்வேறு பதிவுகளைக் கொண்டுள்ளது, மேலும் இந்த எண்ணிக்கை அதிகரித்து வருகிறது. புதிய பதிப்புகளில், அவற்றில் சில இயல்பாகவே இயக்கப்படும்; பழைய பதிப்புகளில் புதுப்பிக்கும்போது அவை இயக்கப்பட வேண்டும். இருப்பினும், அவற்றில் அதிகமானவை உள்ளன. இறுதியில், எனது சர்வரில் இப்போது என்ன நடக்கிறது, சில வகையான சுருக்க டாஷ்போர்டில் என்ன நடக்கிறது என்பதைப் பார்க்க விரும்புகிறேன்.
உங்கள் ClickHouse குழுவில் அல்லது உங்கள் நண்பர்களின் குழுக்களில், இந்த பதிவுகளை ஆயத்த தயாரிப்பாகக் காண்பிக்கும் ஆயத்த டாஷ்போர்டுகளின் சில செயல்பாடுகளை ஆதரிக்கிறீர்களா? இறுதியில், ClickHouse இல் பதிவுகளைப் பார்ப்பது மிகவும் நல்லது. ஆனால் இது ஏற்கனவே டேஷ்போர்டு வடிவில் தயாராக இருந்தால் மிகவும் அருமையாக இருக்கும். எனக்கு ஒரு அடி கிடைக்கும்.
டாஷ்போர்டுகள் உள்ளன, இருப்பினும் அவை தரப்படுத்தப்படவில்லை. எங்கள் நிறுவனத்தில், சுமார் 60 குழுக்கள் ClickHouse ஐப் பயன்படுத்துகின்றன, மேலும் விசித்திரமான விஷயம் என்னவென்றால், அவர்களில் பலர் தாங்களே உருவாக்கிய டாஷ்போர்டுகள் மற்றும் சற்று வித்தியாசமானவை. சில அணிகள் உள் Yandex.Cloud நிறுவலைப் பயன்படுத்துகின்றன. சில ஆயத்த அறிக்கைகள் உள்ளன, அவை அனைத்தும் அவசியமானவை அல்ல. மற்றவர்களுக்கு சொந்தம் இருக்கிறது.
மெட்ரிகாவைச் சேர்ந்த எனது சகாக்கள் கிராஃபனாவில் தங்களுடைய சொந்த டாஷ்போர்டை வைத்திருக்கிறார்கள், அவர்களுடைய கிளஸ்டருக்காக நான் சொந்தமாக வைத்திருக்கிறேன். செரிஃப் கேச் கேச் ஹிட் போன்ற விஷயங்களைப் பார்க்கிறேன். மேலும் கடினமானது என்னவென்றால், நாம் வெவ்வேறு கருவிகளைப் பயன்படுத்துகிறோம். கிராஃபைட்-வெப் எனப்படும் மிகப் பழைய கருவியைப் பயன்படுத்தி எனது டாஷ்போர்டை உருவாக்கினேன். அவர் முற்றிலும் அசிங்கமானவர். நான் இன்னும் இதைப் பயன்படுத்துகிறேன், இருப்பினும் கிராஃபானா மிகவும் வசதியாகவும் அழகாகவும் இருக்கும்.
டாஷ்போர்டுகளில் அடிப்படை விஷயம் ஒன்றுதான். இவை கிளஸ்டருக்கான கணினி அளவீடுகள்: CPU, நினைவகம், வட்டு, நெட்வொர்க். மற்றவை - ஒரே நேரத்தில் கோரிக்கைகளின் எண்ணிக்கை, ஒரே நேரத்தில் இணைக்கப்பட்ட எண்ணிக்கை, வினாடிக்கு கோரிக்கைகளின் எண்ணிக்கை, MergeTree அட்டவணை பகிர்வுகளுக்கான அதிகபட்ச எண்ணிக்கை, பிரதி பின்னடைவு, பிரதி வரிசை அளவு, ஒரு நொடிக்கு செருகப்பட்ட வரிசைகளின் எண்ணிக்கை, ஒரு நொடிக்கு செருகப்பட்ட தொகுதிகளின் எண்ணிக்கை. இவை அனைத்தும் பதிவுகளிலிருந்து அல்ல, அளவீடுகளிலிருந்து பெறப்படுகின்றன.
விளாடிமிர் கோலோபேவ்: அலெக்ஸி, நான் அதை கொஞ்சம் திருத்த விரும்புகிறேன். கிராஃபானா உள்ளது. கிராஃபானாவில் ஒரு தரவுமூலம் உள்ளது, அது ClickHouse. அதாவது, நான் கிராஃபானாவிலிருந்து நேரடியாக கிளிக்ஹவுஸுக்கு கோரிக்கைகளை வைக்க முடியும். ClickHouse இல் பதிவுகள் கொண்ட அட்டவணை உள்ளது, இது அனைவருக்கும் ஒரே மாதிரியாக இருக்கும். இதன் விளைவாக, கிராஃபனாவில் உள்ள இந்த பதிவு அட்டவணையை அணுகி எனது சர்வர் செய்யும் கோரிக்கைகளைப் பார்க்க விரும்புகிறேன். இப்படி ஒரு டேஷ்போர்டு இருந்தால் நன்றாக இருக்கும்.
நானே பைக் ஓட்டினேன். ஆனால் எனக்கு ஒரு கேள்வி உள்ளது - இவை அனைத்தும் தரப்படுத்தப்பட்டிருந்தால், மற்றும் கிராஃபனா அனைவராலும் பயன்படுத்தப்படுகிறது என்றால், ஏன் Yandex இல் அத்தகைய அதிகாரப்பூர்வ டாஷ்போர்டு இல்லை?
கிரில் ஷ்வகோவ்: உண்மையில், ClickHouseக்குச் செல்லும் தரவுமூலம் இப்போது Altinity ஐ ஆதரிக்கிறது. மேலும் எங்கு தோண்டுவது, யாரை தள்ளுவது என்பதற்கான திசையனை மட்டும் கொடுக்க விரும்புகிறேன். நீங்கள் அவர்களிடம் கேட்கலாம், ஏனென்றால் யாண்டெக்ஸ் இன்னும் கிளிக்ஹவுஸை உருவாக்குகிறது, அதைச் சுற்றியுள்ள கதை அல்ல. தற்போது ClickHouse ஐ விளம்பரப்படுத்தும் முக்கிய நிறுவனம் Altinity ஆகும். அவர்கள் அவரைக் கைவிட மாட்டார்கள், ஆனால் அவருக்கு ஆதரவளிப்பார்கள். ஏனெனில், கொள்கையளவில், கிராஃபானா இணையதளத்தில் டாஷ்போர்டைப் பதிவேற்ற, நீங்கள் பதிவுசெய்து பதிவேற்ற வேண்டும் - சிறப்பு சிக்கல்கள் எதுவும் இல்லை.
அலெக்ஸி மிலோவிடோவ்: கடந்த ஆண்டில், ClickHouse பல வினவல் விவரக்குறிப்பு திறன்களைச் சேர்த்துள்ளது. வள உபயோகத்தில் ஒவ்வொரு கோரிக்கைக்கும் அளவீடுகள் உள்ளன. சமீபத்தில், ஒவ்வொரு மில்லி வினாடிக்கும் ஒரு வினவல் எங்கு செலவழிக்கிறது என்பதைப் பார்க்க, இன்னும் குறைந்த அளவிலான வினவல் விவரக்குறிப்பைச் சேர்த்துள்ளோம். ஆனால் இந்த செயல்பாட்டைப் பயன்படுத்த, நான் கன்சோல் கிளையண்டைத் திறந்து கோரிக்கையைத் தட்டச்சு செய்ய வேண்டும், அதை நான் எப்போதும் மறந்துவிடுகிறேன். நான் அதை எங்கோ சேமித்தேன், சரியாக எங்கு மறந்துவிட்டேன்.
வினவல் வகுப்பின்படி தொகுக்கப்பட்ட உங்கள் கனமான வினவல்கள் இதோ என்று ஒரு கருவி இருந்திருக்க விரும்புகிறேன். நான் ஒன்றை அழுத்தினேன், அதனால்தான் அது கனமாக இருக்கிறது என்று அவர்கள் என்னிடம் சொல்வார்கள். இப்போது அத்தகைய தீர்வு இல்லை. மக்கள் என்னிடம் கேட்கும்போது இது மிகவும் விசித்திரமானது: “என்னிடம் சொல்லுங்கள், கிராஃபனாவுக்கு ஏதேனும் ஆயத்த டாஷ்போர்டுகள் உள்ளதா?”, நான் சொல்கிறேன்: “கிராஃபனா இணையதளத்திற்குச் செல்லுங்கள், அங்கு “டாஷ்போர்டுகள்” சமூகம் உள்ளது, டாஷ்போர்டு உள்ளது. டிம்காவிலிருந்து, கோஸ்டியனிலிருந்து ஒரு டாஷ்போர்டு உள்ளது. அது என்னவென்று எனக்குத் தெரியவில்லை, நானே அதைப் பயன்படுத்தவில்லை.
சேவையகம் OOM இல் செயலிழக்காமல் இருக்க, இணைப்புகளை எவ்வாறு பாதிக்கலாம்?
என்னிடம் ஒரு அட்டவணை உள்ளது, அட்டவணையில் ஒரே ஒரு பகிர்வு உள்ளது, அது ReplacingMergeTree. நான் நான்கு ஆண்டுகளாக அதில் தரவுகளை எழுதி வருகிறேன். நான் அதில் ஒரு மாற்றத்தை செய்து சில தரவுகளை நீக்க வேண்டும்.
நான் இதைச் செய்தேன், இந்த கோரிக்கையின் செயலாக்கத்தின் போது, கிளஸ்டரில் உள்ள அனைத்து சேவையகங்களிலும் உள்ள அனைத்து நினைவகங்களும் நுகரப்பட்டன, மேலும் கிளஸ்டரில் உள்ள அனைத்து சேவையகங்களும் OOM இல் சென்றன. பின்னர் அவர்கள் அனைவரும் ஒன்றாக எழுந்து, இதே செயல்பாட்டை, இந்த தரவுத் தொகுதியை ஒன்றிணைக்கத் தொடங்கினர், மீண்டும் OOM இல் விழுந்தனர். பின்னர் அவர்கள் மீண்டும் எழுந்து மீண்டும் விழுந்தனர். இந்த விஷயம் நிற்கவில்லை.
இது உண்மையில் தோழர்களே சரிசெய்த ஒரு பிழை என்று மாறியது. இது மிகவும் அருமையாக உள்ளது, மிக்க நன்றி. ஆனால் ஒரு எச்சம் இருந்தது. இப்போது, டேபிளில் சில வகையான ஒன்றிணைப்பைச் செய்வது பற்றி நான் நினைக்கும் போது, எனக்கு ஒரு கேள்வி உள்ளது - இந்த இணைப்புகளை நான் ஏன் எப்படியாவது பாதிக்க முடியாது? எடுத்துக்காட்டாக, தேவையான ரேமின் அளவு அல்லது கொள்கையளவில், இந்த குறிப்பிட்ட அட்டவணையைச் செயலாக்கும் அளவு மூலம் அவற்றைக் கட்டுப்படுத்துங்கள்.
என்னிடம் "மெட்ரிக்ஸ்" என்ற அட்டவணை உள்ளது, அதை எனக்காக இரண்டு திரிகளில் செயலாக்கவும். பத்து அல்லது ஐந்து இணைப்புகளை இணையாக உருவாக்க வேண்டிய அவசியமில்லை, அதை இரண்டாக செய்யுங்கள். இரண்டு பேருக்கு போதுமான நினைவகம் இருப்பதாக நான் நினைக்கிறேன், ஆனால் அது பத்து செயலாக்க போதுமானதாக இருக்காது. பயம் ஏன் நீடிக்கிறது? அட்டவணை வளர்ந்து வருவதால், ஒரு நாள் நான் ஒரு சூழ்நிலையை எதிர்கொள்வேன், கொள்கையளவில், இனி ஒரு பிழை காரணமாக இருக்காது, ஆனால் தரவு இவ்வளவு பெரிய அளவில் மாறும் என்பதால், எனக்கு போதுமான நினைவகம் இருக்காது. சர்வர். பின்னர் ஒன்றிணைக்கும் போது சேவையகம் OOM இல் செயலிழக்கும். மேலும், நான் பிறழ்வை ரத்து செய்ய முடியும், ஆனால் மெர்ஜி இப்போது இல்லை.
உங்களுக்குத் தெரியும், ஒன்றிணைக்கும் போது, சேவையகம் OOM இல் வராது, ஏனெனில் ஒன்றிணைக்கும் போது, RAM இன் அளவு ஒரு சிறிய அளவிலான தரவுகளுக்கு மட்டுமே பயன்படுத்தப்படுகிறது. எனவே தரவுகளின் அளவைப் பொருட்படுத்தாமல் எல்லாம் சரியாகிவிடும்.
விளாடிமிர் கோலோபேவ்: நன்றாக. இங்கே தருணம் என்னவென்றால், பிழை சரி செய்யப்பட்ட பிறகு, எனக்காக ஒரு புதிய பதிப்பைப் பதிவிறக்கினேன், மற்றொரு அட்டவணையில், சிறியது, பல பகிர்வுகள் இருக்கும் இடத்தில், நான் இதேபோன்ற செயல்பாட்டைச் செய்தேன். மேலும் இணைப்பின் போது, சர்வரில் சுமார் 100 ஜிபி ரேம் எரிந்தது. நான் 150 ஆக்கிரமித்திருந்தேன், 100 சாப்பிட்டேன், மேலும் 50 ஜிபி சாளரம் மீதமுள்ளது, அதனால் நான் OOM இல் விழவில்லை.
உண்மையில் 100 GB RAM ஐப் பயன்படுத்தினால், OOM இல் விழுவதிலிருந்து தற்போது என்னைப் பாதுகாப்பது எது? இணைப்பில் உள்ள ரேம் திடீரென தீர்ந்துவிட்டால் என்ன செய்வது?
அலெக்ஸி மிலோவிடோவ்: குறிப்பாக இணைப்பதற்காக ரேமின் நுகர்வு மட்டுப்படுத்தப்படாத ஒரு சிக்கல் உள்ளது. இரண்டாவது சிக்கல் என்னவென்றால், சில வகையான ஒன்றிணைப்பு ஒதுக்கப்பட்டிருந்தால், அது நகலெடுக்கும் பதிவில் பதிவு செய்யப்பட்டுள்ளதால் அது செயல்படுத்தப்பட வேண்டும். பிரதிப் பதிவு என்பது பிரதியை ஒரு சீரான நிலைக்குக் கொண்டுவருவதற்குத் தேவையான செயல்கள் ஆகும். இந்த நகலெடுப்புப் பதிவைத் திரும்பப்பெறும் கைமுறை கையாளுதல்களை நீங்கள் செய்யவில்லை என்றால், ஒன்றிணைப்பு ஒரு வழி அல்லது வேறு வழியில் செய்யப்பட வேண்டும்.
நிச்சயமாக, OOM க்கு எதிராக "ஒரு வேளை" பாதுகாக்கும் RAM வரம்பைக் கொண்டிருப்பது மிதமிஞ்சியதாக இருக்காது. இது ஒன்றிணைப்பை முடிக்க உதவாது, அது மீண்டும் தொடங்கும், சில வாசலை அடையும், விதிவிலக்கை எறிந்து, பின்னர் மீண்டும் தொடங்கும் - இதில் நல்லது எதுவும் வராது. ஆனால் கொள்கையளவில், இந்த தடையை அறிமுகப்படுத்துவது பயனுள்ளதாக இருக்கும்.
ClickHouse க்கான Golang இயக்கி எவ்வாறு உருவாக்கப்படும்?
கிரில் ஷ்வாகோவ் எழுதிய கோலாங் இயக்கி, இப்போது கிளிக்ஹவுஸ் குழுவால் அதிகாரப்பூர்வமாக ஆதரிக்கப்படுகிறது. அவர் , அவர் இப்போது பெரியவர் மற்றும் உண்மையானவர்.
ஒரு சிறு குறிப்பு. எல்லையற்ற ஒழுங்கின் சாதாரண வடிவங்களின் அற்புதமான மற்றும் பிரியமான களஞ்சியம் உள்ளது - இது வெர்டிகா. வெர்டிகா டெவலப்பர்களால் ஆதரிக்கப்படும் அவர்களின் சொந்த அதிகாரப்பூர்வ பைதான் இயக்கி உள்ளது. பல முறை சேமிப்பக பதிப்புகள் மற்றும் இயக்கி பதிப்புகள் மிகவும் வியத்தகு முறையில் வேறுபட்டன, மேலும் இயக்கி ஒரு கட்டத்தில் வேலை செய்வதை நிறுத்தியது. மற்றும் இரண்டாவது புள்ளி. இந்த அதிகாரப்பூர்வ இயக்கிக்கான ஆதரவு, "முலைக்காம்பு" அமைப்பால் மேற்கொள்ளப்படுவதாக எனக்குத் தோன்றுகிறது - நீங்கள் அவர்களுக்கு ஒரு சிக்கலை எழுதுகிறீர்கள், அது எப்போதும் தொங்குகிறது.
என்னிடம் இரண்டு கேள்விகள் உள்ளன. இப்போது Kirill's Golang இயக்கி என்பது Golang இலிருந்து ClickHouse உடன் தொடர்புகொள்வதற்கான இயல்புநிலை வழியாகும். யாராவது இன்னும் http இடைமுகம் வழியாக தொடர்பு கொள்ளாத வரை, அவர் அதை விரும்புகிறார். இந்த இயக்கியின் வளர்ச்சி எவ்வாறு தொடரும்? களஞ்சியத்தில் ஏதேனும் உடைப்பு மாற்றங்களுடன் இது ஒத்திசைக்கப்படுமா? ஒரு சிக்கலைக் கருத்தில் கொள்வதற்கான நடைமுறை என்ன?
கிரில் ஷ்வகோவ்: முதலாவதாக, அனைத்தும் அதிகாரத்துவ ரீதியாக எவ்வாறு ஒழுங்கமைக்கப்பட்டுள்ளன என்பதுதான். இந்த விஷயம் விவாதிக்கப்படவில்லை, எனவே நான் பதிலளிக்க எதுவும் இல்லை.
சிக்கலைப் பற்றிய கேள்விக்கு பதிலளிக்க, ஓட்டுநரின் சிறிய வரலாறு தேவை. நிறைய டேட்டா இருக்கும் நிறுவனத்தில் வேலை பார்த்தேன். இது ஒரு பெரிய அளவிலான நிகழ்வுகளைக் கொண்ட ஒரு விளம்பர ஸ்பின்னர், அதை எங்காவது சேமிக்க வேண்டும். ஒரு கட்டத்தில் கிளிக்ஹவுஸ் தோன்றியது. நாங்கள் அதை தரவு மூலம் நிரப்பினோம், முதலில் எல்லாம் நன்றாக இருந்தது, ஆனால் கிளிக்ஹவுஸ் செயலிழந்தது. அந்த நேரத்தில் அது தேவையில்லை என்று முடிவு செய்தோம்.
ஒரு வருடம் கழித்து, கிளிக்ஹவுஸைப் பயன்படுத்துவதற்கான யோசனைக்கு நாங்கள் திரும்பினோம், எப்படியாவது தரவை எழுத வேண்டும். அறிமுக செய்தி இதுதான்: வன்பொருள் மிகவும் பலவீனமாக உள்ளது, சில ஆதாரங்கள் உள்ளன. ஆனால் நாங்கள் எப்போதும் இந்த வழியில் வேலை செய்தோம், எனவே நாங்கள் சொந்த நெறிமுறையை நோக்கிப் பார்த்தோம்.
நாங்கள் கோவில் பணிபுரிந்ததால், எங்களுக்கு ஒரு கோ டிரைவர் தேவை என்பது தெளிவாகத் தெரிந்தது. நான் அதை முழு நேரமாகச் செய்தேன் - இது எனது பணி. நாங்கள் அதை ஒரு குறிப்பிட்ட நிலைக்கு கொண்டு வந்தோம், கொள்கையளவில் எங்களைத் தவிர வேறு யாரும் அதைப் பயன்படுத்துவார்கள் என்று யாரும் கருதவில்லை. பின்னர் CloudFlare அதே பிரச்சனையுடன் வந்தது, சில நேரம் நாங்கள் அவர்களுடன் மிகவும் சுமூகமாக வேலை செய்தோம், ஏனென்றால் அவர்களுக்கு ஒரே மாதிரியான பணிகள் இருந்தன. மேலும், கிளிக்ஹவுஸிலும், டிரைவரிலும் இதைச் செய்தோம்.
ஒரு கட்டத்தில், நான் அதைச் செய்வதை நிறுத்திவிட்டேன், ஏனென்றால் கிளிக்ஹவுஸ் மற்றும் வேலையின் அடிப்படையில் எனது செயல்பாடு கொஞ்சம் மாறிவிட்டது. எனவே பிரச்சினைகள் மூடப்படவில்லை. அவ்வப்போது, ஏதாவது தேவைப்படும் நபர்கள் களஞ்சியத்தில் ஈடுபடுகிறார்கள். நான் இழுக்கும் கோரிக்கையைப் பார்க்கிறேன், சில சமயங்களில் நானே எதையாவது திருத்துகிறேன், ஆனால் இது அரிதாகவே நடக்கும்.
நான் டிரைவரிடம் திரும்ப விரும்புகிறேன். பல ஆண்டுகளுக்கு முன்பு, இந்த முழு விஷயமும் தொடங்கியபோது, கிளிக்ஹவுஸ் வேறுபட்டது மற்றும் வெவ்வேறு திறன்களுடன் இருந்தது. டிரைவரை எப்படி ரீமேக் செய்வது என்பது பற்றி இப்போது எங்களுக்கு ஒரு புரிதல் உள்ளது, அது நன்றாக வேலை செய்கிறது. இது நடந்தால், திரட்டப்பட்ட ஊன்றுகோல் காரணமாக பதிப்பு 2 எந்த வகையிலும் பொருந்தாது.
இந்த விஷயத்தை எப்படி ஏற்பாடு செய்வது என்று தெரியவில்லை. எனக்கே அதிக நேரம் இல்லை. சிலர் டிரைவரை முடித்தால், நான் அவர்களுக்கு உதவி செய்து என்ன செய்ய வேண்டும் என்று சொல்ல முடியும். ஆனால் திட்டத்தின் வளர்ச்சியில் யாண்டெக்ஸின் செயலில் பங்கேற்பது இன்னும் விவாதிக்கப்படவில்லை.
அலெக்ஸி மிலோவிடோவ்: உண்மையில், இந்த ஓட்டுநர்களைப் பற்றி இன்னும் அதிகாரத்துவம் இல்லை. ஒரே விஷயம் என்னவென்றால், அவை அதிகாரப்பூர்வ நிறுவனத்திற்கு சமர்ப்பிக்கப்படுகின்றன, அதாவது, இந்த இயக்கி Go க்கான அதிகாரப்பூர்வ இயல்புநிலை தீர்வாக அங்கீகரிக்கப்பட்டுள்ளது. வேறு சில ஓட்டுநர்கள் உள்ளனர், ஆனால் அவர்கள் தனித்தனியாக வருகிறார்கள்.
இந்த இயக்கிகளுக்கான உள் வளர்ச்சி எங்களிடம் இல்லை. இந்தக் குறிப்பிட்ட ஓட்டுநருக்கு அல்ல, அனைத்து சமூக ஓட்டுனர்களின் வளர்ச்சிக்காகவும், தனி நபரை நியமிக்கலாமா அல்லது வெளியில் இருந்து யாரையாவது கண்டுபிடிக்க முடியுமா என்பதுதான் கேள்வி.
lazy_load அமைப்பை இயக்கி மறுதொடக்கம் செய்த பிறகு வெளிப்புற அகராதி ஏற்றப்படாது. என்ன செய்ய?
எங்களிடம் lazy_load அமைப்பு இயக்கப்பட்டுள்ளது, மேலும் சேவையகம் மறுதொடக்கம் செய்யப்பட்ட பிறகு, அகராதி தானாகவே ஏற்றப்படாது. பயனர் இந்த அகராதியை அணுகிய பின்னரே இது எழுப்பப்படுகிறது. முதல் முறையாக நான் அதை அணுகும்போது, அது ஒரு பிழையை அளிக்கிறது. கிளிக்ஹவுஸைப் பயன்படுத்தி அகராதிகளை எப்படியாவது தானாக ஏற்றுவது சாத்தியமா அல்லது பயனர்கள் பிழைகளைப் பெறாதபடி அவற்றின் தயார்நிலையை நீங்களே எப்போதும் கட்டுப்படுத்த வேண்டுமா?
எங்களிடம் கிளிக்ஹவுஸின் பழைய பதிப்பு இருக்கலாம், எனவே அகராதி தானாகவே ஏற்றப்படவில்லை. இப்படி இருக்க முடியுமா?
முதலில், ஒரு வினவலைப் பயன்படுத்தி அகராதிகளை கட்டாயமாக ஏற்றலாம் கணினி மறுஏற்றம் அகராதி. இரண்டாவதாக, பிழையைப் பற்றி - அகராதி ஏற்கனவே ஏற்றப்பட்டிருந்தால், வினவல்கள் ஏற்றப்பட்ட தரவின் அடிப்படையில் செயல்படும். அகராதி இன்னும் ஏற்றப்படவில்லை என்றால், கோரிக்கையின் போது அது நேரடியாக ஏற்றப்படும்.
கனரக அகராதிகளுக்கு இது மிகவும் வசதியானது அல்ல. உதாரணமாக, நீங்கள் MySQL இலிருந்து ஒரு மில்லியன் வரிசைகளை இழுக்க வேண்டும். யாரோ ஒரு எளிய தேர்வை செய்கிறார்கள், ஆனால் இந்த தேர்வு அதே மில்லியன் வரிசைகளுக்கு காத்திருக்கும். இங்கே இரண்டு தீர்வுகள் உள்ளன. முதலில் lazy_load ஐ அணைக்க வேண்டும். இரண்டாவதாக, சர்வர் செயலிழந்தவுடன், அதில் சுமை போடுவதற்கு முன், செய்யுங்கள் கணினி மறுஏற்றம் அகராதி அல்லது அகராதியைப் பயன்படுத்தும் வினவலை மட்டும் செய்யவும். பின்னர் அகராதி ஏற்றப்படும். Lazy_load அமைப்பு இயக்கப்பட்டிருக்கும் அகராதிகளின் கிடைக்கும் தன்மையை நீங்கள் கட்டுப்படுத்த வேண்டும், ஏனெனில் ClickHouse தானாகவே அவற்றை ஏற்றாது.
கடைசி கேள்விக்கான பதில் பதிப்பு பழையது அல்லது பிழைத்திருத்தம் செய்யப்பட வேண்டும்.
சிஸ்டம் ரீலோட் அகராதிகள் பல அகராதிகளில் ஏதேனும் ஒரு பிழையால் செயலிழந்தால் அதில் எதையும் ஏற்றவில்லை என்பதை என்ன செய்வது?
கணினி மறுஏற்றம் அகராதிகளைப் பற்றி மற்றொரு கேள்வி உள்ளது. எங்களிடம் இரண்டு அகராதிகள் உள்ளன - ஒன்று ஏற்றப்படவில்லை, இரண்டாவது ஏற்றப்பட்டது. இந்த நிலையில், சிஸ்டம் ரீலோட் அகராதிகள் எந்த அகராதியையும் ஏற்றாது, மேலும் கணினி ரீலோட் அகராதியைப் பயன்படுத்தி குறிப்பிட்ட ஒன்றை அதன் பெயரால் பாயிண்ட் பை பாயிண்ட் ஏற்ற வேண்டும். இதுவும் ClickHouse பதிப்புடன் தொடர்புடையதா?
நான் உன்னை சந்தோஷப்படுத்த விரும்புகிறேன். இந்த நடத்தை மாறிக்கொண்டே இருந்தது. அதாவது ClickHouseஐ அப்டேட் செய்தால் அதுவும் மாறும். உங்கள் தற்போதைய நடத்தையில் நீங்கள் மகிழ்ச்சியடையவில்லை என்றால் கணினி மறுஏற்றம் அகராதி, புதுப்பிக்கவும், மேலும் இது சிறப்பாக மாறும் என நம்புவோம்.
கிளிக்ஹவுஸ் கட்டமைப்பில் விவரங்களை உள்ளமைக்க வழி உள்ளதா, ஆனால் பிழைகள் ஏற்பட்டால் அவற்றைக் காட்டவில்லையா?
அடுத்த கேள்வி அகராதி தொடர்பான பிழைகள், அதாவது விவரங்கள் பற்றியது. அகராதிக்கான கிளிக்ஹவுஸ் கட்டமைப்பில் இணைப்பு விவரங்களை நாங்கள் குறிப்பிட்டுள்ளோம், மேலும் பிழை இருந்தால், இந்த விவரங்கள் மற்றும் கடவுச்சொல்லைப் பதிலளிப்போம்.
ODBC இயக்கி கட்டமைப்பில் விவரங்களைச் சேர்ப்பதன் மூலம் இந்தப் பிழையைத் தீர்த்தோம். கிளிக்ஹவுஸ் கட்டமைப்பில் விவரங்களை உள்ளமைக்க ஏதேனும் வழி உள்ளதா, ஆனால் பிழைகள் ஏற்பட்டால் இந்த விவரங்களைக் காட்டவில்லையா?
இந்த நற்சான்றிதழ்களை odbc.ini இல் குறிப்பிடுவதே இங்கு உண்மையான தீர்வாகும், மேலும் ClickHouse இல் ODBC தரவு மூலப் பெயரை மட்டும் குறிப்பிட வேண்டும். மற்ற அகராதி மூலங்களுக்கு இது நடக்காது - MySQL உள்ள அகராதி அல்லது மற்றவற்றிற்கு, நீங்கள் பிழைச் செய்தியைப் பெறும்போது கடவுச்சொல்லைப் பார்க்கக்கூடாது. ODBCக்கு, நானும் பார்க்கிறேன் - அது இருந்தால், நீங்கள் அதை அகற்ற வேண்டும்.
போனஸ்: கூட்டங்களில் இருந்து பெரிதாக்குவதற்கான பின்னணிகள்
படத்தைக் கிளிக் செய்வதன் மூலம், கூட்டங்களில் இருந்து போனஸ் பின்னணிகள் மிகவும் தொடர்ச்சியான வாசகர்களுக்கு திறக்கப்படும். Avito டெக்னாலஜி சின்னங்களுடன் சேர்ந்து தீயை அணைக்கிறோம், சிஸ்டம் அட்மினிஸ்ட்ரேட்டரின் அறை அல்லது பழைய பள்ளி கணினி கிளப்பில் இருந்து சக ஊழியர்களிடம் ஆலோசனை நடத்துகிறோம், மேலும் கிராஃபிட்டியின் பின்னணியில் பாலத்தின் கீழ் தினசரி சந்திப்புகளை நடத்துகிறோம்.
ஆதாரம்: www.habr.com